[Vorlage] Servicemeldungen Volume2

looxer01

Version 3.09 ist online

kurze Messages gesendet über email, whatsapp, pushover etc. enthalten jetzt auch den Gerätenamen

vG Looxer

looxer01

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 ist

let 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

rantanplan

@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

looxer01

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

rantanplan

@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

looxer01

@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'] },
];

rantanplan

@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

looxer01

@rantanplan
ok, bitte sag dann Bescheid, wenn es so ok ist.
Ich muss mir generell überlegen wie ich damit umgehe.
die sticky-unreach Meldungen gibt es nur bei den classic Geräten und ich habe nur HMIP-Geräte.

vG Looxer

rantanplan

@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:

ok, bitte sag dann Bescheid, wenn es so ok ist.

Na klar, mache ich.

rantanplan

@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:

@rantanplan
ok, bitte sag dann Bescheid, wenn es so ok ist.

Ist leider nicht ok.
Die automatische Bestätigung auf der CCU3 funktioniert bei mir nicht.
Wenn die Funktion eingeschaltet ist, werden die Meldungen auf der CCU ausgeblendet.

Aber in ioBroker bleiben die aktiv.

Für Dein Script ist alles ok.

Wenn ich auf der CCU die automatische Bestätigung wieder deaktiviere, werden dort auch wieder die Meldungen angezeigt.

Nach der manuellen Bestätigung sind ioBroker und CCU wieder auf dem gleichen Stand.
Und Dein Script meldet meldet nochmal "Derzeit keine Servicemeldungen".

Mit der automatischen Bestätigung aus dem alten Script hat das immer geklappt.

Grüße

looxer01

@rantanplan

Ich verstehe hier vermutlich etwas falsch.

Hier ist was ich sehe bei der Version: auto confirm der CCU

Servicemeldungen in der CCU - 0
Servicemeldungen in iobroker im HM-REGA Datenpunkt = 3
Servicemeldungen laut Script = 0 - entsprechend der CCU

Wo ist jetzt genau das Problem ?
Das script ist gleichauf mit der CCU. Das sieht doch ok aus.
Die Anzahl der Meldungen im HM-Rega Datenpunkt wird durch die CCU Schnittstelle gesetzt und hat nichts mit dem Script zu tun.

Was erwartest du genau zu sehen ?

EDIT:
wahrscheinlich würdest du gerne die 3 Meldungen des HM-REGA Datenpunktes quittieren ?
Das hatte ich bisher nicht auf dem Radar. Warum ist das notwendig ?

vG Looxer

rantanplan

@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:

@rantanplan

Ich verstehe hier vermutlich etwas falsch.

Hier ist was ich sehe bei der Version: auto confirm der CCU

Servicemeldungen in der CCU - 0

Servicemeldungen in iobroker im HM-REGA Datenpunkt = 3

Servicemeldungen laut Script = 0 - entsprechend der CCU

Wo ist jetzt genau das Problem ?
Das script ist gleichauf mit der CCU. Das sieht doch ok aus.
Die Anzahl der Meldungen im HM-Rega Datenpunkt wird durch die CCU Schnittstelle gesetzt und hat nichts mit dem Script zu tun.

Was erwartest du genau zu sehen ?

Hhmmm....:thinking_face:
Das liegt wohl daran, dass ich mir den HM-Rega Datenpunkt in VIS anzeigen lasse.
Und dann kommt ein ungutes Gefühl auf, wenn da etwas nicht übereinstimmt.
Irgendwie werden die auf der CCU bestätigt aber doch nicht wirklich.
(scheint aber ein Problem auf der CCU zu sein)
Ich werde mir mal den Datenpunkt aus Deinen Script anzeigen lassen.
Nach dem Motto: Was ich nicht weiß, macht mich nicht heiß.

Aber eine wahlweise Funktion in Deinem Script könnte das Problem lösen. :wink:

Ich lasse es mal laufen. Hoffentlich kann ich ruhig schlafen. :blush:

Grüße

looxer01

@rantanplan sagte in [Vorlage] Servicemeldungen Volume2:

Und dann kommt ein ungutes Gefühl auf, wenn da etwas nicht übereinstimmt.

verstehe ich.
Allerdings ist die CCU auch nicht perfekt. Das siehst du daran, dass die Schnittstelle offensichtlich
nicht die auto-Bestätigung berücksichtigt.
Bei HMIP werden z.B. Thermostate/Fenstersensoren z.B. bei Unreach gemeldet und zusätzlich
die gleichen als Gruppenmeldung. Also 2 meldungen, wenn z.B. ein Thermostat ein Problem hat.

Die Servicemeldungen aus dem Script sind bei mir bisher eindeutiger als es bei der CCU der Fall ist.

Wenn du trotzdem kein gutes Gefühl hast, dann kannst du ja auch beides anzeigen. So siehst du stets die Unterschiede.

vG Looxer

rantanplan

@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:

Wenn du trotzdem kein gutes Gefühl hast, dann kannst du ja auch beides anzeigen. So siehst du stets die Unterschiede.

Bereits geschehen.
Alles gut!:+1:

Grüße

looxer01

Hi,
kleine Info:
ich habe mir das Thema "Sticky" genauer angesehen und beschlossen die automatische Bestätigung von Servicemeldungen einzubauen.
Das scheint mir nicht so sehr schwierig. Auf diese Art und Weise können dann auch Sticky Meldungen ohne Bestätigung in der CCU gezeigt werden.
Kommt demnächst.
Hinweis: Sticky Meldungen gibt es nur bei Homematic-Classic.

vG Looxer

looxer01

Hi,
Version 3.20 ist jetzt online.
Folgende Änderungen gibt es:

Doppelte Nachrichten im messageCollector verhindern
Vermeidung Meldung "keine Servicemeldungen..." in der Historie wenn bereits vorhanden
Wartezeit für Rega-Trigger wieder auf 5s
Sticky-Meldungen der CCU koennen automatisch bestaetigt werden

Details zur automatischen Bestaetigung von Servicemeldungen:
Zunächst mal hat sich die Funktion sehr gut in das Gesamtkonzept des Scriptes eingepasst - ohne Verbiegungen
Das Ganze ist nur relevant fuer HM-Classic Geräte, da es keine STICKY Meldungen für Homematic IP Geraete gibt.

Es wurde eine neue Variable implementiert, die standardmaessig auf true sitzt: AutoBestaetigungCCUMeldungen = true
Bei true wird eine Unterroutine aufgerufen, die die Bestaetigung vornimmmt wenn die Message bereits obsolet ist
Beispiel: UnreachMessage lag vor ist aber zwischenzeitlich nicht mehr relevant, dann wird die entsprechende STICKY_UNREACH Message bestaetigt.
Hinweis: Wenn die Sticky-Messages automatisch bestaetigt werden sollen, dann empfiehlt es sich die AutoBestaetigung der CCU auszuschalten (Systemeinstellungen der CCU in der Benutzerverwaltung)

zudem wurden im MessengerScope, also die Tabelle für den Nachrichtenversand die StickyMeldungen STICKY_UNREACH und STICKY_SABOTAGE aufgenommen.
Der Grund ist, dass man für diese Meldungen normalerweise keine Nachrichten empfangen möchte, da ja bereits durch UNREACH und SABOTAGE erfolgt.
Also sollte in der Tabelle "Messengerscope" für diese messageTypes alle Nachrichten auf false stehen.

Wenn jemand überhaupt keine STICKY-Messages sehen möchte, dann können die entsprechenden Zeilen einfach in der Tabelle Alarmtypes auskommentiert werden.
Somit werden diese Meldungen ignoriert.

sähe dann so aus

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'] },
];

vG Looxer

rantanplan

@looxer01 Hi

Scheint zu funktionieren!
Habe es mit einigen Sabotagen-Meldungen getestet.
CCU und Script Datenpunkte für Anzahl Meldungen bleiben synchron!
Klasse gemacht, Danke! :+1:

Grüße

rantanplan

@looxer01 Hi

"Kommunikation gestört" werden doch nicht von der CCU gelöscht.
Bei Sabotage Meldungen klappt es einwandfrei.

Im Script habe ich {key: 'Sticky_unreach_alarm".... auskommentiert.
Sonst nur meine üblichen Parameter gesetzt.

Grüße

looxer01

@rantanplan
Hi,
ja klar, wenn STICKY_UNREACH_ALARM auskommentiert ist, dann werden diese Meldungen auch nicht verarbeitet.
Nimm die Auskommentierung zurück. Dann sollte es gehen.

vG Looxer

rantanplan

@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:

Nimm die Auskommentierung zurück. Dann sollte es gehen.

Das war es. Läuft nun perfekt.
Danke.

Grüße

Community Forum

NEWS

[Vorlage] Servicemeldungen Volume2

Support us

836

32.4k

81.5k

1.3m