Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[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) }

[A Former User]

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

[A Former User]

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

[A Former User]

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

[A Former User]

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

[A Former User]

@gargano Habe gestern das gefixed mit den Nachrichten beim deaktivieren einer Instanz. Dann noch eine Option hinzugefügt das man Nachrichten bekommen kann wenn eine Instanz deaktiviert wird und für pushover die option hinzugefügt eine Benutzer/Gruppen api key anzugeben. Wird dann alles mit in der nächsten Version drin sein. :)

[A Former User]

Ist hier zufällig ein User der den Yeelight adapter mit überwacht? Zufällig auch einer der drei User, der öfters mal diesen Fehler im Log stehen hat?

[[getDeviceName]] error: The id "yeelight-2.0." is invalid. Ids are not allowed to end in "."

Müsste mal wissen warum dieser Fehler auftaucht und bräuchte daher am besten eine Übersicht der Datenpunkte um das zu fixen.

[crunchip]

@ciddi89 hab nur eine Lampe, allerdings ist mir die Fehlermeldung nicht bekannt

[A Former User]

@crunchip danke für deine schnelle Antwort. Soweit scheint es dann bei mir zu passen.
Ich hoffe ja das einer der betroffenen sich noch meldet. Kann mir das nämlich nicht erklären bzw. dadurch auch nicht nach bilden. Werde aber dann im Adapter einbauen das er einfach abbrechen soll wenn die ID mit . endet. Ist wohl erstmal das einfachste. Ursache würde mich trotzdem interessieren. :)

[Malz1902]

Ich habe ein neues Zigbee Gerät gerstern angelernt, ein Aqara Bewegungsmelder:

Leider taucht dieser nicht in der Batterie Liste auf, in der Liste bei allen Geräten steht er drin, aber bei Battery seht ein -

"Device":"RTCGQ11LM","Adapter":"Zigbee","Battery":" - ","Signal strength":147,"Last contact":"12:03 Uhr","Status":"Online"}]

[A Former User]

@malz1902 Instanz mal neu gestartet?

[Malz1902]

@ciddi89 danke, das hat geholfen. manchmal ist das leben so einfach

[A Former User]

@malz1902 ein Glück für mich. :D Ich werde aber mal schauen ob ich die Erkennung irgendwie verbessern kann. Auf Github hat nämlich ein anderer User ein ähnlichen Effekt mit der Batterieerkennung.

[A Former User]

Guten Abend Leute,

ist hier zufällig jemand der mit der neusten latest v2.8.3 irgendwie Probleme mit den Instanzen hat wenn eine Instanz nicht verbunden ist mit dem Dienst/Gerät ? Zb. Vermehrt Benachrichtigung? Oder läuft bei euch alles rund? Habe meiner Meinung nach schon die Fehler beseitigt aber anscheinend macht es wohl noch immer Probleme mit der Status Erkennung bei Instanzen. Zumindest bei einem User. Um auszuschließen das es wirklich an den device watcher liegt brauch ich aber bisschen mehr Feedback ob mehr davon betroffen sind oder ob es ein Einzelfall ist. Ich danke schon mal :pray:

Hier der link zum issue:
https://github.com/ciddi89/ioBroker.device-watcher/issues/170

[da_Woody]

@ciddi89 bei mir lööpt alles rund...

[JB_Sullivan]

Nö - hier auch keine Probleme - einzig der Übersetzungsfehler (DE/EN) für die Proxy Instanz ist immer noch vorhanden.

Hier ein Beispiel - nicht verbunden bzw. nicht aktiviert und keinerlei Fehler im LOG