KeyMatic unterbindet verzögerte Programmauslösung

[Narrowmatiker]

Hallo HomeMatic Mitstreiter,

jetzt muss ich leider doch noch einmal einen neuen Thread aufmachen, weil ich definitiv ein Problem mit der KeyMatic habe, welches ich noch nirgends beschrieben finde. Wie ich schon unter viewtopic.php?f=19&t=66750 beschrieben habe, wollte ich nach Installation meiner neuen KeyMatic eine Push-Nachricht über ein kleines Programm verzögert versenden. Dies ging erst nach Neustart der CCU2, aber immer nur für ein paar Stunden, mal länger, mal kürzer, nie kam eine Fehlermeldung. Ein kleines Testprogramm sollte schließlich eine Lampe verzögert einschalten - auch damit war nach ein paar Stunden Schluss. Sofort auslösen: ja, verzögert...erst ja, nach ein paar Stunden oder einem halben Tag: nein. Nach Neustart der CCU2: wieder ja für ein paar Stunden. Sofort auslösen geht immer.
Nachdem ich nun heute zum zweiten Mal die KeyMatic wieder abgelernt habe, ging sofort die verzögert ausgelöste Lampe an, die vermisste Push-Nachricht ging ein. Definitiv ist es also so, dass meine Keymatic nach einiger Zeit dafür sorgt, dass jede verzögerte Programmauslösung unterbunden wird. Dabei sind alle Direktverknüpfungen mit der abgelernten Keymatic noch aktiv und funktionsfähig. Die Probleme fangen erst beim Anlernen der KeyMatic wieder an.

Das Setting ist wie folgt:

3 Handsender (1x HM-RC-Key4-3 als Master-Fernbedienung, 2x HM-RC-Sec4-3) per Direktverknüpfung jeweils wie folgt mit der Keymatic verbunden:
Kanal 1 + 2: verriegeln/entriegeln
Kanal 4: öffnen
Kanal 3: nicht direkt verknüpft, sondern setzt per Programm eine Dimmsteckdose HmIP-PDT auf 70% (kurzer Tastendruck) bzw. auf 0% (langer Tastendruck)

Gleichzeitig haben die drei Handsender auf Kanal 1 und 2 jeweils noch eine weitere Direktverknüpfung mit einer HM-Sec-Sir-WM, nämlich
Kanal 1: Stellt Sirene unscharf
Kanal 2: Stellt Sirene scharf

4 Programme greifen auf die KeyMatic zu:

Das erste Programm zeigt auf einem Display HM-Dis-WM55 den Status von Alarm, Fenstern und eben der Keymatic an. Zugegeben viele "Sonst, wenn..." Verbindungen, hat vorher ohne Keymatic aber auch einwandfrei funktioniert (wobei hier als jeweils dritter Punkt die jetzt schon deinstallierte KeyMatic mit "entriegelt - nur prüfen" bzw. "verriegelt - nur prüfen" fehlt):

Das zweite Programm schließt bzw. öffnet das Schloss zu festgelegten Zeitpunkten:

Das dritte Programm setzt lediglich eine SV namens "Türschloss" auf open bzw. locked:

Das letzte Programm schließlich prüft sämtliche Geräte mit Batterie und setzt eine SV mit dem Namen "Low Battery somewhere" auf wahr, wenn irgendwo eine Batterie nicht o.k. ist. Darin hatte ich auch die KeyMatic aufgeführt.

Damit der Batteriestatus ausgelesen werden kann, habe ich eine SV mit dem Namen "Batterie Keymatic" angelegt, die per Kanalzuordnung mit der Keymatic verbunden ist. Ausgelesen wird über das folgende Programm:

Das darin enthaltene Skript sieht so aus:

Code: Alles auswählen

var bat = dom.GetObject("BidCos-RF.REQ1913790:0.LOWBAT").Value();
dom.GetObject("Batterie Keymatic").State(bat);

Ich würde mich sehr freuen, wenn irgendjemand eine Idee hat, warum die angelernte KeyMatic nach mehreren Stunden die Verzögerung von Programmen abschaltet. Gerne so, dass ein Nicht-Techniker wie ich, aber trotzdem begeisterter Homematicer, es auch verstehen kann. Hilft jemandem vielleicht die gespeicherte Log-Datei, wo der Fehler ungefähr zwischen 19:40 Uhr (da ging es noch) und 20:15 Uhr (da ging es nicht mehr) aufgetreten ist? Oder hat jemand ähnliche Probleme mit der Keymatic gelöst?

[MichaelN]

Ich wüsste nicht, warum man periodisch den Batterie Status abfragen muss. Wenn du das nicht gerade sekündlich machst, sollte es trotzdem nicht schädlich sein. Aber ich würde das Programm mal deaktivieren.

[Sven_A]

Und wie oft funkst du die Keymatic an, weckst sie (und alle anderen Batteriebetriebenen Geräte!) auf, und frägst nach dem Batteriestatus? Was also steht im Zeitmodul drin? Mit .value wird mMn nicht gefunkt, sondern nur der vorhandene Status abgefragt. Trotzdem reicht ein "bei Änderung auslösen".

Wenn der Batteriestatus auf "fast leer" fällt meldet sich meine Keymatic von selber...

Ich hab auch eine Keymatic, damals noch mit der CCU2, heute mit Raspberrymatic, und kann verzögern so viel ich will. Ist also kein generelles Problem.

Gruß,
Sven

[Narrowmatiker]

Also im Zeitmodul steht drin, täglich alle 5 Stunden. Das sollte eigentlich nicht überfordern. Werde das Programm trotzdem wieder als letztes einbauen, wenn ich scheibchenweise die Keymatic wieder anlerne und dann nach und nach die Programme wieder aufbaue. Sollte allerdings schon das bloße Anlernen der KeyMatic an der CCU2 wieder zu den beschriebenen Ausfallerscheinungen führen, weiß ich echt keinen Rat mehr und muss sie wohl außerhalb der HM-Anbindung laufen lassen, womit jegliche Statusabfrage z.B. per Handy hinfällig wäre

[Xel66]

Sollte allerdings schon das bloße Anlernen der KeyMatic an der CCU2 wieder zu den beschriebenen Ausfallerscheinungen führen...

Ich betreibe schon seit Jahren (ca. 2015) eine Keymatic an meinem System und kann eine ähnliche Symptomatik bei mir nicht feststellen. Ich wüsste auch nicht, warum das reine Vorhandensein eines Gerätes im System derartige Auswirkungen haben sollte. Es wird wohl eher daran liegen, dass irgendeines Deiner Programme Amok läuft und sich ständig selbst wieder aufruft, was die Ressourcen der CCU-Firmware an ihre Grenzen bringt (sie hat z.B. eben auch nur eine endliche Anzahl an Verzögerungstimern). Und die ersten Jahre hatte ich ebenfalls noch eine CCU2.

Leere Batterien meldet die CCU selbsttätig per aktusischem Signal, Symbol auf dem eigenen Display und via Webinterface. Da braucht man auch nicht zyklisch drauf triggern. Es reicht vollends aus, auf den Status "Batterie leer" im Kanal 0 zu tirggern und ggf. daraus eine zusätzliche Meldung zu generieren, wenn man es denn unbedingt braucht. Die Meldung wirst Du nur im Zusammenhang mit einer Ansteuerung der Keymatic erhalten, weil dann durch die Belastung beim Lauf die Spannung runtergeht (Erkennung des Ladezustandes der Zellen). Auch wirst Du während des Schließvorganges weit im Vorfeld akustisch mitbekommen, dass der Motor sich schwerer tut. Mit anderen Worten: leere Batterien treten nicht plötzlich auf, sondern sind schon vorher (mehrere Tage!) an einem etwas geänderten Betriebsgeräusch erkennbar.

Zur Batterieüberwachung: dort habe ich erstens alle Geräte die batteriebetrieben sind (Thermostate, Türkontakte, wenige Taster, Temperatursensoren und Keymatic) in einem aussagekräftigen Gewerk "Batterie" zugeordnet. Bei den meisten Geräten gibt es in irgendeinem der Kanäle auch den Trigger "Batterie leer". Daher habe ich ein Programm erstellt, was alle diese Datenpunkte als verODERtem Trigger enthält. Spricht einer dieser Datenpunkte an, iteriert ein Script durch die Geräte dieses Gewerks und stellt einen Meldetext von Geräten mit leerer Batterie zusammen, der nachgehend in Systemvariablen geschrieben wird. Dieser Text wird dann durch Mail und Push-Dienste versandt. Eine zyklische Abfrage per Zeitmodul ist eigentlich überflüssig, weil gerade bei batteriebetriebenen Geräten dieser Datenpunkt nur bei Statusübertragungen (zyklisch oder getriggert) gesetzt wird. Eine zyklische Abfrage würde nur die in der CCU gespeicherten Status (aber nicht die Geräte selbst) abfragen. Man erhält dadurch auch keine schnellere Meldung. Und eins noch. Türkontakte (zumindest für die klassischen optischen kann ich das behaupten) löschen diesen Status auch gern mal wieder nach dem ersten Ansprechen. Darum habe ich es mir nach einer unliebsamen Aktion (TFK hat "offen" gemeldet als die Zelle ihr Leben ausgehaucht hat) zur Aufgabe gemacht, die Zelle sofort nach der ersten Meldung zu tauschen, egal ob die Meldung wieder weg ist oder nicht.

Gruß Xel66

[Sven_A]

...CCU selbsttätig per aktusischem Signal,...

Ein aktusisches Signal? Was ist das? Und wo kommt das raus?
Aber auch akustisch hat meine CCU nie was gemeldet....?

[Narrowmatiker]

Mein Dutycycle liegt eigentlich immer bei 2% bis 5%. Sehe allerdings im Systemprotokoll, dass irrsinnig oft der Zustand der HM-Sec-Sir-WM abgefragt wird

Das wird aber m.E. von keinem Programm andauernd abgefragt - könnte es damit etwas zu tun haben?

[Xel66]

Ein aktusisches Signal? Was ist das? Und wo kommt das raus?

Gleich hinter dem fehlenden Komma kommt das raus. Die Batteriewarnung wird über die CCU, das aktustische Signal (der Keymatic) und dem Display (der Keymatic) signalisiert.

Sehe allerdings im Systemprotokoll, dass irrsinnig oft der Zustand der HM-Sec-Sir-WM abgefragt wird

Da wird nichts abgefragt, sondern Du hast die Sirene auf "protokolliert" und so werden alle Rückmeldungen (zyklisch sowie angesteuert durch Programme der CCU) eben protokolliert. Unabhängig davon kann es durchaus sein, dass auch eines Deiner Programme durch eine andere zyklische Statusmeldung getriggert wird, was wiederum die Innensirene anspricht.

Gruß Xel66

[manfredh]

Unabhängig davon kann es durchaus sein, dass auch eines Deiner Programme durch eine andere zyklische Statusmeldung getriggert wird, was wiederum die Innensirene anspricht.

...und dir das gar nicht bewusst ist, weil sie vom betreffenden Programm immer nur ausgeschaltet wird, obwohl sie bereits aus ist.

[Xel66]

Da würde sie eigentlich ein akustisches Signal absetzen und es müsste sich auch im Duty Cycle niederschlagen. Muss was anderes sein. Sie setzt aber definitiv zyklische Statusmeldungen ab. Aber ich meine in ca. Stundenabstand. Weiß aber nicht, ob sie auch ihren Status per Broadcast sendet, wenn ein TFK seinen Status übermittelt. Ich habe meine Innensirene nicht auf "protokolliert".

Gruß Xel66