Es gibt eine neue Version 1.3.1 des Adapters, derzeit erstmal nur im latest-Repository. Wenn sich der Adapter bewährt hat, kann ich den in ein paar Tagen auch in das stable-Repository übertragen lassen.

Was ist neu? Details s.u.

1. Unterstützung von Limitations. Stichwort: Regensensor.
2. Geräteverwaltung in den Einstellungen ermöglicht (verwalten von Geräten, Gruppen, Szenen).
3. Mindestens erforderliche Node-Version auf 18.x angepasst.

Fehlerbehebungen u.a.

1. Neu angelernte Geräte wurden erst nach Neustart des Adapter erkannt. Jetzt funktioniert das auch im laufenden Betrieb.
2. Aktualisierung von verwendeten Paketen.
3. Zusätzliche, automatisierte Code-Prüfungen hinzugefügt (sog. Linting) und die daraus gemeldeten Fehler behoben.
4. Potentiell mögliche Speicherlecks (memory leaks) behoben.

Limitations (z.B. Regensensor)
Jedes im KLF angelernte Gerät verfügt grundsätzlich immer über einen sog. Main Parameter (MP) und bis zu 16 weiteren Functional Parameters (FP1-FP16).

Der MP steuert dabei normalerweise die Hauptfunktion des Geräts, also z.B. Fenster öffnen, Rollladen hoch/runter, Licht an/aus/dimmen, usw.

Über die FPs lassen sich ggfs. vorhandene Nebenfunktionen eines Geräts steuern, bei einer Lampe könnte das z.B. der Farbwert der Lampe sein. Bei Fenstern und Rollläden ist das z.B. die Geschwindigkeit, mit der sich die Fenster oder Rollläden öffnen und schließen.

Im Adapter unterstütze ich derzeit generell nur den MP und die FP1-4, da das das bisherige Maximum ist, was von VELUX dokumentiert wurde.

Auch die Begrenzungen können für jeden dieser Parameter grundsätzlich unterschiedlich eingestellt sein, sind aber nicht immer sinnvoll und werden daher von den jeweiligen Geräten nicht unbedingt unterstützt. Ob ein FP limitiert sein kann oder nicht, ist leider nicht abfragbar. Ich erkenne es aber daran, dass ich beim Versuch, die Limitations abzufragen, eine unsinnige Antwort bekomme. Parameter, die eine unschlüssige Antwort liefern, werden daher bei den Datenpunkten für die Limitations nicht erstellt.

Daher gibt es für den MP bzw. für jeden erkannten FP die folgenden Datenpunkte (am Beispiel MP):

• limitationMPOriginator: Das ist die Herkunft der Begrenzung. Obwohl es auch den Regensensor als möglichen Wert gibt, steht bei mir immer nur "Emergency controlled". Das kann je nach Fenstertyp sicherlich unterschiedlich sein.
• limitationMPTimeRaw: Wert von 0-255. 0 = 30 Sekunden, 1 = 60 Sekunden usw. bis 252 = 7590 Sekunden. 253 entspricht unendlich und 254 und 255 haben noch Sonderwerte, die eigentlich nur beim Setzen von Begrenzungen eine Bedeutung haben.
• limitationMPTime: Hier rechne ich die Werte in Sekunden um, sofern möglich, sonst steht hier null drin.
• limitationMPMinRaw, limitationMPMaxRaw: Der Wertebereich für einen Parameter liegt zwischen 0 und 51200. Über den jeweiligen Min/Max-Wert wird dieser Wertebereich weiter eingeschränkt, d.h. der Raw-Wert des Parameters muss zwischen den Werten von limitationMPMinRaw und limitationMPMaxRaw liegen.
• limitationMPMin, limitationMPMax: Wie limitationMPMinRaw und limitationMPMaxRaw, nur dass die Werte auf Prozentwerte (0-100) umgerechnet werden. Achtung: Es gibt Geräte, z.B. Fenster, bei denen die Prozentskala umgekehrt ist, d.h. der Raw-Wert 0 entspricht 100% und der Raw-Wert 51200 entspricht 0%. Das führt dazu, dass dann der Min-Wert als 100% und der Max-Wert als 0% angezeigt wird. Das ist verwirrend, aber leider wurde das so von den Herstellern designed.

Die Aktualisierung der Werte findet leider nicht automatisch statt, weil das KLF-200 darüber aktiv keine Informationen sendet. Daher gibt es bei jedem Produkt den Datenpunkt refreshLimitation, mit dem Ihr manuell oder z.B. über ein einfaches Skript/Blockly die Aktualisierung anstoßen könnt. Ich habe das bewusst nicht in den Adapter eingebaut, da ich z.B. vermeiden möchte, dass Akku-betriebene Geräte über Gebühr belastet werden. Um z.B. Regen zu erkennen, müsste ich auch nicht unbedingt sämtliche Fenster abfragen, da könnte ich mich z.B. auf eins je Himmelsrichtung beschränken.

Geräteverwaltung
In den Einstellungen gibt es einen neuen Tabreiter für die Geräteverwaltung. Dort könnt ihr folgendes tun:

1. Vorhandene Geräte löschen
2. Vorhandene Geräte umbenennen
3. Neue Geräte suchen (z.B. wenn ein Fenstermotor ausgetauscht wurde)
4. Gruppen anlegen (Gruppen können immer nur Geräte des gleichen Typs enthalten, also z.B. nur mehrere Fenster)
5. Gruppen umbenennen/bearbeiten
6. Gruppen löschen
7. Szenen löschen
8. Szenen umbenennen
9. Szenen erstellen, dabei muss die Position der Geräte während der Szenen-Erkennung mit einer herkömmlichen Fernbedienung verändert werden

Für diese grundlegenden Verwaltungsaufgaben muss man sich also nicht mehr per WLAN mit dem KLF-200 verbinden.

Viel Spaß beim Testen und mit den neuen Möglichkeiten!

Gruß
Michael

@boostar sagte in Adapter für VELUX KLF-200 Interface:

Hallo zusammen,

ich habe die aktuellste Version des Adapters installiert, könnte mir jemand verraten welche Datenpunkte für den Regensensor verantwortlich sind?
Außerdem interessiert mich ob man die "Aufhebung des Regensensors" welche eigentlich mit den Tasten "Up + OK" auf der Fernbedienung ausgeführt wird, auch iwie per ioBroker ausführen kann?

LG
BooStar

Die Datenpunkte limitationMPMin/Max zeigen die Begrenzung durch den Regensensor an. Bei mir liegt der Wert dann bei 7%, dass kann aber bei anderen Fenster-Typen evtl. anders sein. Die Daten müssen regelmäßig über den Datenpunkt refreshLimitation aktualisiert werden, da diese Daten von den Fenstern bzw. vom KLF-200 nicht automatisch aktualisiert werden. Der Adapter macht das nicht automatisch, um die Akkus von Solarfenstern nicht zu stressen.
Velux selbst fragt die Fenster in den folgenden Intervallen ab, evtl. sollte man sich daran orientieren:

• Strombetriebene Geräte oder bei voll geladenem Akku: Alle 15 Minuten.
• Akku im mittleren Bereich geladen: Jede Stunde.
• Akku im kritischen Bereich geladen: Alle 24 Stunden.

Aktuell kann man das über den Adapter noch nicht übersteuern, da die Logik dafür nicht durch das Setzen eines einzelnen Datenpunkts zu implementieren ist.

Ich habe einen Punkt auf meiner Liste, um beliebige Nachrichten an das KLF-200 senden zu können. Damit sollten sich auch komplexe Aufgaben einfacher lösen lassen.

Es gibt jetzt eine neue Version 0.9.4, welche die Admin 3 Oberfläche unterstützt. Außerdem habe ich im Repository eine kleine Dokumentation mit Screenshots erstellt.

Folgende Bug Fixes sind in Version 0.9.5 eingebaut:

• Bei den "products" wird der Datenpunkt level nun als level.blind erstellt.

• Bei den "scenes" wird der Datenpunkt run nun als switch erstellt.

Damit die Datenpunkte aktualisiert werden, müsst Ihr diese entweder erst im Objektbaum löschen, oder Ihr passt sie selbst im Objektbaum an.

@oxident Grundsätzlich sollte das funktionieren. Die Frage ist, was die Parameter im einzelnen bedeuten. Du könntest im KLF Szenen definieren und dann gucken, welche Eigenschaften wie gesetzt werden.

Hallo,

es gibt eine neue Version des Adapters (1.1.2). Derzeit ist die Version erstmal nur über NPM verfügbar, d.h. im Experten-Modus kann die Version von NPM installiert werden.

Wesentliche neue Features:

• Die funktionalen Parameter FP1-4 können nun ebenfalls über Datenpunkte angesteuert werden (targetFP1Raw-targetFP4Raw). Darüber ist z.B. die Geschwindigkeit der Velux-Fenster steuerbar, aber auch Dinge wie Lamellenwinkel können gesteuert werden.
  Wichtig dabei ist, dass die funktionalen Parameter selbst nichts auslösen, sie werden immer nur in Verbindung mit der targetPosition berücksichtigt.
• Bei den Szenen ist es nun ebenfalls möglich, die Geschwindigkeit über den Datenpunkt velocity zu steuern

Beispiel 1:
Ich möchte das Fenster mit langsamer Geschwindigkeit auf 50% öffnen:

• targetFP1 auf 0 setzen
• targetPosition auf 50 setzen

Beispiel 2:
Ich möchte das Fenster mit schneller Geschwindigkeit wieder schließen:

• targetFP1 auf 51200 setzen
• targetPosition auf 0 setzen

Beispiel 3:
Bei Geräten über den funktionalen Parameter direkt eine Bewegung auslösen:

• targetFPx auf den gewünschten Wert setzen (zwischen 0 und 51200, alternativ einen der Spezialwerte, Mapping ist im Datenpunkt hinterlegt)
• targetPosition auf den bereits vorhandenen Wert setzen

Beispiel 4:
Eine Szene langsam ausführen:

• velocity auf 1 setzen (silent)
• run auf true setzen

Viel Spaß mit den neuen Funktionen!

@oxident Wenn der target-Wert nicht auf Ignore steht, dann wird der Wert auch immer übergeben. Wenn also z.B. das Fenster immer im Silent-Mode geöffnet werden soll, muss der targetFP1Raw auch nur einmal gesetzt werden.

Hallo Zusammen,

ich habe eine neue Version 1.2.0 des Adapters erstellt. Ihr könnt die neue Version über den Expertenmodus per NPM-Package installieren.

Neue Funktionen:

• Es gibt einen neuen Datenpunkt "refreshProduct" an jedem Produkt. Wenn man diesen auf true setzt, wird die aktuelle Position sowie die aktuelle Position etwaiger Funktionsparameter (FP1-FP4) vom Gerät neu gelesen. Das ist z.B. dann notwendig, wenn man ein Fenster oder Rollladen mit einer einfachen Fernbedienung bedient hat. Dann wird der aktuelle Wert nämlich vom Rollladen oder Fenster nicht an den KLF-200 übermittelt. Man könnte jetzt z.B. über ein Skript bei Bedarf regelmäßig den Status aktualisieren lassen. Achtung: Das kostet bei den Solarprodukten natürlich Akku, also nicht zu häufig abfragen.
• Es gibt einen neuen Datenpunkt "refreshScenes" bei den Scenes. Damit kann ich die Szenen aktualisieren lassen, wenn ich z.B. eine neue Szene über das Web-Interface angelegt habe. Bisher musste man dafür immer den Adapter neu starten.
• Der Datenpunkt "targetPositionRaw" kann jetzt auch geschrieben werden. Damit sind außer den bisherigen Prozent-Werten über "targetPosition" auch weitere Änderungen möglich. Es gibt einige Spezialwerte, z.B. um ein Fenster um 10% weiter zu öffnen usw. Ich verweise an dieser Stelle auf die offizielle Velux-Doku, in der die Werte genauer spezifiziert sind. Nicht alle Werte werden von allen Produkten unterstützt.
• Im Einstellungsdialog wird genauer beschrieben, welches Passwort zu verwenden ist. Leider ist das bei Velux in Abhängigkeit von der Historie der KLF-200 nie ganz eindeutig. Ich hoffe, dass die Beschreibung hilft.

Fehlerbehebungen:

• Manchmal war im Protokoll eine Unhandled Promise Rejection-Exception zu finden, wenn es unter bestimmten Umständen zu Timeouts kam. Der Fehler ist behoben.
• Ab einer bestimmten Version des Admin-Adapters wurde eine Fehlermeldung über eine fehlende property ins Protokoll geschrieben. Der Fehler ist behoben.
• Warnungen vom Adapter-Checker wurden behoben.
• Automatisierte Unit-Tests haben unter Linux und MacOS nur 20 der über 260 Tests ausgeführt. Unter Windows wurden immer alle Tests durchgeführt. Ist nun behoben.

@oxident Ich habe diese hier, und da tritt das "Problem" auf:

@oxident Das Lesen der Limitations dauert leider ziemlich lange. Für jedes Produkt muss die aktuelle Limitation für Min und Max jeweils getrennt abgefragt werden. Und dann frage ich das für 5 Parameter ab, MP und FP1-4. Falls ich z.B. für Min FP1 schon eine fehlerhafte Antwort bekommen, frage ich Max FP1 gar nicht mehr ab. Aber bei FP2 muss ich natürlich trotzdem prüfen. Und je nach Anzahl der Produkte dauert das dann ein bisschen. Ein Timeout hatte ich dabei allerdings noch nie.

Den Reboot hatte ich aufgrund Deiner Rückmeldung heute morgen extra noch einmal getestet. Der läuft bei mir sauber durch. Zur Not mal bitte das Logging in den Adapter-Settings auf Alles stellen und dann mal gucken, ob was kommt.

@boostar sagte in Adapter für VELUX KLF-200 Interface:

Hallo zusammen,

ich habe die aktuellste Version des Adapters installiert, könnte mir jemand verraten welche Datenpunkte für den Regensensor verantwortlich sind?
Außerdem interessiert mich ob man die "Aufhebung des Regensensors" welche eigentlich mit den Tasten "Up + OK" auf der Fernbedienung ausgeführt wird, auch iwie per ioBroker ausführen kann?

LG
BooStar

Die Datenpunkte limitationMPMin/Max zeigen die Begrenzung durch den Regensensor an. Bei mir liegt der Wert dann bei 7%, dass kann aber bei anderen Fenster-Typen evtl. anders sein. Die Daten müssen regelmäßig über den Datenpunkt refreshLimitation aktualisiert werden, da diese Daten von den Fenstern bzw. vom KLF-200 nicht automatisch aktualisiert werden. Der Adapter macht das nicht automatisch, um die Akkus von Solarfenstern nicht zu stressen.
Velux selbst fragt die Fenster in den folgenden Intervallen ab, evtl. sollte man sich daran orientieren:

• Strombetriebene Geräte oder bei voll geladenem Akku: Alle 15 Minuten.
• Akku im mittleren Bereich geladen: Jede Stunde.
• Akku im kritischen Bereich geladen: Alle 24 Stunden.

Aktuell kann man das über den Adapter noch nicht übersteuern, da die Logik dafür nicht durch das Setzen eines einzelnen Datenpunkts zu implementieren ist.

Ich habe einen Punkt auf meiner Liste, um beliebige Nachrichten an das KLF-200 senden zu können. Damit sollten sich auch komplexe Aufgaben einfacher lösen lassen.

@samke Das KLF200 sendet über die Nachricht GW_NODE_STATE_POSITION_CHANGED_NTF die currentPosition zurück. Das sind dann die Werte, die ich im Adapter anzeige. Da müsste man sich evtl. nochmal durch ein neues Log "durchwühlen". Wichtig wäre alles ab dem Eintrag "Frame sent GW_SEND_COMMAND_REQ: ...", der durch das Setzen des Wertes erzeugt wird.
Aber ich will da auch nicht zu viel Hoffnung machen, denn schließlich kann der Adapter nur das anzeigen, was geliefert wird.
Der PriorityLevel wird von mir derzeit fest auf 3 gesetzt. Das nennt sich User Level 2 und entspricht dem Standwert von Fernbedienungen (zumindest lt. VELUX-Dokumentation). Das könnte ich aber vergleichsweise einfach als weiteren Datenpunkt zur Verfügung stellen. Hast Du bei fhem einen anderen Wert verwendet?

Musst Du jetzt jedes Mal bestätigen? Kann man den Motor evtl. einmal Stromlos schalten?

@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:

1. Beide Tore sind zu, dann mit der Fernbedienung einen Flügel öffnen
   1b. Danach den Flügel wieder schließen.
2. Beide Tore sind auf, dann mit der Fernbedienung einen Flügel schließen
   2b. Danach wieder öffnen.
3. 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.

@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:

1. FP?TargetPositionRaw auf den gewünschten Wert setzen.
2. 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 @tminimax Die Limitations sind seit Version 1.3.0 enthalten. Ich habe eine neue Version 1.3.5 erstellt, die Ihr über npm installieren könnt. Damit sollten die Warnings verschwinden und die Limitations-Datenpunkte auch für die Produkte größer 20 angelegt werden.

@samke @tminimax Muss ich angucken. Es scheint wohl noch ein Fehler drin zu sein, dass der Adapter ab dem 21. Produkt die Prüfung falsch durchläuft. Ich vermute, dass die Limitations bei den gemeldeten Produkten nicht funktionieren dürften.

@tminimax @samke Ich habe eine neue Version 1.3.4. Die sollte vermutlich morgen im beta-Repository vorhanden sein oder Ihr könnt die bereits jetzt über npm installieren. Ich konnte den Fehler mit meinen Tests nachstellen. Wie vermutet lag es daran, dass Ihr mehr als 20 Produkte installiert habt.

@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.

@johndenver0815 sagte in Adapter für VELUX KLF-200 Interface:

Edit 3: Da mich die Warnung auf ein CRON-Thema schließen lässt, habe ich etwas damit herumgespielt. Wenn ich mit der Einstellung "einfach -> bestimmte Zeit -> 03:00" die Wochentage nach und nach deselektiere, fliegt mir beim letzten Häkchen die ganze GUI um die Ohren.

Das die GUI wegfliegt, ist ein Bug im Admin bzw. in einer der verwendeten Komponenten. Ich habe ein entsprechendes Issue aufgemacht.

Dass eine Warnung bzgl. ungültiger jsonConfig protokolliert wird, liegt daran, dass ich die zwei möglichen Varianten (simple/complex) für die Eingabe des CRON-Zeitpunkts konfiguriert habe. Das ging auch mal, aber da hat man ebenfalls etwas geändert. Ich könnte demnach nur noch eine der beiden Varianten anbieten. Ich habe bei den Entwicklern nachgefragt, ob das so sein soll oder ob das auch ein Fehler ist.

@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