[gelöst] Poolsteuerung, Anfänger braucht[e] Hilfe
-
So ich habe mal einen kleinen Flow für Dich entworfen mit 3 von mir erstellten Datenpunkten:
Über Filteranlage true/false triggerst Du den Flow.
- Ist auf true gesetzt - wird start auf aktuellen timestamp gesetzt.
- Ist false gesetzt wird start auf 0 gesetzt und zeitraum ermittelt und aufaddiert in laufzeit_tag
- Inject Node setzt laufzeit_tag auf 0 und falls Anlage über Mitternacht läuft setzt auf start aktuellen timestamp
- Noch eine Inject Node, die theoretisch ab 20 Uhr abends alle 15 Minuten prüft ob Laufzeit ausreichend ist - müsste halt noch implementiert werden.
DAs mal so auf die Schnelle
hier zum Importieren:
EDIT Korrigiert:
-
So hier habe ich noch eine ganz andere Variante des Flows die vielleicht wesentlich intuitiver ist und auch nur mit einem Daten punkt für die Laufzeit in min geht.
Hier wird nur noch der Datenpunkt Laufzeit in min also laufzeit_tag2 hochgezählt.
Läuft der Filter sendet die Triggernode einfach jede Minute eine 1 und die wird im Datenpunkt aufsummiert, sodass hier immer die Laufzeit in Minuten jederzeit aktuell sichtbar ist. Das ist sicher von Vorteil auch bei einer Visualisierung.
Läuft der Filter nicht, wird die Triggernode mit msg.reset einfach gestoppt. Bei Tageswechsel wird der Punkt einfach auf 0 gesetzt.
Eigentlich gefällt mir diese Umsetzung besser.
Du siehst es führen viele Wege nach Rom - äh zum Ziel.
EDIT: Nochmal korrigiert.
-
@mickym
ich habe mal ne generelle Frage:
Was gebe ich im Feld "Setze" "flow" "Name" ein? Den Namen des Flows links? Oder benenne ich damit eine x beliebige Variable als flow???und wie sieht man den Switch Node richtig?
Eingang ist zu Eigenschaft???
Also hier Wassertemperatur ist 10°C <= Solartemp, oder gerade anders herum? Probiere bis es richtig schaltet, aber so richtig dahinter bin ich noch nicht gekommen.
Danke un LG Torsten
-
- Ja Du gibst den Namen einer FLOW-Variablen ein. Es ist so wie es semantisch da steht:
Setze flow Variable(flow) Temperatur_Soll auf den Wert der Nachrichteneigenschaft (msg) payload.
- Wenn die Switch Node durch eine Nachricht angetriggert wird vergleicht sie die Eigenschaft mit den darunter liegenden Werten. Im obigen Screenshot wird Deine Nachricht an den Ausgang weiter geleitet - je nachdem welchen Wert Deine flow Variable Solartemp hat. Also hat mit dem Wert Deiner Nachricht gar nichts zu tun.
Die oben abgebildete Switch macht gar keinen Sinn, weil die Nachricht sofern sie <= 10 ist immer an Ausgang 1 geleitet wird. Ist sie hingegen > 10 wird sie gar nicht mehr weitergeleitet bzw. reagiert in Deinem Fall unerwartet.
Um die Bedingung auf einen Bereich einzuschränken musst Du die switch Node umkonfigurieren:
Wenn Du es so konfigurierst wie in Deinem Fall - und ich wende es mal auf eine Payload an und Du hast "alle Regeln überprüfen an" -
dann kommt die Nachricht bei einer 9 an beiden Ausgängen heraus:
Nur wenn Du "Nach erster Übereinstimmung stoppen" setzt kommt bei 9 nur am 1. Ausgang was raus.
Aber nochmal - in der Eigenschaft steht mit welche Eigenschaft Du mit welchen Bedingungen vergleichst.
Also Du vergleichst nicht die Wassertemperatur (gehe mal davon aus, dass das Deine msg.payload ist), sondern leitest die Nachricht in Abhängigkeit des Zustandes Deiner Flow Variablen flow.Solartemp. Wolltest Du Deine payload mit Deiner flow Variablen Solartemperatur vergleichen, so kannst Du das ja nur relativ tun, in dem Du sagst msg.payload kleiner als flow.Solartemperatur. Damit vergleichst Du aber nicht mehr mit konstanten Werten:
-
@mickym Blöd, was ich eigentlich erreichen wollte ist eine Schalthysterese...
-
@schneidy76 Na das passt schon - nur musst Du Deine Bedingungen dann halt ausschließlich setzen.
Die Bereiche sollen sich nicht überschneiden.
Also Ausgang 1 bei >= 10 und Ausgang 2 bei <8. Dazwischen mache nichts.
-
@mickym also so?
-
-
@mickym funktioniert nicht, ich glaube wir reden aneinander vorbei:
- Heizen aktiv true: wenn Wassertemperatur 1 Grad unter Soll liegt
- Heizen aktive false: wenn Wassertemperatur 2 Grad über Soll liegt
-
@schneidy76 Du kannst die Eigenschaft entweder mit konstaten Werten vergleichen - oder in Deinem Fall soll ja gleichzeitig mit einer Flowvariablen gerechnet werden.
Es gäbe nun 2 Möglichkeiten - entweder Du setzt 2 weitere Flowvariablen in einem Flow als Grenzen.
Also Heizen_Schalten = Flow Soll_Temp - 1 oder Heizen_Abschalten = Flow Soll_Temp + 2. Dann machst Du 2 switch Nodes in dem Du die payload (Deine aktuelle Wassertemperatur) gegen einmal oberer und untere Grenze laufen lässt.
Falls ich Dir diese Variante zeigen soll - dann musst Dich nochmal melden.Oder man macht es mit gleichzeitiger Berechnung in dem man die Wahrheit auf einen richtigen JSONATA Ausdruck überprüft - also gleichzeitig rechnen lässt:
Zur Illustration habe ich Deine Flow Variable Soll_Temperatur mal auf 20 gesetzt:
Dann mal getestet - den "Mache Nichts Ausgang" kannst wieder weg machen - diente nur zur Illustration:
Da Du vergleichen und gleichzeitig rechnen willst - kannst Du auswerten, ob ein JSONATA Ausdruck richtig ist:
Hier mal die Change Node zum Import:
[ { "id": "ded0ed78.66122", "type": "switch", "z": "6e170384.60c96c", "name": "", "property": "payload", "propertyType": "msg", "rules": [ { "t": "jsonata_exp", "v": "payload < $flowContext('Soll_Temperatur') - 1", "vt": "jsonata" }, { "t": "jsonata_exp", "v": "payload >= $flowContext('Soll_Temperatur') + 2", "vt": "jsonata" }, { "t": "else" } ], "checkall": "true", "repair": false, "outputs": 3, "x": 2030, "y": 4340, "wires": [ [ "e145cadc.4fe838" ], [ "90889703.c5e7e8" ], [ "edec846e.7f4838" ] ] } ] -
@mickym jetzt scheint es zu funktioniere. Danke
Bin auch unter anderen darüber gestolpert, dass eine Änderung an der Soll Temperatur natürlich keine sofortige Änderung am Flow auslöst. Er wird von der trägen Wassertemperatur getriggert, ist ja auch sinnvoll.Kann man trotzdem den Trigger irgendwie kombinieren? Oder wenigstens periodisch anstoßen?
-
@schneidy76 Ich halte es auch für sinnvoll, dass nur die Wassertemperatur triggert, warum willst Du das periodisch anstoßen, wenn sich eh nichts ändert? - Verbraucht doch nur sinnlos - Resourcen am Rechner.
Grundsätzlich kannst Du natürlich manuell über die Kombi Inject-Node und iobroker Get Node den Flow antriggern. Wenn es sein muss, dann halt auch über die Inject Node periodisch, das habe ich Dir ja in dem Flow zur Laufzeit mehrfach gezeigt.
Um den Flow jedoch zu testen nehme ich immer die Inject Node - dafür ist sie da, um selbst über die Taste zu triggern.Und natürlich könntest Du auch über den Datenpunkt im iobroker triggern, wenn dieser Schreiben zulässt.
Und final kannst Du natürlich auch über eine Änderung der Solltemperatur antriggern. Die Solltemperatur mit einer iobrokerIn triggern lassen und die Wassertemperatur über iobrokerGet holen. Alles möglich!
Generell bietet sich hierfür die Huckepack Methode - also ohne Flowvariable an.
Nehmen wir mal an Du hast 2 Datenpunkte (ist= Wassertemperatur, soll = Solltemperatur).
Dann zeig ich Dir mal eine Flow - indem Du beide Werte im msg. Objekt mitschleifst im nächsten Flow.
-
So hier alles ohne Flowvariable - in dem ich die Werte im Objekt mitschleife:
Statt setze msg.ist bzw. msg.soll müsste hier eigentlich bewege stehen - da ich die orginäre payload Eigenschaft nach der Change Node nicht mehr vorhanden ist!
Damit wird das Ganze ohne Flowvariablen realisiert und kann sowohl von Änderungen der Wasser- (=IST) als auch der Soll- (SOLL) Temperatur getriggert werden.
Beide Werte als Eigenschaften im Nachrichtenobjekt mitgetragen als msg.ist bzw. msg.soll und können dann im switch Node direkt miteinander verglichen werden.
Die switch Node vereinfacht sich dann wie folgt:
Bei einem JSONATA Ausdruck wird übrigens die Eigenschaft im switch Node völlig ignoriert. Die Nachrichten werden immer dahin geschickt dessen JSONATA Ausdruck "true" ergibt.
In der Heizungs (Debug Node) siehst Du als Ergebnis das gesamte Nachrichtenobjekt:
Die payload (true oder false), die Du an Deine iobroker Out Node schickst.
Und die Ursprungswerte Die aus der IST und SOLL Node stammen. Das meinte ich mit Huckepack.
Hier wieder der Flow zum Import:
-
@mickym Ich habe beide Varianten gewählt, die Regelung lasse ich so. Für die Solarunterstützung verwende ich die zweite Version.
Mittlerweile sind noch einige Abhängigkeiten dazu gekommen.
Bin überrascht, was man mit Node Red so alles anstellen kann.Ich würde jetzt für die Restlaufzeit der Pumpe deinen Flow zur Laufzeit hernehmen und einfach rückwärts rechnen. Oder?
Was mir allerdings aufgefallen ist, der stand heute Vormittag auf -72.Du setzt hier mehrmals -1 in die msg, warum?
VG Torsten
so sieht es derzeit aus:
-
@schneidy76 sagte in Poolsteuerung, Anfänger braucht Hilfe:
@mickym Ich habe beide Varianten gewählt, die Regelung lasse ich so. Für die Solarunterstützung verwende ich die zweite Version.
Mittlerweile sind noch einige Abhängigkeiten dazu gekommen.
Bin überrascht, was man mit Node Red so alles anstellen kann.Ich würde jetzt für die Restlaufzeit der Pumpe deinen Flow zur Laufzeit hernehmen und einfach rückwärts rechnen. Oder?
Was mir allerdings aufgefallen ist, der stand heute Vormittag auf -72.Du setzt hier mehrmals -1 in die msg, warum?
Nun dann musst Du bei Deinen iobroker in-Nodes entweder setzen, dass die nur Senden dürfen, wenn sich der Wert ändert oder Du klemmst noch eine rbe Node zwischen Deinen UND Baustein und der "switch" Node läuft oder läuft nicht.
Wie Du richtig erkannt hast wird bei jedem "false" - 1 gesetzt und beim Tageswechsel.
Der Grund ist wesentlich simple - um eine kleine Ungenauigkeit von EINER Minute auszugleichen.
Die trigger Node fängt ja sobald der Filter läuft gleich zu Beginn eine 1 zu schicken und dann jede weitere Minute wieder eine 1. Beim Start ist also bereits 1 Minute vergangen in der Zählung, obwohl das erst gestartet ist.
Beginne ich bei - 1 und die Filter schaltet ein - wird sofort auf 0 gesetzt (initiales 1) und somit die erste 1 ignoriert und erst nach Ablauf einer Minute steht der Zähler auf 1. Deshalb wird auch beim Ausschalten auch wieder 1 abgezogen, damit sich das beim nächsten Einschalten wieder ausgleicht.Alles andere, also die erste 1 zu ignorieren würde den Flow unnötig komplizieren und Du müsstest es mit einem kleinen Programm in einer Function Node machen.
Also nachdem Du mehrere Trigger hast - hänge eine rbe nach Deiner UND Node dazwischen, so dass nur noch Zustandsänderungen durchkommen.
Ja mit NodeRed kann man sehr viel und vor allem in meinen Augen übersichtlich machen. Deswegen bin ich auch so ein FAN.
Du wirst sehen, wenn Du NodeRed als Logikmaschine einsetzt wirst Du teilweise noch mehr machen können durch die Entwicklung einer großen FAN Gemeinde. Die Eingangsnodes sind im Prinzip wie Adapter unter iobroker gleich zusetzen. Ich arbeite zum Beispiel gerade an einer SNMP Überwachung meiner Raspberries. Erst habe ich den SMNP Adapter in iobroker versucht, der wurde aber schon seit über 2 Jahren nicht mehr gepflegt und ich bekam einfach nicht alle Werte. Nun mache ich alles mit SNMP Nodes in NodeRed und funktioniert prima auch mit Tabellen etc.============================================================================
So nun zu Deinem Problem der Restlaufzeit - das ist nicht so banal wie es logisch aussieht.
Im Prinzip hast Du eine einfache und eine komplexere Möglichkeit. Das Runterrechnen ist relativ kompliziert.Das Einfachste wäre, wenn Du mal Folgendes festlegen würdes.
Nehmen wir an die Pumpe/Filter müsste pro Tag 2 Stunden laufen und sie wäre den ganzen Tag noch gar nicht gelaufen. Dann würde ich einfach eine Flow über eine Inject Node ab 21:45 anstossen, der alle 10 Minuten überprüft, ob die Mindestlaufzeit erreicht ist indem ich Laufzeit - 120 > oder >= 0 abprüfe. Jedenfalls brauchst Du ja einen externen Zeittrigger - da kannst Du dann ja keine Temperatur mehr verwenden.
Ansonsten muss man halt wie Du sagst den Zeitpunkt des Tageswechsels minus Laufzeit berechnen - dann würde ich mir aber noch den EZTIMER installieren, der Dir dann einen Trigger zur gewünschten Uhrzeit liefern kann.
Immer - >Trigger -> Verarbeitung -> Steuerung. Das ist das A und O.
-
@mickym jepp den rbe habe ich jetzt schon mehrfach benötigt.
Hat ein wenig Suche gekostet, aber wenn man weiß wonach man suchen muss..
Die eine Minute Ungenauigkeit ist nicht so wild...Für die Nachlaufzeit habe ich folgenden Schnipsel gebastelt:
und das dann hier verknüpft
Funktioniert und war easy...
Warst ein guter Lehrer!!!
-
Hi, da habt Ihr ja ein schönes Projekt umgesetzt, von dem Einige bestimmt noch was lernen können. Und Alles gut erklärt. Gefällt mir.
Ich selber würde da zwar keine Logic Nodes verwenden, sondern das mit den Standard Nodes lösen, aber da hat jeder seinen eigenen Weg und seine Vorlieben. -
@schneidy76 sagte in Poolsteuerung, Anfänger braucht Hilfe:
....Warst ein guter Lehrer!!!
Na dann hat sich das Ganze schon gelohnt. Ich habe Deinen Flow nicht mehr importiert, aber ich denke Du kommst ja jetzt alleine zu Recht. Ich denke das Prinzip des Nachrichtenflusses hast Du verstanden.
-
@schneidy76 Hab mir nur mal von der Logik Deine Laufzeitüberprüfung angeschaut. Meines Erachtens läuft ja die Laufzeitüberprüfung dauernd und nicht erst ab 20 Uhr.
Deine trigger Node sendet in Dauerschleife ja alle 1 Min.
In meinen Augen ist dann nach dem initialen Anstoß am 1 Tag 20 Uhr, dann läuft die Pumpe aber nach jedem zuücksetzen die 300 min runter. Also ab 0 Uhr.
Im Übrigen tust Du den Leuten beim Import einen Gefallen - wenn Du den Export in Code Tags packst </> dann können die das mit Select All einfacher in die Zwischenablage kopieren.
Ich würde mir mal Überlegen ob da Deine Logik noch einen kleinen Fehler aufweist.
In dem Fall wäre es sogar einfacher - Du schmeißt die trigger Node weg - und lässt die Inject Node ab 20 Uhr bis 0 Uhr in 1 Minuten Intervall prüfen. Dann bist wenigstens sicher, dass ausserhalb dieses Zeitraums diese Schleife nicht mehr läuft.
-
@schneidy76 Und das das Schalten der Homematic Aktoren nur mit command geht, ist auch klar ....
Der Unterschied zwischen command und value ist, dass bei command der Wert ohne ACK (also bestätigt = nein) und bei value der Wert mit ACK (also bestätigt = ja) geschickt wird.
Datenpunkte, bei den ein Adapter die Hardwaresteuerung übernimmt, darf man nie ein ACK mitgeben, da diese 1. nur noch Datenpunkten suchen, deren Werte nicht bestätigt sind und diese Adapter bestätigen den Datenpunkt selbst, wenn sie vom Aktor eine positive Rückmeldung bekommen.
Datenpunkte, die jedoch nicht von einem Hardwareadapter bestätigt werden müssen, wie Punkte unter 0_userdata.0 schreibst Du mit value (grün) also mit ACK, da es hier ja niemand mehr gibt, der die Ausführung bestätigt.
Das mit dem ACK (also bestätigt true oder false) hat nichts mit Node Red zu tun sondern ist ein Basismechanismus des iobrokers.
