[gelöst] Probleme mit Homematic+AES

Begonnen von tndx, 27 Mai 2019, 19:41:35

Vorheriges Thema - Nächstes Thema

tndx

Hallo zusammen,

ich hatte am Wochenende mal wieder was an meinem FHEM umgestellt und dabei zwischenzeitlich eines von meinen beiden IO-Devices (beide HMUARTLGW, 1x USB, 1x LAN) vom Netz genommen. Das Problem war, mal wieder, dass nachdem das IO-Device wieder online war, keine Kommunikation mit Sensoren mit aktiviertem AES möglich war. Den Workaround habe ich bereits beim letzten Mal rausgefunden, als ich noch dachte, das Problem würde durch einen Wechsel von einem TS-CUL auf HMUARTLGW verursacht:

aesCommReq auf 0, den Sensor auslösen lassen, aesCommReq zurück auf 1.

Funktioniert, dauert nur bei den knapp 20 Sensoren immer lange. Natürlich habe ich schon daran gedacht, das ganze zu automatisieren, aber viel lieber würde ich das Problem an der Wurzel bekämpfen, und das habe ich schon vor 2 Jahren gepostet:
Zitat[...] es kann zu Problemen kommen, wenn es bei der AES-signierten Kommunikation zum Wechsel des IO-Devices kommt.

mgernoth hat damals noch einen Patch beigesteuert, der das Ganze zumindest entschärft hat, das Problem aber leider nicht völlig eliminiert hat, wie meine weiteren K(r)ämpfe beweisen.

Gibt es hier niemanden, der auch AES und mehr als 1 IO-Device im Einsatz hat? Könnte sich jemand dieses Problems annehmen, ich stehe gerne als Testobjekt zur Verfügung oder würde auch ein zusätzliches IO-Device zu Testzwecken überlassen. Die Alternative wäre leider mit meinem ganzen HM-Zoo auf eine CCU umzuziehen, denn dort scheint es das Problem nicht zu geben, was ich aber sehr gerne vermeiden würde.

tndx

Guten Morgen,

ich habe gestern mein FHEM von einem Raspberry 2, wo es seit etwa 2,5 Jahren lief, auf einen Raspberry 3, wo es zusammen mit piVCCU laufen soll, umgezogen. Das Betriebssystem wurde dabei von Jessie auf Stretch aktualisiert. Der Umzug an sich verlief völlig problemlos. Bis auf eine Sache, Ihr ahnt es schon: die ganzen AES abgesicherten Sensoren sind wieder aus dem Tritt geraten und der Workaround ist, wie jedes Mal: Signierung ausschalten, auslösen lassen, Signierung einschalten.

Fühlt sich von den Entwicklern hier niemand berufen, dieses Problem anzugehen? Und hat dieses Problem wirklich sonst niemand in dem Maße, wie ich?

errazzor

Ich hab das gleiche Problem und deswegen aescommreq komplett abgeschaltet. Ist einfach zu nervig.

tndx

Zitat von: errazzor am 20 Juni 2019, 09:56:49
Ich hab das gleiche Problem und deswegen aescommreq komplett abgeschaltet. Ist einfach zu nervig.

Danke für die Rückmeldung, schon mal gut zu wissen, dass ich nicht allein mit dem Problem bin. Leute, bitte noch mehr Rückmeldungen, vielleicht können wir so das Interesse der Devs an diesem Problem wecken  ;)

tndx

Guten Abend,

ich bin mittlerweile bei der Erkenntnis angekommen, dass auch ein simpler FHEM-Neustart ausreicht, um die AES-Kommunikation aus dem Tritt zu bringen. Ich bin mir nur nicht sicher, ob es noch an meinem Multi-IO-Setup liegt, oder ob das ein grundsätzliches Manko ist. Wenn letzteres, dann wundert es mich, dass es sonst keinen stört, nutzen wirklich so wenige AES?

Wie auch immer, ich habe noch eine weiter Beobachtung gemacht. Wie bereits geschrieben, habe ich ca. 20 AES gesicherte Sensoren von folgenden Typen:
HM-SEC-RHS (Nachbau)
HM-SEC-RHS (Original)
HM-SEC-TIS
HM-SEC-SCO
HM-RC-KEY4-2

Nur der HM-SEC-RHS (Original), ich habe nur einen davon, übersteht all meine Spielereien, ohne Eigriff. Kann man von dem noch was lernen bzgl. AES?

Wenn ich schon kein Gehör bei den Entwicklern finde, um dieses Problem zu fixen, hat vielleicht jemand eine Idee, wie ich die AES-Kommunikation ohne so viele manuelle Eingriffe auf Trab bringe? Alle aesCommReq gleichzeitig auf 0 bzw. auf 1 zu setzen sollte keine große Herausforderung sein, das habe ich nur noch nicht probiert. Aber am meisten stört mich der Schritt "Sensoren 1x mit aesCommReq = 0 auslösen lassen", da muss ich nämlich quer durchs ganze Haus rennen... Und dann auch noch sicherstellen, dass die DoIfs nicht ohne Not aktiv werden und dann die DoIfs wieder aktivieren.
Zeitraubend und fehleranfällig!
Was bewirkt dieser Schritt rein technisch, kann man ihn nicht durch irgendeine Anweisung simulieren?

Otto123

Zitat von: tndx am 03 Juli 2019, 21:43:50
...Wenn letzteres, dann wundert es mich, dass es sonst keinen stört, nutzen wirklich so wenige AES?

Hi,

Nur als Statement, ich  kann nicht wirklich helfen.  ::)
Alle die Geräte im Einsatz haben, die ein SEC im Namen tragen nutzen AES. Per default mit dem Systeminternen Schlüssel.

Du nutzt AES offenbar mit einem eigenen Schlüssel - und da wird vermutlich das Problem liegen: Die Verwaltung und Zuordnung dieses eigenen Schlüssels. Aber das ist nur Spekulation.

Ich verwende AES (ich habe Geräte mit SEC) aber ich habe keinen eigenen Schlüssel. Und ich habe mehrere IOs in einer VCCU. Und ich habe kein Problem.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

tndx

Hi,

Zitat von: Otto123 am 03 Juli 2019, 22:03:16
Alle die Geräte im Einsatz haben, die ein SEC im Namen tragen nutzen AES. Per default mit dem Systeminternen Schlüssel.

da wage ich Dir vorsichtig zu widersprechen :)

Meines Wissens bzw. meinen Beobachtungen zufolge ist das bei den SEC-Geräten nur für die Kommunikation von der Zentrale zum Gerät der Fall, sprich die Geräte fordern eine Signatur von der Zentrale an. Das ist etwas, was in den Geräten selber verankert ist, weil es über das Register "sign" gemacht wird. Gerade diese Richtung ist aber bei den Fenstersensoren oder Fernbedienungen witzlos, denn die senden ja fast nur, und diese Kommunikation gilt es abzusichern. Das geht in FHEM mittels des Attributs "aesCommReq" und wird auch bei SEC-Geräten nicht automatisch aktiviert (übrigens im Gegensatz zu CCU und Derivaten).

Aber wie gesagt IMHO, vielleicht kannst Du diese Beobachtung bestätigen oder widerlegen.

Ob der Fehler nur an meinem eigenen Schlüssel liegt, kann ich jetzt nicht sagen, denn ich nutze ihn meinem FHEM von Anfang an (sprich, ich habe FHEM noch nie mit dem Default-Schlüssel benutzt), denn der Default-HM-Schlüssel ist ja längst bekannt, so dass die Signaturen gefälscht werden können. MMn sollte man entweder einen eigenen Schlüssel nutzen oder gleich auf AES verzichten und dabei Funkkontigent und Batterien schonen...

Otto123

Moin,

da will ich Dir nicht widersprechen  :)
Ist ja hier alles ganz gut beschrieben -> https://wiki.fhem.de/wiki/AES_Encryption
Ich hatte dein Problem so richtig verstanden und hatte es nicht allein am aesCommReq festgemacht.
Ich habe mehrer Fenstersensoren und nur bei einem ist aesCommReq auf 1 gesetzt - warum weiß ich nicht mehr. Ich habe kein Problem damit, aber es ist ein Originaler, mit dem hast Du ja auch kein Problem.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

tndx

Hi,

Zitat von: Otto123 am 04 Juli 2019, 10:02:00
da will ich Dir nicht widersprechen  :)

das mit dem Widersprechen bezog sich auf Deine Aussage, alle SEC-Geräte würden automatisch mit der aktivierten AES-Signierung laufen.  ;D Tatsächlich ist aber nur eine Richtung automatisch aktiviert und die andere eben nicht. <Spekulation> Vielleicht meinen auch deswegen so viele FHEM-User kein Problem mit AES zu haben, weil ihnen nicht bewusst ist, dass nur die Hälfte der Kommnunikation gesichert ist und das womöglich auch nur mit dem HM-Default-Schlüssel? </Spekulation>

frank

gibt es eventuell einen zusammenhang mit dem "umassignen" des aktuellen io.
hilft vielleicht attr autoreadreg=0?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

tndx

Hi,

Zitat von: frank am 04 Juli 2019, 12:48:43
gibt es eventuell einen zusammenhang mit dem "umassignen" des aktuellen io.

das war meine erste Feststellung, dass ein Wechsel des IO-Devices zu dem Problem führt, nachdem ich zeitweise ein IO vom Netz genommen hatte. Aber mittlerweile bin ich mir ziemlich sicher, dass auch ein simples Neustarten von FHEM zu dem Problem führt, denn das hatte ich bereits mehrfach zuletzt: den Raspberry neugestartet, ohne an FHEM selber irgendwas geändert zu haben und schon waren alle Sensoren rot...


Zitat von: frank am 04 Juli 2019, 12:48:43
hilft vielleicht attr autoreadreg=0?

Laut Wiki verzögert das Attribut das Lesen der Konfigurationsdatei. Wie und an welcher Stelle könnte das helfen? Bei den Sensoren? IO-Devices?

frank

da beim fhemstart auch die io assigned werden, passt das schon.

aber ohne aes erfahrungen sind es nur bauchgefühle.
ich verstehe zb nicht, warum man an den sensoren "fummeln" muss, damit es wieder läuft. hängen die sich auf und senden nicht mehr?

autoreadreg steuert zb das automatische lesen der register der devices. also bei den problemdevices setzen. devices, bei denen man das knöpfchen zum kommunizieren drücken muss, macht es sowieso sinn.

prefered io setzen sollte auch gut sein.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

tndx

Zitat von: frank am 04 Juli 2019, 17:39:31
ich verstehe zb nicht, warum man an den sensoren "fummeln" muss, damit es wieder läuft. hängen die sich auf und senden nicht mehr?

Weil ansonsten die AES-Signatur nicht mehr akzeptiert wird, was, wenn man die gültige Signatur erwartet, gleichbedeutend mit "senden nicht mehr" ist.

errazzor

Ich musste AES mittlerweile auch bei meinen Rolladenaktoren komplett abschalten. Alle paar Tage kam die Kommunikation aus dem Tritt, auffällig oft, wenn entweder FHEM neu gestartet wurde oder wenn wie hier schon geschrieben wurde das IO-Device gewechselt wurde.

Grade bei den Rolladenaktoren hinterlässt das abschalten von AES bei mir kein gutes Gefühl, denn theoretisch könnte ja jetzt jeder der sich ein bisschen auskennt meine Rolläden steuern.

Die Probleme bei den Rolläden äußerten sich in "aesCommToDev fail" und auch "MISSING ACK". Nach abschalten von AES sind die Probleme weg.

Bei den Fenstersensoren äußern sich die Probleme darin, dass sie dann halt rot leuchten und die Meldungen auch (teilweise) nicht mehr ankommen. Nur hier kann ich AES ja nicht abschalten.

Ich nutze auch von Anfang an einen eigenen Schlüssel, die Probleme mit AES bestehen aber erst seit ca. 1 Jahr oder so. Anfangs hat das alles noch problemlos funktioniert.

Mehr kann ich dazu leider nicht sagen.

Otto123

Hallo errazzor,

das Problem was Du schilderst ist aber die andere Richtung als beim TE!?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz