HM-LC-Bl1PBU-FM nicht mehr setzbar

[gandy]

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%

Code Auswählen Erweitern


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


Code Auswählen Erweitern


#======== 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:

Code Auswählen Erweitern


#======== 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:

Code Auswählen Erweitern


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.

[gandy]

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:

Code Auswählen Erweitern


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.

[martinp876]

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

[gandy]

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.

[martinp876]

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

[martinp876]

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

[gandy]

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:

Code Auswählen Erweitern


/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.

[martinp876]

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

[gandy]

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.

Code Auswählen Erweitern


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.

[martinp876]

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

[martinp876]

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

[gandy]

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.

[martinp876]

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

[gandy]

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.

[martinp876]

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