Hilfe bei Protokollanalyse

[BigBen]

Hallo Martin,

erstmal vielen Dank für Deine Unterstützung - ich kann jetzt ein devicepairing durchführen.

Aber:

Wenn ich den W55-Taster über die Windows-Config-Software gepairt habe, kann ich kein deviceparing mehr über fhem vornehmen.
Ich dachte bisher, es würde ausreichen, wenn man dieselbe ID vom HMLAN in FHEM verwendet, da die eigentlichen Infos sowieso in den Geräten selber gespeichert sind (also auch im HMLAN).

Fakt ist:

Der Taster lässt sich erst problemlos programmieren, wenn er in der Windows-Software gelöscht ist.

Was habe ich da noch nicht verstanden?

cu,
Ben

[martinp876]

Hi Ben,

verstehe ich nicht.
Was meinst du mit "in der win-SW gelöscht"? Wenn FHEM läuft ist doch die WIN-SW abgeschaltet...?

Peeren (devicepair) kann immer nur die zentrale, also die "gepairte".
Ich benutze als ID der Zentrale immer die gleich3 ID, WIN configurator oder FHEM, egal. Wenn du dies unterschiedlich eingestellt hast kommt es zu konflikten.

Lokales peeren (also ohne Zentrale) funktioniert nur, wenn keine Zentrale eingetragen ist - also die ID des "pair" 000000 ist.

Gruss
Martin

[BigBen]

Hi,

wenn der Taster in der Windows Oberfläche angelernt wurde und somit als Gerät in der Liste erscheint, kann ich mit Fhem kein devicepair durchführen, obwohl die HMlan ID unter Windows gleich der ID unter Fhem ist.

Ich dachte eigentlich das dies aufgrund der selben ID möglich ist.

Ich hatte schon mal die Vermutung, dass dies mit dem Systemschlüssel zusammenhängt (den ich zu Beginn geändert habe), aber dieser steckt ja eigentlich auch im HMLAN Adapter und nicht in der Software.

Cu,
Ben

[martinp876]

wenn der Taster in der Windows Oberfläche angelernt wurde und somit als Gerät in der Liste erscheint, kann ich mit Fhem kein devicepair durchführen, obwohl die HMlan ID unter Windows gleich der ID unter Fhem ist.

das ist seltsam, kenn ich so nicht. Sollte eigentlich funktionieren.
Laeuft FHEM parallel zur Windows SW? Was dann passiert weiss ich nicht. Bei mir laeuft entweder oder.

[BigBen]

Hallo,

entweder fhem oder die Windows-Software läuft.

Was mir bis dato aufgefallen ist, wenn es nicht funktioniert:

In den Telegrammen erscheint dann immer 0030 als Status:

R58C1D635,0030,046DDE1D,01,FFA4,0...

cu,
Ben

[martinp876]

Die Kommunikation mit HMLAN hat noch sehr viele Loecher - leider.

Die findest du in 00_HMLAN. Bisher habe ich noch kein wirkliches interworking gebaut - aber noetig waere es schon.
Status habe ich folgendes:
man muss das highbyte und das lowbyte getrennt betrachten. Eigentlich ist es sowieso ein Bitfeld, das man dekodieren muss
im low-byte sind events bezueglich der message.
Im Highbyte scheinen mehr generelle Stati des HMLAN zu kommen.

#  xx 00= 'E' messages haben immer '00', nie 'R'. Message ohne "Bezug"
#  xx 01=ack received for a message we sent
#  xx 02=message send done, no ack was requested
#  xx 08=nack - ACK was requested, 3 times send, but no ack received
#  xx 21= ?
#  xx 30= ?
#  xx 81=open
#  01 xx=??
#  02 xx=trouble in processing
#  04 xx=severe trouble in processing. need power cycle since no way identified to resolve this state.


die xx 30 habe ich noch nicht gesehen. Kannst du den Ablauf schicken? Einen groesseren Ausschnitt. Stati groessen 02 halte ich generell fuer bedenklich und sind offensichtlich Fehler.

Wenn ich Zeit und Lust habe werde ich noch einmal HMLAN untersuchen. Leider ist alles nur reverse engineering - und ich habe kein gutes Beispiel, wie eq3 mit HMLAN redet (ausser die Win config SW - die kann aber nicht viel...). Das verhalten laesst sich deutlich verbessern - timing und error-recovery

Gruss
Martin