NEWS
Test Adapter staleguard v0.1.x
-
GitHub: https://github.com/typhosj/ioBroker.staleguard
npm: https://www.npmjs.com/package/iobroker.staleguard
Aktuelle Version: 0.1.1, im Latest-RepositoryWorum geht es?
Staleguard meldet, wenn ein State keine Daten mehr bekommt. Du markierst einen beliebigen State im Objektbrowser und gibst ihm eine Frist. Bleibt der State länger still, erzeugt Staleguard eine ioBroker-Benachrichtigung, kann die Adapter-Instanz neu starten, zu der der State gehört, und meldet, wenn wieder Daten kommen.
Staleguard überwacht States, nicht Geräte oder Adapter. Es funktioniert deshalb mit jedem Adapter und auch mit eigenen Skripten. Typische Fälle:
- ein Cloud-Adapter hält
info.connectionauftrue, aber die Werte bewegen sich nicht mehr - ein Shelly-, Zigbee- oder Funksensor meldet sich nicht mehr
- ein Skript schreibt seinen Heartbeat-State nicht mehr
Installation
Repository Latest einstellen, dann unter Adapter nach „staleguard“ suchen und installieren.
Voraussetzungen: Node.js >= 22, js-controller >= 6.0.11, Admin >= 7.6.20.Einrichtung
- Instanz anlegen. Die Standardeinstellungen passen für die meisten Systeme.
- Unter Objekte beim gewünschten State auf das Zahnrad (benutzerdefinierte Einstellungen) klicken und im Abschnitt
staleguard.0Aktiviert einschalten. - Felder setzen:
- Frist (min): 1–10080, Standard 60. Alarm, wenn so lange kein Lebenszeichen kommt.
- Lebenszeichen: Jede Aktualisierung (
ts) oder Wertänderung (lc). - Instanz-Neustarts pro Ausfall: 0–5, Standard 0 (aus).
Faustregel für das Lebenszeichen: Sensoren und Skripte mit Jede Aktualisierung. Cloud-Adapter schreiben oft bei jeder Abfrage denselben Wert mit neuem Zeitstempel; eingefrorene Cloud-Daten fallen deshalb nur mit Wertänderung auf. Werte, die lange gleich bleiben dürfen (PV-Leistung nachts), dann besser über einen Zeitstempel aus der Cloud selbst (
lastSeeno. ä.) überwachen.Die Benachrichtigungen erscheinen im Admin. Weiterleitung an Telegram, E-Mail usw. übernimmt der notification-manager; Staleguard selbst verschickt nichts.
Alle Details stehen in der README.
Was ich gern getestet hätte
- Erkennung: Wird ein stiller State zuverlässig gemeldet, und kommt die Meldung „wieder da“, wenn Daten zurückkehren?
- Viele States auf einmal: Fällt ein Gateway mit vielen Sensoren aus, sollte pro Prüfung eine Sammelmeldung kommen, nicht eine pro State.
- Instanz-Neustart: Funktioniert er mit deinem Adapter? Besonders interessant sind Adapter im Schedule-Modus und Adapter, die nach dem Neustart lange zum Verbinden brauchen.
- Falschalarme: Gibt es States, bei denen keiner der beiden Modi passt?
- Texte: Sind die Meldungen und die Einstellungsseite verständlich?
Rückmeldungen
Fehler bitte als GitHub-Issue, gern auch hier im Thread. Hilfreich sind:
- Version von Staleguard, js-controller und Node.js
- die Einstellungen der betroffenen Watch
- das Log der Instanz
staleguard.0, am besten auf Log-Leveldebug
Danke fürs Testen!
- ein Cloud-Adapter hält
-
GitHub: https://github.com/typhosj/ioBroker.staleguard
npm: https://www.npmjs.com/package/iobroker.staleguard
Aktuelle Version: 0.1.1, im Latest-RepositoryWorum geht es?
Staleguard meldet, wenn ein State keine Daten mehr bekommt. Du markierst einen beliebigen State im Objektbrowser und gibst ihm eine Frist. Bleibt der State länger still, erzeugt Staleguard eine ioBroker-Benachrichtigung, kann die Adapter-Instanz neu starten, zu der der State gehört, und meldet, wenn wieder Daten kommen.
Staleguard überwacht States, nicht Geräte oder Adapter. Es funktioniert deshalb mit jedem Adapter und auch mit eigenen Skripten. Typische Fälle:
- ein Cloud-Adapter hält
info.connectionauftrue, aber die Werte bewegen sich nicht mehr - ein Shelly-, Zigbee- oder Funksensor meldet sich nicht mehr
- ein Skript schreibt seinen Heartbeat-State nicht mehr
Installation
Repository Latest einstellen, dann unter Adapter nach „staleguard“ suchen und installieren.
Voraussetzungen: Node.js >= 22, js-controller >= 6.0.11, Admin >= 7.6.20.Einrichtung
- Instanz anlegen. Die Standardeinstellungen passen für die meisten Systeme.
- Unter Objekte beim gewünschten State auf das Zahnrad (benutzerdefinierte Einstellungen) klicken und im Abschnitt
staleguard.0Aktiviert einschalten. - Felder setzen:
- Frist (min): 1–10080, Standard 60. Alarm, wenn so lange kein Lebenszeichen kommt.
- Lebenszeichen: Jede Aktualisierung (
ts) oder Wertänderung (lc). - Instanz-Neustarts pro Ausfall: 0–5, Standard 0 (aus).
Faustregel für das Lebenszeichen: Sensoren und Skripte mit Jede Aktualisierung. Cloud-Adapter schreiben oft bei jeder Abfrage denselben Wert mit neuem Zeitstempel; eingefrorene Cloud-Daten fallen deshalb nur mit Wertänderung auf. Werte, die lange gleich bleiben dürfen (PV-Leistung nachts), dann besser über einen Zeitstempel aus der Cloud selbst (
lastSeeno. ä.) überwachen.Die Benachrichtigungen erscheinen im Admin. Weiterleitung an Telegram, E-Mail usw. übernimmt der notification-manager; Staleguard selbst verschickt nichts.
Alle Details stehen in der README.
Was ich gern getestet hätte
- Erkennung: Wird ein stiller State zuverlässig gemeldet, und kommt die Meldung „wieder da“, wenn Daten zurückkehren?
- Viele States auf einmal: Fällt ein Gateway mit vielen Sensoren aus, sollte pro Prüfung eine Sammelmeldung kommen, nicht eine pro State.
- Instanz-Neustart: Funktioniert er mit deinem Adapter? Besonders interessant sind Adapter im Schedule-Modus und Adapter, die nach dem Neustart lange zum Verbinden brauchen.
- Falschalarme: Gibt es States, bei denen keiner der beiden Modi passt?
- Texte: Sind die Meldungen und die Einstellungsseite verständlich?
Rückmeldungen
Fehler bitte als GitHub-Issue, gern auch hier im Thread. Hilfreich sind:
- Version von Staleguard, js-controller und Node.js
- die Einstellungen der betroffenen Watch
- das Log der Instanz
staleguard.0, am besten auf Log-Leveldebug
Danke fürs Testen!
@typhos Danke, schöne Idee, dass die Überwachung am State hängt und nicht am Gerät. Ich habe kurz in den Code geschaut, der ist sauber aufgebaut (Sammelmeldungen pro Prüfung, Neustart über
common.enabledwie im Admin, alias/0_userdata vom Neustart ausgenommen).Zwei Punkte:
- Wer einen Heartbeat-State von
javascript.0überwacht und Neustarts einschaltet, startet damit die komplette JS-Instanz mit allen Skripten neu. Das würde ich in der README und am besten direkt als Hinweis auf der Einstellungsseite erwähnen. Sonst wundert sich jemand, warum wegen eines hängenden Skripts plötzlich alle anderen neu starten. - Im Schedule-Modus heißt "Neustart" nur, dass der Adapter einmal außerplanmäßig läuft. Die Frist sollte also deutlich größer sein als das Schedule-Intervall, sonst gibt es Fehlalarme. Ein Satz dazu in der README hilft den Testern.
Wenn die ersten Rückmeldungen gut sind, kannst du später den Antrag für stable stellen. Vorher lohnt sich ein Blick in den Adapter-Check: https://adapter-check.iobroker.in/
- ein Cloud-Adapter hält
-
@Bluefox Danke fürs Reinschauen und für die beiden Hinweise.
Zum Neustart von
javascript.0: In der README steht das schon, auf der Einstellungsseite noch nicht. Der Hilfetext unter „Instanz-Neustarts pro Ausfall“ sagt jetzt, dass immer die ganze Instanz neu startet, beijavascript.0also alle Skripte.Zum Schedule-Modus: Die README empfiehlt jetzt, die Frist deutlich über das Schedule-Intervall zu legen, weil sonst schon die normale Pause zwischen zwei Läufen einen Alarm auslöst.
Beides kommt mit der nächsten Version. Den Adapter-Check lasse ich vor dem Antrag für stable noch laufen.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden