bshb - Rollladensteuerung mit yhka Homekit
-
-
@sascho über den neuen Admin findest das nicht.
Du musst halt in Deinem Container schauen - ob in diesem Verzeichnis die KLF200 API noch installiert ist:
oder natürlich auf der Kommandozeile:
cd /opt/iobroker/iobroker-data/node-red/node_modulesdann
ls -la | moredann mit Enter durchscrollen
hier sehe ich dann das alles Node-Typen die ich mit dem Pallettenamanger installiert habe - deswegen gehe ich davon aus, dass hier dann auch ein Verzeichnis velux-klf200-api exisitieren müsste.
drwxrwxr-x+ 8 iobroker iobroker 4096 18. Jul 00:43 node-disk-info drwxrwxr-x+ 3 iobroker iobroker 4096 16. Nov 2020 node-fetch drwxrwxr-x+ 5 iobroker iobroker 4096 29. Mär 03:59 node-persist drwxrwxr-x+ 3 iobroker iobroker 4096 14. Mai 18:26 node-red-contrib-bigtimer drwxrwxr-x+ 5 iobroker iobroker 4096 16. Jul 15:52 node-red-contrib-buffer-parser drwxrwxr-x+ 3 iobroker iobroker 4096 16. Jul 15:53 node-red-contrib-cron-plus drwxrwxr-x+ 4 iobroker iobroker 4096 4. Dez 2019 node-red-contrib-crypto-js drwxrwxr-x+ 4 iobroker iobroker 4096 1. Feb 2021 node-red-contrib-eztimer drwxrwxr-x+ 2 iobroker iobroker 4096 5. Dez 2020 node-red-contrib-fs-ops drwxrwxr-x+ 4 iobroker iobroker 4096 5. Feb 2021 node-red-contrib-harmony-websocket drwxr-xr-x+ 4 iobroker iobroker 4096 18. Jul 00:43 node-red-contrib-homekit-bridged drwxrwxr-x+ 6 iobroker iobroker 4096 29. Mär 03:59 node-red-contrib-light-scheduler drwxrwxr-x+ 6 iobroker iobroker 4096 16. Nov 2020 node-red-contrib-moment drwxrwxr-x+ 3 iobroker iobroker 4096 18. Jul 00:44 node-red-contrib-os drwxrwxr-x+ 3 iobroker iobroker 4096 17. Aug 01:16 node-red-contrib-tail-file drwxrwxr-x+ 6 iobroker iobroker 4096 18. Jul 00:42 node-red-contrib-ui-time-scheduler drwxrwxr-x+ 4 iobroker iobroker 4096 18. Jul 00:42 node-red-dashboard drwxrwxr-x+ 4 iobroker iobroker 4096 18. Jul 00:42 node-red-node-email drwxrwxr-x+ 4 iobroker iobroker 4096 29. Mär 03:56 node-red-node-feedparserUnter meiner Windows-Testinstallation von NodeRed finde ich nach Installation der velux Nodes - diese beiden Verzeichnisse:
Wenn das alles stabil klappt - ich drück Dir die Daumen - dann kannst ja auch ein bisschen mit dem valuetype spielen.
Manchmal muss man halt auch nur exakt lesen - siehe markierte Textstelle! - aber wie gut, dass Du es mit der Inject Node und der iobroker-In Node versucht hast - so konnte man sich über die Unterschiede auf die Lösung des Problems kommen.
Damit kann man dann vielleicht sogar - das Fenster von einer bestehenden Position um einen bestimmten Prozentsatz verändern
Das topic in eine ChangeNode würde dann so aussehen:
id und name musst halt eingeben - der Wert kommt weiterhin über die payload Deiners Datenpunktes.
Hier mal die Change Node zum Import:
So würde ich das mal sehen, um die Beschreibung umzusetzen. Aber schau erst mal ob es so stabil läuft, dann kannst immer noch sehen, ob Du hier mit den Möglichkeiten rumspielen möchtest. Name und ID sind auch optional (also brauchst nicht angeben, wenn Du das in der Node schon spezifizierst), weil Du das wahrscheinlich schon in der Velux NOde angibst. Man kann aber durch das variable Topic aber auch mit weniger Nodes auskommen, da das topic ja die Einstellungen in der Node überschreibt, aber das kann man immer noch später optimieren.
Aber erst muss mal alles stabil sein.
Daumen drück! -
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:
23 Aug 11:33:36 - [error] [velux-connection:6e3b4717.7b2e68] Velux Error: tcp errorError: connect ECONNREFUSED 192.168.178.6:51200 at TLSSocket.velux.errorCallback (/opt/iobroker/node_modules/velux-klf200-api/lib/net.js:171:19) at TLSSocket.emit (events.js:314:20) at emitErrorNT (internal/streams/destroy.js:92:8) at emitErrorAndCloseNT (internal/streams/destroy.js:60:3) at processTicksAndRejections (internal/process/task_queues.js:84:21)Ich vermute, ich müsste es jetzt vom Strom trennen und neu booten da es sich aufgehängt hat. Gefühlt kriegt es den Reset manchmal nach ein paar Stunden selbst hin. Ob die API Node jetzt noch funktionieren würde, weiß ich nicht.
Ob ich Nodes sparen kann - keine Ahnung. Selbst wenn ich Scenes einsetze, habe ich noch 5 Scenes x 1 Current/1x Remaining/1x Scene.
Mir ist auch nicht klar, ob weniger Nodes besser wären, da ja alle über eine API Einstellung laufen.
Ich würde Ende der Woche erst mal schauen, ob ich die Scenes eingerichtet bekomme.
Evtl. kann man ja auch Remaining und Current über eine Node auslesen (All Values). -
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.
-
@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.
