Lampen reagieren unzuverlässig, aber nur wenn Automation mit Schalter ausgelöst wird

Warlaan

New member
Moin,

ich habe ein Problem, das ich mir nicht erklären kann.

Ich habe unser Haus mit Zigbee-Lampen unterschiedlicher Hersteller ausgestattet. Zu Beginn hatte ich nur einen Hue-Hub, wollte die Lampen aber mit IKEA-Schaltern schalten, und habe mir daher noch den Conbee II zugelegt.
Zusammen mit der deConz-/Phoscon-Software hat er gut funktioniert, spätestens nachdem ich den Hue-Gateway rausgeworfen und alles auf den Stick umgemeldet habe.

Jetzt habe ich mir allerdings noch weitere Sensoren gekauft, die von deconz noch nicht unterstützt sind, und habe daher das System auf zigbee2mqtt umgerüstet.
Das funktioniert auch soweit sehr gut, allerdings habe ich ein sehr verrücktes Problem:

Wenn ich die Lampen im Wohnzimmer ausschalte, reagieren sie sehr gut und zuverlässig, wenn ich sie über den Home-Assistant-Server schalte, also zB über das Handy oder das Webinterface.
Wenn ich jedoch dasselbe per Tradfri-Schalter mache, bleiben jedesmal einige Lampen an. Der Server ist dabei allerdings davon überzeugt, dass alle Lampen aus wären. Selbst im Zigbee2Mqtt-Inferface werden die Lampen als aus angezeigt.

Ich hatte erst vermutet, dass es eine Wechselwirkung zwischen der HA-Gruppe und den einzelnen Lichtern sein könnte, und habe daher alles auf Zigbee-Gruppen umgebaut, was die Steuerung vom Handy aus auch noch zuverlässiger gemacht hat, vom Lichtschalter aus gibt es aber immer noch dasselbe Problem.
Selbst wenn ich die Automation, die den Lichtschalter abfragt und dann die Gruppe ausschaltet, manuell über das Webinterface starte, funktioniert alles. Es scheint wirklich nur am Schalter zu liegen.

Im Zigbee2MQTT-Log kann ich auch keinen Unterschied erkennen, außer dass natürlich die Signale vom Schalter zuerst versendet werden. Alle folgenden Datenpakete sehen bei den zwei Verfahren völlig identisch aus.

Hat jemand eine Idee, woran das liegen könnte?
 
Hi :)

Also auch, wenn ich von der Thematik gar keine Ahnung habe, so wirklich logisch erscheint mir das jetzt nicht grade... So wie ich das verstehe, löst der Schalter doch auch nur eine Automatisierung aus, welche Du auch direkt via HA auslösen kannst. Kurzum: "Schalter drücken = löse die Automatisierung aus". Als ganz banales Beispiel nehmen wir jetzt einfach einen binären Status: "0 oder 1".

Schaltest Du via HomeAssistant "ein", ist der Status "1". Schaltest Du via Schalter "ein", ist der Status "1". Für mich macht das jetzt erstmal keinen Unterschied. Allerdings - wie gesagt - hab ich davon auch keine Ahnung, aber dieser "Schalter" ist nicht zufällig noch irgendwie auf anderem Wege mit den Lampen verbunden (direkt oder über eine Basis, oder weiss der Geier wie)?
 
Die Vermutung hatte ich auch kurz, aber als ich die Automation deaktiviert habe, hat sich gar nichts mehr getan, weder bei ein- noch bei ausgeschalteten Lichtern. Außerdem ist es ja unregelmäßig, es sind also nicht immer dieselben Lampen betroffen (außer dass alle fraglichen Lampen in demselben Raum sind).

Ich glaube inzwischen eher, dass es etwas mit der Menge an Nachrichten zu tun hat. Wenn ich per Handy umschalte, geht der Weg zu HA über das WLAN. Wenn ich es per Schalter auslöse, gehen zeitgleich die Nachrichten vom Schalter über das Zigbee-Netzwerk zum HA-Server. Allerdings habe ich schon probiert, ein Delay in die Automation einzubauen, so dass die Nachrichten vom Schalter längst alle Zigbee-Geräte erreicht haben müssten.

Mein Plan ist jetzt zum einen einfach erstmal ein paar Tage zu warten, in der Hoffnung, dass sich vielleicht ein paar Geräte noch anders verbinden und das Problem damit verschwindet. Wenn das nicht eintreffen sollte, wollte ich mit QoS, debounce und der Einstellung für "optimistic" experimentieren.
 
Kurzes Update für alle, die ein vergleichbares Problem haben:
Ich habe das Problem jetzt umgangen, indem ich zum einen wieder auf deConz / Phoscon mit dem Conbee-II-Stick gewechselt habe, und indem ich alles über Zigbee-Gruppen gelöst habe.


Der Wechsel auf deConz hat dazu geführt, dass der Status von Lampen immer korrekt angezeigt wird. Sowohl mit ZHA als auch mit Zigbee2Mqtt kam es immer wieder vor, dass eine Lampe nicht reagiert hat, HA darüber aber nicht informiert wurde. Das ist mir jetzt nicht mehr passiert.
Dass nicht alle Geräte von deConz erkannt werden, habe ich so gelöst, dass ich auf demselben Raspberry auch noch Zigbee2Mqtt mit einem Sonoff Stick laufen habe. Der übernimmt dann die paar "exotischeren" Sensoren. Die große Entfernung zwischen Sensoren und dem Stick ist dabei kein Problem. Ich vermute sogar, dass im anderen Netzwerk die große Anzahl von Sendern auf kleinem Raum ein größeres Problem ist.


Gruppen haben das Reaktionsverhalten der Lampen deutlich verbessert. Technisch bedeutet der Wechsel, dass jetzt alle Lampen selbst wissen, zu welcher Gruppe sie gehören, und wenn einmal gesagt wird, dass sich Gruppe XY abschalten soll, reagieren alle Lampen einer Gruppe darauf. Dadurch reicht ein Befehl um einen ganzen Raum zu schalten.
Wenn man Szenen auf diese Weise abspeichert, kennen die Lampen auch bestimmte Zustände, die sie einnehmen sollen, wenn ein Befehl an die Gruppe geschickt wird.
Das Ergebnis ist, dass jetzt alle Lichter gleichzeitig schalten, während man vorher deutlich sehen konnte, wie nacheinander Befehle bei den unterschiedlichen Lichter ankamen (oder eben auch nicht).


Es wird manchmal von Gruppen abgeraten, weil sie so teuer wären. Das ist technisch richtig, denn für Gruppenbefehle gibt es ein recht niedriges Limit, ich glaube bei 6 oder so. Wenn mehr Befehle als das in einem Zeitfenster von einigen Sekunden gegeben werden, werden die letzten nicht weitergeleitet. Wenn man aber von einer Gruppe mit 5 Lichtern ausgeht, dann wären das schon 30 Befehle in dieser Zeit. Die würden nach meiner Erfahrung deutlich größere Probleme verursachen. Deswegen kann man die Frage "Gruppen ja oder nein" nicht so pauschal beantworten.

Auslöser des ganzen Problems sind vermutlich die Ikea-Tradfri-Schalter (die einfachen "Kippschalter" mit zwei Schaltflächen - andere habe ich nicht, kann sie also nicht beurteilen). Die scheinen Befehle gerne mehrfach abzuschicken und damit das Netzwerk zu überfluten. Selbst jetzt habe ich nämlich gelegentlich das Problem, dass ein Schalter doppelt auslöst, wenn ich einmal draufdrücke. Möglicherweise muss ich da aber auch nur mal die Batterie wechseln.
 
Auslöser des ganzen Problems sind vermutlich die Ikea-Tradfri-Schalter
Wie benutzt Du die denn, um zu schalten? Hast Du da einzelne Automatisierungen, die auf die Events der Taster reagieren?
Ich nutze hier ControllerX für alle ZigBee Taster/Drehregler und ich habe solche Probleme überhaupt nicht. Ich nutze dabei EInfach-/Doppel-/Dreifach/langen-Klick bei vielen Tasten und alles wird passend ausgewertet, aber eben ganz ohne Automatisierungen.
 
ControllerX kannte ich noch nicht, allerdings klingt das für mich wie eine bessere Oberfläche um Zigbee Bindings zu erstellen. Das wäre also im Grunde derselbe Ansatz, mit dem ich auch das größere Problem schon gelöst habe, da dann die "Automation" direkt in den Devices gespeichert wäre und der Hub gar nichts mehr zu tun hat.

Leider funktioniert das nicht für meinen Anwendungsfall, deswegen verwende ich in der Tat HA-Automationen. Ich habe es bei mir so eingerichtet, dass wir an zentralen Stellen jeweils einen Schalter haben, und was der schaltet hängt davon ab, was schon an bzw. aus ist.
Beispiel: Wir haben einen offenen Bereich mit Küche und Wohnzimmer in einem und dem Treppenhaus ohne Türen angeschlossen.
Der erste Ort, an dem ich abends Licht haben will, ist das Treppenhaus, also schaltet der Lichtschalter in der Küche immer erst das Treppenhaus ein. Wenn das aber schon an ist, schaltet er das Licht in der Küche. Später am Abend gehen manche dann ins Wohnzimmer während andere noch in der Küche sind, also schaltet der Lichtschalter beim nächsten Druck das Wohnzimmer an.
Sobald keiner mehr in der Küche ist, drückt man auf aus und die Küche geht als erstes aus. Wenn man dann auch nicht mehr im Wohnzimmer ist, drückt man nochmal auf aus und das Wohnzimmer geht aus. Und am Ende des Tages drückt man nochmal auf aus und auch das Treppenhaus ist aus.

Im Schlafzimmer schalter der Lichtschalter auf diese Weise erst den Radiowecker aus. Im Sommer drücke ich danach nochmal auf aus und das weckergesteuerte Licht im Schlafzimmer geht aus, im Winter drücke ich stattdessen auf an und das Licht im Flur und die Warmwasserzirkulation gehen an.

Auf diese Weise brauchen wir nur sehr wenige, zentrale Lichtschalter, und es gibt für uns fast keine Situationen, wo man tatsächlich mehrfach hintereinander drücken müsste, um das gewünschte Ergebnis zu erhalten.
Aber der Nachteil ist in der Tat, dass ich viele Bedienungs- und technische Vereinfachungen nicht nutzen kann, die von der klassischen 1-zu-1-Kombination von Schaltern und zu steuernden Gruppen ausgehen.
 
allerdings klingt das für mich wie eine bessere Oberfläche um Zigbee Bindings zu erstellen.
Nein, das hat damit überhaupt nichts zu tun!
Es ist eine Software, die auf dem Home Assistant Rechner läuft und einfach nur die Verbindung zwischen ZigBee Tastern und Geräten herstellt.

Dazu muß man eine Datei editieren, in der man die Konfigurationen ablegt:
Hiermit habe ich z.B. einen Ikea 1810 Taster (der alte runde mit den fünf Tasten) einem LED-Streifen zugeordnet und kann mit dem Taster die Ein/Aus, die Helligkeit und die Farben einstellen.
YAML:
  wohnzimmer_controller_licht:
    module: controllerx
    class: E1810Controller
    controller: tradfri_fernbedienung
    integration: deconz
    light: light.fernseher_led

Hiermit steuere ich die Musik im Dachboden mit einem Ikea Symfonisk Drehregler über meinen Logitech Media Server:
YAML:
  dachboden_controller_lms:
    module: controllerx
    class: E1744MediaPlayerController
    controller: lautstarkeregler_dachboden
    integration: deconz
    media_player: media_player.dachboden
    volume_steps: 30
    merge_mapping:
      1005:
        service: switch.toggle
        entity_id: switch.leiste_2
Mit einem Dreifachklick (Event 1005) kann ich dabei den Strom vom Lautsprecher ein-/ausschalten.

Wie und ob man diese Schritte, wie Du sie hast, mit ControllerX hinbekommt, weiß ich nicht auf Anhieb, da ich nur recht einfache Dinge, die ich auch nach Monaten noch verstehe in der Konfiguration habe.

ControllerX (https://xaviml.github.io/controllerx/) läuft also anstelle der Automatisierungen. ControllerX kann dabei auf ZigBee, State, MQTT, Lutron Caseta, Homematic, Shelly und Tasmota Events reagieren und beliebige Geräte, Szenen oder was auch immer auslösen.
 
Ok, danke für den Hinweis, das klingt spannend.

Wenn es auf dem HA-Server läuft, würde ich spontan nicht erwarten, dass es das Problem mit den mehrfach auslösenden Schaltern beheben kann, aber einen Versuch ist es wert.

Allerdings habe ich das Problem auch nur bei einem Schalter und auch nur ganz sporadisch, deswegen vermute ich, dass es entweder mit der Batterie zu tun haben kann oder noch ganz andere Gründe hat. Neulich habe ich 10 Minuten nach einem Bug gesucht bis ich gemerkt habe, dass einfach kurz nachdem ich einen Schalter gedrückt hatte die Dämmerungsautomation angegangen ist.
Wenn das Vertrauen erst einmal weg ist, sieht man Bugs, wo gar keine sind. :)
 
dass es das Problem mit den mehrfach auslösenden Schaltern beheben kann, aber einen Versuch ist es wert.
Es kann ja durchaus sein, daß die Taster prellen. Eine gewisse Entprellzeit sollte man einbauen, was vielleicht bei ControllerX der Fall ist.

Reagierst Du denn in Deinen Automatisierungen auf das spezielle Event des Einfachklicks oder auf alles, was von dem Taster kommt?
 
Ich reagiere gezielt auf die "on"- und "off"-Events.
Ich hatte mir das Problem noch nicht genauer angesehen, weil der Fehler noch nicht oft genug vorgekommen ist. Ich könnte in der Tat mal einen Schalter mit Zigbee2Mqtt verbinden, weil man da das Mqtt-Log sehr gut einsehen kann. Da müsste es ja erkennbar sein, ob der Taster das Signal nur einmal oder mehrfach versendet.
Allerdings müsste es auch im HA-Log zu sehen sein, denn wenn meine Vermutung richtig ist, löst die Automation ja sogar doppelt aus.

Ich kenne es von den 433MHz-Sendern, dass Signale mehrfach gesendet werden, weil beim verbindungslosen Protokoll davon ausgegangen wird, dass da welche verloren gehen. Im Regelfall, wo "Schalter an" auch einfach nur "Lampe 1 an" bedeutet, ist das ja auch völlig unproblematisch.

Es könnte auch sein, dass das Signal vom Schalter auf mehr als einem Weg beim Conbee ankommt und dadurch doppelt wahrgenommen wird... ich sehe es mir mal bei Gelegenheit an. Aktuell läuft aber alles stabil genug, dass ich mich nicht sofort darum kümmern muss.
 
Ich reagiere gezielt auf die "on"- und "off"-Events.
So etwas kenne ich von deCONZ nicht.

Dies hier ist z.B. das Event, das kommt, wenn ich meinen Ikea Symfonisk einmal drücke:
Code:
event_type: deconz_event
data:
  id: lautstarkeregler_dachboden
  unique_id: 14:b4:76:20:d2
  event: 1002
  device_id: 8d97780eac1e2dfcbe626
origin: LOCAL
time_fired: "2023-05-05T12:41:18.058333+00:00"
context:
  id: 01GZNZ0DT8HQQ8KY2
  parent_id: null
  user_id: null

Wichtig ist in dem Fall die "1002", die einmal Drücken bedeutet.
Wenn ich zweimal drücke, kommt das hier:
Code:
event_type: deconz_event
data:
  id: lautstarkeregler_dachboden
  unique_id: 14:b4:76:20:d2
  event: 1004
  device_id: 8d97780eac1e2dfcbe626
origin: LOCAL
time_fired: "2023-05-05T12:43:21.300962+00:00"
context:
  id: 01GZNZ0DT8HQQ8KY2
  parent_id: null
  user_id: null
also das event "1004", das für zweimal drücken steht.

Die Events kannst Du unter Entwicklerwerkzeuge->Ereignisse-Hören auf Ereignisse und dort eintragen von "deconz_event" und dann "Anfangen zuzuhören" sehen.

Da wird auch nichts mehrfach gesendet.

Es könnte auch sein, dass das Signal vom Schalter auf mehr als einem Weg beim Conbee ankommt und dadurch doppelt wahrgenommen wird
Das würde ich auch ausschließen.
 
Ich weiß, ich hatte vor HA OpenHAB verwendet und da musste ich die 1002, 1004 etc angeben. Bei Home Assistant wird es mir als "Turn on" pressed, "Turn on" continually pressed, "Turn on" released after long press usw. angezeigt.

Wie sehen denn bei dir die Routings aus, wenn du sie dir in deConz, Zigbee2Mqtt oder was auch immer anzeigen lässt? Bei mir war da nie ein klarer Weg vom Schalter über einen Router zum Empfänger erkennbar, sondern es ist immer irgendwie alles mit allem verbunden. Daher gehe ich stark davon aus, dass einfach jeder Repeater jede Message wiederholt, sofern er sie nicht schon gesehen hat. Das ist jedenfalls auch meine einzige Erklärung, warum die Lampen in der ursprünglichen Version so unzuverlässig reagiert haben.

Dass man davon im Log im Regelfall nichts sieht, ist mMn eher auf ein entsprechendes Filtering zurückzuführen, so dass man die Duplikate einfach nicht angezeigt bekommt. Das ist aber nur eine Vermutung.
Ich sehe mir mal an, was bei mir in den Logs angezeigt wird, wenn ich so eine "Fehlzündung" habe. Eine bessere Erklärung habe ich jedenfalls noch nicht dafür. Ein mechanisches Mehrfachauslösen halte ich nun wieder für unwahrscheinlich.
 
Bei Home Assistant wird es mir als "Turn on" pressed, "Turn on" continually pressed, "Turn on" released after long press usw. angezeigt.Das
Ach so. Ich habe ja wie geschrieben keine Automatisierungen mit ZigBee Tastern und früher sah das anders aus.
Wie sehen denn bei dir die Routings aus, wenn du sie dir in deConz
Keine Ahnung, die habe ich mir noch nie wirklich angesehen. Dafür müsste ich auch erst einmal deconz beenden und deconz-gui starten. Das läuft bei mir auf einem anderen Pi mit Raspberry Pi OS.
 

Zurzeit aktive Besucher

Keine Mitglieder online.

Letzte Anleitungen

Statistik des Forums

Themen
2.554
Beiträge
28.988
Mitglieder
1.962
Neuestes Mitglied
Papillon
Oben