NEWS
bshb - Rollladensteuerung mit yhka Homekit
-
@sascho So nun habe ich mal so eine Befehlsqueue realisiert:
Wenn Du über die Inject Nodes wie im vorherigen Post Deine Fenster/Jalousien steuern kannst, dann wäre der nächste Schritt so eine Befehlsqueue mittels einer function Node zu realisieren. Man könnte das ggf. auch ohne function Node machen, aber dann wäre der Flow sehr unübersichtlich.
Die blaue Gruppe - in der ich den Fehler der Velux Nodes nur simuliere, kannst Du dann natürlich weglassen. Ich habe in der Simulationsnode - die Fehlerhäufigkeit mal auf 30% eingestellt, so dass 30% einen Fehler erzeugen.
Wenn Du im Flow die function Node "Befehlsqueue" markierst (orange Linie) und dann auf die Kontextdaten gehst und die Daten aktualisierst, dann siehst Du das die Befehlsqueue quasi leer ist.
Nun drücke ich die Inject-Nodes nach der Reihe der IDs (also 1,2,3,4,1,2, ...)
Wenn ein Fehler auftritt, bei mir gleich beim ID 1, dann siehst Du in der trigger Node das 1 Nachricht ansteht und diese nach einer Minute die Befehlsqueue erneut triggert.
In der Queue ist immer noch der eine Befehl - der also wegen des Fehlers noch nicht abgesetzt werden konnte.
Das passiert dann solange - bis die Velux Node (wieder verfügbar ist):
Hier ein Beispiel wo die erste ID funktionierte, ID 2 und 3 jedoch nicht - da Velux Node nicht bereit.
In der Befehlsqueue wurden die beiden zwischengespeichert:
Alle Minuten wird nun versucht - die noch voll Queue abzuarbeiten bis die Velux Node verfügbar ist - dann wird die Queue geleert:
Hier wieder mal der View zum Spielen und Lernen. ;)
Der untere Teil der function Node (Befehlsqueue) wird also ausgeführt, wenn die Velux Node im Fehlerzustand ist, ansonsten werden die Befehle nacheinander an die Velux Node über den oberen Ausgang der function Node gesendet.
Du kannst natürlich meine ganzen Debug Nachrichten aus der function Node rauslöschen, so dass der reine Code der function Node nun so aussieht:
var queue = context.get('queue') || []; var isError = false; msg.OK = msg.OK || false; if (msg.payload !== undefined) queue.push(msg); if (msg.error !== undefined) isError = true; if (msg.OK) { queue.shift(); isError = false; } context.set('queue',queue); if (queue.length > 0 && !isError ) { return [queue[0],null]; } else if (isError) { return [null,msg]; }Wow! Jetzt bin ich völlig erschlagen. Ich muss mir das erst mal morgen alles in Ruhe ansehen. Tausend Dank schon mal vorweg! Ich glaube, ich muss Dir mal einen Präsentkorb schicken, bei dem ganzen Aufwand, den Du hier für mich betreibst!
Ich habe gerade das KLR200 in Betrieb genommen, und im KLF200 4 Szenen zu einem Fensterpaar angelernt:
Mit der Scene Node und einer Inject Node kann ich die 4 Szenen ansteuern. Es funktioniert sehr gut.
Die Kür wäre jetzt, wenn ich nur eine Velux Scene Node benötigen würde, indem ich den Szenenindex in der Nachricht mitgebe. Laut diesem Node Guide wäre das doch möglich:
Was muss ich denn da im Topic mitgeben? Ich bekomme nur Fehler gerade.
Das geht doch in die Richtung, wie Du es oben aufgebaut hast - hinter die Dachfenster Funktionen hängen, die dann die Velux Scene Node anspricht.
Btw. Die Scene Node sendet auch Status Meldungen - einige während die Fenster laufen... Evtl. könnte ich mir da die Current, und Remaining/Run Status Meldungen abfangen und so auf die Velux Nodes komplett verzichten :-)
-
Wow! Jetzt bin ich völlig erschlagen. Ich muss mir das erst mal morgen alles in Ruhe ansehen. Tausend Dank schon mal vorweg! Ich glaube, ich muss Dir mal einen Präsentkorb schicken, bei dem ganzen Aufwand, den Du hier für mich betreibst!
Ich habe gerade das KLR200 in Betrieb genommen, und im KLF200 4 Szenen zu einem Fensterpaar angelernt:
Mit der Scene Node und einer Inject Node kann ich die 4 Szenen ansteuern. Es funktioniert sehr gut.
Die Kür wäre jetzt, wenn ich nur eine Velux Scene Node benötigen würde, indem ich den Szenenindex in der Nachricht mitgebe. Laut diesem Node Guide wäre das doch möglich:
Was muss ich denn da im Topic mitgeben? Ich bekomme nur Fehler gerade.Das geht doch in die Richtung, wie Du es oben aufgebaut hast - hinter die Dachfenster Funktionen hängen, die dann die Velux Scene Node anspricht.
Btw. Die Scene Node sendet auch Status Meldungen - einige während die Fenster laufen... Evtl. könnte ich mir da die Current, und Remaining/Run Status Meldungen abfangen und so auf die Velux Nodes komplett verzichten :-)
@sascho Also die Szene IDs sind ja eindeutig. Im Prinzip brauchst Du in den Velux Scenes Node gar nichts eintragen.
Du gibst einfach die ID in das topic im Inject Node ein und fütterst damit die Scenes Node:
Die Zahl hinter der ID ist die Szene ID und nicht die Node ID - wie bei der Velux Node Node. ;)
Aber nicht msg ;) msg.topic =msg.velux... , sondern natürlich als String :
Sowas geht nicht:
Ein Objekt kann keine Doppelpunkte enthalten und Du hast ja in Deiner Inject kein msg.velux Objekt definiert. - Also einfach die Velux Node mit einem msg.topic als normalen String füttern.
Es macht ausserdem in dem unteren Flow keinen Sinn in der Debug Node eine msg.payload abzugreifen, wenn es keine msg.payload gibt
Dann ist es besser Du stellst die Debug Node auf das gesamte Nachrichten objekt um:
-
@sascho Also die Szene IDs sind ja eindeutig. Im Prinzip brauchst Du in den Velux Scenes Node gar nichts eintragen.
Du gibst einfach die ID in das topic im Inject Node ein und fütterst damit die Scenes Node:
Die Zahl hinter der ID ist die Szene ID und nicht die Node ID - wie bei der Velux Node Node. ;)
Aber nicht msg ;) msg.topic =msg.velux... , sondern natürlich als String :
Sowas geht nicht:
Ein Objekt kann keine Doppelpunkte enthalten und Du hast ja in Deiner Inject kein msg.velux Objekt definiert. - Also einfach die Velux Node mit einem msg.topic als normalen String füttern.
Es macht ausserdem in dem unteren Flow keinen Sinn in der Debug Node eine msg.payload abzugreifen, wenn es keine msg.payload gibt
Dann ist es besser Du stellst die Debug Node auf das gesamte Nachrichten objekt um:
-
@sascho Nun - ich finde leider auch nichts genaues
Wenn die Scene Node noch rot ist - dann muss man da was eingeben. Es darf auf KEINEN Fall noch so ein rotes Warndreieck über der Node zu sehen sein und die rot umrandeten Felder müssen ausgefüllt sein.
So wie ich den Text verstehe:
velux:id:<id> scene id for execute. **The settings are ignored.**Du musst in der Szene ID trotzdem in die Node eingeben (auch wenn man das wohl mit dem topic überschreibt) - das darf nicht leer oder rot bleiben. Also gib einfach mal eine Zahl als Szene Index ein und schau - ob Du das mit der Inject Node überschreiben kannst.
-
@sascho Nun - ich finde leider auch nichts genaues
Wenn die Scene Node noch rot ist - dann muss man da was eingeben. Es darf auf KEINEN Fall noch so ein rotes Warndreieck über der Node zu sehen sein und die rot umrandeten Felder müssen ausgefüllt sein.
So wie ich den Text verstehe:
velux:id:<id> scene id for execute. **The settings are ignored.**Du musst in der Szene ID trotzdem in die Node eingeben (auch wenn man das wohl mit dem topic überschreibt) - das darf nicht leer oder rot bleiben. Also gib einfach mal eine Zahl als Szene Index ein und schau - ob Du das mit der Inject Node überschreiben kannst.
Mit der Variante String geht es leider nicht :-(.
Die ersten zwei Versuche mit den Scene IDs 4 und 5 führen zu keiner Reaktion bei KLF200, der dritte Versuche dann mit Scene ID 5 + Number produziert eine Reaktion allerdings keine Bewegung:
Gäbe es evtl. eine Alternative, die Szene über die Velux API + eine Funktion auszulösen? Hier wird das beschrieben (auch wie man die Überlastung des KLF200 verhindern kann):
https://213.136.68.177/topic/14312/adapter-für-velux-klf-200-interface/41?lang=en-GB&page=6
Dies wäre der Code:
Allerdings müsste ich wahrscheinlich die settings.js modifizieren.
-
Mit der Variante String geht es leider nicht :-(.
Die ersten zwei Versuche mit den Scene IDs 4 und 5 führen zu keiner Reaktion bei KLF200, der dritte Versuche dann mit Scene ID 5 + Number produziert eine Reaktion allerdings keine Bewegung:Gäbe es evtl. eine Alternative, die Szene über die Velux API + eine Funktion auszulösen? Hier wird das beschrieben (auch wie man die Überlastung des KLF200 verhindern kann):
https://213.136.68.177/topic/14312/adapter-für-velux-klf-200-interface/41?lang=en-GB&page=6
Dies wäre der Code:
Allerdings müsste ich wahrscheinlich die settings.js modifizieren.
Ich hab's mit der Function + API Node hinbekommen :-)))!!! Ich kann nun über die Inject Node direkt die Szene aufrufen.
Das Programm zum öffnen von Dateien im Terminal des Docker vom IOBroker nennt sich Nano. Damit konnte ich die settings.js modifizieren. Der Befehl lautet: nano /opt/iobroker/node_modules/iobroker.node-red/settings.js
Ich würde jetzt mal zwei Fenster auf die API Node umbauen. Im nächsten Schritt wäre aber die Frage, ob ich mit einer weiteren API Node auskommen würde, um die Current Position und Remaining/Bewegungsstatus auszulesen :-). Ich bin aber für heute schon mal super Happy!
-
Mit der Variante String geht es leider nicht :-(.
Die ersten zwei Versuche mit den Scene IDs 4 und 5 führen zu keiner Reaktion bei KLF200, der dritte Versuche dann mit Scene ID 5 + Number produziert eine Reaktion allerdings keine Bewegung:Gäbe es evtl. eine Alternative, die Szene über die Velux API + eine Funktion auszulösen? Hier wird das beschrieben (auch wie man die Überlastung des KLF200 verhindern kann):
https://213.136.68.177/topic/14312/adapter-für-velux-klf-200-interface/41?lang=en-GB&page=6
Dies wäre der Code:
Allerdings müsste ich wahrscheinlich die settings.js modifizieren.
@sascho Kannst Du Code für die Zukunft in CodeTags packen - sonst ist das blöd zum Kopieren.
Punkt 1:
Ehrlich gesagt verstehe ich den functions-code nur halb und halte auch davon überhaupt nichts. Wie gesagt, um Überlastung zu verhindern, habe ich Dir ja gestern ein paar Flows geschickt. Die settings.js müsstest Du modifizieren, aber nur weil du die API in der Function Node verfügbar machen müsstest. Dafür hast Du aber die Velux Nodes und die machen die Arbeit schon, auch wenn wir es halt nicht wissen, warum es nicht geht.
In der Function Node werden Fehler auch nur mit catch abgefangen. Wie gesagt - ich halte nichts davon, über function Nodes so was komplett zu schreiben.
Der Ersteller dieser Function Node macht nichts weiter als die API aufzurufen, das können wir mit der API Node ja auch versuchen.
Im Prinzip fängt der Fehler nur mit der Catch Node ab, macht aber nichts draus.
Was der macht ist nur die API aufzurufen, dass kannst Du aber auch mit den API Nodes:Das gleiche können wir aber auch mit der API Node versuchen:
Im Prinzip hat dieser Ersteller der Function Node nur diese API Funktion aufgerufen:
Wenn Du die Inject Node aufmachst um das Objekt zu bearbeiten, dann mach den visuellen Editor auf, dann kannst da die Zahl für die Szene eingeben.
Eventuell muss man lt. API auch noch die Velocity eingeben.
Du hast auch nicht rückgemeldet, ob die API Nodes zur Ermittlung des Status und der Reboot funktionieren????
Punkt 2:
Probier halt auch ob meine Inject Nodes mit den normalen Nodes funktionieren.
Punkt 3
Ich habe mir gerade den Source Code der Szene Node angeschaut - also es muss in jedem Fall das Topic als String übergeben werden:
Ich bin mir aber noch nicht sicher, ob ich das mit den Szenen verstanden habe. Inzwischen kannst ja mal den API Call der Szene probieren und schauen, ob was zurückkommt.
-
Ich hab's mit der Function + API Node hinbekommen :-)))!!! Ich kann nun über die Inject Node direkt die Szene aufrufen.
Das Programm zum öffnen von Dateien im Terminal des Docker vom IOBroker nennt sich Nano. Damit konnte ich die settings.js modifizieren. Der Befehl lautet: nano /opt/iobroker/node_modules/iobroker.node-red/settings.js
Ich würde jetzt mal zwei Fenster auf die API Node umbauen. Im nächsten Schritt wäre aber die Frage, ob ich mit einer weiteren API Node auskommen würde, um die Current Position und Remaining/Bewegungsstatus auszulesen :-). Ich bin aber für heute schon mal super Happy!
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
Ich hab's mit der Function + API Node hinbekommen :-)))!!! Ich kann nun über die Inject Node direkt die Szene aufrufen.
Das Programm zum öffnen von Dateien im Terminal des Docker vom IOBroker nennt sich Nano. Damit konnte ich die settings.js modifizieren. Der Befehl lautet: nano /opt/iobroker/node_modules/iobroker.node-red/settings.js
Ich würde jetzt mal zwei Fenster auf die API Node umbauen. Im nächsten Schritt wäre aber die Frage, ob ich mit einer weiteren API Node auskommen würde, um die Current Position und Remaining/Bewegungsstatus auszulesen :-). Ich bin aber für heute schon mal super Happy!
Ich würde es nicht machen. - Ich hab Dir ja gerade geschickt, wie Du das was die Funktion macht ggf. auhc mit der API Node machen kannst.
Nano ist übrigens ein Linux Editor - dann hat inzwischen jedes neuere Linux System an Board. ;)
Aber wie gesagt mit der Function Node - bin ich aus dem Spiel.
-
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
Ich hab's mit der Function + API Node hinbekommen :-)))!!! Ich kann nun über die Inject Node direkt die Szene aufrufen.
Das Programm zum öffnen von Dateien im Terminal des Docker vom IOBroker nennt sich Nano. Damit konnte ich die settings.js modifizieren. Der Befehl lautet: nano /opt/iobroker/node_modules/iobroker.node-red/settings.js
Ich würde jetzt mal zwei Fenster auf die API Node umbauen. Im nächsten Schritt wäre aber die Frage, ob ich mit einer weiteren API Node auskommen würde, um die Current Position und Remaining/Bewegungsstatus auszulesen :-). Ich bin aber für heute schon mal super Happy!
Ich würde es nicht machen. - Ich hab Dir ja gerade geschickt, wie Du das was die Funktion macht ggf. auhc mit der API Node machen kannst.
Nano ist übrigens ein Linux Editor - dann hat inzwischen jedes neuere Linux System an Board. ;)
Aber wie gesagt mit der Function Node - bin ich aus dem Spiel.
Mit der API Node + Funktion hattest Du vollkommen Recht, das war nichts. Die Reaktion der testweise angeschlossenen Fenster war total sporadisch. Ich habe sie erst einmal wieder rausgenommen - total frustierend so etwas.
Stattdessen habe ich gestern die restlichen Szenen im KLF200 angelernt, nachdem es aufgehört hatte zu regnen (ansonsten fahren die Fenster nicht auf).
Ich habe dann mal auf die Schnelle den KLF200 Adapter wieder installiert und an die Szenen gehängt. Bisher läuft der Adapter ohne Absturz und keine Fehlermeldungen im Log.
Evtl. ist ja der Adapter doch die bessere Wahl in Verbindung mit den Szenen + evtl. das Abfangen von Statusmeldungen im Log. Ich habe jetzt einen Smarten Zwischenstecker vor dem KLF200. Wenn eine Fehlermeldung des Adapters im Log auftaucht, könnte man den Zwischenstecker kurz aus und einschalten und dann den Adapter neu starten. Evtl. ist das die beste Lösung?
Mich würde aber schon noch interessieren, ob wir die Nodes zum Laufen bekommen mit Deinen Skripten - mir fehlt gerade nur die Zeit zum ausprobieren :-(.
-
Mit der API Node + Funktion hattest Du vollkommen Recht, das war nichts. Die Reaktion der testweise angeschlossenen Fenster war total sporadisch. Ich habe sie erst einmal wieder rausgenommen - total frustierend so etwas.
Stattdessen habe ich gestern die restlichen Szenen im KLF200 angelernt, nachdem es aufgehört hatte zu regnen (ansonsten fahren die Fenster nicht auf).
Ich habe dann mal auf die Schnelle den KLF200 Adapter wieder installiert und an die Szenen gehängt. Bisher läuft der Adapter ohne Absturz und keine Fehlermeldungen im Log.
Evtl. ist ja der Adapter doch die bessere Wahl in Verbindung mit den Szenen + evtl. das Abfangen von Statusmeldungen im Log. Ich habe jetzt einen Smarten Zwischenstecker vor dem KLF200. Wenn eine Fehlermeldung des Adapters im Log auftaucht, könnte man den Zwischenstecker kurz aus und einschalten und dann den Adapter neu starten. Evtl. ist das die beste Lösung?
Mich würde aber schon noch interessieren, ob wir die Nodes zum Laufen bekommen mit Deinen Skripten - mir fehlt gerade nur die Zeit zum ausprobieren :-(.
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
Mit der API Node + Funktion hattest Du vollkommen Recht, das war nichts. Die Reaktion der testweise angeschlossenen Fenster war total sporadisch. Ich habe sie erst einmal wieder rausgenommen - total frustierend so etwas.
Na deswegen war ich da auch raus - wenn jemand meint mit einem API Call, dasselbe zu erreichen. Wie gesagt, das hättest Du direkt auch mit der API Node machen können und ich hab Dir ja beschrieben, wie man sowas dann macht. Und wenn man mit der API arbeitet, dann gehört etwas mehr dazu, als nur den Request abzusetzen, das können die API Nodes auch.
Lies mal aus der API Doku ab seite 95
Ich hätte also zumindest erwartet, dass diese Function zurückgibt, ob der Request akzeptiert wurde oder nicht und das hat der alles nicht gemacht. Deswegen war das für mich gleich alles für die Tonne, zudem Du ja die API Node hast, um sowas zu machen.
Aber für Dich ist es wahrscheinlich wirklich besser, Du nimmst den iobroker Adapter wieder in Betrieb und reagierst erst mal auf Fehlersituationen im Log, als Dich mit diesen Problemen rumzuschlagen.
Es wäre was anderes wenn ich auch so KLF Gateway hätte, dann könnte ich Dich hier ganz anders unterstützen, da ich die Dinge ja selbst ausprobieren könnte, aber nach dem nicht der Fall ist, geht das leider nicht. Auch das ich generell den Vorschlag gemacht habe, es mit den Velux Nodes es zu versuchen, war ja nur der Versuch, ob Du damit etwas mehr Stabilität bekommst. Wie Du an dem Flow mit der Befehlsqueue siehst, hat man halt ggf. mehr Möglichkeiten durch direktes Zurückmelden einer Fehlersituation eben schneller zu reagieren, als über den Adapter.
Wie gesagt, nimm den Adapter wieder in Betrieb und installiere Dir die von mir empfohlene Tailnode. Ich habe die jetzt 1-2 Wochen in Betrieb und die kommt nun mit dem Wechsel des iobroker Log Files gut zu Recht.
-
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
Mit der API Node + Funktion hattest Du vollkommen Recht, das war nichts. Die Reaktion der testweise angeschlossenen Fenster war total sporadisch. Ich habe sie erst einmal wieder rausgenommen - total frustierend so etwas.
Na deswegen war ich da auch raus - wenn jemand meint mit einem API Call, dasselbe zu erreichen. Wie gesagt, das hättest Du direkt auch mit der API Node machen können und ich hab Dir ja beschrieben, wie man sowas dann macht. Und wenn man mit der API arbeitet, dann gehört etwas mehr dazu, als nur den Request abzusetzen, das können die API Nodes auch.
Lies mal aus der API Doku ab seite 95
Ich hätte also zumindest erwartet, dass diese Function zurückgibt, ob der Request akzeptiert wurde oder nicht und das hat der alles nicht gemacht. Deswegen war das für mich gleich alles für die Tonne, zudem Du ja die API Node hast, um sowas zu machen.
Aber für Dich ist es wahrscheinlich wirklich besser, Du nimmst den iobroker Adapter wieder in Betrieb und reagierst erst mal auf Fehlersituationen im Log, als Dich mit diesen Problemen rumzuschlagen.
Es wäre was anderes wenn ich auch so KLF Gateway hätte, dann könnte ich Dich hier ganz anders unterstützen, da ich die Dinge ja selbst ausprobieren könnte, aber nach dem nicht der Fall ist, geht das leider nicht. Auch das ich generell den Vorschlag gemacht habe, es mit den Velux Nodes es zu versuchen, war ja nur der Versuch, ob Du damit etwas mehr Stabilität bekommst. Wie Du an dem Flow mit der Befehlsqueue siehst, hat man halt ggf. mehr Möglichkeiten durch direktes Zurückmelden einer Fehlersituation eben schneller zu reagieren, als über den Adapter.
Wie gesagt, nimm den Adapter wieder in Betrieb und installiere Dir die von mir empfohlene Tailnode. Ich habe die jetzt 1-2 Wochen in Betrieb und die kommt nun mit dem Wechsel des iobroker Log Files gut zu Recht.
Dieses Schaubbild von Velux hat mich überzeugt, es mal verstärkt mit den Scenes zu versuchen. Ich habe ganz stark die Vermutung, dass das KLF200 gut damit zurecht kommt, aus einem User-Szenenbefehl mehrere Aktuatoren sauber anzusteuern. Nicht gut zurecht kommt es mit Situationen, wo mehrere User-Befehle mit mehreren Aktuatoren verheiratet werden müssen.
Auch mit fast zeitgleich ausgelösten Szenen kommt es gut zurecht. Seit zwei Tagen läuft der Adapter durch und nichts vom Adapter ist im Log aufgetaucht. Das ist doch schon mal super.Und realistischerweise - ich habe hier im Haus noch so viele Sachen zu erledigen - da mache ich mich an das Nodes Thema lieber später noch mal dran. Evtl. hat es ja noch ein paar Vorteile ggü. dem Adapter.
Ich hoffe, dass der Adapter jetzt mal sauber durchläuft - beim ersten Crash baue ich dann noch die Tail-Node ein.
Als nächstes muss aber auf jeden Fall noch die PV Anlage eingebunden werden :-). Du bist aber eine ganz große Hilfe in der Lage! Wirklich noch einmal großen Dank und meine aufrichtige Hochachtung vor Deinen Fähigkeiten! -
@mickym Kurze Frage, ich wollte gerade noch mal den Restart der Instanz einbauen, wenn der Adapter die Verbindung zum KLF200 verliert.
Trigger für den Restart ist, wenn der Connection Datenpunkt auf False springt.
Ich bekomme aber den Trigger für den Instanz-Restart nicht hin. Es kommt immer folgende Fehlermeldung.
-
@mickym Kurze Frage, ich wollte gerade noch mal den Restart der Instanz einbauen, wenn der Adapter die Verbindung zum KLF200 verliert.
Trigger für den Restart ist, wenn der Connection Datenpunkt auf False springt.
Ich bekomme aber den Trigger für den Instanz-Restart nicht hin. Es kommt immer folgende Fehlermeldung.@sascho Hallo ;) - wäre toll wenn Du den Code für den Flow in CodeTags packen würdest.
Ich habe den klf200 Adapter ja leider nicht installiert - aber ich fürchte ich kann Dir nicht helfen. Weil ich hab einfach mal einen anderen Adapter mit Deinem Flow genommen und der funktioniert:
Ich hab mal den Info Adapter neu gestartet.
Schau mal ob Du andere Adapter neu starten kannst - ansonsten hast Du im System ggf. ein Berechtigungsproblem.
Irgendwie als ob Dein NodeRed Adapter unter einer anderen Kennung läuft keine Ahnung.
Eigentlich muss es so funktionieren. Evtl. ist an Deinem System was schief - da müsste ggf. unser Linux Guru helfen => @Thomas-Braun
HIer gabs mal ein ähnliches Problem: https://forum.iobroker.net/topic/40916/docker-container-restart-iobroker-per-script/42?_=1632433048127
Du kannst also mal probieren:
sudo -u iobroker iobroker restart info.0funktioniert bei mir jedenfalls auch:
-
@sascho Hallo ;) - wäre toll wenn Du den Code für den Flow in CodeTags packen würdest.
Ich habe den klf200 Adapter ja leider nicht installiert - aber ich fürchte ich kann Dir nicht helfen. Weil ich hab einfach mal einen anderen Adapter mit Deinem Flow genommen und der funktioniert:
Ich hab mal den Info Adapter neu gestartet.
Schau mal ob Du andere Adapter neu starten kannst - ansonsten hast Du im System ggf. ein Berechtigungsproblem.
Irgendwie als ob Dein NodeRed Adapter unter einer anderen Kennung läuft keine Ahnung.
Eigentlich muss es so funktionieren. Evtl. ist an Deinem System was schief - da müsste ggf. unser Linux Guru helfen => @Thomas-Braun
HIer gabs mal ein ähnliches Problem: https://forum.iobroker.net/topic/40916/docker-container-restart-iobroker-per-script/42?_=1632433048127
Du kannst also mal probieren:
sudo -u iobroker iobroker restart info.0funktioniert bei mir jedenfalls auch:
-
Ich habs mal mit dem info Adapter probiert. Das funktioniert auch nicht, sieht so aus als wenn ich tatsächlich ein Berechtigungsproblem habe. Soll ich dann mal den Kollegen anklingeln? Die verlinkte Lösung sieht sehr kompliziert aus.
-
Hi,
ich habe das Thema LOG Auswertungen aus Zeitgründen nicht weiterverfolgt. Der KLF200 Adapter ist seit dem ausschließlichen Nutzen von Szenen auch nicht mehr abgestürzt. Das System läuft jetzt seit ein paar Wochen stabil, obwohl ich noch laufend Anpassungen machen.
Aktuell arbeite ich an einer Möglichkeit, die Wärmepumpe sauber in unser System zu integrieren. Sie ist leider keine Inverter Wärmepumpe - d.h. sie kann nur ein- oder ausschalten. Nachts soll soll sie möglichst nicht viel laufen, sondern den Strom der PV Anlage am Tag nutzen.
Daher schalte ich sie per Skript um 16:30 in den Sommermodus (0) und um 10:30 in den Wintermodus (1).
Im Sommermodus arbeitet sie gar nicht und die Rücklauftemperatur fällt irgendwann nachts unter 20°, wodurch das Haus auskühlt. Daher schalte ich die Wärmepumpe per Skript in den Urlaubsmodus, wenn die Rücklauftemperatur unter 20° fällt.
Leider passiert das schon mal durch Temperaturschwankungen. Ich möchte mein Skript daher verbessern, dass die Umschaltung erst erfolgt, wenn die 20° für mehr als 10 Minuten unterschritten werden, und auch nur zwischen 16:30 - 10:30.
Hast Du eine Ahnung, wie das gehen kann?Hier mal ein Testballon....
-
Hi,
ich habe das Thema LOG Auswertungen aus Zeitgründen nicht weiterverfolgt. Der KLF200 Adapter ist seit dem ausschließlichen Nutzen von Szenen auch nicht mehr abgestürzt. Das System läuft jetzt seit ein paar Wochen stabil, obwohl ich noch laufend Anpassungen machen.
Aktuell arbeite ich an einer Möglichkeit, die Wärmepumpe sauber in unser System zu integrieren. Sie ist leider keine Inverter Wärmepumpe - d.h. sie kann nur ein- oder ausschalten. Nachts soll soll sie möglichst nicht viel laufen, sondern den Strom der PV Anlage am Tag nutzen.
Daher schalte ich sie per Skript um 16:30 in den Sommermodus (0) und um 10:30 in den Wintermodus (1).
Im Sommermodus arbeitet sie gar nicht und die Rücklauftemperatur fällt irgendwann nachts unter 20°, wodurch das Haus auskühlt. Daher schalte ich die Wärmepumpe per Skript in den Urlaubsmodus, wenn die Rücklauftemperatur unter 20° fällt.
Leider passiert das schon mal durch Temperaturschwankungen. Ich möchte mein Skript daher verbessern, dass die Umschaltung erst erfolgt, wenn die 20° für mehr als 10 Minuten unterschritten werden, und auch nur zwischen 16:30 - 10:30.
Hast Du eine Ahnung, wie das gehen kann?Hier mal ein Testballon....
@sascho Ich würde an Deiner Stelle lieber mit Hysterese arbeiten als mit Zeitfenstern - das nur allgemein zu den Regelmechanismen. Man kann es auch mit 10 min etc. machen - hängt halt davon ab, wie oft die Temperatur gemeldet wird.
Bitte in Zukunft exportierte Flows in CodeTags stellen - es ist sonst wirklich mühselig durch das Skript zu scrollen.
Falls Du öfter mal zeitliche Filter hast - die Du grafisch einstellen willst - empfehle ich Dir den lightscheduler. Ansonsten kann man es aber auch einfach mit Hausmitteln umsetzen:
Diese Switch Node lässt Nachrichten, wie gewünscht nur zwischen 16:30 und 10:30 durch. Schaltet wahrscheinlich erst um 10:31 dann halt in >= ändern.
Trotzdem - auch wenn eventuell eine Hysterese besser ist - hier mal die Prüfung auf 10 Minuten unter 20°C und die gesamte Logik wie Du sie beschrieben hast: Ab 10:30 Wintermodus (1), ab 16:30 Sommermodus (0) bei 10 min unter 20°C Urlaubsmodus (2) im Zeitraum von 16:30 und 10:30.
-
@sascho Ich würde an Deiner Stelle lieber mit Hysterese arbeiten als mit Zeitfenstern - das nur allgemein zu den Regelmechanismen. Man kann es auch mit 10 min etc. machen - hängt halt davon ab, wie oft die Temperatur gemeldet wird.
Bitte in Zukunft exportierte Flows in CodeTags stellen - es ist sonst wirklich mühselig durch das Skript zu scrollen.
Falls Du öfter mal zeitliche Filter hast - die Du grafisch einstellen willst - empfehle ich Dir den lightscheduler. Ansonsten kann man es aber auch einfach mit Hausmitteln umsetzen:
Diese Switch Node lässt Nachrichten, wie gewünscht nur zwischen 16:30 und 10:30 durch. Schaltet wahrscheinlich erst um 10:31 dann halt in >= ändern.
Trotzdem - auch wenn eventuell eine Hysterese besser ist - hier mal die Prüfung auf 10 Minuten unter 20°C und die gesamte Logik wie Du sie beschrieben hast: Ab 10:30 Wintermodus (1), ab 16:30 Sommermodus (0) bei 10 min unter 20°C Urlaubsmodus (2) im Zeitraum von 16:30 und 10:30.
Prima, das hat funktioniert. Ich habe noch eine E-Mail Notification eingebaut und die E-Mail kam pünktlich und der Test-Datenpunkt wurde mit dem neuen Betriebsmodus beschrieben.
Was allerdings noch fehlen würde, wäre dass der ursprüngliche Sommermodus nach einer festgelegten Zeit wieder eingestellt wird - z.B. 30 Min.
Die festgelegte Minimaltemperatur kann nämlich bereits um 23:00 Uhr unterschritten werden. Dann läuft die Wärmepumpe ungewollt bis Morgens um 10:30 im Urlaubsmodus. Sie sollte stattdessen nach einer festgelegten Zeit wieder "einschlafen".
Ich würde das zeitgesteuert machen und nicht über eine Maximaltemperatur - denn die Rücklauftemperatur schwankt sehr stark je nachdem ob geheizt wird und auch wenn Ventile öffnen und schließen.
Kann man das z.B. über ein Delay + Change Node machen? Würde die Untergrenzenüberwachung dann auch wieder scharf geschaltet?P.S. Was meinst Du mit Code Tags? & Besten Dank!
-
Prima, das hat funktioniert. Ich habe noch eine E-Mail Notification eingebaut und die E-Mail kam pünktlich und der Test-Datenpunkt wurde mit dem neuen Betriebsmodus beschrieben.
Was allerdings noch fehlen würde, wäre dass der ursprüngliche Sommermodus nach einer festgelegten Zeit wieder eingestellt wird - z.B. 30 Min.
Die festgelegte Minimaltemperatur kann nämlich bereits um 23:00 Uhr unterschritten werden. Dann läuft die Wärmepumpe ungewollt bis Morgens um 10:30 im Urlaubsmodus. Sie sollte stattdessen nach einer festgelegten Zeit wieder "einschlafen".
Ich würde das zeitgesteuert machen und nicht über eine Maximaltemperatur - denn die Rücklauftemperatur schwankt sehr stark je nachdem ob geheizt wird und auch wenn Ventile öffnen und schließen.
Kann man das z.B. über ein Delay + Change Node machen? Würde die Untergrenzenüberwachung dann auch wieder scharf geschaltet?P.S. Was meinst Du mit Code Tags? & Besten Dank!
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
P.S. Was meinst Du mit Code Tags? & Besten Dank!
Fangen wir mal damit an - dachte eigentlich als nun "alter Hase" im Forum solltest Du das wissen:
Der Vorteil ist einfach - dass Du mit Select All in der schwarzen Box alles markiert hast und in die Zwischenablage kopieren kannst und nicht ewig durch den Code scrollen musst.
-
Prima, das hat funktioniert. Ich habe noch eine E-Mail Notification eingebaut und die E-Mail kam pünktlich und der Test-Datenpunkt wurde mit dem neuen Betriebsmodus beschrieben.
Was allerdings noch fehlen würde, wäre dass der ursprüngliche Sommermodus nach einer festgelegten Zeit wieder eingestellt wird - z.B. 30 Min.
Die festgelegte Minimaltemperatur kann nämlich bereits um 23:00 Uhr unterschritten werden. Dann läuft die Wärmepumpe ungewollt bis Morgens um 10:30 im Urlaubsmodus. Sie sollte stattdessen nach einer festgelegten Zeit wieder "einschlafen".
Ich würde das zeitgesteuert machen und nicht über eine Maximaltemperatur - denn die Rücklauftemperatur schwankt sehr stark je nachdem ob geheizt wird und auch wenn Ventile öffnen und schließen.
Kann man das z.B. über ein Delay + Change Node machen? Würde die Untergrenzenüberwachung dann auch wieder scharf geschaltet?P.S. Was meinst Du mit Code Tags? & Besten Dank!
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
Sie sollte stattdessen nach einer festgelegten Zeit wieder "einschlafen".
Ich würde das zeitgesteuert machen und nicht über eine Maximaltemperatur - denn die Rücklauftemperatur schwankt sehr stark je nachdem ob geheizt wird und auch wenn Ventile öffnen und schließen.
Kann man das z.B. über ein Delay + Change Node machen? Würde die Untergrenzenüberwachung dann auch wieder scharf geschaltet?Die Logik erschließt sich mir doch nicht so ganz. Wenn es kalt wird sollte doch die Rücklauftemperatur wieder höher werden, wenn die Pumpe eingeschaltet ist, das ist doch Sinn der Sache und wenn mehr geheizt wird, dauert es länger bis die Rücklauftemperatur wieder hoch genug ist. Na egal - so wird halt dann wohl mehrfach geschaltet.
Um 23:00 für eine halbe Stunde - dann wenn wieder 19°C wieder für eine halbe Stunde - na egal ich muss es nicht verstehen.
Nun zur Umsetzung - ist eigentlich ganz easy - Du schaltest 2 Trigger Nodes hintereinander. Die 1. Trigger Node wird nur noch als Trigger für die 2. Trigger Node genutzt - sprich wenn die Dauer der Temperaturüberprüfung abgelaufen ist, die eigentliche Steuerung übernimmt dann die 2. Trigger Node.
Support us
525
Online32.7k
Benutzer82.4k
Themen1.3m
Beiträge