NEWS
shelly Status zur Fallunterscheidung nutzen
-
@rudi-3 Na - ich finde den Flow alles andere als übersichtlich und ich frage mich immer, warum man als Neuling - gerade wenn man von Javascript-Programmierung noch nicht viel Ahnung hat, hier alles mit function Node macht, damit machst Du Dir doch eine Menge von der grafischen Darstellung des Ablaufs kaputt.
Den Flow kann man auch schlecht nachvollziehen, da man viele Deiner Nodes nicht hat und deswegen nicht nachvollziehen kann.
Wenn Du alles willst, dass man das nachvollzieht, dann mach ein Debug Fenster an die shelly-gen1 Node dran und poste das gesamte Datenobjekt in code-tags hier in den Thread, dann kann man das mit einer Inject Node simulieren.
So nachdem man dann versucht hat aus Deinem Code original daten zu schließen und die unbekannten Nodes eliminiert hat, sieht das so aus:
So nun kann man mal grundsätzlich optimieren, wobei ICH diese function Nodes größtenteils überflüssig finde und auch Du Dir angewöhnen solltest, diese wenn möglich zu vermeiden.
Weiter Optimierungen folgen in den nächsten Postings.
Hallo Micky,
hier der Auszug vom Shelly:
Ich möchte den Status bei "ison..." nutzen. Ich habe diverse Versuche gemacht, aber ich hänge immer daran, das der Status nicht richtig in der function node ankommt. In der Tat war der flow mal übersichtlicher, ist allerdings durch die vielen versuche inzwischen ziemlich zerpflückt...
-
Dann fangen wir mal oben an.
Die function Nodes sind schon mal VÖLLIG überflüssig und machen das ganze intransparent.
Dann reißt du das Objekt auseinander, um es dann mit einer JOIN Node wieder zusammenzufügen.Beschäftige Dich lieber mit JSONATA - das ist eine eingebaute geniale Bibliothek, bevor Du mit JS Code rumhantierst. Calculator Node und solche Dinge BRAUCHT MAN NICHT - das macht man mit Boardmitteln. ;)
So hier mal der obere Teil in schön.
Und hier zum Import:
Die beiden Change Nodes kannst Du natürlich in EINE Change Node mit 2 Regeln zusammenfassen.
-
Hallo Micky,
hier der Auszug vom Shelly:
Ich möchte den Status bei "ison..." nutzen. Ich habe diverse Versuche gemacht, aber ich hänge immer daran, das der Status nicht richtig in der function node ankommt. In der Tat war der flow mal übersichtlicher, ist allerdings durch die vielen versuche inzwischen ziemlich zerpflückt...
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
Hallo Micky,
hier der Auszug vom Shelly:
Ich möchte den Status bei "ison..." nutzen. Ich habe diverse Versuche gemacht, aber ich hänge immer daran, das der Status nicht richtig in der function node ankommt. In der Tat war der flow mal übersichtlicher, ist allerdings durch die vielen versuche inzwischen ziemlich zerpflückt...
das bringt nichts - damit man es in eine Inject Node bringt musst Du den Wert aus dem Debug Fenster kopieren und hier in Code Tags einfügen.
Sprich Du gehst im Debug Fenster auf die oberste Ebene der payload und kopierst das ganze Objekt in die Zwischenablage:
Dann fügst Du es hier in Code tags ein:
{"emeters":[{"power":100},{"power":200},{"power":1300}]}Damit kann ich das über Select all in die Zwischenablage kopieren und in eine Inject Node transportieren, dann kann ich damit was anfangen. - Aber ich hab ja die Objekte oben zumindest emuliert (was ich aus Deinen function Nodes entnehmen konnte) und selbst ein Objekt erstellt.
-
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
Hallo Micky,
hier der Auszug vom Shelly:
Ich möchte den Status bei "ison..." nutzen. Ich habe diverse Versuche gemacht, aber ich hänge immer daran, das der Status nicht richtig in der function node ankommt. In der Tat war der flow mal übersichtlicher, ist allerdings durch die vielen versuche inzwischen ziemlich zerpflückt...
das bringt nichts - damit man es in eine Inject Node bringt musst Du den Wert aus dem Debug Fenster kopieren und hier in Code Tags einfügen.
Sprich Du gehst im Debug Fenster auf die oberste Ebene der payload und kopierst das ganze Objekt in die Zwischenablage:
Dann fügst Du es hier in Code tags ein:
{"emeters":[{"power":100},{"power":200},{"power":1300}]}Damit kann ich das über Select all in die Zwischenablage kopieren und in eine Inject Node transportieren, dann kann ich damit was anfangen. - Aber ich hab ja die Objekte oben zumindest emuliert (was ich aus Deinen function Nodes entnehmen konnte) und selbst ein Objekt erstellt.
Hier nochmal in Code-tags:
{"status":{"wifi_sta":{"connected":true,"ssid":"Kellerfritz","ip":"192.168.2.196","rssi":-46},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"15:16","serial":1,"has_update":true,"mac":"10521C06EE47","relays":[{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true},{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true}],"rollers":[{"state":"stop","power":0,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"stop","current_pos":101,"calibrating":false,"positioning":true}],"meters":[{"power":0,"is_valid":true,"timestamp":1689347786,"counters":[0,0,0],"total":0},{"power":0,"is_valid":true,"timestamp":1689347786,"counters":[0,0,0],"total":0}],"inputs":[{"input":0},{"input":0}],"temperature":56.18,"overtemperature":false,"tmp":{"tC":56.18,"tF":133.12,"is_valid":"true"},"update":{"status":"pending","has_update":true,"new_version":"20230503-095750/v1.13.0-g9aed950","old_version":"20191217-074901/1047-long-id-for-shelly-devices@ab2bdce7"},"ram_total":49480,"ram_free":37016,"fs_size":233681,"fs_free":157628,"voltage":235.06,"uptime":6684},"payload":{"relays":[{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true},{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true}],"rollers":[{"state":"stop","power":0,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"stop","current_pos":101,"calibrating":false,"positioning":true}],"meters":[{"power":0,"is_valid":true,"timestamp":1689347786,"counters":[0,0,0],"total":0},{"power":0,"is_valid":true,"timestamp":1689347786,"counters":[0,0,0],"total":0}],"inputs":[{"input":0},{"input":0}],"tmp":{"tC":56.18,"tF":133.12,"is_valid":"true"}},"_msgid":"9bd7710f1fddad89"} -
Hier nochmal in Code-tags:
{"status":{"wifi_sta":{"connected":true,"ssid":"Kellerfritz","ip":"192.168.2.196","rssi":-46},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"15:16","serial":1,"has_update":true,"mac":"10521C06EE47","relays":[{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true},{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true}],"rollers":[{"state":"stop","power":0,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"stop","current_pos":101,"calibrating":false,"positioning":true}],"meters":[{"power":0,"is_valid":true,"timestamp":1689347786,"counters":[0,0,0],"total":0},{"power":0,"is_valid":true,"timestamp":1689347786,"counters":[0,0,0],"total":0}],"inputs":[{"input":0},{"input":0}],"temperature":56.18,"overtemperature":false,"tmp":{"tC":56.18,"tF":133.12,"is_valid":"true"},"update":{"status":"pending","has_update":true,"new_version":"20230503-095750/v1.13.0-g9aed950","old_version":"20191217-074901/1047-long-id-for-shelly-devices@ab2bdce7"},"ram_total":49480,"ram_free":37016,"fs_size":233681,"fs_free":157628,"voltage":235.06,"uptime":6684},"payload":{"relays":[{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true},{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true}],"rollers":[{"state":"stop","power":0,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"stop","current_pos":101,"calibrating":false,"positioning":true}],"meters":[{"power":0,"is_valid":true,"timestamp":1689347786,"counters":[0,0,0],"total":0},{"power":0,"is_valid":true,"timestamp":1689347786,"counters":[0,0,0],"total":0}],"inputs":[{"input":0},{"input":0}],"tmp":{"tC":56.18,"tF":133.12,"is_valid":"true"}},"_msgid":"9bd7710f1fddad89"}@rudi-3 Ok danke in Deiner function Node stand irgendwas von emeters - nun sind es aber nur meters - das deckt sich also NICHT.
Musst Du dann halt ändern - aber das Prinzip für den oberen Flow solltest Du ja verstanden haben.
-
@rudi-3 Ok danke in Deiner function Node stand irgendwas von emeters - nun sind es aber nur meters - das deckt sich also NICHT.
Musst Du dann halt ändern - aber das Prinzip für den oberen Flow solltest Du ja verstanden haben.
Hallo Micky, ich habe es gerade mal nachvollzogen und statt dem inject node das shelly 3EM angehängt. -funktioniert. Soweit ich es verstanden habe, setzt Du die payload mit: payload.emeters.power und das bringt dann alle drei Phasen in ein array? Dein Aufbau ist in der Tat wesentlich kompakter...
-
Hallo Micky, ich habe es gerade mal nachvollzogen und statt dem inject node das shelly 3EM angehängt. -funktioniert. Soweit ich es verstanden habe, setzt Du die payload mit: payload.emeters.power und das bringt dann alle drei Phasen in ein array? Dein Aufbau ist in der Tat wesentlich kompakter...
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
Soweit ich es verstanden habe, setzt Du die payload mit: payload.emeters.power und das bringt dann alle drei Phasen in ein array?
Ja - das ist der Riesenvorteil von JSONATA - da es einzelne Ergebnisse einzeln darstellt - mehrfache automatisch in ein Array verfrachtet.
Das ganze geht dann noch kompakter wenn Du das als EINE Regel definierst in EINER Change Node machst:
Damit ist alles direkt abgefrühstückt und kannst in deinem Gauge ausgeben.
In Summe schaut dass dann so aus:
und das ohne irgendwelche Zusatznodes und Spirenzchen. ;)
Hier nochmal zum Import: -
Als erstes nehme ich mal diese 3. Ausgabe aus - das soll wohl eine Anzeige sein, die ist aber nicht definiert und gesetzt:
Ich geh mal davon aus, dass es LED2 heißen soll. Und hab die Ausgabe mal so geändert:
return [msg.payload2,LED1,LED2];Ansonsten kann ich Deinen Fehler nachvollziehen:
So UND nun komme ich zu dem Punkt - warum DU function Nodes VERMEIDEN sollst, wo es geht. Du kannst keine Debug NOdes ansetzen und musst nun im Code suchen. Schöner wäre es doch in einem Flow zu suchen. Wir sollten - ABER NUR WENN DU Lust hast - im letzten Schritt Deine function Node durch einen schönen Flow ersetzen, was meinst Du?
Aber als erstes suchen wir wo der Fehler auftritt.
-
Als erstes nehme ich mal diese 3. Ausgabe aus - das soll wohl eine Anzeige sein, die ist aber nicht definiert und gesetzt:
Ich geh mal davon aus, dass es LED2 heißen soll. Und hab die Ausgabe mal so geändert:
return [msg.payload2,LED1,LED2];Ansonsten kann ich Deinen Fehler nachvollziehen:
So UND nun komme ich zu dem Punkt - warum DU function Nodes VERMEIDEN sollst, wo es geht. Du kannst keine Debug NOdes ansetzen und musst nun im Code suchen. Schöner wäre es doch in einem Flow zu suchen. Wir sollten - ABER NUR WENN DU Lust hast - im letzten Schritt Deine function Node durch einen schönen Flow ersetzen, was meinst Du?
Aber als erstes suchen wir wo der Fehler auftritt.
Stimmt, die Variable "statusrel0" war ein Debug-Versuch von mir, die hatte ich anstelle einer LED genutzt. Mir wäre es auch sehr lieb, wenn ich die Fallunterscheidungen ohne Programmcode machen könnte, schliesslich war es genau das was ich an Node-Red so gut finde. Die function node war dann eher ein Behelf, da ich keine Idee hat die Unterscheidung mit nodes zu machen. Man fällt irgendwie in die Programmierübungen aus der Schulzeit zurück ;-)
-
Stimmt, die Variable "statusrel0" war ein Debug-Versuch von mir, die hatte ich anstelle einer LED genutzt. Mir wäre es auch sehr lieb, wenn ich die Fallunterscheidungen ohne Programmcode machen könnte, schliesslich war es genau das was ich an Node-Red so gut finde. Die function node war dann eher ein Behelf, da ich keine Idee hat die Unterscheidung mit nodes zu machen. Man fällt irgendwie in die Programmierübungen aus der Schulzeit zurück ;-)
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
Stimmt, die Variable "statusrel0" war ein Debug-Versuch von mir, die hatte ich anstelle einer LED genutzt. Mir wäre es auch sehr lieb, wenn ich die Fallunterscheidungen ohne Programmcode machen könnte, schliesslich war es genau das was ich an Node-Red so gut finde. Die function node war dann eher ein Behelf, da ich keine Idee hat die Unterscheidung mit nodes zu machen. Man fällt irgendwie in die Programmierübungen aus der Schulzeit zurück ;-)
Na wenn das so ist, dann stecke ich in die function Node keine Energie mehr rein - wollen wir den unteren Teil dann gleich neu machen?
-
Als erstes nehme ich mal diese 3. Ausgabe aus - das soll wohl eine Anzeige sein, die ist aber nicht definiert und gesetzt:
Ich geh mal davon aus, dass es LED2 heißen soll. Und hab die Ausgabe mal so geändert:
return [msg.payload2,LED1,LED2];Ansonsten kann ich Deinen Fehler nachvollziehen:
So UND nun komme ich zu dem Punkt - warum DU function Nodes VERMEIDEN sollst, wo es geht. Du kannst keine Debug NOdes ansetzen und musst nun im Code suchen. Schöner wäre es doch in einem Flow zu suchen. Wir sollten - ABER NUR WENN DU Lust hast - im letzten Schritt Deine function Node durch einen schönen Flow ersetzen, was meinst Du?
Aber als erstes suchen wir wo der Fehler auftritt.
Eine Verständnisfrage zwischendurch. Ich habe testweise nach Deinem Vorbild eine change-node genommen um aus der Payload vom shelly-relays einen Teil zu extrahieren. Dabei kam aber wieder das ganze Nachrichtenobjekt raus. Warum ist das so?
-
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
Stimmt, die Variable "statusrel0" war ein Debug-Versuch von mir, die hatte ich anstelle einer LED genutzt. Mir wäre es auch sehr lieb, wenn ich die Fallunterscheidungen ohne Programmcode machen könnte, schliesslich war es genau das was ich an Node-Red so gut finde. Die function node war dann eher ein Behelf, da ich keine Idee hat die Unterscheidung mit nodes zu machen. Man fällt irgendwie in die Programmierübungen aus der Schulzeit zurück ;-)
Na wenn das so ist, dann stecke ich in die function Node keine Energie mehr rein - wollen wir den unteren Teil dann gleich neu machen?
-
Eine Verständnisfrage zwischendurch. Ich habe testweise nach Deinem Vorbild eine change-node genommen um aus der Payload vom shelly-relays einen Teil zu extrahieren. Dabei kam aber wieder das ganze Nachrichtenobjekt raus. Warum ist das so?
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
Eine Verständnisfrage zwischendurch. Ich habe testweise nach Deinem Vorbild eine change-node genommen um aus der Payload vom shelly-relays einen Teil zu extrahieren. Dabei kam aber wieder das ganze Nachrichtenobjekt raus. Warum ist das so?
Vielleicht ein Syntax- Leerzeichen oder irgendwas - was ich so auch nicht sehe. Oder nicht ÜBERNEHMEN geklickt. ;) Keine Ahnung. Bei mir funktioniert es:
Hier der Import:
-
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
Eine Verständnisfrage zwischendurch. Ich habe testweise nach Deinem Vorbild eine change-node genommen um aus der Payload vom shelly-relays einen Teil zu extrahieren. Dabei kam aber wieder das ganze Nachrichtenobjekt raus. Warum ist das so?
Vielleicht ein Syntax- Leerzeichen oder irgendwas - was ich so auch nicht sehe. Oder nicht ÜBERNEHMEN geklickt. ;) Keine Ahnung. Bei mir funktioniert es:
Hier der Import:
-
So ich kann Deinen Fehler nachvollziehen - hatte dann aber nur die Blocks etwas auseinandergezogen und da war der Fehler komischerweise kurz weg.
Also um es kurz zu machen, was definitiv falsch ist, sind Deine Ausgaben. Keine dieser 3 variablen sind definiert.
Alles was innerhalb von geschweiften Klammern definiert wird, hat auch nur Gültigkeit innerhalb dieser geschweiften Klammern. Und msg.payload2 ist ein Objekt das gar nicht definiert ist. Wenn Du das alles zum Schluss ausgeben willst, dann musst Du auch alles am Anfang definieren.
-
So ich kann Deinen Fehler nachvollziehen - hatte dann aber nur die Blocks etwas auseinandergezogen und da war der Fehler komischerweise kurz weg.
Also um es kurz zu machen, was definitiv falsch ist, sind Deine Ausgaben. Keine dieser 3 variablen sind definiert.
Alles was innerhalb von geschweiften Klammern definiert wird, hat auch nur Gültigkeit innerhalb dieser geschweiften Klammern. Und msg.payload2 ist ein Objekt das gar nicht definiert ist. Wenn Du das alles zum Schluss ausgeben willst, dann musst Du auch alles am Anfang definieren.
-
Ich hätte also die Ausgaben direkt in die IF-Blöcke packen müssen / können? Heute habe ich eine steile Lernkurve ;-)
@rudi-3 Nein die Variablen LED1 und LED2 vor den IF Abfragen definieren.
Dann machst Du Vergleiche - obwohl Dein Kontext gar nicht initialisiert ist, wenn Du das Dashboard nicht vorher betätigt hast:
Prüfe also zu jeder Zeit - Deine Kontextdaten und initialisiere die Werte auch bevor Du irgendwas im Dashboard gesetzt hast.
-
Desweiteren wenn Du schon function NOde nimmst, dann musst Du darauf achten, dass Du alle Fälle berücksichtigst:
Mit so vielen unterschiedlichen Parametern, ein, aus, und Summe sind da glaub 12 Fälle. Was machst Du denn wenn summe < ein ist - dann passiert gar nichts.
Mit node.warn kannst Du überprüfen, ob was gesetzt ist.
Du siehst es ist alles undefined - ja wenn kein Fall eintritt - ist es empty weil wir gesetzt haben oder undefined.
Auch so was ist Käse:
- Definierst Du ein Objekt im luftleeren Raum - wenn das ausgegeben werden soll, dann musst Du ein msg Objekt definieren.
Dein Objekt kommt nie und nimmer an.
- Du musst doch IMMER - wenn Du alles AUSGIBST auch alle Ausgaben definieren oder Du setzt diese auf null. Korrigiere ich noch. Aber Du musst auch den 2. Ausgang definieren - entweder für alles oder in jedem Ast.
- Definierst Du ein Objekt im luftleeren Raum - wenn das ausgegeben werden soll, dann musst Du ein msg Objekt definieren.
-
Desweiteren wenn Du schon function NOde nimmst, dann musst Du darauf achten, dass Du alle Fälle berücksichtigst:
Mit so vielen unterschiedlichen Parametern, ein, aus, und Summe sind da glaub 12 Fälle. Was machst Du denn wenn summe < ein ist - dann passiert gar nichts.
Mit node.warn kannst Du überprüfen, ob was gesetzt ist.
Du siehst es ist alles undefined - ja wenn kein Fall eintritt - ist es empty weil wir gesetzt haben oder undefined.
Auch so was ist Käse:
- Definierst Du ein Objekt im luftleeren Raum - wenn das ausgegeben werden soll, dann musst Du ein msg Objekt definieren.
Dein Objekt kommt nie und nimmer an.
- Du musst doch IMMER - wenn Du alles AUSGIBST auch alle Ausgaben definieren oder Du setzt diese auf null. Korrigiere ich noch. Aber Du musst auch den 2. Ausgang definieren - entweder für alles oder in jedem Ast.
Node warn kannte ich noch nicht. Nützliches Ding. Bezüglich der Fälle kommen in der Praxis nicht so viele vor. Wichtig ist mir, das ich die Relais gestuft schalten kann. Etwas tricky ist, das sich der PV-Überschuss in dem Moment kleiner wird, in dem man den Heizstab zuschalten. Ich muss also später noch eine Hystere dazunehmen, sonst schwingt das ganze Werk wild.
- Definierst Du ein Objekt im luftleeren Raum - wenn das ausgegeben werden soll, dann musst Du ein msg Objekt definieren.
-
Node warn kannte ich noch nicht. Nützliches Ding. Bezüglich der Fälle kommen in der Praxis nicht so viele vor. Wichtig ist mir, das ich die Relais gestuft schalten kann. Etwas tricky ist, das sich der PV-Überschuss in dem Moment kleiner wird, in dem man den Heizstab zuschalten. Ich muss also später noch eine Hystere dazunehmen, sonst schwingt das ganze Werk wild.
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
Node warn kannte ich noch nicht. Nützliches Ding. Bezüglich der Fälle kommen in der Praxis nicht so viele vor. Wichtig ist mir, das ich die Relais gestuft schalten kann. Etwas tricky ist, das sich der PV-Überschuss in dem Moment kleiner wird, in dem man den Heizstab zuschalten. Ich muss also später noch eine Hystere dazunehmen, sonst schwingt das ganze Werk wild.
Gut - also eigentlich will ich nun nicht die ganze function Node umschreiben - es gäbe noch 1000 Dinge zu sagen - wollen wir ohne weiter machen?
Support us
813
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge