NEWS
Hue Motion Sensor Delay
-
@J3ff3 die HUE Bewegungsmelder funktionieren nicht zuverlässig über zigbee. Die melden sich nach einiger Zeit einfach ab. Steht auch schon irgendwo hier im Forum.
@peterfido hab ihn jetzt mal eingebunden, mal sehen ob es funktioniert :) ich werde berichten...
zumindest der Dimmschalter funktioniert super :)
-
@peterfido hab ihn jetzt mal eingebunden, mal sehen ob es funktioniert :) ich werde berichten...
zumindest der Dimmschalter funktioniert super :)
Problem ist wie schon beschrieben das Polling der Bridge über ioBroker. Nach unserer Erfahrung können wir den Status des BW auch über eine node-red-Integration abfragen, mit dem Vorteil, dass hier die Verzögerung deutlich geringer ist (Umsetzung z.B. hier).
Smart starten und helfen: www.smarthomejetzt.de
Synology DS718+ | ioBroker | Docker | Home Assistant | FHEM | HUE | Aqara/Xiaomi | Tasmota | WLED | Shelly | Tradfri | Homematic | Nuki | Roborock S5
-
Problem ist wie schon beschrieben das Polling der Bridge über ioBroker. Nach unserer Erfahrung können wir den Status des BW auch über eine node-red-Integration abfragen, mit dem Vorteil, dass hier die Verzögerung deutlich geringer ist (Umsetzung z.B. hier).
@florianshj said in Hue Motion Sensor Delay:
Problem ist wie schon beschrieben das Polling der Bridge über ioBroker. Nach unserer Erfahrung können wir den Status des BW auch über eine node-red-Integration abfragen, mit dem Vorteil, dass hier die Verzögerung deutlich geringer ist (Umsetzung z.B. hier).
Ohne den an sich guten Vorschlag zu sehr schlecht zu reden - dieses Vorgehen funktioniert nur so lange wie es sich um wenige Geräte handelt die so überwacht werden sollen. Auch hier muss ein regelmässiges Abfragen der Hue Bridge per polling erfolgen, so das sich die Vorteile einer kürzeren Abfragezeit pro Sensor durch eine Vervielfachung der Abfragen (1 pro Sensor) schnell aufheben können.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@florianshj said in Hue Motion Sensor Delay:
Problem ist wie schon beschrieben das Polling der Bridge über ioBroker. Nach unserer Erfahrung können wir den Status des BW auch über eine node-red-Integration abfragen, mit dem Vorteil, dass hier die Verzögerung deutlich geringer ist (Umsetzung z.B. hier).
Ohne den an sich guten Vorschlag zu sehr schlecht zu reden - dieses Vorgehen funktioniert nur so lange wie es sich um wenige Geräte handelt die so überwacht werden sollen. Auch hier muss ein regelmässiges Abfragen der Hue Bridge per polling erfolgen, so das sich die Vorteile einer kürzeren Abfragezeit pro Sensor durch eine Vervielfachung der Abfragen (1 pro Sensor) schnell aufheben können.
A.
@asgothian Das stimmt natürlich, aber bei deutlich unter 10 Bewegungsmeldern solltes immernoch deutlich besser funktionieren, als das Abfragen des Presence-Objekts des HUE-Adapters.
-
@florianshj said in Hue Motion Sensor Delay:
Problem ist wie schon beschrieben das Polling der Bridge über ioBroker. Nach unserer Erfahrung können wir den Status des BW auch über eine node-red-Integration abfragen, mit dem Vorteil, dass hier die Verzögerung deutlich geringer ist (Umsetzung z.B. hier).
Ohne den an sich guten Vorschlag zu sehr schlecht zu reden - dieses Vorgehen funktioniert nur so lange wie es sich um wenige Geräte handelt die so überwacht werden sollen. Auch hier muss ein regelmässiges Abfragen der Hue Bridge per polling erfolgen, so das sich die Vorteile einer kürzeren Abfragezeit pro Sensor durch eine Vervielfachung der Abfragen (1 pro Sensor) schnell aufheben können.
A.
@asgothian
@J3ff3Ich habe ne handvoll BWM von HUE , weil die für mich zuverlässig und stabil arbeiten.
Homematic ist für mich noch ne andere Liga, aber anderes Thema.
Ich benutze den "normalen" HUE Adapter und Node Red für die Einbindung.Mal schauen wie die Reaktionszeiten so sind:
Hue Adapter = knapp 1sek bis Schalten des Datenpunktes auf true, Licht geht aber dann sofort an.
Ca. 11sek bis zum Zurücksetzen des Datenpunktes auf false, sodass Bewegung wieder erkannt werden kann.Node-Red = 0,8 sek bis zur Erkennung, Licht geht auch sofort an.
Ca.8 sek bis Schalten auf false.Polling der HUE Bridge ist auf 5 sek eingestellt.
Von der Reaktion und Wiedererkennung von Bewegung ist Node-Red vorne in meinem Test.
Synology DS218+ & 2 x Fujitsu Esprimo (VM/Container) + FritzBox7590 + 2 AVM 3000 Repeater & Homematic & HUE & Osram & Xiaomi, NPM 10.9.4, Nodejs 22.21.0 ,JS Controller 7.0.7 ,Admin 7.7.19
-
@asgothian
@J3ff3Ich habe ne handvoll BWM von HUE , weil die für mich zuverlässig und stabil arbeiten.
Homematic ist für mich noch ne andere Liga, aber anderes Thema.
Ich benutze den "normalen" HUE Adapter und Node Red für die Einbindung.Mal schauen wie die Reaktionszeiten so sind:
Hue Adapter = knapp 1sek bis Schalten des Datenpunktes auf true, Licht geht aber dann sofort an.
Ca. 11sek bis zum Zurücksetzen des Datenpunktes auf false, sodass Bewegung wieder erkannt werden kann.Node-Red = 0,8 sek bis zur Erkennung, Licht geht auch sofort an.
Ca.8 sek bis Schalten auf false.Polling der HUE Bridge ist auf 5 sek eingestellt.
Von der Reaktion und Wiedererkennung von Bewegung ist Node-Red vorne in meinem Test.
@haselchen said in Hue Motion Sensor Delay:
Von der Reaktion und Wiedererkennung von Bewegung ist Node-Red vorne in meinem Test.
Schon klar. Wie ich auch oben geschrieben habe - das ist eine gute und schnelle Lösung.
Ich wollte nur davor warnen das diese schnelle Lösung bei 10 oder 20 überwachten Geräten dann wieder zu den Problemen führen kann die man auch bekommt wenn man das Pols-Intervall des Hue Adapter zu kurz einstellt.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@haselchen said in Hue Motion Sensor Delay:
Von der Reaktion und Wiedererkennung von Bewegung ist Node-Red vorne in meinem Test.
Schon klar. Wie ich auch oben geschrieben habe - das ist eine gute und schnelle Lösung.
Ich wollte nur davor warnen das diese schnelle Lösung bei 10 oder 20 überwachten Geräten dann wieder zu den Problemen führen kann die man auch bekommt wenn man das Pols-Intervall des Hue Adapter zu kurz einstellt.
A.
Bei der Anzahl von Geräten stimme ich Dir zu.
Ich hab "nur" 5 von den Dingern. Da läuft es zufriedenstellend.
Bei sehr viel mehr wird das Polling wahrscheinlich in die Knie gehen.Synology DS218+ & 2 x Fujitsu Esprimo (VM/Container) + FritzBox7590 + 2 AVM 3000 Repeater & Homematic & HUE & Osram & Xiaomi, NPM 10.9.4, Nodejs 22.21.0 ,JS Controller 7.0.7 ,Admin 7.7.19
-
Bei der Anzahl von Geräten stimme ich Dir zu.
Ich hab "nur" 5 von den Dingern. Da läuft es zufriedenstellend.
Bei sehr viel mehr wird das Polling wahrscheinlich in die Knie gehen.Aber woran liegt es dass es über die hue app schneller geht ?
-
Aber woran liegt es dass es über die hue app schneller geht ?
-
na wenn ich über die HUE App programmiere, dass der Motion Sensor dann das Licht an macht als wenn ich es über Blockly komplett mache.
Da läuft der Motion Sensor von HUE ganz gut, aber über HUE Adapter und Blockly dauert es gefühlt 2-3 Sek bis er anspringt und das Polling hab ich schon runtergesetzt sogar :-)
-
na wenn ich über die HUE App programmiere, dass der Motion Sensor dann das Licht an macht als wenn ich es über Blockly komplett mache.
Da läuft der Motion Sensor von HUE ganz gut, aber über HUE Adapter und Blockly dauert es gefühlt 2-3 Sek bis er anspringt und das Polling hab ich schon runtergesetzt sogar :-)
-
na wenn ich über die HUE App programmiere, dass der Motion Sensor dann das Licht an macht als wenn ich es über Blockly komplett mache.
Da läuft der Motion Sensor von HUE ganz gut, aber über HUE Adapter und Blockly dauert es gefühlt 2-3 Sek bis er anspringt und das Polling hab ich schon runtergesetzt sogar :-)
@olli_m sagte in Hue Motion Sensor Delay:
na wenn ich über die HUE App programmiere, dass der Motion Sensor dann das Licht an macht als wenn ich es über Blockly komplett mache.
Da läuft der Motion Sensor von HUE ganz gut, aber über HUE Adapter und Blockly dauert es gefühlt 2-3 Sek bis er anspringt und das Polling hab ich schon runtergesetzt sogar :-)
Philips ist da eigen.
Die eigene App kommuniziert direkt ohne Umwege mit der Bridge - und nutzt dabei Funktionen die nicht in der API abgebildet sind. Es ist auch denkbar das die App die Verbindung Motion Sensor -> Lampe direkt auf die Bridge auslagert, während der ioBroker nur über die RestAPI zugreifen kann - was zeit kostet.
Warum ? Damit die Leute lieber Hue Bridge, Hue App und Hue leuchten nutzen und nicht 3rd Party zigbee :)
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@olli_m sagte in Hue Motion Sensor Delay:
na wenn ich über die HUE App programmiere, dass der Motion Sensor dann das Licht an macht als wenn ich es über Blockly komplett mache.
Da läuft der Motion Sensor von HUE ganz gut, aber über HUE Adapter und Blockly dauert es gefühlt 2-3 Sek bis er anspringt und das Polling hab ich schon runtergesetzt sogar :-)
Philips ist da eigen.
Die eigene App kommuniziert direkt ohne Umwege mit der Bridge - und nutzt dabei Funktionen die nicht in der API abgebildet sind. Es ist auch denkbar das die App die Verbindung Motion Sensor -> Lampe direkt auf die Bridge auslagert, während der ioBroker nur über die RestAPI zugreifen kann - was zeit kostet.
Warum ? Damit die Leute lieber Hue Bridge, Hue App und Hue leuchten nutzen und nicht 3rd Party zigbee :)
A.
Vielen Dank für die gute Erklärung - ich habe genau dieselbe Herausforderung. Zwei Hue BWM für drei IKEA-Lampen (Floalt/Tradfri). Solange die IKEA-Lampen in der Hue Bridge angemeldet waren, war die Reaktionszeit BWM > Lampe ok. Ich habe die Lampen jetzt über iobroker.Zigbee im System. Da ist die Kombination träge und unzuverlässig. Entweder mache ich das wieder über Hue oder ich nehme zwei andere BWM. Mal schauen...
Das Thema NodeRed hatte ich bislang komplett außen vor gelassen. Vielleicht sollte ich mich doch nochmal damit befassen.
Support us
850
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge