set HM_3DBF63 unpair

[hnnmn]

Hallo zusammen

Kontext:
Ich habe 5x HM-PB-2-WM55-2 gebraucht gekauft, sie wurden aus der Zentrale gelöscht, aber sie scheinen noch mit ihrer alten Zentrale (nicht Standard-Zertifikat, ...) irgendwie konfiguriert zu sein. Heisst, ich kann sie aktuell nicht verwenden. Config-Taste 5sec: konstant rot.

Beim gleichen Verkäufer habe ich noch Rolladen-Aktoren HM-LC-BI1-FM gekauft und mir gedacht, ich versuche diese mal kurz mit der Zentrale zu pairen, aber nur zum Testen. Danach wieder unpairen, um sie dann irgendwann mit o.g. Tastern direkt zu peeren (oder pairen), damit sie auch ohne Zentrale funktionieren würden... danach dann noch mit der Zentrale für eine automatisierte Steuerung. Meine Zentrale ist natürlich FHEM... der Vollständigkeit wegen.

Fragen an euch:
1.) Unpair: der HM_3DBF63 ist ein HM-LC-BI1-FM und ich mache:

Code Auswählen Erweitern

set HM_3DBF63 unpair
Gefühlt: 0.0 Feedback, ob das jetzt geklappt hat und ich finde auch unter https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen nichts, was es mir erklärt.
Wenn ich mit den 2x 5sec drücken das Gerät resette und dann bspw. ein get_config in FHEM probiere, funktioniert es nicht mehr.
1.1==> funktioniert das für ein HM-LC-BI1-FM einfach per reset?
1.2==> wenn ich korrekt unpairen möchte, was müsste ich machen? Genauer: wie teste ich, ob das unpair durch ist?
1.3==> denke ich richtig, wenn ich davon ausgehe, dass das unpair im gepairten Gerät in meinem Fall die Zentrale aus der pairing-liste nimmt (R-pairCentral,...)?

2.) Habe ich ausser sie zu EQ3 einzuschicken eine Chance, die HM-PB-2-WM55-2 wieder zum Laufen zu bringen? Aktuelles Verhalten: 5sec drücken und dann kommt einfach konstant rot, bis ich wieder los lasse.

Beste Grüsse
Martin

[MadMax-FHEM]

So mal langsam.

Also:

wenn ein Homematic Gerät bereits mit einer Zentrale GEPAIRED ist, dann:

- kann es nicht mehr mit einer anderen Zentrale gepaired werden (es sei denn die HMID ist die selbe, dann wird allerdings das Gerät nicht wirklich neu gepaired, sondern lediglich die neue Zentrale kennt nun das Gerät als "eigenes", das Gerät selbst kennt keinen Unterschied und sieht die neue Zentrale [gleiche HMID] eben als die alte/bekannte Zentrale an)

- kann KEIN direktes PEERING (Verbindung Sensor/FB etc. -> Aktor etc.) durch "Knöpfchen drücken" mehr aktiviert werden, nur noch über die Zentrale (CCU oder fhem oder oder)

- ein unpair funktioniert NUR über die bekannte/akzeptierte Zentrale (siehe Punkt[e] zuvor) (meist steht bei fhem am Ende des unpair ein "Missing ACK" weil ja fhem drauf wartet, das Gerät aber ja nach dem "unpair" keine Zentrale mehr hat der es ein ACK schicken würde/könnte   )


Wenn ein Gerät also bereits an eine Zentrale angelernt war und so verkauft wurde (ganz schlechter Stil!!!), dann geht eigentlich nur Zurücksetzen wie in der Bedienungsanleitung des Gerätes beschrieben...

Aber Achtung: wenn auch AES (mit eigenem Schlüssel) in der alten Zentrale verwendet wurde, dann geht nur noch einschicken!

Also wenn das Gerät bereits an eine Zentrale angelernt war, kannst du es bei deinem fhem NICHT mehr anlernen (außer du weißt die ursprüngliche HMID [Identifikation der zentrale gegenüber dem Gerät]) und somit auch NICHT über fhem ein unpair (oder irgendwas anderes) aufrufen!


Nicht verwechseln mit "MITLESEN":

es ist Funk und somit wird das von fhem empfangen und einem Gerät zugeordnet (wenn noch nicht existent und autocreate aktiv wird eines angelegt).

Das hat NICHTS mit PAIREN zu tun!!
(viele halten das schon irrtümlich für ein gepairtes Gerät!!)

Zu sehen wäre der PAIRING-Zustand an den Readings: PairedTo oder R-PairCentral

Gruß, Joachim

[hnnmn]

Danke Joachim

wenn ein Homematic Gerät bereits mit einer Zentrale GEPAIRED ist, dann:

- kann es nicht mehr mit einer anderen Zentrale gepaired werden
- kann KEIN direktes PEERING
- ein unpair funktioniert NUR über die bekannte/akzeptierte Zentrale (siehe Punkt[e] zuvor) (meist steht bei fhem am Ende des unpair ein "Missing ACK" weil ja fhem drauf wartet, das Gerät aber ja nach dem "unpair" keine Zentrale mehr hat der es ein ACK schicken würde/könnte   )

Danke bis hier hin - das hatte ich verstanden (oder glaubte ich und somit bestätigt... super).
Dass ich ein unpair an Folge-MissingACKs erkenne, hatte ich mir heute überlegt, ist irgendwie nicht schön, aber technisch nachvollziehbar und wenn man das weiss, kann man damit arbeiten

Wenn ein Gerät also bereits an eine Zentrale angelernt war und so verkauft wurde (ganz schlechter Stil!!!), dann geht eigentlich nur Zurücksetzen wie in der Bedienungsanleitung des Gerätes beschrieben...

Aber Achtung: wenn auch AES (mit eigenem Schlüssel) in der alten Zentrale verwendet wurde, dann geht nur noch einschicken!

Ich meinte, irgendwann mal gelesen zu haben, dass nicht alle Komponenten diese AES-Verschlüsselung nutzen; wenn ich drüber nachdenke, ist das aber vermutlich schlicht Teil des Protokolls und somit doch immer der Fall, oder?

Wird beim Pairing mit einer Zentrale deren AES-Key in das Gerät geschrieben? Wie würde man den da wieder auf default setzen? Bei einem unpair kommt automatisch auch ein AES-Key-Reset (Ausliefer-Zustand, Default-Key)?

Meine Option neben Einschicken, scheint zurückschicken. Der Verkäufer hat angeboten, die noch korrekt abzulernen... macht das Sinn? Nachdem ich sie nicht mal mehr resetten konnte, sind sie vermutlich nach wie vor bei ihm brauchbar/resetbar, da die Zentrale und das Gerät sich bzgl. AES-Key noch verstehen. So in etwa richtig verstanden?

Also wenn das Gerät bereits an eine Zentrale angelernt war, kannst du es bei deinem fhem NICHT mehr anlernen (außer du weißt die ursprüngliche HMID [Identifikation der zentrale gegenüber dem Gerät]) und somit auch NICHT über fhem ein unpair (oder irgendwas anderes) aufrufen!

Nicht verwechseln mit "MITLESEN":

es ist Funk und somit wird das von fhem empfangen und einem Gerät zugeordnet (wenn noch nicht existent und autocreate aktiv wird eines angelegt).

Das hat NICHTS mit PAIREN zu tun!!
(viele halten das schon irrtümlich für ein gepairtes Gerät!!)

Zu sehen wäre der PAIRING-Zustand an den Readings: PairedTo oder R-PairCentral

Gruß, Joachim

Mitlesen und R-PairCentral ist grundsätzlich klar. Ich verstehe zwar nach wie vor trotz noch- und nochmals lesen nicht, wie die Prozess-Ablauf-Schritte sind beim Pairen, aber das get-config nach dem AutoCreate und das gelegentliche Drücken am Gerät, bis die pending commands weg sind, funktioniert idR dann immer irgendwann...

Nochmals besten Dank!

Gruss
Martin

[MadMax-FHEM]

Dass ich ein unpair an Folge-MissingACKs erkenne, hatte ich mir heute überlegt, ist irgendwie nicht schön, aber technisch nachvollziehbar und wenn man das weiss, kann man damit arbeiten

Aber natürlich im Auge behalten: nicht jedes missingACK ist ein unpair

Ich meinte, irgendwann mal gelesen zu haben, dass nicht alle Komponenten diese AES-Verschlüsselung nutzen; wenn ich drüber nachdenke, ist das aber vermutlich schlicht Teil des Protokolls und somit doch immer der Fall, oder?

Wird beim Pairing mit einer Zentrale deren AES-Key in das Gerät geschrieben? Wie würde man den da wieder auf default setzen? Bei einem unpair kommt automatisch auch ein AES-Key-Reset (Ausliefer-Zustand, Default-Key)?

Ja, nicht alle gleich zu beginn.
"Nur" sowas wie "Fenstersensoren" etc. (halt welche die unter "security/Alarmanlage" laufen)...

ABER: man kann es nat. auch selber aktivieren. Dabei wird erst mal der eq3-Schlüssel verwendet. Ist somit komplett Quatsch (weil der mittlerweile "bakannt" ist). Damit ist ein Zurücksetzen auch nicht "schlimm"
Allerdings wenn man einen eigenen AES-Schlüssel vergeben hat und den nicht (mehr) hat, ist es nicht gut. Weil dann hilft eigentlich nur einschicken zu eq3.

Ich weiß nicht wie das ist, wenn der Verkäufer AES aktiviert und einen eigenen Schlüssel vergeben hatte, die Geräte dann "einfach" eingepackt und verkauft hat, du sie zurückgesetzt hast (oder "versucht") und ihm dann zum "unpair" zurück schickst.
Ich bin nicht sicher, ob er das dann noch kann. Kann eigentlich nur gehen, wenn das Gerät den Reset ablehnt, wenn ein eigener Schlüssel vergeben wurde. Bei "nur" AES (ohne eigenen Schlüssel) kann man die ganz einfach zurücksetzen und gut (aber wie geschrieben der eq3-Schlüssel ist "bekannt").

Daher: ob zurückschicken noch Sinn macht kann ich somit nicht wirklich sagen. Aber gegen Geld: ja
Weil wie geschrieben: ganz schlechter Stil vom Verkäufer!
Und ob du die "einfach so" zu eq3 einschicken kannst etc. musst du mit eq3 klären...

https://wiki.fhem.de/wiki/AES_Encryption

Mitlesen und R-PairCentral ist grundsätzlich klar. Ich verstehe zwar nach wie vor trotz noch- und nochmals lesen nicht, wie die Prozess-Ablauf-Schritte sind beim Pairen, aber das get-config nach dem AutoCreate und das gelegentliche Drücken am Gerät, bis die pending commands weg sind, funktioniert idR dann immer irgendwann...

Also Ablauf in etwa:

du setzt fhem/Zentrale in "Anlernmodus"

gleiches beim Gerät. Das schickt dann eben (eine) Anlernnachricht(en) wo eben Typ, Seriennummer, etc. drin steht.

wenn autocreate aktiv ist, dann wird schon mal ein Gerät angelegt

Nun müssen fhem/Zentrale und das Gerät noch ein paar Daten austauschen, u.a. die HMID ("Kennung" der Zentrale / ab jetzt nimmt das Gerät nur noch Befehle entgegen, die von dieser HMID kommen)

Dann macht fhem automatisch (meine ich) einen getConfig, um weitere Daten zu lesen: Kanäle, Einstellungen (Register), etc.

Bei Batteriebetriebenen Geräten heißt es jetzt: entweder warten oder eben "aufwecken" ("Knöpfchen drücken")...

Und solange eben cmds_pending sind ist die Kommunikation/Datenaustausch noch nicht fertig.


Daher: bei Homematic beim Anlernen (gerade bei Batteriegeräten) immer etwas Geduld mitbringen

Viel Spaß und Erfolg noch, Joachim