[Vorlage] Servicemeldungen Volume2
-
@sigi234
der Schedule befindet sich in den Experteneinstellungen//Schedule Zeit fuer refresh der Historie const scheduleTimeClearSMTexte = "2 0 1 * *"; // Sam 1. tag des monats um 00:02 morgens sollen alle Servicemeldungen des Monats geloescht werden // const scheduleTimeClearSMTexte = "58 23 * * 0"; // alternative Sonntags um 23:58 Uhr sollen alle Servicemeldungen der Woche im datenpunkt der SM-Texte geloescht werdenich hatte monatlich und wöchentlich vorgegeben. Das lässt sich aber beliebig anpassen. (z.B. 60 * * * * bedeutet jede 60.Minute. Da es die in cron nicht gibt, wird auch der schedule nie ausgefuehrt)
Einen Refresh Button könntest du dir in die VIS legen und bei Druck den Datenpunkt leeren.
Eine Möglichkeit ohne script wäre ein HTML State Widget. Wenn du da den Datenpunkt angibst und dann in VIS auf die fläche drückst wird der Datenpunkt geleert. Das sollte aber immer nur dann gemacht werden, wenn es keine aktuellen Servicemeldungen gibt.Anmerkung. Es reicht, wenn der JSON Datenpunkt geloescht wird. Also nicht den HTML Datenpunkt löschen, da der immer wieder aufgrund des JSON Datenpunktes neu generiert wird
-
@sigi234
ich werde die Funktion mit einem separaten Datenpunkt und entsprechender Logik hinzufügen.
Es ist eben doch ein wenig mehr als nur den Datenpunkt zu löschen.
Kommt heute oder morgen.vG Looxer
sieht dann ggf so aus:
-
Version 3.07 ist online.
Das ging recht schnell:- Datenpunkt als Button für VIS erstellt (boolean) bei true wird eine Subscription ausgeloest
- Die Subscription loescht die Historie, belaesst aber die noch aktiven Servicemeldungen in der Historie
- Der schedule zur regelmäßige Löschung kann beibehalten werden oder deaktiviert werden
Alles getestet.
vG Looxer
-
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
Der schedule zur regelmäßige Löschung kann beibehalten werden oder deaktiviert werden
Wie deaktvieren?
-
@sigi234
es gibt eine Kommentarzeile dazuconst scheduleTimeClearSMTexte = "2 0 1 * *"; // am 1. tag des monats um 00:02 morgens sollen alle Servicemeldungen des Monats geloescht werden // const scheduleTimeClearSMTexte = "58 23 * * 0"; // alternative Sonntags um 23:58 Uhr sollen alle Servicemeldungen der Woche im datenpunkt der SM-Texte geloescht werden // const scheduleTimeClearSMTexte = "60 * * * *"; // altenative ist den schedule zur Loeschung der Histore nie auszuloesen und ggf über den Datenpunkt id_Button_Refresh_Historie (Button) manuell zu loeschenZeile 1 auskommentieren
Zeile 3 aktivieren -
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
@sigi234
es gibt eine Kommentarzeile dazuconst scheduleTimeClearSMTexte = "2 0 1 * *"; // am 1. tag des monats um 00:02 morgens sollen alle Servicemeldungen des Monats geloescht werden // const scheduleTimeClearSMTexte = "58 23 * * 0"; // alternative Sonntags um 23:58 Uhr sollen alle Servicemeldungen der Woche im datenpunkt der SM-Texte geloescht werden // const scheduleTimeClearSMTexte = "60 * * * *"; // altenative ist den schedule zur Loeschung der Histore nie auszuloesen und ggf über den Datenpunkt id_Button_Refresh_Historie (Button) manuell zu loeschenZeile 1 auskommentieren
Zeile 3 aktivierenDas habe ich gemacht aber:
-
@sigi234
stimmt, das ging früher. Die Türe haben die ioBroker Kollegen dann wohl geschlossen.
Ich habe schon eine alternative eingebaut. Kommt später am Nachmittag.vG Looxer
-
3.08 ist online
- Korrektur zur 3.07: es gibt jetzt die Variable "ScheduleAktiv" in den Experteneinstellungen. Bei true wird der schedule zur Löschung der History z.B. monatlich ausgeführt. Bei false wird der schedule nicht ausgeführt und sollte hin und wieder manuell durchgeführt werden
vG Looxer
-
Im ersten Post habe ich die Views für HTML und JSON aktualisiert. Beide Views sehen nahezu identisch aus und enthalten einen Push-Button, mit dem die Historie manuell gelöscht werden kann. Es gibt keine Sicherheitsabfrage, sodass beim Drücken des Buttons die gesamte Meldungshistorie gelöscht wird.
Die Standardeinstellung bleibt unverändert: Am 1. jedes Monats erfolgt die automatische Löschung. Mit der Einstellung „ScheduleAktiv = false“ kann diese Funktion jedoch deaktiviert werden.
vG Looxer
-
Dein Script funktioniert wirklich zuverlässig.
Ich hab jetzt mal die neueste Version ausprobiert, da ist mir aufgefallen, wenn man Text kurz einstellt, dann wird bei einer Sabotageauslösung nur noch „Sabotage“ gesendet. Das dazugehörige Gerät wird nicht mit gesendet.
Ist das so gewollt? -
@knallochse
Hi
gerade mal nachgesehen im code.
Gesendet wird aufgrund dieser Tabelle: statusMessages (details unten)
Und ich sende bei kurzer Meldung tatsächlich nur die pure messages. In diesem Fall Sabotage. Ist so programmiert aber
vielleicht nicht so hilfreich. Ich schaue es mir an.vG Looxer
const statusMessages = { UNREACH_ALARM: { "hm-rpc": { 0: "keine Kommunikationsfehler", 1: "Kommunikation gestoert", 2: "Kommunikation war gestoert" } }, STICKY_UNREACH_ALARM: { "hm-rpc": { 0: "keine Kommunikationsfehler", 1: "Sticky Kommunikation gestoert", 2: "Sticky Kommunikation war gestoert" } }, SABOTAGE_ALARM: { "hm-rpc": { 0: "Keine Sabotage", 1: "Sabotage", 2: "Sabotage aufgehoben" } }, STICKY_SABOTAGE_ALARM: { "hm-rpc": { 0: "Keine Sabotage", 1: "Sticky Sabotage", 2: "Sticky Sabotage aufgehoben" } }, LOWBAT_ALARM: { "hm-rpc": { 0: "Batterie ok", 1: "Batterie niedrig", 2: "Batterie ok" } }, LOW_BAT_ALARM: { "hm-rpc": { 0: "Batterie ok", 1: "Batterie niedrig", 2: "Batterie ok" } }, ERROR_NON_FLAT_POSITIONING_ALARM: { "hm-rpc": { 0: "Keine Meldung", 1: "Geraet wurde angehoben.", 2: "Geraet wurde angehoben: Bestaetigt" } }, CONFIG_PENDING_ALARM: { "hm-rpc": { 0: "keine Meldung", 1: "Konfigurationsdaten stehen zur Uebertragung an", 2: "Konfigurationsdaten standen zur Uebertragung an" } }, UPDATE_PENDING_ALARM: { "hm-rpc": { 0: "kein Update verfuegbar", 1: "Update verfuegbar", 2: "Update wurde eingespielt" } }, ERROR_OVERHEAT_ALARM: { "hm-rpc": { 0: "kein Overheat Alarm", 1: "Overheat gemeldet", 2: "Overheat geloest" } }, ERROR_UNDERVOLTAGE_ALARM: { "hm-rpc": { 0: "Kein Undervoltage Alarm", 1: "Undervoltage gemeldet", 2: "Undervoltage geloest" } }, DEVICE_IN_BOOTLOADER_ALARM: { "hm-rpc": { 0: "Keine Meldung", 1: "Geraet startet neu", 2: "Geraet wurde neu gestartet" } }, DUTY_CYCLE: { "hm-rpc": { false: "Geraete-Duty Cycle ok", true: "Geraete-Duty Cycle erreicht", null: "unbekannter Status (Duty_Cycle" } }, lowBat: { "hmip": { false: "Batterie ok", true: "Batterie niedrig", null: "Batterie ok" } }, unreach: { "hmip": { false: "keine Kommunikationsfehler", true: "Kommunikation gestoert", null: "Kommunikation war gestoert" } }, sabotage: { "hmip": { false: "Keine Sabotage", true: "Sabotage", null: "Sabotage aufgehoben" } }, configPending: { "hmip": { false: "Keine Meldung", true: "Konfigurationsdaten stehen zur Uebertragung an", null: "Konfigurationsdaten standen zur Uebertragung an" } }, FALLBACK: { "hm-rpc": { 0: "keine Stoerung", 1: "Stoerung", 2: "Stoerung aufgehoben", false: "Keine Stoerung", true: "Stoerung", null: "unbekannter Status Fallback"}, "hmip": { false: "keine Stoerung", true: "Stoerung", null: "Stoerung aufgehoben" }, } }; -
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
@knallochse
Hi
gerade mal nachgesehen im code.
Gesendet wird aufgrund dieser Tabelle: statusMessages (details unten)
Und ich sende bei kurzer Meldung tatsächlich nur die pure messages. In diesem Fall Sabotage. Ist so programmiert aber
vielleicht nicht so hilfreich. Ich schaue es mir an.Hi
Aus diesem Grund bin ich wieder auf das alte Script umgestiegen.
Ich lasse mir die Meldungen nach Telegram schicken. Die lange Version ist mir dabei zuviel und die kurzen Meldungen sind nicht aussagekräftig.
So etwas wie "Sticky Kommunikation gestoert" oder "Batterie niedrig - Batteriebezeichnung: 1x LR3/AAA" ohne Angabe um welches Gerät es sich handelt ist nicht hilfreich.
Das ist im alten Script besser gelöst.Grüße
-
@rantanplan
ich selber nutze nur email und daher habe nur die langen messages wirklich gesichtet und so ist es
mir nicht aufgefallen. Aber ja, so machen die kurzen messages keinen Sinn. Ist bei mir schon gefixt. -
Version 3.09 ist online
- kurze Messages gesendet über email, whatsapp, pushover etc. enthalten jetzt auch den Gerätenamen
vG Looxer
-
Hi,
Die Tabelle zur Ausgabe von messages habe ich überprüft und festgestellt, dass nicht alles so funktioniert wie gedacht.
Hier mal ein Beispiel was möglich istlet MessageSendCollector = [] const services = ['email', 'email', 'whatsApp', 'Signal', 'Telegram', 'Pushover', 'Pushsafer']; const MessengerScope = { 'UNREACH_ALARM': [true, false, false, false, false, false, false], 'LOWBAT_ALARM': [false, false, false, false, false, false, false], 'SABOTAGE_ALARM': [true, false, true, false, false, false, false], 'CONFIG_PENDING': [true, false, false, false, false, false, false], 'Sonstige': [false, false, false, false, false, false, false], 'keineSM': [true, false, false, false, false, false, false], } const MessengerInstanz = [1, 2, 1, 0, 0, 0, 0 ]; // Instanz des Messengers const TextTypeKurz = [false, true, true, true, true, true, true ]; // bei true wird der Kurztext gesendet - sonst der Langtext- Es lassen sich beliebige (gültige) messageTypes hinzufügen.
- Es können je messageType mehrere gleiche messasgeservices mit unterschiedlichen Instanzen hinzugefügt werden.
- Alle gültigen messageTypes, die nicht in einer Zeile konfiguriert sind, werden automatisch unter "Sonstige" konfiguriert und gesendet
Der Zweck mehrerer MessageServices für einen MessageType ist z.B. eine besondere Behandlung für wichtige im Vergleich zu weniger wichtigen Message Types zu ermöglichen (unterschiedliche Instanzen z.B. bei Pushsafer)
Das funktioniert soweit alles bei mir. Ich werde noch ein wenig testen und dann posten.
vG Looxer
-
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
Version 3.09 ist online
- kurze Messages gesendet über email, whatsapp, pushover etc. enthalten jetzt auch den Gerätenamen
vG Looxer
Sieht besser aus.
Danke!Grüße
-
Hi,
Version 3.10 ist online- Erhöhung der Wartezeit für HM-REGA Trigger (GeraeteIDTrigger = false = 1 subscription) von 2 Sekunden auf 3,5 Sekunden. Es gab vereinzelt Fälle bei denen der Update der ioBroker Datenpunkte länger als 2 Sekunden dauerte
- Erweiterung der Funktion der Tabelle MessengerScope. Es lassen sich abhängig vom Alarmtype Nachrichten auf verschiedene Instanzen senden. Dadurch kann z.B. eine erhöte Priorität für Sabotage-alarm indiziert werden. Ein Beispiel für Pushsaver wurde mit den Einstellungen dieser Tabelle eingerichtet. Im u.g. Beispiel wird die Sabotage Meldung sowohl an Instanz 0 als auch an 1 gesendet.
Looxer
Tabelle MessengerScope:
// fuer alle Spalten mit true werden die Nachrichten ueber den zugeordneten Dienst versendet, vorausgesetzt der Messenge Adapter ist in iobroker installiert/konfiguriert const services = ['email', 'whatsApp', 'Signal', 'Telegram', 'Pushover', 'Pushsafer', 'Pushsafer',]; const MessengerScope = { 'UNREACH_ALARM': [false, false, false, false, false, true, false,], 'LOWBAT_ALARM': [false, false, false, false, false, true, false,], 'SABOTAGE_ALARM': [false, false, false, false, false, true, true,], 'CONFIG_PENDING_ALARM': [false, false, false, false, false, true, false,], 'Sonstige': [false, false, false, false, false, true, false,], // text ist fest verdrahtet nicht ändern 'keineSM': [false, false, false, false, false, true, false,], // text ist fest verdrahtet nicht ändern } const MessengerInstanz = [0, 0, 0, 0, 0, 0, 1, ]; // Instanz des Messengers const TextTypeKurz = [false, true, true, true, true, true, false,]; // bei true wird der Kurztext gesendet - sonst der Langtext -
@looxer01 Hallo
wäre es möglich die Bestätigung von Servicemeldungen einzubauen?
Ich habe folgendes Problem.
Wenn ich die automatische Bestätigung in der CCU3 aktiviere, werden erledigte Meldungen, auf der CCU3, nicht mehr angezeigt. (Servicemeldungen (0))
Aber ioBroker bekommt davon nichts mit. Dort werden die Meldungen immer noch angezeigt.
Ich muss dann die Funktion in der CCU wieder deaktivieren.
Wenn ich das gemacht habe, werden die (alten) Meldungen wieder in der CCU angezeigt.
Nach einer manuellen Bestätigung wird dann auch ioBroker aktualisiert und Dein Script kann reagieren.Keine Ahnung woran das liegt und ich der einzige bin der das Problem hat.
Mit dem alten Script hat das immer funktioniert.Grüße
-
@rantanplan
Hi,
es wäre gut ein paar Informationen einzusammeln:- Welche Version nutzt du ?
- du schreibst, dass du die CCU3 nutzt (nicht RM - korrekt ?)
- wie ist die Variable GeraeteIDTrigger eingestrellt ? (true oder false) ich nehme an: false
- die stehengebliebene Service meldungen sehen wie genau aus (alarmtype ?)
- welche hm geraeteklassen sind betroffen (ich nehme an nur HM-Classic)
Das würde helfen
zwischenzeitlich könnte es helfen, die Sticky-Unreach Meldungen zu ignorieren.
Das kannst du erreichen indem du die Zeile auskommentierst (siehe unten)const alarmTypes = [ { key: 'UNREACH_ALARM', suffixes: ['UNREACH_ALARM','unreach' ] },//UNREACH_ALARM = HM-Classic & HMIP-CCU - unreach = HMIP Accesspoint // { key: 'STICKY_UNREACH_ALARM', suffixes: ['STICKY_UNREACH_ALARM'] }, { key: 'CONFIG_PENDING_ALARM', suffixes: ['CONFIG_PENDING_ALARM','configPending'] }, //configPending ist eine HMIP Meldung { key: 'UPDATE_PENDING_ALARM', suffixes: ['UPDATE_PENDING_ALARM'] }, { key: 'LOWBAT_ALARM', suffixes: ['LOWBAT_ALARM', 'LOW_BAT_ALARM','lowBat'] }, //LOWBAT_ALARM = HM-Classic - LOW_BAT_ALARM = HMIP CCU - lowBat = HMIP Accesspoint { key: 'DEVICE_IN_BOOTLOADER_ALARM', suffixes: ['DEVICE_IN_BOOTLOADER_ALARM'] }, { key: 'ERROR', suffixes: ['ERROR','DUTY_CYCLE'] }, // error ist ein Sammler fuer hier nicht definierte Meldungen { key: 'FAULT_REPORTING', suffixes: ['FAULT_REPORTING'] }, { key: 'SABOTAGE_ALARM', suffixes: ['SABOTAGE_ALARM','sabotage'] }, // sabotage ist eine HMIP Meldung { key: 'STICKY_SABOTAGE_ALARM', suffixes: ['STICKY_SABOTAGE_ALARM'] }, { key: 'ERROR_NON_FLAT_POSITIONING_ALARM', suffixes: ['ERROR_NON_FLAT_POSITIONING_ALARM'] }, { key: 'OVERHEAT_ALARM', suffixes: ['ERROR_OVERHEAT_ALARM'] }, { key: 'UNDERVOLTAGE_ALARM', suffixes: ['ERROR_UNDERVOLTAGE_ALARM'] }, ]; -
@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:
@rantanplan
Hi,
es wäre gut ein paar Informationen einzusammeln:- Welche Version nutzt du ?
Version 3.10
- du schreibst, dass du die CCU3 nutzt (nicht RM - korrekt ?)
Korrekt.
- wie ist die Variable GeraeteIDTrigger eingestrellt ? (true oder false) ich nehme an: false
Steht auf false
- die stehengebliebene Service meldungen sehen wie genau aus (alarmtype ?)
Meist "UNREACH_ALARM" oder "STICKY_UNRAECH_ALARM"
In der CCU steht "Gerätekommunikation war gestört".- welche hm geraeteklassen sind betroffen (ich nehme an nur HM-Classic)
Ja.
Das würde helfen
zwischenzeitlich könnte es helfen, die Sticky-Unreach Meldungen zu ignorieren.
Das kannst du erreichen indem du die Zeile auskommentierst (siehe unten)Habe ich auskommentiert.
In der CCU habe ich die automatische Bestätigung wieder aktiviert.Mal schauen was passiert.
Danke für die schnelle Antwort.Grüße
