[gelöst] Probleme mit Homematic+AES

[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:

[...] 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]

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]

...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

[tndx]

Hi,

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

[tndx]

Hi,

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.  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?

[tndx]

Hi,

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...

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.

[tndx]

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

[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.

[tndx]

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

Die Aktoren senden ja auch, das sieht man ja auch in Ottos Auszug:

Code Auswählen Erweitern

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

Macht ja auch Sinn bei Statusänderungen...

Bei meinen Sensoren funktioniert es aber wie gesagt auch, ohne dass sign=on gesetzt ist.

Viel interessanter ist aber nun, was passiert, wenn Du nun FHEM neustertest oder im laufenden Betrieb ein anderes IO-Device zuweist?

[Otto123]

nichts arbeitet nach wie vor.
Ich habe 3 IOs: HMLAN1,HMUART1,ser2netUart.
Der IO war (IOgrp VCCU) Internals -> IODev HMUART1 - klar weil der am nächsten dran ist.
Hab umgestellt IOgrp VCCU:ser2netUart - das bestätigt er auch in Internals -> IODev ser2netUart
Dann mal geschaltet

Code Auswählen Erweitern

2019-07-18_14:12:07 RolloAZL level: set_90
2019-07-18_14:12:07 RolloAZL set_90
2019-07-18_14:12:08 RolloAZL aesCommToDev: pending
2019-07-18_14:12:08 RolloAZL aesCommToDev: ok
2019-07-18_14:12:08 RolloAZL deviceMsg: auf (to VCCU)
2019-07-18_14:12:08 RolloAZL level: 100
2019-07-18_14:12:08 RolloAZL motor: down:auf
2019-07-18_14:12:08 RolloAZL auf
2019-07-18_14:12:13 RolloAZL deviceMsg: 90 (to broadcast)
2019-07-18_14:12:13 RolloAZL level: 90
2019-07-18_14:12:13 RolloAZL motor: stop:90
2019-07-18_14:12:13 RolloAZL pct: 90
2019-07-18_14:12:13 RolloAZL 90
2019-07-18_14:12:25 RolloAZL level: set_100
2019-07-18_14:12:25 RolloAZL set_100
2019-07-18_14:12:25 RolloAZL aesCommToDev: pending
2019-07-18_14:12:25 RolloAZL aesCommToDev: ok
2019-07-18_14:12:25 RolloAZL deviceMsg: 90 (to VCCU)
2019-07-18_14:12:25 RolloAZL level: 90
2019-07-18_14:12:25 RolloAZL motor: up:90
2019-07-18_14:12:25 RolloAZL 90
2019-07-18_14:12:32 RolloAZL deviceMsg: auf (to broadcast)
2019-07-18_14:12:32 RolloAZL level: 100
2019-07-18_14:12:32 RolloAZL motor: stop:auf
2019-07-18_14:12:32 RolloAZL pct: 100
2019-07-18_14:12:32 RolloAZL auf

[tndx]

Hast Du auch mal "shutdown restart" gemacht?

Dann weiß ich echt nicht mehr, woran es noch liegen kann. Natürlich kann es immer noch sein, dass ausgerechnet meine Sensorarten problematisch sind...

Ich habe im Übrigen vorhin noch mal geschaut, "sign" war definitiv "off", um da Abhängigkeiten auszuschließen, habe ich bei einem Sensor auf "on" gesetzt, trotzdem Probleme nach restart.

[frank]

peere mal einen sensor mit der vccu.

[tndx]

peere mal einen sensor mit der vccu.

Wie meinst Du das genau?

[frank]

du peerst einen sensorchannel mit einem channel der vccu. entweder mit peersmart oder peerchan.
ich würde erst einen sensor versuchen, der nur einen channel hat. da ist dann natürlich hauptdevice und channel identisch.

oder was hast du nicht verstanden?

[tndx]

Sorry, hab's nicht so mit Peerings.

Aber zufälligerweise sind die Channel der ebenfalls von dem Problem betroffenen Fernbedienung HM-RC-KEY4-2 mit einem virtuellen Channel der VCCU gepeert. Habe ich damals gemacht, damit die LED der Fernbedienung grün wird. Meinst Du das?

[frank]

genau so.

zeig mal je ein list von dem vccu_chn, fb_chn1 und fb_device.

[tndx]

list vccu_chn:

Code Auswählen Erweitern

Internals:
   DEF        F3A46001
   FUUID      5c489f6a-f33f-7a7c-dea0-a05a0a55be2f9c0a
   NAME       VCCU_Btn1
   NOTIFYDEV  global
   NR         262
   NTFY_ORDER 50-VCCU_Btn1
   STATE      ???
   TYPE       CUL_HM
   chanNo     01
   device     VCCU
   peerList   HM_400FE5_unlock,HM_400FE5_lock,
   READINGS:
     2019-07-18 20:32:22   CommandAccepted yes
     2019-07-18 15:04:43   peerList        HM_400FE5_unlock,HM_400FE5_lock,
     2019-07-18 20:32:22   recentStateType ack
     2019-07-18 11:13:55   trigLast        HM_400FE5_unlock:short
     2019-07-18 11:13:10   trig_HM_400FE5_lock Short_224
     2019-07-18 11:13:55   trig_HM_400FE5_unlock Short_129
     2019-07-18 11:15:23   trig_aes_HM_400FE5_lock fail:225
     2019-07-18 11:15:34   trig_aes_HM_400FE5_unlock fail:131
   helper:
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
Attributes:
   model      CCU-FHEM
   peerIDs    400FE501,400FE502,
   webCmd     press short:press long

list fb_chn1:

Code Auswählen Erweitern

Internals:
   DEF        400FE502
   FUUID      5c489f66-f33f-7a7c-8f87-e0f4522e44ab6589
   NAME       HM_400FE5_lock
   NOTIFYDEV  global
   NR         169
   NTFY_ORDER 50-HM_400FE5_lock
   STATE      Short 3_224 (to VCCU)
   TYPE       CUL_HM
   chanNo     02
   device     HM_400FE5
   peerList   VCCU_Btn1,
   READINGS:
     2018-05-01 11:54:36   R-VCCU_Btn1-expectAES on
     2018-05-01 11:54:36   R-VCCU_Btn1-peerNeedsBurst off
     2018-05-01 11:44:42   R-sign          off
     2018-05-01 11:54:35   RegL_01.        04:10 08:00 09:00 00:00
     2018-05-01 11:54:36   RegL_04.VCCU_Btn1 01:80 00:00
     2019-07-18 15:04:40   peerList        VCCU_Btn1,
     2019-07-18 11:13:10   state           Short 3_224 (to VCCU)
     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
   helper:
     peerFriend peerAct,peerVirt
     peerOpt    4:remote
     regLst     1,4p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
   role:
Attributes:
   aesCommReq 0
   model      HM-RC-KEY4-2
   peerIDs    00000000,F3A46001,

list fb_device:

Code Auswählen Erweitern

Internals:
   DEF        400FE5
   FUUID      5c489f66-f33f-7a7c-b4dd-4669627734d3950d
   IODev     
   NAME       HM_400FE5
   NOTIFYDEV  global
   NR         163
   NTFY_ORDER 50-HM_400FE5
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_400FE5_unlock
   channel_02 HM_400FE5_lock
   channel_03 HM_400FE5_light
   channel_04 HM_400FE5_open
   READINGS:
     2018-05-01 11:56:21   CommandAccepted yes
     2018-05-01 11:56:21   D-firmware      1.2
     2018-05-01 11:56:21   D-serialNr      MEQ1115969
     2018-05-01 11:50:23   PairedTo        0xF3A460
     2018-05-01 11:43:33   R-pairCentral   0xF3A460
     2018-05-01 11:50:23   RegL_00.        02:01 0A:F3 0B:A4 0C:60 18:00 00:00
     2019-07-18 11:15:34   aesCommToDev    fail
     2018-05-01 11:48:52   aesKeyNbr       04
     2019-07-18 11:15:18   aesReqTo        VCCU
     2018-05-01 11:42:55   alive           yes
     2019-07-18 11:13:55   battery         ok
     2018-05-01 11:42:55   powerOn         2018-05-01 11:42:55
     2018-05-01 11:42:55   recentStateType info
     2019-07-18 11:15:18   state           CMDs_done
   helper:
     HM_CMDNR   56
     mId        00A6
     peerFriend
     peerOpt    -:remote
     regLst     0
     rxType     20
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +400FE5,00,00,00
       prefIO     
       rxt        2
       vccu       VCCU
       p:
         400FE5
         00
         00
         00
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     tmpl:
   role:
Attributes:
   IOgrp      VCCU
   aesCommReq 0
   autoReadReg 0
   expert     2_raw
   firmware   1.2
   model      HM-RC-KEY4-2
   room       CUL_HM
   serialNr   MEQ1115969
   subType    remote
   webCmd     getConfig:clear msgEvents

[Otto123]

Shutdown restart gemacht, arbeitet immer noch.

Code Auswählen Erweitern

2019-07-18_21:39:01 RolloAZL aesCommToDev: pending
2019-07-18_21:39:01 RolloAZL aesCommToDev: ok
2019-07-18_21:39:01 RolloAZL deviceMsg: zu (to VCCU)
2019-07-18_21:40:33 RolloAZL level: set_10
2019-07-18_21:40:33 RolloAZL set_10
2019-07-18_21:40:34 RolloAZL aesCommToDev: pending
2019-07-18_21:40:34 RolloAZL aesCommToDev: ok
2019-07-18_21:40:34 RolloAZL level: 0
2019-07-18_21:40:34 RolloAZL motor: up:zu
2019-07-18_21:40:34 RolloAZL zu
2019-07-18_21:40:39 RolloAZL deviceMsg: 10 (to broadcast)
2019-07-18_21:40:39 RolloAZL level: 10
2019-07-18_21:40:39 RolloAZL motor: stop:10
2019-07-18_21:40:39 RolloAZL pct: 10
2019-07-18_21:40:39 RolloAZL 10


[frank]

beim fb_device fehlt das attr IODev. das internal zeigt auch keinen eintrag.

setze es mit dem namen eines io.

attr autoReadReg über das frontend gesetzt, sollte "0_off" anzeigen. 

wenn alles nichts ändert, würde ich das device sniffen und versuchen, unterschiede beim umschalten der io zu erkennen.

zeig auch noch.ein list vom hauptdevice der vccu. keys verschleiern.

[tndx]

beim fb_device fehlt das attr IODev. das internal zeigt auch keinen eintrag.

OK, Recht hast Du, aber sollte sich nicht die VCCU darum kümmern? Ich habe extra konsequent alle IODevs entfernt und nur noch IOGrps stehen lassen.

Ich werde mir das heute Abend noch mal in Ruhe anschauen...

[Otto123]

Ich habe extra konsequent alle IODevs entfernt und nur noch IOGrps stehen lassen.

Es steht doch nirgendwo, dass man dies tun soll? Ich habe mal irgendwann gelernt/gelesen (Beispiel), das IODev erstmal nicht unbedingt was mit CUL_HM zu tun hat sondern "generischer" ist.
Die VCCU kümmert sich um die interne Verwendung und CUL_HM nimmt dann nicht mehr das attr IODev sondern verwendet das Internal IODev - mal etwas populärwissenschaftlich ausgedrückt, weil ich die Internas auch bloß nicht kenne.

Ich weiß nicht welche Seiteneffekte das Löschen von IODev haben kann.

Gruß Otto

[Otto123]

Ich war heute morgen noch etwas erschrocken, weil ich im Log den Eindruck hatte, dass ein Fenstersensor mit eingeschaltetem aesCommReq mehr plappert. Aber das war ein Trugschluss durch event-on-change-reading .*
Es kommt lediglich der gleiche Event zusätzlich wie bei den Rollladenaktoren. Mal zwei im Vergleich, der eine mit aesCommReq 1

Code Auswählen Erweitern

2019-07-19 11:10:42 CUL_HM FensterAZR alive: yes
2019-07-19 11:10:42 CUL_HM FensterAZR battery: ok
2019-07-19 11:10:42 CUL_HM FensterAZR contact: closed (to VCCU)
2019-07-19 11:10:42 CUL_HM FensterAZR sabotageError: off
2019-07-19 11:10:42 CUL_HM FensterAZR closed
2019-07-19 11:33:52 CUL_HM FensterAZL aesCommToDev: pending
2019-07-19 11:33:53 CUL_HM FensterAZL aesCommToDev: ok
2019-07-19 11:33:53 CUL_HM FensterAZL alive: yes
2019-07-19 11:33:53 CUL_HM FensterAZL battery: ok
2019-07-19 11:33:53 CUL_HM FensterAZL contact: closed (to VCCU)
2019-07-19 11:33:53 CUL_HM FensterAZL sabotageError: off
2019-07-19 11:33:53 CUL_HM FensterAZL closed
2019-07-19 12:11:02 CUL_HM FensterAZR alive: yes
2019-07-19 12:11:02 CUL_HM FensterAZR battery: ok
2019-07-19 12:11:02 CUL_HM FensterAZR contact: closed (to VCCU)
2019-07-19 12:11:02 CUL_HM FensterAZR sabotageError: off
2019-07-19 12:11:02 CUL_HM FensterAZR closed
2019-07-19 12:28:26 CUL_HM FensterAZL aesCommToDev: pending
2019-07-19 12:28:27 CUL_HM FensterAZL aesCommToDev: ok
2019-07-19 12:28:27 CUL_HM FensterAZL alive: yes
2019-07-19 12:28:27 CUL_HM FensterAZL battery: ok
2019-07-19 12:28:27 CUL_HM FensterAZL contact: closed (to VCCU)
2019-07-19 12:28:27 CUL_HM FensterAZL sabotageError: off
2019-07-19 12:28:27 CUL_HM FensterAZL closed
Was ich irgendwie noch nicht ganz verstehe, bei dem Rollladenaktor ist das aesCommToDev ja Teil des Steuerbefehls? Aber der Fenstersensor meldet sich doch selbstständig? Der bekommt doch keine Steuerbefehle?
Edit: ok, beim Betätigen gibt es noch einen Unterschied: 

Code Auswählen Erweitern

2019-07-19 13:25:09 CUL_HM FensterAZL trig_aes_VCCU: ok:80


Soll ich mal alle Rollladenaktoren mit sign on versehen? Und dann halbtäglich mal die IOgrp bei allen ändern? - da müsst ich mir einen Zufallsgenerator dafür einfallen lassen. 

[frank]

moin otto,

die fb von tndx zeigt auch noch das reading

Code Auswählen Erweitern

2019-07-18 11:15:18   aesReqTo        VCCU

gibt es das bei dir nicht?
sind das die optischen kontakte (sco)?

die stündlichen logmeldungen (ohne trigger_aes) sind dann also die stündlichen keepalive statusmeldungen?

da müsst ich mir einen Zufallsgenerator dafür einfallen lassen

sunrise/sunset?

[Otto123]

gibt es das bei dir nicht?
sind das die optischen kontakte (sco)?

Gibt es nicht, ja es sind die optischen SCO

die stündlichen logmeldungen (ohne trigger_aes) sind dann also die stündlichen keepalive statusmeldungen?

Ja so wird es sein Macht die der Sensor eigenverantwortlich oder werden die von der Zentrale angeschubst?

Das wäre jetzt eine Sub mit der man per Zufall einen IO aus der liste "auswählt" und preferred setzt.

Code Auswählen Erweitern

sub randomIOgrp($)
# setzt einen zufälligen IO in IOgrp als preferred
{
    my ($devspec)= @_;
    my @vccu=devspec2array(".mId=FFF0");
    my @IOList=split /,/,AttrVal($vccu[0],"IOList","");
    my @list = devspec2array($devspec);
    foreach (@list) {
       fhem ("attr $_ IOgrp $vccu[0]:$IOList[int(1+(rand 3))-1]")
    }
}
sunset/sunrise ist ne gute Idee, da würde ich dann {randomIOgrp('subType=blindActuator')} aufrufen.

Ich finde gerade: ich habe schon ne kleine Macke

Gruß Otto

[frank]

ja, die meldungen des sco sind freiwillig und eventuell auch abschaltbar mit cyclicInfoMsg.

[tndx]

Es steht doch nirgendwo, dass man dies tun soll?

Im Wiki steht folgendes dazu:

Mit der Anlage einer VCCU wird ein eventuell angelegtes Attribut IODev eines HM_Devices funktionslos (das Attribut muss aber nicht entfernt werden). Statt dessen setzt die VCCU ein Internal IODev automatisch je nach Verfügbarkeit und Funklage.

"Muss nicht" heißt aber auch nicht "verboten", habe aber auch schon irgendwo andere Diskussionen drüber gelesen, dass die Benutzer das Attribut ohne Auswirkungen entfernt hätten

Wie auch immer, in meinem Fall war nach einem "getConfig" das Internal auch gesetzt. autoReadReg = 0_off habe ich auch gesetzt, leider das gleiche Problem. List der VCCU liefere ich später nach.

Da es wohl aufs Sniffen des Funkverkehrs hinausläuft, würde ich es gerne auf einem separaten System laufen lassen. Hat jemand eine Anleitung, wie ich nur relevante Daten möglichst detailliert mitsniffe und den Rest am besten gar nicht? Dafür kann man wohl logIDs angeben, aber welche sind damit gemeint, HMIDs? Und welche brauche ich in meinem Fall, nur die entsprechenden Sensoren?

[frank]

attr IODev hast du jetzt aber gesetzt?
alle hauptdevices, auch virtuelle, zb vccu.

zusätzlich, da du vccu nutz, ebenfalls IOgrp in allen devices.

ich kann mich schemenhaft erinnern, dass es auch schon aes probleme gab, weil manche devices kein IOgrp hatten.

sniffe erst mal nur die fb. dazu in beiden io "attr logIDs sys,HM_400FE5" setzen.

[Otto123]

"Muss nicht" heißt aber auch nicht "verboten", habe aber auch schon irgendwo andere Diskussionen drüber gelesen, dass die Benutzer das Attribut ohne Auswirkungen entfernt hätten

Es ist auch nicht verboten an den Weidezaun zu pinkeln - man muss es aber auch nicht tun

Ich habe bei mir vorhin noch ganz mutig, den hier abgesetzt:

Code Auswählen Erweitern

set subType=blindActuator regSet sign on
Und ein DOIF gebaut:

Code Auswählen Erweitern

defmod di_Test1 DOIF ([{sunrise()}] or [{sunset()}]) ({randomIOgrp('subType=blindActuator')})
attr di_Test1 do always
attr di_Test1 room Test

Mal sehen was meine Rollladen am Wochenende so tun. 
Sollte ich noch andere Geräte einbeziehen? Meine SCO sind ja alle Original, die haben ja kein Problem?!

Gruß Otto

[tndx]

Es ist auch nicht verboten an den Weidezaun zu pinkeln - man muss es aber auch nicht tun

OK, Du hast mich überzeugt, ich werde das Attribut wieder überall einfügen  Aber solange das im Wiki so beschrieben steht, werde ich nicht der letzte sein, der zu gründlich aufräumt 

Sollte ich noch andere Geräte einbeziehen? Meine SCO sind ja alle Original, die haben ja kein Problem?!

Mein Original-SCO hat auch das Problem, und ich hatte schon mal deutlich mehr davon im Einsatz, alle mit denselben Symptomen. Nur mein Original HM-SEC-RHS scheint resistent zu sein.

[tndx]

Hi,

attr IODev hast du jetzt aber gesetzt?
alle hauptdevices, auch virtuelle, zb vccu.

zusätzlich, da du vccu nutz, ebenfalls IOgrp in allen devices.

ich kann mich schemenhaft erinnern, dass es auch schon aes probleme gab, weil manche devices kein IOgrp hatten.

sniffe erst mal nur die fb. dazu in beiden io "attr logIDs sys,HM_400FE5" setzen.

Ich werde das mit IODev nachtragen und auch die Fernbedienung sniffen, komme wohl erst ab Sonntag Nachmittag dazu.

[Otto123]

OK, Du hast mich überzeugt, ich werde das Attribut wieder überall einfügen  Aber solange das im Wiki so beschrieben steht, werde ich nicht der letzte sein, der zu gründlich aufräumt 


Mein Original-SCO hat auch das Problem, und ich hatte schon mal deutlich mehr davon im Einsatz, alle mit denselben Symptomen. Nur mein Original HM-SEC-RHS scheint resistent zu sein.

Ok wenn wir hier schlauer sind, ändere ich das Wiki - versprochen. Die jetzige Formulierung, zumindest ein Teil, ist glaub ich sogar von mir.
Dann setzt  ich mal das attribute bei den SCO, da hab ich ja auch ein paar. Bei denen ist es ja sogar so, dass das attribute scheinbar etwas auslöst. Bei den Rollladen spielt das attribute wirklich eine Rolle?

Code Auswählen Erweitern

attr model=HM-SEC-SCO aesCommReq 1

Gute Nacht
Otto

[Otto123]

die fb von tndx zeigt auch noch das reading

Code Auswählen Erweitern

2019-07-18 11:15:18   aesReqTo        VCCU

gibt es das bei dir nicht?

Moin Frank,

an den Aktoren und Sensoren sehe ich diese Readings nicht. Aber die VCCU hat eines.
Kann man auch loggen:

Code Auswählen Erweitern

2019-07-20_10:29:11 VCCU aesReqTo: RolloGZR
2019-07-20_10:30:34 VCCU aesReqTo: RolloGZL
2019-07-20_10:33:48 VCCU aesReqTo: RolloAZR
2019-07-20_10:33:48 VCCU aesReqTo: RolloGZL
2019-07-20_10:33:49 VCCU aesReqTo: RolloGZR

Ansonsten läuft alles unauffällig. Ich habe mir überlegt, man könnte auch noch immer mal am Tag einen der 3 IOs außer Betrieb nehmen:

Code Auswählen Erweitern

sub randomIOclose()
# schließt zufällig einen IO der VCCU
{
    my @vccu=devspec2array(".mId=FFF0");
    my @IOList=split /,/,AttrVal($vccu[0],"IOList","");
foreach (@IOList) {fhem ("set $_:FILTER=state!=opened reopen")}
    fhem ("set $IOList[int(1+(rand 3))-1] close");
}
Das würde den IO aus dem Sendeweg und aus dem Empfangsweg nehmen. Aber alles was ich so probiere, zeigt eine zuverlässige Funktion der VCCU.

Gruß Otto

[frank]

moin otto,

an den Aktoren und Sensoren sehe ich diese Readings nicht. Aber die VCCU hat eines.
Kann man auch loggen:

Code Auswählen Erweitern

2019-07-20_10:29:11 VCCU aesReqTo: RolloGZR
2019-07-20_10:30:34 VCCU aesReqTo: RolloGZL
2019-07-20_10:33:48 VCCU aesReqTo: RolloAZR
2019-07-20_10:33:48 VCCU aesReqTo: RolloGZL
2019-07-20_10:33:49 VCCU aesReqTo: RolloGZR

interessant, und von der logik, so wie ich aes (bisher) verstehe, wesentlich besser an dieser stelle.
denn mit aesCommReq=1 in einem device fordert die zentrale/fhem/vccu den aes request vom device.

Code Auswählen Erweitern

2019-07-18 11:15:18   aesReqTo        VCCU
das reading im hauptdevice der fb von tndx, deutet ja dann auf einen aes request der fb an seine vccu hin. ausgelöst durch irgend eine messge der vccu. korrekterweise müsste dieser reqest aber durch ein gesetztes sign an der fb erfolgen. zumindestens im gezeigten chn ist sign aber off. hm...

warten wir mal auf neue info, zb list vccu.


übrigens:

Ok wenn wir hier schlauer sind, ändere ich das Wiki - versprochen. Die jetzige Formulierung, zumindest ein Teil, ist glaub ich sogar von mir.

an dieser stelle wurde sicherlich schon oft verbessert.
die erwartungshaltung der leser wird immer eine für sie passende interpretation finden.

[Otto123]

Ich habe mal bei meiner FB 12 aesCommReq gesetzt und voila:

2019-07-20_19:06:34 VCCU aesReqTo: FB12

Aber die FB12 hat kein Reading bekommen

Ich habe noch nicht genau verstanden was passiert. Das Reading aesReqTo wurde nur einmalig auf FB12 gesetzt, die Rollos setzen das wiederholt.

[tndx]

Guten Abend,

habe mich gerade wieder meinem Problem gewidmet. Zunächst mal ein list meiner VCCU:

Code Auswählen Erweitern

Internals:
   DEF        F3A460
   FUUID      5c489f65-f33f-7a7c-523a-b93c1b2fca92609c
   IODev      myHmUARTLGW
   LASTInputDev myHmUARTLGW
   MSGCNT     440
   NAME       VCCU
   NOTIFYDEV  global
   NR         78
   NTFY_ORDER 50-VCCU
   STATE      meinLGW:UAS,myHmUARTLGW:ok,myHmUARTUSB:ok
   TYPE       CUL_HM
   assignedIOs meinLGW,myHmUARTLGW,myHmUARTUSB
   channel_01 VCCU_Btn1
   lastMsg    No:3E - t:01 s:F3A460 d:469A98 010E
   myHmUARTLGW_MSGCNT 140
   myHmUARTLGW_RAWMSG 050000413EA001F3A460469A98010E
   myHmUARTLGW_RSSI -65
   myHmUARTLGW_TIME 2019-07-21 22:52:39
   myHmUARTUSB_MSGCNT 300
   myHmUARTUSB_RAWMSG 0500023E738002F3A4603E30D801012A00
   myHmUARTUSB_RSSI -62
   myHmUARTUSB_TIME 2019-07-21 22:50:30
   protLastRcv 2019-07-21 22:52:38
   protRcv    337 last_at:2019-07-21 22:52:38
   protRcvB   4 last_at:2019-07-21 22:48:39
   rssi_at_myHmUARTLGW cnt:140 min:-67 max:-64 avg:-65.84 lst:-65
   rssi_at_myHmUARTUSB cnt:300 min:-64 max:-62 avg:-62.16 lst:-62
   READINGS:
     2019-07-21 22:52:38   CommandAccepted yes
     2019-07-21 22:43:41   IOopen          2
     2019-07-20 22:00:50   aesKeyNbr       00
     2019-07-21 22:47:03   aesReqTo        Keymatic
     2019-07-21 22:43:41   state           meinLGW:UAS,myHmUARTLGW:ok,myHmUARTUSB:ok
   helper:
     HM_CMDNR   62
     mId        FFF0
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       nextSend   1563742359.37566
       prefIO     
       vccu       VCCU
       ioList:
         myHmUARTLGW
         myHmUARTUSB
     mRssi:
       mNo        3E
       io:
         myHmUARTLGW:
           -61
           -61
         myHmUARTUSB:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
       at_myHmUARTLGW:
         avg        -65.85
         cnt        140
         lst        -65
         max        -64
         min        -67
       at_myHmUARTUSB:
         avg        -62.16
         cnt        300
         lst        -62
         max        -62
         min        -64
     tmpl:
Attributes:
   IODev      myHmUARTLGW
   IOList     myHmUARTLGW,myHmUARTUSB
   IOgrp      VCCU
   hmKey      01:XXX
   hmKey2     02:YYY
   model      CCU-FHEM
   room       VCCU
   subType    virtual
   webCmd     virtual:update

Ich habe heute wie versprochen mit der Giesskanne IODev und IOgrp gesetzt:

Code Auswählen Erweitern

attr TYPE=CUL_HM IODev myHmUARTLGW
attr TYPE=CUL_HM IOgrp VCCU

Außerdem habe ich mein FHEM auf die neueste Version aktualisiert, der Stand davor war 1-2 Monate alt.

Anschließend habe ich auf einem Laptop mit einer Minimal-FHEM-Konfiguration den Funkverkehr mitsniffen wollen:

Code Auswählen Erweitern

attr global verbose 1
attr global mseclog 1
attr logIDs sys,HM_400FE5

Anschließend war ich gleich doppelt irritiert, zum Einen von dem Inhalt der Logdatei:

Code Auswählen Erweitern

2019.07.21 22:40:20.091 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:40:20.099 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:40:20.099 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:40:20.099 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0074
2019.07.21 22:40:35.096 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:40:35.104 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:40:35.104 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:40:35.104 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0078
2019.07.21 22:40:50.098 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:40:50.107 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:40:50.107 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:40:50.107 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0078
2019.07.21 22:41:05.107 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:41:05.117 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:41:05.117 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:41:05.117 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0094
2019.07.21 22:41:20.113 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:41:20.131 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:41:20.132 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:41:20.132 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0182
2019.07.21 22:41:35.118 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:41:35.124 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:41:35.124 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:41:35.124 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0054
2019.07.21 22:41:50.123 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:41:50.130 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:41:50.130 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:41:50.131 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0069
2019.07.21 22:42:05.129 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:42:05.144 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:42:05.144 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:42:05.144 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0145
2019.07.21 22:42:20.133 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:42:20.150 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:42:20.150 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:42:20.150 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0161
2019.07.21 22:42:35.138 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:42:35.147 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:42:35.147 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:42:35.147 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0079
2019.07.21 22:42:50.143 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:42:50.158 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:42:50.158 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:42:50.158 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0145
2019.07.21 22:43:05.149 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:43:05.158 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:43:05.158 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:43:05.159 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0091
2019.07.21 22:43:20.153 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:43:20.161 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:43:20.161 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:43:20.161 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0067
2019.07.21 22:43:35.160 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:43:35.171 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:43:35.171 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:43:35.171 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0100
2019.07.21 22:43:50.163 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:43:50.174 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:43:50.175 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:43:50.175 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0107
2019.07.21 22:44:05.171 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:44:05.179 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:44:05.179 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:44:05.179 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0078
2019.07.21 22:44:20.174 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:44:20.184 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:44:20.185 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:44:20.185 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0102
2019.07.21 22:44:35.176 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:44:35.186 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:44:35.186 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:44:35.186 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0091
2019.07.21 22:44:50.179 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:44:50.184 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:44:50.184 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:44:50.185 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0052
2019.07.21 22:45:05.182 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:45:05.190 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:45:05.190 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:45:05.190 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0072
2019.07.21 22:45:20.184 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:45:20.191 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:45:20.191 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:45:20.191 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0062
2019.07.21 22:45:35.187 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:45:35.196 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:45:35.196 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:45:35.196 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0082
2019.07.21 22:45:50.193 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:45:50.205 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:45:50.206 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:45:50.206 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0114
2019.07.21 22:46:05.199 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:46:05.212 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:46:05.212 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:46:05.212 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0123
2019.07.21 22:46:20.204 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:46:20.217 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:46:20.218 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:46:20.218 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0131
2019.07.21 22:46:35.208 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:46:35.215 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:46:35.215 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:46:35.215 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0060
2019.07.21 22:46:50.211 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:46:50.220 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:46:50.220 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:46:50.220 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0080
2019.07.21 22:47:05.216 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:47:05.228 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:47:05.228 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:47:05.228 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0105
2019.07.21 22:47:20.220 0: HMUARTLGW myHmUARTLGW send: 00 08
2019.07.21 22:47:20.235 0: HMUARTLGW myHmUARTLGW recv: 00 040202, state 98
2019.07.21 22:47:20.235 0: HMUARTLGW myHmUARTLGW GetSet Ack: 02, state 98
2019.07.21 22:47:20.235 0: HMUARTLGW myHmUARTLGW roundtrip delay: 0.0145


Irgendwie kann ich dem nichts Sinnvolles entlocken, habe ich irgendeine Sniffing-Einstellung übersehen?

Zum anderen von der Tatsache, dass die AES-signierte Kommunikation einer FB-Taste nach mehrfachen (mind. 2x) FHEM-Neustarts funktioniert hat.

Leider fehlt mir jetzt die Zeit, noch mal das komplette Fehlerszenario durchzuspielen, aber ich habe wieder Hoffnung 

Melde mich morgen wieder, wenn ich mehr Zeit zum spielen gehabt habe.

[Otto123]

Moin,

ich kann, trotz ständigem Wechsel des preferred IO in Kombination mit genauso zufälligem Ausschalten eines IO von dreien, meinem System keinen Fehlerhaften aes Zustand abringen. Ich werde das dann mal wieder auf normal zurückstellen.
Entweder läuft das System so zuverlässig und macht genau das was es soll, oder mein Testszenario ist ungeeignet und besagt nichts. Ich bin nicht ganz sicher über diese beiden Möglichkeiten, habe aber für mich ein gutes Gefühl 
Zu meiner Konfiguration:
IODev nirgendwo gelöscht
IOgrp überall gesetzt, meist ohne preferred IO nur auf VCCU
Kein eigener AES Key im Einsatz, ich halte das für mich persönlich als unrelevant und spar mir die Arbeit für den Tag an dem alles andere getan ist

@tndx

2019-07-20 22:00:50   aesKeyNbr       00
...
     2019-07-21 22:43:41   state           meinLGW:UAS,myHmUARTLGW:ok,myHmUARTUSB:ok

Das mit dem dritten IO ist so gewollt? Der ist da aber der VCCU nicht zugeordnet, sollte aber kein Problem sein.
aesKeyNbr 00 macht mich stutzig: Du hast zwar eigene Keys definiert, aber die sind nicht in Verwendung? oder verstehe ich da was falsch?

Gruß Otto

[frank]

@otto

ich habe verstanden, dass tndx auf einem sehr guten weg ist, da die fb nach dem setzen aller IODev/IOgrp-attribute nun bereits 2 restarts überlebt hat.


@tndx

der sniff zeigt nur die regelmässige (15s) kommunikation von fhem (HMUARTLGW) mit dem io (abfrage der credits).
entweder konnte das io keine messages der fb empfangen, da ausserhalb der reichweite, oder es gab keine messages im zeitraum, oder der name der fb bei attr logids ist falsch.

Code Auswählen Erweitern

attr TYPE=CUL_HM IODev myHmUARTLGW
attr TYPE=CUL_HM IOgrp VCCU

das sollte falsch sein, da hiermit auch alle channel versorgt werden. folgendes sollte passen:

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=...... IODev myHmUARTLGW
attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp VCCU

tip: solche massenhaften zuweisungen probiere ich vorher immer mit list:

Code Auswählen Erweitern

list TYPE=CUL_HM:FILTER=DEF=......

[Otto123]

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

Mit der FB wollte ich nochmal experimentieren, meine Gedanken,Fragen:

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? Denn:
- Die Rollladen Aktoren (oder die VCCU) setzen bei jeder Aktion das Reading aesReqTo in der VCCU.
- die FB hat es bei mir genau einmal gesetzt: nach setzen des attributes und nach dem ersten Tastendruck. Dann nie wieder? (Ich habe ein peering gelöscht)

Ich muss mich mit dem Thema aes mal mehr beschäftigen

Gruß Otto

[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