NEWS
Test Adapter Device-Watcher v2.x.x GitHub/Latest
-
Aktuelle Test Version Veröffentlichungsdatum 26.05.2022 Github Link https://github.com/ciddi89/ioBroker.device-watcher Test Adapter Device-Watcher
:flag-de: Deutsche Dokumentation
Dies ist ein Watchdog für Geräte/Services und Adapter/Instanzen. Der Adapter sucht nach den verschiedenen Informationen über die Datenpunkte und erstellt JSON & HTML Listen davon:
Geräte/Services:
- Geräte mit Batterie,
- Geräte mit niedrigem Batteriestand,
- Geräte mit Verbindungsqualität,
- Updates für Geräte, (only shelly & unifi yet)
- Geräte offline
- alle Geräte
- und eine Raw-Liste mit allen verfügbaren Daten der oben genannten Liste.
Adapter/Instanzen:
- verfügbare Adapter Updates
- Alle Instanzen
- Ausgefallene Instanzen
- Deaktivierte Instanzen
Außerdem werden sie in denselben Kategorien gezählt. Die Listen und Zählungen können zum Beispiel für Grafana, Jarvis usw. verwendet werden.
Unterstützte Adapter:
Eine Liste mit den unterstützten Adaptern und welche Information pro Adapter genutzt werden / möglich sind, findest du in der Github Doku.
Benachrichtigungen:
Der Adapter hat verschiedene Möglichkeiten, Benachrichtigungen zu senden:
- Ein Gerät ist nicht mehr erreichbar oder wieder erreichbar
- Ein Gerät hat den niedrigen Batteriestand erreicht oder der Low-Bat-Status ist true
- Wenn ein Update für ein Gerät verfügbar ist (shelly und unifi)
- Zeitbasiert eine Liste der Offline-Geräte
- Zeitbasierte Liste von Geräten mit niedrigem Batteriestand
- Zeitbasiert eine Liste der Geräte, die aktualisiert werden können
Derzeitige Unterstützte Adapter für Benachrichtigungen:
- Telegram
- Pushover
- Jarvis
- Lovelace
- Signal
- SynoChat
- und einen Datenpunkt mit der zuletzt gesendeten Benachrichtigung.
Blacklist
Ist es notwendig, ein bestimmtes Gerät/Service oder Instanz zu ignorieren, kann es auf die schwarze Liste gesetzt werden und der Device-Watcher ignoriert es.
Es ist möglich zu wählen:- In Benachrichtigungen ignorieren
- In der Hauptliste ignorieren
- In den eigenen Listen der Adapter ignorieren
Feature Request & Bug Report
Ich bitte euch der Übersicht halber Fehler und Feature Request auf der Githubseite zu erstellen.
Seht Ihr dort ein Feature Request und euch gefällt die Idee, könnt Ihr auch dafür abstimmen. Dann sehe ich bei einigen Dingen, wo ich mir nicht sicher bin ob es Sinnvoll wäre oder nicht, ob überhaupt Interesse an sowas besteht.
Wählt dafür einfach einen von den Emojis aus:
Screenshots und weitere Informationen finder Ihr auf der Githubseite.
Hallo, ich bin gerade dabei einmal den Device Watcher korrekt in meiner Jarvis Oberfläche zu intregieren. Dabei ist mir jetzt einmal aufgefallen, dass meine Netatmo Geräte als "Offline" markiert sind. Aber der letzte Zeitstempel ist wirklich super aktuell und die Geräte sind definitiv online. Was wird hierfür denn von dem DeviceWatcher Adapter abgefragt ? Das gleiche ist meine USV über den NUT Adapter.
Des weiteren sind bei meinem HM-RPC Adapter die Battlevel nur als Volt ausgegeben. Somit passt natürlich die Sortierung nicht. Ich könnte natürlich die Spannung über Blockly umrechenen. Aber wie bekomme ich diese denn in DeviceWatcher intrigiert ? Konnte jetzt so hier nichts auf die schnelle finden ?
Hat da jemand einen Tipp für mich ? Danke und schönen Sonntag

-
das wir von netatmo überwacht
netatmo: { adapterKey: 'netatmoDevices', selektor: 'netatmo.*.LastUpdate', timeSelector: '.LastUpdate', adapterID: 'netatmo', adapter: 'Netatmo', rssiState: '.WifiStatus', rfState: '.RfStatus', battery: '.BatteryStatus', reach: 'none', isLowBat: 'none', },und HM-RPC ist ne Sonderlocke im code vom feinsten.. hab die Teile nicht hier. kein plan was die liefern
das wird da überwacht.. aber es sind viele interne Regeln noch dazu
hmrpc: { adapterKey: 'hmrpcDevices', selektor: 'hm-rpc.*.RSSI_PEER', timeSelector: '.UNREACH', adapterID: 'hmrpc', adapter: 'Homematic RPC', rssiState: '.RSSI_DEVICE', rssiPeerState: '.RSSI_PEER', battery: '.OPERATING_VOLTAGE', reach: '.UNREACH_ALARM', isLowBat: '.LOW_BAT_ALARM', isLowBat2: '.LOWBAT_ALARM', isLowBat3: '.LOW_BAT', stateValue: '.1.STATE', faultReporting: '.4.FAULT_REPORTING', hmDNBattery: '.4.BATTERY_STATE', upgrade: '.UPDATE_PENDING_ALARM', }, -
@arteck Wo finde ich diese Definition?
Ok, hab downgegraded.

Offensichtlich waren die Last seen Werte auch schon so hoch jedoch in Tagen angegeben.Korrekt ist es dennoch nicht dass die Geräte zu dieser Zeit das letzt mal gesehen worden.
@Rushmed so hab mir die hue Problemtik mal angeschaut..
na ja das problem ist der reachable wird nur einmalig bei lampe ist da = true oder nicht = false aktualisiert.. im hue adapter
wenn der hue adapter zuletzt vor 300 Tagen aktualisert hat reachable = true ..dann ist die Lampe seid 300 Tagen erreichbar..
und es gab keine Statusänderung.. somit errechnet der device-watcher das was im timestamp steht (ok Stunden oder Tage ist jetzt egal)der reachable status aktualisiert sich nicht wenn du die Lampe schaltest (so wie es aussieht.. ist vielleicht ein hue adapter problem)
-
@Rushmed so hab mir die hue Problemtik mal angeschaut..
na ja das problem ist der reachable wird nur einmalig bei lampe ist da = true oder nicht = false aktualisiert.. im hue adapter
wenn der hue adapter zuletzt vor 300 Tagen aktualisert hat reachable = true ..dann ist die Lampe seid 300 Tagen erreichbar..
und es gab keine Statusänderung.. somit errechnet der device-watcher das was im timestamp steht (ok Stunden oder Tage ist jetzt egal)der reachable status aktualisiert sich nicht wenn du die Lampe schaltest (so wie es aussieht.. ist vielleicht ein hue adapter problem)
@arteck Vielen Dank für deine Mühe.
Das ist doch genau was ich gesagt habe.
Für das was der device-watcher mit last seen ausdrücken will ist die Zeit der letzten Aktualiserung von reachable einfach ungeeignet.
Reachable im Hue ist für sich stimmig. Der online Status stimmt. -
@arteck Vielen Dank für deine Mühe.
Das ist doch genau was ich gesagt habe.
Für das was der device-watcher mit last seen ausdrücken will ist die Zeit der letzten Aktualiserung von reachable einfach ungeeignet.
Reachable im Hue ist für sich stimmig. Der online Status stimmt. -
@arteck es ist ja eine Frage der Betrachtungsweise. Wenn sich ein Zustand ändert, dann hat ioBroker das Gerät doch gesehen. Wäre es nicht besser die Zeit von dem State auszugeben, der sich am häufigsten Ändert?
@Hiltex sagte in Test Adapter Device-Watcher v2.x.x GitHub/Latest:
Wäre es nicht besser die Zeit von dem State auszugeben, der sich am häufigsten Ändert?
der da währe ??
@Hiltex sagte in Test Adapter Device-Watcher v2.x.x GitHub/Latest:
Wenn sich ein Zustand ändert, dann hat ioBroker das Gerät doch gesehen.
iobroker ja .. wenn der adapter abne keine aktualisierung für das DP schickt.. dann hab ich da ein 300 Tage ales timestamp..
-
Ich hab jetzt auch schon alles überprüft. Die zur Verfügung stehenden Status betreffen alle irgendwelche tatsächlichen Lampeneinstellungen die ich auch oft lange nicht ändere. Deren Aktualisierung wird dann auch immer Älter obwohl der Online Status bleibt.
Mir persönlich würde es reichen wenn der online Sataus solide funktioniert.
Das tut er nach meinen letzte Tests.Wenn es keine valide Quelle für last seen gibt dann git es diesen Wert eben nicht.
Bei batteriebetriebenen BWMs gibt es noch lastupdated der entspricht aber auch der letzten Bewegungserkennung und nicht dem letzten Kontakt.
-
ja das ist im hue adapter verankert... die zigbee adapter oder zwave aktualisieren die DP's bei jeglicher änderung.. bzw da melden sich die Lampen selbst mit "ich bin noch da"
erstell da ein issue dass der reachable status auch bei jeder änderung egal welcher aktualisiert wird.
-
@Hiltex sagte in Test Adapter Device-Watcher v2.x.x GitHub/Latest:
Wäre es nicht besser die Zeit von dem State auszugeben, der sich am häufigsten Ändert?
der da währe ??
@Hiltex sagte in Test Adapter Device-Watcher v2.x.x GitHub/Latest:
Wenn sich ein Zustand ändert, dann hat ioBroker das Gerät doch gesehen.
iobroker ja .. wenn der adapter abne keine aktualisierung für das DP schickt.. dann hab ich da ein 300 Tage ales timestamp..
@arteck kann sein, dass ich mir das zu leicht vorstelle, aber mein Gedanke wäre folgender:
Der OnlineSTATUS wird wie bisher von Reachable abhängig gemacht. Die Zeit des letzten Kontaktes wird aber vom On/Off-State genutzt. Oder im Falle einer dimmbaren Lampe von Level. Bei beiden gehe ich davon aus, dass die sich am häufigsten ändern.
Für mich persönlich wäre die Anzeige des letzten Kontakts in einer Liste nicht von Bedeutung. Erst wenn ein Gerät als offline betrachtet wird ist für mich interessant, dann ioBroker zuletzt von dem Gerät gehört hat. In dieser Variante wäre es auch nicht nötig, zusätzliche States zu abonnieren.
-
@arteck kann sein, dass ich mir das zu leicht vorstelle, aber mein Gedanke wäre folgender:
Der OnlineSTATUS wird wie bisher von Reachable abhängig gemacht. Die Zeit des letzten Kontaktes wird aber vom On/Off-State genutzt. Oder im Falle einer dimmbaren Lampe von Level. Bei beiden gehe ich davon aus, dass die sich am häufigsten ändern.
Für mich persönlich wäre die Anzeige des letzten Kontakts in einer Liste nicht von Bedeutung. Erst wenn ein Gerät als offline betrachtet wird ist für mich interessant, dann ioBroker zuletzt von dem Gerät gehört hat. In dieser Variante wäre es auch nicht nötig, zusätzliche States zu abonnieren.
-
@arteck kann sein, dass ich mir das zu leicht vorstelle, aber mein Gedanke wäre folgender:
Der OnlineSTATUS wird wie bisher von Reachable abhängig gemacht. Die Zeit des letzten Kontaktes wird aber vom On/Off-State genutzt. Oder im Falle einer dimmbaren Lampe von Level. Bei beiden gehe ich davon aus, dass die sich am häufigsten ändern.
Für mich persönlich wäre die Anzeige des letzten Kontakts in einer Liste nicht von Bedeutung. Erst wenn ein Gerät als offline betrachtet wird ist für mich interessant, dann ioBroker zuletzt von dem Gerät gehört hat. In dieser Variante wäre es auch nicht nötig, zusätzliche States zu abonnieren.
@Hiltex sagte in Test Adapter Device-Watcher v2.x.x GitHub/Latest:
Erst wenn ein Gerät als offline betrachtet wird ist für mich interessant
hoffentlich übermittelt das der hue adapter.. nochmal device-watcher wertet nur das aus was der einzelne adapter anliefert plsu wasn es zuletzt gelifert wurde.. die Information ist so alt wie der adapter es in den entsprechenden DP geschrieben hat
bei Lampe on/off/level.. ja kann da stimmt.. und bei Dimmer .. batterie betrieben .. und bei BWM und weiss was ich was da sonst noch gibt.. es muss der haue adapter liefern.. ich werde nicht eine litanei an sonderfindungsregeln einbauen in den device-watcher.. das wird dann unwartbar..
@Rushmed ja bei nächsten Statusänderung (egal ob true oder false).. du kannst dir ein script schreiben der dir den DP bestätigt, alle was weiss ich x minuten oder stunden.. dann hast du auch was aktuelles in der liste stehen wenn dir die liste wichtig ist
schraub doch mal so ne birne raus und guck was passiert vor allem wann es passiert -
Hab' mal in Git Issue beim HUE Adapter erstellt.
https://github.com/iobroker-community-adapters/ioBroker.hue/issues/826