HM-LC-Bl1PBU-FM nicht mehr setzbar

Begonnen von gandy, 15 August 2013, 18:32:48

Vorheriges Thema - Nächstes Thema

gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

gandy

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?
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

martinp876

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

gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

martinp876

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




gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

martinp876

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

gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

martinp876

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

gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

martinp876

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

gandy

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.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

martinp876

ok - wie gesagt, bitte die rohmessages.
Gruss Martin

gandy

Ah, right, wollte ich ohnehin gefragt haben, was genau muss ich tun, um an die Rohmessages (und ms-Auflösung) zu kommen?

Danke,
Andy.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

martinp876

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