UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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?

[zahnheinrich]

@cash
Habe das script nochmal neu gestartet.
Jetzt meckert er nicht mehr das nicht vorhandene Gerät an, sondern:

javascript.0	2019-11-21 18:35:54.267	error	(4347) at ContextifyScript.Script.runInContext (vm.js:59:29)
javascript.0	2019-11-21 18:35:54.266	error	(4347) at script.js.common.Verschiedenes.Fehelermedungen_Allinclusive:2103:5
javascript.0	2019-11-21 18:35:54.266	error	(4347) at Servicemeldung (script.js.common.Verschiedenes.Fehelermedungen_Allinclusive:669:20)
javascript.0	2019-11-21 18:35:54.266	error	(4347) at Object.result.each (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:808:29)
javascript.0	2019-11-21 18:35:54.265	error	(4347) at script.js.common.Verschiedenes.Fehelermedungen_Allinclusive:674:76
javascript.0	2019-11-21 18:35:54.265	error	(4347) TypeError: Cannot read property 'TYPE' of undefined
javascript.0	2019-11-21 18:35:54.264	error	(4347) ^
javascript.0	2019-11-21 18:35:54.264	error	(4347) native_type = getObject(id.substring(0, id.lastIndexOf('.') - 2)).native.TYPE;
javascript.0	2019-11-21 18:35:54.263	error	(4347) script.js.common.Verschiedenes.Fehelermedungen_Allinclusive: script.js.common.Verschiedenes.Fehelermedungen_Allinclusive:674
javascript.0	2019-11-21 18:35:53.008	info	(4347) Start javascript script.js.common.Verschiedenes.Fehelermedungen_Allinclusive

Bei mir läuft übrigens js-contoller 2.1.0,
alle Adapter up to date.

In der alten Version kam auch ein Fehler im Zusammenhang mit CuxD.
Hatte daher das script disabled und wollte jetzt mit der neuen Version einen neuen Anlauf nehmen.

[cash]

@zahnheinrich Bitte mal aktuelle Version von gitub verwenden. Die wird das Problem vermutlich nicht lösen.

Wenn der Fehler dort noch auftaucht. Script stoppen. hm.0 Adapter stoppen. Alle Objekte unter hm.0 löschen und Script starten. Wenn der Fehler dann auftritt bitte Log. Wenn nicht. Script stoppen.Adapter starten und wenn alle Objekte wieder angelegt sind das Script starten. Wenn der Fehler dann noch auftritt brauche ich das Log und Screenshots...

@All Neue Version auf github. Behebt die Probleme der vergangen Tage also Push immer mit Prio 0 und Batterieupdate

[Kaschi68]

@cash

Hallo, gerade mal den neuen Script gestartet. Dann in den Objekten den Status bei LOWBATT auf "1" geändert. Push kommt nach wie vor bei mir nur in Prio 0 an. Obwohl LOWBAT bei mir auf Prio 2 steht.

Kann das am JS-Controller liegen ?

Danke und Gruß

[cash]

@Kaschi68 Lösch mal die Zeile 1989. (Da sollte prio = 0; stehen) Derzeit ist der Fehler nur unter bestimmten Konstelationen behoben :-).

Ich denke wenn Du die löscht könnte es gehen. Ansonsten müsste ich nochmal ein paar Log Einträge einbauen

[Kaschi68]

@cash

Hallo,
habe Zeile 1989 gelöscht. LOWBAT kam dann in Prio 2 wie es sein soll. Aber auch alle nachfolgenden von Prio 0 z.B. UNREACH kommen in Prio 2 :-(.

//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;