Velux KLF200 mit Firmware 2.0.0.71 für io-homecontrol

[curt]

Guten Tag Bernd und alle,

derzeit in Auslieferung sind zwei "Velux-Wohnraumdachflächenfenster Integra Solar incl. Eindeckrahmen EZ 1000 und ELX, Regensensor und Funk-Wandschalter", und "EZ 2000 Möglichkeit zur Einbindung in andere Hausautomationssysteme mit Velux INTEGRA Interfaces". Ich gehe mal davon aus, dass damit "KLF 200" gemeint ist. Das frage ich derzeit nach.

Um das nun wiederum (ich habe hier u.a. Homematic und ZWave) in mein FHEM einzubinden, bin ich hier richtig? Fehlt mir von der Hardware her noch eine Voraussetzung?

Bzgl. der Integration in FHEM: Wie muss ich dann vorgehen? Gibt es irgendwo eine Roadmap oder fange ich in diesem Thread auf Seite 1 an? (Oder sind die Infos auf Seite 1 veraltet?)

Ich bitte freundlich um Hinweise.

[Elektrolurch]

Hallo,

ich bekomme manche Events doppelt, obwohl das Attribut "event-on-change-reading" auf .* gesetzt ist:

Der Befehl "set Gz_Dachfenster pct 30" (start bei pct = 0 = geschlossen, führt zu folgendem Log-Eitnrag:

Code: [Auswählen]

2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd pct val 30
2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd target val 30
2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd execution val öffnet
2022.10.12 12:12:54 3: KLF200Node (Gz_Dachfenster) Unknown OperatingState ID: 83
2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd execution val stop
2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd execution val öffnet
2022.10.12 12:13:15 4: Fenster_notifiy: GästeBad-Sauna rd pct val 30
2022.10.12 12:13:15 4: Fenster_notifiy: GästeBad-Sauna rd 30 val
2022.10.12 12:13:15 4: Fenster_notifiy: GästeBad-Sauna rd execution val stop
Der "set"-Befehl wird korekt mit "target 30" quittiert.
Dann kommt allerdings ein "Unknown OperatingState ID: 83
" mit einem "execution stop".
Und dann erneut ein "pct 30" und das Fenster fährt auf die gewünschte Position.

Am Fenster merkt man davon nichts. Es fährt sofort auf die gewünschte Position.

Elektrolurch

[HarryT]

Hi

I hope this thread is a good place for my problem.
 
I am running FHEM 6.1 on a RaspberryPi 3

Unfortunately I had problems with a faulty powersupply for my Raspberry so I started some experimenting and updated the KLF200 FHEM module to the version dated (interrnal) 2022-30-08
After my experiments and the update to the newer KLF200 version my KLF200 freezes every night. I don't know yet if it is every night at the same time and I can not yet identify an event which could be the trigger

In the fhem logging I see:
KLF200 (KLF200) GW_GET_STATE_CFM Queue is not empty! Run queue again. queueSize 89 subState Performing task in Command Handler

In the KLF200 logging I see for example:
2022-12-27_03:20:04 KLF200 queueSize: 2
2022-12-27_03:30:04 KLF200 subState: Performing task in Command Handler
2022-12-27_03:30:04 KLF200 queueSize: 1
2022-12-27_03:40:04 KLF200 subState: Performing task in Command Handler
2022-12-27_03:40:05 KLF200 queueSize: 0
2022-12-27_03:50:04 KLF200 subState: Performing task in Command Handler
2022-12-27_04:00:04 KLF200 subState: Performing task in Command Handler
2022-12-27_04:10:04 KLF200 subState: Performing task in Command Handler

I am able to unfreeze the KLF200 by unplugging the RaspberryPI and the KLF200 and plugging in the power again AND login on the http://klf200.velux. (just login, no actions, is enough)
Actually I am not sure if all 3 are necessary. But previously it was not enough to unplug the RasperryPI and the KLF200, but it might be that the KLF200 was locked for some time due to my tests.

In the past such a freeze was very occasionally and most when I changed anything. I don't know if it has anything to do with the newer KLF200 and KLF200Node version.

Anybody had the same experience?

Anybody have an idea how to solve this?

What is the preferred way to unlock a frozen KLF200 ?
  Maybe: - unplug the KLF200 and plugin again
               - empty in fhem the KLF queue
  But I would love if I could do it all from fhem.

Is there any drawback if I place the previous version of 83_KLF200.pm and 83_KLF200Node.pm in the FHEM directory again?  Maybe that would stabilize my environment.

Thanks in advance for any help

{HT}



 

[ramses]

Hi

I hope this thread is a good place for my problem.
 
I am running FHEM 6.1 on a RaspberryPi 3

Unfortunately I had problems with a faulty powersupply for my Raspberry so I started some experimenting and updated the KLF200 FHEM module to the version dated (interrnal) 2022-30-08
After my experiments and the update to the newer KLF200 version my KLF200 freezes every night. I don't know yet if it is every night at the same time and I can not yet identify an event which could be the trigger

In the fhem logging I see:
KLF200 (KLF200) GW_GET_STATE_CFM Queue is not empty! Run queue again. queueSize 89 subState Performing task in Command Handler

In the KLF200 logging I see for example:
2022-12-27_03:20:04 KLF200 queueSize: 2
2022-12-27_03:30:04 KLF200 subState: Performing task in Command Handler
2022-12-27_03:30:04 KLF200 queueSize: 1
2022-12-27_03:40:04 KLF200 subState: Performing task in Command Handler
2022-12-27_03:40:05 KLF200 queueSize: 0
2022-12-27_03:50:04 KLF200 subState: Performing task in Command Handler
2022-12-27_04:00:04 KLF200 subState: Performing task in Command Handler
2022-12-27_04:10:04 KLF200 subState: Performing task in Command Handler

I am able to unfreeze the KLF200 by unplugging the RaspberryPI and the KLF200 and plugging in the power again AND login on the http://klf200.velux. (just login, no actions, is enough)
Actually I am not sure if all 3 are necessary. But previously it was not enough to unplug the RasperryPI and the KLF200, but it might be that the KLF200 was locked for some time due to my tests.

In the past such a freeze was very occasionally and most when I changed anything. I don't know if it has anything to do with the newer KLF200 and KLF200Node version.

Anybody had the same experience?

Anybody have an idea how to solve this?

What is the preferred way to unlock a frozen KLF200 ?
  Maybe: - unplug the KLF200 and plugin again
               - empty in fhem the KLF queue
  But I would love if I could do it all from fhem.

Is there any drawback if I place the previous version of 83_KLF200.pm and 83_KLF200Node.pm in the FHEM directory again?  Maybe that would stabilize my environment.

Thanks in advance for any help

{HT}

long story short: the problem is in the KLF200 box. The most actual firmware 2.0.0.71 still has this issue (i suppose it is a sw problem with the api) and velux doesn't care about this. In my eyes the KLF200 seems to be end of life from Velux point of view.

the solution was until a few months ago a regulary reboot sent by the FHEM module KLF200 at a time where KLF200 is still responsive. This "automatic" reboot once a day (in the night) seems to be removed without notice which was a suprise for me. If it wasn't removed, then it doesn't work anymore as before.
Anyway, the solution now is simple: define an "at" which will perform the reboot for you e.g. at 3.00 a clock in the night

Code: [Auswählen]

define rebootKLF200 at *03:00:00 set <KLF device> reboot   (not sure if the set command is correct, i have no access to my fhem now)

maybe there is also another solution (priority Level?) but this solution is working reliable for me!

good luck!

[HarryT]

Hi Ramses

Thanks for your quick answer. It seems you problem was the same as mine.

I have an AT which triggers every 4 hours. I will start by adding the reboot of KLF200 in this event.

We will see what happens tonight.

{HT}

[buennerbernd]

Hallo,

ich bekomme manche Events doppelt, obwohl das Attribut "event-on-change-reading" auf .* gesetzt ist:

Der Befehl "set Gz_Dachfenster pct 30" (start bei pct = 0 = geschlossen, führt zu folgendem Log-Eitnrag:

Code: [Auswählen]

2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd pct val 30
2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd target val 30
2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd execution val öffnet
2022.10.12 12:12:54 3: KLF200Node (Gz_Dachfenster) Unknown OperatingState ID: 83
2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd execution val stop
2022.10.12 12:12:54 4: Fenster_notifiy: GästeBad-Sauna rd execution val öffnet
2022.10.12 12:13:15 4: Fenster_notifiy: GästeBad-Sauna rd pct val 30
2022.10.12 12:13:15 4: Fenster_notifiy: GästeBad-Sauna rd 30 val
2022.10.12 12:13:15 4: Fenster_notifiy: GästeBad-Sauna rd execution val stop
Der "set"-Befehl wird korekt mit "target 30" quittiert.
Dann kommt allerdings ein "Unknown OperatingState ID: 83
" mit einem "execution stop".
Und dann erneut ein "pct 30" und das Fenster fährt auf die gewünschte Position.

Am Fenster merkt man davon nichts. Es fährt sofort auf die gewünschte Position.

Elektrolurch

Kannst du das beobachtete Verhalten immer noch beobachten?

Zur Erklärung:
execution ist ein vom KLF200Node-Modul berechnetes Reading, aus OperatingState und target.

Unknown OperatingState ID: 83 wird geloggt, wenn eine ID vorbeikommt, die in der Velux-Doku nicht vorkommt. Es gibt hier aber einen Fallback. Wenn man von der ID nur die letzten 3 Bits nimmt, dann kommen plausible Werte heraus.

Bei dir 83 => 3 => "Waiting for power"

Dieser OperatingState kommt bei einigen Geräten für den Bruchteil einer Sekunde.
Bei "Waiting for power" nimmt das KLF200Node-Modul als execution = "stop".
Deshalb flackert bei dir dar Reading execution.

Wenn das bei dir immer reproduzierbar ist, dann könnte ich mir vorstellen, dass es besser ist, die execution bei "Waiting for power" einfach unangetastet zu lassen. Dann würde das kurze stop einfach wegfallen.

[HarryT]

Hi

Yesterday I updated my Raspberry software and since then my KLF200 is logged in but does not send signals to the somfy devices. I had long wait times, > 12 hours without touching anything, and had the KLF200 disconnected from power for about 1,5 hour. It connects quickly but doesn't work.  The status of the nodes I can see in FHEM is not correct and I can't send a command. It is placed in the queue but nothing happens.
I emptied the queue several times but that does not help.

If I login on the KLF200 and try to blink a somfy device I get the message that the device is busy.

So I think it is not a FHEM module problem, but the KLF200 is locked somehow.

Anybody recognizes this behavior and has a solution?

Thanks in advance.

{HT}

[HarryT]

Answer to myself

The issues was solved by:
- disconnect the KLF200 from power
- disconnect the KLF200 from the ethernet
- connect the KLF200 to ethernet
- connect the KLF200  to power

After that it worked nice as before

{HT}

[buennerbernd]

I assume, the KLF200 was in a learning mode.

[HarryT]

I assume, the KLF200 was in a learning mode.

Hi

No, not as far as I know.  I just changed the raspberry software, fhem was not changed and there was nothing changed in the KLF200. So I expect the KLF200 was running as usual.
 
If the KLF200 has gone in learning mode,  I don't have any idea why or how that could happen. Or how to detect that the KLF200 is in learning mode.
Besides after 20 hours I would expect the KLF200 to quit that mode.

Everything is possible. I don't know what happend or how to avoid it.

{HT}

[pejonp]

@HarryT

Die somfy-Gerät hängen dirkt am KLF200 oder über die TaHoma am KLF200 ?
Sind die keys noch in Ordnung ?

The somfy devices hang directly on the KLF200 or on the TaHoma on the KLF200?
Are the keys still in order?

pejonp

[HarryT]

@pejonp  (I can perfectly read German, but not write it)

I have no TaHoma box and everything is connected direct to the KLF200.
No problems with the keys. After the latest reset with power and ethernet disconnected, everything works fine.

So I would say the KLF200 was lost and didn't know what to do.

{HT}