NEWS
[Javascript] Adapter-Instanzen überwachen
-
Update 14.07.2022:
Hier der Link zum Projekt und Quellcode:
Acgua/ioBroker-Script-Adapter-Instances-Watcher
Ursprüngliche Nachricht vom 26. Juni 2022:
Hi,
ich habe ein Script geschrieben, das ich gedenke, zu veröffentlichen.
Vom Aufbau her gleich in Klassen etc., damit im Fall leicht überführbar in einen Adapter, diesen würde ich aber dann erweitern und auch andere Dinge mit überwachen etc.Frage an euch: Besteht überhaupt Interesse daran? Habt ihr auch diesen Use Case? Denn nur dann mache ich mir die weitere Mühe, das Script "schön" und sicher zu machen, und zu veröffentlichen.
Unten die Erklärung, die ich auch schon mal auf Github angefangen habe, hier noch mit paar Screenshots.
Warum dieses Script? Use Case?
Der Auslöser für mich für dieses Script war, dass ich zuverlässig Datenpunkte brauchte, die mir anzeigen, ob eine Adapter-Instanz "läuft".
Nur so einfach ist das ganze nicht:
Es gibt hauptsächlich Daemon-Adapter und Schedule-Adapter (Link, aber auch weitere, die ich hier aber nicht näher betrachte.Daemon-Adapter sind etwa alexa2, cloud, hue. Schedule-Adapter sind z.B. daswetter, feiertage, ical.
Ob ein Daemon-Adapter läuft, sieht man in den Datenpunkten (Beispiel: cloud, Instanz 0)
system.adapter.cloud.0.aliveundsystem.adapter.cloud.0.connected. Außerdem noch über die Objekteigenschaften vonsystem.adapter.cloud.0, dort zeigtcommon:enabledan, ob die Instanz überhaupt ein- oder ausgeschaltet ist. Zudem bauen noch manche Adapter eine Verbindung zu einem Gerät oder Service auf, hier gibt es dann etwa noch den Datenpunktcloud.0.info.connection. Dies machen aber nicht alle Daemon-Adapter.Schedule-Adapter verhalten sich ganz anders. Diese werden gemäß Zeitplan ("Schedule") regelmäßig neu gestartet und rufen dann z.B. Wetterdaten ab, also etwa im Fall vom Adapter daswetter. Um hier zu wissen, ob der Adapter "aktiv und zuverlässig läuft", ist es wichtig, dass der Adapter angeschaltet ist (sichtbar über Objekteigenschaften von
system.adapter.daswetter.0,common:enabledauftrue), und dass der letzte Zeitplan auch gelaufen ist. Wir wollen schließlich keine alten Wetterdaten am Tablet sehen.Was macht nun dieses Script?
Kurz zusammengefasst:
-
Für jede Adapter-Instanz gibt es u.a. einen Datenpunkt wie etwa
0_userdata.0.System.Adapter-Instanzen.cloud_0.isFunctioning, der auftruegesetzt ist, sobald Instanz eingeschaltet und verbunden ist, und auch – falls Verbindung mit Gerät/Service – auch diese Verbindung steht. Dies bei Daemon-Adapter, bei Schedule-Adapter wird geprüft, ob die Instanz eingeschaltet ist und der letzte Zeitplan (Cron, also Schedule) gelaufen ist.
Beispiel für Daemon-Adapter cloud:
Beispiel für Schedule-Adapter daswetter:
-
Des weiteren gibt es noch eine Zusammenfassung in Datenpunkten, also Liste aller Instanzen, die zwar eingeschaltet sind, aber nicht "laufen", als auch einen Datenpunkt für die Anzahl dieser eingeschalteten, aber nicht laufenden Instanzen.
-
Weiteres wird nach und nach eingebaut, wie einfaches ein- und ausschalten, etc. (was sich bei Schedule-Adapter wieder anders verhält, als bei Daemon-Adapter).
-
-
Update 14.07.2022:
Hier der Link zum Projekt und Quellcode:
Acgua/ioBroker-Script-Adapter-Instances-Watcher
Ursprüngliche Nachricht vom 26. Juni 2022:
Hi,
ich habe ein Script geschrieben, das ich gedenke, zu veröffentlichen.
Vom Aufbau her gleich in Klassen etc., damit im Fall leicht überführbar in einen Adapter, diesen würde ich aber dann erweitern und auch andere Dinge mit überwachen etc.Frage an euch: Besteht überhaupt Interesse daran? Habt ihr auch diesen Use Case? Denn nur dann mache ich mir die weitere Mühe, das Script "schön" und sicher zu machen, und zu veröffentlichen.
Unten die Erklärung, die ich auch schon mal auf Github angefangen habe, hier noch mit paar Screenshots.
Warum dieses Script? Use Case?
Der Auslöser für mich für dieses Script war, dass ich zuverlässig Datenpunkte brauchte, die mir anzeigen, ob eine Adapter-Instanz "läuft".
Nur so einfach ist das ganze nicht:
Es gibt hauptsächlich Daemon-Adapter und Schedule-Adapter (Link, aber auch weitere, die ich hier aber nicht näher betrachte.Daemon-Adapter sind etwa alexa2, cloud, hue. Schedule-Adapter sind z.B. daswetter, feiertage, ical.
Ob ein Daemon-Adapter läuft, sieht man in den Datenpunkten (Beispiel: cloud, Instanz 0)
system.adapter.cloud.0.aliveundsystem.adapter.cloud.0.connected. Außerdem noch über die Objekteigenschaften vonsystem.adapter.cloud.0, dort zeigtcommon:enabledan, ob die Instanz überhaupt ein- oder ausgeschaltet ist. Zudem bauen noch manche Adapter eine Verbindung zu einem Gerät oder Service auf, hier gibt es dann etwa noch den Datenpunktcloud.0.info.connection. Dies machen aber nicht alle Daemon-Adapter.Schedule-Adapter verhalten sich ganz anders. Diese werden gemäß Zeitplan ("Schedule") regelmäßig neu gestartet und rufen dann z.B. Wetterdaten ab, also etwa im Fall vom Adapter daswetter. Um hier zu wissen, ob der Adapter "aktiv und zuverlässig läuft", ist es wichtig, dass der Adapter angeschaltet ist (sichtbar über Objekteigenschaften von
system.adapter.daswetter.0,common:enabledauftrue), und dass der letzte Zeitplan auch gelaufen ist. Wir wollen schließlich keine alten Wetterdaten am Tablet sehen.Was macht nun dieses Script?
Kurz zusammengefasst:
-
Für jede Adapter-Instanz gibt es u.a. einen Datenpunkt wie etwa
0_userdata.0.System.Adapter-Instanzen.cloud_0.isFunctioning, der auftruegesetzt ist, sobald Instanz eingeschaltet und verbunden ist, und auch – falls Verbindung mit Gerät/Service – auch diese Verbindung steht. Dies bei Daemon-Adapter, bei Schedule-Adapter wird geprüft, ob die Instanz eingeschaltet ist und der letzte Zeitplan (Cron, also Schedule) gelaufen ist.
Beispiel für Daemon-Adapter cloud:
Beispiel für Schedule-Adapter daswetter:
-
Des weiteren gibt es noch eine Zusammenfassung in Datenpunkten, also Liste aller Instanzen, die zwar eingeschaltet sind, aber nicht "laufen", als auch einen Datenpunkt für die Anzahl dieser eingeschalteten, aber nicht laufenden Instanzen.
-
Weiteres wird nach und nach eingebaut, wie einfaches ein- und ausschalten, etc. (was sich bei Schedule-Adapter wieder anders verhält, als bei Daemon-Adapter).
@acgua sagte in [Javascript] Adapter-Instanzen überwachen:
Link: https://github.com/Acgua/ioBroker-Script-Adapter-Instances-Watcher
Synology 918+ 16GB - ioBroker in Docker v9 , VISO auf Trekstor Primebook C13 13,3" , Hikvision Domkameras mit Surveillance Station .. CCU RaspberryMatic in Synology VM .. Zigbee CC2538+CC2592 .. Sonoff .. KNX .. Modbus ..
-
-
@glasfaser
Danke, korrigiert, bzw. entfernt, da alles hier auch schon steht. -
@acgua said in [Javascript] Adapter-Instanzen überwachen:
Der Auslöser für mich für dieses Script war, dass ich zuverlässig Datenpunkte brauchte, die mir anzeigen, ob eine Adapter-Instanz "läuft".
Ich hab dafür ein kleines Blockly nach diesem Muster: machs-smart.de
Und das funktioniert bisher sehr zuverlässig.
Das meldet, wenn eine Instanz nicht mehr läuft. -
Hier das Script:
Github-Projekt, Anleitung: Acgua/ioBroker-Script-Adapter-Instances-Watcher
JS in "Raw": https://raw.githubusercontent.com/Acgua/ioBroker-Script-Adapter-Instances-Watcher/main/adapter-instance-watcher.js
-
Vielen Dank für das Script.Das schaut wirklich klasse aus.
Dann baue ich mir mal meine Telegram Benachrichtigung zusammen (mit Blockly) für den Fall, dass eine Instanz ausgfällt.
Danke für deine Arbeit.
-
Danke für das Skript! Sehr ausführlich und sieht nach viel Arbeit aus. :)
Bei zwei Instanzen hat er ein Fehler ausgespuckt da er für den Datenpunkt
connected_with_device_serviceeinen String bekommt. Habe diese dann händisch von Boolean auf String geändert. Dann meckert er nicht mehr. Der Rest lief/läuft ohne Probleme. -
Danke für das Skript! Sehr ausführlich und sieht nach viel Arbeit aus. :)
Bei zwei Instanzen hat er ein Fehler ausgespuckt da er für den Datenpunkt
connected_with_device_serviceeinen String bekommt. Habe diese dann händisch von Boolean auf String geändert. Dann meckert er nicht mehr. Der Rest lief/läuft ohne Probleme.Vielen Dank für euer Feedback @frana120500 und @ciddi89 !
@ciddi89
Danke für den Logauszug, Problem also bei den Instanzen "admin.0" und "mqtt.0" bezüglich String statt Boolean.
mqtt habe ich derzeit nicht im Einsatz, aber den admin zwangsläufig :grin:Leider kann ich den Fehler bei admin.0 und allen anderen Instanzen nicht reproduzieren.
Für sämtliche Instanzen bekomme ich mit einem log(), eine Zeile vor dem setState(), auf Prüfung der Variable immer ein Boolean, hier als Auszug für admin.0:16:28:03.008 warn javascript.0 (1047) script.js.System.Adapter-Instance-Watcher: [admin.0] Type=[boolean], Value stringified=[true]Könntest du mir bitte einen Gefallen tun und Zeile 396, also
setState(this.path + '.info.connected_with_device_service', {val:this.connected_with_device_service, ack:true});löschen und ersetzen mit:
///// - TEST 1 - 15.07.2022 - https://forum.iobroker.net/post/827939 if (typeof this.connected_with_device_service !== 'boolean') { log(`[${this.id}] connected_with_device_service type error, boolean expected – Type=[${typeof this.connected_with_device_service}], Value stringified=[${JSON.stringify(this.connected_with_device_service)}]`, 'warn'); } else { setState(this.path + '.info.connected_with_device_service', {val:this.connected_with_device_service, ack:true}); } /////////////////////////////////////////////////////////////////Welche Log-Ausgabe bekommst du da? Da sollte jetzt für "admin.0" und "mqtt.0" jeweils eine warn-Logzeile kommen mit Datentyp und Wert.
Welche JavaScript-Adapter-Version setzt du denn ein? Ich aktuell 5.8.10, und bis vor kurzem 5.8.3 / 5.8.5.
Danke!
-
Vielen Dank für euer Feedback @frana120500 und @ciddi89 !
@ciddi89
Danke für den Logauszug, Problem also bei den Instanzen "admin.0" und "mqtt.0" bezüglich String statt Boolean.
mqtt habe ich derzeit nicht im Einsatz, aber den admin zwangsläufig :grin:Leider kann ich den Fehler bei admin.0 und allen anderen Instanzen nicht reproduzieren.
Für sämtliche Instanzen bekomme ich mit einem log(), eine Zeile vor dem setState(), auf Prüfung der Variable immer ein Boolean, hier als Auszug für admin.0:16:28:03.008 warn javascript.0 (1047) script.js.System.Adapter-Instance-Watcher: [admin.0] Type=[boolean], Value stringified=[true]Könntest du mir bitte einen Gefallen tun und Zeile 396, also
setState(this.path + '.info.connected_with_device_service', {val:this.connected_with_device_service, ack:true});löschen und ersetzen mit:
///// - TEST 1 - 15.07.2022 - https://forum.iobroker.net/post/827939 if (typeof this.connected_with_device_service !== 'boolean') { log(`[${this.id}] connected_with_device_service type error, boolean expected – Type=[${typeof this.connected_with_device_service}], Value stringified=[${JSON.stringify(this.connected_with_device_service)}]`, 'warn'); } else { setState(this.path + '.info.connected_with_device_service', {val:this.connected_with_device_service, ack:true}); } /////////////////////////////////////////////////////////////////Welche Log-Ausgabe bekommst du da? Da sollte jetzt für "admin.0" und "mqtt.0" jeweils eine warn-Logzeile kommen mit Datentyp und Wert.
Welche JavaScript-Adapter-Version setzt du denn ein? Ich aktuell 5.8.10, und bis vor kurzem 5.8.3 / 5.8.5.
Danke!
@acgua ja bei allen anderen Instanzen ist es auch der Typ Boolean. Komischerweise hier aber nicht, dort steht auch ein String drin. Javascript Adapter Version ist die 5.7.0. Sollte also die stable sein. Hier die Ausgabe vom Log aus deinem Test:
-
Vielen Dank für das Script.Das schaut wirklich klasse aus.
Dann baue ich mir mal meine Telegram Benachrichtigung zusammen (mit Blockly) für den Fall, dass eine Instanz ausgfällt.
Danke für deine Arbeit.
@frana120500 said in [Javascript] Adapter-Instanzen überwachen:
Dann baue ich mir mal meine Telegram Benachrichtigung zusammen (mit Blockly) für den Fall, dass eine Instanz ausgfällt.
Sag gerne Bescheid, falls du noch zusätzliche Datenpunkte brauchst.
Ich überlege mir da auch noch was sinnvolles.
Gibt ja Adapter, die mal für paar Minuten keine Verbindung mit einem Service haben, aber da möchte man dann nicht ständig Telegram-Messages bekommen.
Außerdem wäre wohl eine Historie sinnvoll, um nachzuvollziehen, wann und wie lange pro Tag eine Instanz nicht "functioning" war. -
@acgua ja bei allen anderen Instanzen ist es auch der Typ Boolean. Komischerweise hier aber nicht, dort steht auch ein String drin. Javascript Adapter Version ist die 5.7.0. Sollte also die stable sein. Hier die Ausgabe vom Log aus deinem Test:
@ciddi89
Danke. Ich wollte auf JS-Adapter 5.7.0 downgraden zum testen, aber bekomme diverse npm errors und klappt nicht... Ich bin immer im Latest unterwegs, mit derzeit Node.js v16.15.1, NPM: 8.11.0, JS-Controller 4.0.23Seltsam jedenfalls, aber das könnte auch ein Bug der 5.7.0 sein, der in nachfolgenden Versionen behoben ist.
Die String-Ausgaben sind jedenfalls interessant, weil diese eigentlich nur boolean sein können:
Der Wert wird abgefragt von z.B.admin.0.info.connection, über
Undadmin.0.info.connectionist boolean.
Muss mir mal was überlegen. Eigentlich nur eine Kleinigkeit, aber nervt jetzt grad :joy:
-
@frana120500 said in [Javascript] Adapter-Instanzen überwachen:
Dann baue ich mir mal meine Telegram Benachrichtigung zusammen (mit Blockly) für den Fall, dass eine Instanz ausgfällt.
Sag gerne Bescheid, falls du noch zusätzliche Datenpunkte brauchst.
Ich überlege mir da auch noch was sinnvolles.
Gibt ja Adapter, die mal für paar Minuten keine Verbindung mit einem Service haben, aber da möchte man dann nicht ständig Telegram-Messages bekommen.
Außerdem wäre wohl eine Historie sinnvoll, um nachzuvollziehen, wann und wie lange pro Tag eine Instanz nicht "functioning" war. -
@acgua Historie wäre geil, dann könnte man eventuelle Fehlerquellen zeitlich eingrenzen
@frana120500
cool, dachte ich mir auch, dann baue ich das noch ein.Welche JS-Adapter-Version setzt du denn ein? Bekommst du evtl. auch Warnungen wie
You are assigning a string to the state (...) which expects a boolean.im Log? -
@ciddi89
Danke. Ich wollte auf JS-Adapter 5.7.0 downgraden zum testen, aber bekomme diverse npm errors und klappt nicht... Ich bin immer im Latest unterwegs, mit derzeit Node.js v16.15.1, NPM: 8.11.0, JS-Controller 4.0.23Seltsam jedenfalls, aber das könnte auch ein Bug der 5.7.0 sein, der in nachfolgenden Versionen behoben ist.
Die String-Ausgaben sind jedenfalls interessant, weil diese eigentlich nur boolean sein können:
Der Wert wird abgefragt von z.B.admin.0.info.connection, über
Undadmin.0.info.connectionist boolean.
Muss mir mal was überlegen. Eigentlich nur eine Kleinigkeit, aber nervt jetzt grad :joy:
@acgua ja deswegen hat es mich gewundert und darum habe ich den Fehler hier rein gestellt. Für mich persönlich nicht schlimm, wie gesagt hab die zwei Datenpunkte auf String umgeändert. Aber ich weiß wie es ist das so eine Kleinigkeit einen stören kann und man wissen will wieso weshalb warum. Wenn ich später mal Zeit habe schaue ich mir das Skript auch mal in Ruhe an, vielleicht finde ich auch selbst heraus woher es kommen könnte. :)
-
@frana120500
cool, dachte ich mir auch, dann baue ich das noch ein.Welche JS-Adapter-Version setzt du denn ein? Bekommst du evtl. auch Warnungen wie
You are assigning a string to the state (...) which expects a boolean.im Log?@acgua Hi, ich nutze den Script Adapter in Version 5.8.10... also die letzte Beta
Ich bekomme aufgrund des Sonoff und des MQTT Adapters die folgenden Fehlermeldungen:
You are assigning a string to the state "0_userdata.0.System.Adapter-Instanzen.sonoff_0.info.connected_with_device_service" which expects a boolean. Please fix your code to use a boolean or change the state type to string. This warning might become an error in future versions.
You are assigning a string to the state "0_userdata.0.System.Adapter-Instanzen.mqtt_0.info.connected_with_device_service" which expects a boolean. Please fix your code to use a boolean or change the state type to string. This warning might become an error in future versions. -
@acgua Hi, ich nutze den Script Adapter in Version 5.8.10... also die letzte Beta
Ich bekomme aufgrund des Sonoff und des MQTT Adapters die folgenden Fehlermeldungen:
You are assigning a string to the state "0_userdata.0.System.Adapter-Instanzen.sonoff_0.info.connected_with_device_service" which expects a boolean. Please fix your code to use a boolean or change the state type to string. This warning might become an error in future versions.
You are assigning a string to the state "0_userdata.0.System.Adapter-Instanzen.mqtt_0.info.connected_with_device_service" which expects a boolean. Please fix your code to use a boolean or change the state type to string. This warning might become an error in future versions.@frana120500
Danke. Auch noch mal an @ciddi89 für deine Rückinfo.Dann muss ich mir das die Tage mal näher ansehen, gerade weil es auch im Latest (5.8.10) vorkommt, das ist sehr wichtig zu wissen.
Ich habe nur beschränkt Zeit, daher brauche ich ggf. ein paar Tage, also bitte nicht wundern, aber ich kümmere mich darum.
Ist nur eine Kleinigkeit und eher ein "Schönheitsfehler", weil sonst ja alles läuft, aber nervt mich :grin: und werde ich lösen, also die Ursache. -
@frana120500
Danke. Auch noch mal an @ciddi89 für deine Rückinfo.Dann muss ich mir das die Tage mal näher ansehen, gerade weil es auch im Latest (5.8.10) vorkommt, das ist sehr wichtig zu wissen.
Ich habe nur beschränkt Zeit, daher brauche ich ggf. ein paar Tage, also bitte nicht wundern, aber ich kümmere mich darum.
Ist nur eine Kleinigkeit und eher ein "Schönheitsfehler", weil sonst ja alles läuft, aber nervt mich :grin: und werde ich lösen, also die Ursache.@acgua hehe ja gerne doch. Mach dir kein Stress, wie du schon sagst: es ist nur ein Schönheitsfehler. Und ich kenne das nur zu gut mit der Zeit. Das Problem habe ich und viele andere auch hier.😬 Falls ich vorher schon was finde, gebe ich dir natürlich Bescheid. :)
-
@acgua hehe ja gerne doch. Mach dir kein Stress, wie du schon sagst: es ist nur ein Schönheitsfehler. Und ich kenne das nur zu gut mit der Zeit. Das Problem habe ich und viele andere auch hier.😬 Falls ich vorher schon was finde, gebe ich dir natürlich Bescheid. :)
@ciddi89 und @frana120500
Ich habe nun Version 0.0.2 veröffentlicht, Änderung:- Acgua – Workaround aufgrund Issue #1 eingebaut. In manchen ioBroker-Umgebungen scheint die Abfrage von
admin.0.info.connection(sowie bisher identifizierte Adapter mqtt und sonoff) kein Boolean zurückzugeben, sondern ein String wie etwa[2]admin, javascript. Ich kann es nicht reproduzieren aber habe ein Workaround eingebaut. Bei Ausgabe eines Strings (Länge > 1) wird angenommen, dass eine Verbindung besteht.
Hier übrigens die Änderungen im Script:
https://github.com/Acgua/ioBroker-Script-Adapter-Instances-Watcher/commit/08b171e5a93995eab65d9400bc049cc25760e382Link zum Projekt: https://github.com/Acgua/ioBroker-Script-Adapter-Instances-Watcher
- Acgua – Workaround aufgrund Issue #1 eingebaut. In manchen ioBroker-Umgebungen scheint die Abfrage von
-
@ciddi89 und @frana120500
Ich habe nun Version 0.0.2 veröffentlicht, Änderung:- Acgua – Workaround aufgrund Issue #1 eingebaut. In manchen ioBroker-Umgebungen scheint die Abfrage von
admin.0.info.connection(sowie bisher identifizierte Adapter mqtt und sonoff) kein Boolean zurückzugeben, sondern ein String wie etwa[2]admin, javascript. Ich kann es nicht reproduzieren aber habe ein Workaround eingebaut. Bei Ausgabe eines Strings (Länge > 1) wird angenommen, dass eine Verbindung besteht.
Hier übrigens die Änderungen im Script:
https://github.com/Acgua/ioBroker-Script-Adapter-Instances-Watcher/commit/08b171e5a93995eab65d9400bc049cc25760e382Link zum Projekt: https://github.com/Acgua/ioBroker-Script-Adapter-Instances-Watcher
@acgua danke, hab die neue Version gleich ausprobiert. :) Vielen dank für die Arbeit. Das log sieht nun so aus:
- Acgua – Workaround aufgrund Issue #1 eingebaut. In manchen ioBroker-Umgebungen scheint die Abfrage von
Support us
559
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge