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

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.

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

Hallo,
erstmal danke an die Entwickler vom Interface. Ich teste diesen seit 2 Tagen, derzeit mit durchwachsenen Ergebnis bei mir. Folgendes Problem:
Der Adapter verliert immer wieder die Verbindung zur KLF 200. Ein manuelles neustarten des Adapter bringt manchmal ablöse, machnmal muss aber auch der host neugestartet werden. Ein Neustart der KLF 200 bringt keine Verbesserung.

Habt ihr sonst noch Ideen danke.

Das sieht für mich auch nach einem Netzwerk-Problem aus. Der KLF-200 trennt die Verbindung automatisch nach 15 Minuten, wenn keine Kommandos gesendet werden. Damit das nicht passiert, sendet der Adapter spätestens 5 Minuten nach dem letzten Kommando einen Status-Request ab, um den Status des Gateways zu erfragen.
Das scheint bei Dir auch ein paar Mal funktioniert zu haben, bevor dann irgendwann die Verbindung gekappt wurde. Ab da sieht man, dass zwischen jedem Timeout ziemlich genau 5 Minuten + 10 Sekunden liegen. (Die 10 Sekunden kommen daher, dass der Adapter maximal 10 Sekunden auf eine Antwort wartet.)

Viele Grüße
Michael

@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

@Haloda Ok, ich habe den Fehler gefunden. Ich werde eine neue Version erstellen.

@haloda Sind im KLF-200 evtl. noch Produkte hinterlegt, die nicht mehr vorhanden sind? Das kommt z.B. vor, wenn Teile getauscht wurden. Dann sind die Produkte noch da und beim Versuch, den Status der Produkte abzufragen, dauert es an diesem Punkt einfach sehr lange, bis das KLF-200 zurückmeldet, dass es keine Antwort bekommt. In Summe führt das dann dazu, dass der ioBroker den Adapter terminiert. Die Lösung wäre dann, das oder die fehlenden Produkte aus dem KLF-200 zu entfernen.
Oder hast Du evtl. sehr viele Produkte? Evtl. dauert das Auslesen dann einfach zu lange.
Kannst Du evtl. ein Log vom Adapter-Start posten? Danke.

Viele Grüße
Michael

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

Mir ist gerade noch etwas aufgefallen: nach einem "RefreshLimitations" geht "CurrentPosition" auf 100%...

Auch wenn noch nicht alles klappt: Ich kann es nicht oft genug sagen: der Adapter ist Klasse!

Tritt das Problem mit der Version 1.3.1 eigentlich noch immer auf? Ich kann das bei mir nämlich nicht mehr nachstellen. Ich kann mich aber daran erinnern, dass ich das bei mir auch gesehen hatte. Aber vielleicht habe ich den Fehler "versehentlich" mit einer anderen Korrektur behoben

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

Hallo,
erstmal danke an die Entwickler vom Interface. Ich teste diesen seit 2 Tagen, derzeit mit durchwachsenen Ergebnis bei mir. Folgendes Problem:
Der Adapter verliert immer wieder die Verbindung zur KLF 200. Ein manuelles neustarten des Adapter bringt manchmal ablöse, machnmal muss aber auch der host neugestartet werden. Ein Neustart der KLF 200 bringt keine Verbesserung.

Habt ihr sonst noch Ideen danke.

Das sieht für mich auch nach einem Netzwerk-Problem aus. Der KLF-200 trennt die Verbindung automatisch nach 15 Minuten, wenn keine Kommandos gesendet werden. Damit das nicht passiert, sendet der Adapter spätestens 5 Minuten nach dem letzten Kommando einen Status-Request ab, um den Status des Gateways zu erfragen.
Das scheint bei Dir auch ein paar Mal funktioniert zu haben, bevor dann irgendwann die Verbindung gekappt wurde. Ab da sieht man, dass zwischen jedem Timeout ziemlich genau 5 Minuten + 10 Sekunden liegen. (Die 10 Sekunden kommen daher, dass der Adapter maximal 10 Sekunden auf eine Antwort wartet.)

Viele Grüße
Michael