Test Adapter Device-Watcher v2.x.x GitHub/Latest

[A Former User]

@brainbug super danke. Im Prinzip funktionieren Adaptern die mit "reachable" oder "present" arbeiten schonmal. Muss es jetzt aber ein bisschen umbauen da diese Datenpunkt ja schon sagen ob ein Gerät erreichbar ist oder nicht. Wenn ich es soweit umgebaut habe das es für mich passt gebe ich euch bescheid

[frankthegreat]

@ciddi89 sagte in Test Adapter Device-Watcher v0.0.x GitHub/Latest:

@brainbug ist evtl. der Datenpunkt present dafür da ob das Gerät erreichbar ist oder nicht?

Jepp, „present“ ist für die Erreichbarkeit. Steht auch so auf GIthub.

[A Former User]

Ich hatte es bisher noch nie das ein DECT Gerät nicht mehr erreichbar war. Und die Frage ist natürlich wie weit du mit den unterstützen Geräten gehen möchtest? Was soll alles mit in die Abfrage. Jetzt nicht ernst gemeint: Chromecast, Fullybrowser usw.

[frankthegreat]

@brainbug
Wenn die Batterien vom Thermostat leer sind kommt der DB.
Ok, ich krieg dann eine Pushnachricht von der Fritte.

Aber im Prinzip hast Recht…Erreichbarkeit ist eigentlich sehr stabil.

[A Former User]

@brainbug Für mich ist eigentlich klar das ich nur Adapter aufnehmen möchte die mit Lampen, Steckdosen und diverse Sensoren zu tun haben. Vorzugsweise natürlich Geräte mit Batterien weil es in erster Linie darum gehen sollte das man merkt falls ein Gerät wegen einer leeren Batterie nicht mehr erreichbar ist und Werte usw. nicht mehr liefert. Ich denke alles andere würde einfach den Rahmen sprengen. Aber das wird man mit der Zeit sehen. Gehe aber davon aus das wichtigsten Adaptern schon genannt wurden und daher wird da nicht mehr viel kommen. Aber das wird dann die Zeit zeigen in welche Richtung sich der Adapter hin entwickelt.

[A Former User]

@frankthegreat

Aber im Prinzip hast Recht…Erreichbarkeit ist eigentlich sehr stabil.

Liegt bei mir daran dass ich nur strombetriebene DECT Geräte besitze. Bei Heitzkörper Thermostaten sieht die Sache natürlich anders aus.

[da_Woody]

@ciddi89 sagte in Test Adapter Device-Watcher v0.0.x GitHub/Latest:

Geräte mit Batterien

weils mir gerade auffällt. hab 2 shelly DW im system. garage und werkstattür. die tun mit battery, hab aber [{"Device":"--keine--","Adapter":"","Battery":""}] in den objekten. liegts an der schreibweise?

[A Former User]

@da_woody liegt der rssi Datenpunkt, wenn diese Geräte einen haben, in den sys Ordner?

[da_Woody]

@ciddi89 sorry, nicht bedacht...

unterschiedliche. battery in sensor, rssi im root.

nebenbei, alexa echo? zwar kein rssi, aber online... hab da grad so einen show der mir immer wieder abkackt...

[A Former User]

@da_woody das ding mit Shelly habe ich gefixt. Sollte nun den Batterie wert zeigen. Wäre dir dankbar für eine Rückmeldung. Werde die Tage mal alle restlichen Punkte/Wünsche von euch nach und nach abarbeiten. Mittlerweile sind mir auch selber paar Sachen aufgefallen die noch gefixt werden müssen. Die to-do liste ist also lang.

[A Former User]

@kenny384 Habe Devons hinzugefügt. Bitte Testen ob es auch funktioniert.

An Alle: Ansonsten nutzen Homematic Geräte und Deconz jetzt ihre eigenen reachable States. Und gerade bei Homematic sollte daher die Falschmeldungen nun ausbleiben. Zusätzlich werden Homematic Geräte nicht mehr zu den Geräten mitgezählt wegen zu niedriger Batterie. Werde die Tage das noch umschreiben das diese dann ihre eigenen Low_Bat States nutzen.

[da_Woody]

@ciddi89 [{"Device":"Tür","Adapter":"Shelly","Battery":"100%"},{"Device":"Tor","Adapter":"Shelly","Battery":"100%"}]
beide da!

[arteck]

@ciddi89 kannst du noch die Tabellen als widget export im ersten post dazu packen... dann ist alles beisamen

ja ich weiss sind nur json tabellen aber für die Einsteiger

und denk an Zwave

[Ronny Gerndt]

Hab heute morgen mal die aktuelle Version aus github installiert und deConz sieht auf den ersten Blick gut aus.
Konnte das Json direkt in Jarvis einbinden und ausgeben. Werde nachher mal noch etwas die Tabelle anpassen aber sonst echt super

In dem Zuge fällt mir auf das ich meine Geräte echt mal sinnvoll benennen muss

Edit:
Was mir dazu gerade noch einfällt, neben der offline Liste wäre denke ich auch eine Liste mit allen Geräten die unter dem Batterielevel liegen ganz nett. Ich würde mir das gerne auf die Visualisierung packen um schnell zu sehen wo bald wieder neue Batterien fällig werden.

[kenny384]

@ciddi89 Danke für die schnelle Umsetzung. Deconz scheint auf den ersten Blick gut zu funktionieren. Er hat direkt die ganzen Stecker meiner Weihnachtsbeleuchtung als unerreichbar angezeigt. So hatte ich auch gleich den ersten Grund due Blacklist zu testen und auch die funktioniert wunderbar .

[A Former User]

@arteck ja ich guck heut Abend eben, vielleicht hab ich Zeit das dann eben zu machen

@Ronny-Gerndt mit der Liste für low bat Geräte werde ich mit rein nehmen.

[david83]

Hallo @ciddi89
Erstmal Danke das du das Thema angepackt hast.
Ich hätte 2 Dinge auf meiner Wunschliste, ist es möglich Geräte im Ping Adapter abzufragen ob diese On oder offline sind? Und könntest du ausser den Benachrichtigungsdiensten wie z.B. Pushover auch ein Datenpunkt unter /device-watcher.0 einfügen der den Benachrichtigungsinhalt enthält? ( Für all diejenigen die andere nicht implementierte Benachrichtigungsdienste nutzen möchten)

Mfg
David

[JLeg]

@ciddi89 prima Adapter, würde bei mir einige gehackte Scripte ersetzen - habe allerdings ein paar Probleme, oder aber ich verstehe ein paar Dinge nur nicht:

• ich bekomme diverse Zigbee-Geräte als "nicht verfügbar" gemeldet, obwohl diese einwandfrei funktionieren, und den "available"-DP auf "true" stehen haben. Lediglich der timestamp genau dieses DP ist oft nicht ganz aktuell. Und bislang ging der DP auch zuverlässig auf "false", wenn das jeweilige Gerät mal wirklich nicht erreichbar war. Liegt vielleicht auch an der Zigbee-Adapter-Version (bin noch auf 1.16.x) - aber vielleicht wäre es eine Option, die Nicht-Erreichbarkeit zu definieren als "DP 'available'=false"? Ggf. optional...
• in der "Blacklist" kann man ja eigentlich keine "Geräte" auswählen, sondern Datenpunkte von Geräten. Fummelt sich der Adapter dann das jeweilige Gerät aus dem DP raus, oder sollte man dann jeweils manuell den DP aus dem Pfad löschen? Oder sollen dort die tatsächlich geprüften DPs ausgewählt werden (available, battery, ...)?

[A Former User]

@jleg Beim Zigbee Adapter nimmt er den State Link_quality. Der Grund war damals das der andere Datenpunkt available nicht immer genau war und daher wird der Zeitstempel vom Datenpunkte Link quality genutzt. Da die Geräte in der Regel zwischen durch sich melden.

Wegen blacklist, das gefällt mir noch nicht so ganz. Könnte zu Fehler anfällig sein wenn der User den falschen Datenpunkt nimmt. Muss noch gucken wie ich es besser umsetze. Aber in der Readme auf GitHub steht auch das man zb bei Zigbee den Datenpunkt „link_quality“ nutzen soll. Das hat den Hintergrund der Adapter nutzt diesen als Hauptpfad und zerlegt den dann und nimmt für die anderen Aufgaben zb link_quality weg und fügt dann battery an usw.

[A Former User]

@ronny-gerndt said in Test Adapter Device-Watcher v0.0.x GitHub/Latest:

Was mir dazu gerade noch einfällt, neben der offline Liste wäre denke ich auch eine Liste mit allen Geräten die unter dem Batterielevel liegen ganz nett. Ich würde mir das gerne auf die Visualisierung packen um schnell zu sehen wo bald wieder neue Batterien fällig werden.

Habe ich mit eingebaut und ist im letzten Upload mit drin

@david83 said in Test Adapter Device-Watcher v0.0.x GitHub/Latest:

Und könntest du ausser den Benachrichtigungsdiensten wie z.B. Pushover auch ein Datenpunkt unter /device-watcher.0 einfügen der den Benachrichtigungsinhalt enthält? ( Für all diejenigen die andere nicht implementierte Benachrichtigungsdienste nutzen möchten)

Der deviceWatcherLog state hat genau dies gemacht. Habe diesen nun umbenannt in lastNotification damit es für die User deutlicher ist.
Ping schreibe ich mir auf. Werde dann gucken ob ich den mit aufnehme.