bshb - Rollladensteuerung mit yhka Homekit
-
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
Stabil laufen wäre jetzt erst einmal mein Hauptziel :-). Ich habe gestern mal alles auf Velux Nodes umgestellt - also pro Fenster 1x Current, 1x Remaining, 1x Target. Dadurch musste ich ziemlich oft die Red Node Flows neu deployen. Das hat wohl das KLF200 überfordert. Ich bekomme seitdem nur noch diese Fehlermeldungen:
Nun das heiß erst mal, dass es mit einer Node stabil gelaufen ist. Ich gehe mal davon aus, dass Du beim deployen zumindest nur die geänderten Nodes deployest - wenn nicht - vielleicht hilft das ja auch schon etwas.
Mir ist auch nicht klar, ob weniger Nodes besser wären, da ja alle über eine API Einstellung laufen
Nun auch wenn es über eine API läuft, so könntest Du über das Topic ja verscheiden KLF Nodes ansprechen. Mit theoretisch einer Node - kannst Du den Nachrichtenfluß ggf. über die Delay Node bremsen.
Evtl. kann man ja auch Remaining und Current über eine Node auslesen (All Values).
Auch das ist mE eine gute Idee.
Oder generell eben, wie ich mit dem API aufruf prüfen, ob die KLF idle und ready ist und ggf. zumindest alles was Schreiben betrifft - blockieren, solange KLF nicht ready.
-
Ja, die API Node würde ich auch gerne mal in Gang setzen. Aber ich habe das gleiche Problem wie der Themenersteller hier. Man bekommt nur ein schwarzes Dropdown in der Velux API:
https://github.com/PLCHome/node-red-contrib-velux/issues/11
Ich muss wahrscheinlich in die Konfiguration ändern, bevor ich hier? den Befehl:
eingeben kann:
Dazu müsste ich aber in die Container Ordnerstruktur kommen.
closed Velux Api Node #11
-
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
Wie komme ich eigentlich in die Pfadstruktur von Docker bzw. buanet iobroker? Deinen Befehl direkt im terminal einzugeben gibt nur ein Fehler:
Du hast so etwas wie einen Ordner Browser offen. So etwas würde ich mir auch gerne einrichten.
Da kann ich leider nicht helfen, da ich nicht mit Docker oder VMs arbeite.
Das ist bei mit der verpönte Raspberry Desktop.
-
@sascho Schreib doch mal gar nichts in die API Node und versuch doch nur mal über die Inject Nodes API Befehle abzusetzen.
Ich habe Dir ja mal den Reboot gepostet - und hier mal zusätzlich die Statusabfrage:
-
@sascho Aber nochmal, wenn das mit den Nodes keine gute Idee ist oder zu kompliziert - dann bleib doch bei Deiner Adapterlösung. Das mit dem anhand des Logs die KLF neu zu starten, wie Du es ursprünglich vorhattest ist dann vielleicht doch einfacher.
-
Ich teste das mit den Inject Nodes mal heute Abend. Aber ich glaube das KLF200 ist jetzt nicht mehr über die api erreichbar.
Ich hatte heute Nacht das Testsystem mit den 3 Velux nodes online. Dies bekommt auch keine Verbindung mehr.
Das heißt ab einem gewissen Punkt muss man das KLF200 per smartem Zwischenstecker vom Netz trennen um einen reboot zu initiieren. Das würde sehr wahrscheinlich nicht mehr über den Adapter oder die api Node klappen, da die api down ist.
Ich würde das über den von Dir oben beschriebenen Weg machen.Bleibt aber noch die Frage warum das KLF200 einfriert. Ich vermute Überlastung. Da würde ich mal testen ob die Velux nodes im Normalbetrieb besser arbeiten als der Adapter. Vorteil wäre, dass sie nicht wie der Adapter dauerhaft abschalten wenn das KLF200 nicht erreichbar ist.
Ich glaube wir sind auf einem guten Weg auch wenn es viel try und error ist. -
@sascho Wie gesagt, über den API Call kannst Du ja den Status abrufen. Falls dann keine Antwort kommt, dann die Steckdose (smarten Zwischenstecker) schalten:
Hier kannst Du halt über die Steckdose (Zwischenstecker) direkt reagieren anstelle von Logs, wenn das KLF200 nicht mehr erreichbar ist:
Diese 3 Nodes kannst Du Dir generell auch als Subflow speichern, dann hast Du alles in einer Node und kannst diese als timeout Node für alle Nodes verwenden, wo Du nach einer bestimmten Zeit eine Antwort erwartest. Statt on und off kannst natürlich auch true und false verwenden, je nachdem was Du halt für Deine Steckdose brauchst.
-
Hi!
also ich konnte den Hardware Reset am KLF200 jetzt machen und die Velux Nodes funktionieren - so lala. Ich habe die Beobachtung gemacht, dass ich immer nur einen Befehl geben kann, dann warten muss bis sich der Status aktualisiert hat und dann den nächsten Befehl geben kann. Auch das klappt nicht immer und es erscheinen diese Fehler im Log:
Ich habe jetzt nur noch die Hoffnung, die Anzahl der Nodes durch die Verwendung von Szenen für das Target und die All Values Node für die Current Values zu reduzieren.
Kannst du spontan sagen, wie ich so einen Payload zerlege und in Datenpunkt ausgebe?
Wenn das alles nicht hilft, muss ich wohl zurück auf den Adapter gehen und mir mit der Reboot Funktionalität behelfen :-(.
-
- Mit der Catch Node - kannst Du, wenn Du weißt welche Velux Nodes diesen Fehler produzieren (ist das die Statusabfrage) ggf. abfangen. Einfach eine Catch Node rausziehen, dann zu überwachende Nodes auswählen und das msg.error Objekt analysieren.
2. Wenn Du ein Objekt hast, hängt nun davon ab, ob Du wirklich alles in Datenpunkte schreiben willst oder nur einzelne Daten.2.1 Wenn Dich nur eine einzelne Eigenschaft interessiert zum Beispiel velocity - dann setzt Du die msg.payload auf msg.payload.velocity
2.2. Wenn Du jede Eigenschaft als eigene payload haben willst hängst Du eine split Node dran
2.3. Wenn Du das ganze Objekt in einen Datenpunkt schreiben willst, wandelst Du es in einen JSON String um und beim Auslesen wieder in ein Objekt
und so wandelst Du es wieder in ein Objekt zurück:
2.4.
Auch wenn es mit der neuen Adminversion zum Beginn wohl einige Fehlermeldungen(gabs dann doch nicht) - dann nimmst Du meinen Subflow, der hier genau beschrieben ist: https://forum.iobroker.net/topic/43856/json-string-oder-java-object-in-iobroker-strukturDort ist auch die genaue Bedienung beschrieben - hier nur die Kurzfassung:
Im NodeRed Adapter musst Du die Erstellung von Fremdobjekten zulassen:
Das Anlegen macht die iobroker Out Node in dem Du das einstellst:
Wider Erwarten gabs bei mir im Log keine Fehlermeldung:
Mit diesem Flow
erzeugst Du dann automatisch die Objektstruktur als einzelne Datenpunkte im iobroker:
Ergänzung: Die Fehlermeldung im Log gabs wahrscheinlich nicht, weil es direkt nach 0_userdata.0 angelegt wurde.
Du kannst aber erst mal selbst keine Datenpunkte seit dem neuen Admin anlegen, weil NodeRed leider keine Objekte im iobroker anlegen kann.
Du siehst das fehlende Objekt im neuen admin an dem fehlenden Stiftsymbol
Du musst dann auf der Ebene 0_userdata.0 den Punkt velux nochmals manuell anlegen, damit alles regelkonform ist:
Dann kannst auch manuell in diesem "Verzeichnis" wieder neue Datenpunkte anlegen:
Wenn Du auf den Adapter zurückgehst um das Log zu analysieren, dann sag nochmal Bescheid, denn ich hab noch was an der ChangeNode geändert und wie gesagt eine andere Tailnode verwendet.
-
Also, ich habe mal alles auf die All Value Nodes umgebaut - über die Change Variante. Gefühlt hat das schon mal etwas gebracht. Es kommen weniger Fehlermeldung ins Log:
Allerdings habe ich beobachtet, dass wenn ich Fensterpaare ansteuere, dass die Status Nodes kurz offline sind, und erst nach 2-3 Minuten wieder einen Status berichten. Ich vermute stark, dass in diesem Moment die Fehlermeldungen generiert werden. Vermutlich kann das KLF200 wirklich nur 2 Befehle gleichzeitig verarbeiten. Ich bekomme später des KLR200 und versuche dann mal die Target Befehle über Szenen abzubilden. Evtl. reduziert das die Probleme weiter.
Wie ich die Catch Node verwenden kann ist mir aber nicht klar.
Ich habe sie mit ins Flow Fenster kopiert.. Sollte sie das Debug Fenster beladen?
![54766800-8a13-47f2-b9da-90fe02c324a7-image.png]
(/assets/uploads/files/1630158935738-54766800-8a13-47f2-b9da-90fe02c324a7-image.png)
-
@sascho Nein die Catch Node ist dazu da, um Fehler abzufangen oder ggf. darauf zu reagieren.
Wie gesagt ich würde es aber nicht mit allen Nodes machen, sondern dafür ausgewählte Velux Nodes von Dir verwenden.
Ich versuche Dir das für Dein Beispiel, so am Besten wie möglich zu illustrieren. Da ich wie gesagt keine KLF 200 und keine Velux-Fenster habe, behelfe ich mich momentan mit einer Function Node - die in diesem Beispiel zum Beispiel eine Velux API Node sein könnte, um den Status abzufragen oder auch um das Target zu setzen .
Doch zuerst noch mal die Catch Node.
Man kann entweder alle Nodes in einem Flow überwachen oder nur spezielle. Für spezielle kann man die über eine Liste auswählen, da die ziemlich lange ist, kann man das aber auch über die Schaltfläche Nodes auswählen machen, wie ich versucht habe in folgendem Video darzustellen:
Catch Node zur Fehlerbehandlung.mp4
So und hier nun der Flow und was ich mit dieser Catch Node erreichen kann.
Die FunctionNode simuliert eine Velux Node, die ich mit einer Zufallszahl füttere, wenn diese größer als 0,5 ist - spukt die Node einen Fehler aus, wenn die Zufallszahl kleiner 0,5 ist, dann ist alles OK.
Den Fehler, den die Funktion Node ausstößt, ist in etwa der den Du im Log gepostet hast und das sieht im Beipielflow im Log dann so aus:
wenn ich diese nicht mit der Catch Node abfange.
Der Vorteil ist natürlich nicht nur, dass ich den Fehler statt im Log im Debug Fenster habe, sondern dass ich damit nun eigene Flows starten kann, die durch den Fehler in der Velux Node getriggert werden können.
Du siehst wenn Du in der function Node also ein Fehler erzeugt wird (das würde ja Deiner Velux Node entsprechen), dann triggert die Catch Node mit der Error-Objekt
Dieses kann man nun zwar einfach im Debug Fenster ausgeben lassen oder man lässt einen sinnvollen Flow starten. In meinem Beispielflow filtere ich also nur die Fehlermeldung mit dem timeout aus - man kann natürlich generell einfach alles durchlassen, was einen Fehler erzeugt.
Wichtig ist aber, dass ich über die nachfolgende Change Node nun eine Flowvariable "timeout" auf true setzen kann:
Solange dies gesetzt ist - wird oben der Flow blockiert bis die timeout Variable wieder false ist.
Sprich so kann man nur Werte setzen wenn die timeout-Variable false ist.
Arbeit die Velux Node richtig (in dem Beispiel die Function Node und liegt keine Fehlersituation vor), dann wird timeout auf false gesetzt.
Ich geh einfach mal davon aus, dass die Velux Node im Fehlerfall bislang auch nichts mehr ausspukt und nur wenn alles OK ist, wird auch was aus der Node ausgegeben.
Hier mal der Beispielflow zum Import:
Noch was zur Catch Node - falls Du nicht alle Nodes überwachst gibt die Zahl hinter der Node an (wenn Du keinen Namen vergibst) wieviel Nodes von der Catch Node überwacht werden.
In dem msg.error Objekt, das die Catch Node zurückgibt, ist neben der Fehlermeldung die source interessant:
Damit kannst Du anhand des Namens oder auch der ID, die Node identifizieren, welche den Fehler geworfen hat. Dies ist dann wichtig, wenn Du mehrere Nodes mit einer Catch Node überwachst.Wenn Du die ID über die Schaltfläche in die Zwischenablage kopierst:
Dann kannst Du diese Node über diese ID im Info-Fenster einfach suchen:
Mit etwas Programmierung in einer Function Node - könnte man sich damit auch eine Befehlsqueue aufbauen, die nur bei korrektem Fehlerstatus die Velux Nodes mit Befehlen versieht.
-
In Anlehnung an das vorherige Posting könntest Du auch versuchen mit einer Velux Node verschiedene Fenster zu steuern und mal schauen ob das geht.
Ich habe das mal mit dem topic und Inject Nodes versucht - und das kannst ja auch mal probieren, halt mit Deinen IDs
ob Du so Deine verschiedenen Fenster / Rolläden mit einer Velux Node steuern kannst.
-
@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
-
@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:
-
Also, irgendwie funktioniert es noch nicht. Ich habe die Inject Node auf String umgestellt und den Scene Index 0 und 1 probiert. Darauf reagiert die Velux Scene Node nicht:
Die Debug Node habe ich auf all Messages umgestellt.
-
@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.
-
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 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.
