[Vorlage] Servicemeldungen Volume2

[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"
  }
}

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:

Spoiler

Object Daten WZ-VD-Regal:4.FAULT_REPORTING

Spoiler

{
 "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

Spoiler

{
 "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......."

Spoiler

[
 {
   "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:

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:

Spoiler

[
 {
   "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

[rantanplan]

@looxer01
Perfekt!!!!
Konnte zwar keine "Leere Batterie" mehr erzeugen, weil die alten Batterien wohl jetzt komplett leer sind, aber dafür kam die Meldung "Fehlstellung Ventil".

Neue Batterien rein und alles gut!
Ich gehe davon aus das das mein ENDbericht ist.

Vielen lieben Dank für den super Support!!!!

Grüße

[looxer01]

@rantanplan
danke dir. ich mache dann morgen vermutlich eine neue Version.
Bezüglich Telegram ist es so, dass nur neue Messages auch gesendet werden.
Sonst hätten wir ja immer bei Scriptstart immer neue Meldungen in der Inbox.

vG Looxer