NEWS
ZigBee neue Version 1.4.4
-
Hallo,
beim pingen auf ein ikea Floalt L1529 bekomme ich eine Warnmeldungwarn (3444) Failed to read state '"color_temp_startup"'of '0xbc33acfffed57c9d' after query with '{"code":134}'Der stat color_temp_startup steht auch nicht in der Objektliste
-
Hallo,
beim pingen auf ein ikea Floalt L1529 bekomme ich eine Warnmeldungwarn (3444) Failed to read state '"color_temp_startup"'of '0xbc33acfffed57c9d' after query with '{"code":134}'Der stat color_temp_startup steht auch nicht in der Objektliste
Damit wirst Du (erst einmal) leben müssen. Die Implementierung des Floalt im Zigbee-Herdsman gibt an das das Panel diesen Parameter unterstützt, daher versucht die Funktion diesen auszulesen. Die Meldung "Code:134" kommt vom Gerät selber, und bedeutet "unsupported attribute", i.e. das Panel meldet das es diesen Wert nicht unterstützt.
Es ist denkbar das in der Zukunft bestimmte Meldungen heraus gefiltert und dann nicht als Warnungen ausgegeben werden.
A.
-
Damit wirst Du (erst einmal) leben müssen. Die Implementierung des Floalt im Zigbee-Herdsman gibt an das das Panel diesen Parameter unterstützt, daher versucht die Funktion diesen auszulesen. Die Meldung "Code:134" kommt vom Gerät selber, und bedeutet "unsupported attribute", i.e. das Panel meldet das es diesen Wert nicht unterstützt.
Es ist denkbar das in der Zukunft bestimmte Meldungen heraus gefiltert und dann nicht als Warnungen ausgegeben werden.
A.
-
Hallo,
sorry das ich euch hier evtl jetzt nerve :/Mein setup: Mini PC mit Proxmox, iobroker in ner VM, CC26XXX Board
Alle Adapter und das System selbst aktuell.
Da der SOnoff Mini in der Stable Version als ??? angezeigt wurde und somit nicht erkant wurde, habe ich mir nun die Beta 1.4.4 geladen.Der Sonof wird erkannt.
ABER...
Ohne an der Hardware etwas geändert zu (der Sonof kam dazu!) sind nun einige meiner Lampen (Tradfri + Osram) nicht mehr erreichbar.
Ein anlernen war möglich, danach aber nicht mehr erreichbar.
Die Lampen wurden dort angelernt wo sie jetzt auch sind. - 1 Lampe ist ungefähr 3m vom Koordinator entfernt.Ja ich weis, der Screenshot bzw die Sendequalität ist nicht unbedingt korrekt, allerdings hatte ich mit 1.3.1 keine "Empfangsprobeme" und nun werden mir viele Geräte Orange und rot angezeigt?!
Schalter Katze + Bett sowie die Lampe Katze liegen nebeneinander. Lampe funktioniert nicht - nicht erreichbar, Schalter aber schon?Platzl Licht ist eine Osram und macht Probleme (seit dem Update) liegt ca 6 Meter entfernt vom Koordinator
Aromastudio Platzl ist eine Tradfri und liegt ungefähr 8 Meter NACH der Platzl Licht (ca 14Meter vom Koordinator entfernt) und macht derzeit keine Problem.. :(
evtl noch zu erwähnen: Gestern noch mit 1.3.1 war Kanal 11 mit 10% der beste kanal - alle andren lagen bei 50-80%
Heute nach dem Update habe gar keinen Kanal mehr unter 70% - in einer 300 Einwohner Gemeinde mit alterdurchschnitt 70+
Ich wäre dankbar, für hilfe um dieses Problem lösen zu können :)
Danke -
was ist neu
@Ilya : man kann externe konverter einbinmden für DIY Geräte
@Asgothian verbesserung des Pingprozesses - hier ist auch ein Button in den Objecten dazugekommen
@arteck Geräte können diert aus dem Converter gezogen werden auch wenn diese bei uns definiert sind
@Asgothian automatisches Löschen nicht gebrauchter Datenpunkte wenn man dem Ausschluss Tab nutzt
so uns nu lassen die Spiele beginnen
@Nachtrag da es hier zu vielen Fragen kommt
nach dem Update und nach dem Adapter start sind ALLE Geräte erstmal mit einer Link Quality von 10 in der Kacheln.. nach dem sich die Geräte gemeldet haben (Router) geht die Link Quality auf das was das Gerät lifert. bleibt die Link Quality auf 10 meldet sich das Gerät nicht, dass kann mehre Stunden dauern..also Geduld
ausser
die batteriebenen Geräte .. diese müssen sich erst melden. das dauert da sich diese selten Melden vor allem Aqara bzw. Xiaomi .. man kann es selbst antrigern per drücken des Knopfes am Gerät. erst dann sieht man die richtige Link Quality..Ich möchte dieses Mal über eine sehr positive Erfahrung bzgl. des Adapter Updates berichten - zumindest kurz was man nach der Installation sagen kann.
Vielleicht auch für den einen oder anderen ein paar Tipps.
Ich bin grundsätzlich ein Anhänger - meist nur "Stable" Versionen einzusetzen. Ich habe mich nun aber entschlossen, da mein node-red Adapter teilweise ein anderes Verhalten, als bei anderen Usern hier an Board an den Tag legt, doch auf die nodejs- Version 14 hochzurüsten, auch wenn das offiziell noch nicht empfohlen wird.
Gut also die NodeJS Version hochgezogen - alle starteten bis auf den zigbee - Adapter. :(
So nun an alle die das absichtlich oder unabsichtlich nachmachen also nodejs hochziehen - lasst Eurem System mal ca. 10-15 Minuten Zeit.
Die Ansteuerung des seriellen Ports wird bzw. für die neue nodejs Version neu kompiliert werden. Das erfolgt auch im HIntergrund - nur bekommt man davon erstmal nichts mit. :(Nach dieser Zeit bekommt man zwar ein paar Warnungen von der Neukompilierung der "serialport_unix.cpp" aber das klappte gut:
Die Version 1.3.1 des Adapters wurde wieder gestartet.
Dann dachte ich mir, dann probierst doch mal die neueste Version aus (also diese hier 1.4.4), da diese eine Funktion enthält, mit der man den Status der Geräte pullen kann, da dies ein großer Kritikpunkt für mich war, dass IST-Zustand mit dem Zustand der Datenpunkte leider nicht immer übereinstimmte und das war für mich ein großer Schwachpunkt. Sprich laut Datenpunkt, war eine Lampe aus, aber bestimmte Lampen, haben sich automatisch nachdem der Strom zurückkam eingeschaltet. Also ist dieser Ping Button in dieser Version mit der man den aktuellen Zustand direkt abfragen kann eine erhebliche Verbesserung.. Auch wenn es sicher eine Zeit dauern wird, bis ich meine Logik umgestellt habe - hilft das in jedem Fall.
Gut also die neueste Version von GitHub installiert.
Die Installation bzw. das Update das zigbee Adapter erfolgte ohne Probleme, Warnungen oder Fehlermeldungen mit Exit Code 0.
Es erfolgten nach einiger Zeit wieder die gleichen Fehlermeldungen - wie vorher. Es erfolgte erneut eine Rekompilierung der "serialport_unix.cpp" - und dann ein erfolgreicher Start der Version 1.4.4
Seitdem kann ich bislang also folgendes Feedback geben:
- Version konnte dieses Mal ohne Fehler installiert werden.
- Die Rekompilierung der "serialport_unix.cpp" muss man abwarten - erfolgte bei mir automatisch im Hintergrund.
- Die Anbindung des Sticks über den seriellen Port an den Adapter hat sich in meinen Augen sehr verbessert - früher waren manchmal mehrfache Neustarts erforderlich.
- Dieser PING Button ist es wert die neue Version zu installieren - auch wenn ich ihn noch nicht über meine Node Red Flows angesprochen habe.
- Ich habe bislang keine Probleme mit Gruppen oder einzelnen Geräten, die vorher auch gingen. Das der State zwischen der Gruppe und dem Einzelgerät nicht übereinstimmt - das hatte ich von Beginn an und steht ja nun auf der Liste. Das wird wahrscheinlich generell schwierig - da ich auch schon oft den Fall hatte, dass nach dem Stromausfall sich nicht alle Lampen einer Gruppe gleich verhielten. Es kam durchaus vor, dass eine Lampe von 3en in einer Gruppe brannte, die anderen beiden nicht.
Eine generelle Anregung zu zukünftigen Verbesserungen hätte ich dennoch - ich hoffe man versteht das nicht als Kritik. Vielleicht könnte man dem Adapter ja generell beibringen - dass er aktiv die Zustände (states) setzt, die zuletzt in den Datenpunkten gespeichert waren (Vielleicht als Option). Bei Sensoren macht das natürlich keinen Sinn, aber bei Aktoren, wäre das in meinen Augen durchaus sinnvoll.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
Ich möchte dieses Mal über eine sehr positive Erfahrung bzgl. des Adapter Updates berichten - zumindest kurz was man nach der Installation sagen kann.
Vielleicht auch für den einen oder anderen ein paar Tipps.
Ich bin grundsätzlich ein Anhänger - meist nur "Stable" Versionen einzusetzen. Ich habe mich nun aber entschlossen, da mein node-red Adapter teilweise ein anderes Verhalten, als bei anderen Usern hier an Board an den Tag legt, doch auf die nodejs- Version 14 hochzurüsten, auch wenn das offiziell noch nicht empfohlen wird.
Gut also die NodeJS Version hochgezogen - alle starteten bis auf den zigbee - Adapter. :(
So nun an alle die das absichtlich oder unabsichtlich nachmachen also nodejs hochziehen - lasst Eurem System mal ca. 10-15 Minuten Zeit.
Die Ansteuerung des seriellen Ports wird bzw. für die neue nodejs Version neu kompiliert werden. Das erfolgt auch im HIntergrund - nur bekommt man davon erstmal nichts mit. :(Nach dieser Zeit bekommt man zwar ein paar Warnungen von der Neukompilierung der "serialport_unix.cpp" aber das klappte gut:
Die Version 1.3.1 des Adapters wurde wieder gestartet.
Dann dachte ich mir, dann probierst doch mal die neueste Version aus (also diese hier 1.4.4), da diese eine Funktion enthält, mit der man den Status der Geräte pullen kann, da dies ein großer Kritikpunkt für mich war, dass IST-Zustand mit dem Zustand der Datenpunkte leider nicht immer übereinstimmte und das war für mich ein großer Schwachpunkt. Sprich laut Datenpunkt, war eine Lampe aus, aber bestimmte Lampen, haben sich automatisch nachdem der Strom zurückkam eingeschaltet. Also ist dieser Ping Button in dieser Version mit der man den aktuellen Zustand direkt abfragen kann eine erhebliche Verbesserung.. Auch wenn es sicher eine Zeit dauern wird, bis ich meine Logik umgestellt habe - hilft das in jedem Fall.
Gut also die neueste Version von GitHub installiert.
Die Installation bzw. das Update das zigbee Adapter erfolgte ohne Probleme, Warnungen oder Fehlermeldungen mit Exit Code 0.
Es erfolgten nach einiger Zeit wieder die gleichen Fehlermeldungen - wie vorher. Es erfolgte erneut eine Rekompilierung der "serialport_unix.cpp" - und dann ein erfolgreicher Start der Version 1.4.4
Seitdem kann ich bislang also folgendes Feedback geben:
- Version konnte dieses Mal ohne Fehler installiert werden.
- Die Rekompilierung der "serialport_unix.cpp" muss man abwarten - erfolgte bei mir automatisch im Hintergrund.
- Die Anbindung des Sticks über den seriellen Port an den Adapter hat sich in meinen Augen sehr verbessert - früher waren manchmal mehrfache Neustarts erforderlich.
- Dieser PING Button ist es wert die neue Version zu installieren - auch wenn ich ihn noch nicht über meine Node Red Flows angesprochen habe.
- Ich habe bislang keine Probleme mit Gruppen oder einzelnen Geräten, die vorher auch gingen. Das der State zwischen der Gruppe und dem Einzelgerät nicht übereinstimmt - das hatte ich von Beginn an und steht ja nun auf der Liste. Das wird wahrscheinlich generell schwierig - da ich auch schon oft den Fall hatte, dass nach dem Stromausfall sich nicht alle Lampen einer Gruppe gleich verhielten. Es kam durchaus vor, dass eine Lampe von 3en in einer Gruppe brannte, die anderen beiden nicht.
Eine generelle Anregung zu zukünftigen Verbesserungen hätte ich dennoch - ich hoffe man versteht das nicht als Kritik. Vielleicht könnte man dem Adapter ja generell beibringen - dass er aktiv die Zustände (states) setzt, die zuletzt in den Datenpunkten gespeichert waren (Vielleicht als Option). Bei Sensoren macht das natürlich keinen Sinn, aber bei Aktoren, wäre das in meinen Augen durchaus sinnvoll.
@mickym sagte in ZigBee neue Version 1.4.4:
Dieser PING Button ist es wert die neue Version zu installieren - auch wenn ich ihn noch nicht über meine Node Red Flows angesprochen habe.
Bitte prüfe:
durch die Anpassungen der Geräteabfrage sollte der Adapter bei einem Gerät welches sich "Neu" wieder anmeldet den Status von verschiedenen States vom Gerät automatisch abfragen. Insbesondere sind das die Helligkeit sowie der an/aus Zustand von Lampen.
Das ganze findet dann statt wenn
- ein Gerät als Offline erkannt wurde (available = false)
- das Gerät das erste mal eine Meldung sendet (available geht auf true).
Alle Lampen melden wenn sie Strom bekommen an das Netzwerk das sie "wieder da" sind.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@mickym sagte in ZigBee neue Version 1.4.4:
Dieser PING Button ist es wert die neue Version zu installieren - auch wenn ich ihn noch nicht über meine Node Red Flows angesprochen habe.
Bitte prüfe:
durch die Anpassungen der Geräteabfrage sollte der Adapter bei einem Gerät welches sich "Neu" wieder anmeldet den Status von verschiedenen States vom Gerät automatisch abfragen. Insbesondere sind das die Helligkeit sowie der an/aus Zustand von Lampen.
Das ganze findet dann statt wenn
- ein Gerät als Offline erkannt wurde (available = false)
- das Gerät das erste mal eine Meldung sendet (available geht auf true).
Alle Lampen melden wenn sie Strom bekommen an das Netzwerk das sie "wieder da" sind.
A.
NUKI soll ja auch ZigBee beherrschen. Gibt es schon Bestrebungen dieses Türschloss zu unterstützen?
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
NUKI soll ja auch ZigBee beherrschen. Gibt es schon Bestrebungen dieses Türschloss zu unterstützen?
@legro
Zigbee ist zwar seitens nuki angekündigt gewesen, wird aber wohl jetzt doch nicht mehr umgesetzt. Irgendwelche Hardware-Limitationen, wenn ich das richtig gelesen habe. -
@legro
Zigbee ist zwar seitens nuki angekündigt gewesen, wird aber wohl jetzt doch nicht mehr umgesetzt. Irgendwelche Hardware-Limitationen, wenn ich das richtig gelesen habe.@thomas-braun said in ZigBee neue Version 1.4.4:
@legro
Zigbee ist zwar seitens nuki angekündigt gewesen, wird aber wohl jetzt doch nicht mehr umgesetzt. ..Warten wir mal ab. Ich bin zuversichtlich, dass ich bald hier etwas tut.:slightly_smiling_face:
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
@thomas-braun said in ZigBee neue Version 1.4.4:
@legro
Zigbee ist zwar seitens nuki angekündigt gewesen, wird aber wohl jetzt doch nicht mehr umgesetzt. ..Warten wir mal ab. Ich bin zuversichtlich, dass ich bald hier etwas tut.:slightly_smiling_face:
@legro
Ich nicht:https://nuki.io/de/blog/nuki-news-de/nuki-sommer-update-2019/
Aus dem nuki developer Forum:
https://developer.nuki.io/t/zigbee-in-2-0/148/37It was mentioned already in last years blog post to the summer software 39 update that Zigbee is not doable with the current hardware in the quality that we wanted to do it. Therefore Zigbee is not supported and will - most likely - never be supported.
-
@legro
Ich nicht:https://nuki.io/de/blog/nuki-news-de/nuki-sommer-update-2019/
Aus dem nuki developer Forum:
https://developer.nuki.io/t/zigbee-in-2-0/148/37It was mentioned already in last years blog post to the summer software 39 update that Zigbee is not doable with the current hardware in the quality that we wanted to do it. Therefore Zigbee is not supported and will - most likely - never be supported.
Derzeit stehe ich in Kontakt mit NUKI. Die Signale, die ich erhalte, sind erfreulich andere.
In den nächsten Tage soll ich offizielle und verbindliche Antworten erhalten. Dann sehen wir weiter.
Was die Hardware betrifft, hast du wohl nicht ganz unrecht. Die verbaute Hardware wird wohl nur von ZigBee 3.0 unterstützt. Geräte, die 3.0 verstehen, sind jedoch kaum vorhanden. Mein Coordinator CC26X2R1 von Intel kann jedoch ZigBee 3.0.
Derzeit ist ZigBee in der Tat definitiv in den NUKI 2.0 deaktiviert.
-
@mickym sagte in ZigBee neue Version 1.4.4:
Dieser PING Button ist es wert die neue Version zu installieren - auch wenn ich ihn noch nicht über meine Node Red Flows angesprochen habe.
Bitte prüfe:
durch die Anpassungen der Geräteabfrage sollte der Adapter bei einem Gerät welches sich "Neu" wieder anmeldet den Status von verschiedenen States vom Gerät automatisch abfragen. Insbesondere sind das die Helligkeit sowie der an/aus Zustand von Lampen.
Das ganze findet dann statt wenn
- ein Gerät als Offline erkannt wurde (available = false)
- das Gerät das erste mal eine Meldung sendet (available geht auf true).
Alle Lampen melden wenn sie Strom bekommen an das Netzwerk das sie "wieder da" sind.
A.
@asgothian Habe ich geprüft.
Habe die Lampen vom Netz genommen und gewartet bis available = false. Dann wieder Strom gesetzt. Es fand dann auch automatisch eine Abfrage statt.
Die Helligkeit wurde zwar nicht angefragt (finde ich auch nicht so wichtig), aber der state und die link quality.
Hier mal die Momentaufnahme:
Dass die Gruppeneinträge nicht mit aktualisiert werden, wurde ja bereits erwähnt. Trotzdem muss ich den Sollzustand immer noch zusätzlich speichern. Diese blöden Tradfri Lampen haben einfach die unangenehme Eigenschaft, dass die bei Wiederverfügbarkeit des Stroms grundsätzlich angehen. Aber das wichtige an dieser Adapterversion ist eben, man bekommt es nun wenigstens mit, während das vorher eben nicht der Fall war. Ich stelle außerdem ja nun auch fest, dass der state nun zyklisch abgefragt wird, was ebenfalls eine wesentliche Verbesserung darstellt, da nun IST-Zustand und Zustand im Datenpunkt des iobrokers nicht mehr auseinanderlaufen.
Mit der neuen Funktion habe ich zwar nun die Möglichkeit den state zu prüfen also wenn Strom wieder da ob Lampe an oder aus - trotzdem muss ich halt den gewünschten Zustand weiter zwischenspeichern, damit wenn available von false auf true springt, ich wieder den Zustand erhalten, der bestand bevor available auf false sprang. Wahrscheinlich kommt man da aber sowieso nicht drum rum - da bei Stromausfällen im Sekundenbereich, diese sowieso nicht registriert werden.
Da ich im Moment in jedem Raum (mit den IKEA Tradfri Lampen) aber sowieso diese XIAOMI Bewegungsmelder habe - ist das nicht ganz so schlimm, da diese ja wegen der Helligkeitsmessung sowieso innerhalb von 2 Stunden mal funken und somit Abwesenheit signalisiert, was dann spätestens die Lampen ausschaltet. Es ist halt ein Unding, warum IKEA bei diesen Lampen eine Rückkehr des Stroms auf ON programmiert hat und nicht auf OFF. Dann würd ich zwar erst mal im Dunklen sitzen, was mir aber lieber wäre als zu wissen, dass irgendwelche Lampen tageweise brennen. Aber das ist ein anderes Thema.
-
Hi, sorry falls ich nerve, aber:
Soll die Gruppenfunktion unterstützt werden, oder geht das momentan nicht?@mr-x Falls ich da zur Verwirrung beigetragen habe. Die Gruppenfunktion funktioniert - allerdings wird der Status der Einzelgeräte, wenn diese über die Gruppe geschaltet wird, nicht aktualisiert. Sie funktioniert aber.
-
@mr-x Falls ich da zur Verwirrung beigetragen habe. Die Gruppenfunktion funktioniert - allerdings wird der Status der Einzelgeräte, wenn diese über die Gruppe geschaltet wird, nicht aktualisiert. Sie funktioniert aber.
-
@asgothian Habe ich geprüft.
Habe die Lampen vom Netz genommen und gewartet bis available = false. Dann wieder Strom gesetzt. Es fand dann auch automatisch eine Abfrage statt.
Die Helligkeit wurde zwar nicht angefragt (finde ich auch nicht so wichtig), aber der state und die link quality.
Hier mal die Momentaufnahme:
Dass die Gruppeneinträge nicht mit aktualisiert werden, wurde ja bereits erwähnt. Trotzdem muss ich den Sollzustand immer noch zusätzlich speichern. Diese blöden Tradfri Lampen haben einfach die unangenehme Eigenschaft, dass die bei Wiederverfügbarkeit des Stroms grundsätzlich angehen. Aber das wichtige an dieser Adapterversion ist eben, man bekommt es nun wenigstens mit, während das vorher eben nicht der Fall war. Ich stelle außerdem ja nun auch fest, dass der state nun zyklisch abgefragt wird, was ebenfalls eine wesentliche Verbesserung darstellt, da nun IST-Zustand und Zustand im Datenpunkt des iobrokers nicht mehr auseinanderlaufen.
Mit der neuen Funktion habe ich zwar nun die Möglichkeit den state zu prüfen also wenn Strom wieder da ob Lampe an oder aus - trotzdem muss ich halt den gewünschten Zustand weiter zwischenspeichern, damit wenn available von false auf true springt, ich wieder den Zustand erhalten, der bestand bevor available auf false sprang. Wahrscheinlich kommt man da aber sowieso nicht drum rum - da bei Stromausfällen im Sekundenbereich, diese sowieso nicht registriert werden.
Da ich im Moment in jedem Raum (mit den IKEA Tradfri Lampen) aber sowieso diese XIAOMI Bewegungsmelder habe - ist das nicht ganz so schlimm, da diese ja wegen der Helligkeitsmessung sowieso innerhalb von 2 Stunden mal funken und somit Abwesenheit signalisiert, was dann spätestens die Lampen ausschaltet. Es ist halt ein Unding, warum IKEA bei diesen Lampen eine Rückkehr des Stroms auf ON programmiert hat und nicht auf OFF. Dann würd ich zwar erst mal im Dunklen sitzen, was mir aber lieber wäre als zu wissen, dass irgendwelche Lampen tageweise brennen. Aber das ist ein anderes Thema.
@mickym sagte in ZigBee neue Version 1.4.4:
Es ist halt ein Unding, warum IKEA bei diesen Lampen eine Rückkehr des Stroms auf ON programmiert hat und nicht auf OFF. Dann würd ich zwar erst mal im Dunklen sitzen, was mir aber lieber wäre als zu wissen, dass irgendwelche Lampen tageweise brennen. Aber das ist ein anderes Thema.Resume last mode wäre eine gute Reaktion. Würde aber Flash Speicher mit vielen Speicherzyklen bedeuten. Das wollte man sich wohl sparen und hat deshalb beschlossen, in den "sicheren" mode zu gehen.
Du kannst ja ein- oder zweimal pro Tag die Leuchten abfragen und schauen, ob sie noch mit Deinem Speicherwert übereinstimmen und ggf. auf einer sanften Rampe abgleichen. Dann hat bei einer "Fehlschaltung" der Nutzer noch die Möglichkeit einzugreifen. -
@mickym sagte in ZigBee neue Version 1.4.4:
Es ist halt ein Unding, warum IKEA bei diesen Lampen eine Rückkehr des Stroms auf ON programmiert hat und nicht auf OFF. Dann würd ich zwar erst mal im Dunklen sitzen, was mir aber lieber wäre als zu wissen, dass irgendwelche Lampen tageweise brennen. Aber das ist ein anderes Thema.Resume last mode wäre eine gute Reaktion. Würde aber Flash Speicher mit vielen Speicherzyklen bedeuten. Das wollte man sich wohl sparen und hat deshalb beschlossen, in den "sicheren" mode zu gehen.
Du kannst ja ein- oder zweimal pro Tag die Leuchten abfragen und schauen, ob sie noch mit Deinem Speicherwert übereinstimmen und ggf. auf einer sanften Rampe abgleichen. Dann hat bei einer "Fehlschaltung" der Nutzer noch die Möglichkeit einzugreifen.@klassisch Ja das mache ich ja und die entsprechende Logik schaltet die Lampen sofort wieder aus - und wie gesagt der BWM - schaltet die Lampen dann auch noch aus.
Aber wie Du schon sagtest einen Speicher um den letzten Zustand zu speichern, gibt es bei den Lampen wohl nicht.Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@klassisch Ja das mache ich ja und die entsprechende Logik schaltet die Lampen sofort wieder aus - und wie gesagt der BWM - schaltet die Lampen dann auch noch aus.
Aber wie Du schon sagtest einen Speicher um den letzten Zustand zu speichern, gibt es bei den Lampen wohl nicht.@mickym sagte in ZigBee neue Version 1.4.4:
@klassisch Ja das mache ich ja und die entsprechende Logik schaltet die Lampen sofort wieder aus - und wie gesagt der BWM - schaltet die Lampen dann auch noch aus.
Aber wie Du schon sagtest einen Speicher um den letzten Zustand zu speichern, gibt es bei den Lampen wohl nicht.Das ist nicht notwendig. Die Funktion mit der die Anwesenheit der Lampen verifiziert wird macht das alle x Minuten automatisch. Bei Geräten die
- fest am strom hängen
- sich nicht von alleine Melden, bzw. die nicht geschaltet werden
- einen Status "on/off" besitzen
wird versucht an statt einer unspezifischen "ping" anfrage der Status des on/off states abzufragen. Wenn eine Antwort kommt wird auch der Eintrag in den Objekten angepasst.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@mickym sagte in ZigBee neue Version 1.4.4:
@klassisch Ja das mache ich ja und die entsprechende Logik schaltet die Lampen sofort wieder aus - und wie gesagt der BWM - schaltet die Lampen dann auch noch aus.
Aber wie Du schon sagtest einen Speicher um den letzten Zustand zu speichern, gibt es bei den Lampen wohl nicht.Das ist nicht notwendig. Die Funktion mit der die Anwesenheit der Lampen verifiziert wird macht das alle x Minuten automatisch. Bei Geräten die
- fest am strom hängen
- sich nicht von alleine Melden, bzw. die nicht geschaltet werden
- einen Status "on/off" besitzen
wird versucht an statt einer unspezifischen "ping" anfrage der Status des on/off states abzufragen. Wenn eine Antwort kommt wird auch der Eintrag in den Objekten angepasst.
A.
@asgothian
Versteh ich zwar nicht ganz. Ja es ist richtig, dass der state nun dem Zustand entspricht, aber ausschalten muss ich sie ja trotzdem über Logik.Wie gesagt es ist eine Riesenverbesserung, dass man nun den aktuellen Zustand in den Datenpunkten sieht, aber die Tradfri Lampen schalten sich nun mal immer ein, wenn der Strom wiederkommt - egal welchen Zustand sie vorher hatten.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@asgothian
Versteh ich zwar nicht ganz. Ja es ist richtig, dass der state nun dem Zustand entspricht, aber ausschalten muss ich sie ja trotzdem über Logik.Wie gesagt es ist eine Riesenverbesserung, dass man nun den aktuellen Zustand in den Datenpunkten sieht, aber die Tradfri Lampen schalten sich nun mal immer ein, wenn der Strom wiederkommt - egal welchen Zustand sie vorher hatten.
Support us
316
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge