shelly Status zur Fallunterscheidung nutzen
-
@mickym stimmt, im Code ist's falsch im Kommentar steht drin wie es sein soll. muss ich beim rumprobieren ver... haben.
-
@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.
-
@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.
-
@rudi-3 Wenn ich das Konzept richtig verstanden habe, müsste man die Summe von oben in das Objekt "Energiemanagement" aufnehmen?
-
@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.
-
@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 -
@rudi-3 sagte in shelly Status zur Fallunterscheidung nutzen:
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.
Wie gesagt von der Pollerei und festen Zeiten halte ich gar nichts - so was löst man besser mit einer Trigger Node. Ich mach das dann meist so - dass am Anfang nichts gesendet wird und wenn Deine Karenzzeit vergangen ist - erst geschaltet wird.
Diese Node ist so was von genial und auch wieder ohne Code.
Du achtest darauf, dass nur veränderte Nachrichten durchkommen - dass kann man mit einer filter Node machen.
Mit jeder neuen Nachricht (also wenn ping pong gespielt wird) - wird die Nachricht 1 Minute lang in der trigger Node zurückgehalten. Jede neue Nachricht verzögert wieder um 1 Minute. Damit ist das ganze nicht starr.
Erst nach Ablauf der Minute ohne eine veränderte Nachricht wird die letzte, aktuellste Nachricht durchgelassen.
Da die Shelly Node ja permanent sendest - kannst Du die Trigger Node auch umgekehrt konfigurieren, dann kommt das Signal sofort durch - ist aber dann für die Minute gesperrt/blockiert, um neue Nachrichten weiterzuleiten.
Wie gesagt eine geniale Node, wie ich finde.
