NEWS
[Vorlage] Servicemeldungen Volume2
-
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
habe ca 130 Homematic Geräte, wenn du die meinst
Schau ich mir mal an
Edit:
const GeraeteIDTrigger = true;steht so
Edit 2: bei
const GeraeteIDTrigger = false;kommt die Meldung nicht
-
@looxer01
Die Info ist für mich ziemlich wichtig. Danke. Ich komme erst am WE zum Testen, aber dann mit gut 180 Geräten. Das dürfte dann deutlich heftiger ausfallen als mit nur 80. Da werde ich dann auf jeden Fall besser auf die Historie verzichten.@samson71 sagte in [Vorlage] Servicemeldungen Volume2:
Da werde ich dann auf jeden Fall besser auf die Historie verzichten.
teste doch beides und schau mal ob sich in der performance Unterschiede zeigen.
Ich bin eher der Meinung, dass die Zahl der Subscriptions vermutlich nicht so ausschlaggebend ist.
Sie kosten etwas (minimal) Speicher.
Die Performance wird konsumiert, wenn subscriptions ausgelöst werden und wenn dies oft passiert.BTW: ich habe eine Sicherheit eingebaut , wenn es mehr als 50 IDS sind, die innerhalb kurzer Zeit ausgelöst werden.
Dann pausiert das script für 5 Minuten, bis dann irgendwann der workload abgearbeitet ist.
So möchte ich verhindern, dass es einen overload in Extremsituationen gibt
(z.B. bei Stromausfall und einer USV, die CCU und iobroker alive hält. In dieser Situation gäbe es eine Menge Servicemeldungen)vG Looxer
Edit:
Ich hatte für eine ganze Zeit das alte Servicemeldungssript parallel im Einsatz und damit mehr als doppelt soviel IDs subcribed. (ca 570 subscriptions). Ich habe keinen Unterschied bemerkt, allerdings habe ich einen recht performanten Rechner. -
Hi
Ich habe im ersten post noch ein script eingestellt, das die Batterien eurer Geräte checkt.
Wenn ihr Geräte habt, die noch nicht in der Liste des Servicemeldungsscripts enthalten sind, dann werden diese gelistet
Ihr könnt die mir dann mitteilen, idealerweise gleich Native Bezeichnung (aus dem Script) und der Bezeichnung der
Batterien. Wird dann in das Servicemeldungsscript eingepflegt.vG Looxer
-
Hi,
Das vorliegende Script logged Servicemeldungen von der CCU/AccessPoint/HCU-Für welche Umgebungen eignet sich das Skript?
- CCU (bzw. Raspberry Pi-Ersatz)
- CCU FUNK
- CCU Wired
- HMIP Access Point (Achtung: „GeraeteIDTrigger“ muss auf „true“ gesetzt sein)
- HMIP HCU Cloud (Achtung: „GeraeteIDTrigger“ muss auf „true“ gesetzt sein)
Es handelt sich dabei nicht um ein „entweder-oder“ – die Instanzen werden parallel überwacht.
Was kann das Skript?
- Überprüfung der Servicemeldungen: Das Skript prüft, ob Servicemeldungen vorliegen.
- Speicherung der Servicemeldungen: Servicemeldungen werden in Lang- und Kurztexten (Text, JSON, HTML) gespeichert.
- Zählung von Servicemeldungen: Es werden Zählungen nach Meldungsarten und insgesamt gespeichert.
- Erstellung der erforderlichen Datenpunkte: Das Skript legt automatisch die notwendigen Datenpunkte an.
- Reaktion auf Geräteänderungen: Es reagiert entweder auf Veränderungen auf Geräteebene (viele Subscriptions – z.B. 298 bei 80 Geräten) oder, standardmäßig, auf Veränderungen der Anzahl der in der CCU gemeldeten Servicemeldungen (1 Subscription)
- Historie: Es wird eine Historie geführt, die auch zeigt, wann Servicemeldungen wieder aufgehoben wurden.
- HMIP Access Point/HCU Support: Wenn der Access Point genutzt wird, muss auf die Geräte-ID getriggert werden (da der REGA-Datenpunkt fehlt).
- Externe Log-Datei: Es kann ein externes Log im Excel-Format fortgeschrieben werden. Hierin werden alle Servicemeldungen langfristig fortgeschrieben
- Heizungsgruppenmeldungen: Heizungsgruppenmeldungen sind standardmäßig deaktiviert. Sie können jedoch bei Bedarf aktiviert werden.
- Servicemeldungen Bestätigung: Das Skript bestätigt auf Wunsch CCU Servicemeldungen.
- Flexible Messaging Services: Es können email', 'whatsApp', 'Signal','Telegram', 'Pushover', 'Pushsafer oder auch SPRACHE zum versenden von Servicemeldungen eingestellt werden. Das Versenden kann per MessageType vereinbart werden.
- Flexibles Tabellenwerk: Anpassungen für z.B. neue MessageTypes von Servicemeldungen bei neuen Geräten können ohne Programmierung im Tabellenwerk konfiguriert werden
Einfache Nutzung: Das Skript ist sofort lauffähig, vorausgesetzt, die Instanzen (CCU etc.) sind korrekt eingerichtet.
Das Skript arbeitet in der aktuellen Version stabil und zuverlässig.Zusätzliche Hinweise:
In der Standardkonfiguration des Skripts werden 2 Subscriptions und 1 Schedule erstellt.
Ich verwende das Skript mit einer Subscription auf Ebene Einzel-ID (Einstellung „GeraeteIDTrigger“). Bei dieser Konfiguration wird eine Warnung im Log angezeigt, wenn mehr als 100 Subscriptions von dem Servicemeldungs-Skript erstellt werden.
Diese Grenze kann in den „Instanzen JavaScript“-Einstellungen angepasst werden. Für diesen Anwendungsfall sind keine Performance-Probleme zu erwarten.
Channel Selector: Das Skript verwendet statische Channel-Selector. Das bedeutet, dass Änderungen an den Datenstrukturen durch die CCU (z.B. das Löschen oder Hinzufügen von Geräten) nicht bekannt sind, solange das Skript nicht neu gestartet wird.
Falls Geräte hinzugefügt oder gelöscht werden, muss das Skript neu gestartet werden.und hier das Script:
Servicemeldungen_Vol2_3-32.txtDazu stelle ich zwei Views für VIS zur Verfügung:

Den View gibt es für das JSON Format also auch für das HTML Format. Beide sehen weitestgehend identisch aus-
JSON View: Diese View ist für die Darstellung der JSON-Datenpunkte gedacht. Die Datenpunkte sind auf „javascript.0....“ ausgerichtet, was ggf. angepasst werden muss. Die View kann in VIS über „view importieren“ geladen werden. Der Inventwo-Adapter muss installiert sein. Falls du VIS2 nutzt, empfiehlt sich momentan die HTML-Variante.
View_SM_JSON.txt -
HTML View: Diese View zeigt die HTML-Datenpunkte an. Auch hier müssen die Datenpunkte ggf. angepasst werden. Die View kann ebenfalls in VIS über „view importieren“ geladen werden. Die verwendeten Widgets sind klassische ioBroker-Widgets und funktionieren sowohl in VIS1 als auch in VIS2.
View_SM_HTML.txt
Die Views enthalten einen Push-Button. Wenn der gedrückt wird, wird die Meldungshistorie ohne Nachfrage gelöscht
Da das Skript bei niedrigem Batteriestand automatisch die erforderlichen Batterien überprüft, müssen die Geräte mit den Batterien in eine Liste eingetragen werden. Mit dem folgenden Script kannst du überprüfen, ob die Liste vollständig ist. Alle Geräte mit unbekannten Batterien werden aufgelistet. Du kannst mir diese Liste dann zur Verfügung stellen, und ich pflege sie gerne ein.
hier das Checkscript:
Batterie-Check-1-1.txtZusätzlich stelle ich ein Tool zur Verfügung, das alle ioBroker-Subscriptions auflistet. Dies steht nicht direkt im Zusammenhang mit dem Servicemeldungsskript, ist aber hilfreich, um transparent zu sehen, was insgesamt abonniert wurde. Über eine Variable kann die Liste auch auf ein bestimmtes Skript eingeschränkt werden. Das Ergebnis kann in eine externe Datei geschrieben werden.
Hier das script
ListSubscriptions_1.0@looxer01 Schönes Script!
Es wäre noch gut, wenn man eine Messenger Instanz und einen Empfänger eintragen könnte.
Ich habe es mit Telegram probiert und da bekommen alle eine Meldung.
Oder habe ich etwas übersehen?Grüße
-
@looxer01 Schönes Script!
Es wäre noch gut, wenn man eine Messenger Instanz und einen Empfänger eintragen könnte.
Ich habe es mit Telegram probiert und da bekommen alle eine Meldung.
Oder habe ich etwas übersehen?Grüße
@rantanplan
Hi, bin gerade beruflich unterwegs.
Anschauen kann ich mir das nächste Woche.
Was meinst du mit , dass alle eine Meldung bekommen?Vg looxer
-
@rantanplan
Hi, bin gerade beruflich unterwegs.
Anschauen kann ich mir das nächste Woche.
Was meinst du mit , dass alle eine Meldung bekommen?Vg looxer
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
Was meinst du mit , dass alle eine Meldung bekommen?
Hi, ich habe mehrere Telegram-Benutzer, die unterschiedliche Meldungen aus ioBroker bekommen.
Die Servicemeldungen aus Deinem Script werden an alle Benutzer gesendet, die in der Instanz Telegram.0 eingetragen sind.Grüße
-
@rantanplan
Hi, bin gerade beruflich unterwegs.
Anschauen kann ich mir das nächste Woche.
Was meinst du mit , dass alle eine Meldung bekommen?Vg looxer
-
Hi,
neue Versionen sind online.Servicmeldungsscript Version 1.05:
- Fix fuer Status 0 fuer historische Meldungen. Text aus Tabelle: StandardstatusMessages verwendet // Text angepasst in Tabelle fuer 0
- Batteriemeldung erweitert
- Telegram Instanz und User hinzugefügt
- WICHTIGE Aenderung fuer REGA subscription: Intelligenterer Umgang bei vielen Aenderungen von Anzahl der Servicmeldungen aus der CCU
Batteriescript Version 1.1
- doppelte Listungen verhindert, wenn alle Geräte gelistet werden
- Native IDs für aa und aaa batterien hinzugefügt // Danke an Quarkmax
-
Ich habe eine Sabotage Meldung provoziert. Die Nachricht wird auch versendet (Telegram) aber der Zähler (Anzahl_SABOTAGE) steht bei mir auf 0

Es wäre super, wenn man noch die Anzahl der zu überwachenden Instanzen konfigurieren könnte.
Ich habe 4 rpc Instanzen.
rpc.0 = CUxD
rpc.1 = Homematic
rpc.2 = Homematic IP
rpc.3 = Virtuelle (Gruppen) -
Ich habe eine Sabotage Meldung provoziert. Die Nachricht wird auch versendet (Telegram) aber der Zähler (Anzahl_SABOTAGE) steht bei mir auf 0

Es wäre super, wenn man noch die Anzahl der zu überwachenden Instanzen konfigurieren könnte.
Ich habe 4 rpc Instanzen.
rpc.0 = CUxD
rpc.1 = Homematic
rpc.2 = Homematic IP
rpc.3 = Virtuelle (Gruppen)@knallochse
Hi,
bei Homematic classic werden die Sabotage Meldungen unter MessageType "Error" geführt und da ist auch der Zähler bei dir auf 1. Das ist anders bei HMIP. Da werden die Sabotage Meldungen unter Sabotage geführt.
Ich könnte das zwar code technisch abfangen. Das wäre aber irgendwie schon sehr Spaghetti.zu den instanzen.
CUxD. Das sind ja vermutlich keine HM-Geräte, die darunter laufen. Da also die Datenstrukturen vermutlich anders sind, sind dann auch die Meldungen nicht identisch. Ich habe keine Ahnung wie das funktioniert.Die anderen schaue ich mir an.
Die virtuellen Gruppen habe ich z.Zt draußengelassen. Der Mehrwert bei Meldungen zur Gruppe ist ohnehin fragwürdig. Allerdings sind die nur auskommentiert im Coding und lassen sich einfach aktivieren.vG Looxer
Edit: also eigentlich lassen sich die Instanzen ja jetzt schon konfigurieren.
Im Grunde müssen ja nur die vorgegebenen Instanzen um 1 erhöht werden.
Das befindet sich in den "Experteneinstellungen":const idsUNREACH = []; // @ts-ignore $('state[id=hm-rpc.0.*.UNREACH_ALARM]').each(id => idsUNREACH.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.UNREACH_ALARM]').each(id => idsUNREACH.push(id)); // @ts-ignore // $('state[id=hm-rpc.2.*.UNREACH_ALARM]').each(id => idsUNREACH.push(id)); // auskommentiert keine Gruppenmeldungen const idsSTICKY_UNREACH = []; // @ts-ignore $('state[id=hm-rpc.0.*.STICKY_UNREACH_ALARM]').each(id => idsSTICKY_UNREACH.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.STICKY_UNREACH_ALARM]').each(id => idsSTICKY_UNREACH.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.STICKY_UNREACH_ALARM]').each(id => idsSTICKY_UNREACH.push(id)); // auskommentiert keine Gruppenmeldungen const idsConfig_Pending = []; // @ts-ignore $('state[id=hm-rpc.0.*.CONFIG_PENDING_ALARM]').each(id => idsConfig_Pending.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.CONFIG_PENDING_ALARM]').each(id => idsConfig_Pending.push(id)); // @ts-ignore // $('state[id=hm-rpc.2.*.CONFIG_PENDING_ALARM]').each(id => idsConfig_Pending.push(id)); // auskommentiert keine Gruppenmeldungen const idsUPDATE_PENDING_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.UPDATE_PENDING_ALARM]').each(id => idsUPDATE_PENDING_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.UPDATE_PENDING_ALARM]').each(id => idsUPDATE_PENDING_ALARM.push(id)); // @ts-ignore //$('state[id=hm-rpc.2.*.UPDATE_PENDING_ALARM]').each(id => idsUPDATE_PENDING_ALARM.push(id)); // auskommentiert keine Gruppenmeldungen const idsLOWBAT_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.LOWBAT_ALARM]').each(id => idsLOWBAT_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.LOW_BAT_ALARM]').each(id => idsLOWBAT_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.LOW_BAT_ALARM]').each(id => idsLOWBAT_ALARM.push(id)); // auskommentiert keine Gruppenmeldungen const idsDEVICE_IN_BOOTLOADER_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.DEVICE_IN_BOOTLOADER_ALARM]').each(id => idsDEVICE_IN_BOOTLOADER_ALARM.push(id)); // nur HM-Classic const idsERROR = []; // @ts-ignore $('state[id=hm-rpc.0.*.ERROR]').each(id => idsERROR.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.ERROR]').each(id => idsERROR.push(id)); // @ts-ignore // $('state[id=hm-rpc.2.*.ERROR]').each(id => idsERROR.push(id)); // auskommentiert keine Gruppenmeldungen const idsFAULT_REPORTING = []; // @ts-ignore $('state[id=hm-rpc.0.*.FAULT_REPORTING]').each(id => idsFAULT_REPORTING.push(id)); // nur HM-Classic const idsSABOTAGE_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.SABOTAGE_ALARM]').each(id => idsSABOTAGE_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.SABOTAGE_ALARM]').each(id => idsSABOTAGE_ALARM.push(id)); // @ts-ignore //$('state[id=hm-rpc.2.*.SABOTAGE_ALARM]').each(id => idsSABOTAGE_ALARM.push(id)); // auskommentiert keine Gruppenmeldungen const idsERROR_NON_FLAT_POSITIONING_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.ERROR_NON_FLAT_POSITIONING_ALARM]').each(id => idsERROR_NON_FLAT_POSITIONING_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.ERROR_NON_FLAT_POSITIONING_ALARM]').each(id => idsERROR_NON_FLAT_POSITIONING_ALARM.push(id)); -
@knallochse
Hi,
bei Homematic classic werden die Sabotage Meldungen unter MessageType "Error" geführt und da ist auch der Zähler bei dir auf 1. Das ist anders bei HMIP. Da werden die Sabotage Meldungen unter Sabotage geführt.
Ich könnte das zwar code technisch abfangen. Das wäre aber irgendwie schon sehr Spaghetti.zu den instanzen.
CUxD. Das sind ja vermutlich keine HM-Geräte, die darunter laufen. Da also die Datenstrukturen vermutlich anders sind, sind dann auch die Meldungen nicht identisch. Ich habe keine Ahnung wie das funktioniert.Die anderen schaue ich mir an.
Die virtuellen Gruppen habe ich z.Zt draußengelassen. Der Mehrwert bei Meldungen zur Gruppe ist ohnehin fragwürdig. Allerdings sind die nur auskommentiert im Coding und lassen sich einfach aktivieren.vG Looxer
Edit: also eigentlich lassen sich die Instanzen ja jetzt schon konfigurieren.
Im Grunde müssen ja nur die vorgegebenen Instanzen um 1 erhöht werden.
Das befindet sich in den "Experteneinstellungen":const idsUNREACH = []; // @ts-ignore $('state[id=hm-rpc.0.*.UNREACH_ALARM]').each(id => idsUNREACH.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.UNREACH_ALARM]').each(id => idsUNREACH.push(id)); // @ts-ignore // $('state[id=hm-rpc.2.*.UNREACH_ALARM]').each(id => idsUNREACH.push(id)); // auskommentiert keine Gruppenmeldungen const idsSTICKY_UNREACH = []; // @ts-ignore $('state[id=hm-rpc.0.*.STICKY_UNREACH_ALARM]').each(id => idsSTICKY_UNREACH.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.STICKY_UNREACH_ALARM]').each(id => idsSTICKY_UNREACH.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.STICKY_UNREACH_ALARM]').each(id => idsSTICKY_UNREACH.push(id)); // auskommentiert keine Gruppenmeldungen const idsConfig_Pending = []; // @ts-ignore $('state[id=hm-rpc.0.*.CONFIG_PENDING_ALARM]').each(id => idsConfig_Pending.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.CONFIG_PENDING_ALARM]').each(id => idsConfig_Pending.push(id)); // @ts-ignore // $('state[id=hm-rpc.2.*.CONFIG_PENDING_ALARM]').each(id => idsConfig_Pending.push(id)); // auskommentiert keine Gruppenmeldungen const idsUPDATE_PENDING_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.UPDATE_PENDING_ALARM]').each(id => idsUPDATE_PENDING_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.UPDATE_PENDING_ALARM]').each(id => idsUPDATE_PENDING_ALARM.push(id)); // @ts-ignore //$('state[id=hm-rpc.2.*.UPDATE_PENDING_ALARM]').each(id => idsUPDATE_PENDING_ALARM.push(id)); // auskommentiert keine Gruppenmeldungen const idsLOWBAT_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.LOWBAT_ALARM]').each(id => idsLOWBAT_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.LOW_BAT_ALARM]').each(id => idsLOWBAT_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.LOW_BAT_ALARM]').each(id => idsLOWBAT_ALARM.push(id)); // auskommentiert keine Gruppenmeldungen const idsDEVICE_IN_BOOTLOADER_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.DEVICE_IN_BOOTLOADER_ALARM]').each(id => idsDEVICE_IN_BOOTLOADER_ALARM.push(id)); // nur HM-Classic const idsERROR = []; // @ts-ignore $('state[id=hm-rpc.0.*.ERROR]').each(id => idsERROR.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.ERROR]').each(id => idsERROR.push(id)); // @ts-ignore // $('state[id=hm-rpc.2.*.ERROR]').each(id => idsERROR.push(id)); // auskommentiert keine Gruppenmeldungen const idsFAULT_REPORTING = []; // @ts-ignore $('state[id=hm-rpc.0.*.FAULT_REPORTING]').each(id => idsFAULT_REPORTING.push(id)); // nur HM-Classic const idsSABOTAGE_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.SABOTAGE_ALARM]').each(id => idsSABOTAGE_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.SABOTAGE_ALARM]').each(id => idsSABOTAGE_ALARM.push(id)); // @ts-ignore //$('state[id=hm-rpc.2.*.SABOTAGE_ALARM]').each(id => idsSABOTAGE_ALARM.push(id)); // auskommentiert keine Gruppenmeldungen const idsERROR_NON_FLAT_POSITIONING_ALARM = []; // @ts-ignore $('state[id=hm-rpc.0.*.ERROR_NON_FLAT_POSITIONING_ALARM]').each(id => idsERROR_NON_FLAT_POSITIONING_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.1.*.ERROR_NON_FLAT_POSITIONING_ALARM]').each(id => idsERROR_NON_FLAT_POSITIONING_ALARM.push(id));@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
@knallochse
Hi,
bei Homematic classic werden die Sabotage Meldungen unter MessageType "Error" geführt und da ist auch der Zähler bei dir auf 1. Das ist anders bei HMIP. Da werden die Sabotage Meldungen unter Sabotage geführt.
Ich könnte das zwar code technisch abfangen. Das wäre aber irgendwie schon sehr Spaghetti.Dann hab ich es verstanden. Ich bräuchte keine Änderung.
zu den instanzen.
CUxD. Das sind ja vermutlich keine HM-Geräte, die darunter laufen. Da also die Datenstrukturen vermutlich anders sind, sind dann auch die Meldungen nicht identisch. Ich habe keine Ahnung wie das funktioniert.Eine Überwachung der CUxD Geräte vom Skript ist nicht nötig. Aber die rpc.0 Instanz wird ja überwacht, und die Geräte zur Überwachung befinden sich ja in anderen Instanzen. Wird dann noch alles richtig zugeordnet bzw. überwacht?
Die anderen schaue ich mir an.
Die virtuellen Gruppen habe ich z.Zt draußengelassen. Der Mehrwert bei Meldungen zur Gruppe ist ohnehin fragwürdig. Allerdings sind die nur auskommentiert im Coding und lassen sich einfach aktivieren.In den Gruppen befinden sich ja die einzelnen Geräte und diese werden ja schon überwacht.
vG Looxer
-
Von meiner Seite vielen Dank für dein Skript. Schön, dass du dich der Sache annimmst.
-
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
@knallochse
Hi,
bei Homematic classic werden die Sabotage Meldungen unter MessageType "Error" geführt und da ist auch der Zähler bei dir auf 1. Das ist anders bei HMIP. Da werden die Sabotage Meldungen unter Sabotage geführt.
Ich könnte das zwar code technisch abfangen. Das wäre aber irgendwie schon sehr Spaghetti.Dann hab ich es verstanden. Ich bräuchte keine Änderung.
zu den instanzen.
CUxD. Das sind ja vermutlich keine HM-Geräte, die darunter laufen. Da also die Datenstrukturen vermutlich anders sind, sind dann auch die Meldungen nicht identisch. Ich habe keine Ahnung wie das funktioniert.Eine Überwachung der CUxD Geräte vom Skript ist nicht nötig. Aber die rpc.0 Instanz wird ja überwacht, und die Geräte zur Überwachung befinden sich ja in anderen Instanzen. Wird dann noch alles richtig zugeordnet bzw. überwacht?
Die anderen schaue ich mir an.
Die virtuellen Gruppen habe ich z.Zt draußengelassen. Der Mehrwert bei Meldungen zur Gruppe ist ohnehin fragwürdig. Allerdings sind die nur auskommentiert im Coding und lassen sich einfach aktivieren.In den Gruppen befinden sich ja die einzelnen Geräte und diese werden ja schon überwacht.
vG Looxer
@knallochse sagte in [Vorlage] Servicemeldungen Volume2:
Eine Überwachung vom Skript ist nicht nötig. Aber die rpc.0 Instanz wird ja überwacht, und die Geräte zur Überwachung befinden sich ja in anderen Instanzen. Wird dann noch alles richtig zugeordnet bzw. überwacht?
ich denke ja. Dann muß also CuxD einfach nur auschgeschlossen werden.
@knallochse sagte in [Vorlage] Servicemeldungen Volume2:
In den Gruppen befinden sich ja die einzelnen Geräte und diese werden ja schon überwacht.
genau, also ist die Hinzunahme der Gruppen nicht notwendig.
Ich habe für dich die Configuration im folgenden Code gemacht. Diesen müßtest du durch den Vorhandenen ersetzen.
const idsUNREACH = []; // @ts-ignore $('state[id=hm-rpc.1.*.UNREACH_ALARM]').each(id => idsUNREACH.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.UNREACH_ALARM]').each(id => idsUNREACH.push(id)); // @ts-ignore // $('state[id=hm-rpc.3.*.UNREACH_ALARM]').each(id => idsUNREACH.push(id)); // auskommentiert keine Gruppenmeldungen const idsSTICKY_UNREACH = []; // @ts-ignore $('state[id=hm-rpc.1.*.STICKY_UNREACH_ALARM]').each(id => idsSTICKY_UNREACH.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.STICKY_UNREACH_ALARM]').each(id => idsSTICKY_UNREACH.push(id)); // @ts-ignore //$('state[id=hm-rpc.3.*.STICKY_UNREACH_ALARM]').each(id => idsSTICKY_UNREACH.push(id)); // auskommentiert keine Gruppenmeldungen const idsConfig_Pending = []; // @ts-ignore $('state[id=hm-rpc.1.*.CONFIG_PENDING_ALARM]').each(id => idsConfig_Pending.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.CONFIG_PENDING_ALARM]').each(id => idsConfig_Pending.push(id)); // @ts-ignore // $('state[id=hm-rpc.3.*.CONFIG_PENDING_ALARM]').each(id => idsConfig_Pending.push(id)); // auskommentiert keine Gruppenmeldungen const idsUPDATE_PENDING_ALARM = []; // @ts-ignore $('state[id=hm-rpc.1.*.UPDATE_PENDING_ALARM]').each(id => idsUPDATE_PENDING_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.UPDATE_PENDING_ALARM]').each(id => idsUPDATE_PENDING_ALARM.push(id)); // @ts-ignore //$('state[id=hm-rpc.3.*.UPDATE_PENDING_ALARM]').each(id => idsUPDATE_PENDING_ALARM.push(id)); // auskommentiert keine Gruppenmeldungen const idsLOWBAT_ALARM = []; // @ts-ignore $('state[id=hm-rpc.1.*.LOWBAT_ALARM]').each(id => idsLOWBAT_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.LOW_BAT_ALARM]').each(id => idsLOWBAT_ALARM.push(id)); // @ts-ignore //$('state[id=hm-rpc.3.*.LOW_BAT_ALARM]').each(id => idsLOWBAT_ALARM.push(id)); // auskommentiert keine Gruppenmeldungen const idsDEVICE_IN_BOOTLOADER_ALARM = []; // @ts-ignore $('state[id=hm-rpc.1.*.DEVICE_IN_BOOTLOADER_ALARM]').each(id => idsDEVICE_IN_BOOTLOADER_ALARM.push(id)); // nur HM-Classic const idsERROR = []; // @ts-ignore $('state[id=hm-rpc.1.*.ERROR]').each(id => idsERROR.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.ERROR]').each(id => idsERROR.push(id)); // @ts-ignore // $('state[id=hm-rpc.3.*.ERROR]').each(id => idsERROR.push(id)); // auskommentiert keine Gruppenmeldungen const idsFAULT_REPORTING = []; // @ts-ignore $('state[id=hm-rpc.1.*.FAULT_REPORTING]').each(id => idsFAULT_REPORTING.push(id)); // nur HM-Classic const idsSABOTAGE_ALARM = []; // @ts-ignore $('state[id=hm-rpc.1.*.SABOTAGE_ALARM]').each(id => idsSABOTAGE_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.SABOTAGE_ALARM]').each(id => idsSABOTAGE_ALARM.push(id)); // @ts-ignore //$('state[id=hm-rpc.3.*.SABOTAGE_ALARM]').each(id => idsSABOTAGE_ALARM.push(id)); // auskommentiert keine Gruppenmeldungen const idsERROR_NON_FLAT_POSITIONING_ALARM = []; // @ts-ignore $('state[id=hm-rpc.1.*.ERROR_NON_FLAT_POSITIONING_ALARM]').each(id => idsERROR_NON_FLAT_POSITIONING_ALARM.push(id)); // @ts-ignore $('state[id=hm-rpc.2.*.ERROR_NON_FLAT_POSITIONING_ALARM]').each(id => idsERROR_NON_FLAT_POSITIONING_ALARM.push(id)); -
@looxer01 Vielen Dank.
Ich habe den Code durch deinen ersetzt. Ich beobachte das ganze mal eine Weile.
Schade, dass sich Batteriemeldungen schlecht simulieren lassen. -
@looxer01 Vielen Dank.
Ich habe den Code durch deinen ersetzt. Ich beobachte das ganze mal eine Weile.
Schade, dass sich Batteriemeldungen schlecht simulieren lassen.@knallochse
sehr gerne.
Ich mache die Instanz wahrscheinlich noch variabel. Dann ist es einfacher anzupassen für alle die, die CuxD verwenden -
Hi,
Version 1.06 ist online:- GruppenSelektoren auskommentiert fuer unreach#
- Korrektur fuer REGA subcription:Timer variable zuruecksetzen
- HM-Classic Sabotage counts werden umgeleitet von error auf Sabotage
- Instanzen zur Selektion sind jetzt als Variable definiert - z.B. um CuxD auszuschliessen
Looxer01
-
Hi,
Version 1.06 ist online:- GruppenSelektoren auskommentiert fuer unreach#
- Korrektur fuer REGA subcription:Timer variable zuruecksetzen
- HM-Classic Sabotage counts werden umgeleitet von error auf Sabotage
- Instanzen zur Selektion sind jetzt als Variable definiert - z.B. um CuxD auszuschliessen
Looxer01
@looxer01 mit der 1.6 scheint der Zähler bei Auslösen eines Sabotage Aktors nicht mehr zu funktionieren

in der Nachricht (Telegram) steht SABOTAGE
-
@looxer01 mit der 1.6 scheint der Zähler bei Auslösen eines Sabotage Aktors nicht mehr zu funktionieren

in der Nachricht (Telegram) steht SABOTAGE
@knallochse
vielen Dank
Fehler ist gefunden. Fix kommt mit der nächsten Version.vG Looxer
-
Version 1.07 ist online.
- Zähler für Sabotage funktioniert jetzt für HMClassic und HMIP
- Text StandardMessages angepasst
- Fuer alle Messenger Services kann die gewuenschte Instanz angegeben werden
Looxer