Reset-Schutz bei eigenem AES-Schlüssel?

[Pfriemler]

Ja, Fragezeigen.
Denn eigentlich ist hier immer die Rede davon, dass ein gesetzter AES-Schlüssel einen lokalen Reset verhindert. Ich habe das jetzt an einem Wandschalter und einem Energiemesszwischenstecker testweise probiert und kann das nicht verifizieren: Die Schalter lassen sich problemlos zurücksetzen.

Kann es sein, dass der große Bruder CCU in diesem Zusammenhang localResDis explizit dazu setzt?

Im Detail bin ich so vorgegangen (bedarfsweise natürlich immer incl. getConfig):
- assignHMKey
- sign on
- Schaltvorgang ein/aus
-> aesCommToDev = ok und aesKeyNbr = 02
sind für mich Zeichen eines erfolgreich gesetzten und angewendeten AES-Schlüssels.
Trotzdem lassen sich beide ohne Probleme lokal zurücksetzen:
- 4s drücken bis langsames blinken (grün bzw gelb für Schalter/Zwischenstecker)
- 4s drücken bis schnelles Blinken (grün / 3x kurz rot)
Beide senden anschließend ihren Status broadcast, reagieren nicht auf Bedienung aus FHEM, lassen sich aber mit hmPairSerial sofort wieder anlernen.

Unabhängig davon führt das Setzen von localResDis auf on zum gewünschten Ergebnis, unabhängig von aesKeyNr und sign:
- 4s drücken bis langsamens Blinken (grün bzw. gelb)
- 4s drücken (Schalter: grün geht sofort aus, Zwischenstecker leuchtet 2s rot)
und natürlich keine Einstellung verändert.

Nettes Randdetail zum Fixen:
Der Schalter meldet als Registerwert für localResDis "on", der Energiemesszwischenstecker hingegen "undef lit: 1" Das ist auch kein Fehler von hm.js (was den Wert dann allerdings nicht darstellen kann), sondern erscheint auch in list und regTable. "off" wird von beiden korrekt gemeldet.

edit: Denkfehler?
Möglichweise wird der Aktor lokal resettet, behält aber seinen AES-Schlüssel. Schalte ich nach dem Wiederanlernen jedoch "sign on", wechselt aesKeyNr zu 00.
Natürlich kennt die Zentrale den richtigen Schlüssel und deswegen klappt das Anlernen...
Aber wieso dann aesKeyNr = 00?

Leider habe ich kein zweites FHEM oder eine CCU zum Testen. *
Immerhin würde das aber erklären, warum hier hin und wieder davon berichtet wird, dass sich Geräte resetten, aber stur nicht anlernen lassen. Ich war davon ausgegangen, dass in solchen Fällen ein lokaler Reset gar nicht möglich ist.

*edit2: Brauche ich überhaupt ein zweites FHEM? reicht nicht ein zweites IO mit abweichender HMID außerhalb der VCCU?

[MadMax-FHEM]

Hallo Pfriemler,

Interessante Fragestellung!
Und guter Test...

Wenn auch (von mir) mit unerwartetem Ergebnis

*edit2: Brauche ich überhaupt ein zweites FHEM? reicht nicht ein zweites IO mit abweichender HMID außerhalb der VCCU?

Wenn du ein 2tes IO hast, dann ist doch der Weg zu einem 2ten fhem nicht weit

Einfach auf der selben Plattform fhem mit anderer Konfig (wo eben das andere IO mit anderer HMID eingebunden ist) manuell starten

Ob man das für den Test braucht: keine Ahnung

Gruß, Joachim (EDIT: der [noch] kein AES nutzt   )

[Pfriemler]

So, neue Erkenntnisse, die meinen Verdacht untermauern:
Ich brauche kein zweites FHEM, nur ein zusätzliches IO.
- HMLAN ("Ufo") ausm Schrank gekramt, angeschlossen
- abweichende HMID zur VCCU gesetzt (praktisch: das originale vom HMLAN)
- sichergestellt, dass HMLAN nicht zur vccu gehört.

Also eigener hm-Key ist ja bei der VCCU hinterlegt. Wenn ich weitere Geräte über diesen anderen HMLAN kopple, sollten diese den default Schlüssel nutzen, richtig?

Da einige Versuche zu Kleinholz führten, hier die richtige Reihenfolge:

- Switch an VCCU angelernt, assignHMKey, sign on, Test: aesKeyNr = 02, alles ok. Ist mit eigenem AES unterwegs.
- lokaler Reset am Switch
- IOs der VCCU händisch deaktiviert (close) (wichtig, sonst klappt das Anlernen am HMLAN nicht, auch umgekehrt für das Wiederanlernen an VCCU muss der HMLAN zuvor deaktiviert sein)
- IOGrp am Switch löschen (!)
- am HMLAN hmPairSerial <SwitchSerial>
-> Schalter ist mit abweichener HMID gepairt, IODev allda aktualisiert auf HMLAN, lässt sich schalten und konfigurieren.

Ich bleibe also dabei: Auch bei einem erfolgreich gesetzten Schlüssel ist offenbar noch immer ein lokaler Reset möglich und das Gerät anschließend anderswo anlernbar.

Gegenmeinungen sind sehr willkommen!