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

[Ein ehemaliger Benutzer]

@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 .

[Ein ehemaliger Benutzer]

@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, ...)?

[Ein ehemaliger Benutzer]

@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.

[Ein ehemaliger Benutzer]

@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.

[Ein ehemaliger Benutzer]

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

@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

Zwave ist mit drin. Wie meinst du das mit Widget Export für die Tabellen? Meinst du für Vis? Ich selber nutze Grafana um mir das anzuzeigen. Müsste mich dann erst mit Vis beschäftigen

[JLeg]

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

@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.

Hm, für diesen DP gilt bei mir das selbe wie für ‚available‘ - Geräte funktionieren seit 1-2 Jahren einwandfrei, auch wenn der Timestamp dieses DP etwas ausgeleiert sein mag.
Die timestamps der DPs, bei denen sich regelmäßig was tut (sensorwert, voltage etc.) sind i.d.R. aktuell.

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

aus meiner Sicht - warum sollte ein Anwender überhaupt einen DP wählen müssen, wenn es eigentlich ums Gerät geht? Da fände ich sogar besser, wenn man einfach die Device-ID angeben könnte, auch ohne Selectbox…

[Ein ehemaliger Benutzer]

@jleg

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

Hm, für diesen DP gilt bei mir das selbe wie für ‚available‘ - Geräte funktionieren seit 1-2 Jahren einwandfrei, auch wenn der Timestamp dieses DP etwas ausgeleiert sein mag.
Die timestamps der DPs, bei denen sich regelmäßig was tut (sensorwert, voltage etc.) sind i.d.R. aktuell.

Ich stelle es nachher mal Testweise um das er auf den Wert guckt. Bin leider derzeit nicht zuhause um zu Testen wie schnell sich der Datenpunkt ändert wenn ein Gerät offline geht. Aber wenn dieser zuverlässiger ist, nehme ich natürlich diesen.

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

aus meiner Sicht - warum sollte ein Anwender überhaupt einen DP wählen müssen, wenn es eigentlich ums Gerät geht? Da fände ich sogar besser, wenn man einfach die Device-ID angeben könnte, auch ohne Selectbox…

Ich weiß, daher bin ich auch noch nicht damit zufrieden. Möchte es den Anwender natürlich so einfach machen wie möglich. Die Idee war eigentlich das man sich das Gerät, also den Hauptordner aus den Objektbaum wählt. Muss mich da aber erstmal noch ein bisschen einarbeiten und schauen ob das überhaupt so geht mit der JSON Variante vom Admin.

[JLeg]

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

@jleg

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

Hm, für diesen DP gilt bei mir das selbe wie für ‚available‘ - Geräte funktionieren seit 1-2 Jahren einwandfrei, auch wenn der Timestamp dieses DP etwas ausgeleiert sein mag.
Die timestamps der DPs, bei denen sich regelmäßig was tut (sensorwert, voltage etc.) sind i.d.R. aktuell.

Ich stelle es nachher mal Testweise um das er auf den Wert guckt. Bin

Welchen Wert meinst du - den von ‚link_quality‘? Würde in diesem Fall imo nicht helfen - wenn bei mir ein Zigbeegerät aus dem Netz fliegt, dann geht wie gesagt eigentlich zuverlässig ‚available‘ auf false, alle anderen inkl. link_quality bleiben einfach auf dem letzten Wert stehen…

[Ein ehemaliger Benutzer]

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

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

@jleg

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

Hm, für diesen DP gilt bei mir das selbe wie für ‚available‘ - Geräte funktionieren seit 1-2 Jahren einwandfrei, auch wenn der Timestamp dieses DP etwas ausgeleiert sein mag.
Die timestamps der DPs, bei denen sich regelmäßig was tut (sensorwert, voltage etc.) sind i.d.R. aktuell.

Ich stelle es nachher mal Testweise um das er auf den Wert guckt. Bin

Welchen Wert meinst du - den von ‚link_quality‘? Würde in diesem Fall imo nicht helfen - wenn bei mir ein Zigbeegerät aus dem Netz fliegt, dann geht wie gesagt eigentlich zuverlässig ‚available‘ auf false, alle anderen inkl. link_quality bleiben einfach auf dem letzten Wert stehen…

Ähm ja das stimmt. Aber der nimmt den Zeitstempel wann dieser Punkt zuletzt aktualisiert worden ist. Der Wert ist egal. Und in den Instanzeinstellungen kann man ja wählen ab wann dieses Gerät dann als Offline gilt. Grundeinstellung sind 6 std. Aber ich habe es nun auf available umgeändert. Da gilt diese offline Zeit nicht mehr sondern direkt wenn der Datenpunkt nun auf false steht. Werde es nachher hochladen.

[arteck]

@ciddi89 die meine ich

aber ja wenns grafana ist.. sah nach html widget aus..

[crunchip]

@ciddi89 bei zigbee ist es aber so, das der available nicht zuverlässig auf false wechselt, zumindest bei den Sensoren, das war ja das Problem.

Mit der aktuellen Version von gestern abend sind alle tasmota Geräte seit xxxStd offline, dementsprechend auch die Geräte, welche auf die black Liste gesetzt wurden, da ist wohl ein Fehler unterlaufen?

[Stephan Schleich]

@ciddi89 hast du bei sonoff auch berücksichtigt, das man dort die Baumstruktur aktivieren kann und sich dann die Objekte andern aufteilen?

[Ein ehemaliger Benutzer]

@crunchip ja genau. Und deswegen haben wir das damals mit den timestamp von Link quality gemacht. Das läuft bei mir auch absolut zuverlässig. Daher muss man nun Abwegen was zuverlässiger ist. Ist halt schwieriger wenn der eine sagt bei den läuft das besser und bei den anderen läuft das andere besser. Code mäßig ist das nur ein Wort austauschen und dann nutzt er entweder das eine oder das andere.

Hmm okay tasmota hab ich eigentlich nichts angerührt ich gucke mal wenn ich Zeit habe was da los ist

[Ein ehemaliger Benutzer]

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

@ciddi89 hast du bei sonoff auch berücksichtigt, das man dort die Baumstruktur aktivieren kann und sich dann die Objekte andern aufteilen?

Danke für den Hinweis. Nein das wusste ich nicht. Habe keine sonoff Geräte. Muss ich dann mit eintragen

Edit: sollte aber soweit kein Problem sein. Ist dann aber nur ein Problem wenn der battery State, falls Vorhanden, in einen anderen Ordner liegt. Das müsste ich dann nur wissen