[gelöst] Probleme mit Homematic+AES

[tndx]

Hallo zusammen,

ich habe jetzt mehrfach den Fehlerfall geprobt, bei keinem einzigen der Sensoren gab es einen Aussetzer. Ich wage mich noch nicht zu entspannen, werde das System weiterhin beobachten, zumal wir morgen (wieder) eine geplante Stramabschaltung haben.

Danke an Euch für die Unterstützung!

Rückblickend kann es an fehlenden IODev-Attributen gelegen haben, oder bei FHEM wurde in den letzten Tagen/Wochen noch irgendwas unter der Motorhaube geändert...

@Frank:
Dass die Anweisungen auch die Channels erwischen war mir klar, aber FHEM übergeht sie einfach mit einer Warnung und geht zum nächsten Device. Hatte ich ja in den letzten Tagen mit unterschiedlichen Wertekombinationen bis zum Erbrechen geübt

@Otto:
- 2019-07-20 22:00:50   aesKeyNbr       00: das ist bestimmt irgendein kosmetischer Fehler, denn das hat bei der VCCU normalerweise nichts zu suchen, sondern nur bei den Nicht-IO-Devices
- der 3. IO ist im Zustand "dummy" und wird momentan nicht benutzt, aber offenbar merkt es die VCCU über die übereinstimmende HMID. Kann ich bei Gelegenheit ändern / aufräumen.

Noch eine Frage zum Sniffing: ich habe das im Nachhinein auch so interpretiert, dass die 2. FHEM-Instanz die eigentliche Kommunikation gar nicht mitgeschnitten hat. Wie gesagt, es ist ja eine komplett frische Installation mit quasi leerer fhem.cfg. Was muss ich machen, damit die 2. Instanz die Kommunikation der 1. Instans mitschneidet / im Event-Manager ausgibt? Devices anlernen / anlegen lassen?

[Otto123]

Zu aesKeyNbr       00 - ich habe das mal mit geloggt, sieht regelmäßig so aus:

Code Auswählen Erweitern

2019-07-22_09:53:48 VCCU aesReqTo: RolloBDu
2019-07-22_09:53:49 VCCU aesReqTo: RolloBWa
2019-07-22_09:53:50 VCCU aesReqTo: RolloGZR
2019-07-22_09:53:50 VCCU aesReqTo: RolloKUL
2019-07-22_09:53:52 VCCU aesReqTo: RolloBWa
2019-07-22_09:54:04 VCCU aesKeyNbr: 00
2019-07-22_10:11:32 VCCU aesKeyNbr: 00
2019-07-22_10:27:54 VCCU aesKeyNbr: 00
2019-07-22_10:30:50 VCCU aesKeyNbr: 00
2019-07-22_10:32:09 VCCU aesKeyNbr: 00
2019-07-22_10:33:19 VCCU aesKeyNbr: 00
2019-07-22_10:50:02 VCCU aesKeyNbr: 00
2019-07-22_11:00:00 VCCU aesReqTo: RolloBDu
2019-07-22_11:00:01 VCCU aesReqTo: RolloBWa
2019-07-22_11:00:01 VCCU aesReqTo: RolloGZR
2019-07-22_11:00:05 VCCU aesReqTo: RolloBDu
2019-07-22_11:06:35 VCCU aesKeyNbr: 00
2019-07-22_11:18:54 VCCU aesKeyNbr: 00
2019-07-22_11:26:10 VCCU aesKeyNbr: 00
2019-07-22_11:27:23 VCCU aesKeyNbr: 00
2019-07-22_11:27:46 VCCU aesKeyNbr: 00
2019-07-22_11:40:57 VCCU aesKeyNbr: 00
2019-07-22_12:01:13 VCCU aesKeyNbr: 00
2019-07-22_12:13:13 VCCU aesKeyNbr: 00
2019-07-22_12:20:11 VCCU aesKeyNbr: 00
2019-07-22_12:22:04 VCCU aesKeyNbr: 00
2019-07-22_12:24:02 VCCU aesKeyNbr: 00verstehen tue ich es nicht

Der 3 IO bei Dir hat die gleiche HMID deswegen erkennt ihn die VCCU als unassigned (UAS) .  Wenn es stört entweder zuordnen, oder HMID attr löschen. Braucht man im Falle der VCCU Zuordnung eh nicht.

[frank]

Wir hatten nach der immer wieder auftauchenden Verwirrung mit den 6 Punkten mal noch dieses Filter erarbeitet:

Code Auswählen Erweitern

TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6}
Die spart den Actiondetector aus

stimmt den actiondetector habe ich übersehen.

aber folgendes ist dann für mein hirn besser zu verarbeiten und erfordert deutlich weniger fingerakrobatik auf der tastertur: 

Code Auswählen Erweitern

TYPE=CUL_HM:FILTER=DEF=......:FILTER=DEF!=000000


--------------------

Man kann attr aesCommReq am Hauptdevice und an den Kanälen separat setzen - was bewirkt es genau wo?
aesCommReq  ist ja ein attribute, d.h. das Gerät weiß davon gar nichts - es steht ja nicht im Register.
Es kann eigentlich nur so wirken: Die Zentrale fragt das Gerät etwas mit aesCommReq und das Gerät antwortet darauf signiert. Wird damit die Antwort auf einen Befehl (ack) signiert angefordert?

aesCommReq ist quasi das "sign" für die zentrale.

bei homematic entscheidet immer der empfänger einer message (cmd, trigger, status, ...), ob und wie er reagiert. für aesCommReq ist als empfänger also immer die zentrale/vccu/fhem gemeint. aesCommReq=1 bewirkt dann, dass zb trigger von einem speziellen device, die an fhem adressiert sind, zusätzlich einen aes request zum absender des triggers auslösen, bevor der trigger verarbeitet wird.

ähnlich wie in einem aktor, wo ich nur in ausgewählten channels sign=on setzen kann, lässt sich auch aesCommReq auf ausgesuchte entities reduzieren. also, eventuell: global in der vccu, für alle btn einer fb im hauptdevice, nur ein btn einer fb im channel.


beispiel:
du hast ein notify "notaus", das auf deine fb_btn7_short triggert und damit dein ganzes haus "abschaltet".
dein nachbar hat sich nun eine selbstbau fb bei ebay besorgt, die zufällig die selbe id hat, wie deine fb. was meinst du, passiert, wenn er kurz auf btn7 drückt? 
um das zu verhindern, schaltest du aesCommReq für dieine fb_btn7 ein, wodurch dein fhem nach dem erhalt des triggers den aes request zurück an die fb sendet.

wie es bei tndx aussieht, werden die trigger im trigger-reading der fb nur nach erfolgreicher antwort der fb gesetzt:

Code Auswählen Erweitern

     2019-07-18 11:15:23   trig_aes_VCCU   fail:225
     2019-07-18 11:13:10   trigger         Short_224
     2019-07-18 11:13:10   trigger_cnt     224


[tndx]

Guten Abend zusammen,

ich habe am Montag aufgrund einer geplanten Stromabschaltung noch ein mal das Fehlerszenario durchgespielt. Kein einziger Aussetzer. Leider habe ich es versäumt, bei ein paar Sensoren das IODev-Attribut zu löschen, um zu prüfen, ob das nun tatsächlich der Auslöser war. Das werde ich aber bei der nächsten Gelegenheit nachholen.

Vilen Dank an Otto und Frank, ohne Eure Mithilfe würde schon einen Umzug auf eine CCU proben!

[frank]

prima, dann sollte sich nun noch errazzor positiv äussern.

@tndx
ich würde es begrüssen, wenn du deine "negative" äusserung bezüglich aes in dem anderen "empfehlungsthread" löschen und mit einem neuen post dort zusätzlich darauf hinweisen würdest. danke.

wie gesehen, verbreiten sich "fake news" besser als alles andere.

[tndx]

Ich habe meine Aussage editiert und auf die Lösung des Problems hingewiesen.

[tndx]

Hallo zusammen,

Leider habe ich es versäumt, bei ein paar Sensoren das IODev-Attribut zu löschen, um zu prüfen, ob das nun tatsächlich der Auslöser war. Das werde ich aber bei der nächsten Gelegenheit nachholen.

Ich habe heute mit meinem Test-FHEM ein wenig rumgespielt und kann nun behaupten, dass das Löschen des Attributs IODev bei einer vorhandenen VCCU zu der in diesem Thread eingangs beschriebenen Störung führt.

Die Beschreibung im Wiki sollte daher dahingehend geändert werden, dass das Attribut nicht gelöscht werden darf!

Alternativ/zusätzlich könnte geprüft werden, ob diese Abhängigkeit überhaupt beabsichtigt ist.

[Otto123]

Ich habe mal auf die Schnelle einen Hinweis im Wiki eingefügt.

[tndx]

Hallo zusammen,

(erstmal) keine große Sache, deswegen lasse ich "gelöst" im Thread-Namen stehen, aber ich hatte gestern schon wieder einen Ausfall der AES-Kommunikation. Grund war dieses mal nicht Neustarten von FHEM, sondern Editieren in der fhem.cfg.
Ja, ich weiß, macht man nicht, aber ich wollte die lästige Meldung beim Start von FHEM "AskSin Devices not supported" oder so loswerden, indem ich ein HM-IO-Device nach weiter oben in der fhem.cfg verschiebe. Anderen Weg gibt es dafür soweit ich weiß nicht...
Hat auch geklappt, aber anschließend wird ja die geänderte cfg-Datei eingelesen, was aber nicht ganz einem Neustart entspricht. Was in dem Fall schade ist, denn einen Neustart übersteht meine AES-Kommunikation mittlerweile.

Wie gesagt, keine große Sache, aber hätte meine Frau, die gerade wieder angefangen hat, ihre KeyMatic-Fernbedienung zu nutzen, nicht ins Haus gekonnt, wäre es schon wieder für lange Zeit ein Rückfall ins smarthome-lose Zeitalter gewesen!

Deswegen bleibt meine Bitte bestehen, kann sich nicht einer der Entwickler das ganze AES-Thema noch Mal anschauen?

P.S.: Das ganze war mit einem "shutdown restart" behoben. Schon mal sehr angenehm, dass ich nicht zu jedem Sensor hin musste