UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[mickym]

@hape1

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]

@mickym ... Du bist zu schnell für mich :-) :

[mickym]

@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.

[Hape1]

@mickym

Ok, "alles klar" :-) ... ich werde den Flow testen und melde mich einem Ergebnis zurück ...

Ps. Dein Tempo ist mir ein wenig unheimlich :-) VIELEN DANK!

[mickym]

@hape1 sagte in Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard:

@mickym

Ok, "alles klar" :-) ... ich werde den Flow testen und melde mich einem Ergebnis zurück ...

Ps. Dein Tempo ist mir ein wenig unheimlich :-) VIELEN DANK!

Na ich dachte eigentlich, dass ich Dir das Schritt für Schritt erkläre. Ich hätte ja auch einfach den Flow fertig machen können. Es geht mir aber darum, dass Du verstehst was passiert und welchen Vorteil Du mit dieser grafischen Programmierung hast und eben nicht Text und Text formulierst sondern die Macht der Knoten nutzt. ;)

Ich würde es auch mal schön machen und in eine Linie zeichnen, also die Nodes NICHT so untereinander zu quetschen - dann sieht man schöner wie der Flow von Anfang (links) also dem Trigger - zur Steuerung ganz nach rechts läuft.

[Hape1]

@mickym

... nein, nein, Missverständnis ... die Erklärungen waren sehr hilfreich, aber ich musste erstmal nachdenken, bis ich das erklärte verstanden hatte ... Alles gut, ich freue mich, wenn ich was lernen kann!

[mickym]

@hape1 trotzdem musst du Dir halt deine Logik überlegen. Im Moment würde halt alles blockiert, sobald der Ladezustand der Batterie unter 99% sinkt. Ich weiß nicht, ob das gewünscht ist - aber wie gesagt, das musst Du wissen.

[Hape1]

@mickym sagte in Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard:

@hape1 trotzdem musst du Dir halt deine Logik überlegen. Im Moment würde halt alles blockiert, sobald der Ladezustand der Batterie unter 99% sinkt. Ich weiß nicht, ob das gewünscht ist - aber wie gesagt, dass musst Du wissen.

Das soll natürlich nicht sein!

Bei unter 99% soll der Wechselrichter seine volle Leistung bringen!

[mickym]

@hape1 Ja wie gesagt, das musst Du wissen. Momentan blockiert die 1. Switch Node alles wenn der SOC kleiner 99 ist.

Und vielleicht bringt ja der Wechselrichter seine volle Leistung wenn nichts an den mqtt-Switch geschickt wird. Ansonsten musst Du halt nun auch dafür sorgen, was soll passieren, wenn der SOC unter 99% ist. Dann machst Du da einen 2. Ausgang hin und formulierst die Bedingungen.

[Hape1]

@mickym

ok, aber das würde ja sinngemäß auch für den EVCS_Status gelten:

Denn bei allen Werten die NICHT 3 sind, soll der Wechselrichter voll laufen ...

ok, ich denke noch mal darüber nach.

[mickym]

@hape1 Vielleicht solltest Du dann auch die Reihenfolgen der Switch Nodes ändern und einen 2. Ausgang bei der EVCS Filter Node machen - wo der Status ungleich (also != 3) ist.

Am Besten ist halt Du formulierst die Bedingung in Sätzen:

1. Wenn SoC => 99 und EVCS = 3
2. Wenn SoC <99 und EVCS !=3 usw.

Denn bei allen Werten die NICHT 3 sind, soll der Wechselrichter voll laufen ...

Sowas sagt mir nichts.

[Hape1]

@mickym

?

[mickym]

@hape1 NEIN - nochmal 2 Ausgänge in die gleiche Node sind unsinnig.

Wenn Du folgendes machen willst:

1. Soc => 99 und EVCS = 3
   Soc <99 und nicht <= 98 (ist einfach eindeutiger)

2. Ausgang (nicht 2 mal = - die Bedingungen sollen ja EINDEUTIG sein)

An den 2. Ausgang machst Du dann eine 3. Switch Node hin - in der Du EVCS !=3 prüfst.

[mickym]

So schaut der Flow korrekt aus. Hier zum Import:

Spoiler

[{"id":"c4c40945afdc6a5c","type":"switch","z":"289f539dcc33814e","name":"batterie_SOC >= 99?","property":"payload","propertyType":"msg","rules":[{"t":"gte","v":"99","vt":"num"},{"t":"lt","v":"99","vt":"num"}],"checkall":"true","repair":false,"outputs":2,"x":440,"y":4920,"wires":[["ad05fef3c6162b83"],["3c358c83e23a5c47"]]},{"id":"ad05fef3c6162b83","type":"switch","z":"289f539dcc33814e","name":"EVCS_Status == 3","property":"EVCS_Status","propertyType":"flow","rules":[{"t":"eq","v":"3","vt":"num"}],"checkall":"true","repair":false,"outputs":1,"x":670,"y":4900,"wires":[["b184583f91d48f03"]]},{"id":"3c358c83e23a5c47","type":"switch","z":"289f539dcc33814e","name":"EVCS_Status != 3","property":"EVCS_Status","propertyType":"flow","rules":[{"t":"neq","v":"3","vt":"num"}],"checkall":"true","repair":false,"outputs":1,"x":670,"y":4940,"wires":[["b184583f91d48f03"]]},{"id":"b184583f91d48f03","type":"junction","z":"289f539dcc33814e","x":840,"y":4920,"wires":[[]]}]

Du musst Dir einfach vorstellen, Du bist ein Nachrichtenobjekt und Du kommst bei den verschiedenen Nodes an, die Dich entweder passieren lassen, Dir den richtigen Ausgang zeigen oder Deine Weiterreise unterbinden.

Wenn Du übrigens mit der Maus über die entsprechenden Ausgänge fährst wird Dir die Bedingung für den Ausgang angezeigt:

Wenn Du sowas machst:

dann kannst Du Dir auch die Bedingungen sparen - das macht nur Sinn, wenn es dann noch Fälle gibt, die weder in den Ausgang 1 noch in den Ausgang 2 gehen. Wenn aber die Nachrichten immer entweder in Ausgang 1 oder in den Ausgang 2 gehen - dann kann ich mir den Node auch sparen.

Hier wieder das Gleiche:

Egal ob der EVCS Status 3 oder ungleich 3 ist - alle Nachrichten werden in die mqtt Node weitergeleitet. Dann kann ich die Node auch weglassen.

[Hape1]

@mickym

hmm, irgendetwas stimmt noch nicht ...

Aus den debug-notes 6 und 7 kommt nix ...

Aus 4 und 5 schon ...

Will sagen es gibt zwar keinen Netzbezug, weil noch aus der Batterie gespeist wird, aber die Bedingung Batt <98 und EVCS-Status !=3 sind erfüllt, es sollte also keine Runterregelung des Wechselrichters stattfinden ...

[mickym]

@hape1 Na das aus 6 nichts kommt ist ja richtig - da der SOC unter 99 liegt. Also müsste es ja aus 7 rauskommen, da unter 99 % und ungleich 3. Also prüfe nochmal beide Ausgänge der 1. Switch Node

[Hape1]

@mickym

nein, das ist verkehrt herum, sobald unter 98 soll was rauskommen!

[mickym]

@hape1 Wie gesagt mach noch debug Nodes an die Ausgänge der 1. Switch Node dran und dann schau, was nicht passt.

[mickym]

@hape1 sagte in Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard:

@mickym

nein, das ist verkehrt herum, sobald unter 98 soll was rauskommen!

Zeig halt mal Deine 1. Switch Node nochmals. Vielleicht habe ich ja auch einen Fehler gemacht.

[Hape1]

@mickym

Du hast keinen Fehler gemacht --> aber ich, weil es einfach einen Schreibfehler gab. Jetzt kommt was ...

debug 6 ist allerdings still.

erster Switch: