NEWS
Adapter für VELUX KLF-200 Interface
-
Seit ein paar Releases habe ich das Phänomen, dass ich den aktuellen Zustand der Rollos in meiner Vis nicht mehr zuverlässig sehen kann wenn diese außerhalb von ioBroker gesteuert wurden.
Will sagen, bisher habe ich in den HQWidgets die targetPosition verwendet und meine auch, dass sich diese bei externer Änderung mit verändert hat.
Nun sieht es mir aber so aus, dass die currentPosition der tatsächliche Wert ist (welcher nur nach RefreshProduct aktualisiert wird?). Das macht es natürlich schwierig, ein einziges Widget für Anzeige und Steuerung zu verwenden.
Wie macht ihr das denn? Vielleicht über Alias mit getrennten Lese-/Schreib-Datenpunkten?
Update: Okay, Alias würe klappen, aber bilde ich mir nur ein, dass man früher kein manuelles refreshProduct ausführen musste? Zumal das bei meinen netzbetriebenen Produkten direkt (!) in einen Timeout läuft. Werte werden aber dennoch aktualisiert ... state jedoch auf 45 (unbekannt?) gesetzt.
Sehr mysteriös...
Hi,
ich hab ein neues iobroker System, mit 1.3.2 Adapter aufgesetzt.
Das ganze verbindet sich zur VELUX Box, und dann erhalte ich folgenden Fehler:- 22 products found.
- Checking for unresponsive products...
- Error during initialization of the adapter.
- error: Too many nodes.
Ich habe noch ein altes System (Adapter Version 1.0.1) - wenn ich das starte, funktioniert das alles.
Was kann das beim neuen System sein?
Danke!
-
Hi,
ich hab ein neues iobroker System, mit 1.3.2 Adapter aufgesetzt.
Das ganze verbindet sich zur VELUX Box, und dann erhalte ich folgenden Fehler:- 22 products found.
- Checking for unresponsive products...
- Error during initialization of the adapter.
- error: Too many nodes.
Ich habe noch ein altes System (Adapter Version 1.0.1) - wenn ich das starte, funktioniert das alles.
Was kann das beim neuen System sein?
Danke!
-
@haloda Ich habe eine neue Version 1.3.2 erstellt. Damit sollte der Fehler nicht mehr auftreten. Die Version ist vermutlich ab morgenfrüh im beta- bzw. latest-repository verfügbar. Alternativ kann die Version jetzt bereits direkt von NPM installiert werden.
Viele Grüße
Michael@mischroe:
Hallo Michael, seit einiger Zeit verwende ich deine Adapter - danke für deine bisherige Arbeit. Bisher hatte ich nur in wenigen Situationen das Problem, dass beim automatischen Neustart des Adapters in der Nacht, dieser nicht mehr neu startete. Durch ein manuelles Starten lief dann aber wieder alles. Wie gesagt, das war so selten, dass es nicht gestört hat. Habe nun gesehen, dass es eine neue Version (1.3.2) gibt. Leider startet mir da der Adapter gar nicht mehr.
ein Debug Log vom Adapter-Start in der neuen Version hätte ich auch, wo bzw. wie darf ich dir das zukommen lassen.
Ich habe jetzt wieder zurückgestellt auf Version 1.3.1. Dann läuft es wieder, aber seither bekomme ich nun dieses Warning:
Systemeckdaten: Raspberry Pi, Plattform: linux, RAM: 3.7 GB, Node.js: v18.18.2, NPM: 9.8.1, js controller 6.0.11
Danke für deine Hilfe
Lg
TMinimax
PS. ev. hat @samke das gleiche Problem wie ich?
-
@mischroe:
Hallo Michael, seit einiger Zeit verwende ich deine Adapter - danke für deine bisherige Arbeit. Bisher hatte ich nur in wenigen Situationen das Problem, dass beim automatischen Neustart des Adapters in der Nacht, dieser nicht mehr neu startete. Durch ein manuelles Starten lief dann aber wieder alles. Wie gesagt, das war so selten, dass es nicht gestört hat. Habe nun gesehen, dass es eine neue Version (1.3.2) gibt. Leider startet mir da der Adapter gar nicht mehr.ein Debug Log vom Adapter-Start in der neuen Version hätte ich auch, wo bzw. wie darf ich dir das zukommen lassen.
Ich habe jetzt wieder zurückgestellt auf Version 1.3.1. Dann läuft es wieder, aber seither bekomme ich nun dieses Warning:
Systemeckdaten: Raspberry Pi, Plattform: linux, RAM: 3.7 GB, Node.js: v18.18.2, NPM: 9.8.1, js controller 6.0.11
Danke für deine Hilfe
Lg
TMinimax
PS. ev. hat @samke das gleiche Problem wie ich?
@tminimax + @samke Ich sehe gerade, dass ich bei der Prüfung, ob die Nodes generell antworten, maximal 20 Nodes in einem Rutsch abfragen darf. Daher kommt bei Euch der Fehler. Bei den älteren Versionen brauche ich die Prüfung nicht, weil dort noch keine Limitations unterstützt werden. Ich melde mich, wenn ich eine Korrektur habe.
Die Warnung bzgl. der jsonConfig ist bereits bekannt und kommt vom Admin-Adapter. Die ist meiner Meinung nach falsch und ich habe dort ein Issue aufgemacht. -
@tminimax + @samke Ich sehe gerade, dass ich bei der Prüfung, ob die Nodes generell antworten, maximal 20 Nodes in einem Rutsch abfragen darf. Daher kommt bei Euch der Fehler. Bei den älteren Versionen brauche ich die Prüfung nicht, weil dort noch keine Limitations unterstützt werden. Ich melde mich, wenn ich eine Korrektur habe.
Die Warnung bzgl. der jsonConfig ist bereits bekannt und kommt vom Admin-Adapter. Die ist meiner Meinung nach falsch und ich habe dort ein Issue aufgemacht. -
@mischroe: danke für dein erstes Feedback - bitte gib uns dann bescheid wenn es eine lösung (betreffend V.1.3.2 problemfix) gibt bzw. ich irgendwie helfen kann - danke
-
@mischroe: super Danke; läuft soweit (ich hoffe das sich an den Zuordnungen der Geräte nichts verändert hat - schaut aber gut aus).
Jedoch bekomme ich jetzt für die Geräte 20-24 eine "warning" (sind 2x Fenster-Objekte und 2x Innenrollo-Objekte). Also die letzten 4 wo er vorher abgebrochen hat. Diese "warnings" bekomme ich mit der alten Version des Adapters nicht; bedienen lassen sie sich aber über die Adapter-Objekte....
Ist da noch was faul?
-
@mischroe: super Danke; läuft soweit (ich hoffe das sich an den Zuordnungen der Geräte nichts verändert hat - schaut aber gut aus).
Jedoch bekomme ich jetzt für die Geräte 20-24 eine "warning" (sind 2x Fenster-Objekte und 2x Innenrollo-Objekte). Also die letzten 4 wo er vorher abgebrochen hat. Diese "warnings" bekomme ich mit der alten Version des Adapters nicht; bedienen lassen sie sich aber über die Adapter-Objekte....
Ist da noch was faul?
-
Hab bei mir das gleiche Verhalten. Auch die Warnung für 20 + 21.
Es werden aber trotzdem alle Produkte über 20 gefunden. -
-
Danke dir!
Es kommt im Log vorher auch die Info -> "Reading limitations for product 1..." und das für alle Produkte bis 21 bei mir.
Ich meine, diese Meldung gab es ja vorher auch nicht. Oder ist die nach 1.3.1 dazu gekommen? -
-
-
Hallo, ich hätte da jetzt noch ein kleines Problem/Wunsch.
Ich habe ein Hoftor (Category Gate opener) von Somfy an das KLF-200 verbunden, per iO.
Öffnen und schließen funktioniert wunderbar; auch der Status wird wunderbar ausgegeben.Mir fehlt jetzt nur die Funktion, nur einen Flügel von dem Doppelflügeltor zu öffnen.
Unter targetPositionRaw bzw. currentPositionRaw gibt es folgende Werte, welche auch als Status unter Objekte angezeigt werden, wenn ich das Tor per Fernbedienung bewege:
- 51200 -> zu
- 0 -> offen
- 54272 -> fährt auf/zu
- 63487 -> ein Flügel offen
Gebe ich nun bei "targetPositionRaw" -> 0 -> ein, fährt das Tor auf.
Gebe ich -> 51200 -> ein, fährt es zu.
Wenn ich aber -> 63487 -> eingebe, wechselt der Wert wieder auf 51200 (100%).Kann man die Werteliste zur Eingabe in diesem Feld vielleicht ergänzen?
Wäre top, wenn ich über ioBroker beim Tor auch nur einen Flügel steuern könnte.
Danke für die Hilfe!
-
Hallo, ich hätte da jetzt noch ein kleines Problem/Wunsch.
Ich habe ein Hoftor (Category Gate opener) von Somfy an das KLF-200 verbunden, per iO.
Öffnen und schließen funktioniert wunderbar; auch der Status wird wunderbar ausgegeben.Mir fehlt jetzt nur die Funktion, nur einen Flügel von dem Doppelflügeltor zu öffnen.
Unter targetPositionRaw bzw. currentPositionRaw gibt es folgende Werte, welche auch als Status unter Objekte angezeigt werden, wenn ich das Tor per Fernbedienung bewege:
- 51200 -> zu
- 0 -> offen
- 54272 -> fährt auf/zu
- 63487 -> ein Flügel offen
Gebe ich nun bei "targetPositionRaw" -> 0 -> ein, fährt das Tor auf.
Gebe ich -> 51200 -> ein, fährt es zu.
Wenn ich aber -> 63487 -> eingebe, wechselt der Wert wieder auf 51200 (100%).Kann man die Werteliste zur Eingabe in diesem Feld vielleicht ergänzen?
Wäre top, wenn ich über ioBroker beim Tor auch nur einen Flügel steuern könnte.
Danke für die Hilfe!
@samke Der Wert 63487 steht eigentlich dafür, dass kein Wert zurückgemeldet wird. Daher bewirkt auch das Setzen auf diesen Wert nichts. Prüfe doch mal, ob sich die Werte bei den Werten für die FP1-4 ändern, wenn Du das Tor mit der Fernbedienung bedienst. Ich würde vermuten, dass darüber evtl. die einzelnen Flügel gesteuert werden könnten. Evtl. musst Du über den refreshProduct-Wert das Auslesen der Werte anschubsen, während sich ein einzelner Flügel bewegt.
Falls dort Werte drin sind, müsste das Schreiben wie folgt funktionieren:- FP?TargetPositionRaw auf den gewünschten Wert setzen.
- Den targetPositionRaw auf 53760 setzen (=Current). Damit müsste der Transport des FP-Parameters ausgeführt werden.
Falls das nicht hilft, stelle das Logging des Adapters auf Debug (oder alles) um und starte danach mal die Bedienung eines einzelnen Flügels. Wenn wir Glück haben, sehen wir im Logging Nachrichten wie "Frame received GW_NODE_INFORMATION_CHANGED_NTF: ..." und auch ein paar andere. Das kannst Du dann hier posten und ich kann mir das ansehen.
Die Werteliste in den Raw-Feldern ist übrigens nur eine Ausfüllhilfe, d.h. man kann dort grundsätzlich jeden beliebigen Wert zwischen 0 und 65535 eintragen, aber nicht alle Werte sind auch mit einer Aktion definiert.
Aus der VELUX-Doku:
-
@samke Der Wert 63487 steht eigentlich dafür, dass kein Wert zurückgemeldet wird. Daher bewirkt auch das Setzen auf diesen Wert nichts. Prüfe doch mal, ob sich die Werte bei den Werten für die FP1-4 ändern, wenn Du das Tor mit der Fernbedienung bedienst. Ich würde vermuten, dass darüber evtl. die einzelnen Flügel gesteuert werden könnten. Evtl. musst Du über den refreshProduct-Wert das Auslesen der Werte anschubsen, während sich ein einzelner Flügel bewegt.
Falls dort Werte drin sind, müsste das Schreiben wie folgt funktionieren:- FP?TargetPositionRaw auf den gewünschten Wert setzen.
- Den targetPositionRaw auf 53760 setzen (=Current). Damit müsste der Transport des FP-Parameters ausgeführt werden.
Falls das nicht hilft, stelle das Logging des Adapters auf Debug (oder alles) um und starte danach mal die Bedienung eines einzelnen Flügels. Wenn wir Glück haben, sehen wir im Logging Nachrichten wie "Frame received GW_NODE_INFORMATION_CHANGED_NTF: ..." und auch ein paar andere. Das kannst Du dann hier posten und ich kann mir das ansehen.
Die Werteliste in den Raw-Feldern ist übrigens nur eine Ausfüllhilfe, d.h. man kann dort grundsätzlich jeden beliebigen Wert zwischen 0 und 65535 eintragen, aber nicht alle Werte sind auch mit einer Aktion definiert.
Aus der VELUX-Doku:
Wenn ich refreshProduct klicke (egal bei welchen Produkt), bekomme ich im Log -> Couldn't set state klf200.0.products.9.refreshProduct to value true: Timeout error
So komm ich aktuell leider wohl nicht an den Wert.
Hier das Log - es geht um Produkt 9, vielleicht sieht man hier mehr?
-
@samke Der Wert 63487 steht eigentlich dafür, dass kein Wert zurückgemeldet wird. Daher bewirkt auch das Setzen auf diesen Wert nichts. Prüfe doch mal, ob sich die Werte bei den Werten für die FP1-4 ändern, wenn Du das Tor mit der Fernbedienung bedienst. Ich würde vermuten, dass darüber evtl. die einzelnen Flügel gesteuert werden könnten. Evtl. musst Du über den refreshProduct-Wert das Auslesen der Werte anschubsen, während sich ein einzelner Flügel bewegt.
Falls dort Werte drin sind, müsste das Schreiben wie folgt funktionieren:- FP?TargetPositionRaw auf den gewünschten Wert setzen.
- Den targetPositionRaw auf 53760 setzen (=Current). Damit müsste der Transport des FP-Parameters ausgeführt werden.
Falls das nicht hilft, stelle das Logging des Adapters auf Debug (oder alles) um und starte danach mal die Bedienung eines einzelnen Flügels. Wenn wir Glück haben, sehen wir im Logging Nachrichten wie "Frame received GW_NODE_INFORMATION_CHANGED_NTF: ..." und auch ein paar andere. Das kannst Du dann hier posten und ich kann mir das ansehen.
Die Werteliste in den Raw-Feldern ist übrigens nur eine Ausfüllhilfe, d.h. man kann dort grundsätzlich jeden beliebigen Wert zwischen 0 und 65535 eintragen, aber nicht alle Werte sind auch mit einer Aktion definiert.
Aus der VELUX-Doku:
Vielleicht hilft das noch - ich hatte das ganze mal vor Jahren mit fhem und dem klf200 am laufen, da funkionierte es, nur ein Flügel zu öffnen. Ich habe dazu noch Infos gefunden, wie man damals den Weg zur Funktion gefunden hat.
Diese Daten hatte ich ausgelesen
Fußgänger offen (ein Flügel auf) 2022-03-06_08:03:59 Velux_9 updateCurrentPosition 2022-03-06_08:03:59 Velux_9 sessionID: 361 2022-03-06_08:03:59 Velux_9 MP: 55303 2022-03-06_08:03:59 Velux_9 FP8: 55303 2022-03-06_08:03:59 Velux_9 FP16: 55303 2022-03-06_08:03:59 Velux_9 MP: 63487 Beide Flügel auf 2022-03-06_08:09:52 Velux_9 updateCurrentPosition 2022-03-06_08:09:52 Velux_9 sessionID: 377 2022-03-06_08:09:52 Velux_9 FP8: 0 2022-03-06_08:09:52 Velux_9 FP16: 0 Tor (beide) zu 2022-03-06_08:12:32 Velux_9 updateCurrentPosition 2022-03-06_08:12:33 Velux_9 sessionID: 385 2022-03-06_08:12:33 Velux_9 FP8: 51200 2022-03-06_08:12:33 Velux_9 FP16: 51200Und daraus ergab sich dann folgender Befehl, womit nur der eine Flügel auf ging:
set Velux_9 raw MP=55303Wenn ich jetzt aber unter "targetPositionRaw" -> "55303" eingebe, passiert nichts - springt dann erst auf 63487 und dann auf 51200.
-
@samke Der Wert 63487 steht eigentlich dafür, dass kein Wert zurückgemeldet wird. Daher bewirkt auch das Setzen auf diesen Wert nichts. Prüfe doch mal, ob sich die Werte bei den Werten für die FP1-4 ändern, wenn Du das Tor mit der Fernbedienung bedienst. Ich würde vermuten, dass darüber evtl. die einzelnen Flügel gesteuert werden könnten. Evtl. musst Du über den refreshProduct-Wert das Auslesen der Werte anschubsen, während sich ein einzelner Flügel bewegt.
Falls dort Werte drin sind, müsste das Schreiben wie folgt funktionieren:- FP?TargetPositionRaw auf den gewünschten Wert setzen.
- Den targetPositionRaw auf 53760 setzen (=Current). Damit müsste der Transport des FP-Parameters ausgeführt werden.
Falls das nicht hilft, stelle das Logging des Adapters auf Debug (oder alles) um und starte danach mal die Bedienung eines einzelnen Flügels. Wenn wir Glück haben, sehen wir im Logging Nachrichten wie "Frame received GW_NODE_INFORMATION_CHANGED_NTF: ..." und auch ein paar andere. Das kannst Du dann hier posten und ich kann mir das ansehen.
Die Werteliste in den Raw-Feldern ist übrigens nur eine Ausfüllhilfe, d.h. man kann dort grundsätzlich jeden beliebigen Wert zwischen 0 und 65535 eintragen, aber nicht alle Werte sind auch mit einer Aktion definiert.
Aus der VELUX-Doku:
Ich habe jetzt noch weiter getestet und dabei den Adapter noch mal neu installiert.
Nun passiert was, wenn ich bei targetPositionRaw = 55303 eingebe - nur der eine Flügel fährt auf, juhu.
ABER, nachdem er aufgefahren ist, fährt er direkt ca. 30% wieder zurück/zu (geschätzt).
Im Feld targetPositionRaw fällt auf, dass der Wert hin und her springt. Ich gebe 55303 ein, danach springt es automatisch auf 63487, 51200, 63487, 51200 und dann zu letzt auf 63487.
51200 ist ja „zu“, das erklärt ja vielleicht warum das Tor wieder Richtung zu fährt und dann noch mal 51200 stopp es vielleicht?!
Die Frage ist, woher das kommt?
Bei der Fernbedienung fährt der Flügel nur auf (der eine Flügel) und bleibt dann auf der Position.Nachtrag: Wenn der Flügel dann nach der 30%igen Rückfahrt stehengeblieben ist und man dann noch mal 55303 sendet, dann fährt der Flügel wieder ganz auf und bleibt dort auch stehen, ohne erneute Rückfahrt.
-
Ich habe jetzt noch weiter getestet und dabei den Adapter noch mal neu installiert.
Nun passiert was, wenn ich bei targetPositionRaw = 55303 eingebe - nur der eine Flügel fährt auf, juhu.
ABER, nachdem er aufgefahren ist, fährt er direkt ca. 30% wieder zurück/zu (geschätzt).
Im Feld targetPositionRaw fällt auf, dass der Wert hin und her springt. Ich gebe 55303 ein, danach springt es automatisch auf 63487, 51200, 63487, 51200 und dann zu letzt auf 63487.
51200 ist ja „zu“, das erklärt ja vielleicht warum das Tor wieder Richtung zu fährt und dann noch mal 51200 stopp es vielleicht?!
Die Frage ist, woher das kommt?
Bei der Fernbedienung fährt der Flügel nur auf (der eine Flügel) und bleibt dann auf der Position.Nachtrag: Wenn der Flügel dann nach der 30%igen Rückfahrt stehengeblieben ist und man dann noch mal 55303 sendet, dann fährt der Flügel wieder ganz auf und bleibt dort auch stehen, ohne erneute Rückfahrt.
@samke Mir fällt in deinen fhem-Logs noch auf, dass dort auch die Parameter FP8 und FP16 mit angegeben sind. Der Adapter ist aktuell nur auf die Parameter FP1-4 aus gelegt, u.a. auch, weil das KLF200 in vielen Nachrichten nur die ersten 4 FPs unterstützt.
Kannst du bitte einmal folgende Tests machen und jeweils die Debug-Logs posten:- Beide Tore sind zu, dann mit der Fernbedienung einen Flügel öffnen
1b. Danach den Flügel wieder schließen. - Beide Tore sind auf, dann mit der Fernbedienung einen Flügel schließen
2b. Danach wieder öffnen. - Beide Tore sind zu, diesmal die targetPositionRaw auf 55303 setzen.
Problem dabei könnte jedoch sein, dass wir die FP8 und FP16 vermutlich trotzdem nicht protokolliert bekommen, weil die vom KLF200 nicht automatisch geliefert werden.
Aber eventuell kann man insbesondere bei Schritt 1 und 3 einen Unterschied in den Logs sehen, was die Nachrichten angeht, die versendet werden.
- Beide Tore sind zu, dann mit der Fernbedienung einen Flügel öffnen
-
@samke Mir fällt in deinen fhem-Logs noch auf, dass dort auch die Parameter FP8 und FP16 mit angegeben sind. Der Adapter ist aktuell nur auf die Parameter FP1-4 aus gelegt, u.a. auch, weil das KLF200 in vielen Nachrichten nur die ersten 4 FPs unterstützt.
Kannst du bitte einmal folgende Tests machen und jeweils die Debug-Logs posten:- Beide Tore sind zu, dann mit der Fernbedienung einen Flügel öffnen
1b. Danach den Flügel wieder schließen. - Beide Tore sind auf, dann mit der Fernbedienung einen Flügel schließen
2b. Danach wieder öffnen. - Beide Tore sind zu, diesmal die targetPositionRaw auf 55303 setzen.
Problem dabei könnte jedoch sein, dass wir die FP8 und FP16 vermutlich trotzdem nicht protokolliert bekommen, weil die vom KLF200 nicht automatisch geliefert werden.
Aber eventuell kann man insbesondere bei Schritt 1 und 3 einen Unterschied in den Logs sehen, was die Nachrichten angeht, die versendet werden.
Ich hatte irgendwie das Gefühl, das es an meiner ioBroker Maschine liegt. Ich habe daher dieses aus einem Backup restored und siehe da, nur der eine Flügel fährt nun mit 55303 auf und verweilt dort dann auch. Grundsätzlich funktioniert nun das gewünscht. (Was auch immer da vorher quer lief...)
Jetzt habe ich nur noch zwei kleine Probleme.
Sende ich 55303 per targetPositionRaw fährt das Tor wie gesagt auf die richtige Position. Danach bleibt aber als Wert bei currentPositionRaw = 63487 (also "kein Wert zurückgemeldet"). Daher weiß ich so nicht, steht das Tor im "Fußgängermodus" oder liegt ein Fehler am Tor vor.
Bei ganz auf/zu wird am Ende ja auch 0 bzw. 51200 zurückgemeldet.
Bekommt man das noch hin, das also nach einer 55303 Fahrt, am Ende als aktuelle Position 55303 gemeldet wird?
Bedarf es dafür die von dir gewünschten Logs, oder helfen die hier nicht für?Zweites Problem; Wenn ich mich jetzt per TahomaBox/App auf das Tor schalte, steht dort nun, das der Motor im "manuellen Modus" ist und nur vor Ort gesteuert werden kann. Das muss man dann immer erst bestätigen und dann kann man das ganze steuern. Gleiches gilt auch für die Alexa Anbindung vom Tor - diese lässt eine Steuerung jetzt auch nicht mehr zu.
Das muss irgendwie durch die ganzen Tests passiert sein. Hast du eine Idee, wie ich diese Warnung/Modus wieder weg bekomme?
Nebenfrage, gibt es bei dem Adapter die Funktion "priorityLevel"? Könnte es was damit zu tun haben? (das gab es bei Fhem, daher komme ich darauf) - Beide Tore sind zu, dann mit der Fernbedienung einen Flügel öffnen
Support us
493
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge