NEWS
[gelöst] Poolsteuerung, Anfänger braucht[e] Hilfe
-
@schneidy76 Nun eine Counter Node - ist nicht im Standard enthalten. Falls Du diese Node meinst, dann halte ich die für eher ungeeignet. Die zählt ja nur je nach Nachrichteneingang entweder rauf oder runter - aber Du willst ja zeitliche Steuerungen.
Dann solltest Du halt streng nach der Ein- und Ausgabelogik vorgehen. ;)
Und dann ist Deine Logik noch nicht ganz klar bzw. es fehlt noch was, aber dazu später.Also was haben wir als Eingangstrigger auf der linken Seite:
- Den Schaltzustand der Filteranlage bzw. der Heizung (true oder false) sowie ich mich erinnere.
- Den Zeittrigger um 0 Uhr, um die Laufzeit zurückzusetzen.
- Einen weiteren Zeittrigger, der am Abend (ist das ein fixer Zeitpunkt ??) überprüft, ob die Laufzeit erreicht wurde oder nicht.
- Oder eine periodische Überprüfung am Abend - dann empfehle ich Dir den Light-Scheduler zu installieren - den liebe ich. (das wurde mir aus der Aufgabenstellung nicht klar. ;) )
Dann brauchst Du ja ein paar Variablen/Datenpunkte zum Speichern:
- Den Startzeitpunkt an dem die Zeitperiode beginnt zum Speichern - man kann auch den Timestamp der letzten Änderungen des Heizungsdatenpunktes verwenden.
- Die aufsummierte Zeit zu speichern.
Nachdem Du es ja persistent machen willst (was sinnvoll ist, gerade wenn man den Adapter oder den iobroker mal neustarten muss), würde ich halte Datenpunkte anlegen, in den Du alles zwischenspeicherst.
Wenn die normale Logik funktioniert, dann solltest Du eben die Szenarien durchgehen, dass der iobroker neugestartet wird, während die Heizung läuft oder zwischenzeitlich ausgeschaltet wurde, während der iobroker gestoppt war.
Dazu muss man nur bissi Vorstellungskraft walten lassen.
Ich hoffe Dir damit Anregungen zum Start gegeben zu haben.
@mickym Huhu, ja Du hast Recht.
Zum ersten, genau diesen Node meinte ich.
Finde den auch nicht so ganz passend...
Thema Trigger (in Deiner Reihenfolge)- Ich setze die Filteranlage immer wenn nötig auf true, auch wenn ich die Wärmepumpe und Filteranlage über einen Parallelkontakt zwangsläufig parallel schalte. Sonst könnte die WP Schaden nehmen. Also nehmen wir die Filteranlage als Trigger.
- 0:00 Uhr rücksetzen - Check
- nein nicht fix, nennen wir ihn „Heizen nicht mehr sinnvoll“ - lassen wir mal so stehen. Ich habe eine Wetterstation da in der Nähe, eventuell nehme ich die Sonneneinstrahlung als Referenz, oder das Wasser ist warm genug. Punkt für die Ferne.
Glaube, wenn das fertig ist, wird das super. Stelle dann alles hier rein. 😁
Raspberry Matic (RP3), LIVE PV Monitoring mit Smartmeter, Poolsteuerung mit NodeRed, KNX Ausbau (ersetzt stückweise HM & klassische Installation), ioBroker Multihost (RP4 &RP2), Visu mit VIS
-
@mickym Huhu, ja Du hast Recht.
Zum ersten, genau diesen Node meinte ich.
Finde den auch nicht so ganz passend...
Thema Trigger (in Deiner Reihenfolge)- Ich setze die Filteranlage immer wenn nötig auf true, auch wenn ich die Wärmepumpe und Filteranlage über einen Parallelkontakt zwangsläufig parallel schalte. Sonst könnte die WP Schaden nehmen. Also nehmen wir die Filteranlage als Trigger.
- 0:00 Uhr rücksetzen - Check
- nein nicht fix, nennen wir ihn „Heizen nicht mehr sinnvoll“ - lassen wir mal so stehen. Ich habe eine Wetterstation da in der Nähe, eventuell nehme ich die Sonneneinstrahlung als Referenz, oder das Wasser ist warm genug. Punkt für die Ferne.
Glaube, wenn das fertig ist, wird das super. Stelle dann alles hier rein. 😁
@schneidy76 Gut dann kannst ja loslegen. ;)
2 Datenpunkte anlegen - einen für aktuelle Laufzeit, einen für Laufzeit am Tag.
- iobroker In Node des Datenpunktes der Filteranlage triggert - bei True - Beginn der aktuellen Laufzeit, bei false auf 0 setzen und Zeitdifferenz zur aktuellen Zeit in Datenpunkt für die Tageslaufzeit aufsummieren.
- Inject Node mit Tageswechsel setzt Tageslaufzeit auf 0.
- Periodisches Prüfen ob sinnvoll - dann lightscheduler Node installieren. ;)
Bastel mal schnell was mit 3 Datenpunkten (Filteranlage - true/false, Start aktuelle Laufzeit, Tageslaufzeit).
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@schneidy76 Gut dann kannst ja loslegen. ;)
2 Datenpunkte anlegen - einen für aktuelle Laufzeit, einen für Laufzeit am Tag.
- iobroker In Node des Datenpunktes der Filteranlage triggert - bei True - Beginn der aktuellen Laufzeit, bei false auf 0 setzen und Zeitdifferenz zur aktuellen Zeit in Datenpunkt für die Tageslaufzeit aufsummieren.
- Inject Node mit Tageswechsel setzt Tageslaufzeit auf 0.
- Periodisches Prüfen ob sinnvoll - dann lightscheduler Node installieren. ;)
Bastel mal schnell was mit 3 Datenpunkten (Filteranlage - true/false, Start aktuelle Laufzeit, Tageslaufzeit).
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:
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
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.
-
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
Raspberry Matic (RP3), LIVE PV Monitoring mit Smartmeter, Poolsteuerung mit NodeRed, KNX Ausbau (ersetzt stückweise HM & klassische Installation), ioBroker Multihost (RP4 &RP2), Visu mit VIS
-
@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:
-
- 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...
Raspberry Matic (RP3), LIVE PV Monitoring mit Smartmeter, Poolsteuerung mit NodeRed, KNX Ausbau (ersetzt stückweise HM & klassische Installation), ioBroker Multihost (RP4 &RP2), Visu mit VIS
-
@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.
-
@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
Raspberry Matic (RP3), LIVE PV Monitoring mit Smartmeter, Poolsteuerung mit NodeRed, KNX Ausbau (ersetzt stückweise HM & klassische Installation), ioBroker Multihost (RP4 &RP2), Visu mit VIS
-
@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" ] ] } ] -
@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 :clap:
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? :grinning:
Raspberry Matic (RP3), LIVE PV Monitoring mit Smartmeter, Poolsteuerung mit NodeRed, KNX Ausbau (ersetzt stückweise HM & klassische Installation), ioBroker Multihost (RP4 &RP2), Visu mit VIS
-
@mickym jetzt scheint es zu funktioniere. Danke :clap:
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? :grinning:
@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.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@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. :grinning: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:
Raspberry Matic (RP3), LIVE PV Monitoring mit Smartmeter, Poolsteuerung mit NodeRed, KNX Ausbau (ersetzt stückweise HM & klassische Installation), ioBroker Multihost (RP4 &RP2), Visu mit VIS
-
@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. :grinning: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. :grinning: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.
-
@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. :grinning: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. :grin: 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!!! :muscle: :stuck_out_tongue_winking_eye:
Raspberry Matic (RP3), LIVE PV Monitoring mit Smartmeter, Poolsteuerung mit NodeRed, KNX Ausbau (ersetzt stückweise HM & klassische Installation), ioBroker Multihost (RP4 &RP2), Visu mit VIS
-
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. -
@mickym jepp den rbe habe ich jetzt schon mehrfach benötigt. :grin: 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!!! :muscle: :stuck_out_tongue_winking_eye:
@schneidy76 sagte in Poolsteuerung, Anfänger braucht Hilfe:
....Warst ein guter Lehrer!!! :muscle: :stuck_out_tongue_winking_eye:
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. ;)
Support us
682
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge