Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard
-
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 ...
-
@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
-
nein, das ist verkehrt herum, sobald unter 98 soll was rauskommen!
-
@hape1 Wie gesagt mach noch debug Nodes an die Ausgänge der 1. Switch Node dran und dann schau, was nicht passt.
-
@hape1 sagte in Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard:
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.
-
Du hast keinen Fehler gemacht --> aber ich, weil es einfach einen Schreibfehler gab. Jetzt kommt was ...
debug 6 ist allerdings still.
erster Switch:
-
@hape1 Ja das ist doch richtig! - Es soll ja nur entweder oder rauskommen.
Debug 6 darf ja nur was bekommen, wenn SoC >= 99 und der Status EVCS Status 3 ist. Sonst immer debug 7
Es würde JA KEINEN SINN machen, wenn 2 Nachrichten aufeinmal kommen!! (aus jedem Ast). Erstens willst Du ja nur 1 Nachricht alle 10 s und das macht ja sonst auch keinen Sinn, das alles abzuprüfen
Wie gesagt wenn Du meinen Flow importiert hättest, dann schaut der 1. Switch so aus:
-
oh sorry, ich habe den gar nicht gesehen ...
Ich sehe, das das System in den mqtt-node etwas schreibt, aber eigentlich müßte er unter den bestehenden Bedingungen:
Batterie unter 99%
EVCS ungleich 31600 W in den mqtt-node schreiben ... ?
Statt dessen pendelt der Wert um die 1W
-
@hape1 Nein es wird ja der Wert geschrieben, den Du aus der Summe berechnet hast (und der aus der range Node kommt). Wenn Du hier volle 1600 haben willst - egal was du vorher berechnet hast, dann spielt die berechnete Summe ja gar keine Rolle. Dann änderst Du halt zum Schluss die payload auf 1600. Du könntest also die Berechnung der Summe auch erst auf den oberen Ast ziehen. Aber wie gesagt kannst es erst mal so lassen, das kannst Du später immer noch optimoeren.
-
@mickym
das verstehe ich leider nicht ...Wenn das System nun um die 1W pendelt, obwohl es unter den jetzigen Bedingungen 1600 eintragen müßte, kann doch irgendwo etwas nicht stimmen, oder?
-
@hape1 sagte in Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard:
@mickym
das verstehe ich leider nicht ...Na was aus der range Node rauskommt wird doch jetzt egal welchen Ast Du nimmst unverändert in die mqtt Node geschrieben. Sprich debug 5 ist debug 7.
Wenn Du im unteren Ast immer 1600 in die mqtt node schreiben willst dann ändere die payload auf 1600 - dann wird immer 1600 geschrieben, wenn der untere Ast aktiv ist.
-
@hape1 sagte in Node-Red - Shelly PlusPlugS - Mqtt Node-Red Dashboard:
@mickym
das verstehe ich leider nicht ...Wenn das System nun um die 1W pendelt, obwohl es unter den jetzigen Bedingungen 1600 eintragen müßte, kann doch irgendwo etwas nicht stimmen, oder?
Vom Flow her schon wenn das nicht Deiner Logik entspricht, dann setze unten auf 1600. Wie gesagt Du musst wissen, was Du willst. Vom Flow her stimmt alles.
-
Ich verstehe nicht, wo Du die 1600 eintragen möchtest ...
-
@hape1 Nun wenn Du willst, dass die Summe keine Rolle spielt, sondern Du immer wenn Soc < 99% und EVCS_Status ungleich 3 ist, 1600 an Deine mqtt Node senden willst füge da eine Change Node ein und setze die payload einfach auf 1600.
-
-
@hape1 genau - nun sollte immer 1600 geschickt werden, solange die Bedingungen für den unteren Ast erfüllt sind. Bei über 99% und Status 3 dann wird die berechnete Summe geschickt, die Du vorher aus deinen 3 Datenpunkten berechnet hast.
Im Prinzip kannst Du nun die Summenberechnung auch nur auf den Fall durchführen, wenn SoC >99% ist.
-
Jo, jetzt steht im mqtt der Wert 1600, so soll es sein.
Mache jetzt Schluss, muss morgen früh raus.
Nochmal ein ausdrückliches Danke für Deine unerschütterliche Hilfe!
VG
Hape -
@hape1 Dann gute Nacht. Wie gesagt Du musst eine Art Kochbiuch formulieren, wie Du es gerne hättest, ich kann das nicht beurteilen. Ich kann Dir nur helfen, das was DU WILLST versuchen umzusetzen. Du musst Dich halt mal fragen, für was die Summierung überhaupt gut ist, wenn die Batterie voll ist.
Und ich erinnere auch noch an meine Fusszeile - wenn irgendwas kaputt geht, weil das vielleicht überlädt - Du bist dafür verantwortlich - ich kann Dir inhaltlich nicht helfen. Wenn das so OK ist - dann kappe lieber mal den oberen Ast, wenn dadurch die Gefahr einer Überladung erfolgt.
Gerade am Anfang macht es vielleicht Sinn erst mal zu schauen, was in den Debug Nodes rauskommt, bevor man diese Werte dann an irgendwelche Geräte schickt.
-
@mickym Hi, melde mich zurück:
Bin heute mal in Kombination mit dem Energie produzierenden Microwechselrichter und dem super Wetter dazu gekommen, den Flow in Live testen zu können.
Leider funtktioniert das setzen des reduzierten Wertes nicht, bzw. der letzte Payload im flow setzt zwar den Wert, aber der Wert wird nicht in den mqtt-Datenpunkt des Wechselrichters/opendtu übernommen.
Ich mache mal ein paar Screeshots, damit man hoffentlich besser versteht, was ich ich meine:
Hier sieht man im Datenpunkt "limit_nonpersistent_relativ" 100%, aber im "korrospondierenden" Datenpunkt "current_limit_relativ" stehen 10%.
Schreibe ich aber direkt im Datenpunkt "limit_nonpersistent_relativ" den Wert 10%, dann wird dieser auch im"current_limit_relativ" übernommen.
Ich verstehe nicht, wo der Fehler liegt.
Bzw. mir ist jetzt wo ich so schreibe, gar nicht klar, welchen Datenpunkt man zum Regeln der opendtu/Wechselrichter überhaupt benutzten soll?
-
@hape1 Na das kann ich Dir auch nicht sagen welchen Punkt Du beschreiben musst. Aber Du schreibst auch keine Zahl sondern einen Text.
