Hallo Martin,
hatte gestern ein interessantes Phänomen: Nachdem ich morgens ein Fenster mit HM-SEC-RHS am Griff geschlossen hatte, fing dieser an mit etwa 4 Nachrichten pro Sekunde (!) freudig mitzuteilen, dass er geschlossen ist. Irgendwann gegen Abend hat er dann aufgegeben und seine LED beleidigt rot leuchten lassen. Erst eine mehrsekündige Phase ohne Batterien konnte ihn wieder zu normaler Arbeit "überreden". Augenscheinlich kann auch die Firmware eines Fenstersensors mal hängenbleiben.
Sicherlich kein Fehler in FHEM, auch nicht in HMLAN und Co. - aber was ich mich bei der Gelegenheit gefragt habe: Gibt es eine Möglichkeit, derartige Zustände zu erkennen und darauf zu reagieren, z.B. mit einer EMail?
Die restlichen HM-Funktionen waren übrigens nicht im geringsten beeinträchtigt, auch Bulk-Kommandos an 15 Rollos inkl. AES-sign gingen klaglos durch.
Beste Grüße,
Andy.
Hi Andy,
gute Frage. Erst muss man sicher überlegen, was man erkennen will. Einfach nur "viele" messages?
Du hast sicher keinen Log, was passiert ist. Wäre interessant, ob es immer die identische Nachricht war oder od der RHS lauter neue Ereignisse erkannt hat.
Vorstellen kann man sich so etwas wie maxMsgPerTime - und dann ein "babbling" alarm. Könnte man beim ActionDetector oder HMInfo verankern. Es wäre wohl ein Attribut notwendig, das limit zu setzen.
Ist es sinnvoll einen solchen Bug per allgemeiner SW abzufangen?
Gruss Martin
Mein FHEM läuft auf einem sich sonst langweilenden alten Laptop mit reichlich freiem Platz auf der Platte - klar hab ich Einräge im Logfile ;D
Also insgesamt 20MB, der Spaß ging ja fast 11 Stunden lang, ich hab mal Anfang und Ende angehängt, jeweils ~10 min, dazwischendrin ist wohl alles nach dem selben Muster, kann das aber gern auch anhängen, falls Du das nach wiederkehrenden Mustern analysieren möchtest. Gepackt ist das ein gutes MB.
In der Tat eine spannende Frage, worauf man überhaupt reagieren möchte, das hängt sicherliche davon ab, was da gesendet wurde. Wenn es sich immer um die gleiche Nachricht handelt, wäre ein maxMsgPerTime-Attribut sicherlich schon ausreichend. Bin gespannt auf Deine Analyse. Hast Du eine Möglichkeit, die Logs durch einen Interpreter zu jagen, um daraus Klartext zu erzeugen oder ließt Du schlicht und ergreifend den Code? 8)
Beste Grüße,
Andy.
Hallo Andy,
ich lese den code einfach so.
Ein Interpreter steht die quasi zu Verfügung mit dem Attribut hmProtocolEvents. Da wird aber dekodiert, was ich eh schon weiss. In so einem Fall will ich sehen, was HM sendet, dass ich noch nicht kenne.
Was passiert ist, dass dein Kontakt den Event an die Zentrale meldet, wie die anderen Kontakte auch - gut.
der 196980 meldet 3 ereignisse im Abstand von 0.5sec. Das 3. sendet er auch an "7A2CBA" und erhält keine Antwort (2 wiederholungen).
Dann kommen noch 2 Events - beide "sauber" - im Abstand von 0.5sec.
Und dann beginnt der SC alle 350ms events zu senden - keine wiederholungen. Es ist immer das gleiche Ereigniss, aber der msgCounter wird korrekt hochgezählt. Alles addressiert an die Zentrale, aber eine Antwort wird nicht erwartet.
Interessant ist, dass immer "zu" gemeldet wird.
Wichtig könnte sein, dass in der message zum "7A2CBA" ein bit gesetzt ist, und danach bei der messageFlut ein anderes. Beide sind i.a. '0'.
Ich kann beide nicht interpretieren. Hier könnte man aber einhaken - das Device will wohl etwas los werden.
Evtl. sollte man diese Bits in ein Reading schreiben... aber deuten kann ich sie noch nicht.
Gruss Martin