Hoymiles WR per MQTT an/aus - abhängig vom SoC der Batterie
-
Hey
Ich habe ein kleines Bastelprojekt, wo ich einen HM400 mit 2 x 12V 100Ah LiFePo4 in Reihe betreibe. Dazu gibts n 75/15 von Victron und den 500A Smartshunt.
Die Daten derer werden von "OpenDTU-onbattery" gesammelt und auf meinen Iobroker MQTT geschoben.Nun möchte ich dort ein Automation in Node-Red realisieren, das der HM-400 nur einspeisen darf, wenn der SoC des Akkus zwischen 20% und 90% ist, also bis 20% entladen, dann warten bis SoC wieder bei 90% ist, dann wieder entladen.
Zusätzlich soll natürlich geschaut werden, ob wir überhaupt Bezug haben - diese Daten kommen auch von OpenDTU, weil er die Daten vom Shelly 3EM schon publisht.
Speisen wir eh schon ein (anderer WR), darf dieser HM-400 nicht einspeisen. Diesen Wert möchte ich einstellbar machen, damit ich zb sagen kann, ab wann der HM-400 "einspringen" soll. Also wenn der erste WR keine Sonne mehr hat - und sagen wir - nur noch 10W macht, geht der eh dann bald aus - dann soll der HM-400 "übernehmen".Das Ganze soll nun auch noch zeitgesteuert werden, also soll erst ab 20 Uhr (einstellbar) zb lauffähig sein, natürlich auch nur dann, wenn Bezug da ist und der Akku einen passenden Stand hat.
Da ich es verstehen will, soll natürlich niemand den Flow für mich machen - ich wills ja lernen.
Ich weiß nur nicht, wie ich jetzt weiter machen muss, das auf dem Bild hab ich schon lauffähig bekommen
Also den SoC hab ich schonmal als Wert zum Vergleichen, aber ich weiß nicht, wie das funktioniert. Da bräuchte ich mal etwas Hilfe, wie ich jetzt einen Vergleich mache, ob ich mich innerhalb oder außerhalb der "Range" befinde.
Das Ein, - und Ausschalten geht soweit. Mit "0" senden geht er off und mit "1" wieder an.
Wie gehts jetzt weiter? Kann man sowas überhaupt realisieren, mit all den Wünschen?
Chris
-
@fellpower Nun dann schau Dir vielleicht noch mein Datums und Uhrzeit Thread an.
https://forum.iobroker.net/topic/50086/datum-und-zeitverarbeitung-mit-noderedHier siehst Du zum Beispiel wie Du Zeitfenster mit Standardnodes prüfen kannst. Ansonsten kannst Du Dir auch die Chronos Nodes installieren. (https://flows.nodered.org/node/node-red-contrib-chronos)
Wenn Du Zeiträume mit Standardnodes über den Tageswechsel benötigt nimmst, dann nimmst Du die Verneinung der komplimentären Periode.
Ansonsten musst Du nun nur mit switch Nodes Deine Bedingungen formulieren und dann entsprechend die payload setzen. Wobei bissi eigenartig warum Du 2 verschiedene topics mit 2 unterschiedlichen payloads hast. Der SoC kann ja triggern, als nächstes würde ich mich um das Zeitfenster kümmern und dann den SoC.
Und ich würde nochmal prüfen, ob Du nicht mit EINER identischen Node über verschiedene topics schalten kannst oder über ein topic mit verschiedenenen payloads.
-
Dankeschön für deine Antwort. Das sind ja schon einmal mehr Informationen, um sich weiter in das Thema "einzugraben".
Ich kann natürlich über eine Node den WR an und aus machen, das geht. Ich habe das nur für mich zum Testen so gemacht. Wenn du das meintest.
An dieses Topic schicke ich halt ne 0 für aus und ne 1 für an. Ist ein Command von OpenDTU.
Verzeih mir bitte, wenn ich nicht alles verstanden habe, was du geschrieben hast, ich habe nur Grundlagen in Node-Red, versuche mich aber einzuarbeiten.
Es scheitert natürlich auch an der nicht vorhandenen Kenntnis von Javascript oder überhaupt irgend einer Programmiersprache - daher möchte ich es ja "grafisch" per Node-Red machen.Wie man Payloads zusammensetzt / zerlegt, oder parsed aus ner JSON usw (liefert OpenDTU ja) - da muss ich noch dran arbeiten.
Alleine schon das "payload setzen" bringt mich manchmal um den Verstand
Ich habe es jetzt erstmal so gelöst (mit timeswitch Paket Installation):
Jetzt noch der SoC
-
@fellpower nun ja ich verstehe ja was du willst und ich bin ja auch ein Freund des grafischen „Programmierens“, nur ein paar Grundkenntnisse wirst du Dir trotzdem aneignen müssen.
noch fehlt es Dir aber im Moment an der Logik. ich hatte Dich ja außerdem gefragt, ob du nur Standard-Nodes nutzen willst oder auch zusätzliche Nodes?
Nun Du willst anscheinend auch zusätzliche Nodes nutzen und das ist ja völlig in Ordnung. Nur warum installierst Du Dir dann eine timeswitch node, anstatt der von mir empfohlenen Chronos nodes?
Diese Nodes spukt nun alle Minuten eine 0 oder eine 1 aus. Was hat das aber mit dem SoC zu tun? Ist es nicht sinnvoller den SoC triggern zu lassen, als die Uhrzeit?
ich würde dir auch immer empfehlen, eine Bedingung nach der anderen abzuarbeiten und dir genau zu überlegen, was triggert und was nicht? Das sind reine logische Überlegungen und die müssen klar sein, bevor Du auch nur eine Node verwendest.
am Besten erklärst du mal was dein flow da unten macht.
-
@mickym
Logik ist kein Problem, ich versteh die Grundlagen, wie AND, OR usw schon. Nur ist mir nicht klar, wie ich das in Node-Red umsetzen muss.Natürlich nehme ich auch Nodes, die es mir vereinfachen, also müssen es nicht nur Standard Nodes sein.
Das untere Bild war nur ein Test, um zu schauen, ob ich den WR zu einem bestimmten Zeitpunkt anschalten kann. Mit Chronos hab ich auch schon rumprobiert, aber irgendwie ist mir das, ohne Wissen, noch zu komplex. Ich muss mich da erst einlesen. Von deinem "Chronos Thread" habe ich nur 10% verstanden - das muss ich mir erstmal erarbeiten.
Ihr, die sich damit auskennen, wisst, was ne msg is, was n topic ist usw. Ich muss mich da erst rein finden, wie das funktioniert.
Den SoC zu triggern habe ich versucht - mit switch Node - aber das müsste ja ne Art Flip Flop sein, damit es funktioniert.
Ist der SoC über 45% (Beispiel) darf der WR an sein - aber nur, wenn die Zeit stimmt. Und natürlich kein Bezug ist (das gilt es auch noch rauszufinden, wie das dann geht). Also habe ich einfach ne switch Node gemacht, mit >= 45. Leider geht der WR dann gleich an, anstatt auf die 90% SoC zu "warten". Logisch,w eil ja die Ausgabe der switch Node keine 0 oder 1 ist, sondern dann wird dort ja der Wert ausgegeben.
Es soll ja immer so sein: In der Nacht wird die Batterie leer gemacht, bis 45% (Beispiel). Morgens ist der WR dann aus, weil der SoC 45% erreicht hat. Nun muss aber gewartet werden, bis der SoC wieder 90% erreicht, erst dann darf der WR wieder starten, zeitlich und bezugstechnisch gesteuert. Bis 45% entladen - neuer Durchlauf.
Ich weiß, viel zu ambitioniert für meine Idee. Sinnvoll? Vielleicht nicht. Würdest ihr das anders machen? Bestimmt. Aber ich möchte damit ja auch verstehen, wann ich welche Node einsetzen kann.
Ich habe ja viele Bedingungen, die ich auswerten möchte. Ich denke, ich werde erstmal weiter lesen.
-
@fellpower sagte in Hoymiles WR per MQTT an/aus - abhängig vom SoC der Batterie:
Ihr, die sich damit auskennen, wisst, was ne msg is, was n topic ist usw. Ich muss mich da erst rein finden, wie das funktioniert. ;)t
Nun um es Dir etwas zu vereinfachen, fasse ich das mal als Frage auf. Das Nachrichtenobjekt ist das Kernelement eines Flows und wird von links nach rechts durch die Verbindungskabel von einer Node zur anderen geschickt. Dabei kann das Nachrichtenobjekt beliebig viele Eigenschaften haben, die man auch selbst definieren kann. topic und payload sind 2 Eigenschaften, die man am häufigsten nutzt, auch wenn das technisch nicht zwingend ist. Es ist eine Art Vereinbarung. In der Nachrichteneigenschaft „payload“, sind die sogenannten Nutzdaten, also zum Beispiel Dein SoC, der vielleicht aktuell zum Beispiel vielleicht 30 ist. Das topic beschreibt in der Regel, um was es sich bei der payload handelt. Wenn du einen komplexeren Flow hast, könnte es ja mehrere payloads mit dem Wert 30 geben. Also beschreibt das topic in der Regel, um was es sich bei der payload handelt. Also um einen SoC oder um eine Temperatur.
Den SoC zu triggern habe ich versucht - mit switch Node - aber das müsste ja ne Art Flip Flop sein, damit es funktioniert.
Na das ist doch schon mal ein richtiger Ansatz.
Ist der SoC über 45% (Beispiel) darf der WR an sein - aber nur, wenn die Zeit stimmt. Und natürlich kein Bezug ist (das gilt es auch noch rauszufinden, wie das dann geht). Also habe ich einfach ne switch Node gemacht, mit >= 45. Leider geht der WR dann gleich an, anstatt auf die 90% SoC zu "warten". Logisch,w eil ja die Ausgabe der switch Node keine 0 oder 1 ist, sondern dann wird dort ja der Wert ausgegeben.
Nun hier siehst Du ja was ich mit Logik meine. Das mit dem Switch zur Unterscheidung von verschiedenen Fällen ist ja richtig, aber die Logik war eben nicht richtig. Wenn deine switch Node also >= 45 abfragt, geht der WR gleich an, anstelle zu warten. Deshalb darf der SoC nur an den Grenzen triggern und zwischendrin, triggert der SoC eben nichts. Der Zustand des WR ist also für den Flow völlig irrelevant. Den kannst Du vielleicht in einem eigenem Flow ermitteln und dann in einer Kontextvariablen speichern, aber ist in diesem Zusammenhang völlig irrelevant. Also ist Dein Logikfehler, der gewesen, dass bei einem SoC von 45 überhaupt etwas passieren soll.
Deshalb lässt man aus der switch node nur SoC Nachrichten durch wenn dieser >= 90 oder <= 20 ist. Da Du ja nicht mit einer payload von 90 oder 20 schaltest, ÄNDERST Du die payload vom jeweiligen SoC Wert in 0 oder 1. Zur Änderung der payload oder allgemein einer beliebigen Nachrichteneigenschaft gibt es die Change Node.
Damit nicht mehrfach mit der gleichen Nachricht geschaltet wird, kannst du die payload mit einer Filternode noch auf Änderungen überprüfen.Es soll ja immer so sein: In der Nacht wird die Batterie leer gemacht, bis 45% (Beispiel). Morgens ist der WR dann aus, weil der SoC 45% erreicht hat. Nun muss aber gewartet werden, bis der SoC wieder 90% erreicht, erst dann darf der WR wieder starten, zeitlich und bezugstechnisch gesteuert. Bis 45% entladen - neuer Durchlauf.
Das Zeitmanagement übernimmst Du wenn Deine Logik grundsätzlich funktioniert. Das meine ich, mit eins nach dem anderen. Wenn du die von mir empfohlenen chronos Nodes installierst, dann enthalten diese auch einen timeswitch. Die jetzig installierte Node triggert unnötig, wenn der SoC triggert.
Ich weiß, viel zu ambitioniert für meine Idee. Sinnvoll? Vielleicht nicht. Würdest ihr das anders machen? Bestimmt. Aber ich möchte damit ja auch verstehen, wann ich welche Node einsetzen kann.
Das versuche ich Dir ja gerade zu vermitteln.
Ich habe ja viele Bedingungen, die ich auswerten möchte. Ich denke, ich werde erstmal weiter lesen.
Zusätzliche Bedingungen, wenn als UND definiert schaltest Du in Serie, ODER schaltest Du im Flow parallel.
-
Grundsätzlich solltest Du Dir ausserdem überlegen, ob Du in NodeRed mit mqtt arbeitest oder falls die Daten sowieso im iobroker sind, nicht mit den iobroker Nodes. Der Vorteil über den iobroker ist, dass Du da deine Daten ja jederzeit zur Verfügung hast.
Wenn Du das Zeitfenster variabel halten willst, dann solltest Du Dich lieber an die Standardnodes halten und wie gesagt simulieren als trigger mit Inject Nodes - also ob sie vom SoC kommen und schau Dir an, ob das Ergebnis passt.
-
Danke bis hierhin. Ja, der Denkprozess muss natürlich auch optimiert werden
Dein letztes Beispiel hatte ich auch schon so aufgebaut, um zu testen, aber meine switch node gibt ja keine 1 oder 0 aus, sondern an dem Ausgangsknoten dessen Regel wahr ist, den Wert.
Aber alleine die Reihen / Parallelschaltungen von Nodes. Viele Nodes haben zb keinen Eingang, oder nur einen Ausgang - da hat es mir das "UND durch Hintereinanderschalten" etwas schwer gemacht ^^
Ich bastel noch - mal schauen, ob ichs kapiere
Ich denke, mit den Hinweisen kann ich erstmal Lernen und Ausprobieren
-
Dein letztes Beispiel hatte ich auch schon so aufgebaut, um zu testen, aber meine switch node gibt ja keine 1 oder 0 aus, sondern an dem Ausgangsknoten dessen Regel wahr ist, den Wert.
Ja Deine switch Node gibt keine 0 oder 1 aus, deswegen ändert man die payload mit einer Change Node.
Aber alleine die Reihen / Parallelschaltungen von Nodes. Viele Nodes haben zb keinen Eingang, oder nur einen Ausgang - da hat es mir das "UND durch Hintereinanderschalten" etwas schwer gemacht ^^
Dann waren es nicht die richtigen Node. Die wichtigste Node um Bedingungen hintereinander zuschalten, ist das Hintereinanderschalten von Switch Nodes um die Nachrichten zu filtern.
-
