Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard
-
@hape1 Die rangeNode gibt halt den einschließenden Ausgabebereich einfach weiter und gibt halt wenn dieser über- bzw. unterschritten wird die definierten Ränder aus. Die payload kannst ja dann mit mqtt wo du willst hinschreiben.
-
@mickym ... erstmal ganz lieben Dank für Deine Hilfe. Ich kann das Setup erst testen, wenn die Sonne scheint, was also frühestens morgen sein wird. Ich melde mich dann hierzu zurück.
Nochmals vielen Dank für Deine Hilfe, ich hätte wenn ich es überhaupt hingekriegt hätte, wohl eher Wochen statt Stunden gebraucht ... !!!
-
@hape1 Ja gerne. Wie gesagt mit debug und inject Nodes kannst Du immer viel simulieren und testen - dann brauchst Du nicht auf die Sonne warten. Aber ansonsten mach mal eine Pause und lasse es Dir mal durch den Kopf gehen. Wichtig ist, dass Du NodeRed nutzen willst und nicht programmieren. Das kannst Du im iobroker auch ohne NodeRed.
-
Hast Recht, die Stunden haben mir wohl "zugesetzt" --> ich habe nämlich glatt mal drei zusätzliche Bedingungen für die Ausregelung des Wechselrichters gegen 0 vergessen:
- Diese soll erst greifen, wenn die Hausbatterien voll geladen und
- zusätzlich das Auto nicht an der Wallbox hängt bzw.
- dieses voll geladen ist.
Die Datenpunkte von 1-3 stehen per mqtt zur Verfügung.
Ok, ich lasse das jetzt erstmal sacken und melde mich wieder ...
-
@mickym Hi, melde mich zum Thema zurück.
Der programmierte Flow funktioniert wie gewünscht, der Wechselrichter reagiert genauso wie es der Flow vorgibt und wird gegen 0 ausgeregelt.
Super!
Nun muss aber noch etwas dazu, nämlich die folgenden, zusätzlichen Bedingungen:
- Die Hausbatterien müssen voll geladen sein und
- das Auto (Wallbox) voll geladen ist bzw.
- dieses gar nicht angeschlossen ist.
Erst wenn die Bedingungen 1-3 erfüllt sind soll die Ausregelung gegen 0 erfolgen.
Die Datenpunkte von 1-3 stehen per modbus-iobroker-Adapter zur Verfügung.
Wäre schön, wenn Du mir nochmal helfen würdest.
-
@hape1 Nun Du musst Dir halt die Daten entweder in den Flow holen oder Du holst Dir unabhängig die Daten in NodeRed, was ich effizienter finde und speicherst das in Flowvariablen. Bedingungen die alle erfüllt sein müssen, erreichst Du in dem Du mit Switch Nodes nur dann die Nachrichten weiter durchlässt, wenn diese erfüllt sind.
Ich würde also mit iobroker IN Nodes (diese so konfigurieren, dass sie beim Start die Werte einlesen) die Werte in Variablen des Flow Kontexts speichern (machst Du mit einer ChangeNode). Den Inhalt kannst Du im Kontexttab überprüfen.
-
Ok, so sieht das Ganze jetzt aus ... ich muss. Dein Input wäre nun hilfreich ...
Wobei ich noch vergessen habe, das die "EVCS" folgende Statusmeldungen bringt:
0 - Disconnected
1 - Connected
2 - Charging
3 - Charged
4 - Waiting for sun
6 - Waiting for start
7 - Low SOC0 = Bedingung KEINE Ausregelung gegen 0
1 = Bedingung KEINE Ausregelung gegen 0
2 = Bedingung KEINE Ausregelung gegen 0
4 = Bedingung KEINE Ausregelung gegen 0
6 = Bedingung KEINE Ausregelung gegen 0
7 = Bedingung KEINE Ausregelung gegen 03 = Bedingung Ausregelung gegen 0
-
@hape1 ja die iobroker In Nodes mit Fire bei Start sehen gut aus. Nun speicherst Du die payload einfach in einer Variablen im Flowkontext mit einer Change node.
Also zum Beispiel die erste Node in einer Variablen "Batterie_SoC" oder "EVCS".
Den Flow Kontext musst Du akutualisieren, um den aktuellen Zustand Deiner Variablen zu sehen.
Welcher Zustand geliefert wird, ist erst mal egal - Du musst ja nur wissen auf was Du später filtern willst.
-
-
@hape1 Gar nichts speichere einfach die payload im Kontext - ist doch egal wenn da Zahlen drin stehen. Du musst ja nur wissen, welche Bedeutung die Zahlen haben.
-
-
@hape1 Ja und nun filterst Du mit switch Nodes alles aus, so dass nur noch wenn die Bedingungen stimmen die Nachricht die mqtt Node erreicht.
-
Obwohl, das ginge wohl auch mit nur einem Switch, in dem dann die unterschiedlichen Bedingungen zusammengefasst werden?
-
Nein komplett verkehrt - da unten haben die switch Nodes gar nichts verloren und Du filterst eins nach dem anderen.
Also welchen Status muss EVCS haben?
Welchen Status muss der SoC haben?Beides machst Du in eine eigene Switch Node und schiebst die als Filter vor Deine mqtt Node. In dem Du die beiden Switch Nodes in Serie schaltest müssen ja beide Bedingungen erfüllt sein.
-
EVCS hat folgende Statusausgaben:
0 = Bedingung KEINE Ausregelung gegen 0
1 = Bedingung KEINE Ausregelung gegen 0
2 = Bedingung KEINE Ausregelung gegen 0
4 = Bedingung KEINE Ausregelung gegen 0
6 = Bedingung KEINE Ausregelung gegen 0
7 = Bedingung KEINE Ausregelung gegen 03 = Bedingung Ausregelung gegen 0
Batterie SOC
Ausgabe als Wert in %D.h. =/> 99% = Ausregelung gegen 0
-
@hape1 Damit kann ich nichts anfangen, versetze Dich doch mal in das Nachrichtenobjekt. Aus der Range Node kommt ein Wert zwischen 0 und 1600. Muss dieser Wert irgendwas überprüft werden oder soll der EVCS überprüft werden.
Sag genau wie Deine Bedingung aussehen soll.
Wenn der Wert 300 kommt und EVCS Status ungleich 3 und SOC < 80 ist, dann soll geregelt werden. Versuche mal Deinen Flow in eine Logik zu formulieren. Ich kenne mich damit NICHT aus - DU musst die Logik schon selbst formulieren - ich kann Dir nur vorschlagen, wie man es umsetzen kann.
Ich kenne mich nicht mit Batterien etc. aus - das musst Du schon selbst formulieren.
Du weißt doch, dass aus der range Node ein Wert zwischen 0 und 1600 rauskommt, was soll also als nächstes überprüft werden? oder von mir aus verzweigt sich Dein Flow - weil die Bedingungen bei unterschiedlichen Werten unterschiedlich aussehen. Du musst halt Schritt für Schritt überlegen, wie und was geprüft werden soll.
-
Kein Problem, ich bin ja froh, das Du nicht alles weißt
Ok, ich formuliere das jetzt mal so:
Wenn die Bedingung Batterie SOC =/> 99% UND der EVCS Status den Wert 3 ausgibt dann soll der Flow arbeiten und den Wechselrichter runterregeln.
Im Umkehrschluss wird daraus, das beim EVCS-Status 0;1;2;4;6;7 und alles SOC-Werten <98% KEINE Ausregelung erfolgen soll.
Dh. ich würde das mal mit meinem Wissen so ausbilden:
-
So was macht in der Regel keinen Sinn, weil dann brauche ich keine Abprüfung.
Also wenn wir das umsetzen wollen: Wenn die Bedingung Batterie SOC =/> 99% UND der EVCS Status den Wert 3 ausgibt dann müssen wir dafür sorgen, dass nur das durchgelassen wird - alles andere wird ja automatisch blockiert.
Also zeig wie du Deinen State of Charge überprüftst?
Das ist schon mal verkehrt - also Name würde ich eine geben "Batterie_SOC > 99%" - das beschriftet Dir die Node nur.
In der Eigenschaft steht der Wert den du überprüfen willst und das ist NICHT die payload - da diese ja den Wert 0-1600 aus Deiner Summierung enthält. Du willst doch den Wert Deiner Flowvariablen Batterie_SOC überprüfen und nicht die payload. Also stelle das erst mal richtig.Das mit der Überprüfung der Variablen EVCS ist natürlich auch Quatsch. Hier überprüfst Du ja wieder Deine payload - die Deine Werte aus der range Node enthält:
Dann macht es in der Regel (es gibt Ausnahmen) KEINEN Sinn wenn beide Ausgänge GLEICH behandelt werden - sprich alle in die gleiche Node münden ohne dass dazwischen das Nachrichtenobjekt unterschiedlich bearbeitet wird.
Auch hier dient der Name nur der Beschriftung der Node - das kann man dafür nutzen - da wir nur die Nachricht durchlassen wollen, wenn EVCS gleich 3 ist. Dann schreibst Du als Name am Besten "EVCS = 3"
-
-
@hape1 ##
wenn du das ist true wegmachst, dann passt es - ES wird grundsätzlich die Nachricht nur an den Ausgang weitergeleitet wenn die Bedingug erfüllt ist.
Und wie gesagt Du kannst das alles überprüfen indem Du mit Inject Nodes die Werte simulierst und änderst.
Wenn Du hinter jede Switch Node eine Debug Node machst, dann kannst Du genau nachvollziehen, welche Node die Nachricht wegfiltert oder durchlässt.
:
