Shelly Button1 per Shelly Binding

[redaeq]

Hi, könnte mir einer von euch Mal die Konfig von eurem Button1 zur Verfügung stellen.
Ich habe versucht den Button einzubinden, aber gerade der Status Event lässt kein Item zu.
Habe gelesen, das geht über den Channeltrigger direkt über die Rules. Aber das funktioniert leider auch nicht.
Als Triggerwerte habe ich schon S, Short,Short_pressed versucht ....klappt alles nicht.

[Snatsch]

Code: Alles auswählen

rule "Türklingel wurde gedrückt"

when Channel "shelly:shellybutton1:98cdac2de98a:status#button" triggered 

then Meldung.postUpdate("Es hat geklingelt")
end 

so läuft es bei mir

[mad-mike]

Moin,

Macht der vielleicht ein unterschied mit groß und klein Schreibung??

habe z.B.:

Code: Alles auswählen

Channel "shelly:shelly1:f75aa81704:relay#button" triggered LONG_PRESSED              //Taster Flurlicht

das funktioniert.

Im Log müsste ja auch was stehen, wenn du den Button drückst.

[redaeq]

mhh, was habt ihr im button1 ein oder ausgeschaltet?
Muss die "Action" enabled sein ohne eine URL drin, reicht es sie zu disablen?
Wie sieht es mit CoIoT oder MQTT aus, was muss an was muss aus?

[redaeq]

Ich glaube es liegt an der Kombination Docker und Unicast an den Docker der im bridge Modus ist...
shellybutton1-c8c9a370289b: CoIoT peer in device settings does not point this to this host
I

[Snatsch]

Hallo.
die Rule mit dem Klingelknopf ist bei mir immer gelaufen. Jetzt wird leider das Signal wenn ich den Button einmal kurz drücke nicht weitergegeben. Also im Log kommt nicht an das ich den Shelly gedrückt habe. Hat vielleicht jemand eine Idee warum es nicht mehr geht ? Das Thing ist online und eingebunden war es schon immer über das Shelly Binding

[the-ninth]

Hi, könnte mir einer von euch Mal die Konfig von eurem Button1 zur Verfügung stellen.
Ich habe versucht den Button einzubinden, aber gerade der Status Event lässt kein Item zu.
Habe gelesen, das geht über den Channeltrigger direkt über die Rules. Aber das funktioniert leider auch nicht.

Es geht auch nur über die Kanäle die man einem Item zuordnen kann: man setzt den Trigger auf den Event Count (Point "Switch_EG_AE_Lichtschalter_Event_Count" im Beispiel unten) und eine Bedingung auf Last Event (Point "Switch_EG_AE_Lichtschalter_Last_Event"):

Code: Alles auswählen

triggers:
  - id: "4"
    configuration:
      itemName: Switch_EG_AE_Lichtschalter_Event_Count
    type: core.ItemStateChangeTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: Switch_EG_AE_Lichtschalter_Last_Event
      state: S
      operator: =
    type: core.ItemStateCondition

[SmartDave]

Hallo,

bei mir besteht das Problem, dass Shellys, welche über einen Fritz Mesh Repeater mit dem Netzwerk verbunden sind keine Push Events durchgeben. Das funktioniert nur bei den Shelly, welche direkt mit der Fritzbox verbunden sind.
Hat jemand eine Ahnung, woran das ligen kann und welche Lösungsmöglichkeiten bestehen?
Eine separate SSID (zweites WLAN) kommt für mich nicht in Frage.

[udo1toni]

Das hat nichts mit den SSIDs zu tun. Ich betreibe bei mir drei AP, jeder der drei AP hat drei (mit den anderen zwei AP identische) SSIDs. Die SSIDs kennzeichnen unterschiedliche LAN (bei mir logisch (VLAN), meist aber physisch. Am ehesten wäre also die Frage, ob Du einen zweiten AP aufbauen kannst (z.B. eine zweite FRITZ!Box, welche dann per LAN (nicht WLAN) mit der ersten FRITZ!Box mesht.

Auf die Frage nach dem Warum kann ich nur raten, dass die Repeater evtl. nicht nur repeaten, sondern nebenbei auch noch ein eigenes Subnetz aufmachen (wäre dann z.B. nicht 192.168.178.x, sondern 192.168.177.x) Es kann aber auch reichen, dass der repeater "nur" repeatet.
Der Punkt ist halt, dass es zwei zusätzliche Hops für die Verbindung gibt, und vermutlich geht da das Advertisement nicht rüber.
Falls dem so ist, wäre das ein Fehler in der Firmware der Repeater, die müssen natürlich möglichst transparent sein.
Machen die Geräte hingegen eigene Subnetze auf, ist eher die Frage, warum man das nicht konfigurieren kann...

[SmartDave]

...und hier folgt die Auflösung:

Der Mesh-Netzwerkaufbau (hier Fritzbox u. Fritz Power-LAN) war nicht direkt das Problem. Sondern der PiHole im Netzwerk. Dadurch waren die Shellys hinter dem Repeater nur noch Schaltbar, aber blind für http-Befehle anderer Shellys sowie Stumm, was Events wie "LONG_PRESSED" angeht.
Die Lösung: in den einzelnen Shellys die IP als statisch setzen und die 192.168.178.1 (Router) als Gateway- und DNS-Adresse festlegen.

Dadurch hat das Ärgernis ein Ende und alle Shellys funktionieren vollumfänglich!