Seit einigen Wochen betreibe ich nun problemlos acht HM-LC-Bl1PBU-FM an meinem HMLAN, mittlerweile auch automatisiert nach Sonnenstand. Bin auch sehr zufrieden mit FHEM (tolles Projekt, wirklich klasse was Ihr hier auf die Beine gestellt habt).
Nun aber kann ich seit gestern von FHEM aus keinen einzigen Rolladen mehr bewegen, im Forum habe ich noch keine rechten Anhaltspunkte finden können. Einiges konnte ich aber schonmal testen:
* Manuelle Bedienung an den Schaltern funktioniert (in beiden Richtungen) und FHEM zeigt die neuen Positionen auch korrekt an
* "set <DEVICE> press *" funktioniert, damit sollte die Kommunikation grundsätzlich OK sein.
* "set <DEVICE> stop" funktioniert nicht (Motor fährt weiter).
* "set <DEVICE> pct <XY>" führt bei jedem der Aktoren dazu, dass set_XY als status angezeigt wird, was sich auch nicht mehr ändert, ausser wenn ich später den Aktor von Hand bediene.
* Zurücksetzen der FHEM Installation (SVN) auf Backup zeigt keine Änderung.
* "shutdown restart" und komplettes Beenden und Neustarten von fhem zeigt keine Wirkung.
* Power-Cycle des HMAN zeigt erzielt keine Verbesserung
* Power-Cycle der Aktoren (hängen alle an der selben Sicherung) erzielt keine Verbesserung.
Log-Einträge beim manuellen Bedienen (kurzes Hochfahren):
2013.08.15 17:48:16 3: HMLAN_Send: HMLAN1 I:K
2013.08.15 17:48:16 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:045ED195 IDcnt:0011
2013.08.15 17:48:32 3: HMLAN_Parse: HMLAN1 R:E1AF5A9 stat:0000 t:045F0EA3 d:FF r:FFB8 m:58 A410 1AF5A9 139AF8 06016C10
2013.08.15 17:48:38 3: HMLAN_Parse: HMLAN1 R:E1AF5A9 stat:0000 t:045F2803 d:FF r:FFB4 m:5C A410 1AF5A9 139AF8 06017B30
2013.08.15 17:48:41 3: HMLAN_Send: HMLAN1 I:K
2013.08.15 17:48:41 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:045F3345 IDcnt:0011
Log Einträge beim Versuch, den selben Schalter fernzusteuern:
2013.08.15 17:51:53 2: CUL_HM set RolloSchalter06 70
2013.08.15 17:51:53 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.15 17:51:53 3: HMLAN_Send: HMLAN1 S:S82AD0C88 stat: 00 t:00000000 d:01 r:82AD0C88 m:60 A011 139AF8 1AF5A9 0301
2013.08.15 17:51:53 3: HMLAN_Parse: HMLAN1 R:E1AF5A9 stat:0100 t:04622148 d:FF r:FFB6 m:60 A002 1AF5A9 139AF8 0453F44EB8597B06
2013.08.15 17:51:53 3: HMLAN_Delay: HMLAN1 1AF5A9
2013.08.15 17:51:54 3: HMLAN_Parse: HMLAN1 R:R82AD0C88 stat:0030 t:0462214D d:03 r:FFB6 m:60 A002 1AF5A9 139AF8 0453F44EB8597B06
2013.08.15 17:51:54 3: HMLAN_SdDly: HMLAN1 1AF5A9
2013.08.15 17:51:54 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.15 17:51:54 3: HMLAN_Send: HMLAN1 S:S82AD0D3D stat: 00 t:00000000 d:01 r:82AD0D3D m:61 A011 139AF8 1AF5A9 02018C
2013.08.15 17:51:54 3: HMLAN_Parse: HMLAN1 R:E1AF5A9 stat:0100 t:04622693 d:FF r:FFB6 m:61 A002 1AF5A9 139AF8 04C3149BED324A06
2013.08.15 17:51:55 3: HMLAN_Parse: HMLAN1 R:R82AD0D3D stat:0030 t:04622698 d:03 r:FFB6 m:61 A002 1AF5A9 139AF8 04C3149BED324A06
Logeinträge bei Verwendung von press und stop:
2013.08.15 17:55:05 2: CUL_HM set RolloSchalter06 press short up
2013.08.15 17:55:05 3: HMLAN_Send: HMLAN1 S:S82AFFA58 stat: 00 t:00000000 d:01 r:82AFFA58 m:66 A03E 139AF8 1AF5A9 1AF5A9400203
2013.08.15 17:55:05 3: HMLAN_Parse: HMLAN1 R:R82AFFA58 stat:0001 t:04650F33 d:FF r:FFB3 m:66 8002 1AF5A9 139AF8 01012F1044
2013.08.15 17:55:14 2: CUL_HM set RolloSchalter06 stop
2013.08.15 17:55:14 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.15 17:55:14 3: HMLAN_Send: HMLAN1 S:S82B01F72 stat: 00 t:00000000 d:01 r:82B01F72 m:67 A011 139AF8 1AF5A9 0301
2013.08.15 17:55:14 3: HMLAN_Parse: HMLAN1 R:E197D4E stat:0000 t:04653394 d:FF r:FFC3 m:82 8670 197D4E 000000 00E533
2013.08.15 17:55:15 3: HMLAN_Parse: HMLAN1 R:E1AF5A9 stat:0100 t:0465344E d:FF r:FFB6 m:67 A002 1AF5A9 139AF8 048E4470A23A6A06
2013.08.15 17:55:15 3: HMLAN_Parse: HMLAN1 R:R82B01F72 stat:0030 t:04653453 d:03 r:FFB6 m:67 A002 1AF5A9 139AF8 048E4470A23A6A06
2013.08.15 17:55:21 3: HMLAN_Send: HMLAN1 I:K
2013.08.15 17:55:21 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:04654E53 IDcnt:0011
2013.08.15 17:55:22 2: CUL_HM set RolloSchalter06 press short off
2013.08.15 17:55:22 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.15 17:55:22 3: HMLAN_Send: HMLAN1 S:S82B03E6B stat: 00 t:00000000 d:01 r:82B03E6B m:68 A03E 139AF8 1AF5A9 1AF5A9400104
2013.08.15 17:55:22 3: HMLAN_Parse: HMLAN1 R:R82B03E6B stat:0001 t:0465534C d:FF r:FFB8 m:68 8002 1AF5A9 139AF8 0101963047
2013.08.15 17:55:32 3: HMLAN_Parse: HMLAN1 R:E1B09BD stat:0000 t:04657940 d:FF r:FFD5 m:81 8670 1B09BD 000000 00FA21
2013.08.15 17:55:46 3: HMLAN_Send: HMLAN1 I:K
2013.08.15 17:55:46 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:0465B007 IDcnt:0011
Die Einstellungen der betreffenden Entity:
(siehe Anhang / see attachement)
Das Problem besteht bei allen acht Aktoren, bei manchen wechselt allerdings die Statusanzeige manchmal auf "MISSING ACK" - aber auch das nicht immer.
Was kann ich noch an Informationen beistellen, was zur Lösung beitragen kann? Durch die Wohnung laufen und Schalter bedienen ist irgendwie uncool geworden ;)
Vielen Dank für Eure Hilfe,
Andy.
Nachdem ich nun selbst noch viel rumprobiert habe, habe ich nun per Windows-Software "HomeMatic-Lan-Interface konfigurieren" dem HMLAN ein Firmware-update verpasst. Vor dem Update meldete die Software einen Firmware stand 0.961. Während des Updates kam eine Meldung, dass auf 0.952 aktualisiert wird. Nach dem als erfolgreich gemeldeten Update lief dann aber wieder die 0.961.
Unmittelbar danach verhielt sich die Steuerung wieder so gut wie eh und je, sämtliche oben beschriebene Fehler waren verschwunden.
Dann habe ich wieder auf die aktuelle SVN Version von FHEM aktualisiert und alles funktionierte eine Zeitlang, bis die Symptome aber wieder auftraten. Mit einer Ausnahme: Vor dem Firmware Update hatte ich drei von den acht Rollos von "Gesichert" auf "Standard" umgeschalten. Diese ließen sich weiterhin steuern, während die anderen fünf wieder nicht mehr reagieren wollten.
Als nächstes habe ich FHEM gestoppt, im Windows HMLAN-Konfigurator einen weiteren Rollo auf "Standard" gesetzt, danach FHEM wieder gestartet. Jetzt ließen sich wieder alle Rollos fernsteuern, ob mit oder ohne AES-Signierung.
Ich beobachte das mal weiter - irgendwelche Vorschläge, was alles protokolliert werden sollte?
Hi Grandy,
es könnte also sein, dass einige der registerwerte, die du irgendwann geaendert hast zu diesem Verhalten geführt haben.
Das Beispiel des RolloSchalter6 ist von einem "Defecten"??
kannst du die Register lesen nachdem er jetzt funktioniert?
Gruss Martin
Hi Martin,
nochmal eine etwas strukturiertere Darstellung der Situation:
Installiert sind 8 RolloSchalter01..08 - davon sind 01..05 als "Gesichert" (AES-Signierung), der Rest als "Standard" konfiguriert.
Nun ist es so, dass das System immer wieder in einen Zustand gerät, in dem die gesicherten Rollos nicht mehr auf pct Kommandos reagieren (s.O.) - die nicht gesicherten allerdings schon.
Als Beispiel folgen Kommandos für RolloSchalter05 (geht nicht) und RolloSchalter06 (geht):
2013.08.20 19:52:58 2: CUL_HM set RolloSchalter05 pct 80
2013.08.20 19:52:58 3: HMLAN_Send: HMLAN1 S:+1B711B,00,01,
2013.08.20 19:52:58 3: HMLAN_Send: HMLAN1 S:S9CDBB529 stat: 00 t:00000000 d:01 r:9CDBB529 m:7D A011 139AF8 1B711B 0301
2013.08.20 19:52:59 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0100 t:019C28AF d:FF r:FFC6 m:7D A002 1B711B 139AF8 04B4855F41E9E406
2013.08.20 19:52:59 3: HMLAN_Delay: HMLAN1 1B711B
2013.08.20 19:52:59 3: HMLAN_Parse: HMLAN1 R:R9CDBB529 stat:0030 t:019C28B4 d:03 r:FFC6 m:7D A002 1B711B 139AF8 04B4855F41E9E406
2013.08.20 19:52:59 3: HMLAN_SdDly: HMLAN1 1B711B
2013.08.20 19:52:59 3: HMLAN_Send: HMLAN1 S:+1B711B,00,01,
2013.08.20 19:52:59 3: HMLAN_Send: HMLAN1 S:S9CDBB5DE stat: 00 t:00000000 d:01 r:9CDBB5DE m:7E A011 139AF8 1B711B 0201A0
2013.08.20 19:53:00 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0100 t:019C2DF6 d:FF r:FFC6 m:7E A002 1B711B 139AF8 0413CED565819006
2013.08.20 19:53:01 3: HMLAN_Parse: HMLAN1 R:R9CDBB5DE stat:0030 t:019C2DFB d:03 r:FFC6 m:7E A002 1B711B 139AF8 0413CED565819006
2013.08.20 19:54:45 2: CUL_HM set RolloSchalter05 pct 90
2013.08.20 19:54:45 3: HMLAN_Send: HMLAN1 S:+1B711B,00,01,
2013.08.20 19:54:45 3: HMLAN_Send: HMLAN1 S:S9CDD5661 stat: 00 t:00000000 d:01 r:9CDD5661 m:7F A011 139AF8 1B711B 0301
2013.08.20 19:54:45 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0100 t:019DC9F7 d:FF r:FFC6 m:7F A002 1B711B 139AF8 042A717C40234A06
2013.08.20 19:54:45 3: HMLAN_Delay: HMLAN1 1B711B
2013.08.20 19:54:46 3: HMLAN_Parse: HMLAN1 R:R9CDD5661 stat:0030 t:019DC9FC d:03 r:FFC6 m:7F A002 1B711B 139AF8 042A717C40234A06
2013.08.20 19:54:46 3: HMLAN_SdDly: HMLAN1 1B711B
2013.08.20 19:54:46 3: HMLAN_Send: HMLAN1 S:+1B711B,00,01,
2013.08.20 19:54:46 3: HMLAN_Send: HMLAN1 S:S9CDD5726 stat: 00 t:00000000 d:01 r:9CDD5726 m:80 A011 139AF8 1B711B 0201B4
2013.08.20 19:54:47 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0100 t:019DCF3D d:FF r:FFC6 m:80 A002 1B711B 139AF8 043CE0D67B8E3206
2013.08.20 19:54:48 3: HMLAN_Parse: HMLAN1 R:R9CDD5726 stat:0030 t:019DCF42 d:03 r:FFC6 m:80 A002 1B711B 139AF8 043CE0D67B8E3206
2013.08.20 19:55:51 2: CUL_HM set RolloSchalter06 pct 80
2013.08.20 19:55:51 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.20 19:55:51 3: HMLAN_Send: HMLAN1 S:S9CDE58AD stat: 00 t:00000000 d:01 r:9CDE58AD m:81 A011 139AF8 1AF5A9 0301
2013.08.20 19:55:51 3: HMLAN_Parse: HMLAN1 R:R9CDE58AD stat:0001 t:019ECC4F d:FF r:FFC7 m:81 8002 1AF5A9 139AF8 0101C80035
2013.08.20 19:55:51 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.20 19:55:51 3: HMLAN_Send: HMLAN1 S:S9CDE594F stat: 00 t:00000000 d:01 r:9CDE594F m:82 A011 139AF8 1AF5A9 0201A0
2013.08.20 19:55:52 3: HMLAN_Parse: HMLAN1 R:R9CDE594F stat:0001 t:019ECDDE d:FF r:FFC6 m:82 8002 1AF5A9 139AF8 0101C82035
2013.08.20 19:55:59 3: HMLAN_Parse: HMLAN1 R:E1AF5A9 stat:0000 t:019EE9DD d:FF r:FFC7 m:83 A410 1AF5A9 139AF8 0601A000
2013.08.20 19:56:00 3: HMLAN_Parse: HMLAN1 R:E197D4E stat:0000 t:019EEF42 d:FF r:FFC2 m:CE 8670 197D4E 000000 00E53B
2013.08.20 19:56:38 2: CUL_HM set RolloSchalter06 pct 90
2013.08.20 19:56:38 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.20 19:56:38 3: HMLAN_Send: HMLAN1 S:S9CDF0FAD stat: 00 t:00000000 d:01 r:9CDF0FAD m:83 A011 139AF8 1AF5A9 0301
2013.08.20 19:56:38 3: HMLAN_Parse: HMLAN1 R:R9CDF0FAD stat:0001 t:019F8357 d:FF r:FFC7 m:83 8002 1AF5A9 139AF8 0101A00035
2013.08.20 19:56:38 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.20 19:56:38 3: HMLAN_Send: HMLAN1 S:S9CDF104F stat: 00 t:00000000 d:01 r:9CDF104F m:84 A011 139AF8 1AF5A9 0201B4
2013.08.20 19:56:39 3: HMLAN_Parse: HMLAN1 R:R9CDF104F stat:0001 t:019F84E6 d:FF r:FFC6 m:84 8002 1AF5A9 139AF8 0101A01035
2013.08.20 19:56:43 3: HMLAN_Parse: HMLAN1 R:E1AF5A9 stat:0000 t:019F9669 d:FF r:FFC7 m:85 A410 1AF5A9 139AF8 0601B400
Um das System wieder benutzbar zu machen, stoppe ich FHEM, starte in der VirtualBox den HomeMatic LAN-Konfigurator, warte einige Sekunden, beende ihn und starte FHEM wieder. Danach funktionieren die Rollos wieder ganz normal, egal ob gesichert oder nicht:
2013.08.20 20:01:13 2: CUL_HM set RolloSchalter05 pct 80
2013.08.20 20:01:13 3: HMLAN_Send: HMLAN1 S:+1B711B,00,01,
2013.08.20 20:01:13 3: HMLAN_Send: HMLAN1 S:S9CE3408E stat: 00 t:00000000 d:01 r:9CE3408E m:2B A011 139AF8 1B711B 0301
2013.08.20 20:01:13 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0100 t:01A3B461 d:FF r:FFC6 m:2B A002 1B711B 139AF8 04F4427801125706
2013.08.20 20:01:13 3: HMLAN_Delay: HMLAN1 1B711B
2013.08.20 20:01:13 3: HMLAN_Parse: HMLAN1 R:R9CE3408E stat:0021 t:01A3B466 d:03 r:FFC5 m:2B 8002 1B711B 139AF8 010178003A2512EEB4
2013.08.20 20:01:13 3: HMLAN_SdDly: HMLAN1 1B711B
2013.08.20 20:01:13 3: HMLAN_Send: HMLAN1 S:+1B711B,00,01,
2013.08.20 20:01:13 3: HMLAN_Send: HMLAN1 S:S9CE34143 stat: 00 t:00000000 d:01 r:9CE34143 m:2C A011 139AF8 1B711B 0201A0
2013.08.20 20:01:14 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0100 t:01A3B6F1 d:FF r:FFC5 m:2C A002 1B711B 139AF8 046184F71B69A006
2013.08.20 20:01:14 3: HMLAN_Parse: HMLAN1 R:R9CE34143 stat:0021 t:01A3B6F6 d:03 r:FFC1 m:2C 8002 1B711B 139AF8 010178103AEC1C2980
2013.08.20 20:01:21 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0000 t:01A3D388 d:FF r:FFC5 m:2D A410 1B711B 139AF8 0601A000
2013.08.20 20:01:59 2: CUL_HM set RolloSchalter05 pct 90
2013.08.20 20:01:59 3: HMLAN_Send: HMLAN1 S:+1B711B,00,01,
2013.08.20 20:01:59 3: HMLAN_Send: HMLAN1 S:S9CE3F4D0 stat: 00 t:00000000 d:01 r:9CE3F4D0 m:2D A011 139AF8 1B711B 0301
2013.08.20 20:01:59 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0100 t:01A468A9 d:FF r:FFC6 m:2D A002 1B711B 139AF8 046A64EF12FC5406
2013.08.20 20:01:59 3: HMLAN_Delay: HMLAN1 1B711B
2013.08.20 20:01:59 3: HMLAN_Parse: HMLAN1 R:R9CE3F4D0 stat:0021 t:01A468AE d:03 r:FFC5 m:2D 8002 1B711B 139AF8 0101A0003B3B02F4D6
2013.08.20 20:01:59 3: HMLAN_SdDly: HMLAN1 1B711B
2013.08.20 20:01:59 3: HMLAN_Send: HMLAN1 S:+1B711B,00,01,
2013.08.20 20:01:59 3: HMLAN_Send: HMLAN1 S:S9CE3F585 stat: 00 t:00000000 d:01 r:9CE3F585 m:2E A011 139AF8 1B711B 0201B4
2013.08.20 20:02:00 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0100 t:01A46B39 d:FF r:FFC6 m:2E A002 1B711B 139AF8 04984AEEA5A05406
2013.08.20 20:02:00 3: HMLAN_Parse: HMLAN1 R:R9CE3F585 stat:0021 t:01A46B3E d:03 r:FFC0 m:2E 8002 1B711B 139AF8 0101A0103ACE200F08
2013.08.20 20:02:04 3: HMLAN_Parse: HMLAN1 R:E1B711B stat:0000 t:01A47DBF d:FF r:FFC6 m:2F A410 1B711B 139AF8 0601B400
2013.08.20 20:02:24 2: CUL_HM set RolloSchalter06 pct 80
2013.08.20 20:02:24 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.20 20:02:24 3: HMLAN_Send: HMLAN1 S:S9CE45816 stat: 00 t:00000000 d:01 r:9CE45816 m:2F A011 139AF8 1AF5A9 0301
2013.08.20 20:02:25 3: HMLAN_Parse: HMLAN1 R:R9CE45816 stat:0001 t:01A4CBF6 d:FF r:FFC7 m:2F 8002 1AF5A9 139AF8 0101B40036
2013.08.20 20:02:25 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.20 20:02:25 3: HMLAN_Send: HMLAN1 S:S9CE458B7 stat: 00 t:00000000 d:01 r:9CE458B7 m:30 A011 139AF8 1AF5A9 0201A0
2013.08.20 20:02:25 3: HMLAN_Parse: HMLAN1 R:R9CE458B7 stat:0001 t:01A4CD85 d:FF r:FFC6 m:30 8002 1AF5A9 139AF8 0101B42036
2013.08.20 20:02:29 3: HMLAN_Parse: HMLAN1 R:E1AF5A9 stat:0000 t:01A4DF10 d:FF r:FFC6 m:31 A410 1AF5A9 139AF8 0601A000
2013.08.20 20:02:49 2: CUL_HM set RolloSchalter06 pct 90
2013.08.20 20:02:49 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.20 20:02:49 3: HMLAN_Send: HMLAN1 S:S9CE4B886 stat: 00 t:00000000 d:01 r:9CE4B886 m:31 A011 139AF8 1AF5A9 0301
2013.08.20 20:02:49 3: HMLAN_Parse: HMLAN1 R:R9CE4B886 stat:0001 t:01A52C6A d:FF r:FFC6 m:31 8002 1AF5A9 139AF8 0101A00036
2013.08.20 20:02:49 3: HMLAN_Send: HMLAN1 S:+1AF5A9,00,01,
2013.08.20 20:02:49 3: HMLAN_Send: HMLAN1 S:S9CE4B928 stat: 00 t:00000000 d:01 r:9CE4B928 m:32 A011 139AF8 1AF5A9 0201B4
2013.08.20 20:02:50 3: HMLAN_Parse: HMLAN1 R:R9CE4B928 stat:0001 t:01A52DF9 d:FF r:FFC4 m:32 8002 1AF5A9 139AF8 0101A01037
2013.08.20 20:02:54 3: HMLAN_Parse: HMLAN1 R:E1AF5A9 stat:0000 t:01A53F7C d:FF r:FFC7 m:33 A410 1AF5A9 139AF8 0601B400
Per Wireshark habe ich mitgeloggt, was der LAN-Konfigurator übertragen hat (siehe Anhang).
Wie geschildert, hatte alles bis vor einigen Tagen problemlos funktioniert, irgendwann nach einem der letzten Updates hat es dann begonnen. Ich hatte versucht, auf ältere Versionen aus dem Backup zurückzugehen, kannte da aber den Trick mit dem LAN Konfigurator noch nicht. Ich werde das jetzt nochmals versuchen und sehen, ob eine ältere Version stabiler läuft - vielleicht hat ja auch die Hardware was abbekommen...
Kann ich noch weitere Daten liefern um dem Ganzen auf die Schliche zu kommen?
Beste Grüße,
Andy.
Hallo Andy,
ich fasst noch einmal zusammen:
mit der aktuellen FHEM version funktionieren
- die Rollos ohne AES immer
- Rollos von FHEM programmiert mit AES manchmal?? nie??
- alle Rollos nach einem "reprogram" durch die PC SW
Im log ist es klar zu sehen: auch im Gutfall wird AES vom HMLAN generiert. FHEM macht keinen Unterschied und es läuft beide male der gleiche Code.
Wenn es also einen Unterschied gibt muss der im Device abgelegt sein.
Interessant wäre also ein abzug der Register, zum Einen vom gut und dann vom Schlechtfall.
Wenn möglich also ein getConfig und dann ein list mit attr expert 2, so dass man die Register sehen kann, im Rohformat.
Gruss Martin
Hi,
> - Rollos von FHEM programmiert mit AES manchmal?? nie??
Immer nach einem "reprogram", dann nach wenigen Minuten bis einigen Stunden gehen die Probleme wieder los, der Status bleibt bei den AES-Rollos auf "set_*" - getStatus funktioniert allerdings, auch press, aber nicht stop und pct
Die Rollos haben alle attr autoReadReg 3 und HMLAN loglevel ist runtergesetzt - kann ich die nötigen Daten dann aus dem Logfile extrahieren?
Grüße,
Andy.
Hallo Andy,
das Logfile hat die Daten wahrscheinlich nicht.
Was ich sehen will sind die Register. Evtl schreibt die PC Sw etwas...
im detail will ich die Reglist 0 und reglist1 im rohformat. Dazu solltest du ein getConfig triggern und ein List mit attr expert 2.
Und um Unterschiede sehen zu können brauche ich es von einem AES device (im threat ist leider nur Rollo6, das ist ohne AES)
Der AES key ist nicht in diesen Daten, den kann man nicht auslesen - also keine Angst.
Nicht klar ist mir, ob du ein Device in den "fehlerhaften" Zustand rückversetzen kannst. Wenn ja: wie? Und wenn du es gemacht hast bitte die Register wie oben
Danke
Martin
Hallo Martin,
hab gerstern abend noch auf auf altes Backup zurückgesetzt (SVN-Stand vom 4.Aug.), seitdem laufen alle Rollos noch (was noch nichts heissen muss).
Anbei die Rollo-bezogenen Einträge meiner fhem.cfg (config.txt) und den Output von get RolloSchalter* saveConfig. Sind das die Daten die Du meintest? Dann setze ich die gleichen Befehle wieder ab, sobald das Problem wieder auftritt.
Eine Sache fiel mir auf: RolloSchalter08 zeigt Einträge für RegL_03, die anderen nicht. Hängt das damit zusammen, dass ich den vor einigen Tagen per LAN-Konfigurator zurückgesetzt und neu angelernt habe? (nachdem er massive Kommunikationsstörungen hatte)
Bei der Gelegenheit fällt mir ein: Ich hatte vor etwa zwei Wochen mit RolloSchalter05 gespielt, die Statemachine etwas zerschossen und ihn dann mit den Registerinhalten von RolloSchalter01 zurückgesetzt. Kann sich dabei irgendetwas "eingeschlichen" haben, was das System insgesamt instabil macht? Damals war übrigens bei allen Aktoren noch AES-Signierung aktiviert. Danach lief aber dann alles zunächst gut.
Hab mir gerade nochmal verschiedene Daten angesehen (backup-timestamps, fhem restarts, Rollopositionen):
Am 10.Aug habe ich ein update gefahren und fhem neu gestartet, die Steuerung verhielt sich tadellos.
Am 11.Aug habe ich ein update gefahren (13:58), offenbar aber vergessen, ein shutdown restart hinterherzuschieben.
Das habe ich dann am 12.Aug abends nachgeholt, danach haben die Probleme begonnen.
Jetzt fahre ich wie gesagt den FHEM Stand vom 4.Aug. - falls bis morgen alles weiter funktioniert, will ich die backups der Reihe nach wieder einspielen, bis das Problem wieder auftaucht.
Beste Grüße,
Andy.
Hallo Andy
Rollo8 hat internalKeys visible gesetzt, alle anderen nicht. Du kannst also sehen was die Funktion der eingebauten wipptaster ist und diese aendern. Wenn du auf invisib setzt ist es nicht sichtbar.
Die List 3 würdest du auch für jeden angelernten Peer sehen und steuern können.
Ich denke nicht dass das kopieren der Register ein Problem war.
Mit welcher statemachine hast du gespielt? Da ist kein peer zu sehen
gut, dass es Zeitlich so eng einzugrenzen ist. mal fanden
Gruss Martin
Hi Martin,
OK, das mit den regs hab ich verstanden. Dass die Spielerei nich tragisch war hatte ich vermutet, aber man weiss nie. Grund dafür war die Hoffnung, die Einschaltverzögerung meiner Rollomotoren abzubilden; führt im Wesentlichen dazu, dass immer etwa 1/2s weniger gefahren wird pro Teilstück, als nötig. Aber das greif ich erst wieder auf wenn die aktuellen Probleme behoben sind.
Mit dem Stand vom 4.Aug. läuft bislang alles gut was die o.g. Probleme anbelangt. dafür gingen aber gestern tagsüber RS02 und RS07 "verloren", die waren komplett hähngengeblieben: kein Funk mehr (auch kein getConfig), keine lokale Bedienung, LED dauerhaft an. Hab dann abends die Sicherungen ausgenommen, danach waren diese beiden OK, dafür waren direkt nach Wiedereinschalten RS06 und RS08 nicht mehr per Funk erreichbar (kein getConfig, auch nichts mehr per Windows), aber lokal bedienbar. Irgendwelche Chancen die beiden wiederbeleben zu können? Wie lange muss der Strom weg sein? Und darf bei Rückkehr fhem laufen?
Edit: Was die beiden aber sehr wohl noch tun, ist ihren neuen Status zu senden, wenn sie manuell gefahren wurden. Beide sind übrigens ohne AES-Signierung.
Werde später wieder auf den aktuellen SVN Stand zurückkehren, um das AES-Problem weiter zu untersuchen.
Beste Grüße,
Andy.
Hallo Andy,
dass Aktoren nicht mehr reagieren hatte ich auch schon - und mit Sicherung gelöst.
Leider weiss ich nicht, wie man in den Zustand kommen kann. Ich habe ein paar Versuche gemacht ein reset zu schicken,... ohne erfolg.
Vom HMLAN kenne ich, dass dieser blockieren kann und keine Nachrichten mehr empfängt/verarbeitet. Der braucht dann so 6min pause - man darf keine Daten mehr senden sonst verlängert sich diese Zeit. Die HMLAN SW berücksichtigt dies mittlerweile und signalisiert es entsprechend.
Warum der HMLAN in diesen Zustand kommt ist nicht klar - eine einfache overload-prorection ist dies nicht, aber so in die Richtung
Evtl. kann der Aktor auch in so einem Zustand sein. Wie lange hast du gewartet?
Gruss Martin
Hi Martin,
beim ersten Mal habe ich etwa 10sec stromlos gelassen, während des Wiedereinschaltens lief FHEM. Dann stellte ich fest, dass RS02 und RS07 wieder da, RS06 und RS08 dafür weg sind. Danach habe ich für etwa 3-4 min stromlos geschaltet und zum Wiedereinschalten auch FHEM gestoppt. Für RS06 und RS08 hat das nichts gebracht, aber ich versuch es heut abend nochmal mit 10 min., um sicherzugehen.
Aktuell läuft wieder die tagesaktuelle SVN Version. Zwei versetzte AT fahren alle fünf Minuten alle Rollos um 2% nach unten und 2Min. später wieder 2% hoch. Das hat bislang immer geholfen, Probleme zu provozieren, vielleicht taucht ja das AES-bezogene wieder auf und ich kann Registerinhalte extrahieren.
Grüße,
Andy.
ok - wie gesagt, bitte die rohmessages.
Gruss Martin
Ah, right, wollte ich ohnehin gefragt haben, was genau muss ich tun, um an die Rohmessages (und ms-Auflösung) zu kommen?
Danke,
Andy.
Die Messages am HMLAN (letzte und erste Sichtung in FHEM) erhält man mit
attr <hmlan> loglevel 1
attr global verbose 1
attr global mseclog 1
Dann sind die anderen logs aus und stören nicht.
und besser
attr <hmlan> hmProtokolEvents 0
Gruss Martin
Hi Martin,
habe die beiden Abtrünnigen wieder ins Boot holen können - 15min ohne Strom, danach neu pairen, nun tun sie wieder. Davor ging neu pairen nicht.
Aber: Nach dieser Prozedur sind nun die AES-Signierer (R02,R03 und R04) nicht mehr ansprechbar. Fehlerbild wie beschrieben:
set RS04 pct 100 -> status: set_100 bleibt beliebig lange bestehen
Manuele Bedienung (nach oben) -> status geht auf 100%
2013.08.22 20:13:42.569 2: CUL_HM set RolloSchalter04 80
2013.08.22 20:13:42.570 3: HMLAN_Send: HMLAN1 S:+1AF52B,00,01,
2013.08.22 20:13:42.570 3: HMLAN_Send: HMLAN1 S:SA73B676A stat: 00 t:00000000 d:01 r:A73B676A m:81 A011 139AF8 1AF52B 0301
2013.08.22 20:13:42.749 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0100 t:0011FF67 d:FF r:FFC9 m:81 A002 1AF52B 139AF8 041959AB251D9C06
2013.08.22 20:13:42.751 3: HMLAN_Delay: HMLAN1 1AF52B
2013.08.22 20:13:43.681 3: HMLAN_Parse: HMLAN1 R:RA73B676A stat:0030 t:0011FF6C d:03 r:FFC9 m:81 A002 1AF52B 139AF8 041959AB251D9C06
2013.08.22 20:13:43.682 3: HMLAN_SdDly: HMLAN1 1AF52B
2013.08.22 20:13:43.682 3: HMLAN_Send: HMLAN1 S:+1AF52B,00,01,
2013.08.22 20:13:43.683 3: HMLAN_Send: HMLAN1 S:SA73B681F stat: 00 t:00000000 d:01 r:A73B681F m:82 A011 139AF8 1AF52B 0201A0
2013.08.22 20:13:44.100 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0100 t:001204AE d:FF r:FFC8 m:82 A002 1AF52B 139AF8 04E545CC8387AE06
2013.08.22 20:13:45.032 3: HMLAN_Parse: HMLAN1 R:RA73B681F stat:0030 t:001204B3 d:03 r:FFC8 m:82 A002 1AF52B 139AF8 04E545CC8387AE06
2013.08.22 20:13:51.787 3: HMLAN_Send: HMLAN1 I:K
2013.08.22 20:13:51.791 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:001222D2 IDcnt:0008
2013.08.22 20:13:52.486 3: HMLAN_Parse: HMLAN1 R:E197D4E stat:0000 t:00122581 d:FF r:FFC4 m:48 8670 197D4E 000000 00E239
2013.08.22 20:14:02.076 2: CUL_HM set RolloSchalter04 getConfig
2013.08.22 20:14:02.076 3: HMLAN_Send: HMLAN1 S:+1AF52B,00,01,
2013.08.22 20:14:02.077 3: HMLAN_Send: HMLAN1 S:SA73BB39C stat: 00 t:00000000 d:01 r:A73BB39C m:83 A001 139AF8 1AF52B 00040000000000
2013.08.22 20:14:02.241 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:00124B9F d:FF r:FFC9 m:83 A010 1AF52B 139AF8 0202010A130B9A0CF815FF
2013.08.22 20:14:02.357 3: HMLAN_Parse: HMLAN1 R:RA73BB39C stat:0001 t:00124BA4 d:FF r:FFC9 m:83 A010 1AF52B 139AF8 0202010A130B9A0CF815FF
2013.08.22 20:14:02.488 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:00124C97 d:FF r:FFC9 m:84 A010 1AF52B 139AF8 030000
2013.08.22 20:14:02.492 3: HMLAN_Send: HMLAN1 S:+1AF52B,00,01,
2013.08.22 20:14:02.492 3: HMLAN_Send: HMLAN1 S:SA73BB53C stat: 00 t:00000000 d:01 r:A73BB53C m:84 A001 139AF8 1AF52B 01040000000001
2013.08.22 20:14:03.004 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:00124E9B d:FF r:FFC9 m:84 A010 1AF52B 139AF8 030801000000FE00FE0500
2013.08.22 20:14:03.121 3: HMLAN_Parse: HMLAN1 R:RA73BB53C stat:0001 t:00124EA0 d:FF r:FFC9 m:84 A010 1AF52B 139AF8 030801000000FE00FE0500
2013.08.22 20:14:03.252 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:00124F93 d:FF r:FFC7 m:85 A010 1AF52B 139AF8 030000
2013.08.22 20:14:03.256 3: HMLAN_Send: HMLAN1 S:SA73BB838 stat: 00 t:00000000 d:01 r:A73BB838 m:85 A001 139AF8 1AF52B 0103
2013.08.22 20:14:03.763 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:00125192 d:FF r:FFC9 m:85 A010 1AF52B 139AF8 0100000000
2013.08.22 20:14:03.884 3: HMLAN_Parse: HMLAN1 R:RA73BB838 stat:0001 t:00125197 d:FF r:FFC9 m:85 A010 1AF52B 139AF8 0100000000
#======== store device data:RolloSchalter04 === from: 2013-08-22 20:15:31
#--- entity:RolloSchalter04
# Peer Names:
set RolloSchalter04 peerBulk 00000000,
set RolloSchalter04 regBulk RegL_00: 02:01 0A:13 0B:9A 0C:F8 15:FF 00:00
set RolloSchalter04 regBulk RegL_01: 08:01 09:00 0A:00 0B:00 0C:FE 0D:00 0E:FE 0F:05 10:00 00:00
# timestamp of the readings for reference
# :peerList
# 2013-08-22 20:14:02 :RegL_00:
# 2013-08-22 20:14:03 :RegL_01:
======= finished ===
Nun also FHEM beenden, HomeMatic-LAN-Konfigurator unter Windows starten, einige Sekunden warten, wieder beenden (und merken dass wireshark an der Stelle nicht verkehrt gewesen wäre)
FHEM wieder starten und warten bis alles durchgelaufen ist, dann:
#======== store device data:RolloSchalter04 === from: 2013-08-22 20:20:08
#--- entity:RolloSchalter04
# Peer Names:
set RolloSchalter04 peerBulk 00000000,
set RolloSchalter04 regBulk RegL_00: 02:01 0A:13 0B:9A 0C:F8 15:FF 00:00
set RolloSchalter04 regBulk RegL_01: 08:01 09:00 0A:00 0B:00 0C:FE 0D:00 0E:FE 0F:05 10:00 00:00
# timestamp of the readings for reference
# :peerList
# 2013-08-22 20:18:28 :RegL_00:
# 2013-08-22 20:18:28 :RegL_01:
======= finished ===
(kein Unterschied??) Funktionstest:
2013.08.22 20:20:54.773 2: CUL_HM set RolloSchalter04 80
2013.08.22 20:20:54.773 3: HMLAN_Send: HMLAN1 S:+1AF52B,00,01,
2013.08.22 20:20:54.774 3: HMLAN_Send: HMLAN1 S:SA741FFB5 stat: 00 t:00000000 d:01 r:A741FFB5 m:2D A011 139AF8 1AF52B 0301
2013.08.22 20:20:54.952 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0100 t:001897F3 d:FF r:FFC9 m:2D A002 1AF52B 139AF8 04700C4EB3D23306
2013.08.22 20:20:54.954 3: HMLAN_Delay: HMLAN1 1AF52B
2013.08.22 20:20:55.190 3: HMLAN_Parse: HMLAN1 R:RA741FFB5 stat:0021 t:001897F8 d:03 r:FFC9 m:2D 8002 1AF52B 139AF8 0101C800353D21E29A
2013.08.22 20:20:55.191 3: HMLAN_SdDly: HMLAN1 1AF52B
2013.08.22 20:20:55.191 3: HMLAN_Send: HMLAN1 S:+1AF52B,00,01,
2013.08.22 20:20:55.191 3: HMLAN_Send: HMLAN1 S:SA742006A stat: 00 t:00000000 d:01 r:A742006A m:2E A011 139AF8 1AF52B 0201A0
2013.08.22 20:20:55.608 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0100 t:00189A83 d:FF r:FFC9 m:2E A002 1AF52B 139AF8 0424FEF40499CA06
2013.08.22 20:20:56.541 3: HMLAN_Parse: HMLAN1 R:RA742006A stat:0030 t:00189A88 d:03 r:FFC9 m:2E A002 1AF52B 139AF8 0424FEF40499CA06
2013.08.22 20:21:02.765 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:0018B68A d:FF r:FFC8 m:2F A410 1AF52B 139AF8 0601A000
2013.08.22 20:22:12.254 2: CUL_HM set RolloSchalter04 getConfig
2013.08.22 20:22:12.255 3: HMLAN_Send: HMLAN1 S:+1AF52B,00,01,
2013.08.22 20:22:12.255 3: HMLAN_Send: HMLAN1 S:SA7432E5F stat: 00 t:00000000 d:01 r:A7432E5F m:2F A001 139AF8 1AF52B 00040000000000
2013.08.22 20:22:12.418 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:0019C6AA d:FF r:FFC8 m:2F A010 1AF52B 139AF8 0202010A130B9A0CF815FF
2013.08.22 20:22:12.534 3: HMLAN_Parse: HMLAN1 R:RA7432E5F stat:0001 t:0019C6AF d:FF r:FFC8 m:2F A010 1AF52B 139AF8 0202010A130B9A0CF815FF
2013.08.22 20:22:12.665 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:0019C7A2 d:FF r:FFC8 m:30 A010 1AF52B 139AF8 030000
2013.08.22 20:22:12.669 3: HMLAN_Send: HMLAN1 S:+1AF52B,00,01,
2013.08.22 20:22:12.670 3: HMLAN_Send: HMLAN1 S:SA7432FFD stat: 00 t:00000000 d:01 r:A7432FFD m:30 A001 139AF8 1AF52B 01040000000001
2013.08.22 20:22:13.182 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:0019C9A7 d:FF r:FFC8 m:30 A010 1AF52B 139AF8 030801000000FE00FE0500
2013.08.22 20:22:13.299 3: HMLAN_Parse: HMLAN1 R:RA7432FFD stat:0001 t:0019C9AC d:FF r:FFC8 m:30 A010 1AF52B 139AF8 030801000000FE00FE0500
2013.08.22 20:22:13.430 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:0019CA9F d:FF r:FFC8 m:31 A010 1AF52B 139AF8 030000
2013.08.22 20:22:13.434 3: HMLAN_Send: HMLAN1 S:SA74332FA stat: 00 t:00000000 d:01 r:A74332FA m:31 A001 139AF8 1AF52B 0103
2013.08.22 20:22:13.941 3: HMLAN_Parse: HMLAN1 R:E1AF52B stat:0000 t:0019CC9E d:FF r:FFC8 m:31 A010 1AF52B 139AF8 0100000000
2013.08.22 20:22:14.062 3: HMLAN_Parse: HMLAN1 R:RA74332FA stat:0001 t:0019CCA3 d:FF r:FFC8 m:31 A010 1AF52B 139AF8 0100000000
2013.08.22 20:22:18.134 3: HMLAN_Parse: HMLAN1 R:E1B09BD stat:0000 t:0019DCFF d:FF r:FFBF m:44 8670 1B09BD 000000 00D336
- und es funktioniert wieder...
Ich hoffe das hilft Dir weiter, wenn das wieder auftritt, versuche ich an den wireshark Mitschnitt zu denken...
Beste Grüße,
Andy.
Guten Morgen Martin,
Nachtrag zum gestrigen Fehlerbericht:
Nachdem alles gut funktioniert hatte, hab ich mich kurz anderen Hobbies zugewandt, danach fiel mir ein, noch die Laufzeiten zu kontrollieren. Also kurz noch die meisten der Rollos kurz angepasst, dann alle per Struct versucht zu fahren, worauf bei allen ein MISSING ACK kam. Danach versucht, der Reihe nach Befehle zu schicken und damit die meisten bewegen können. Irgendwann ging RolloSchalter07 wieder verloren (LED dauer-an, keine lokale Bedienung, kein Funk), der blieb bis heute Morgen so, dann ging ich wieder zum Sicherungskasten. Danach waren die AES-Rollos wieder beleidigt.
Dafür lief die ganze Zeit ein ausführliches LOG in ms-Auflösung und ohne hmProtocolEvents. In der Hoffnung, dass darin die Informationen enthalten sind, die Deinem erfahrenen Blick ins Auge stechen, hänge ich das mal ganz frech mit all seinen 6770 Zeilen an...
Damit Du Dir gezielt rauspicken kannst, was Du brachst, hier die wichtigsten Wegmarken:
2013.08.22 19:26:29.889 : Shutdown für 20min, um Aktoren stromlos zu schalten
2013.08.22 19:57:11.365 : Neustart; Zustand danach: RS02,RS03,RS04 mit AES-Problem, RS06 und RS08 nicht gepaired?, Rest OK
2013.08.22 20:01:56.328 : Erster Versuch, alle auf "pct 0" zu setzen (per struct)
2013.08.22 20:03:43.611 : Versuch, alle auf "pct 100" zu setzen (per struct)
2013.08.22 20:04:45.735 : Pairing RolloSchalter06
2013.08.22 20:05:17.089 : Pairing RolloSchalter08
2013.08.22 20:13:42.569 : Erfolgloser Versuch, RolloSchalter04 (AES) zu bewegen, danach getConfig
2013.08.22 20:16:22.871 : Shutdown für Reset per LAN-Konfigurator
2013.08.22 20:17:31.606 : Restart
2013.08.22 20:20:54.773 : Erneuter Versuch, RolloSchalter04 (AES) zu bewegen, danach getConfig
2013.08.22 20:34:08.737 : Versuch, alle auf "pct 0" zu setzen (per struct) - einige noACK
2013.08.22 21:52:11.822 : Beginn, die driveUp / driveDown geradezubiegen
2013.08.22 22:03:26.232 : Versuch, alle auf "pct 55" zu setzen (per struct) - einige noACK, AES-Problem vorhanden
2013.08.22 22:03:52.877 : HMLAN disconnected, waiting to reappear (kommt auch gleich wieder)
2013.08.22 22:04:22.600 : Weiterer Versuch, alle auf "pct 55" zu setzen (einzeln) - einige noACK, danach einzelne RS manuell gefahren
2013.08.23 06:46:38.625 : Versuch, alle auf "pct 100" zu setzen (per struct) - einige noACK - Danach Sicherung rausgenommen für Revival von RolloSchalter06, etwa um 07:00:00 wieder eingeschaltet
2013.08.23 07:01:16.219 : FHEM beginnt, getSerial, getConfig und statusRequiest für alle abzusetzen -> AES-Problem vorhanden
2013.08.23 07:05:53.201 : Verschiedene Fahrbefehle (einzeln)
2013.08.23 07:12:41.169 : Sonnenschutz (per sunpos) setzt ein, versucht RS01..RS04 zu fahren, nur RS01 fährt (AES-Problem bei RS02..RS04)
Zwischendrin immer wieder I:K und die Daten von den Temp-Sensoren und Türgriff-Sensoren.
Mein Plan für heute Abend (außer Du hast eine bessere Idee):
- Alle RolloSchalter auf Werkeinstellung zurücksetzen (per LAN-Konfigurator) und neu pairen, in der Hoffnung, sie "vergessen" dadurch, Probleme zu machen
- Die AES-Signierung erstmal auf einen der Rollos beschränken, der für den Sonnenschutz nicht so relevant ist
- Dann weiter beobachten und berichten in der Hoffnung, Deine Geduld nicht über-zu-strapazieren...
Beste Grüße,
Andy.
Hallo Andy,
jede Menge Events. Ich denke wir muessen die aufspalten und eins nach dem andern angehen.
Erst einmal sehe ich, dass die Bulk-settings deutlisch schneller sind. Vormals gab es eine Sek delay je Rollo.
-> warum ist dies weg? Kann es am hmProtokollEvents liegen?
Was zu sehen ist, dass es einige missing Acks gibt und diese durch wiederholen korrigiert werden.
Ich werden mir noch einenRollo vornehmen, bei dem es das missingAck problem gibt. Hast du hier eine Rollo-nummer mit diesem Effekt?
das mit der generellen nicht-erreichbarkeit ist dann die nächste Baustelle
Gruss Martin
Hallo Martin,
stimmt, als ich die Rollos per struct fahren ließ, liefen sie fast gleichzitig los - zumindest die, die sich bewegen ließen. Hatte das auf den Umstand geschoben dass ich davor die Version vom 04.Aug. hatte, jetzt aber wieder auf der aktuellen SVN-Version fahre. Natürlich hatte davor aber auch die fhem.cfg eine ältere Version als jetzt (hatte vorübergehend die aus dem Backup genommen) - gibt es einen Parameter, der das Delay beeinflusst?
hmProtokollEvents war glaube ich nie gesetzt, habs nur sicherheitshalber auf 0 gestellt, was aber wenn ich richtig gesehen habe, default ist? Anzahl der Notifies hat sich auch nicht geändert und auch sonst habe ich nie versucht, küstliche Delays einzubauen. Sollte denn in der aktuellen SVN Version (vom 22.08.2013) ein Delay vorkommen?
Rollos 02, 03, 04 zeigen den AES-Effekt; wobei ich heute Morgen die 02 und 04 noch manuell gefahren habe, die 02 habe ich glaub ich in Ruhe gelassen (evtl gestern abend noch manuell gefahren).
Grüße,
Andy.
Hallo Andy,
hmProtokollEvents war im ersten Log gesetzt - sonst wären die entsprechenden Logs nicht gekommen. Das hat nachweislich einen delay zur Folge, die Grössenordnung hängt aber vom Level ab, erst der Höchste schlägt richtig zu. Ob dies aber die "dramatischen" Verzögerungen zu verantworten hat kann ich nicht sagen.
Die Grössenordnung der Verzögerung hängt dann sicher von den notifies ab, FHEM muss bei jedem Trigger alle notifies durchsuchen....
Ich schaue mir einmal Rollo 2 und 4 an, ob hier etwas fehlt.
Gruss Martin
Ich habe einmal 2 und 4 durchgesehen - ich kann nicht erkennen, dass es ein missingAck gegeben hat. Zu sehen ist, dass es wiederholungen gibt. Zum einen die 3 mal des HMLAN. Das senden wird dann 3-mal wiederholt, mit dynamischer Zeit (1-4 sec) also max 9 mal sendeversuche. Ich kann in diesem Fall nicht erkennen, dass es einen Fehler gegeben hat.
Unterscheide der beiden Logs sind
- vorher hmProtokollEvents aktiv
- vorher indiskutables system-timing (nicht aus CUL_HM oder HMLAN!)
- vorher messung in CUL_HM, jetzt in HMLAN, also näher am Sender
- jetzt: nicht alle Devices aktiv
Das Problem das erste mal war m.E. klar ein timing problem, unklar wer das System versaute.
Wenn wir jetzt erst einmal die Devices wieder zum Laufen bekommen machen wir einen "research schwenk". Jetzt muss ich neu Denken ;-) Welche Device hängen jetzt noch, was ist der Zustand und welche Logs gibt es?
Gruss Martin
Hi Martin,
das deckt sich mit meinen Beobachtungen, es kommt beim AES-Problem meistens gar nicht zum Missing Ack, es wird nur einfach der Befehl nicht ausgeführt. Gemäß Protokoll sieht es so aus als würden Nachrichten ausgetauscht, am Aktor selbst leuchtet aber die LED nicht auf und die Relais bleiben ruhig.
Dann bleiben wir also vorerst beim aktuellen SVN Stand (soll ich heute nochmal updaten?). Meine aktuellen Versionen:
/usr/share/fhem/FHEM/00_HMLAN.pm:# $Id: 00_HMLAN.pm 3558 2013-07-31 11:24:52Z martinp876 $
/usr/share/fhem/FHEM/10_CUL_HM.pm:# $Id: 10_CUL_HM.pm 3763 2013-08-21 19:26:22Z martinp876 $
Aktuell zeigen RS02, RS03 und RS04 das AES-Problem. Ich versuche nachher an den wireshark-Mitschnitt zu denken:
- getConfig auf allen Aktoren
- set pct 80 auf allen Aktoren
- FHEM stop
- wireshark starten
- LAN-Konfigurator starten und stoppen
- FHEM start (getConfig ist automatisch)
- set pct 70 auf allen Aktoren
- Logfile hochladen
Aus Deiner Sicht OK? Oder denkst Du noch über alternative Strategien nach, um an die passenden Log-Einträge zu kommen? Will Dich nicht mit unnötigen Daten zumüllen ;-)
Grüße,
Andy.
Hi Andy,
ich denke, die Logs sind ok.
Bin an den "rohmessages" des Ablaufs interessiert.
Und eine Beschreibung, was schief gegangen ist, damit ich suchen kann.
Gruss Martin
Hallo Martin,
anbei nun das Log von heute Vormittag. Software Stand wie gestern gepostet.
Zu Beginn des Logs folgende Situation: RS01, RS05..RS08 funktionieren vollständig (alle ohne AES konfiguriert), während RS02,RS03,RS04 auf AES konfiguriert sind und nicht auf Funkbefehle reagieren.
2013.08.24 07:13:45.357 : Beschattungsautomatik setzt ein, versucht RS01..04 zu fahren. Nur 01 fährt, 02..04 bleiben reglos
(Muster wiederholt sich einige Male mit verschiedenen RolloPositionen)
2013.08.24 11:18:07.064 : getConfig auf alle RolloSchalter (einzeln, im 10sek Abstand)
2013.08.24 11:21:39.007 : FHEM stop, dann LAN Konfigurator kurz an (siehe wireshark-Mitschnitt), dann FHEM restart
(ab hier wieder getConfig währen FHEM Start)
2013.08.24 11:38:58.578 : Bulk set pct 15 auf RS01..04 - alle Rollos führen Kommando aus
(weitere Bulk Kommandos, ebenfalls erfolgreich)
2013.08.24 12:20:29.709 : Beschattungsautomatik versucht, RS01..04 auf 40 und RS05..08 auf 0 zu setzen.
(in meiner Abwesenheit; laut Positionsplot hat RS01 das Kommando ausgeführt, alle anderen nicht)
Aktuell ist der Status laut FHEM-Webinterface: RS01=100%, RS02..04=set_100, RS05..08=MISSING_ACK
Im Anhang auch das Logfile mit den RolloPositionen (Auszug passend zu Rohmessages)
Was mir noch aufgefallen ist: Offenbar mische ich irgendwie "set <device> <pos>" und "set <device> pct <pos>" - wird das unterschiedlich gehandhabt oder ist das absolut gleichwertig?
Hoffe das hilft,
beste Grüße,
Andy.
Hi Andy,
logs muss ich noch durchsehen.
set <dev> <pos> und set <dev> pct <pos> ist absolut identisch. Das erstere wird sowieso immer in das 2. umgewandelt (intern). Eigentlich verarbeitet wird immer nur pct.
Gruss Martin
Hallo Andy,
ich denke jetzt wenigstens ein paar statusbytes besser verstanden zu haben.
Es sieht für mich so aus, als ob der AES key nicht akzeptiert wird. Das Kommando wird gesendet, Aktor requested AES, HMLAN antwortet und erhält einen negativen bescheid.
Es sieht so aus als ob AES nicht in allen messages notwendig ist, so dass manche funktionieren. Könnte sein, dass AES beim lesen nicht notwendig ist aber bei allen Setze oder Schreib funktionen.
Hattest du mir schon ein log geschickt, wenn AES funktioniert und du das Rollo setzt? Habe jetzt keins gefunden.
Zum einen versuche ich, diesen Status im WebInterface darzustellen, in der Art AESfailed, AES success. Mal probieren.
Zum 2. - wenn ich es richtig sehe funktioniert AES garnicht in deinem Fall.
Wenn du also einen Fall hast, in dem es funktioniert kann ich es prüfen. Es kann eigentlich nur mit den Kommandos zu tun haben, die zwischen FHEM und HMLAN ausgetauscht werden. Da brauche ich ein Beispiel, muss sich noch suchen, wenn du keins hast.
Gruss Martin
Hi Martin,
Die Sache ist, es funktioniert immer dann für kurze Zeit, nachdem der LAN-Konfigurator lief, siehe letztes Beispiel, restart kurz vor 12, die ersten paar abgesetzten fahrkommandos. Erst wo in diesem Beispiel die beschattungsautomatik einsetzt gehts wieder schief...
Grüße,
Andy.
Kann ich nicht erkennen.
Shutdown 11:21
Lesen von diversen daten nach Hochfahren, alle Rollos bis 11:38
=> kein AES beim Lesen
Ab dann kommen "Setze" kommandos, AES notwendig. Diese funktionieren ALLE nicht.
==> AES funktioniert in diesem File garnicht.
Im Anhang habe ich 2 files, die kannst du einspielen. Das gibt dir infos über AES. Du kannst dann im device nachsehen unter
protEvt_AESresp <Zähler> # anzahl der AES responses, die HMLAN gesendet hat
protEvt_AESerrReject <Zähler> # anzahl der AES responses fehlgeschlagen
Bin noch am Testen der Readings. Zumindest die Errors sollte man anzeigen.
Wenn du also noch einen Fall hast, in dem es wirklich funktioniert, schicke bitte Logs
Gruss Martin
Hi Martin,
super, danke, sobald ich wieder zuhause bin probier ich die 2 Files gleich aus. seltsam dass sich die rollos trotz aes Fehler bewegt haben. spannende Sache jedenfalls :-)
was ich mir zwischenzeitlich überlegt hatte: denkst du es hat Sinn, versuchshalber aus fhem heraus teile des wireshark mitschnitts an den hmlan zu schicken? gibt es einen Mechanismus dafür? dann würde ich das morgen mal versuchen, vielleicht springt dabei ja was raus..?
grüße,
Andy.
Hi Andy,
zu deinen wiresharks - damit komme ich nicht zurecht. Wie speicherst du?
ein pcap wäre der eigentliche output.
Ich kann die messages nicht erkennen, die gesendet werden. Mein wireshark sieht anders aus.
Ja, man kann die messages "roh" schicken, kommt etwas darauf an, welche. Ethernet-packete roh zu schicken macht keinen sinn.
Hast du eigentlich schon einmal probiert den AES code neu zu setzen - mit der PC-SW? Vielleicht ist der Key einfach inkorrekt? Aus der PC-SW kann man dann ja auch einset schicken.
Interessant ist, dass die Rollos funktioniert haben - das verstehe ich nicht. Das hört sich nach einem Bug an..... mal weiter beobachten. Vielleicht verstehe ich etwas falsch.
Gruss Martin
hi Martin,
meine wireshark mitschnitte sind Text Files, die aus "follow TCP stream" als txt gespeichert werden - sieht ähnlich aus wie der Austausch zwischen fhem und hmlan. hab auch jeweils als raw gespeichert - oder wie sollte es richtig sein?
grüße,
Andy.
Hi Martin,
konnte jetzt endlich Deine Dateien einspielen und damit testen. Hab damit reichlich Daten erhoben dann den AES code neu gesetzt und zur Sicherheit alle Aktoren auf Werkszustand gesetzt/neu angelernt, im letzten Schritt dann RS04 und RS08 auf "gesichert" gesetzt. Wirklich interessant wirds vermutlich am Ende, weil beide AES code reject melden, aber nur einer von beiden nicht fährt.
Logfile fhem-2013-08.log-1, beginnt mit fhem shutdown restart - zu Beginn wie gehabt Rollos 02,03,04 mit AES-Problem, entsprechend neuer Log-Eintrag AES code rejected beim Versuch, RS04 zu fahren. abwechselnd AES code reject oder auch nicht, Rollos fahren meistens (bis auf einen Fall, s.U.)
Im Einzelnen (fhem-2013-08.log-1)
2013.08.26 07:26:47.480 : shutdown restart, um neue Treiber einzubinden
2013.08.26 07:26:59.288 : FHEM beginnt, getSerial,getConfig,statusRequest auf allen RolloSchaltern abzusetzen
Zwischendrin funkt die Beschattungsautomatik dazwischen, Rollos fahren aber nicht, AES code rejected
2013.08.26 07:31:00.325 : FHEM shutdown für LAN-Konfigurator Einsatz
2013.08.26 07:35:18.229 : FHEM neustart
2013.08.26 07:35:29.249 : FHEM beginnt, getSerial,getConfig,statusRequest auf allen RolloSchaltern abzusetzen
2013.08.26 07:36:18.728 : Beschattungsautomatik steuer Rollos 01,02,03,04 an - AES code rejected für 02,03,04, [b]aber Rollos fahren![/b]
2013.08.26 07:37:43.464 : Kommando von Webschnittstelle an Rollo 04 - fährt, kein AES code reject
An der Stelle habe ich den Logeintrag leicht modifiziert, um bei AES code reject "src" statt "dst" zu loggen
2013.08.26 07:59:50.054 : shutdown restart - reload 00_HMLAN hätte wohl gereicht...
2013.08.26 08:01:59.293 : set RolloSchalter04 60 - kein AES code reject, Rollo fährt
2013.08.26 08:02:48.449 : set RolloSchalter04 70 - AES code rejected, aber Rollo fährt
2013.08.26 08:05:08.132 : set RolloSchalter04 80 - kein AES code reject, Rollo fährt
2013.08.26 08:05:44.473 : set RolloSchalter04 90 - AES code rejected, aber Rollo fährt
2013.08.26 08:06:24.000 : set RolloSchalter04 90 - kein AES code reject (noch 3x mit der selben Position wiederholt)
2013.08.26 08:06:50.522 : set RolloSchalter04 100 - kein AES code reject, Rollo fährt
2013.08.26 08:09:26.804 : set RolloSchalter04 pct 90 - AES code rejected, aber Rollo fährt
...
(Hier zwischendrin manuell eingegriffen, am besten ignorieren)
...
2013.08.26 08:12:04.172 : set RolloSchalter04 100 - kein AES code reject, Rollo fährt
(ab hier per Endlosschleife im 10sek Abstand in 10% Schritten zwischen 0 und 100 gefahren)
(mal mit / mal ohne AES code reject, Rollos fuhren jedes mal, ausser bei dem hier:)
2013.08.26 08:21:17.733 : set RolloSchalter04 pct 70 - AES code reject, Rollo fährt nicht (auch keine LED Anzeige oder Relais-Geräusch)!!!!
2013.08.26 08:29:38.007 : Endlosschleife gestoppt
2013.08.26 09:16:06.342 : set RolloSchalter04 15 - kein AES code reject, Rollo fährt
----
Hier habe ich nun FHEM wieder beendet, per LAN-Konfigurator einen neuen AES-Key vergeben, ALLE Rolloschalter auf Werkszustand zurückgesetzt, wieder alle angelernt und FHEM neu gestartet. Dort dann driveUp und driveDown gesetzt. Ausserdem ein paar Rollos gefahren, siehe fhem-2013-08.log-2
----
Dann FHEM wieder gestoppt, LAN-Konfigurator geöffnet und RS04,RS08 jeweils auf "Gesichert" umgestellt. Dabei gesehen, dass driveUp/driveDown noch auf Werkseinstellung stehen (50s).
fhem-2013-08.log-3: FHEM neu gestartet und versucht, alle Rollos zu fahren. AES code reject auf RS04 und RS08. Unterschied: Rollo RS04 bewegt sich, RS08 nicht. Vielleicht erste Hinweise?
Jede Menge Daten, ich hoffe es ist was brauchbares dabei....
Beste Grüße,
Andy.
Nachtrag: nach ein paar weiteren versuchen habe ich RS04 und RS08 nochmals auf werkseinstellungen zurůckgesetzt und aes-sign nicht wieder aktiviert. Während des fhem Starts kam es dann zu einer Situation mit schnellen Richtungswechseln, seitdem fahren beide Motoren nur noch abwärts. sieht ganz nach dem verklebte-relais-kontakte-syndrom aus.... vorerst scheinen die beiden Jungs aus dem Spiel zu sein...
Beste grüße,
Andy.
Edit: Hab die beiden Motoren auf Handschalter zurückgebaut - und sie fahren immer noch nur in eine Richtung...
Hi,
habe version 3802 eingestellt. Hier kann man für AES 2 neue ProtokollEvents einsehen:
prot_AESerrReject # Anzahl nicht erfolgreicher AES anforderungen
prot_AESok # Anzahl erfolgreicher AES Anforderungen
Eine Übersicht bekommt man mit HMInfo (immer gut für Übersichten)
set hm param -d prot_AESok prot_AESerrReject
Zu beachten ist, dass bei einem deiner Versuche HMLAN "Zusammengebrochen" ist. Hat also den Status ERROR-OVERLOAD. FHEM blockiert die Übertragung bis HMLAN wieder aktiv ist.
Gruss Martin
Hi Martin,
kurzes Update: Beide Rollos sind wieder OK, anscheinend hatte ich es geschafft, die Endpositionen in den Motoren neu zu setzen - nach einer Neukalibrierung funktioniert jetzt alles wieder, auch die Aktoren sind fehlerfrei.
Bin jetzt wieder mit der aktuellsten SVN Version dabei, habe aktuell einen der Aktoren auf AES konfiguriert, konnte bislang aber noch keine prot_AESok oder prot_AESerrReject sehen.
Beste Grüße,
Andy.
Hallo Andy,
hier eine erweiterte Version.
kannst du es einmal einbauen und noch einmal loggen?
Problem war, dass das erste AES vom device rejected wird. Das habe ich noch nicht abgefangen.
Warum es zu dem AES Problem kommt kann ich nicht sagen - evtl ist dies normal nach restart... wird das log zeigen. Am AES selbst habe ich nichts geaendert - kann ich garnicht
Gruss Martin
Hallo Martin,
hab eben ein update durchgeführt, 00_HMLAN.pm ersetzt und fhem neu gestartet. Dann ohne über die Windows Software zu gehen direkt
set RolloSchalter02 regSet sign on
abgesetzt, etwas gewartet und dann das Rollo munter in der Gegend herumgefahren:
2013.09.18 21:10:58.824 2: CUL_HM set RolloSchalter02 pct 20
2013.09.18 21:10:58.825 3: HMLAN_Send: HMLAN1 S:S327B8A4A stat: 00 t:00000000 d:01 r:327B8A4A m:93 A011 139AF8 1AB518 020128
2013.09.18 21:10:59.000 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0100 t:262B94F0 d:FF r:FFBF m:93 A002 1AB518 139AF8 0423E97D17298908
2013.09.18 21:10:59.237 3: HMLAN_Parse: HMLAN1 R:R327B8A4A stat:0021 t:262B94F5 d:04 r:FFC1 m:93 8002 1AB518 139AF8 010100103F0C4300B6
2013.09.18 21:11:06.110 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0000 t:262BB0C8 d:FF r:FFBE m:94 A410 1AB518 139AF8 06012800
2013.09.18 21:11:12.617 3: HMLAN_Send: HMLAN1 I:K
2013.09.18 21:11:12.621 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:262BCA3E IDcnt:000F
2013.09.18 21:11:37.632 3: HMLAN_Send: HMLAN1 I:K
2013.09.18 21:11:37.636 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:262C2BF9 IDcnt:000F
2013.09.18 21:11:46.033 3: HMLAN_Parse: HMLAN1 R:E1B09BD stat:0000 t:262C4CBF d:FF r:FFB8 m:44 8670 1B09BD 000000 008A55
2013.09.18 21:11:58.549 2: CUL_HM set RolloSchalter02 pct 30
2013.09.18 21:11:58.549 3: HMLAN_Send: HMLAN1 S:S327C7396 stat: 00 t:00000000 d:01 r:327C7396 m:94 A011 139AF8 1AB518 02013C
2013.09.18 21:11:58.725 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0100 t:262C7E45 d:FF r:FFBE m:94 A002 1AB518 139AF8 042C10745E36B808
2013.09.18 21:11:59.657 3: HMLAN_Parse: HMLAN1 R:R327C7396 stat:0030 t:262C7E4B d:04 r:FFBE m:94 A002 1AB518 139AF8 042C10745E36B808
2013.09.18 21:11:59.657 3: HMLAN_Parse: HMLAN1 AES code rejected for 139AF8 48
2013.09.18 21:12:02.635 3: HMLAN_Send: HMLAN1 I:K
2013.09.18 21:12:02.639 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:262C8DA7 IDcnt:000F
2013.09.18 21:12:03.298 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0000 t:262C9035 d:FF r:FFBF m:95 A410 1AB518 139AF8 06013C00
2013.09.18 21:12:15.134 2: CUL_HM set RolloSchalter02 pct 35
2013.09.18 21:12:15.134 3: HMLAN_Send: HMLAN1 S:S327CB45F stat: 00 t:00000000 d:01 r:327CB45F m:95 A011 139AF8 1AB518 020146
2013.09.18 21:12:15.311 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0100 t:262CBF11 d:FF r:FFBF m:95 A002 1AB518 139AF8 0445BA05482C3A08
2013.09.18 21:12:16.243 3: HMLAN_Parse: HMLAN1 R:R327CB45F stat:0030 t:262CBF17 d:04 r:FFBF m:95 A002 1AB518 139AF8 0445BA05482C3A08
2013.09.18 21:12:16.244 3: HMLAN_Parse: HMLAN1 AES code rejected for 139AF8 48
2013.09.18 21:12:18.615 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0000 t:262CCC0C d:FF r:FFBF m:96 A410 1AB518 139AF8 06014600
2013.09.18 21:12:27.640 3: HMLAN_Send: HMLAN1 I:K
2013.09.18 21:12:27.644 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:262CEF58 IDcnt:000F
2013.09.18 21:12:29.476 2: CUL_HM set RolloSchalter02 pct 40
2013.09.18 21:12:29.477 3: HMLAN_Send: HMLAN1 S:S327CEC66 stat: 00 t:00000000 d:01 r:327CEC66 m:96 A011 139AF8 1AB518 020150
2013.09.18 21:12:29.654 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0100 t:262CF71B d:FF r:FFBF m:96 A002 1AB518 139AF8 04ED6E3EC6BCEA08
2013.09.18 21:12:29.890 3: HMLAN_Parse: HMLAN1 R:R327CEC66 stat:0021 t:262CF720 d:04 r:FFC1 m:96 8002 1AB518 139AF8 010146103FA435060F
2013.09.18 21:12:30.331 3: HMLAN_Parse: HMLAN1 R:E197D4E stat:0000 t:262CF9D0 d:FF r:FFBA m:6B 8670 197D4E 000000 00DC3E
2013.09.18 21:12:33.036 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0000 t:262D0463 d:FF r:FFBD m:97 A410 1AB518 139AF8 06015000
2013.09.18 21:12:43.377 2: CUL_HM set RolloSchalter02 pct 45
2013.09.18 21:12:43.378 3: HMLAN_Send: HMLAN1 S:S327D22B3 stat: 00 t:00000000 d:01 r:327D22B3 m:97 A011 139AF8 1AB518 02015A
2013.09.18 21:12:43.553 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0100 t:262D2D68 d:FF r:FFBE m:97 A002 1AB518 139AF8 044C83572EF45D08
2013.09.18 21:12:43.790 3: HMLAN_Parse: HMLAN1 R:R327D22B3 stat:0021 t:262D2D6E d:04 r:FFC1 m:97 8002 1AB518 139AF8 010150103FCC8AE13F
2013.09.18 21:12:46.861 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0000 t:262D3A66 d:FF r:FFBF m:98 A410 1AB518 139AF8 06015A00
2013.09.18 21:12:51.459 2: CUL_HM set RolloSchalter02 pct 50
2013.09.18 21:12:51.460 3: HMLAN_Send: HMLAN1 S:S327D4245 stat: 00 t:00000000 d:01 r:327D4245 m:98 A011 139AF8 1AB518 020164
2013.09.18 21:12:51.636 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0100 t:262D4CFB d:FF r:FFBE m:98 A002 1AB518 139AF8 04E98EF734D00708
2013.09.18 21:12:51.872 3: HMLAN_Parse: HMLAN1 R:R327D4245 stat:0021 t:262D4D01 d:04 r:FFC1 m:98 8002 1AB518 139AF8 01015A103FCAE09ED0
2013.09.18 21:12:52.642 3: HMLAN_Send: HMLAN1 I:K
2013.09.18 21:12:52.646 3: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0061517 d:139AF8 O:139AF8 t:262D5106 IDcnt:000F
2013.09.18 21:12:55.017 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0000 t:262D5A44 d:FF r:FFBE m:99 A410 1AB518 139AF8 06016400
2013.09.18 21:13:00.474 2: CUL_HM set RolloSchalter02 pct 60
2013.09.18 21:13:00.475 3: HMLAN_Send: HMLAN1 S:S327D657C stat: 00 t:00000000 d:01 r:327D657C m:99 A011 139AF8 1AB518 020178
2013.09.18 21:13:00.651 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0100 t:262D7035 d:FF r:FFBD m:99 A002 1AB518 139AF8 04C9EE1C81FE3508
2013.09.18 21:13:00.888 3: HMLAN_Parse: HMLAN1 R:R327D657C stat:0021 t:262D703B d:04 r:FFC0 m:99 8002 1AB518 139AF8 01016410406CEC7E2C
2013.09.18 21:13:05.260 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0000 t:262D8249 d:FF r:FFC0 m:9A A410 1AB518 139AF8 06017800
2013.09.18 21:13:08.981 2: CUL_HM set RolloSchalter02 pct 0
2013.09.18 21:13:08.982 3: HMLAN_Send: HMLAN1 S:S327D86B7 stat: 00 t:00000000 d:01 r:327D86B7 m:9A A011 139AF8 1AB518 020100
2013.09.18 21:13:09.158 3: HMLAN_Parse: HMLAN1 R:E1AB518 stat:0100 t:262D9172 d:FF r:FFC0 m:9A A002 1AB518 139AF8 049984CF8D6A8608
2013.09.18 21:13:10.090 3: HMLAN_Parse: HMLAN1 R:R327D86B7 stat:0030 t:262D9177 d:04 r:FFC0 m:9A A002 1AB518 139AF8 049984CF8D6A8608
2013.09.18 21:13:10.091 3: HMLAN_Parse: HMLAN1 AES code rejected for 139AF8 48
Augenscheinlich gibt es Situationen mit reject und welche ohne. Aber zumindest im Moment scheint alles zu funktionieren.
Zum weiter Testen habe ich nun 6 von den 8 Aktoren auf sign eingestellt, logfile läuft sowieso immer mit. Sollte noch was vorkommen, schick ich weitere Einträge. Auf jeden Fall an der Stelle ein rießiges Dankeschön für Deinen unermüdlichen Einsatz und Hilfe, das ist echt Klasse!
Beste Grüße,
Andy.
hi Andy,
ist befremdlich.
1) danke für die logs, sehr gut für die Auswertung
2) ALLE deine Kommandos wurden ausgeführt, auch die mit AES reject
3)die AES reject zeigen kein ACK, werden dennoch bearbeitet.
4)bei AES reject wird (bisher) nicht wiederholt. Die nächste Version wird wiederholen
Version 3924 hat ein verbessertes handling
- protEvt_AESerrReject zählung
- Wiederholung von messages wenn AES Probleme gemeldet werden
gerne noch einmal einen log nach einem test... .und bitte prüfen, dass die Zähler korrekt arbeiten
Danke Martin
Hi Martin,
ok, werd ich machen - den letzten Punkt hab ich aber noch nicht verstanden, wie achte ich auf korrekte Funktion der Zähler?
Grüße,
Andy.
prüfen, ob die proto-events auch inkrementieren...
Mit dem Thread Link (http://forum.fhem.de/index.php?topic=14926.msg96125#msg96125) kommt die Auflösung des Ganzen, damit ist dieses Thema aus meiner Sicht abgeschlossen, auf zum Nächsten :-)
Grüße,
Andy.