[Vorlage] Servicemeldungen Volume2

looxer01

@edis77
ok, kein Problem. Ich erstelle eine Version, die aber dann schon final ist.
Ich bin sicher, dass das beschriebene Problem damit behoben wird.

kann aber Morgen werden.

vG Looxer

looxer01

Hi Version 3.21 ist online

ACHTUNG die JSON fuer aktuelle und historische Servicemeldungen wurde um ein Feld erweitert. Bitte sorgt dafür, dass ihr keine aktuellen STICKY-Meldungen habt, wenn diese Script-Version aktiviert wird (gibt dann Fehlermeldungen). Ansonsten kann die Version ohne Probleme aktiviert werden.
Tabelle "instanceIds" um feld "Messaging" erweitert(Ausschalten von Nachrichten Adapter/Instanz Kombi). Somit kann z.B. für die Gruppenmeldungen generell ein Nachrichtenversand verhindert werden
DataPoint Filter für selektor hinzugefuegt. Der Filter laesst sich flexibel mit wildcards in einer Tabelle einstellen. Notwendig wurde dieser für den HM-AccessPoint, um Datenpunkte mit Alarmtypes auszuschliessen, die aber nur für Gruppen relevant waren und nicht für einzelne Geräte

vG Looxer

@Edis77
Diese Version sollte dein Problem beheben.

Edis77

@looxer01
Danke für das Anpassung.
Skript läuft und keine Fehler im LOG.

looxer01

Hi,
Version 3.30 ist online mit der Möglichkeit der Sprachausgabe.

Ich schreibe gerade für mich ein Alarmanlagenscript. Sprachausgabe ist eine von vielen Anforderungen.
Dabei nutze ich viele Elemente des Servicemeldungsscripts. Daher habe ich die Sprachausgabe dem Servicemeldungsscript jetzt hinzugefügt.

Die Sprachausgabe erfolgt über den "sayit" Adapter.
Eine Uhrzeit von bis kann konfiguriert werden, damit es Nachts nicht zu Störungen kommt.
Ich meine, dass die Sprachausgabe insbesondere bei Sabotage Sinn macht.
Anmerkung: im sayit Adapter kann je instanz ein anderes ausgabegerät festgelegt werden.
Im servicemeldungsscript können mehrere Instanzen konfiguriert werden - das passt also.

Die Konfig findet ihr in der Tabelle messenger scope und die Uhrzeiten für die Sprachausgaben darunter.

noch ein Hinweis:
im SayIt Adapter kann man "Browser" als Ausgabegerät konfigurieren. Damit können also eventuelle Tablets z.B. mit dem FullyKioskBrowser als Ausgabegeräte genutzt werden

vG Looxer

rantanplan

@looxer01 Hallo

Ich habe hier eine Servicemeldung die Dein Script nicht mitbekommt.

Bei dem Gerät handelt es sich um ein HM-Classic "HM-CC-RT-DN".
Die Servicemeldung lautet: "Leere Batterie".

In Deinem Script habe ich mal folgendes hinzugefügt.

//ErrorMessages fuer HM-Classic Geraet (Heizung) - Sonderfaelle
const faultMessages = {
    'HM-CC-RT-DN': {
        0: 'keine Stoerung',
        1: 'Ventil blockiert',
        2: 'Einstellbereich Ventil zu gross',
        3: 'Einstellbereich Ventil zu klein',
        4: 'Kommunikationsfehler',
        6: 'Spannung Batterien/Akkus gering',
        7: 'Fehlstellung Ventil',
	8: 'Leere Batterie'       //von mir hinzugefügt !!!
    }
};

Hat aber nichts gebracht. (Vielleicht weil die Meldung schon vorhanden ist?)

Grüße

looxer01

@rantanplan
Hi,
kannst du mal die Objektliste für das Gerät checken ?
In den Objektdaten stehen ja die möglichen Status. (also mindestens die 0 - 7)
Ich muss halt wissen welcher Datenpunkt den Status für die leere Batterie mit welcher Ausprägung enthält.
(leider besitze ich kein classic mehr)

Kannst du das Protokoll laufen lassen mit debug level 2 und posten ?
muss der Zeitpunkt sein bei dem die CCU die Servicemeldung lowbat erzeugt.

vG Looxer

Edit: der relevante Datenpunkt müsste FAULT_REPORTING sein, wenn es der ist, den du im Blick hast.
Allerdings war ich der Meinung, dass es auch einen "lowbat"-Datenpunkt geben müsste.

emil70

@looxer01

Der LOWBAT Datenpunkt sieht so aus

{
  "type": "state",
  "common": {
    "name": "Heizung Büro:0.LOWBAT",
    "role": "indicator.lowbat",
    "def": false,
    "type": "boolean",
    "read": true,
    "write": false
  },
  "native": {
    "DEFAULT": false,
    "FLAGS": 9,
    "ID": "LOWBAT",
    "MAX": true,
    "MIN": false,
    "OPERATIONS": 5,
    "TAB_ORDER": 3,
    "TYPE": "BOOL",
    "UNIT": ""
  },
  "from": "system.adapter.hm-rega.0",
  "user": "system.user.admin",
  "ts": 1733764617734,
  "_id": "hm-rpc.0.NEQ0871182.0.LOWBAT",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

der LOWBAT_ALARM Datenpunkt so

{
  "type": "state",
  "common": {
    "name": "Heizung Büro:0.LOWBAT_ALARM",
    "type": "number",
    "role": "indicator.alarm",
    "read": true,
    "write": true,
    "def": 0,
    "states": {
      "0": "NO ALARM",
      "1": "ALARM",
      "2": "ACKNOWLEDGED"
    }
  },
  "native": {
    "Name": "Heizung Büro:0.LOWBAT_ALARM",
    "TypeName": "ALARM",
    "DP": "16869"
  },
  "from": "system.adapter.hm-rega.0",
  "user": "system.user.admin",
  "ts": 1733806812677,
  "_id": "hm-rpc.0.NEQ0871182.0.LOWBAT_ALARM",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

der BATTERY_STATE Datenpunkt so

{
  "type": "state",
  "common": {
    "name": "Heizung Büro.BATTERY_STATE",
    "role": "value.voltage",
    "def": 0,
    "type": "number",
    "read": true,
    "write": false,
    "min": 1.5,
    "max": 4.6,
    "unit": "V"
  },
  "native": {
    "CONTROL": "NONE",
    "DEFAULT": 0,
    "FLAGS": 1,
    "ID": "BATTERY_STATE",
    "MAX": 4.6,
    "MIN": 1.5,
    "OPERATIONS": 5,
    "TAB_ORDER": 2,
    "TYPE": "FLOAT",
    "UNIT": "V"
  },
  "from": "system.adapter.hm-rega.0",
  "user": "system.user.admin",
  "ts": 1733764617915,
  "_id": "hm-rpc.0.NEQ0871182.4.BATTERY_STATE",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Screenshot 2025-03-19 at 12-33-17 objects - f5529c8310eb.png
Hoffe das ist das was du brauchst

looxer01

@emil70
@rantanplan

vielen Dank, das ist es was ich brauchte
Allerdings stelle ich fest, dass es sich hier um einen Standardfall handelt.
LOWBAT_ALARM wird mit 1 gesetzt womit das Gerät selektiert werden sollte, wie andere classic Geräte auch.

Die erste Frage ist, ob das Script überhaupt ausgelöst wird. Das hängt mit der GeraeteIDTrigger einstellung zusammen
Entweder weil der Datenpunkt hm-rega.0.maintenance verändert wurde (bei GeraeteIDTrigger = false) oder
weil die 1 im Datenpunkt LOWBAT_ALARM gesetzt wurde (bei GeraeteIDTrigger = true).
Wenn es auslöst, dann hilft ein Protokoll. Das kann ja auch über längere Zeit aktiv gesetzt werden und als Datei abgespeichert werden.
So stört es dann nicht im Protokoll und du brauchst nicht danach im Protokoll zu suchen.

vG Looxer

rantanplan

@looxer01
Ich habe mal im Script debugLevel auf 2 gesetzt.
GeraeteId steht bei mir auf false.

Dann habe ich neue Batterien eingesetzt.
Meldung auf der CCU3 weg.

Dann wieder die alten Batterien eingesetzt.
Systemmeldung auf der CCU3 "Leere Batterie"

Hier das LOG.
ServicemeldungenSystemLog.csv

Aktuell sind noch die leeren Batterien drin.
Sieht so aus:

Object Daten WZ-VD-Regal:4.FAULT_REPORTING

{
 "type": "state",
 "common": {
   "def": 0,
   "type": "number",
   "read": true,
   "write": false,
   "min": 0,
   "max": 7,
   "states": {
     "0": "NO_FAULT",
     "1": "VALVE_TIGHT",
     "2": "ADJUSTING_RANGE_TOO_LARGE",
     "3": "ADJUSTING_RANGE_TOO_SMALL",
     "4": "COMMUNICATION_ERROR",
     "5": "",
     "6": "LOWBAT",
     "7": "VALVE_ERROR_POSITION"
   },
   "role": "indicator",
   "name": "WZ-VD-Regal:4.FAULT_REPORTING"
 },
 "native": {
   "CONTROL": "NONE",
   "DEFAULT": 0,
   "FLAGS": 9,
   "ID": "FAULT_REPORTING",
   "MAX": 7,
   "MIN": 0,
   "OPERATIONS": 5,
   "TAB_ORDER": 1,
   "TYPE": "ENUM",
   "UNIT": "",
   "VALUE_LIST": [
     "NO_FAULT",
     "VALVE_TIGHT",
     "ADJUSTING_RANGE_TOO_LARGE",
     "ADJUSTING_RANGE_TOO_SMALL",
     "COMMUNICATION_ERROR",
     "",
     "LOWBAT",
     "VALVE_ERROR_POSITION"
   ]
 },
 "from": "system.adapter.hm-rega.0",
 "user": "system.user.admin",
 "ts": 1740918410792,
 "_id": "hm-rpc.0.OEQ2637929.4.FAULT_REPORTING",
 "acl": {
   "object": 1636,
   "state": 1636,
   "owner": "system.user.admin",
   "ownerGroup": "system.group.administrator"
 }
}

Object Daten WZ-VD-Regal:4.FAULT_REPORTING-6_ALARM

{
 "type": "state",
 "common": {
   "name": "WZ-VD-Regal:4.FAULT_REPORTING-6_ALARM",
   "type": "number",
   "role": "indicator.alarm",
   "read": true,
   "write": true,
   "def": 0,
   "states": {
     "0": "NO ALARM",
     "1": "ALARM",
     "2": "ACKNOWLEDGED"
   }
 },
 "native": {
   "Name": "WZ-VD-Regal:4.FAULT_REPORTING-6_ALARM",
   "TypeName": "ALARM",
   "DP": "16978"
 },
 "from": "system.adapter.hm-rega.0",
 "user": "system.user.admin",
 "ts": 1548955628248,
 "_id": "hm-rpc.0.OEQ2637929.4.FAULT_REPORTING-6_ALARM",
 "acl": {
   "object": 1636,
   "state": 1636,
   "owner": "system.user.admin",
   "ownerGroup": "system.group.administrator"
 }
}

Was kann ich noch tun?

Grüße

looxer01

@rantanplan

@rantanplan sagte in [Vorlage] Servicemeldungen Volume2:

Was kann ich noch tun?

im moment nichts. Ich erstelle einen Fix und poste ihn hier.
Ursache ist, so glaube ich, klar.

vG Looxer

looxer01

@rantanplan
kannst du diese Tabelle austauschen und dann nochmal mit debug laufen lassen ?

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','FAULT_REPORTING-1_ALARM','FAULT_REPORTING-2_ALARM','FAULT_REPORTING-3_ALARM','FAULT_REPORTING-4_ALARM','FAULT_REPORTING-5_ALARM','FAULT_REPORTING-6_ALARM'] },
    { 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'] },
];

Die Änderung befindet sich in Zeile 9.

looxer01

@rantanplan
ignoriere die voherige message.
Nutze stattdessen die angehängte Version. Ich musste noch ein paar Codezeilen hinzufügen.
Es konnte gar nicht funktionieren

Servicemeldungen_Vol2_3-30_Rantanplan.txt

rantanplan

@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:

@rantanplan
ignoriere die voherige message.

Zu spät

Mit leeren Batterien kam die Meldung ".....Ventil blockiert"

Damit meine "Arbeit" nicht umsonst war, hier das Log.
ServicemeldungenSystemLog.csv

Probiere jetzt Dein geändertes Script.

rantanplan

@looxer01
Nach dem Script-Start wird "Einstellbereich Ventil zu gross" gemeldet
Auf der CCU3 keine Servicemeldung.

Hier das Log.
ServicemeldungenSystemLog.csv

Habe auch mal das andere Log aktiviert.
ServicemeldungenVol2.csv

Sehe gerade, dass "FAULT_REPORTING-6_ALARM" in ioBroker tatsächlich auf '2' steht. Warum auch immer.
CCU3 sagt "alles ok".

Tausche jetzt nochmal die Batterien.

looxer01

@rantanplan

es wäre gut zu wissen wie Object Daten WZ-VD-Regal:4.FAULT_REPORTING ausgeprägt ist. Denn dort gibt es die status 1 - 7. bei den anderen nicht. (das hatte ich leider falsch gesehen)
In der Regel werden die ALARM-Datenpunkte augelöst.
Ein quick Fix wäre 'FAULT_REPORTING-6_ALARM' unter den AlarmType LowBat zu listen. Dann fehlen aber immer noch die anderen Alarme.

ich muss nochmal nachdenken.

EDIT
ok, nachgedacht.
Der Ansatz wäre

'FAULT_REPORTING-6_ALARM' unter lowbat zu führen. Dann bekommst du das auch klassifiziert als lowbat und nicht als 'FaultMessage"
Die anderen werde ich dann vom status her als FaultMessages führen und die status 1-7 (ohne 6) entsprechend als status messages entsprechend der Tabelle: faultMessages aus dem Script darstellen

brauche ich jetzt aber ein wenig Zeit für

looxer01

@rantanplan
ich habe eine neue Version gebaut und hoffe, dass es jetzt ok ist.

Du solltest jetzt eine lowbat message erhalten für dieses gerät.

für alle anderen messages (Ventilstellung etc) erhälts du "Fault Messages"

Servicemeldungen_Vol2_3-30_Rantanplan2.txt

Falls ok, werde ich das in die nächste Version übernehmen.

vG Looxer

rantanplan

@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:

@rantanplan
ich habe eine neue Version gebaut und hoffe, dass es jetzt ok ist.

Du solltest jetzt eine lowbat message erhalten für dieses gerät.

für alle anderen messages (Ventilstellung etc) erhälts du "Fault Messages"

Irgendetwas hakt noch. (Sorry)

Leztes Script gestartet.
Leere Batterien noch im Gerät.
CCU3 zeigt "Leere Batterie"
Script JSONAktuelleSM "Keine passende Meldung......."

[
 {
   "datum_seit": "20.03.25 13:12:21 Uhr",
   "meldungsart": "FAULT_REPORTING-6_ALARM",
   "common_name": "Wohnzimmer-VD-Regal",
   "GeraeteId": "OEQ2637929",
   "status": 1,
   "status_message_Lang": "20.03.25 13:12:21 Uhr - FAULT_REPORTING-6_ALARM - Wohnzimmer-VD-Regal - (OEQ2637929) - 1 - Keine passende Meldung fuer MessageType: \"FAULT_REPORTING-6_ALARM\", Adapter: \"hm-rpc\", Status: \"1\". - Batteriebezeichnung: 2x LR6/AA",
   "status_message_Pure": "Keine passende Meldung fuer MessageType: \"FAULT_REPORTING-6_ALARM\", Adapter: \"hm-rpc\", Status: \"1\". - Batteriebezeichnung: 2x LR6/AA",
   "batterie_bezeichnung": "2x LR6/AA",
   "SM_aufgehoben_seit": "aktiv",
   "DataPoint": "hm-rpc.0.OEQ2637929.4.FAULT_REPORTING-6_ALARM"
 }
]

Über Telegram kam keine Meldung!!!

Hier das LOG.
ServicemeldungenSystemLog.csv

Grüße

looxer01

@rantanplan
wenn ich mir das log ansehe, dann sehe ich, dass eine Message reported wird:

Screenshot 2025-03-20 152312.png

EDIT:
ja, schon gefunden. Ist die Umsetzung für die Nachricht.
Muss ich mir aber näher ansehen.

looxer01

@rantanplan
kannst du die folgende Tabelle austauschen ?

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" } },
    'FAULT_REPORTING-6_ALARM':        { "hm-rpc": { 0: "Batterie ok",                    1: "Batterie niedrig",                                  2: "Batterie ok" } }, // nur for HM-CC-TT-DN
    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" }, }
};

rantanplan

@looxer01 sagte in [Vorlage] Servicemeldungen Volume2:

@rantanplan
kannst du die folgende Tabelle austauschen ?

Habe ich gemacht.
Sieht gut aus!

Scipt-Meldung:

[
 {
   "datum_seit": "20.03.25 13:12:21 Uhr",
   "meldungsart": "FAULT_REPORTING-6_ALARM",
   "common_name": "Wohnzimmer-VD-Regal",
   "GeraeteId": "OEQ2637929",
   "status": 1,
   "status_message_Lang": "20.03.25 13:12:21 Uhr - FAULT_REPORTING-6_ALARM - Wohnzimmer-VD-Regal - (OEQ2637929) - 1 - Batterie niedrig - Batteriebezeichnung: 2x LR6/AA",
   "status_message_Pure": "Batterie niedrig - Batteriebezeichnung: 2x LR6/AA",
   "batterie_bezeichnung": "2x LR6/AA",
   "SM_aufgehoben_seit": "aktiv",
   "DataPoint": "hm-rpc.0.OEQ2637929.4.FAULT_REPORTING-6_ALARM"
 }
]

Telegram hat aber nichts gemeldet.
Liegt das eventuell daran, dass die Meldung schon vorhanden war?

Hier das aktuelle Log
ServicemeldungenSystemLog.csv

Ich mache jetzt nochmal Batteriewechsel und melde mich danach.

Grüße

NEWS

[Vorlage] Servicemeldungen Volume2

Support us

967
Online

31.7k
Users

79.6k
Topics

1.3m
Posts

NEWS

[Vorlage] Servicemeldungen Volume2

Support us

967Online

31.7kUsers

79.6kTopics

1.3mPosts

967
Online

31.7k
Users

79.6k
Topics

1.3m
Posts