Hilfe bei debuggen einer übernommenen Funktion
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ok, da werde ich mich morgen früh direkt ransetzen.
Dann kann ich die Logik natürlich entsprechend für die Chlor-Pumpe übernehmen und anpassen!!
Was dann noch fehlt, ist das periodische Ein- und Ausschalten der Dosier-Pumpen in Abhängigkeit der über das Dashboard eingestellte Lauf- und Pausenzeit, damit das Becken nicht sinnlos überdosiert wird.
Kannst du das ganz kurz umreißen? Im Urpsrungs-Skript wurde das (natürlich) wieder mit Funktions-Nodes gelöst.
Ich hab den Flow nochmal am Anfang verändert und auch nur die Dosierpumpenansteuerung gefiltert, wenn der Zeitplan aktiv ist, sonst kann das mit dem Ausschalten Konfliktsituationen ergeben.
Was ich aber hier schon sehe mit count Down Nodes etc - finde ich schon wieder Mist. Sowas macht man mit trigger Nodes - die schon an Board sind.
Sprich Du überprüfst die Laufzeit am Anfang und dann lässt Du einfach die Pumpe eine von Dir definierte Zeit laufen.
Während dieser Zeit würde ich mit einem trigger Block auch noch dafür sorgen, dass während der Laufzeit der Pumpe keine weitere Nachricht ankommt.Sprich um das jetzt konkreter zu machen und dieses Wirr-Warr da oben zu entwirren.
Prüfst Du also erst für die ph Pumpen mit Pausen und Laufzeiten.
Ich hab hier mal einen Vorschlag - ohne Fachwissen natürlich.
Die Parameter im Kontext musst Du natürlich selbst setzen.
Jedenfalls finde ich diesen Flow wesentlich übersichtlicher, als dieses Wirr-warr da oben und mit den function Nodes als Black-Boxes.
Hier mal alles zum Import:
-
Guten Morgen,
das mit den Variablen habe ich soweit umgesetzt.
Deinen neuen Flow hab ich auch schon geladen, was mir da direkt auffällt, dass du die "Vergleiche" per JSONata machst.
Ich hatte gehofft, meine Bedingungen so abzufragen.
-
Wenn ich deinen neuen Flow richtig interpretiere, wird nach Ablauf der Laufzeit ein "False" an die Pumpe gesendet und dann über den anderen Trigger die Pausenzeit abgewartet, richtig?
Dann hast du ja noch das "Trigger & Block" gesetzt, welche nur ein "False" ausgeben würde, wenn ich den "manuellen Reset" nutze.
Nutzt dieser Block dann das "true" der Bedingungen und wenn da ein False wäre, würde die Pumpe noch für die eingestellte Zeit laufen und dann nicht mehr, weil am Trigger & Block kein True mehr durchkommt? -
Egal, ob ich deine Change- und Switch-Node für die max. Laufzeit nutze oder auch meine, bei beiden wird kein True ausgegeben.
Die Tageslaufzeit steht auf 0 Minuten und die max. Tages-Laufzeit auf 5 Min. Damit wäre ja eigentlich die Bedingung erfüllt.
-
Und dann (mutmaßlich zum Schluss) stehe ich noch vor der Herausforderung,
die einstellbaren Parameter ohne Function-Node zu erstellen.
So ist es im eigentlichen Skript:
Ich glaube auch verstanden zu haben, was dort gemacht wurde, erholt sich aus der Flow.Variable Ph-Parameter die einzelne Werte, schreib die in das jeweilige msg.payload, dieser payload wird über das Dashboard geändert und mit der zweiten Function-Node wieder ins Array geschrieben.
Ich gehe davon aus, dass man fürs zurückschreiben wieder JSONata nutzen muss, da wäre mir aber die Syntax nicht klar.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Guten Morgen,
das mit den Variablen habe ich soweit umgesetzt.
Deinen neuen Flow hab ich auch schon geladen, was mir da direkt auffällt, dass du die "Vergleiche" per JSONata machst.
Ich hatte gehofft, meine Bedingungen so abzufragen.
Ja das geht auch prinzipiell, allerdings muss der variable Teil in dem Vergleich oben abgefragt werden.
- das geht auf jeden Fall:
- das geht nicht - bzw. Du musst das umdrehen:
das habe ich gerade getestet (damit kannst Du die ChangeNode) weglassen in meinem Flow:
Hier habe ich es mal getrennt getestet:
Kannst ja selbst so ausprobieren:
3. geht schon - aber willst Du eine Nachrichteneigenschaft abfragen?
- Sollte auch gehen, aber ansonsten wie 2.
Also im Prinzip geht das alles, wie Du es Dir vorstellst. Bei Vergleichen innerhalb von Kontextvariablen würde ich aber ggf. testen.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Egal, ob ich deine Change- und Switch-Node für die max. Laufzeit nutze oder auch meine, bei beiden wird kein True ausgegeben.
Die Tageslaufzeit steht auf 0 Minuten und die max. Tages-Laufzeit auf 5 Min. Damit wäre ja eigentlich die Bedingung erfüllt.
Das geht aber musst ggf nochmal Deinen Kontext überprüfen:
Dann über switch Node direkt oder über Change Node.
-
@bf0911 Um Dein Dashboard zu intialisieren brauchst Du das topic nicht. Dieser Mensch scheint irgendwie nicht begriffen zu haben, dass man in das topic auch Objekte schreiben kann.
Du lädst Dir einmal den Kontext in eine payload und verteilst das dann über eine Change Node direkt an Dein Dashboard.
Vorher solltest Du aber den Kontext über mqtt bereits eingelesen haben. Also in dem Fall musst Du wohl mit dem retain Flag arbeiten oder Du speicherst grundsätzlich nicht in mqtt sondern im iobroker.Du musst jedenfalls kein JSONATA verwenden, sondern geht alles direkt - so wie auch bei den switch Nodes, wie unten beschrieben.
Wie gesagt Du musst Dir halt mal überlegen, ob Du für die Speicherung mal generell mqtt oder den iobroker verwendest.
Ich hab mal nur als Parameter für Dein Dashboard den Grenzwert und die max. Tageslaufzeit genommen.
Ist also sehr einfach, ohne JSONATA und alles.
Du holst Dir also den ganzen Kontext in Dein Nachrichtenobjekt und initialisierst dann einfach die Inputfelder mit den Eigenschaften deines Objektes ph-Parameter. Du musst halt nach dem Neustart warten bis Dein Kontext initialisiert ist (bei mqtt durch das Retain oder bei Iobroker In durch das sofortige Auslesen).
Ich habe deshalb mal den Init auf 10s gestellt. Eventuell brauchst noch länger:
Wie Du siehst kannst Du die Ausgabe des Dashboards direkt in die Parameter im Flowkontext schreiben,
Eigentlich doch sehr easy und verständlich. Hier der Flow:
-
Danke für deine Ausführungen.
Ich hatte es mit der Nachrichten-Eigenschaft so verstanden, dass ich dafür z. B. False oder True von den Pumpen abfragen kann.
Deswegen msg.chlorpumpe.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ich hatte es mit der Nachrichten-Eigenschaft so verstanden, dass ich dafür z. B. False oder True von den Pumpen abfragen kann.
Na wenn Du es vorher mit einer iobroker-get in Dein Nachrichtenobjekt geholt hast, dann schon. Alles gut. Wie gesagt, wenn du die Parameter nicht mehr brauchst oder die payload nicht mehr brauchst, dann kannst auch die direkt verwenden.
Aber ich denke Du bist nun soweit - dass Du meine Hilfe nicht mehr brauchst, bei solchen Dingen.
Wenn Du Dir nun Dein Gesamtwerk betrachtest, ist das nicht viel übersichtlicher geworden?
-
@bf0911 Wie gesagt, ich würde mir in Deinem Fall überlegen, ob Du überhaupt mit mqtt arbeitest oder mqtt nicht nur dafür verwendest ggf. Deine Hardware zu steuern.
Wie bist Du überhaupt darauf gekommen, mqtt zu verwenden? - Jetzt sag nicht, weil das Skript das gemacht hat. Ja wenn man kein iobroker hat, dann nimmt man in NOdeRed Standalone Konfigurationen mqtt - dann muss man ggf. mit retain Flags arbeiten oder mit einem Filekontext, der einen Neustart überlebt. In Deinem Fall würde ich aber alles in Datenpunkten speichern. Du musst nur die Objekte als JSON Strings abspeichern und wieder restaurieren.
Im Endeffekt glaube ich, dass Dir die Zeit Dich in NodeRed einzuarbeiten weniger Zeit gekostet hat, als nach fertigen Skripten zu suchen.
-
Ja, erstmal ganz lieben Dank für die Zeit und Mühe.
Eine abschließende Frage hab ich noch, du setzt in dem Beispiel "Dashboard" die flow.Variablen. Die habe ich bzw. wir ja schon an einer anderen Stelle gesetzt. Fehlt da dann nicht noch das zurückschreiben per MQTT in das Array?
Ja, mein Flow ist wirklich total übersichtlich geworden. Und dass ist für mich das wichtigste, ich weiß was wann wo passiert und kann dies alles nachvollziehen.
Ja, doch richtig. Weil es so vorgeben war. Ich hatte ja die Hoffung, nur ein, zwei Nodes anpassen zu müssen, damit das Skript läuft.
Ich nehme mal an, dass ich mit iobroker-out genau so Arrays schreiben kann wie per MQTT? Also natürlich, wenn der Datenpunkt vorhanden ist.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ja, erstmal ganz lieben Dank für die Zeit und Mühe.
Eine abschließende Frage hab ich noch, du setzt in dem Beispiel "Dashboard" die flow.Variablen. Die habe ich bzw. wir ja schon an einer anderen Stelle gesetzt. Fehlt da dann nicht noch das zurückschreiben per MQTT in das Array?
Ja da hast Du Recht, aber das würde ich nur ein einziges Mal machen im Flow. Wird natürlich bei jeder Änderung das ganze Objekt zurückgeschrieben. (aber du siehst wieviel einfacher das ist).
In dieser letzten Change Node holst Du Dir einfach das ganze Objekt nochmal als payload in das Nachrichtenobjekt.
Ja, mein Flow ist wirklich total übersichtlich geworden. Und dass ist für mich das wichtigste, ich weiß was wann wo passiert und kann dies alles nachvollziehen.
Perfekt!
Und bis auf wenige Regeln, in den Du JSONATA verwendet hast, hast Du doch so gut wie keinen Code geschrieben? -´Oder siehst Du das anders?Ja, doch richtig. Weil es so vorgeben war. Ich hatte ja die Hoffung, nur ein, zwei Nodes anpassen zu müssen, damit das Skript läuft.
Ja aber Du hättest den Flow nicht verstanden, so wie jetzt und ausserdem kannst Du nun in Zukunft Flows alleine schreiben und suchst Dir nicht mehr was zusammen .
Ich nehme mal an, dass ich mit iobroker-out genau so Arrays schreiben kann wie per MQTT? Also natürlich, wenn der Datenpunkt vorhanden ist.
Ja das einzige was der iobroker Nodes nicht können, gleich die Objekte als JSON Strings zu schreiben bzw. zu verwandeln.
Wenn Du also Dein PH_Parameter als Ganzen in einen iobroker-Datenpunkt schreiben willst, dann musst Du den vorher in einen JSON-String umwandeln.
Den Datenpunkt im iobroker gibst halt auch den Datentyp JSON
Sollen die Daten dann automatisch eingelesen werden - kannst Du das in der iobroker-IN Node konfigurieren:
Hier nochmal zum Import:
Achso ein Fehler habe ich noch in der iobroker-Out node gemacht.
Wenn Du unter 0_userdata.0 schreibst, dann gibts ja keine Hardware, die diesen Wert in Empfang nimmt. Hier als ein ACK=true schreiben (also einen value und KEIN command).
Wenn Du hingegen Deine Pumpen steuerst und direkt in einen Adapterdatenpunkt schreibst, zum Steuern, dann Type command (ACK=false) verwenden. -
Ja, super. Vielen Dank. Ich habe jetzt alle MQTT-In und Out gegen Json und Iobroker-in und out getauscht.
Da werden auch schon die Daten in die Datenpunkte geschrieben. Das scheint zu klappen.
Nun muss ich das noch mit dem Dashboard verstehen und umsetzen.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Nun muss ich das noch mit dem Dashboard verstehen und umsetzen.
Na da brauchst dann die Init Node nicht mehr sondern konfigurierst Dir die iobroker-In Node so, dass die Parameter direkt eingelesen werden:
-
-
@bf0911 Einmal musst natürlich auch das komplette Objekt nach dem Einlesen in deine Flowvariable einlesen, das hatte ich noch vergessen:
Ich frage mich nur im Nachhinein, warum Dein Skript alles mit globalen Variablen und x unterschiedlichen Flows gemacht hat. Wenn ich mir das bis jetzt so anschaue
ist der Flow doch nicht so groß und komplex??
-
Warum globale Variable etc benutzt wurden kann ich dir nicht sagen.
Mein Flow ist etwas größer als deiner bzw. wird noch größer wegen dem Dashboard usw
Ich hab den Flow mit dem Dashboard zu übernommen, aber es lassen sich keine Zahlen einstellen
Das springt immer -
@bf0911 Na wenn du es wirklich übernommen hast, dann sollte es nicht passieren.
Schau mal ob du die Nachrichten nicht durchreichst?
das muss natürlich deaktiviert sein.
Ggf. musst DU natürlich bei ALLEN Dashboard Feldern schauen, dass Du die Nachrichten nicht durchreichst!!! (Also auch nicht bei Schaltern(switches) etc.)
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ich hab den Flow mit dem Dashboard zu übernommen, aber es lassen sich keine Zahlen einstellen
Das springt immerUnd ggf. immer Debug Nodes an die letzte Node vorne und direkt dahinter machen. Prüfen, wenn Du das Kabel vorne trennst, ob es an ankommenden Nachrichten liegt oder nicht. Das ist ja nun das schöne, dass Du sowas gut debuggen kannst.
