NEWS
shelly Status zur Fallunterscheidung nutzen
-
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?
-
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.
-
Da kommt doch einiges zusammen, das ich erstmal durcharbeiten muss.... Da wird das Wochenende wohl etwas knapp.
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
Da kommt doch einiges zusammen, das ich erstmal durcharbeiten muss.... Da wird das Wochenende wohl etwas knapp.
Also ohne function Node?
-
@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?
-
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
@mickym dann versuchen wir es lieber ohne function node. Das hebe ich mir für später auf.
Ja und nochmal - wenn Du programmierst machst Du dir soviel kaputt - deswegen nur wenn es gar nicht anders geht.
Als erstes werden wir - da wir ja keine function Node mehr benutzen - Deine ganzen Parameter im flow Kontext speichern.
Man kann mit einer Inject Node - die beim Start ausgeführt wird - alle Parameter auch mit 0 initialisieren.
Trigger wird ja der Shelly sein. ;)
Da das Setzen der parameter unabhängig von den Shellies ist holen wir uns nun den ganzen FlowKontext rein. Ich ändere das oben nochmal in den ich nicht 3 einzelne Werte nehmen, sondern ein Objekt dann ist das einfacher. Ich nenne das Objekt mal EnergieManagement.
Das Ganze sieht dann so aus:
Wenn der Shelly dann triggert, dann lesen wir das ganze Objekt EnergieManagement in unser Nachrichtenobjekt ein.
Wir haben dazu in das Nachrichtenobjekt eine eigene Eigenschaft EnergieManagement aufgenommen und haben das nun überall in unserem Nachrichtenobjekt jederzeitverfügbar - zusammen mit der Shelly payload.
So nun versuche ich mich an Deine Logik von der function Node zu orientieren - wobei
sowas Käse ist (relais1 = relais[0].ison und wird ja auf true überprüft.
Sowas ist auch UNLOGISCH:
Das sind haargenau die gleichen Bedingungen und werden beide ausgeführt - im Code wird also der grüne Bereich NIE eintreten, weil er durch den roten Code überschrieben wird. Das ist auch überflüssig - da ja theoretisch das Relais 1 schon eingeschaltet ist.
-
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
@mickym dann versuchen wir es lieber ohne function node. Das hebe ich mir für später auf.
Ja und nochmal - wenn Du programmierst machst Du dir soviel kaputt - deswegen nur wenn es gar nicht anders geht.
Als erstes werden wir - da wir ja keine function Node mehr benutzen - Deine ganzen Parameter im flow Kontext speichern.
Man kann mit einer Inject Node - die beim Start ausgeführt wird - alle Parameter auch mit 0 initialisieren.
Trigger wird ja der Shelly sein. ;)
Da das Setzen der parameter unabhängig von den Shellies ist holen wir uns nun den ganzen FlowKontext rein. Ich ändere das oben nochmal in den ich nicht 3 einzelne Werte nehmen, sondern ein Objekt dann ist das einfacher. Ich nenne das Objekt mal EnergieManagement.
Das Ganze sieht dann so aus:
Wenn der Shelly dann triggert, dann lesen wir das ganze Objekt EnergieManagement in unser Nachrichtenobjekt ein.
Wir haben dazu in das Nachrichtenobjekt eine eigene Eigenschaft EnergieManagement aufgenommen und haben das nun überall in unserem Nachrichtenobjekt jederzeitverfügbar - zusammen mit der Shelly payload.
So nun versuche ich mich an Deine Logik von der function Node zu orientieren - wobei
sowas Käse ist (relais1 = relais[0].ison und wird ja auf true überprüft.
Sowas ist auch UNLOGISCH:
Das sind haargenau die gleichen Bedingungen und werden beide ausgeführt - im Code wird also der grüne Bereich NIE eintreten, weil er durch den roten Code überschrieben wird. Das ist auch überflüssig - da ja theoretisch das Relais 1 schon eingeschaltet ist.
-
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:
Ich muss also später noch eine Hystere dazunehmen, sonst schwingt das ganze Werk wild.
Die Hysterese hast Du ja in dem Du eine Ein- und Ausschwelle hast.
-
An Deiner Stelle versteh ich auch nicht, warum du die Summe mit einem Slider setzt - macht es nicht Sinn, dass die Summe automatisch festgelegt wird - z.Bsp. durch den oberen Teil.
Musst Du aber wissen.
-
An Deiner Stelle versteh ich auch nicht, warum du die Summe mit einem Slider setzt - macht es nicht Sinn, dass die Summe automatisch festgelegt wird - z.Bsp. durch den oberen Teil.
Musst Du aber wissen.
-
@mickym Der Slider ist nur zu Testzwecken drin. Die für die Relaisschaltung relevante Summe kommt aus dem ersten Teil des Flows.
-
@rudi-3 also abgezweigt von der Gesamtleistung. Wie ich schon sagte, der Flow ist durch die vielen Versuche leider ziemlich zerpflückt.
-
An Deiner Stelle versteh ich auch nicht, warum du die Summe mit einem Slider setzt - macht es nicht Sinn, dass die Summe automatisch festgelegt wird - z.Bsp. durch den oberen Teil.
Musst Du aber wissen.
@mickym Sorry habe zwischendurch für eventuelle Mitleser meine Gedanken zur Hysterese zusammengefasst. Stimmt, das ist die halbe Miete. In der Praxis wird allerdings folgendes passieren: Wir erreichen z.B. 1000W Überschuss. Der Heizstab schaltet ein (700W). Dann liegt der Überschuss nur noch bei 300W. Dementsprechend groß muss die Hystere sein bzw. wird unnötig Strom verschenkt. Zudem soll der Heizstab nicht unnötig oft schalten. Daher möchte ich zum Schluss eine Verzögerung einbauen, die z.B. nur alle paar Minuten ein Schaltsignal an die Relais gibt. Dabei muss man natürlich abwägen, das hier kurzzeitig teurer Netzstrom ins Warmwasser geht.
-
@mickym Sorry habe zwischendurch für eventuelle Mitleser meine Gedanken zur Hysterese zusammengefasst. Stimmt, das ist die halbe Miete. In der Praxis wird allerdings folgendes passieren: Wir erreichen z.B. 1000W Überschuss. Der Heizstab schaltet ein (700W). Dann liegt der Überschuss nur noch bei 300W. Dementsprechend groß muss die Hystere sein bzw. wird unnötig Strom verschenkt. Zudem soll der Heizstab nicht unnötig oft schalten. Daher möchte ich zum Schluss eine Verzögerung einbauen, die z.B. nur alle paar Minuten ein Schaltsignal an die Relais gibt. Dabei muss man natürlich abwägen, das hier kurzzeitig teurer Netzstrom ins Warmwasser geht.
-
@rudi-3 Na mit der Ein und Ausschaltschwelle hast Du eine Hysterese - wenn Du Angst hast, dass das zeitlich beides zu häufig ausgelöst wird kannst Du die Nachrichtenrate begrenzen.
-
@mickym Meine Idee war, einfach die polling rate von den shellys zu nutzen. Die delay-node wollte nicht nutzen und nur an einer Stelle "bremsen".
@rudi-3 Na musst Du sehen - hier der Flow ist fertig und nun kannst Du selbst einfach über Debug Nodes schauen, wie die Logik verläuft und musst auch keine unwahrscheinlichen Fälle berücksichtigen:
Hier der Import. Viel Spaß! ;)
Und das ohne Code - (wenn man mal von < oder > absieht. ;) )
Ich würde an Deiner Stelle auch mit der Inject Node - die Szenarien simulieren - das macht mehr Sinn - als den Realbetrieb abzuwarten - dafür brauchst Du auch nicht das Dashboard.
Du kannst einfach das Objekt verändern und dann mit Inject Now - mit dem veränderten Objekt testen:
Wenn Du die Debug NOdes anständig benennst - erkennst Du so auch - ob die Relays richtig geschaltet werden. In dem Beispiel wird also simuliert, wie erst Relay1 und dann Relay2 einschaltet.
-
@rudi-3 Na musst Du sehen - hier der Flow ist fertig und nun kannst Du selbst einfach über Debug Nodes schauen, wie die Logik verläuft und musst auch keine unwahrscheinlichen Fälle berücksichtigen:
Hier der Import. Viel Spaß! ;)
Und das ohne Code - (wenn man mal von < oder > absieht. ;) )
Ich würde an Deiner Stelle auch mit der Inject Node - die Szenarien simulieren - das macht mehr Sinn - als den Realbetrieb abzuwarten - dafür brauchst Du auch nicht das Dashboard.
Du kannst einfach das Objekt verändern und dann mit Inject Now - mit dem veränderten Objekt testen:
Wenn Du die Debug NOdes anständig benennst - erkennst Du so auch - ob die Relays richtig geschaltet werden. In dem Beispiel wird also simuliert, wie erst Relay1 und dann Relay2 einschaltet.
@mickym Cooler Tip, das werde ich versuchen. Bisher haben bei mir viele Beispielflows mit inject-nodes funktioniert und mit den shellys dann nicht mehr. Daher habe ich hier ein Provisorium auf dem Tisch liegen..
Ich hatte mir zwar extra ein Node-Red Buch gekauft, aber die größte Lernkurve hatte ich heute Nachmittag, auch wenn ich noch nicht alles nachvollzogen habe. Da wird mir am Sonntag bestimmt nicht langweilig. Vielen Dank nochmals für Deine ausführlichen Erklärungen, damit kann man gut arbeiten. Vor allem sind sie auch für andere hilfesuchende eine gute Informationsquelle.
Übrigens ist es heute auf den Tag genau 20 Jahre her, das ich mit Forumshilfe ein größeres Bastelprojekt hinbekommen habe. Daher möchte ich mich speziell bei Dir und im Allgemeinen bei Allen bedanken, die ihr Wissen im Internet teilen.
Rudi
Support us
579
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge