Penetrante Alarm-Meldung bei 19-Tasten-Fernbedienung HM-RC-19-SW

[Ben Cooper]

Hallo,

ich bin bisher davon ausgegangen, dass die auf einer 19-Tasten-Fernbedienung HM-RC-19-SW angezeigte Anzahl der SE- und AL-Meldungen immer mit der Anzahl der Service- und Alarmmeldungen in der WebUI einer CCU3 bzw. RaspberryMatic übereinstimmt, aber das scheint wohl nicht so zu sein!?

Im Display der Fernbedienung wird seit einiger Zeit dauerhaft das Briefumschlag-Symbol angezeigt. Wenn ich mit der mittleren der drei Sondertasten durch die Meldungsliste klicke, so erscheint zuerst "SE 0" und dann "AL 1". In der WebUI meiner RaspberryMatic (Version 3.61.7.20220115) sind dagegen weder Service- noch Alarmmeldungen vorhanden - beide sind grün und stehen dort auf (0).

Abgesehen davon arbeitet die Fernbedienung einwandfrei. Ich kann andere Geräte damit (per Direktverbindung) ansteuern und die Fernbedienung auch von der Zentrale aus konfigurieren (z.B. Tastendrücke simulieren, Display-Symbole ein- und ausschalten sowie Textnachrichten an das Display senden. Die ominöse Alarmmeldung bekomme ich aber nicht weg.

Kann es sein, dass die Fernbedienung einen eigenen Alarmmeldungs-Zähler hat und von der Zentrale nicht die absolute Anzahl der jeweils vorhandenen Alarme, sondern stattdessen Inkrement- bzw. Dekrement-Werte (es gibt jetzt einen Alarm mehr bzw. weniger) erhält? Vielleicht hat sie dann irgendwann mal eine Alarm-Dekrement-Meldung nicht mitbekommen?

[Roland M.]

Hallo!

Kann es sein, dass die Fernbedienung einen eigenen Alarmmeldungs-Zähler hat und von der Zentrale nicht die absolute Anzahl der jeweils vorhandenen Alarme, sondern stattdessen Inkrement- bzw. Dekrement-Werte (es gibt jetzt einen Alarm mehr bzw. weniger) erhält? Vielleicht hat sie dann irgendwann mal eine Alarm-Dekrement-Meldung nicht mitbekommen?

Nein, daran glaube ich nicht.
Allerdings gibt es zwei systeminterne Programme "Servicemeldungen anzeigen" und "Alarmmeldungen anzeigen". Da mich diese Anzeigen genervt haben (hat meiner Meinung nach nichts auf einer FB zu tun!), habe ich diese beiden Programme deaktiviert. Aktuell habe ich eine bestehende Servicemeldung, die FB zeigt aber "SE 0 / AL 0" an.
An deiner Stelle würde ich kontrollieren, ob es diese beiden Programme gibt und sie auch aktiv sind.


Roland

[Ben Cooper]

Allerdings gibt es zwei systeminterne Programme "Servicemeldungen anzeigen" und "Alarmmeldungen anzeigen".

Danke für den Hinweis, die hatte ich gar nicht mehr auf dem Schirm. Allerdings existieren die beiden Programme und sie sind auch beide aktiviert.

Zum Test habe ich mal ein weiteres Programm erstellt, welches auf Tastendruck der untersten Fernbedienungs-Sondertaste (Kanal 17) die gleiche Aktivität wie das systeminterne Alarmmeldungs-Programm ausführt - und siehe da, nun kann ich die störrische Alarmmeldung auf Tastendruck löschen

Damit ist meine Inkrement/Dekrement-Hypothese vom Tisch!

Die Bedingung des systeminternen Alarmmeldungs-Programm sieht ja so aus:
Wenn | Systemzustand | Alarmmeldungen | im Wertebereich / mit Wert | größer oder gleich 0 | bei Aktualisierung auslösen
Falls dieses Programm immer nur dann auslöst, wenn sich die Anzahl der Alarmmeldungen in der CCU ändert, dann vermute ich, dass es irgendwann beim Rücksetzen eines Alarms (Anzahl Alarmmeldungen von 1 ==> 0) korrekt ausgelöst wurde, aber ein Kommunikationsproblem mit der Fernbedienung gegeben hat. Beim nächsten Alarm wären CCU und Fernbedienung dann wohl wieder synchron gewesen!?

Das wichtigste ist allerdings, dass ich nun den Mechanismus der Service- und Alarmmeldungen verstanden habe (zumindest glaube ich das) und bedanke mich nochmals für den Hinweis auf die Systemprogramme.

[Baxxy]

Ich kann mich vage dran erinnern das es mal ein Problem gab mit der Anzahl Alarmmeldungen.

Da hatte die SysVar "Alarmmeldungen" einen Wert >0 und in der WebUI wurde trotzdem keine Alarmmeldung signalisiert.
Ich kenne aber weder die FB noch die zugehörigen Programme / Scripte, würde aber vermuten das hier auch die SysVar ausgelesen wird.

Den Wert der SysVar "Alarmmeldungen" kann man z.B. im Script testen ermitteln.

Code: Alles auswählen

WriteLine(dom.GetObject (ID_SYSTEM_VARIABLES).Get (40).Value());

[Roland M.]

Hallo!

Ich kenne aber weder die FB noch die zugehörigen Programme / Scripte, würde aber vermuten das hier auch die SysVar ausgelesen wird.

Richtig, zwei analoge Programme, greifen auf die SV "Servicemeldungen" bzw. "Alarmmeldungen" zu, hier die Version für die Servicemeldungen:

Roland

[Baxxy]

zwei analoge Programme,

Ah ja, Danke.
Recht simpel, da kann ja eigentlich nichts kaputt sein.

Dann wird es vermutlich doch der falsche "Alarmmeldungen" Wert sein. Lässt sich leicht reproduzieren.
Eine Alarm-SysVar auslösen, den Alarm anstehen lassen und rebooten.
Sieht dann nach dem Reboot so aus und die FB würde eben eine anstehende Alarmmeldung signalisieren.
(Achtung: Test mit RaspberryMatic, ich weiß nicht ob das bei CCUx auch so ist)

Trudelt irgendwann die erste echte Alarmmeldung ein, bleibt der Zähler bei 1 und wird beim quittieren auf "0" gesetzt.

[Ben Cooper]

Dann wird es vermutlich doch der falsche "Alarmmeldungen" Wert sein.

Genau danach sieht es tatsächlich aus! Ich habe direkt mal
WriteLine(dom.GetObject (ID_SYSTEM_VARIABLES).Get (40).Value());
ohne vorherigen Neustart der RaspberryMatic ausgeführt und den Ausgabewert 1 erhalten, obwohl in der WebUI nach wie vor alles grün ist.

Als nächstes habe ich dieses Programm erstellt und getestet:

Nun ja - hüstel - genau gesagt hatte ich das Programm vorher schon erstellt und behauptet, dass es "die gleiche Aktivität wie das systeminterne Alarmmeldungs-Programm ausführt", aber wie ich gerade feststellen musste, war das nicht ganz korrekt

Mein ursprüngliches Programm hatte anstelle von "[Systemzustand] mit Alarmmeldungen" stattdessen "[Wert] auf 0", wodurch ich mittels Tastendruck der untersten Fernbedienungs-Sondertaste (Kanal 17) die störrische Alarmmeldung löschen konnte.

Nach der Anpassung (so dass mein Programm jetzt tatsächlich dem o.a. Screenshot entspricht) meldet die Fernbedienung auf Tastendruck wieder "AL 1" begleitet von fünfmaligem energischem Piepsen

Dank Eurer Erklärungen passt für mich jetzt alles zusammen und ich denke, dass ich bei nächster Gelegenheit einmal tiefer in den Themenbereich der System-Zustände, -Variablen und -Programme eintauchen werde.

[Ben Cooper]

Nachtrag: Mit

Code: Alles auswählen

dom.GetObject("Alarmzone 1").State(true);
dom.GetObject("Alarmzone 1").DPInfo("Test-Alarm");

habe ich einen Test-Alarm ausgelöst, der auch in der Zentrale angezeigt wurde. Die Fernbedienung gab dabei keinen Mucks von sich (vermutlich weil sie ja bereits einen gespeicherten Alarm hatte). Dann habe ich den Test-Alarm im WebUI bestätigt, woraufhin er auch in der Fernbedienung gelöscht wurde.

Der nochmalige Aufruf von
WriteLine(dom.GetObject (ID_SYSTEM_VARIABLES).Get (40).Value());
lieferte danach den Ausgabewert 0 und das System war konsistent

===================================================================================

Nächster Test: Wie von Baxxy vorgeschlagen, habe ich einen Test-Alarm erzeugt (der danach auch in der Zentrale angezeigt wurde) und die Zentrale bei anstehendem Alarm neu gestartet. Nach dem Neustart wurde in der Zentrale kein Alarm angezeigt, wohl aber auf der Fernbedienung. Die Systemvariable lieferte den Wert 1 (also alles wie gehabt).

===================================================================================

Letzter Test: Einen Test-Alarm erzeugt, diesen in der Zentrale bestätigt und die Zentrale danach neu gestartet. Nach dem Neustart ist alles OK und konsistent: Keine Alarme in Zentrale und Fernbedienung, Systemvariable hat den Wert 0.

FAZIT: Vor einem Zentralen-Neustart sollte man immer alle anstehenden Alarme bestätigen. Sollte das aus irgendeinem Grund nicht möglich sein (oder man es vergessen haben), kann man nach dem Zentralen-Neustart einen Test-Alarm erzeugen und diesen direkt wieder quittieren. Danach sollte alles konsistent sein. Interessant wäre, ob das nur bei RaspberryMatic oder auch bei einer Original-CCU3 auftritt