[gelöst] Probleme mit Homematic+AES

[errazzor]

Möglich ja, aber zumindest in Teilen sehe ich da Gemeinsamkeiten.

Bei den Rolladenaktoren hat es anfangs geholfen, lediglich "aesCommReq" von "1" auf "0" zu setzen. Dann wurden die Probleme weniger, aber sie verschwanden nicht ganz.
Irgendwann häuften sich die Probleme immer mehr, sodass die Rolläden nicht mehr vernünftig zu steuern waren. AES komplett abzuschalten (also auch sign off) brachte dann die Besserung.

Ich würde mich als Testobjekt zur Verfügung stellen, wenn ein Entwickler irgendwelche Infos braucht. Würde AES schon gerne in beide Richtungen weiterhin nutzen, nur ist das aktuell nicht möglich.

[frank]

zumindestens hat tndx mehrere io, daher kam mir diese aussage gerade in den sinn:

Ein Problem von HM ist die Verwendung mehrerer HM-MOD-UARTs beim Start von FHEM.
Hier wird immer das erste HM-MOD-UART Device der VCCU IOList verwendet (HmUART_OG1,HmUART_EG,HmUART_OG2,HmUART_AB_GTO,HmUART_AB_FR). Erst später werden die zugeteilen HM-MOD-UART Device der HM Geräte verwendet.

ändert sich euer verhalten einiger devices eventuell positiv, wenn ihr die reihenfolge der io entsprechend anpasst?

[errazzor]

Also ich habe auch mehrere IOs, aber:

Als die Probleme ganz schlimm waren, hatte ich:

KG: HMLAN
EG: CUL-Stick per ser2net angebunden
OG: HM-MOD-RPI-PCB

Habe extra den CUL ersetzt weil ich dachte, die Probleme kämen daher...somit habe ich jetzt:

KG: HMLAN
EG: WLAN-HMUART
OG: HM-MOD-RPI-PCB

Die Probleme sind aber die gleichen. Weiss nicht, ob daher meine Konstellation für deine Frage nun eine Rolle spielt?

[tndx]

Hallo zusammen,

Ein Problem von HM ist die Verwendung mehrerer HM-MOD-UARTs beim Start von FHEM.
Hier wird immer das erste HM-MOD-UART Device der VCCU IOList verwendet (HmUART_OG1,HmUART_EG,HmUART_OG2,HmUART_AB_GTO,HmUART_AB_FR). Erst später werden die zugeteilen HM-MOD-UART Device der HM Geräte verwendet.

das ist gut zu wissen, ist das irgendwo dokumentiert? Ist das auch "offiziell", oder ist es nur zufällig im Moment so und kann sich mit dem nächsten Update wieder ändern?

Wie auch immer, alleine daran kann es nicht liegen, ich habe hier nämlich mehrere Sensoren, die an dem 1. HM-MOD-UART Device der VCCU IOList hängen (ganz ohne preferred IO, automatisch anhand der RSSI-Werte) und trotzdem kommt die Kommunikation nach einem FHEM-Neustart aus dem Tritt.

Habe extra den CUL ersetzt weil ich dachte, die Probleme kämen daher...somit habe ich jetzt:

Ich hatte vorher auch einen CUL mit der TS-Firmware anstelle eines HM-MOD-UARTs im Einsatz und habe ihn ersetzt in der Hoffnung, den Problemen mit AES so aus dem Weg gehen zu können. Im Nachhinein betrachtet, haben die Probleme aber eher zugenommen, insbesondere das mit dem Neustart ist mir erst mit den beiden HM-MOD-UARTs aufgefallen.

[tndx]

Guten Morgen,

ich habe heute 2 selbstgebaute Fenstersensoren (HM-SEC-RHS-2) nach mehreren Monaten ohne Saft reanimiert, auch hier musste ich anschließend die Signierung aus und wieder einschalten. Das ist im Moment die einzige bekannte Möglichkeit, die AES-Signierung wieder auf Trab zu bringen. Doch genau diesen Schritt möchte ich ja eliminieren, damit ich nicht zu jedem der 20 Sensoren rennen muss. Gibt es denn potentiell Möglichkeiten, den Zustand der AES-Kommunikation zu sichern und wiederherstellen, damit dieser Schritt zumindest bei geplanten FHEM-Neustarts nicht wiederholt werden muss?

[Otto123]

Hi,

da Du mittlerweile an andere Stelle verallgemeinernde Statements abgibst will ich nochmal klar nachfragen: Du hast die Probleme mit AES und Homematic ausschließlich mit selbstgebauten Komponenten? Also die eq3 HM Komponenten laufen?

Gruß Otto

[tndx]

Hi Otto,

was ist daran verallgemeinernd? Ich schrieb ja "Leider habe ich [...]" mit dem Link auf ebendiesen Thread. Wie bereits geschrieben habe ich folgende Komponenten, die ich mit AES-Signierung betreibe:
HM-SEC-RHS (Nachbau)
HM-SEC-RHS (Original)
HM-SEC-TIS
HM-SEC-SCO
HM-RC-KEY4-2

Nur HM-SEC-RHS (Original) kommt mit Neustarts / Wegfall von IO-Devices zurecht, alle anderen verschlucken sich daran.

Ich nutze keine allzu ausgefallene Konfiguration und nur (mehr oder weniger) empfohlene IO-Devices: HM-MOD-UART und CUL mit TS-Firmware (zuletzt auch nicht mehr).

P.S.: Falls das nicht deutlich genug rüberkommt: nur von den HM-SEC-RHS habe ich welche nachgebaut. Der Rest sind die originalen HM-Geräte von eq-3.

[Otto123]

Sorry, ich wollte es wirklich nur verstehen.  Also umgekehrt ist es, Du hast Original HM-SEC-RHS die kommen zurecht, alle anderen egal ob Selbstbau oder Original haben Probleme.

Ich werde mal bei mir mit der Signierung rumspielen. Mal sehen was ich da heraus finde.

Wen ich mal alle meine Rollladen Aktoren mit sign on und aesCommReq 1 ausstatte sollte ich ja Deiner Meinung nach Probleme bekommen?

Gruß Otto

[tndx]

Also umgekehrt ist es, Du hast Original HM-SEC-RHS die kommen zurecht, alle anderen egal ob Selbstbau oder Original haben Probleme.

Genau! Genauer gesagt, ich habe genau einen originalen HM-SEC-RHS, und der zeigt sich unbeeindruckt von den FHEM-Neustarts und IO-Wechsel. Alle anderen zicken rum.

Wen ich mal alle meine Rollladen Aktoren mit sign on und aesCommReq 1 ausstatte sollte ich ja Deiner Meinung nach Probleme bekommen?

Sign on sollte noch nicht mal Voraussetzung dafür sein, aesCommReq=1 sollte reichen.

[Otto123]

Moin,

ok, habe das gemacht

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=subType=blindActuator aesCommReq 1
Betrifft 13 Aktoren - mal sehen was passiert

Gruß Otto

[tndx]

Hi,

ok, habe das gemacht

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=subType=blindActuator aesCommReq 1
Betrifft 13 Aktoren - mal sehen was passiert

Danke für Deine Hilfsbereitschaft! Schau mal in Deine Event-Anzeige, ist da irgendwas von der angeforderten AES-Signatur zu erkennen, wie z.B.:

Code Auswählen Erweitern

2019-07-13_09:45:03 GWC_Fenster_rechts aesCommToDev: pending
2019-07-13_09:45:03 GWC_Fenster_rechts aesCommToDev: ok
2019-07-13_09:45:03 GWC_Fenster_rechts battery: ok
2019-07-13_09:45:03 GWC_Fenster_rechts contact: tilted (to VCCU)
2019-07-13_09:45:03 GWC_Fenster_rechts tilted
2019-07-13_09:45:03 GWC_Fenster_rechts trig_aes_VCCU: ok:2
2019-07-13_09:45:03 GWC_Fenster_rechts trigger_cnt: 2

Denn so viel senden ja die Aktoren nicht und ich bin mir nicht sicher, ob für das Bisschen auch noch die Signatur angefordert wird.

Aber der nächste Schritt wäre, FHEM neu zu starten, was passiert dann?

[frank]

hattest du denn nun zum testen autoreadreg=0 probiert?

[tndx]

Hi,

hattest du denn nun zum testen autoreadreg=0 probiert?

hatte ich bis dahin nicht, da es mir nicht ganz einleuchten wollte, wie das das Problem entschärfen soll... Aber getreu dem Motto Ertrinkender und Strohhalm und so habe ich es gerade ausprobiert, leider keine Besserung 

[Otto123]

erst nachdem ist sign on gesetzt habe 

Code Auswählen Erweitern

2019-07-18_11:44:28 RolloAZL level: set_90
2019-07-18_11:44:28 RolloAZL set_90
2019-07-18_11:44:29 RolloAZL deviceMsg: auf (to VCCU)
2019-07-18_11:44:29 RolloAZL level: 100
2019-07-18_11:44:29 RolloAZL motor: down:auf
2019-07-18_11:44:29 RolloAZL auf
2019-07-18_11:44:34 RolloAZL deviceMsg: 90 (to broadcast)
2019-07-18_11:44:34 RolloAZL level: 90
2019-07-18_11:44:34 RolloAZL motor: stop:90
2019-07-18_11:44:34 RolloAZL pct: 90
2019-07-18_11:44:34 RolloAZL 90
2019-07-18_11:46:16 RolloAZL R-sign: set_on
2019-07-18_11:46:22 RolloAZL R-sign: auf
2019-07-18_11:47:10 RolloAZL level: set_100
2019-07-18_11:47:10 RolloAZL set_100
2019-07-18_11:47:11 RolloAZL aesCommToDev: pending
2019-07-18_11:47:11 RolloAZL aesKeyNbr: 00
2019-07-18_11:47:11 RolloAZL aesCommToDev: ok
2019-07-18_11:47:11 RolloAZL deviceMsg: 90 (to VCCU)
2019-07-18_11:47:11 RolloAZL level: 90
2019-07-18_11:47:11 RolloAZL motor: up:90
2019-07-18_11:47:11 RolloAZL 90
2019-07-18_11:47:18 RolloAZL deviceMsg: auf (to broadcast)
2019-07-18_11:47:18 RolloAZL level: 100
2019-07-18_11:47:18 RolloAZL motor: stop:auf
2019-07-18_11:47:18 RolloAZL pct: 100
2019-07-18_11:47:18 RolloAZL auf

[frank]

das finde ich aber normal und logisch.

das steuern des aktors durch fhem löst den aes request vom aktor an fhem nur aus, wenn im aktor sign=on gesetzt ist.

aescommreq=1 ist aber für die andere signalrichtung.
eventuell also nur für trigger von devices an fhem gedacht, die ja in fhem zu einer reaktion führen könnten. mir fällt gerade keine aktion ein, bei der vom aktor ausgehend auf der empfängerseite etwas gefordert oder ausgelöst werden sollte.

wahrscheinlich wirkt aescommreq nur bei sensoren, wenn diese trigger an fhem senden.