HM Tür/Fensterkontakt: Falsche (nicht existierende) Statusvariable?

Hallo zusammen,

habe heute meine Batterieüberwachung für HM in Betrieb genommen - und dabei ist mir aufgefallen, das IPS nicht existente Statusvariablen anlegt.

Präzise ist mir das jetzt beim HM-TFK (Tür-/Fensterkontakt) aufgefallen. Wird eine solche Instanz über den HM-Konfigurator angelegt (und zwar für Kanal Nr. 1), so hat sie die Statusvariablen ERROR, INSTALL_TEST, STATE und LOWBAT. LOWBAT gibt es aber eigentlich nur im Maintenance-Kanal (#0). Auch in der Script-Dokumentation Teil 4 - Datenpunkte ist für keine der FW-Versionen (bis V1.6, V1.7, ab V1.8) ein LOWBAT-Parameter aufgelistet.

Ist das ein Fehler in IP-Symcon oder hat die HM-Firmware da einen Bug?

Ich meine mich erinnern zu können, das Paresy irgendwann einmal erwähnt hat, das die Statusvariablen direkt aus der CCU abgefragt und entsprechend angelegt werden. Dann wäre es ja ein Bug in der HM-Firmware…

Vielleicht kann das ja mal einer der Wissenden bestätigen oder berichtigen.

Wenn das wirklich so ist muss ich meinem Überwachungsscript nämlich noch ein weiteren Balkon anflanschen um diese „falschen“ Batteriemeldungen zu eleminieren… :mad:

Liegt an der CCU-Firmware.
Siehe auch hier und weiterführende Links.

Hi nancilla

Danke für die schnelle Antwort, sollte doch öfters die Suche verwenden. :o

Ich gelobe Besserung für die Zukunft… :smiley:

Ich hoffe, die Info von mir hat dich nicht zu weit zurück geworfen… berichte mal bitte darüber… Du hast ja schon einige nützliche Skripte im Forum gepostet:)

Servus,

Also die Info war kein Problem, aber das was ich darauf hin jetzt erst gesehen habe schon…
Wird mich noch mal einiges an Hirnschmalz kosten, damit die Überwachung das alleine hinbekommt.

Wenn ich das Problem gelöst habe (was warscheinlich mit einem der nächsten FW-Updates für die CCU wieder verschwindet) kann ich das Script hier gerne posten. Als kleine Vorabinfo sei so viel angemerkt:

Das Script legt automatisch eine Kategorie an, erzeugt für jedes HM-Batteriegerät mit LOWBAT-Meldung eine Dummy-Instanz mit Anzeige akt. Status (Voll, Schwach, Leer), erzeugt die notwendigen Trigger für die Updates und verarbeitet „Resetanforderungen“ aus dem WebFront. Datum des letzten „Batteriewechsels“ (= Zeitpunkt des Resets der Meldung) wird ebenfalls protokolliert. Startet man die Setup-Routine erneut (einfach Script von der Konsole starten) werden die vorhandenen Überwachungen „aktualisiert“, d.h. neue hinzugefügt und nicht mehr existierende gelöscht. Die Namen der Variablen usw. kann man bel. ändern, alle Zugriffe erfolgen über die Ident-Eigenschaft der Objekte.

So, nu muss ich aber gucken wie ich das Problem mit den TFK’s in den Griff bekomme.

Also ich persönlich sehe das nicht so als Problem. Du kannst ja 1x täglich, wenn Dir danach ist, die Fenster/Tür-Melder abfragen, ob das LOWBAT-Flag unter MAINTENANCE gesetzt ist. Ich mache das 1x wöchentlich, und wenn ich für längere Zeit nicht zu Hause bin…

Viel wichtiger scheint mir, dass man automatisiert auf UNREACH-Meldungen reagiert, denn wenn dieser Fall eintritt, passiert einmal gar nichts - und da ist einschreiten angesagt…