Velux KLF200 mit Firmware 2.0.0.71 für io-homecontrol

buennerbernd · 28 Juli 2020, 20:42:03

Schnelle Antwort aus dem Urlaub:
Vielleicht hilft es, die Aufrufe zeitlich etwas zu entzerren.
Falls du selbst herausfinden willst, was die Meldungen bedeuten, so als Sommerrätsel, dann suche in der API Doc von Velux nach 0311 und hangele dich weiter

Ich schaue nach dem Urlaub mal drauf.

pschlaeppi · 29 Juli 2020, 16:08:47

Hallo Stefan,

Herzlichen Dank für deine schnelle Antwort aus deinem Urlaub.
Habe mich gemäss deinem Rat mal daran gemacht mit dem enträtseln des Sommerrätsels zu beginnen und wollte mal als erstes ein Verbose 5 Log ziehen um die Fakten beisammen zu haben. Das Log ist attached.

Um die vorgeschlagene zeitliche Entzerrung zu erhalten habe ich den limitationMax befehl auf 10% mal isoliert über die FHEM Command Line abgesetzt. Es gab davor also keinerlei andere Befehle von FHEM an den KLF die noch nicht abgearbeitet waren.

Code Auswählen


{fhem("set [a-zA-Z]{2}.[a-zA-Z]{2}.(MA|DF).* limitationMax 10")}

Dieses hat dann den Output des attachten Logs ergeben. Ich nehme mal an dass das so angedacht ist, dass auf 100 stehende Markisen die den "set <aktorWildcard> limitationMax 10" Befehl akzeptieren dann auch gleich auf 10 Prozent fahren. Da alle Fenster zu waren, haben die sich nicht gerührt. 2 Markisen und 2 Fenster haben den Befehl akzeptiert und 2 Markisen und 1 Fenster nicht.

Die 0x0310 Messages sind die GW_SET_Limitation_REQ Messages und
die 0x0311 Messages sind die GW_SET_Limitation_CFN Messages.

Wenn ich mich beim aufschlüsseln nicht geirrt habe, müsste zum Beispiel die erste unknown Message bedeuten

Code Auswählen

2020.07.29 13:40:35 1 : KLF200 (Velux) - unknown:  03111db801

0311 = SET_GW_LIMITATION_CFM
Data 1-2: Session ID: = 1db8 (Dec = 7608)
Data 3 : Status : = 01 (0 ist rejected, 1 ist accepted)

Im attachten Log enden alle diese 7 Messages (4 MA und 3 DF) jeweils mit einem "Accepted". Wenn ich das richtig interpretiere werden wohl demzufolge die unknown Meldungen zwar nicht erkannt, sind aber korrekt.

Akzeptiert hatten die Limitierung die Aktoren:
- eg.wg.DF.Links (Session 7608)
- eg.wg.DF.Rechts (Session 7609)
- eg.wg.MA.Links (Session 7610,7611)
- og.ga.MA.Links (Session 7615,7616)

Nicht akzeptiert haben die limitierung die folgenden Aktoren:
- og.ga.DF.Links (Session 7614)
- eg.wg.MA.Rechts (Session 7612)
- og.ga.MA.Rechts (Session 7617)

Sessions im Log die keinem Aktor zugeordnet sind:
- 7613
- 7618

Wenn ich das zu interpretieren versuchen fällt mir auf das die Markisen die funktioniert haben, 2 Sesions haben. Die mit der tieferen Nummer für den limitationMax Befel und die zweite Session für den Fahrbefehl auf Auf.
Die beiden "leeren" Sessions würden eigentlich als Fahrbefehl Sessions zu den beiden Markisen passen, die nicht gefahren sind und auch den Befehl nicht umgesetzt haben.

Habe dann mal die folgenden beiden Befehle zeitlich versetzt abgesetzt:

Code Auswählen


{fhem("set [a-zA-Z]{2}.[a-zA-Z]{2}.MA.* limitationMax 70")}
{fhem("set [a-zA-Z]{2}.[a-zA-Z]{2}.DF.* limitationMax 70")}

So haben dann alle Aktoren die Einstellungen auch übernommen. Ich werde das nun mal auf
zwei verschiedene Befehle aufteilen und Sie so absetzen.

Worin lag das Problem aus deiner Sicht eher?
- zuviele gleichzeitige Sessions (Gibt es da ne bekannte Limite)
- müssten die beiden Befehle nun noch zeitlich versetzt werden?
- Falls ja, welchen Ansatz und welche Zeitspanne empfiehlst du?
* Verwendung von sleep, da das aber so weit ich weiss blocking ist, würde ich das
nur so mit 0.1 oder 0.2 Sekunden nutzen wollen.
* Verwendung von at

Herzlichen Dank für deine Unterstützung.

Grüsse und weiterhin einen schönen Urlaub

Philipp

Elektrolurch · 29 Juli 2020, 16:47:23

Nimm doch DOIF und das wait - Attribut.
Dass habe ich auch für die Velux-Fenster und -Rolladen eingesetzt.
Zwar anderer use-case:
Soll das Fenster geöffnet werden und ist der Rolladen zu, wird erst der Rolladen geöffnet und dann das Fenster, damit das Fenster nicht in das Rollo fährt und umgekehrt.
DOIF(..)
(Befehl 1)
(Befehl 2)

Attr mein-doif wait 0:10

Gruß

Elektrolurch

pschlaeppi · 29 Juli 2020, 20:52:31

Hallo Elektrolurch,

Da ich bei mir das Zeugs dynamisch zusammenpfriemle denke ich das mit einem at fast einfacher geht aus dem Programm eines zu definieren als ein DOIF anzulegen mit den zugehörigen Attributen. Speziell da ich bereits für HoldOverTimer dynamische at's brauche auf die ich über !defs{} prüfe ob sie da sind und je nachdem dann verzweige.

Ich habe das inzwischen übrigens mit 2 at's getestet die 5 und 10 Sekunden später die limitationMax ändern.

Leider funktioniert es auch damit noch nicht so recht. Es gibt trotzdem immer wieder den einen oder anderen Aktor der es nicht mitkriegt.
Muss da wohl noch etwas mit längeren Delays arbeiten.

Grüsse Philipp

Nachtrag vom 8.8.2020:
================
Mit Delays von 20 Sekunden für die ersten 4 "set <aktor> liitationMax 0" und mit 40 Sekunden für die verbleibenden 3 Aktoren, funktioniert es nach wie vor nicht zuverlässig.

Erst wenn ich die ersten 4 Befehle nach 60 Sekunden und die verbleibenden 3 dann nach 120 Sekunden absetze, funktioniert es bisher in jedem Fall zuverlässig.

eurofinder · 04 August 2020, 22:18:30

Hallo,

bei mir sind heute 2 Rollläden nicht die in der Kombination von KLF200 mit ASC zum "night close" gesteuert worden.
Im Logfile eines der Rolläden kann ich überhaupt keinen Steuerbefehl feststellen, im anderen Fall ist zwar ein Eintrag vorhanden, der Befehl wurde aber nicht ausgeführt.

Um 21:49:40 Uhr ist der Befehl zum Schließen. Der Befehl um 21:55:15 Uhr habe ich dann manuell angestoßen.

Code Auswählen

2020-08-04_05:46:38 Rollo_OG_Bad pct 100
2020-08-04_05:46:59 Rollo_OG_Bad pct: 100
2020-08-04_21:49:40 Rollo_OG_Bad pct 0
2020-08-04_21:55:15 Rollo_OG_Bad pct 0
2020-08-04_21:55:34 Rollo_OG_Bad pct: 0

Kann mir jemand sagen, wo ich hier ansetzen könnte, warum im ersten Fall überhaupt kein Fahrbefehl gesendet wurde - das ist wahrscheinlich eher ein Problem verursacht durch ASC, bzw. warum beim Rollo_OG_Bad der Befehl nicht ausgeführt wurde?

Ergänzend würde mich interessieren, wie bekomme ich die Einträge in den separaten Logfiles des KLF200Node ins Logfile des FHEM?

Gruß
eurofinder

onkel-tobi · 08 August 2020, 09:43:46

Hallo zusammen,

ich probiere mich aktuell auch an dem KLF200 um meine beiden Außenrollos entsprechend zu bedienen.
Leider bekomme ich immer wieder log in failed.

Ich habe die neueste fhem version und des moduls installiert.
KLF und fhem rebooted. Bekam dann auch kurz den status opened, gefolgt von nit logged kn.
Habe knzwischen dem Thread komplett durch, aber bis auf das presence nichts gefunden was mir helfen könnte.
Presence habe ich mE nicht im Einsatz.

Hier das list meines KLFs:

Code Auswählen

 Internals:
   DEF        192.168.1.150
   DeviceName 192.168.1.150:51200
   FD         117
   FUUID      5ef26519-f33f-daf3-d2cc-c93b12e3c0b46697
   Host       192.168.1.150
   NAME       VeluxGW
   NR         532
   PARTIAL    
   SSL        1
   STATE      Log in failed
   TIMEOUT    10
   TYPE       KLF200
   READINGS:
     2020-06-25 08:01:15   address         daeb32
     2020-08-08 09:24:23   connectionBroken 0
     2020-08-05 21:54:30   connectionsAfterBoot 4
     2020-06-23 22:26:52   hardwareVersion 6
     2020-08-07 14:55:12   lastError       
     2020-06-23 22:26:52   model           0.2.0.0.71.0
     2020-08-08 09:30:21   queueSize       5
     2020-08-08 09:05:55   sessionID       212
     2020-06-23 22:26:52   softwareVersion 0.2.0.0.71.0
     2020-08-08 09:31:00   state           Log in failed
     2020-07-11 23:57:46   subState        Idle state
Attributes:
   controlNames daeb32-1:KLF200 Input,daeb32-8:FHEM,5bad0e-1:User Remote control,2f0000-8:Stand Alone Automatic Controls,0c2409-1:User Remote control

Hat noch wer eine Idee? Ich habe beide PWs probiert.

Danke & Gruß,
Tobi

postman · 08 August 2020, 11:20:18

Hallo tobi,
bei mir will FHEM das WLAN-PW haben.
Damit sollte es funktionieren.
Gruß

pschlaeppi · 08 August 2020, 12:17:06

Hallo Tobi,

Bist du allenfalls parallel auch noch per WebGUI im Browser eingelogged?
Bei mir ging es dann auch nicht.

Gruss Philipp

onkel-tobi · 09 August 2020, 00:04:59

Hi zusammen,

ich war ja kurz verbunden. Aber dann Wechsel auf login failed, gefolgt von disconnected.

Wie beschrieben schon beide PWs ausprobiert. Auf das web-if komme ich doch gar nicht, wenn ich das lan kabel aktiv habe, oder seh ich das falsch?

Update: ok. Dann scheint genau da was mein Problem zu sein, manueller Aufruf im browser gibt ein timeout, nachdem ich kurz vorher noch ne cert Warnung bekommen habe...

Gruß,
Tobi

eurofinder · 09 August 2020, 08:09:01

@onkel-tobi:
Kannst du das KLF200 per http://klf200.velux erreichen?
Hast du ggf. das klf200 als Repeater konfiguriert?
Mach mal einen Restart von fhem und zeige ein Auszug aus dem Lofile.
Schon mal probiert das klf200-Device in fhem zu löschen und neu anzulegen?
Gruß
eurofinder

onkel-tobi · 09 August 2020, 09:29:50

So, habe das Gerät nun nochmal in ein subnet gepackt, dass definitiv kein problem machen kann.
Außerdem ne statische ip adresse vergeben. Per lan kam ich nicht ran, per wlan schon.
Anschließend in fhem das define angepasst, login und siehe da: opened. Aber nach kurzer Zeit dann wieder disconnected.

Hier das log:

Code Auswählen

2020.08.09 09:16:18.046 1: 127.0.0.1:1883 disconnected, waiting to reappear (m2c)
2020.08.09 09:16:18.090 1: 127.0.0.1:1883 reappeared (m2c)
2020.08.09 09:16:48.090 2: m2c: No PINGRESP for last PINGREQ (at 2020-08-09 09:16:17), disconnecting
2020.08.09 09:16:48.092 1: 127.0.0.1:1883 disconnected, waiting to reappear (m2c)
2020.08.09 09:16:49.017 1: 127.0.0.1:1883 reappeared (m2c)
2020.08.09 09:17:10.544 3: CUL_HM set dg_fe_ga off
2020.08.09 09:17:11.694 3: CUL_HM set dg_fe_vg off
2020.08.09 09:17:37.398 5: KLF200 (VeluxGW) - Set login
2020.08.09 09:17:37.427 5: KLF200 (VeluxGW) GW_PASSWORD_ENTER_REQ
2020.08.09 09:17:37.427 5: KLF200 VeluxGW: unwrapped bytes     300076656c7578313233000000000000000000000000000000000000000000000000
2020.08.09 09:17:37.428 5: KLF200 VeluxGW: wrapped bytes c00023300076656c757831323300000000000000000000000000000000000000000000000051c0
2020.08.09 09:17:37.428 5: SW: c00023300076656c757831323300000000000000000000000000000000000000000000000051c0
2020.08.09 09:17:37.444 5: KLF200 (VeluxGW) - received: 300101
2020.08.09 09:17:37.445 5: KLF200 (VeluxGW) GW_PASSWORD_ENTER_CFM 3001 1

Gelöscht hab ich das gerät noch nicht. Wenn ich das GW lösche muss ich vermutlich auch die beiden rollos löschen?

Danke & Gruß,
Tobi

buennerbernd · 09 August 2020, 10:52:14

Die Box ist erreichbar und antwortet, das Passwort stimmt nicht. Löschen würde wohl nicht helfen.
Was kommt bei dem WIFI Passwort?

Ist LAN im Web UI dauerhaft angeschaltet?

Elektrolurch · 09 August 2020, 10:57:25

Bei meiner Box ist nach einiger Zeit nach dem Einschalten das WLan immer weg, obwohl es laut GUI dauerhaft eingeschaltet ist. Daher habe ich die Box per Kabel angeschlossen.
Vielleicht ist das die Ursache?

Elektrolurch

buennerbernd · 09 August 2020, 11:05:40

Das API geht nur über LAN und das Web UI nur über WIFI. Dafür muss LAN dauerhaft an sein und WIFI auf 10 min begrenzt.

onkel-tobi · 09 August 2020, 12:00:06

Zitat von: buennerbernd am 09 August 2020, 10:52:14
Die Box ist erreichbar und antwortet, das Passwort stimmt nicht. Löschen würde wohl nicht helfen.
Was kommt bei dem WIFI Passwort?

Ist LAN im Web UI dauerhaft angeschaltet?

Lan ist dauerhaft da (ping läuft unauffällig durch).
Mit dem default pw velux123 ist er kurz verbunden und dann ist wieder vorbei.

Aktuell bekomme ich allerdings eine Antwort, die evtl hilft?

Code Auswählen

SSL wants a read first

Update: Ich habe mich via wlan nochmals auf das interface eingeloggt. Logs gelöscht und anschließend einen reboot gemacht und seitdem nun seit ca. 20 Minuten eingeloggt...
Irgendwie komisch, denn rebootet hatte ich schon etliche male, aber ich glaube nur 1 mal via web interface.