NR crasht wegen Huejay timeout - warum?
-
Ich habe irgendwie seit heute Nacht das Problem dass mein Node Red alle paar Stunden crasht weil Huejay in einem Timeout läuft.
Als ich mit Huemagic in NR angefangen habe, hatte ich hue extended im IoBroker noch aktiv. In NR in allen 10 Räumen Flows für die Lichtsteuerung erstellt, die leider allesamt Schleifen waren. Da war mir klar wieso das nicht klappt. Hue extended ist aber deaktiviert und alle Flows angepasst.Angefangen hat das heute Nacht um 03:04, dann nochmal um 06:15 und grade eben kurz vor 13 Uhr nochmal. Im Iobroker Log sehe ich voher und hinterher aber nichts.
In den Meldungen kann ich jetzt aber auch nicht erkennen, an was das liegen sollte?
Das einzige was ich "vor kurzem" geändert habe, ist dass ich einen Ikea Tradfri Button hinzugefügt habe, mit dem ich Lichter in verschiedenen Räumen gleichzeitig an und aus mache. Eine Schleife ist das aber definitiv nicht, und der Knopf wurde zu dem Zeitpunkt auch nicht gedrückt. Zumal das jetzt 3 Tage her ist...Hat jemand eine Idee, wie ich rausfinden kann woran das liegt?
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Huejay
Na da kann ich auch nicht viel helfen, insbesondere nachdem der Fehler ja wohl nicht erst seit heute Nacht passiert. ;)
Das Einzige - was Du gegen ein Crash ggf. tun kannst, über all wo diese Hue-Nodes verwendest, die mit einer catch Node zu überwachen- Das löst das Problem nicht - hilft aber ggf. dass NR komplett crasht.https://github.com/Foddy/node-red-contrib-huemagic/issues/148
-
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Huejay
Na da kann ich auch nicht viel helfen, insbesondere nachdem der Fehler ja wohl nicht erst seit heute Nacht passiert. ;)
Das Einzige - was Du gegen ein Crash ggf. tun kannst, über all wo diese Hue-Nodes verwendest, die mit einer catch Node zu überwachen- Das löst das Problem nicht - hilft aber ggf. dass NR komplett crasht.https://github.com/Foddy/node-red-contrib-huemagic/issues/148
Das mit der Catch Node probiere ich mal. Im Tooltip steht die fängt Fehler von Nodes im selben Flow Tab.
D.h. den packe ich entsprechend in alle meine 17 Flows, richtig? (Ich weiß dass das eine DAU Frage ist, aber vielleicht gibts ja eine streng geheime Möglichkeit die "Global" abzufangen).Zu dem Github: Gut nachgeforscht! haha
Tatsächlich hatte ich jetzt echt ne Weile Ruhe, und dass es jetzt gleich 3 mal innerhalb von 9 Stunden passiert nachdem mind. 2 Wochen Ruhe war, macht mich dann doch etwas stutzig.Aber die Catch Nodes sind schon mal eine super Idee! Danke dafür! :)
-
Das mit der Catch Node probiere ich mal. Im Tooltip steht die fängt Fehler von Nodes im selben Flow Tab.
D.h. den packe ich entsprechend in alle meine 17 Flows, richtig? (Ich weiß dass das eine DAU Frage ist, aber vielleicht gibts ja eine streng geheime Möglichkeit die "Global" abzufangen).Zu dem Github: Gut nachgeforscht! haha
Tatsächlich hatte ich jetzt echt ne Weile Ruhe, und dass es jetzt gleich 3 mal innerhalb von 9 Stunden passiert nachdem mind. 2 Wochen Ruhe war, macht mich dann doch etwas stutzig.Aber die Catch Nodes sind schon mal eine super Idee! Danke dafür! :)
@schmetterfliege Nun erst mal ist das sogar besser das nicht global zu machen, sondern per Flow. Geht auch meines Erachtens nicht. Ausserdem willst Du ja rausfinden welche Nodes es sind. Du kannst in jeder Catch Node auch noch wählen welche Nodes überwacht werden.
Über das error-object kannst Du dann herausbekommen, welche Node oder ID den Fehler geschmissen hat und ggf. diese mal deaktivieren oder überwachen, was da rein- oder rauskommt.
Die ID kannst Du dann ja über die Info Registerkarte suchen und damit identifizieren, welche Node es ggf. im Flow war. Die Debug Node hinter der Catch Node würde ich halt so benennen, dass man diese ggf. identifizieren kann. Falls der Fehler nicht so häufig auftritt, dann hängst Du eine function Node an und gibst eine Node-Error oder Node-Warn message mit näheren Angaben mit, diese werden dann in das iobroker log geschrieben.
Schließlich soll das ja kein Dauerzustand sein. Es ist halt irgendwas mit dem irgendeine HUE Node nicht zurecht kommt und das gilt es halt ggf. zu vermeiden.
-
@schmetterfliege Nun erst mal ist das sogar besser das nicht global zu machen, sondern per Flow. Geht auch meines Erachtens nicht. Ausserdem willst Du ja rausfinden welche Nodes es sind. Du kannst in jeder Catch Node auch noch wählen welche Nodes überwacht werden.
Über das error-object kannst Du dann herausbekommen, welche Node oder ID den Fehler geschmissen hat und ggf. diese mal deaktivieren oder überwachen, was da rein- oder rauskommt.
Die ID kannst Du dann ja über die Info Registerkarte suchen und damit identifizieren, welche Node es ggf. im Flow war. Die Debug Node hinter der Catch Node würde ich halt so benennen, dass man diese ggf. identifizieren kann. Falls der Fehler nicht so häufig auftritt, dann hängst Du eine function Node an und gibst eine Node-Error oder Node-Warn message mit näheren Angaben mit, diese werden dann in das iobroker log geschrieben.
Schließlich soll das ja kein Dauerzustand sein. Es ist halt irgendwas mit dem irgendeine HUE Node nicht zurecht kommt und das gilt es halt ggf. zu vermeiden.
@mickym
Gute Idee, werde ich mal so umsetzen und dann ausnahmsweiße mal hoffen dass der Fehler auftritt, hehe.Danke dir!
-
Also, das mit der Function Node die dann im iobroker loggen soll habe ich bisher noch nicht umgesetzt.
Die Catch Node habe ich allerdings in allen 17 Flows.Dennoch ist mir NR wegen dem Fehler 3 mal innerhalb von 10 Minuten gecrasht. Zu der Zeit war keiner Zuhause, nichts wurde geschaltet und mein Rechner war aus - den Output der Debug Node sehe ich also auch nicht.
Was ich allerdings im iobroker Log sehe, ist dass NR trotz Catch Nodes gecrasht und neu gestartet ist.Nachdem der dann 3 mal gecrasht ist läuft es seit dem wieder sauber...
-
Also, das mit der Function Node die dann im iobroker loggen soll habe ich bisher noch nicht umgesetzt.
Die Catch Node habe ich allerdings in allen 17 Flows.Dennoch ist mir NR wegen dem Fehler 3 mal innerhalb von 10 Minuten gecrasht. Zu der Zeit war keiner Zuhause, nichts wurde geschaltet und mein Rechner war aus - den Output der Debug Node sehe ich also auch nicht.
Was ich allerdings im iobroker Log sehe, ist dass NR trotz Catch Nodes gecrasht und neu gestartet ist.Nachdem der dann 3 mal gecrasht ist läuft es seit dem wieder sauber...
@schmetterfliege Nun wie gesagt falls NR so abstürzt, dass sogar die catch Nodes nichts mehr abfangen können, kannst Du nur versuchen mal eine Zeitlang im iobroker log mitschreiben, was Du in die HUE Nodes schickst oder rauskommt und es ggf. vermeidest. Wenn die HUE Node allerdings einen Zustand Deiner Lampen nicht verarbeiten kann, dann hilft nur ein Fix des Node-Entwicklers.
Da Du ja mit dem iobroker arbeitest - kannst in diesem Fall ja auch ggf. auf den iobroker Adapter ausweichen - vielleicht hat der ja nicht den Fehler. Ich mach das ja auch so, wenn ein iobroker Adapter nicht funktioniert dann suche ich mir eine NOde Red Node - in diesem Fall kann man es ja mal umgekehrt versuchen. ;)
-
@mickym said in NR crasht wegen Huejay timeout - warum?:
@schmetterfliege Nun wie gesagt falls NR so abstürzt, dass sogar die catch Nodes nichts mehr abfangen können, kannst Du nur versuchen mal eine Zeitlang im iobroker log mitschreiben, was Du in die HUE Nodes schickst oder rauskommt und es ggf. vermeidest. Wenn die HUE Node allerdings einen Zustand Deiner Lampen nicht verarbeiten kann, dann hilft nur ein Fix des Node-Entwicklers.
Da Du ja mit dem iobroker arbeitest - kannst in diesem Fall ja auch ggf. auf den iobroker Adapter ausweichen - vielleicht hat der ja nicht den Fehler. Ich mach das ja auch so, wenn ein iobroker Adapter nicht funktioniert dann suche ich mir eine NOde Red Node - in diesem Fall kann man es ja mal umgekehrt versuchen. ;)
Ich befürchte fast dass es darauf hinauslaufen wird dass ich was die Lichtsteuerung angeht wieder zum IoBroker zurück muss :(
Bezüglich ins iobroker Log schreiben: Hab vorhin mal versucht mir zu überlegen wie ich das am besten anstelle, aber.. wo anfangen?
NR crasht ja zu einem Zeitpunkt, zu dem nichts gesteuert wird. Also wüsste ich nicht was ich mir ins Log schreiben soll, bzw von welcher Node aus und welche Information. Die Meldungen die im Log stehen wenn NR crasht geben ja leider keinerlei Aufschluss darüber, in welchem Flow das überhaupt passiert.Wie eingangs erwähnt konnte ich genau den Fehler easy reproduzieren indem ich massenhaft Loops erstellt und damit huejay vollgeballert habe (unabsichtlich^^).
Aber ich würde mal behaupten dass es keine Loops mehr gibt, und dass dieser Flow:
nicht random dafür sorgt dass Huejay abstürzt ohne dass der Button (Nachtlicht Katzenfutter) überhaupt betätigt wird.
Andererseits ist das der einzige Tradfri Button den ich bisher in NR benutze. Wäre ja vielleicht möglich dass der ab und zu ausrastet und seinen Status hundert Mal aktualisiert - was ja dann auch Huejay zerschießen würde weil die beiden Lampen dann hundert Mal ausgeschalten werden. Da kann ich ja einfach mal den Status den NR vom Button bekommt ins iobroker log schreiben. Dann sehe ich ja ob der das macht oder nicht.Falls ja, baue ich einfach mal eine Switch Node ein die prüft ob die Lampen an sind bevor er sie ausschaltet (oooooder: über eine Trigger Node die das Kanonenfeuer abfängt! :) ).
Und wenn das nix bringt... back to iobroker :/ -
@mickym said in NR crasht wegen Huejay timeout - warum?:
@schmetterfliege Nun wie gesagt falls NR so abstürzt, dass sogar die catch Nodes nichts mehr abfangen können, kannst Du nur versuchen mal eine Zeitlang im iobroker log mitschreiben, was Du in die HUE Nodes schickst oder rauskommt und es ggf. vermeidest. Wenn die HUE Node allerdings einen Zustand Deiner Lampen nicht verarbeiten kann, dann hilft nur ein Fix des Node-Entwicklers.
Da Du ja mit dem iobroker arbeitest - kannst in diesem Fall ja auch ggf. auf den iobroker Adapter ausweichen - vielleicht hat der ja nicht den Fehler. Ich mach das ja auch so, wenn ein iobroker Adapter nicht funktioniert dann suche ich mir eine NOde Red Node - in diesem Fall kann man es ja mal umgekehrt versuchen. ;)
Ich befürchte fast dass es darauf hinauslaufen wird dass ich was die Lichtsteuerung angeht wieder zum IoBroker zurück muss :(
Bezüglich ins iobroker Log schreiben: Hab vorhin mal versucht mir zu überlegen wie ich das am besten anstelle, aber.. wo anfangen?
NR crasht ja zu einem Zeitpunkt, zu dem nichts gesteuert wird. Also wüsste ich nicht was ich mir ins Log schreiben soll, bzw von welcher Node aus und welche Information. Die Meldungen die im Log stehen wenn NR crasht geben ja leider keinerlei Aufschluss darüber, in welchem Flow das überhaupt passiert.Wie eingangs erwähnt konnte ich genau den Fehler easy reproduzieren indem ich massenhaft Loops erstellt und damit huejay vollgeballert habe (unabsichtlich^^).
Aber ich würde mal behaupten dass es keine Loops mehr gibt, und dass dieser Flow:
nicht random dafür sorgt dass Huejay abstürzt ohne dass der Button (Nachtlicht Katzenfutter) überhaupt betätigt wird.
Andererseits ist das der einzige Tradfri Button den ich bisher in NR benutze. Wäre ja vielleicht möglich dass der ab und zu ausrastet und seinen Status hundert Mal aktualisiert - was ja dann auch Huejay zerschießen würde weil die beiden Lampen dann hundert Mal ausgeschalten werden. Da kann ich ja einfach mal den Status den NR vom Button bekommt ins iobroker log schreiben. Dann sehe ich ja ob der das macht oder nicht.Falls ja, baue ich einfach mal eine Switch Node ein die prüft ob die Lampen an sind bevor er sie ausschaltet (oooooder: über eine Trigger Node die das Kanonenfeuer abfängt! :) ).
Und wenn das nix bringt... back to iobroker :/@schmetterfliege Nun back zu iobroker - heißt ja nicht, dass nicht komplett, sondern man kann die Logik ja trotzdem weiter in NR implementieren. Das ist ja das schöne - man schreibt halt statt in die Node - dann eben in den Datenpunkt des Adapters.
nun mal paar grundsätzliche Überlegenung zu dem Flow:
-
Nun ich weiß nicht, wie Deine iobroker In Node ausschaut und durch was der Datenpunkt getriggert wird. Ist da ein Filter drin, dass nur geänderte Werte triggern.
-
Was macht der switch - was machen die blöden function Nodes - entält der 20 Flows in Codezeilen programmiert?
-
Ist Dir schon mal der Gedanke gekommen, dass mehrfach getriggert wird ?
-
Ist Dir schon mal der Gedanke gekommen, dass Deine HUE Bridge überfordert ist, wenn Du mehr oder weniger 2 Lampen gleichzeitig steuerst. Ggf. macht es Sinn die Nachrichtenrate zu begrenzen, um der HUE Bridge die Möglichkeit zu geben die Nachricht zu verarbeiten. Auch ein Konfigurationsnode , die allen HUE Nodes zugrunde liegt braucht ggf. trotz Asynchronität eine gewisse Verarbeitungszeit?
-
Vielleicht macht es auch mehr Sinn solche Dinge über eine HUE Gruppe zu steuern. - Die Einzelsteuerung dürfte ja immer noch gehen.
-
-
@schmetterfliege Nun back zu iobroker - heißt ja nicht, dass nicht komplett, sondern man kann die Logik ja trotzdem weiter in NR implementieren. Das ist ja das schöne - man schreibt halt statt in die Node - dann eben in den Datenpunkt des Adapters.
nun mal paar grundsätzliche Überlegenung zu dem Flow:
-
Nun ich weiß nicht, wie Deine iobroker In Node ausschaut und durch was der Datenpunkt getriggert wird. Ist da ein Filter drin, dass nur geänderte Werte triggern.
-
Was macht der switch - was machen die blöden function Nodes - entält der 20 Flows in Codezeilen programmiert?
-
Ist Dir schon mal der Gedanke gekommen, dass mehrfach getriggert wird ?
-
Ist Dir schon mal der Gedanke gekommen, dass Deine HUE Bridge überfordert ist, wenn Du mehr oder weniger 2 Lampen gleichzeitig steuerst. Ggf. macht es Sinn die Nachrichtenrate zu begrenzen, um der HUE Bridge die Möglichkeit zu geben die Nachricht zu verarbeiten. Auch ein Konfigurationsnode , die allen HUE Nodes zugrunde liegt braucht ggf. trotz Asynchronität eine gewisse Verarbeitungszeit?
-
Vielleicht macht es auch mehr Sinn solche Dinge über eine HUE Gruppe zu steuern. - Die Einzelsteuerung dürfte ja immer noch gehen.
@mickym said in NR crasht wegen Huejay timeout - warum?:
@schmetterfliege Nun back zu iobroker - heißt ja nicht, dass nicht komplett, sondern man kann die Logik ja trotzdem weiter in NR implementieren. Das ist ja das schöne - man schreibt halt statt in die Node - dann eben in den Datenpunkt des Adapters.
Das stimmt. Huemagic hat aber so schön farbige Nodes hahaha
Aber ja, mit "Back to Iobroker" meinte ich nicht dass ich die Steuerung selbst dann über Iobroker mache. Dann müsste ich ja auch wieder zu VIS wechseln, was definitiv nicht mein Plan ist^^nun mal paar grundsätzliche Überlegenung zu dem Flow:
- Nun ich weiß nicht, wie Deine iobroker In Node ausschaut und durch was der Datenpunkt getriggert wird. Ist da ein Filter drin, dass nur geänderte Werte triggern.
Guter Hinweis! Hatte ich vergessen und sofort umgesetzt :)
- Was macht der switch - was machen die blöden function Nodes - entält der 20 Flows in Codezeilen programmiert?
Der guckt ob der Button True oder False wiedergibt. Wenn True -> in die Function Nodes. Wenn False -> wird false an die Hue Nodes geschickt um die Lampen auszuschalten.
Die Function Nodes enthalten das hier:return {payload: {brightness: 20 } };return {payload: {colorTemp: 400 } };Und ja, das könnte man auch mit einer Function oder einer Change Node lösen :D.
- Ist Dir schon mal der Gedanke gekommen, dass mehrfach getriggert wird ?
Jep, hatte ich ja geschrieben :) Ist auch das einzige, was für mich in Frage kommen würde.
- Ist Dir schon mal der Gedanke gekommen, dass Deine HUE Bridge überfordert ist, wenn Du mehr oder weniger 2 Lampen gleichzeitig steuerst. Ggf. macht es Sinn die Nachrichtenrate zu begrenzen, um der HUE Bridge die Möglichkeit zu geben die Nachricht zu verarbeiten. Auch ein Konfigurationsnode , die allen HUE Nodes zugrunde liegt braucht ggf. trotz Asynchronität eine gewisse Verarbeitungszeit?
Naja, es sind 2 einzelne Lampen, das sollte die Bridge abkönnen. Wenn ich mein Esszimmer Licht schalte, gehen da ganze 4 Lampen an :P Die Steuerung meines Bürolichts in NR funktioniert ja auch tadellos, und da sind es 3 Lampen gleichzeitig.
Also dass es daran liegt würde ich aktuell erst mal ausschließen.
Zum jetzigen Zeitpunkt setze ich mein Pferd darauf, dass der Tradfri Button Quatsch macht - das in der IN Node abzufangen ist ja schon mal ein guter Startpunkt um es rauszufinden :) -
-
@mickym said in NR crasht wegen Huejay timeout - warum?:
@schmetterfliege Nun back zu iobroker - heißt ja nicht, dass nicht komplett, sondern man kann die Logik ja trotzdem weiter in NR implementieren. Das ist ja das schöne - man schreibt halt statt in die Node - dann eben in den Datenpunkt des Adapters.
Das stimmt. Huemagic hat aber so schön farbige Nodes hahaha
Aber ja, mit "Back to Iobroker" meinte ich nicht dass ich die Steuerung selbst dann über Iobroker mache. Dann müsste ich ja auch wieder zu VIS wechseln, was definitiv nicht mein Plan ist^^nun mal paar grundsätzliche Überlegenung zu dem Flow:
- Nun ich weiß nicht, wie Deine iobroker In Node ausschaut und durch was der Datenpunkt getriggert wird. Ist da ein Filter drin, dass nur geänderte Werte triggern.
Guter Hinweis! Hatte ich vergessen und sofort umgesetzt :)
- Was macht der switch - was machen die blöden function Nodes - entält der 20 Flows in Codezeilen programmiert?
Der guckt ob der Button True oder False wiedergibt. Wenn True -> in die Function Nodes. Wenn False -> wird false an die Hue Nodes geschickt um die Lampen auszuschalten.
Die Function Nodes enthalten das hier:return {payload: {brightness: 20 } };return {payload: {colorTemp: 400 } };Und ja, das könnte man auch mit einer Function oder einer Change Node lösen :D.
- Ist Dir schon mal der Gedanke gekommen, dass mehrfach getriggert wird ?
Jep, hatte ich ja geschrieben :) Ist auch das einzige, was für mich in Frage kommen würde.
- Ist Dir schon mal der Gedanke gekommen, dass Deine HUE Bridge überfordert ist, wenn Du mehr oder weniger 2 Lampen gleichzeitig steuerst. Ggf. macht es Sinn die Nachrichtenrate zu begrenzen, um der HUE Bridge die Möglichkeit zu geben die Nachricht zu verarbeiten. Auch ein Konfigurationsnode , die allen HUE Nodes zugrunde liegt braucht ggf. trotz Asynchronität eine gewisse Verarbeitungszeit?
Naja, es sind 2 einzelne Lampen, das sollte die Bridge abkönnen. Wenn ich mein Esszimmer Licht schalte, gehen da ganze 4 Lampen an :P Die Steuerung meines Bürolichts in NR funktioniert ja auch tadellos, und da sind es 3 Lampen gleichzeitig.
Also dass es daran liegt würde ich aktuell erst mal ausschließen.
Zum jetzigen Zeitpunkt setze ich mein Pferd darauf, dass der Tradfri Button Quatsch macht - das in der IN Node abzufangen ist ja schon mal ein guter Startpunkt um es rauszufinden :)@schmetterfliege Das was Deine Function Nodes machen ist trotzdem Käse. Das schicke ich doch nicht 2 fach - sondern in einem Objekt.
Jedenfalls sind 2 Eigenschaften mit 2 Objekten zu setzen in meinen Augen unsinnig. Eventuell ist das auch überhaupt Dein Problem, da Du nur eine Eigenschaft schickst, die HUE Node aber beide Eigenschaften erwartet.
Ich befürchte auch, dass Dein zigbee hin und wieder eine Aktualisierung schickt und das passiert auch manchmal zweimal hintereinander. Eventuell auch noch eingrenzen, dass nur bestätigte Änderungen durchkommen (ACK=true).
-
@schmetterfliege Das was Deine Function Nodes machen ist trotzdem Käse. Das schicke ich doch nicht 2 fach - sondern in einem Objekt.
Jedenfalls sind 2 Eigenschaften mit 2 Objekten zu setzen in meinen Augen unsinnig. Eventuell ist das auch überhaupt Dein Problem, da Du nur eine Eigenschaft schickst, die HUE Node aber beide Eigenschaften erwartet.
Ich befürchte auch, dass Dein zigbee hin und wieder eine Aktualisierung schickt und das passiert auch manchmal zweimal hintereinander. Eventuell auch noch eingrenzen, dass nur bestätigte Änderungen durchkommen (ACK=true).
Wie gesagt, mit der Change Node ginge das selbstverständlich auch - und du hast Recht dass das deutlich sinnvoller ist.
Werde die bei Zeiten auch entsprechend mal anpassen.Die Hue Node erwartet nicht beide Eigenschaften, sondern beliebige Eigenschaften. Farbtemperatur, Helligkeit, Farbe.
Wenn ich der nur 1 davon schicke, dann steuert sie die Lampe auch nur entsprechend damit. Der Node kann ich prinzipiell aber übergeben was ich möchte.
NR crasht ja auch nicht wenn ich die Lampen auf genau diese Weiße steuere - sondern zu Zeiten zu denen keiner sie steuert.
-> deshalb kann es meiner Meinung nach nur an den Aktualisierungen liegen.Die bestätigten Änderungen sind ebenfalls ein sehr guter Punkt! Danke! :)
-
Wie gesagt, mit der Change Node ginge das selbstverständlich auch - und du hast Recht dass das deutlich sinnvoller ist.
Werde die bei Zeiten auch entsprechend mal anpassen.Die Hue Node erwartet nicht beide Eigenschaften, sondern beliebige Eigenschaften. Farbtemperatur, Helligkeit, Farbe.
Wenn ich der nur 1 davon schicke, dann steuert sie die Lampe auch nur entsprechend damit. Der Node kann ich prinzipiell aber übergeben was ich möchte.
NR crasht ja auch nicht wenn ich die Lampen auf genau diese Weiße steuere - sondern zu Zeiten zu denen keiner sie steuert.
-> deshalb kann es meiner Meinung nach nur an den Aktualisierungen liegen.Die bestätigten Änderungen sind ebenfalls ein sehr guter Punkt! Danke! :)
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Die Hue Node erwartet nicht beide Eigenschaften, sondern beliebige Eigenschaften. Farbtemperatur, Helligkeit, Farbe.
Wenn ich der nur 1 davon schicke, dann steuert sie die Lampe auch nur entsprechend damit. Der Node kann ich prinzipiell aber übergeben was ich möchte.Das ist schon richtig - ich habe mir ja die Beschreibung der Node angeschaut. Aber wenn Du schon beide Eigenschaften setzt (was Du mit beiden Function Nodes ja tust) - dann doch lieber aufeinmal, als 2 mal - das macht so keinen Sinn und ist nur unökonomisch. ;)
Ausserdem musst Du darauf achten, dass Du über die function Nodes ja den extendend Mode nutzt, beim Ausschalten wahrscheinlich nur den Boolean:
Das heißt vielleicht solltest Du im Extenden Mode - dann On auch als true mitschicken.
-
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Die Hue Node erwartet nicht beide Eigenschaften, sondern beliebige Eigenschaften. Farbtemperatur, Helligkeit, Farbe.
Wenn ich der nur 1 davon schicke, dann steuert sie die Lampe auch nur entsprechend damit. Der Node kann ich prinzipiell aber übergeben was ich möchte.Das ist schon richtig - ich habe mir ja die Beschreibung der Node angeschaut. Aber wenn Du schon beide Eigenschaften setzt (was Du mit beiden Function Nodes ja tust) - dann doch lieber aufeinmal, als 2 mal - das macht so keinen Sinn und ist nur unökonomisch. ;)
Ausserdem musst Du darauf achten, dass Du über die function Nodes ja den extendend Mode nutzt, beim Ausschalten wahrscheinlich nur den Boolean:
Das heißt vielleicht solltest Du im Extenden Mode - dann On auch als true mitschicken.
Wenn ich die Brightness verändere, schaltet der die Lampe automatisch ein.
So steuere ich alle meine Lichter^^Da fände ich es eher unnötig der Lampe zu sagen sie soll auf Helligkeit 20% gehen, und ihr dann noch zu sagen dass sie auch angehen soll - so intelligent sind die Birnen schon :D.
-
@mickym said in NR crasht wegen Huejay timeout - warum?:
@schmetterfliege Nun back zu iobroker - heißt ja nicht, dass nicht komplett, sondern man kann die Logik ja trotzdem weiter in NR implementieren. Das ist ja das schöne - man schreibt halt statt in die Node - dann eben in den Datenpunkt des Adapters.
Das stimmt. Huemagic hat aber so schön farbige Nodes hahaha
Aber ja, mit "Back to Iobroker" meinte ich nicht dass ich die Steuerung selbst dann über Iobroker mache. Dann müsste ich ja auch wieder zu VIS wechseln, was definitiv nicht mein Plan ist^^nun mal paar grundsätzliche Überlegenung zu dem Flow:
- Nun ich weiß nicht, wie Deine iobroker In Node ausschaut und durch was der Datenpunkt getriggert wird. Ist da ein Filter drin, dass nur geänderte Werte triggern.
Guter Hinweis! Hatte ich vergessen und sofort umgesetzt :)
- Was macht der switch - was machen die blöden function Nodes - entält der 20 Flows in Codezeilen programmiert?
Der guckt ob der Button True oder False wiedergibt. Wenn True -> in die Function Nodes. Wenn False -> wird false an die Hue Nodes geschickt um die Lampen auszuschalten.
Die Function Nodes enthalten das hier:return {payload: {brightness: 20 } };return {payload: {colorTemp: 400 } };Und ja, das könnte man auch mit einer Function oder einer Change Node lösen :D.
- Ist Dir schon mal der Gedanke gekommen, dass mehrfach getriggert wird ?
Jep, hatte ich ja geschrieben :) Ist auch das einzige, was für mich in Frage kommen würde.
- Ist Dir schon mal der Gedanke gekommen, dass Deine HUE Bridge überfordert ist, wenn Du mehr oder weniger 2 Lampen gleichzeitig steuerst. Ggf. macht es Sinn die Nachrichtenrate zu begrenzen, um der HUE Bridge die Möglichkeit zu geben die Nachricht zu verarbeiten. Auch ein Konfigurationsnode , die allen HUE Nodes zugrunde liegt braucht ggf. trotz Asynchronität eine gewisse Verarbeitungszeit?
Naja, es sind 2 einzelne Lampen, das sollte die Bridge abkönnen. Wenn ich mein Esszimmer Licht schalte, gehen da ganze 4 Lampen an :P Die Steuerung meines Bürolichts in NR funktioniert ja auch tadellos, und da sind es 3 Lampen gleichzeitig.
Also dass es daran liegt würde ich aktuell erst mal ausschließen.
Zum jetzigen Zeitpunkt setze ich mein Pferd darauf, dass der Tradfri Button Quatsch macht - das in der IN Node abzufangen ist ja schon mal ein guter Startpunkt um es rauszufinden :)@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Und ja, das könnte man auch mit einer Function oder einer Change Node lösen :D.
Ich habe selbst im NR Forum gesehen, dass die meisten lieber function Nodes nutzen - anstelle von Nodes. Verstehen tue ich es halt nicht.
-
Wenn ich die Brightness verändere, schaltet der die Lampe automatisch ein.
So steuere ich alle meine Lichter^^Da fände ich es eher unnötig der Lampe zu sagen sie soll auf Helligkeit 20% gehen, und ihr dann noch zu sagen dass sie auch angehen soll - so intelligent sind die Birnen schon :D.
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Wenn ich die Brightness verändere, schaltet der die Lampe automatisch ein.
So steuere ich alle meine Lichter^^Da fände ich es eher unnötig der Lampe zu sagen sie soll auf Helligkeit 20% gehen, und ihr dann noch zu sagen dass sie auch angehen soll - so intelligent sind die Birnen schon :D.
Ok - aber colorTemp gibst ja auch mit - wie gesagt - alles in einem Objekt schicken macht jedenfalls mehr Sinn. Deswegen arbeitet man ja mit Objekten, damit nicht alles einzeln verarbeitet werden muss.
-
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Wenn ich die Brightness verändere, schaltet der die Lampe automatisch ein.
So steuere ich alle meine Lichter^^Da fände ich es eher unnötig der Lampe zu sagen sie soll auf Helligkeit 20% gehen, und ihr dann noch zu sagen dass sie auch angehen soll - so intelligent sind die Birnen schon :D.
Ok - aber colorTemp gibst ja auch mit - wie gesagt - alles in einem Objekt schicken macht jedenfalls mehr Sinn. Deswegen arbeitet man ja mit Objekten, damit nicht alles einzeln verarbeitet werden muss.
@mickym said in NR crasht wegen Huejay timeout - warum?:
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Wenn ich die Brightness verändere, schaltet der die Lampe automatisch ein.
So steuere ich alle meine Lichter^^Da fände ich es eher unnötig der Lampe zu sagen sie soll auf Helligkeit 20% gehen, und ihr dann noch zu sagen dass sie auch angehen soll - so intelligent sind die Birnen schon :D.
Ok - aber colorTemp gibst ja auch mit - wie gesagt - alles in einem Objekt schicken macht jedenfalls mehr Sinn. Deswegen arbeitet man ja mit Objekten, damit nicht alles einzeln verarbeitet werden muss.
Die Function Nodes sind noch "Relikte" aus der Zeit als ich mit NR angefangen habe (2 Monate?) und bevor du mir die ganzen Tricks, Tipps und Kniffe gezeigt hast.
Ich hatte bloß noch nicht die Muse alles zu überarbeiten/verbessern.
Die beiden Functions in diesem Beispiel werde ich definitiv mit einer Change Node ersetzen. Allein schon weil das Board sonst irgendwann vor lauter Nodes zum Urwald wird :D -
@mickym said in NR crasht wegen Huejay timeout - warum?:
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Wenn ich die Brightness verändere, schaltet der die Lampe automatisch ein.
So steuere ich alle meine Lichter^^Da fände ich es eher unnötig der Lampe zu sagen sie soll auf Helligkeit 20% gehen, und ihr dann noch zu sagen dass sie auch angehen soll - so intelligent sind die Birnen schon :D.
Ok - aber colorTemp gibst ja auch mit - wie gesagt - alles in einem Objekt schicken macht jedenfalls mehr Sinn. Deswegen arbeitet man ja mit Objekten, damit nicht alles einzeln verarbeitet werden muss.
Die Function Nodes sind noch "Relikte" aus der Zeit als ich mit NR angefangen habe (2 Monate?) und bevor du mir die ganzen Tricks, Tipps und Kniffe gezeigt hast.
Ich hatte bloß noch nicht die Muse alles zu überarbeiten/verbessern.
Die beiden Functions in diesem Beispiel werde ich definitiv mit einer Change Node ersetzen. Allein schon weil das Board sonst irgendwann vor lauter Nodes zum Urwald wird :D@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Die Function Nodes sind noch "Relikte" aus der Zeit als ich mit NR angefangen habe (2 Monate?) und bevor du mir die ganzen Tricks, Tipps und Kniffe gezeigt hast.
Ich hatte bloß noch nicht die Muse alles zu überarbeiten/verbessern.
Die beiden Functions in diesem Beispiel werde ich definitiv mit einer Change Node ersetzen. Allein schon weil das Board sonst irgendwann vor lauter Nodes zum Urwald wirdNa 2 Monate - dann ist das alles OK. Ich habe auch viel gelernt und lerne noch dazu. Ich habe allerdings sofort und nur mit NodeRed unter dem iobroker gearbeitet. Blockly kam nie in Frage. Mit 2 Monaten stehst Du ungefähr da, wo ich vor 2 Jahren stand. Insofern gibts ja auch noch einiges für Dich zu entdecken und begreifen. Insbesondere wenn man tiefer einsteigt ist diese Produkt echt genial und verstehe es bis heute nicht, wie die IBM so etwas dann quasi kostenlos der Open Source Community überlassen hat.
-
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Die Function Nodes sind noch "Relikte" aus der Zeit als ich mit NR angefangen habe (2 Monate?) und bevor du mir die ganzen Tricks, Tipps und Kniffe gezeigt hast.
Ich hatte bloß noch nicht die Muse alles zu überarbeiten/verbessern.
Die beiden Functions in diesem Beispiel werde ich definitiv mit einer Change Node ersetzen. Allein schon weil das Board sonst irgendwann vor lauter Nodes zum Urwald wirdNa 2 Monate - dann ist das alles OK. Ich habe auch viel gelernt und lerne noch dazu. Ich habe allerdings sofort und nur mit NodeRed unter dem iobroker gearbeitet. Blockly kam nie in Frage. Mit 2 Monaten stehst Du ungefähr da, wo ich vor 2 Jahren stand. Insofern gibts ja auch noch einiges für Dich zu entdecken und begreifen. Insbesondere wenn man tiefer einsteigt ist diese Produkt echt genial und verstehe es bis heute nicht, wie die IBM so etwas dann quasi kostenlos der Open Source Community überlassen hat.
@mickym said in NR crasht wegen Huejay timeout - warum?:
@schmetterfliege sagte in NR crasht wegen Huejay timeout - warum?:
Die Function Nodes sind noch "Relikte" aus der Zeit als ich mit NR angefangen habe (2 Monate?) und bevor du mir die ganzen Tricks, Tipps und Kniffe gezeigt hast.
Ich hatte bloß noch nicht die Muse alles zu überarbeiten/verbessern.
Die beiden Functions in diesem Beispiel werde ich definitiv mit einer Change Node ersetzen. Allein schon weil das Board sonst irgendwann vor lauter Nodes zum Urwald wirdNa 2 Monate - dann ist das alles OK. Ich habe auch viel gelernt und lerne noch dazu. Ich habe allerdings sofort und nur mit NodeRed unter dem iobroker gearbeitet. Blockly kam nie in Frage. Mit 2 Monaten stehst Du ungefähr da, wo ich vor 2 Jahren stand. Insofern gibts ja auch noch einiges für Dich zu entdecken und begreifen. Insbesondere wenn man tiefer einsteigt ist diese Produkt echt genial und verstehe es bis heute nicht, wie die IBM so etwas dann quasi kostenlos der Open Source Community überlassen hat.
Das ist von IBM? Boa sind die doof :D.
Mit NR hatte ich mich anfangs gar nicht beschäftigt, weil ich unsinnigerweiße dachte das wäre quasi ein "Konkurrent" bzw. eine Alternative zu IoBroker. Erst als mir klar war, dass man die beiden Systeme ja wunderbar vereinen kann, hab ich angefangen mal reinzuschauen - und mich sofort verliebt.
VIS und Blockly waren nicht doof, aber... alleine das Verbinden der Nodes... ich glaube ich könnte den ganzen Tag einfach nur Nodes miteinander verbinden weil das so geil ist :D. -
Ach menno :(
Wäre ich mal 2 Stunden länger wach geblieben...
-
Ach menno :(
Wäre ich mal 2 Stunden länger wach geblieben...
@schmetterfliege Deaktiviere halt die iobroker In Node mit dem Tradfri Button und schau mal, ob damit dieser Fehler wieder dauerhaft verschwindet und dann hab ich Dir ja ein paar Tipps gegeben, wie Du den Flow noch optimieren kannst.
Als nächstes wäre ja dann mal ein Logeintrag zu schreiben, wenn die Tradfri Datenpunkte was ausspuken und ob das zeitlich mit den Abstürzen in einen zeitlichen Zusammenhang zu bringen sind.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden375
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge