Adapter für VELUX KLF-200 Interface

[MiSchroe]

@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

[JohnDenver0815]

Habe soeben auf 1.3.1 aktualisiert, ebenso den Admin auf 7.1.5, der Rest war vorher schon up to date.

Der Admin-Adapter gibt folgende gelbe Warnung aus:

Spoiler

klf200 has an invalid jsonConfig: [{"instancePath":"/items/optionstab/items/automaticRebootCronTime","schemaPath":"#/definitions/cronProps/oneOf","keyword":"oneOf","params":{"passingSchemas":[0,1]},"message":"must match exactly one schema in oneOf"},{"instancePath":"/items/optionstab","schemaPath":"#/properties/items/patternProperties/%5E.%2B/allOf/9/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match "then" schema"},{"instancePath":"","schemaPath":"#/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match "then" schema"}]

Der klf200-Adapter gibt folgende rote Fehlermeldung aus:

Spoiler

Error: Client network socket disconnected before secure TLS connection was established

und meldet am Punkt "Verbunden mit Gerät oder Dienst" ebenfalls rot.

Ich warte ab was 1.3.2 bringt.

Edit: Nach einer Stunde Wartezeit, mehreren Adapter- und Hardwareneustarts sowie Anlesen des Downgradeprozesses hat der Adapter scheinbar Angst bekommen und spontane Selbstheilung erfahren. Es geht wieder alles wie gehabt.

Edit 2: Die gelbe Warnung vom Admin hat Bestand, sonst läuft alles ohne Einschränkungen.

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.

[MiSchroe]

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

@mischroe 1.3.2 hat mein Problem gelöst und läuft nun wieder einwandfrei - danke für das Update!

[oxident]

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

[samke]

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!

[samke]

Hab noch ein wenig „ausprobiert“.

Dabei hab ich festgestellt, dass das Problem nur mit der 1.3.2 Version vorkommt.

Mit Downgrade auf 1.3.1 (und auch kleiner - bis 1.2 getestet) funktioniert das ganze.

[tminimax]

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

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

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

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

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

[samke]

@tminimax

Hab bei mir das gleiche Verhalten. Auch die Warnung für 20 + 21.
Es werden aber trotzdem alle Produkte über 20 gefunden.

[MiSchroe]

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

[samke]

@mischroe

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?

[MiSchroe]

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

[tminimax]

@mischroe : danke - schaut gut aus - werde es mal laufen lassen

[samke]

@mischroe

Ja, nun sind die Warnungen weg, und bei mir alle 22 Produkte da.
Das alles bei Version v1.3.5.

Danke für die schnelle Umsetzung!!!

[samke]

@MiSchroe

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!

[MiSchroe]

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