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 (https://forum.fhem.de/index.php/topic,62680.msg554337.html#msg554337):
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 (https://forum.fhem.de/index.php/topic,65184.msg566275.html#msg566275) beigesteuert, der das Ganze zumindest entschärft hat, das Problem aber leider nicht völlig eliminiert hat, wie meine weiteren K(r)ämpfe (https://forum.fhem.de/index.php/topic,98128.msg914557.html#msg914557) 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.
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?
Ich hab das gleiche Problem und deswegen aescommreq komplett abgeschaltet. Ist einfach zu nervig.
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 ;)
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?
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
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...
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
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>
gibt es eventuell einen zusammenhang mit dem "umassignen" des aktuellen io.
hilft vielleicht attr autoreadreg=0?
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?
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.
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.
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.
Hallo errazzor,
das Problem was Du schilderst ist aber die andere Richtung als beim TE!?
Gruß Otto
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.
zumindestens hat tndx mehrere io, daher kam mir diese aussage gerade in den sinn:
Zitat von: Burny4600 am 08 Juli 2019, 16:44:15
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?
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?
Hallo zusammen,
Zitat von: Burny4600 am 08 Juli 2019, 16:44:15
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.
Zitat von: errazzor am 10 Juli 2019, 14:32:21
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.
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?
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
Hi Otto,
was ist daran verallgemeinernd? Ich schrieb ja "Leider habe ich [...]" mit dem Link auf ebendiesen Thread. Wie bereits geschrieben (https://forum.fhem.de/index.php/topic,100911.msg955127.html#msg955127) 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.
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
Zitat von: Otto123 am 17 Juli 2019, 23:36:55
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.
Zitat von: Otto123 am 17 Juli 2019, 23:36:55
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.
Moin,
ok, habe das gemachtattr TYPE=CUL_HM:FILTER=subType=blindActuator aesCommReq 1
Betrifft 13 Aktoren - mal sehen was passiert :)
Gruß Otto
Hi,
Zitat von: Otto123 am 18 Juli 2019, 10:04:04
ok, habe das gemachtattr 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.:
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: 2Denn 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?
hattest du denn nun zum testen autoreadreg=0 probiert?
Hi,
Zitat von: frank am 18 Juli 2019, 10:35:30
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 :(
erst nachdem ist sign on gesetzt habe :-\
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
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.
Zitat von: frank am 18 Juli 2019, 12:34:49
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:
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: okMacht 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?
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
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
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.
peere mal einen sensor mit der vccu.
Zitat von: frank am 18 Juli 2019, 18:43:08
peere mal einen sensor mit der vccu.
Wie meinst Du das genau?
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?
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?
genau so.
zeig mal je ein list von dem vccu_chn, fb_chn1 und fb_device.
list vccu_chn:
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:
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:
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
Shutdown restart gemacht, arbeitet immer noch.
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
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.
Zitat von: frank am 19 Juli 2019, 09:55:40
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...
Zitat von: tndx am 19 Juli 2019, 11:19:31
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 (https://forum.fhem.de/index.php/topic,62653.msg542661.html#msg542661)), 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. ;D
Ich weiß nicht welche Seiteneffekte das Löschen von IODev haben kann.
Gruß Otto
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
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: ;)
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. :D
moin otto,
die fb von tndx zeigt auch noch das reading
2019-07-18 11:15:18 aesReqTo VCCUgibt 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?
Zitatda müsst ich mir einen Zufallsgenerator dafür einfallen lassen
sunrise/sunset?
Zitat von: frank am 19 Juli 2019, 14:08:09
gibt es das bei dir nicht?
sind das die optischen kontakte (sco)?
Gibt es nicht, ja es sind die optischen SCO
Zitatdie 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.
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
ja, die meldungen des sco sind freiwillig und eventuell auch abschaltbar mit cyclicInfoMsg.
Zitat von: Otto123 am 19 Juli 2019, 11:34:41
Es steht doch nirgendwo, dass man dies tun soll?
Im Wiki steht folgendes dazu:
ZitatMit 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?
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.
Zitat von: tndx am 19 Juli 2019, 20:28:21
"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 :) ;D
Ich habe bei mir vorhin noch ganz mutig, den hier abgesetzt:
set subType=blindActuator regSet sign on
Und ein DOIF gebaut:
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
Zitat von: Otto123 am 19 Juli 2019, 21:14:27
Es ist auch nicht verboten an den Weidezaun zu pinkeln - man muss es aber auch nicht tun :) ;D
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 ;D
Zitat von: Otto123 am 19 Juli 2019, 21:14:27
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.
Hi,
Zitat von: frank am 19 Juli 2019, 20:43:40
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.
Zitat von: tndx am 19 Juli 2019, 22:39:31
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 ;D
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?
attr model=HM-SEC-SCO aesCommReq 1Gute Nacht
Otto
Zitat von: frank am 19 Juli 2019, 14:08:09
die fb von tndx zeigt auch noch das reading
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:
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: RolloGZRAnsonsten 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:
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
moin otto,
Zitat von: Otto123 am 20 Juli 2019, 10:57:24
an den Aktoren und Sensoren sehe ich diese Readings nicht. Aber die VCCU hat eines.
Kann man auch loggen:
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.
2019-07-18 11:15:18 aesReqTo VCCUdas 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:
ZitatOk 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.
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.
Guten Abend,
habe mich gerade wieder meinem Problem gewidmet. Zunächst mal ein list meiner VCCU:
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:
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:
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:
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.
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 ;D
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
Zitat2019-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
@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.
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:
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:
list TYPE=CUL_HM:FILTER=DEF=......
Wir hatten nach der immer wieder auftauchenden Verwirrung mit den 6 Punkten mal noch dieses Filter erarbeitet:
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
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?
Zu aesKeyNbr 00 - ich habe das mal mit geloggt, sieht regelmäßig so aus:
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.
Zitat von: Otto123 am 22 Juli 2019, 12:27:58
Wir hatten nach der immer wieder auftauchenden Verwirrung mit den 6 Punkten mal noch dieses Filter erarbeitet:
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: :)
TYPE=CUL_HM:FILTER=DEF=......:FILTER=DEF!=000000--------------------
ZitatMan 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? 8)
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:
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
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!
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.
Ich habe meine Aussage editiert und auf die Lösung des Problems hingewiesen.
Hallo zusammen,
Zitat von: tndx am 24 Juli 2019, 19:34:21
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.
Ich habe mal auf die Schnelle einen Hinweis im Wiki eingefügt.
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 :)