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

[Stephan Schleich]

@ciddi89 man könnte anstatt dem Ping auch den Alive state prüfen ob dieser älter als XX wäre (Wert variable zu setzen in den settings?)

[Ein ehemaliger Benutzer]

@stephan-schleich ist teilweise schon so. Aber noch nicht bei allen Adapter da bei vielen der state nicht auf false geht. Um welchen Adapter/Geräte handelt es sich genau?

[Stephan Schleich]

@ciddi89 wäre der Sonoff Adapter, in meinem Fall ging er auch nicht auf Off, weil sich mein WLAN aufgahngen hat, wätte man nur mit einer prüfung des zuletzt geändert erkennen können oder eben einem ping

[Ein ehemaliger Benutzer]

@stephan-schleich ja gut bei sonoff ist es tatsächlich derzeit so, das wenn der Datenpunkt auf false springt und der Datenpunkt solange in der X eingestellten Zeit, wie in den Settings eingestellt, auf false steht das es dann erst gilt.
Ist wirklich schwierig abzuwägen wie ich das prüfen lassen soll weil viele User anderer Meinungen sind. Bei den einen gehen die Datenpunkte zuverlässig und bei dem anderen nicht.
Der eine will das man nur nach der Zeit zuletzt aktualisiert geht und der andere will das die Zeit nur zählt wenn der Datenpunkt auch auf false ist usw. Und ich will da auch keine tausend Einstellmöglichkeiten implementieren, das macht es leider nur zu kompliziert. Daher ich muss mir mal überlegen was man am besten machen kann, damit alle glücklich sind.

An pingen ist auch schwierig und garnicht die Aufgabe des devicewatcher. Woher soll der die ganzen Daten dafür nehmen? Dieser ist nur für die Auswertung der gegeben Daten da, die die anderen Adapter liefern. Daher sollten die dazugehörigen Adapter der Geräte auch die Aufgabe haben die Werte korrekt und aktuell zu übermitteln. Aber leider haperts da bei vielen.
Daher mein Vorschlag: Bei den Geräten/Adapter wo die Erreichbarkeitsdatenpunkte nicht korrekt Funktionen ein issue auf Github des jeweiligen Adapters eröffnen und deren Entwickler darum bitten das die da evtl. nacharbeiten und dort sowas wie anpingen etc. unterbringen. Das ist meines Erachtens die sinnvollere Variante.

[Ein ehemaliger Benutzer]

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

@ilovegym mit der vorherigen Version waren die Werte noch korrekt?

Mit der letzten 2.6.x ja

[Ein ehemaliger Benutzer]

@ilovegym hm okay komisch. Hatte diesbezüglich eigentlich nicht wirklich was geändert. Außer das ID's auf Endung von . geprüft werden sollen und wenn wahr dann diese zu überspringen. Da es dadurch zu Fehlern kam wegen gelöschten/nicht verfügbaren devices. Hab das in 2.7.1 rausgenommen sind die Geräte nun wieder vollzählig? Sonst muss ich weiter gucken woran es liegen könnte. :man-gesturing-ok:

[Ein ehemaliger Benutzer]

@ciddi89

Auch in der 2.7.1 so.. es fehlen 2 devices.. eins ist offline.. aber gesamt Anzahl ist doch alles, oder??

[Ein ehemaliger Benutzer]

@ilovegym ja sollte so sein. Wenn es vorher richtig war dann muss ich noch mal gucken warum die auf einmal nicht mehr auftauchen. In der Blacklist stehen die aber nicht oder? ist der Datenpunkt link_qualitiy von den zwei Geräten da ?

[Ein ehemaliger Benutzer]

@ciddi89

Ahhh blacklist!! Doch da stehn se…

Da war „aus den Listen nehmen“ angehakt.. Sorry !!

[Gargano]

Was ist im Benachrichtigungsdienst PushOver die Geräte ID ?
Wenn ich einen anderen Token eintrage als in der Pushover Instanz wird der ignoriert und es erfolgt immer ein Meldung auf das Token, welches in der PushOver Instanz eingetragen ist.

Javascript Überwachung funktioniert nicht. Wenn ich eine Instanz stoppe erfolgt keine Meldung.
Allerdings steht es in device-watcher.0.adapterAndInstances.listDeactivatedInstances, aber nicht in device-watcher.0.lastNotification, daher auch keine Meldung.

[Ein ehemaliger Benutzer]

@gargano

Was ist im Benachrichtigungsdienst PushOver die Geräte ID ?

Geräte ID sollte der name des Gerätes sein die bei Pushover auch eingetragen ist. Siehe Screenshot:

Javascript Überwachung funktioniert nicht.

Was meinst du damit genau?

Wenn ich eine Instanz stoppe erfolgt keine Meldung.

Ist in den Settings auch alles korrekt eingestellt?

[Gargano]

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

Was meinst du damit genau?

In der Blacklist stehen die Javascript jedenfalls nicht drin.

Ich habe jetzt mal Debug-Log aktiviert. Da sieht man, daß javascript.3 deaktiviert wurde (host-log) 2023-03-30 17:23:10.550.
Vom Device-watcher ist aber keine Reaktion.
Später wurde miele-cloud deaktiviert (2023-03-30 17:24:36.830) . Da kommt dann auch die Meldung vom Device-Watcher (2023-03-30 17:24:56.986).

Unter dem Datenpunkt steht es richtig drin:

[{"Adapter":"Javascript","Instance":"javascript.3","Status":"Instanz deaktiviert"},{"Adapter":"Mielecloudservice","Instance":"mielecloudservice.0","Status":"Instanz deaktiviert"}]

Es gibt viele Meldungen mit

Search can't be optimized because wildcard not at the end

device-watcher.0
2023-03-30 17:25:19.192	debug	Search can't be optimized because wildcard not at the end, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) }

device-watcher.0
2023-03-30 17:24:58.934	debug	Search can't be optimized because wildcard not at the end, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) }

device-watcher.0
2023-03-30 17:24:58.665	debug	Search can't be optimized because wildcard not at the end, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) }

device-watcher.0
2023-03-30 17:24:56.986	info	Instanz Watchdog: mielecloudservice.0: Instanz deaktiviert
host.raspberrypi
2023-03-30 17:24:37.707	info	instance system.adapter.mielecloudservice.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)

device-watcher.0
2023-03-30 17:24:37.008	debug	Search can't be optimized because wildcard not at the end, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) }
host.raspberrypi
2023-03-30 17:24:36.878	info	stopInstance system.adapter.mielecloudservice.0 send kill signal
host.raspberrypi
2023-03-30 17:24:36.830	info	stopInstance system.adapter.mielecloudservice.0 (force=false, process=true)
host.raspberrypi
2023-03-30 17:24:36.829	info	"system.adapter.mielecloudservice.0" disabled
host.raspberrypi
2023-03-30 17:23:11.204	info	instance system.adapter.javascript.3 terminated with code 0 (NO_ERROR)

device-watcher.0
2023-03-30 17:23:10.684	debug	Search can't be optimized because wildcard not at the end, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) }
host.raspberrypi
2023-03-30 17:23:10.573	info	stopInstance system.adapter.javascript.3 send kill signal
host.raspberrypi
2023-03-30 17:23:10.550	info	stopInstance system.adapter.javascript.3 (force=false, process=true)
host.raspberrypi
2023-03-30 17:23:10.549	info	"system.adapter.javascript.3" disabled

device-watcher.0
2023-03-30 17:22:58.276	debug	Search can't be optimized because wildcard not at the end, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) }

device-watcher.0
2023-03-30 17:22:57.628	debug	Search can't be optimized because wildcard not at the end, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) }

device-watcher.0
2023-03-30 17:22:57.053	debug	Search can't be optimized because wildcard not at the end, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) }

[Ein ehemaliger Benutzer]

@gargano

Search can't be optimized because wildcard not at the end

Das kann ignoriert werden. Hat was mit den Wildcards zu tun womit ich die Datenpunkte suche und das bekommt man leider nicht weg.

Hast aber Recht, habe bei mir auch Javascript deaktiviert und da passiert auch nichts. Werde mal die Tage gucken warum das so ist und das dann fixen.

[Gargano]

@ciddi89 Ok, danke.
Habe gerade gesehen, da gehen auch andere Adapter nicht : Meteoalarm, LogParser
Wahrscheinlich auch noch mehr.

[Gargano]

@ciddi89 Hab noch einen Wunsch beim PushOver:
Außer dem Device-ID auch den Token optional zulassen.
Dann kann man auch Gruppen adressieren.

[Ein ehemaliger Benutzer]

@gargano ich sehe gerade, ich weiß warum man keine Benachrichtigungen bekommt. Das ist bisher auch garnicht vorgesehen da man Instanzen normalerweise nur Händisch deaktiviert. Nachrichten sollen nur bei Fehler gesendet werden. Ist es gewünscht das auch eine Nachricht beim deaktivieren kommt? Dann nehme ich eine Checkbox mit rein wo der User das aktivieren kann.

@ciddi89 Hab noch einen Wunsch beim PushOver:
Außer dem Device-ID auch den Token optional zulassen.
Dann kann man auch Gruppen adressieren.

Werde die Option die Tage hinzufügen.

[Gargano]

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

st es gewünscht das auch eine Nachricht beim deaktivieren kommt? Dann nehme ich eine Checkbox mit rein wo der User das aktivieren kann.

Ja , ist gewünscht, da sich Adapter auch mal selber deaktivieren können. (z.B. Wenn zu viele Fehler auftraten).
Oder der Host deaktiviert auch schon mal Javascript Adapter unter bestimmten Bedingungen.

Aber wieso geht dann der Miele-Cloud ?
Auf was schaust Du , damit eine Meldung kommt ?

[Ein ehemaliger Benutzer]

@gargano ja wenn der Adapter mit Host nicht verbunden ist gibst auch Bescheid. Daher fand ich das bisher unnötig bzw. ich selber hatte auch noch nie das sich ein Adapter selbst deaktiviert
Hm gute Frage wundert mich selber. Ich gucke auf den alive Datenpunkt der Instanzen unter System.Adapter

//Edit: ich denke ich weiß warum er das macht. Ich versuche das mal zu verbessern. Evtl. Gibst dann am we ein fix dafür.

[Gargano]

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

ich denke ich weiß warum er das macht

Meinst Du hier ? if (id.endsWith('updatesJson'))

Und evtl. ein Testbutton zum Test-Senden wäre gut.

[Ein ehemaliger Benutzer]

@gargano hehe nein. Das ist für die Update Benachrichtigung.
Wenn eine Instanz einen Fehler hat, also connected to host oder connected to device ist false, wird erst geprüft ob alive auf false ist. Wenn nicht dann wartet der adapter 10 sek und prüft noch mal den Status und wenn eines der beiden connected immer noch false ist wartet er nochmal 10 sek. Wenn du also nun einen Adapter deaktivierst dann wird wohl connected to host teilweise früher auf false schalten aber in der Wartezeit wird der alive Datenpunkt nicht noch mal abgefragt. Wird aber nebenbei Im Status schon hinterlegt wenn sich dieser ändert von einer anderen Funktion aus. Und daher kommt das dann zu der Meldung das die deaktiviert ist. Was ja auch stimmt, wird aber indirekt vom falschen Auslöser gesetzt. Ergo muss ich bei den zwei Prüfung nochmal abfragen ob alive mittlerweile auf false gegangen ist und das senden Abbrechen damit es nicht zu den Nebeneffekt kommt.