Servicemeldungen - All inclusive für Homematic -

[cash]

@bommel_030 Ich verstehe da so einiges nicht. Gestern hast Du geschrieben läuft. Heute Morgen das Du das Script scharf gemacht hast? Wie lief es gestern und hast Du es wieder gestoppt? Das zweite Log deutet darauf hin das das Script neu gestartet wurde? Z. B. durch reboot oder Adapter neu gestartet? Was ist dort passiert? Läuft Dein System insgesamt stabil? Für das Script brauchst Du jedensdall keinen Reeboot. Meine Kiste läuft 24/7.

Wie sieht die Config von Dir aus? Cuxd = „1“?

[cash]

@Dominik-F Genau das meinte ich. Die Antwort war nur zur Fehleranalyse wichtig aber ich hatte es ja auch so gefunden. Mit der nächsten Version brauchst Du das Script nicht mehr anpassen. Ich habe die entsprechenden Zeilen dort auch gelöscht weil nicht mehr nötig.

[Dominik F.]

@cash

ich danke dir auf jedenfall.

Ich hätte da vielleicht noch einen Vorschlag für dein Skript, weil ich das aus meinem bisherigen Skript für Servicemeldungen so kenne. Vielleicht könntest du eine Option einbauen, mit der man sich zu festgelegten Zeiten eine Pushnachricht/Email etc schicken kann mit den Meldungen? Bisher bekomme ich alle 24h eine Email ob alles in Ordnung ist bzw ob etwas vorliegt. Vielleicht könnte man das Skript so erweitern, das man einstellen kann, ob z.B.Push wie bisher versendet wird, oder zusätzlich zu festgelegten zeiten.

[cash]

@Dominik-F Das werde ich nicht einbauen weil ich keinen Sinn darin sehe. Man bekommt sofort beim auftreten der Meldung eine Push. Die Meldung landet in ein Objekt welches man bei Bedarf jederzeit auf vis sich angucken kann. Somit kann jeder bei Bedarf zu jeder Zeit nachgucken wie der Stand ist. Eine Batteriemeldung ist so lange aktiv bis man die Batteiren tauscht. Beim aufheben unreach bekommt man ebenfalls eine Nachricht.

Wozu also noch eine regelmäßige Übersicht die eigentlich immer zu 95% mit aktuell keine Servicemeldung ankommt.

Also wozu?

Du kannst Dir ja relativ einfach ein Script schreiben welches alle x Stunden Dir per Push das Objekt mit den Serviemeldungen schickt...Das ganze auch noch in das Script packen macht es nicht übersichtlicher. Ich hätte aber auch keine Idee wie ich das einigermaßen Sinnvoll konfigurierbar einbauen könnte.

[Dominik F.]

@cash

okay, so wie du das jetzt erklärt hast mach es wirklich nicht so viel sinn bzw ist eigentlich überflüssig. hab das nicht bedacht, dass man sich den Datenpunkt in Vis anzeigen lassen kann und man dort den aktuellen Status ja einsehen kann.

[bommel_030]

@cash
Das Testscript lief einwandfrei. Habe ich heute früh deaktiviert und die aktuelle Version deines Skriptes aktiviert. Auch das lief einwandfrei. Lowbat simuliert, geht. Da ich eh gerade am Rechner saß, JS-Controller aktualisiert, und getestet ob das Skript auch nach einem reboot funktioniert. Auch das hat funktioniert.
Die geposteten Fehlermeldungen kamen erst ne Weile danach.
Ein reboot schließe ich eigentlich aus. Ich habe keinen durchgeführt und wäre er "abgestürzt" wäre ich benachrichtigt worden.
Cuxd ist mit 1 auch richtig eingestellt und seit heute Vormittag läuft es wie erwartet.

[cash]

@bommel_030 Bleibt kurios. Ich habe in der neuen Version dafür einige Anpassungen vorgenommen um im Log das hinterher besser nachvollziehen zu können. Werde die Version in den nächsten Tagen online stellen.

[Dominik F.]

@cash

Mir sind in den letzten Tagen ein paar Dinge aufgefallen und ich bin mir unsicher ob das so sein soll.

Ich hatte zunächst einen Stromausfall, danach wurde ein Rauchmelder, der vorher immer eine Servicemeldung verusacht hat (hab weil er Fehlalarme verursacht hat, den vorrübergehend aus der Halterung genommen und es trat ein kommunikationsfehler auf), weder im Skript noch im Webui angezeigt.
Dazu habe ich, um das Skript nochmals zu testen, eine Funkzwischensteckdose vom Strom genommen. Auch hier trat keine Servicemeldung auf. Erst, als ich diese mit Vis einen Tag später geschaltet habe, kam dort ein Kommunikationsfehler in der WebUI und damit auch im Skript. Jetzt habe ich dauerhaft 2 Meldungen, einmal Sticky Unreach und einmal Unreach. Ist das richtig, dass mir dauerhaft angezeigt wird mit Sticky Unreach? In der WebUI habe ich nur den Kommunikationsfehler weil dort die andere Meldung automatisch bestätigt wurde. Im Skript und in den Datenpunkten taucht diese jedoch weiterhin auf.
Mir scheint, dass die CCU nur Fehlermeldungen ausspuckt, wenn z,B, ein Aktor direkt angesprochen wird. Beim Beispiel von dem Feuermelder würde ich jetzt eigentlich gar nicht wissen, dass dieser nicht mehr funktioniert. Bei Geräten die regelmäßig angesprochen werden, wie Wandthermostat etc funktioniert alles, aber die werden halt auch angesprochen.

Ich hoffe ich konnte mich verständlich ausdrücken.
Mache ich was falsch?

[cash]

@Dominik-F Das Script kann nur etwas melden wenn entsprechende Datenpunkte sich verändern. Bei Kom-Störungen sind das eben Sticky_unreach und unreach. Sprich wenn die sich ändern reagiert das Script. In der Webui der CCU muss man also einen Fehler sehen sonst werden die Homematic Adapter keine Datenpunkte ändern worauf das Script reagiert.
Nehmen wir mal den normalen Fall: Gerät an der CCU ist angelernt ohne Fehler (z. B. Brandmelder) . Alles gut.
Dieses Gerät meldet sich nur alle 24 Stunden (oder alle 12? Keine Ahnung) bei der CCU oder wenn es eben qualmt sofort. Jetzt entfernst Du die Batterie. Die CCU kriegt hiervon erstmal nichts mit. Erst wenn das Gerät sich nicht mehr meldet fragt die CCU ja. Da es keine Antwort gibt wird eine Serviemeldung in der CCU erzeugt. Der Rega-Adapter bekommt das mit und dadurch wird ein Objekt in ioroker geändert und jetzt kommt das Script ins Spiel....

Wenn Du jetzt den Stecker der CCU ziehst ist die Servicemeldung weg. Bei einen gekippten Fenster und den Drehgriffsensoren z. B. werden Dir jetzt auch alle Fenster als geschlossen angezeigt. Erst nach x Stunden. bei der nächsten Routinemeldung vom Sensor passt der Status wieder...

Und so ist es beim Brandmelder vermutlich auch. Das heißt irgendwann sollte in der CCU auch dazu wieder eine Serviemeldung auftauchen. Und erst dann kann mein Script reagieren.

Stromausfall ist generell etwas speziell. Und nach meiner Erfahrung ist jeder Test anders als die Realität. Bei mir macht es einen Unterschied ob ich eine normale Störung durch Umwelteinflüsse habe oder durch Batterie oder Strom entfernen. Deshalb teste ich das Script nur noch an echten Fällen. Bei mir funktioniert es wie es soll und ich kriege die Meldungen die ich erwarte. Je nach Wetter habe ich aber auch mal ein paar Wochen keine Fehlermeldung oder so wie gerade jeden Tag eine.

[bommel_030]

@cash
Kurze Rückmeldung meinerseits, die letzte Version deines Skriptes läuft bei mir seit einigen Tagen fehlerfrei.
Mehrere reboots, simulierte Fehlermeldungen, ignorierte Komponenten, Wechsel der js-Instanz hat alles keine Probleme verursacht.
Lediglich ein "Schönheitsfehler". Ich habe zwei Komponenten denen der Versorger regelmäßig den Saft abdreht.
Dazwischen liegen in der Regel wenige Sekunden. Ich bekomme dann immer 2 Nachrichten im Sekundenabstand. Die erste meldet den ersten Fehler, die zweite den ersten und zweiten Fehler zusammen. Schöner wäre es, wenn nach dem eintreffen eine Fehlermeldung x Sekunden gewartet wird ob noch eine weitere kommt.
Meine auch so einen Delay irgendwo im Skript gesehen zu haben.
Ist für mich nicht wirklich relevant, da die betroffenen Geräte im Realbetrieb eh ignoriert werden. Fiel mir nur beim testen auf.
Vielen Dank nochmals für dein Skript und die Unterstützung

[Kaschi68]

@cash
Erstmal vielen Dank für die ganze Mühe die Du schon in das Script eingebracht hast.

Ich nutze Deinen Script seit V1.20 mit mehreren Pushover Instanzen. Nun habe ich auf 1.62 gewechselt es gibt ein Problem, wo ich nicht hinter komme.
Alle Meldungen werden bei mir nur über eine pushover Instanz gesendet (pushover.3) bei mir prio 0.

Eingestellt habe ich meiner Meinung alles richtig.

const Version = 1.62;
const logging = true; //Sollte immer auf true stehen. Bei false wird garnicht protokolliert
const debugging = true; //true protokolliert viele zusätzliche Infos
const find_bug = false; //erhöht das Logging wird nur verwendet wenn ein aktulles Bug gesucht wird
const show_each_device = false; //zeigt alle verfügbaren Datenpunkte je Device

const autoAck = true; //Löschen bestätigbarer Kommunikationsstörungen (true = an, false = aus)

const observation = true; //Dauerhafte Überwachung der Geräte auf Servicemeldungen aktiv (true = aktiv // false =inaktiv)
const onetime = true; //Prüft beim Script Start ob derzeit Geräte eine Servicemeldung haben
const with_time = false; //Hängt die Uhrzeit an die Serviemeldung

//Geräte die nicht überwacht werden sollen. Komma getrennt erfassen
const no_observation = 'LEQ092862x9, XXX';

//Instanz Cuxd ausschließen. Instanz als Zahl z. B. '1' oder bei Nichtnutzung hohe Nr eintragen z. B. '9'
const CUXD = '1';

//pro Fehlertyp kann eine andere Prio genutzt werden
const prio_LOWBAT = 2;
const prio_UNREACH = 0;
const prio_STICKY_UNREACH = 0;
const prio_CONFIG_PENDING = -1;
const prio_UPDATE_PENDING = -1;
const prio_DEVICE_IN_BOOTLOADER = 0;
const prio_ERROR = 1;
const prio_ERROR_CODE = 1;
const prio_FAULT_REPORTING = 0;
const prio_SABOTAGE= 2;
const prio_ERROR_NON_FLAT_POSITIONING = 0;

//Variablen für Servicemeldung in Objekt schreiben // Wenn einer Meldung auftritt wird diese in ein Textfeld geschrieben. z. B. für vis
const write_message = false; // true schreibt beim auftreten einer Servicemeldung die Serviemeldung in ein Objekt
const id_Text_Servicemeldung = ''; // Objekt wo die Servicemeldung hingeschrieben werden soll

//Variablen für Pushover
const sendpush = true; //true = verschickt per Pushover Nachrchten // false = Pushover wird nicht benutzt
const pushover_Instanz0 = 'pushover.3'; // Pushover instance für Pio = 0
const pushover_Instanz1 = 'pushover.4'; // Pushover instance für Pio = 1
const pushover_Instanz2 = 'pushover.5'; // Pushover instance für Pio = 2
const pushover_Instanz3 = 'pushover.2'; // Pushover instance für Pio = -1 oder -2
let prio = -2; //nicht verändern die höchste Prio nach Fehlertyp wird verwendet
let titel;
let message;
let device = 'All'; //Welches Gerät soll die Nachricht bekommen
//let _device = 'All';

Der Script ist bei mir im Script-Adapter im Root-Verzeichnis abgelegt. JS-Controller ist 1.5.14.
Node.js v8.15.1, NPM 6.4.1.
Wie gesagt, bei V1.20 läuft alles mit den 4 pushover Instanzen für die Servicemeldungen.

Vielen Dank

[cash]

@Kaschi68 Obwohl Du eine LOWBAT hast kommt es über die Instanz 3? Theoretisch sehen die Einstellungen gut aus. Welche Servicemeldung hast Du wo der Fehler auftritt?

[sigi234]

@Kaschi68

Bitte benutzt die Code Tags Funktion -> </>
Hier gehts zur Hilfe.

[Kaschi68]

@cash

Also egal welche Servicemeldung ausgelöst wird, LOWBAT, UNREACH, ERROR usw. wird über pushover.3, also Prio = 0 verschickt.
Wie gesagt, deaktiviere ich 1.62 und aktiviere 1.20 bekomme ich die Meldungen über mehrere Instanzen.

Danke und schönen Abend

[cash]

@Kaschi68 Ok kann den Fehler bestätigen. Mit der nächsten Version ist er dann hoffentlich weg....

[Kaschi68]

@cash

Klasse, hier noch zwei Batterieaktualisierungen :

let lr3x1 = ['HmIP-RCB1' ,.....
let lr3x2 = ['ALPHA-IP-RBG' ,....

Danke und Gruß.....

[zahnheinrich]

@cash
Habe die neueste Version 1.62 installiert und bekomme wieder den bekannten CUXD Fehler beim Start:

vascript.0	2019-11-21 15:24:12.688	error	(195) at ContextifyScript.Script.runInContext (vm.js:59:29)
javascript.0	2019-11-21 15:24:12.688	error	(195) at script.js.common.Verschiedenes.Fehelermedungen_Allinclusive:2103:5
javascript.0	2019-11-21 15:24:12.688	error	(195) at Servicemeldung (script.js.common.Verschiedenes.Fehelermedungen_Allinclusive:669:20)
javascript.0	2019-11-21 15:24:12.687	error	(195) at Object.result.each (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:808:29)
javascript.0	2019-11-21 15:24:12.687	error	(195) at script.js.common.Verschiedenes.Fehelermedungen_Allinclusive:670:74
javascript.0	2019-11-21 15:24:12.687	error	(195) TypeError: Cannot read property 'common' of null
javascript.0	2019-11-21 15:24:12.687	error	(195) ^
javascript.0	2019-11-21 15:24:12.687	error	(195) common_name = getObject(id.substring(0, id.lastIndexOf('.') - 2)).common.name;
javascript.0	2019-11-21 15:24:12.686	error	(195) script.js.common.Verschiedenes.Fehelermedungen_Allinclusive: script.js.common.Verschiedenes.Fehelermedungen_Allinclusive:670
javascript.0	2019-11-21 15:24:12.685	warn	(195) Object "hm-rpc.0.CUX2801002" does not exist
javascript.0	2019-11-21 15:24:11.655	info	(195) Start javascript script.js.common.Verschiedenes.Fehelermedungen_Allinclusive

CUXD läuft bei mir unter hm-rpc2.

Im script eingetragen:

//Instanz Cuxd ausschließen. Instanz als Zahl z. B. '1' oder bei Nichtnutzung hohe Nr eintragen z. B. '9'
const CUXD = '2'

Das im log angemeckerte Gerät "hm-rpc.0.CUX2801002" gibt es in der Tat nicht, wohl aber das Gerät "hm-rpc.2.CUX2801002".

[cash]

@zahnheinrich Den Fehler hast Du schon selber gefunden. Ich verstehe nicht was bei Euren System falsch läuft. Wie kann ein cuxd Gerät was es nicht gibt und wofür die Instanz nicht konfiguriert ist angelegt werden? Mach doch mal ein Fehler bei github auf das immer cuxd Geräte angelegt werden die es nicht gibt...

Lösung erstmal Gerät unter der falschen Instanz löschen...

Werde heute Abend noch die aktuelle Version hochladen.

[zahnheinrich]

@cash
wie schon oben geschrieben: Das Gerät existiert NICHT in hm-rpc0 !!

[cash]

@zahnheinrich das hast das Script ermittelt ein Gerät unter der Instanz 0 welches in den Objekten definitiv nicht vorhanden ist? Würde mich jetzt erstmal sehr stark wundern.

Mach mal Screenshots vom Objektbaum von beiden Instanzen? Die Version die Du vorher hattest hat keinen Fehler gemeldet?