Velux KLF200 mit Firmware 2.0.0.71 für io-homecontrol

[Prof. Dr. Peter Henning]

Pardon, aber das ist Unsinn. Die Stromversorgung erfolgt keinesfalls über den "Port", sondern über die 5V und GND-Leitungen der USB-Steckdose. Das Abschalten des Ports - jederzeit möglich per Software - trennt nicht diese Leitungen auf.

Es gibt ein dezidiertes HmIP- Gerät, das in eine USB-Leitung eingeschleift wird und diese Auftrennung macht.

Nutze ich seit einigen Jahren zum erzwungenen Reboot einer KLF200.

LG

pah

[CGR]

Genau.

[Sidey]

Wenn es in Homeassistant ohne diese Unterbrechung funktioniert, dann ist es doch ein Software Thema.


Hat da schon mal wer ein bisschen Analyse betrieben?
Grundsätzlich gibt es auch mqtt Übersetzer. Das könnte ja ein Weg sein das System robust zu integrieren. Den Übersetzer in einen eigenen Container und fertig.

Grüße Sidey

[postman]

Hallo zusammen,
ich hatte das gleiche Problem. Ich habe es mit Hilfe eines AT-Befehls gelöst, indem ich nachts ein reboot an die KLF200 sende. Seit dem läuft die KLF200 ohne Probleme. Verbindungsabbrüche gibt so gut wie gar nicht mehr.
Also einen Befehl wie diesen hier

Code Auswählen Erweitern

*23:59:00 set Velux reboot senden und gut ist. Da muss nicht mal mehr der Stromstecker gezogen werden.
Gruß
Uwe

[Sidey]

Das sind doch workarounds... Ich habe ein bisschen analysiert und werde einen Patch vorschlagen.


Grüße Sidey

[Prof. Dr. Peter Henning]

Da muss nicht mal mehr der Stromstecker gezogen werden.

Das Problem befindet sich offenbar im TCP/IP-Stack des Geräts. Denn von Zeit zu Zeit verabschiedet es sich aus dem WLAN - und dann kann man auch keinen "Reboot"-Befehl senden.
(Edit: Natürlich nicht WLAN, das Ding steckt im LAN. Egal, ist derselbe TCP/IP-Stack)

Ich ziehe auch nicht den Stecker, sondern schalte das Gerät per FHEM-Befehl für 5 Sekunden stromlos.

LG

pah

[Sidey]

Wenn es ohne Reboot mit homeassistant geht, dann liegt das Problem ja nicht ausschließlich in der Box. Oder?

[postman]

Hallo Sidey,
schwer zu sagen, ob es nur an der KLF200 liegt oder eventuell auch an FHEM. Das der Reboot nur ein Workaround ist, ist klar. Da die LAN-Verbindung aber nicht regelmäßig, also z.B. einmal pro Woche weg ist, sondern in unregelmäßigen Zeitabschnitten ausfällt, läßt sich der Grund dafür nicht ganz so einfach herausfinden. Das Problem könnte auch im Heimnetz liegen. WLAN wird ja für die Verbindung zu FHEM nicht genutzt. WLAN dient, wenn ich die Beschreibung der KLF200 richtig verstanden habe, nur für die Konfiguration der KLF200 genutzt. Die Steuerung der einzelnen Rollläden usw. wird über LAN gemacht. Deshalb vermute ich, dass das Problem in der KLF200 und nicht in FHEM zu suchen ist, da andere Komponenten, die ebenfalls über LAN von FHEM gesteuert werden, ohne solche Ausfälle laufen und es keine Verbindungsprobleme gibt. Eventuell ist auch nur das Netzteil der KLF200 der Übeltäter, weil es im Dauerbetrieb SPannungseinbrüche hat, die die KLF200 einfach nur in einen undefinierten Zustand bringen, der dann nur mit stromlos machen wieder behoben werden kann.

Gruß
Uwe

[dieter114]

Möglicherweise ist auch das was ganz Anderes:
Ich habe das 5V Netzteil gegen ein etwas Leistungfähigeres ausgetauscht.
Läuft seit 5 Tagen ohne Probleme.
Vor einigen Jahren hatte ich ein ähnliches Problem mit einem CUL der über den RPI
nicht richtig versorgt wurde.
Nur so als mögliche Lösung.....

[Prof. Dr. Peter Henning]

Also zunächst einmal hat die KLF200 kein eigenes Netzteil. Sondern hängt bei mir an einem Installationsschrank mit zwei Raspberry Pi und diversen anderen Komponenten, die eine sehr stabile und batteriegepufferte 5V-Versorgung haben.

Zweitens verstehe ich nicht, wieso bei postman die Rollläden und Fenster über "LAN" gesteuert werden. Wenn das so wäre, bräuchte man keine KLF200. Die hängt eben mit einer Seite im LAN, und steuert auf der anderen Seite über das proprietäre Funkinterface ioHomecontrol die Velux-Fenster (und einen Somfy-Funkschalter für einen weiteren Rollladen). Wo bitte ist dort "LAN"?

Dass der TCP/IP-Stack der KLF200 manchmal abstürzt, muss übrigens bei Homeassistant nicht so auftreten. Um den Unterschied zu sehen, müsste man wissen, wie genau HA auf die Box zugreift.


LG

pah

[Sidey]

Dass der TCP/IP-Stack der KLF200 manchmal abstürzt, muss übrigens bei Homeassistant nicht so auftreten. Um den Unterschied zu sehen, müsste man wissen, wie genau HA auf die Box zugreift.

Ich habe pyvlx untersucht.
Es gibt ein paar Unterschiede. Das der Socket hängt, liegt aber tatsächlich an der KLF200 Implementierung:



KLF200 nimmt keine Verbindung mehr an - woran es liegt (gemessen)

Der KLF200 erlaubt laut API-Doku zwei gleichzeitige TCP-Verbindungen auf Port
51200. Sind beide belegt, weist er neue mit "Connection refused" ab. Das ist das bekannte Symptom: irgendwann geht gar nichts mehr und nur Stromlos-Machen hilft.

Ich habe das mit einer zweiten FHEM-Instanz gegen eine echte Box durchgemessen
(Firmware 0.2.0.0.71.0, per LAN angebunden). Entscheidend ist, ob die Box beim Verbindungsende noch ein TCP-FIN bekommt:
- FHEM geordnet beendet (shutdown): Slot sofort wieder frei, Reconnect nach rund 6 Sekunden.
- FHEM hart gekillt (kill -9): ebenfalls sofort frei. Der Kernel schickt das FIN auch dann noch.

- Netzverbindung gekappt (Kabel raus, WLAN weg, Container vom Netz getrennt):
  Slot bleibt belegt. Bei mir über 28 Minuten, dann habe ich die Messung abgebrochen.

Im dritten Fall greift auch das dokumentierte Timeout nicht. In der API-Doku steht in Abschnitt 4.1: "TCP/IP socket will be closed after 15 min, with no communication". Ein tcpdump über fünf Minuten nach dem Abriss zeigt, dass die Box an die tote Verbindung überhaupt nichts mehr sendet - und sie trotzdemnicht aufräumt. Ein serverseitiges TCP-Keepalive hat sie offenbar nicht.



Was das praktisch heißt:

1. Ein abgestürztes FHEM oder ein Docker-Neustart ist unkritisch. Das Problem entsteht bei Netzproblemen: WLAN-Abriss, Switch-Neustart, Kabel raus oder VM-Snapshot.
2. Solange noch ein Slot frei ist, hilft "set <name> reboot". Der Reboot gibt beide Slots frei, das hat bei mir mehrfach zuverlässig funktioniert.
3. Genau dafür ist das Attribut autoReboot im Modul gedacht.
4. Sind beide Slots verbrannt, kommt man nicht mehr hinein, um den Reboot abzusetzen. Dann bleibt tatsächlich nur Strom weg.

Wer die Box per WLAN anbindet oder öfter Netzunterbrechungen hat, trifft es entsprechend häufiger. Im Log sieht man es als "Can't connect to ...
Connection refused (111)".

pyvlx bootet die Box nicht wenn ein Slot belegt ist.
Es mag noch andere Situationen geben, die einen Slot blockieren. Vielleicht wird auch 1x am Tag der blockierte freigegeben.


Grüße Sidey