anbei eine erste test version des moduls mit unterstützung des neuen umdokumentierten push api der hue bridge.
- es ist die neueste fhem bzw. HttpUtils.pm version von morgen (2021-07-16) nötig: https://forum.fhem.de/index.php/topic,122066.msg1166545.html (https://forum.fhem.de/index.php/topic,122066.msg1166545.html)
- es ist die neueste firmware auf der bridge nötig (bei mir aktuell 1945163030).
- im internal EventSource ist zu sehen ob die verbindung steht.
- das automatische neu verbinden ist noch nicht optimal.
da philips/signify (noch ?) nichts dokumentiert hat und sie scheinbar ein komplett neues v2 api entwickeln (das sich ziemlich vom aktuellen unterscheidet) ist die implementierung im modul aktuell weder vollständig noch korrekt. d.h. es es kann z.b. sein das sich mit dem nächsten update der bridge das api wieder ändert. es sind u.a aktuell nicht alle events mit den möglichen werten implementiert.
wichtig ist zu wissen das events nur für dinge erzeugt werden von denen die bridge auch etwas mitbekommen hat. d.h. z.b. für das schalten von lampen über die bridge gibt es sofort events. für das schalten einer lampe direkt über eine fernbedienung gibt es erst dann ein event wenn die bridge den geänderten zustand auch mitbekommen hat. das ist aber immer noch schneller als zu pollen. das gleiche gilt für bewegungsmelder und deren motion events. ich habe noch kein temperatur oder helligkeits event gesehen. erreichbarkeits events kommen schneller als beim pollen, aber hier sollte man vermutlich nicht zu viel erwarten. es gibt auch events für die gruppen an der eine lampe beteiligt ist.
was gehen sollte: lampen schalten, motion, erreichbarkeit. jeweils mit den obigen einschränkungen.
alles andere ist noch nicht implementiert. ob es entsprechende events gibt kann man mit verbose 4 sehen. wenn hier etwas aufällig ist oder fehlt: bitte posten. wenn etwas nicht reagiert wie erwartet: ebenfalls das log posten.
edit 2022-01-08: neue version mit support für hue remotes/buttons.
edit 2022-01-17: tippfehler in button events korrigiert
edit 2022-01-17: fix für friends of hue taster events
edit 2022-01-17: fix für lange events, fix for perl warnung
edit 2022-01-17: proof of concept um dynamische szenen zu starten: set <bridge> v2scene <id>
achtung: aktuell ohne besondere fehler prüfung und deshalb auf eigene gefahr. das ganze bedient sich auch noch etwas unhandlich da man sich die id von hand raussuchen muss.
mit get <bridge> v2scenes die id der gewünschten szene anhand von name und gruppe/raum suchen und dann mit set <bridge> v2scene <id> die szene starten. wenn es eine dynamische szene ist sollte sie anfangen zu spielen.
mit get <bridge> v2resource <id> kann man sich die internas der szene ausgeben lassen dynamische szenen enthalten im palette knoten nicht leere einträge stehen.
ganz allgemein kann man sich mit get <bridge> v2resource <id> alle internas einer resource ausgeben lassen und mit get <bridge> v2resource alle v2 internas. mit get <bridge> v2resourcetype bekommt man alle resource typen und mit get <bridge> v2resourcetype <type> alle internen ids des angebenden typs. die hier gefunden ids kann man dann wieder in ein get <bridge> v2resource <id> stecken um genauere information zu bekommen. wenn sich hier rid einträge finden kann man sich damit auch wieder weiter hangeln. also zum beispiel alle buttons suchen und schauen zu welchem taster sie gehören, oder welche lampen zu welchen gruppen gehören oder welche szenen welche lampen steuern oder ...
ich habe gesehen das manche lampen (die filament birnen) jetzt scheinbar einen kerzen effekt haben und andere einen feuer effekt (neuere farbige lampen). ich weiss noch nicht wie man die startet. ich weiss auch nicht ob die liste der unterstützten effekte auch bei nicht philips lampen funktioniert. die lichterkette aus dem anderen thread wäre ein kandidat bei dem man mal schauen könnte.
demnächst werden die v2 szenen noch vernünftig (d.h. mit drop down & listen und co) in fhem eingebaut.
mit den daten aus dem v2 api müsste es auch möglich sein zusammengehörende sensoren in ein einziges device zu packen.
edit 2022-01-19: erkennung von neuen geräten zur laufzeit verbessert, intervalle in der bridge werden angepasst, pollDevices wird gelöscht und intervalle in den devices werden entfernt wenn der EventStream verbunden wird.
edit 2022-01-19: der aktuelle stand ist jetzt eingecheckt und ab morgen per update für alle verfügbar
Habe nun FHEM aktuallisiert, dann die beiden Module in das Verzeichnis FHEM kopiert und FHEM neu gestartet. Wie erkenne ich nun, on diese Version aktiv ist? Rein optisch sehe ich keinen Unterschied. Selbst unter FVERSION steht noch 30_HUEBridge.pm:0.242960/2021-04-21.
Was mache ich falsch?
Viele Grüße
Jürgen
Zitat- im internal EventSource ist zu sehen ob die verbindung steht.
und im log sollte auch etwas zu sehen sein.
EventSource ist connected. apiversion ist 1.45.0
Im Log steht leider nichts. Schalten funktioniert.
VG
Jürgen
hast du verbose auf 4 gesetzt?
was genau erwartest du denn?
Hallo justeme1968,
vorbose 4 hatte ich noch nicht. Habe ich nun geändert.
Ich hätte zumindest unter FVERSION und unter apiversion neue Werte erwartet.
Dann wollte ich zumindest Testen, ob meine Lampenfunktionen noch passen. Wollte nur helfen beim Testen :-)
Einfach schreiben, wenn es was zum Testen gibt.
Viele Grüße
Jürgen
PS.: Zumindest erscheinen jetzt im Log einträge, wenn Lampen geschaltet werden :-)
die firmware der bridge ändert sich ja nicht wenn du das neue modul verwendest.
interessant wären aktuell vorfallen events von fernbedienungen, tastern undo bewegungsmeldern.
Wenn ich eine Lampe über eine Fernbedienung schalte, habe ich nur die Events der Lampe im Eventmonitor.
2021-07-17 16:36:20 HUEDevice HUEDevice9 onoff: 1
2021-07-17 16:36:20 HUEDevice HUEDevice9 pct: 100
2021-07-17 16:36:20 HUEDevice HUEDevice9 on
Viele Grüße
Jürgen
wie ist deine fb konfiguriert? direkt mit einer lampe verknüpft oder geht die steuerung über eine Regel in der bridge? nur bei letzterem könnte man eventuell etwas sehen.
FB ist direkt mit den Lampen verknüpft.
Viele Grüße
Jürgen
Aktuell habe ich diese Meldungen im Log
2021.07.17 17:23:17 4: using HttpUtils_NonblockingGet: GET
2021.07.17 17:23:18 4: parse status message for Philips_HUE
2021.07.17 17:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 17:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 17:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 17:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 17:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 17:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 17:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 17:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 17:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 17:24:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:25:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:26:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:27:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:28:00 4: using HttpUtils_NonblockingGet: PUT lights/11/state
2021.07.17 17:28:01 4: using HttpUtils_NonblockingGet: GET lights/11
2021.07.17 17:28:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:29:17 4: using HttpUtils_NonblockingGet: GET
2021.07.17 17:29:18 4: parse status message for Philips_HUE
2021.07.17 17:29:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 17:29:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 17:29:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 17:29:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 17:29:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 17:29:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 17:29:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 17:29:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 17:29:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 17:29:32 4: using HttpUtils_NonblockingGet: PUT lights/11/state
2021.07.17 17:29:33 4: using HttpUtils_NonblockingGet: GET lights/11
2021.07.17 17:30:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:30:42 4: using HttpUtils_NonblockingGet: PUT lights/11/state
2021.07.17 17:30:43 4: using HttpUtils_NonblockingGet: GET lights/11
2021.07.17 17:31:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:32:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:33:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:34:17 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:35:18 4: using HttpUtils_NonblockingGet: GET
2021.07.17 17:35:18 4: parse status message for Philips_HUE
2021.07.17 17:35:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 17:35:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 17:35:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 17:35:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 17:35:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 17:35:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 17:35:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 17:35:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 17:35:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 17:35:39 4: using HttpUtils_NonblockingGet: PUT lights/11/state
2021.07.17 17:35:40 4: using HttpUtils_NonblockingGet: GET lights/11
2021.07.17 17:36:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:37:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:38:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:39:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:40:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:41:18 4: using HttpUtils_NonblockingGet: GET
2021.07.17 17:41:18 4: parse status message for Philips_HUE
2021.07.17 17:41:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 17:41:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 17:41:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 17:41:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 17:41:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 17:41:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 17:41:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 17:41:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 17:41:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 17:41:24 2: Philips_HUE: http request failed: read from https://philips-hue:443 timed out
2021.07.17 17:41:24 4: HUEBridge_closeEventSource: closing eventstream
2021.07.17 17:41:24 4: HUEBridge_openEventSource: tying to connect to eventstream
2021.07.17 17:42:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:43:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:44:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:45:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:46:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:47:18 4: using HttpUtils_NonblockingGet: GET
2021.07.17 17:47:18 4: parse status message for Philips_HUE
2021.07.17 17:47:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 17:47:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 17:47:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 17:47:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 17:47:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 17:47:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 17:47:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 17:47:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 17:47:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 17:48:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:49:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:50:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:51:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:52:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:53:18 4: using HttpUtils_NonblockingGet: GET
2021.07.17 17:53:18 4: parse status message for Philips_HUE
2021.07.17 17:53:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 17:53:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 17:53:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 17:53:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 17:53:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 17:53:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 17:53:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 17:53:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 17:53:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 17:54:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:55:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:56:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:57:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:58:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 17:59:18 4: using HttpUtils_NonblockingGet: GET
2021.07.17 17:59:18 4: parse status message for Philips_HUE
2021.07.17 17:59:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 17:59:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 17:59:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 17:59:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 17:59:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 17:59:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 17:59:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 17:59:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 17:59:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 18:00:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:00:31 4: using HttpUtils_NonblockingGet: PUT lights/11/state
2021.07.17 18:00:32 4: using HttpUtils_NonblockingGet: GET lights/11
2021.07.17 18:01:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:02:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:03:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:04:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:05:18 4: using HttpUtils_NonblockingGet: GET
2021.07.17 18:05:18 4: parse status message for Philips_HUE
2021.07.17 18:05:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 18:05:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 18:05:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 18:05:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 18:05:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 18:05:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 18:05:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 18:05:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 18:05:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 18:06:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:07:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:08:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:09:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:10:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:11:18 4: using HttpUtils_NonblockingGet: GET
2021.07.17 18:11:18 4: parse status message for Philips_HUE
2021.07.17 18:11:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 18:11:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 18:11:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 18:11:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 18:11:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 18:11:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 18:11:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 18:11:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 18:11:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 18:12:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:13:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:14:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:15:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:16:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:17:18 4: using HttpUtils_NonblockingGet: GET
2021.07.17 18:17:18 4: parse status message for Philips_HUE
2021.07.17 18:17:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 18:17:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 18:17:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 18:17:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 18:17:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 18:17:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 18:17:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 18:17:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 18:17:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
2021.07.17 18:18:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:19:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:20:13 4: using HttpUtils_NonblockingGet: PUT lights/11/state
2021.07.17 18:20:14 4: using HttpUtils_NonblockingGet: GET lights/11
2021.07.17 18:20:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:21:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:22:18 4: using HttpUtils_NonblockingGet: GET lights
2021.07.17 18:23:16 4: using HttpUtils_NonblockingGet: PUT lights/11/state
2021.07.17 18:23:17 4: using HttpUtils_NonblockingGet: GET lights/11
2021.07.17 18:23:18 4: using HttpUtils_NonblockingGet: GET
2021.07.17 18:23:18 4: parse status message for Philips_HUE
2021.07.17 18:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S2
2021.07.17 18:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S31
2021.07.17 18:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S1
2021.07.17 18:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S32
2021.07.17 18:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S26
2021.07.17 18:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S5
2021.07.17 18:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S28
2021.07.17 18:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S6
2021.07.17 18:23:18 4: Philips_HUE: message for unknown sensor received: Philips_HUE-S27
Benötigst Du weitere Infos?
Viele Grüße
Jürgen
Die Bridge aktualisiert ja unter umständen selbsttätig, daher die Frage ob die alte API weiterhin unterstützt wird oder ob es dort dann probleme geben kann?
Ich habe die Testversion vor 10 Tagen installiert und bin begeistert, die Verbindung steht stabil und die Rückmeldungen vom Status der Lampen kommen fast in Echtzeit an!
Die Events von Dimmerswitches sind aktuell noch nicht implementiert, sehe ich das richtig?
Da freue ich mich dann sehr drauf, wenn ich das resourcenbelegende Polling für die Switches beenden kann und die Tastendrücke per Push reinkommen.
da es noch keine doku für das api gibt weiss ich noch nicht mal ob events für die schalter erzeugt werden. schaum mal mit verbose 5 im log und poste es wenn es etwas gibt. dann baue ich es ein.
Danke justme1968!
Nach was soll ich im Log Ausschau halten? Ist es so was hier?
Der Dimmerswitch ist Sensor 2.
2021.09.02 13:57:25 4: HueBridge: received: $VAR1 = [ { 'id' => 'c8c1a493-aa9b-4b5c-81c8-a9e6c0ea9040', 'type' => 'update', 'data' => [ { 'id_v1' => '/sensors/2', 'id' => '9b6c532f-f458-4c7a-8640-dfcbed55dca8', 'type' => 'button', 'button' => { 'last_event' => 'initial_press' } } ], 'creationtime' => '2021-09-02T11:57:24Z' }, { 'creationtime' => '2021-09-02T11:57:24Z', 'data' => [ { 'on' => { 'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ) }, 'type' => 'light', 'id' => '26671fe4-1118-4d41-b2a1-1d5c338353ba', 'id_v1' => '/lights/27' } ], 'type' => 'update', 'id' => '81684907-7679-420b-9be2-b6a69fc36ac1' }, { 'type' => 'update', 'id' => '05e6065e-b870-40f1-b8ac-431fb8032ecb', 'creationtime' => '2021-09-02T11:57:24Z', 'data' => [ { 'on' => { 'on' => $VAR1->[1]{'data'}[0]{'on'}{'on'} }, 'type' => 'grouped_light', 'id_v1' => '/groups/36', 'id' => 'c2f66858-c60e-444b-a402-7ef0cf1bbae1' } ] } ];
2021.09.02 13:57:25 3: HueBridge: message for unknown device received: HueBridge-S2
2021.09.02 13:57:25 4: HueBridge: created: $VAR1 = { 'state' => { 'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ) } };
perfekt. genau nach sowas.
ich bräuchte alle möglichen varianten von drücken, loslassen, halten, ... und was dir sonst noch so einfällt was events erzeugt. und dann bitte hier posten.
dazu noch ein get <bridge> sensors detail
Hue DimmerSwitch V1
Erstmal die Sensors-Info aus der Bridge direkt:
"2":{"state":{"buttonevent":1002,"lastupdated":"2021-08-30T07:42:59"},"swupdate":{"state":"noupdates","lastinstall":"2019-10-10T12:33:27"},"config":
{"on":true,"battery":94,"reachable":true,"pending":[]},"name":"Wohnzimmer","type":"ZLLSwitch","modelid":"RWL021","manufacturername":"Signify Netherlands B.V.","productname":"Hue dimmer
switch","diversityid":"73bbabea-3420-499a-9856-46bf437e119b","swversion":"6.1.1.28573","uniqueid":"00:17:88:01:04:e7:a4:17-02-fc00","capabilities":{"certified":true,"primary":true,"inputs":
[{"repeatintervals":[800],"events":[{"buttonevent":1000,"eventtype":"initial_press"},{"buttonevent":1001,"eventtype":"repeat"},{"buttonevent":1002,"eventtype":"short_release"},
{"buttonevent":1003,"eventtype":"long_release"}]},{"repeatintervals":[800],"events":[{"buttonevent":2000,"eventtype":"initial_press"},{"buttonevent":2001,"eventtype":"repeat"},
{"buttonevent":2002,"eventtype":"short_release"},{"buttonevent":2003,"eventtype":"long_release"}]},{"repeatintervals":[800],"events":[{"buttonevent":3000,"eventtype":"initial_press"},
{"buttonevent":3001,"eventtype":"repeat"},{"buttonevent":3002,"eventtype":"short_release"},{"buttonevent":3003,"eventtype":"long_release"}]},{"repeatintervals":[800],"events":
[{"buttonevent":4000,"eventtype":"initial_press"},{"buttonevent":4001,"eventtype":"repeat"},{"buttonevent":4002,"eventtype":"short_release"},{"buttonevent":4003,"eventtype":"long_release"}]}]}}
Und hier die Meldungen aus dem Log:
Taste 1 gedrückt, "initial_press" 1000
2021.09.03 12:29:58 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'creationtime' => '2021-09-03T10:29:58Z', 'data' => [
{ 'button' => { 'last_event' => 'initial_press' }, 'id_v1' =>
'/sensors/2', 'type' => 'button', 'id' => '7316cf75-abfd-4d48-b99c-e5b9e9858d95' } ], 'id'
=> '5110b402-3100-47df-8cc1-6e1c132fb63e' } ];
2021.09.03 12:29:58 3: HueBridge: message for unknown device received: HueBridge-S2
Taste 1 gehalten, "repeat" 1001
2021.09.03 12:41:36 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'creationtime' => '2021-09-03T10:41:36Z', 'id' => 'c7753181-7b10-4469-
b054-c6350f074c2d', 'data' => [ { 'button' => { 'last_event' => 'repeat'
}, 'id_v1' => '/sensors/2', 'type' => 'button', 'id' => '7316cf75-abfd-4d48-b99c-e5b9e9858d95'
} ] } ];
2021.09.03 12:41:36 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"buttonevent":1001,"lastupdated":"2021-09-03T10:53:13"}
{"pending":[],"battery":100,"reachable":true,"on":true}
Taste 1 kurz losgelassen, "short_release" 1002
2021.09.03 12:46:22 4: HueBridge: received: $VAR1 = [ { 'data' => [ { 'id_v1' => '/sensors/2',
'button' => { 'last_event' => 'short_release' }, 'id' => '7316cf75-abfd-4d48-b99c-e5b9e9858d95',
'type' => 'button' } ], 'id' => 'd28a32cf-ffdb-46ee-a536-8f9a04063fbc', 'creationtime' => '2021-09-
03T10:46:21Z', 'type' => 'update' } ];
2021.09.03 12:46:22 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2: Wohnzimmer ZLLSwitch {"lastupdated":"2021-09-03T10:46:21","buttonevent":1002}
{"on":true,"reachable":true,"battery":100,"pending":[]}
Taste 1 lange losgelassen, "long_release" 1003
2021.09.03 13:07:46 4: HueBridge: received: $VAR1 = [ { 'id' => '3b54662b-d229-41bf-be98-7267791a54d1', 'data' => [ {
'id_v1' => '/sensors/2', 'button' => { 'last_event' => 'repeat' },
'id' => '7316cf75-abfd-4d48-b99c-e5b9e9858d95', 'type' => 'button' } ], 'creationtime' => '2021-09-03T11:07:46Z',
'type' => 'update' } ];
2021.09.03 13:07:46 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"buttonevent":1003,"lastupdated":"2021-09-03T11:07:47"}
{"pending":[],"battery":95,"reachable":true,"on":true}
Taste 2 gedrückt, "initial_press" 2000
2021.09.03 13:18:03 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'creationtime' => '2021-09-03T11:18:03Z', 'data' => [
{ 'button' => { 'last_event' => 'initial_press' }, 'id_v1' =>
'/sensors/2', 'type' => 'button', 'id' => '5a2693ad-319b-4115-b077-85f7a0af5f8d' } ], 'id'
=> '70add22f-1365-4cf1-8b5b-de8f00c2c233' } ];
2021.09.03 13:18:03 3: HueBridge: message for unknown device received: HueBridge-S2
Taste 2 gehalten, "repeat" 2001
2021.09.03 13:24:00 4: HueBridge: received: $VAR1 = [ { 'id' => '91ae0195-7c65-4514-8cc8-48a59f313ced', 'data' => [ {
'id' => '5a2693ad-319b-4115-b077-85f7a0af5f8d', 'type' => 'button', 'id_v1' => '/sensors/2', 'button' => {
'last_event' => 'repeat' } } ], 'creationtime' => '2021-09-03T11:23:59Z',
'type' => 'update' } ];
2021.09.03 13:24:00 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"buttonevent":2001,"lastupdated":"2021-09-03T11:23:29"}
{"battery":98,"reachable":true,"on":true,"pending":[]}
Taste 2 kurz losgelassen, "short_release" 2002
2021.09.03 13:18:04 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'data' => [ { 'id' => '5a2693ad-
319b-4115-b077-85f7a0af5f8d', 'type' => 'button', 'id_v1' => '/sensors/2', 'button' => {
'last_event' => 'short_release' } } ], 'id' => '40a816b5-4fff-4f1e-a14a-b18dae387fed',
'creationtime' => '2021-09-03T11:18:03Z' } ];
2021.09.03 13:18:04 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"buttonevent":2002,"lastupdated":"2021-09-03T11:18:03"}
{"reachable":true,"battery":98,"on":true,"pending":[]}
Taste 2 lange losgelassen, "long_release" 2003
2021.09.03 13:28:13 4: HueBridge: received: $VAR1 = [ { 'id' => '3cd1f3d4-81d9-404c-9d23-97856d3e8b64', 'data' => [ {
'type' => 'button', 'id' => '5a2693ad-319b-4115-b077-85f7a0af5f8d', 'button' => { 'last_event' =>
'long_release' }, 'id_v1' => '/sensors/2' } ], 'creationtime' => '2021-09-
03T11:28:13Z', 'type' => 'update' } ];
2021.09.03 13:28:13 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"lastupdated":"2021-09-03T11:28:13","buttonevent":2003}
{"pending":[],"reachable":true,"on":true,"battery":98}
Taste 3 gedrückt, "initial_press" 3000
2021.09.03 13:38:17 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'data' => [ { 'id' => '73ff1179-
5d74-482e-88ac-15ab123cf2f1', 'type' => 'button', 'id_v1' => '/sensors/2', 'button' => {
'last_event' => 'initial_press' } } ], 'id' => 'dad2e4da-472a-4465-8648-fc804e3d8280',
'creationtime' => '2021-09-03T11:38:17Z' } ];
2021.09.03 13:38:17 3: HueBridge: message for unknown device received: HueBridge-S2
Taste 3 gehalten, "repeat" 3001
2021.09.03 13:41:26 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'creationtime' => '2021-09-03T11:41:25Z', 'data' => [
{ 'button' => { 'last_event' => 'repeat' }, 'id_v1' =>
'/sensors/2', 'type' => 'button', 'id' => '73ff1179-5d74-482e-88ac-15ab123cf2f1' } ], 'id'
=> 'ae1532a3-2833-49b0-b8c3-8897da8cca0a' } ];
2021.09.03 13:41:26 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"buttonevent":3001,"lastupdated":"2021-09-03T11:41:59"}
{"reachable":true,"battery":97,"on":true,"pending":[]}
Taste 3 kurz losgelassen, "short_release" 3002
2021.09.03 13:39:31 4: HueBridge: received: $VAR1 = [ { 'creationtime' => '2021-09-03T11:39:30Z', 'id' => '4bd69a16-3531-4451-8b4b-5538b2c5e5f9',
'data' => [ { 'id_v1' => '/sensors/2', 'button' => { 'last_event' => 'short_release'
}, 'id' => '73ff1179-5d74-482e-88ac-15ab123cf2f1', 'type' => 'button' }
], 'type' => 'update' } ];
2021.09.03 13:39:31 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"lastupdated":"2021-09-03T11:39:30","buttonevent":3002}
{"pending":[],"on":true,"reachable":true,"battery":97}
Taste 3 lange losgelassen, "long_release" 3003
2021.09.03 13:46:14 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'creationtime' => '2021-09-03T11:46:13Z', 'id' => '2cfb5448-33cf-4b91-
8543-0f55bc37bf45', 'data' => [ { 'type' => 'button', 'id' => '73ff1179-5d74-482e-88ac-15ab123cf2f1',
'button' => { 'last_event' => 'long_release' }, 'id_v1' => '/sensors/2'
} ] } ];
2021.09.03 13:46:14 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"lastupdated":"2021-09-03T11:46:13","buttonevent":3003}
{"pending":[],"reachable":true,"on":true,"battery":95}
Taste 4 gedrückt, "initial_press" 4000
2021.09.03 13:55:07 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'creationtime' => '2021-09-03T11:55:07Z', 'data' => [
{ 'button' => { 'last_event' => 'initial_press' }, 'id_v1' =>
'/sensors/2', 'type' => 'button', 'id' => '9b6c532f-f458-4c7a-8640-dfcbed55dca8' } ], 'id'
=> 'a8114b7b-b5e5-49d0-84ec-2cc9899dd396' } ];
2021.09.03 13:55:07 3: HueBridge: message for unknown device received: HueBridge-S2
Taste 4 gehalten, "repeat" 4001
2021.09.03 13:59:28 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'id' => 'f348b508-6976-4c3e-bafe-6bc3a19d7328', 'data' => [
{ 'id' => '9b6c532f-f458-4c7a-8640-dfcbed55dca8', 'type' => 'button', 'id_v1' => '/sensors/2',
'button' => { 'last_event' => 'repeat' } } ],
'creationtime' => '2021-09-03T11:59:27Z' } ];
2021.09.03 13:59:28 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"lastupdated":"2021-09-03T12:00:02","buttonevent":4001}
{"on":true,"reachable":true,"battery":95,"pending":[]}
Taste 4 kurz losgelassen, "short_release" 4002
2021.09.03 13:49:27 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'id' => 'bda13ff7-4406-4d93-8716-1f4bc300cf53', 'data' => [
{ 'id_v1' => '/sensors/2', 'button' => { 'last_event' => 'short_release'
}, 'id' => '9b6c532f-f458-4c7a-8640-dfcbed55dca8', 'type' => 'button' } ],
'creationtime' => '2021-09-03T11:49:26Z' } ];
2021.09.03 13:49:27 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"buttonevent":4002,"lastupdated":"2021-09-03T11:49:26"}
{"pending":[],"reachable":true,"on":true,"battery":95}
Taste 4 lange losgelassen, "long_release" 4003
2021.09.03 14:01:23 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'id' => 'e2bf788a-0e11-496a-aa28-576339b7c10e', 'data' => [
{ 'id' => '9b6c532f-f458-4c7a-8640-dfcbed55dca8', 'type' => 'button', 'id_v1' => '/sensors/2',
'button' => { 'last_event' => 'long_release' } } ],
'creationtime' => '2021-09-03T12:01:22Z' } ];
2021.09.03 14:01:23 3: HueBridge: message for unknown device received: HueBridge-S2
get HueBridge sensors detail
2:Wohnzimmer ZLLSwitch {"lastupdated":"2021-09-03T12:01:22","buttonevent":4003}
{"reachable":true,"battery":97,"on":true,"pending":[]}
Und hier habe ich auch noch ein Helligkeits-Event vom Hue Outdoor-Bewegungsmelder (leider nur mit anderen Meldungen zusammen):
Sensor 159 Helligkeit
2021.09.03 14:09:16 4: HueBridge: received: $VAR1 = [ { 'creationtime' => '2021-09-03T12:09:14Z', 'data' => [ {
'id_v1' => '/groups/0', 'on' => { 'on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ) },
'type' => 'grouped_light', 'id' => '19623758-d1ba-45c9-b786-38d0d2649fe6' } ], 'id' => '643fb216-b8ff-
4643-9965-d34b9fd3d183', 'type' => 'update' }, { 'type' => 'update', 'data' => [ { 'id_v1' =>
'/groups/36', 'id' => 'c2f66858-c60e-444b-a402-7ef0cf1bbae1', 'on' => { 'on' => $VAR1->[0]{'data'}[0]{'on'}
{'on'} }, 'type' => 'grouped_light' } ], 'id' => '8646ff8d-d805-4de6-ab8f-
e1dbb5ab0218', 'creationtime' => '2021-09-03T12:09:14Z' }, { 'type' => 'update', 'data' => [ {
'id_v1' => '/sensors/159', 'id' => 'bd707860-4837-40db-9880-e5d4982c4325', 'light' => { 'light_level' =>
29495, 'light_level_valid' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ) }, 'type' =>
'light_level' } ], 'id' => 'af3bfb7d-2de2-4fda-8e52-09aa62494ed6', 'creationtime' => '2021-09-03T12:09:15Z' } ];
2021.09.03 14:09:16 4: HueBridge: created: $VAR1 = { 'state' => { 'on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ) } };
2021.09.03 14:09:16 4: parse status message for hueBridge1_HUEGroup0
2021.09.03 14:09:16 4: HueBridge: created: $VAR1 = { 'state' => { 'on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ) } };
2021.09.03 14:09:16 4: parse status message for hueBridge1_HUEGroup36
2021.09.03 14:09:16 3: HueBridge: message for unknown device received: HueBridge-S159
get HueBridge sensors detail
159: Garten ZLLLightLevel {"dark":false,"lightlevel":30431,"daylight":true,"lastupdated":"2021-09-03T12:39:12"}
{"ledindication":false,"reachable":true,"battery":100,"alert":"none","on":true,"tholddark":232,"tholdoffset":23768,"usertest":false,"pending":[]}
Und ein Hue Indoor-Bewegungsmelder Temperatur-Event:
Sensor 26 Temperatur
2021.09.03 14:09:07 4: HueBridge: received: $VAR1 = [ { 'creationtime' => '2021-09-03T12:09:07Z', 'id' => '63dee9e7-d23d-4ce3-8f3f-74dff02e30a3',
'data' => [ { 'temperature' => { 'temperature' => '18.4500007629395',
'temperature_valid' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ) }, 'id_v1' => '/sensors/26',
'type' => 'temperature', 'id' => '7bf55e6f-ac66-4553-b76c-d7470d9287d7' } ], 'type' => 'update' } ];
2021.09.03 14:09:07 3: HueBridge: message for unknown device received: HueBridge-S26
get HueBridge sensors detail
26: Flur ZLLTemperature {"temperature":1873,"lastupdated":"2021-09-03T12:24:05"}
{"usertest":false,"pending":[],"ledindication":false,"on":true,"reachable":true,"battery":65,"alert":"none"}
das ist genau die information die wir brauchen, aber wir haben scheinbar ein kleines problem:
die ganzen button events verwenden scheinbar eine id um den button zu identifizieren und ich habe keine ahnung wie der zusammenhang von id zu button nummer ist. bei button 1 ist es z.b. 7316cf75-abfd-4d48-b99c-e5b9e9858d95. die ist bei allen events die diesen button betreffen gleich. schau mal bitte ob dir was auffällt oder ob die id noch irgendwo sonst in den bridge daten auftaucht...
ansonsten habe ich eine version angehängt die temperature und lightlevel verstehen müsste.
edit: neue version weiter unten: https://forum.fhem.de/index.php/topic,122075.msg1173473.html#msg1173473 (https://forum.fhem.de/index.php/topic,122075.msg1173473.html#msg1173473)
Oh, ich hatte gehofft, Du wirst da schlau draus, dass die Meldungen etwas kryptisch sind ist mir auch aufgefallen. Ich habe leider bisher keinen blassen Schimmer wie das Muster sein könnte.
Danke für deine Arbeit soweit!
Ich habe hier noch mal die Meldungen von einem anderen Dimmerswitch rausgesucht, vom Dimmerswitch Sensor 189 scheint die ID die 33240b3f-26be-408d-b752-d6981915afee zu sein, die wiederholt sich in jeder Meldung.
2021.09.03 14:30:17 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'id' => 'ee1a481b-e353-4918-8f7c-4108e2e24d53', 'data' => [ { 'button' => { 'last_event' => 'initial_press' }, 'id_v1' => '/sensors/189', 'type' => 'button', 'id' => '33240b3f-26be-408d-b752-d6981915afee' } ], 'creationtime' => '2021-09-03T12:30:17Z' } ];
2021.09.03 14:30:17 4: HueBridge: created: $VAR1 = { 'state' => {} };
2021.09.03 14:30:18 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'creationtime' => '2021-09-03T12:30:17Z', 'id' => '670df1c0-426b-4d32-9386-21ab99291c13', 'data' => [ { 'id' => '33240b3f-26be-408d-b752-d6981915afee', 'type' => 'button', 'id_v1' => '/sensors/189', 'button' => { 'last_event' => 'repeat' } } ] } ];
2021.09.03 14:30:18 4: HueBridge: created: $VAR1 = { 'state' => {} };
Ich krame morgen noch mal ein paar Sensors und die dazugehörige Log-Meldung raus, vielleicht findet sich dann ein Muster.
Die 7316cf75-abfd-4d48-b99c-e5b9e9858d95 taucht absolut nirgendwo in der Bridge auf, wenn ich mir per HTTP Get <bridge-ip>/api/<key>/ die komplette Bridge ausgeben lasse.
Dass die Sensor-ID auch in der Meldung auftaucht hast du gesehen, bringt aber nix?
Kann man das nicht irgendwie modulseitig verknüpfen und hinterlegen?
2021.09.03 12:41:36 4: HueBridge: received: $VAR1 = [ { 'type' => 'update', 'creationtime' => '2021-09-03T10:41:36Z', 'id' => 'c7753181-7b10-4469-
b054-c6350f074c2d', 'data' => [ { 'button' => { 'last_event' => 'repeat'
}, 'id_v1' => '/sensors/2', 'type' => 'button', 'id' => '7316cf75-abfd-4d48-b99c-e5b9e9858d95'
} ] } ];
2021.09.03 12:41:36 3: HueBridge: message for unknown device received: HueBridge-S2
Edit: ich glaube, ich verstehe noch nicht wo genau die Baustelle ist. Fehlt dir in den Event-Meldungen die Info, welche von den 4 Tasten am Dimmerswitch gedrückt wurde oder die, um welchen Dimmerswitch es sich handelt?
es fehlt welche der 4 tasten betätigt wurde. bzw. jede taste hat zwar eine eigene id, ich weiss aber nicht welche id zu welcher taste gehört. d.h. ich kann aus dem event nicht den 4 stelligen readings wert machen der beim pollen kommt.
Ok, habs nun verstanden, danke!
Ich hab jetzt mehrere Dimmerswitches verglichen, und die IDs der Tasten sind bei jedem anders. Kein Muster zu erkennen, keine hinterlegte Info in der Bridge dazu.
Aus meinen bisherigen Erkenntnissen bliebe wohl nur, die Tasten initial mit per Polling erhobenen Daten zu der zugehörige Push-Meldung zuzuordnen und diese Info irgendwo zu hinterlegen.
Oder Signify ringt sich doch mal zeitnah dazu durch, die Api-Documentation auf Stand zu bringen...
bitte teste mal diese version mit verbose 4. direkt nach einem set <bridge> reconnect sollte ein ziemlich großer formatierter datenblock im log erscheinen. das sind die ressourcen über das neue api ausgelesen.
schau mal ob da irgendwo die 7316cf75-abfd-4d48-b99c-e5b9e9858d95 auftaucht.
mich würde auch der komplette sensor teil interessieren. vielleicht kannst du mir den kompletten block mailen.
Ich bekomme mit der neuen Version leider keine Push-Aktualisierung über Tastendrücke am Dimmerswitch.
Den Datenblock nach set Bridge reconnect habe ich per PN geschickt.
Die 7316cf75-abfd-4d48-b99c-e5b9e9858d95 ist dabei.
Danke für deine Arbeit!
Nebenbemerkung: ich habe heute beschlossen, von der Hue Bridge auf den Conbee-II-USB-Stick umziehen. Ich persönlich habe dann keinen Bedarf mehr daran dass die Push-Mitteilungen von der Hue Bridge funktionieren.
die tastendrücke waren ja auch noch nicht eingebaut da ich bisher die button nummer noch nicht habe.
ich habe die pn bekommen. wie es ausschaut bekomme ich die button nummer über die neuen daten. wann willst du denn umziehen? wenn es niemanden zum testen gibt kann ich es nicht einbauen :)
ps: über das neue api scheint es eventuell auch möglich zu sein die mehrfach sensor devices wieder zusammenzufassen. allerdings braucht es auch hier jemandem zum testen.
Das dauert wohl einige Wochen mit dem Umzug.
Ich teste gerne weiter, ich finde das spannend :)
Signify hat mich die letzten Jahre öfter mal an den Rand der Verzweiflung getrieben mit ihrer Api-Geheimniskrämerei, ich freue mich jedes Mal wenn man dem ein Schnippchen schlagen kann.
Guten Morgen,
als ich mir bei der Weiterentwicklung meines Miele@Home-Moduls Deinen Code angeschaut habe, ist mir aufgefallen, dass in dem Modul aus dem ersten Post incrementalTimeout falsch geschrieben ist. Es fehlt ein 'e' ;-) -> incrementalTim[e]out.
Dieses hatte ja auch schon Rudi hier https://forum.fhem.de/index.php?topic=85307.0 hinzugefügt ;-)
LG
Christian
ups... ist fürs nächste mal korrigiert.
Läuft bei mir jetzt seit einigen Wochen ohne Probleme. Ist geplant, das ins offizielle SVN zu bringen?
die implementierung hier ist ohne doku und durch probieren entstanden. inzwischen hat phillips das neue api angekündigt und in einer unvollständigen test version zum teil dokumentiert. wenn die doku vollständig ist das ganze nicht mehr beta status hat baue ich es komplett ein und dann wird es auch eingecheckt. vorher vermutlich nicht.
Super! Funktioniert sehr gut! :)
Zitat von: justme1968 am 02 Dezember 2021, 12:52:48
die implementierung hier ist ohne doku und durch probieren entstanden. inzwischen hat phillips das neue api angekündigt und in einer unvollständigen test version zum teil dokumentiert. wenn die doku vollständig ist das ganze nicht mehr beta status hat baue ich es komplett ein und dann wird es auch eingecheckt. vorher vermutlich nicht.
Bin also auch bereit zu testen. Habe diverses neues und altes Material von Hue.
ich habe ganz oben eine neue version angehängt. damit müssten die buttonevents für die diversen hue schalter und buttons funktionieren. getestet mit einem hue dimmer switch, einem hue smart button und einem friends of hue senic smart switch. hue tap müsste auch gehen.
es gibt wie gehabt events für initial press, hold, short release und long release.
das schnelle pollen sollte damit nicht mehr nötig sein.
achtung: nur die hardware die mit batterie betrieben wird unterstützt repeat und long. d.h. senic und tap liefern nur press und release.
Super! Herzlichen Dank!
Nach Kurztest: funktioniert sehr gut!
Nur eine Kleinigkeit: Beim Modul LWV001 ist ein (bei mir) nicht existentes Icon "hue_filled_filament" eingetragen (31_HUEDevice.pm Zeile 84/85).
das icon habe ich erst vorgestern mit drei weiteren neuen eingecheckt. du kannst es dir per update images/fhemSVG holen.
Guten Morgen zusammen,
herzlichen Dank erstmal, dass hier fleißig weiter gearbeitet wird. Ich habe heute die beiden Dateien ersetzt und neu gestartet. Noch scheint das bei mir nicht zu pushen. Die Lampen sind trotzdem verzögert, wenn man über die HUE App einschaltet. Soll man bei der Sensor Config das PollInterval entfernen?
Irgendwas mache ich bestimmt noch falsch und hoffe auf eure Antwort.
Vielen Dank.
Internals:
DEF sensor 121 1 IODev=HUEBridge1
FVERSION 31_HUEDevice.pm:0.254300/2022-01-06
ID S121
INTERVAL 1
IODev HUEBridge1
NAME HUE_WZ_Schalter
NR 206
STATE 4000
Internals:
DEF 192.168.10.28
EventStream connecting
FVERSION 30_HUEBridge.pm:0.242960/2021-04-21
INTERVAL 60
NAME HUEBridge1
NOTIFYDEV global
NR 18
NTFY_ORDER 50-HUEBridge1
STATE connected
TYPE HUEBridge
apiversion 1.48.0
bridgeid xx
has_v2_api 1
ZitatEventStream connecting
d.h. die verbindung steht noch nicht.
gib mal von hand ein
set HUEBridge1 reconnect ein. geht es dann auf connected?
Hallo,
okay, danke für die Antwort. Ich habe den Befehl probiert, das ganze System nochmal neu gestartet, das Hue Gatway neu gestartet. Lieder ohne Erfolg.
Liegt es am Docker Betrieb oder müssen die attr. richtig gesetzt werden ?
Gruß,
Stefan
es könnte an docker liegen.
was sagt das log bei verbose 5?
dein bridge device hat auch recht wenig internals. ist das eine philips bridge oder deconz?
Ne, ist eine normal Hue Bridge. Das Log füllt sich schnell, weil ich viele Polls wg BWM und Dimmer habe..
Muss ich bei Docker ein Port aufmachen?
2022.01.15 13:31:17.488 4: using HttpUtils_NonblockingGet: GET sensors/157
2022.01.15 13:31:17.496 5: HUEBridge_dispatch: sensors/157
2022.01.15 13:31:17.622 4: HUEBridge_closeEventStream: closing eventstream
2022.01.15 13:31:17.623 4: HUEBridge_openEventStream: tying to connect to eventstream
2022.01.15 13:31:17.741 4: using HttpUtils_NonblockingGet: GET sensors/167
2022.01.15 13:31:17.751 5: HUEBridge_dispatch: sensors/167
2022.01.15 13:31:17.784 4: using HttpUtils_NonblockingGet: GET sensors/95
2022.01.15 13:31:17.801 5: HUEBridge_dispatch: sensors/95
2022.01.15 13:31:17.846 4: using HttpUtils_NonblockingGet: GET sensors/46
2022.01.15 13:31:17.855 5: HUEBridge_dispatch: sensors/46
2022.01.15 13:31:17.866 4: using HttpUtils_NonblockingGet: GET sensors/102
2022.01.15 13:31:17.875 5: HUEBridge_dispatch: sensors/102
Hatte nur nicht alle internals mitgenommen:
Internals:
DEF 192.168.10.28
EventStream connecting
FUUID 5d960448-xxxxxx
FVERSION 30_HUEBridge.pm:0.242960/2021-04-21
INTERVAL 60
NAME HUEBridge1
NOTIFYDEV global
NR 18
NTFY_ORDER 50-HUEBridge1
STATE connected
TYPE HUEBridge
apiversion 1.48.0
application id 300c5cb3-xxxxxxxx
bridgeid 0017xxxxx
has_v2_api 1
host 192.168.10.28
mac 00:17:xx:60:f2:xx
manufacturer Signify
modelName Philips hue bridge 2015
modelid BSB002
name Bredx
swversion 1949107040
updatestate 1 [18]
zigbeechannel 25
READINGS:
2022-01-15 12:03:07 lastError resource, /lights/63, not available
2022-01-15 13:27:47 state connected
2022-01-08 14:55:07 swupdate 1.49.1.1
helper:
apiversion 77824
count 0
last_config_timestamp 1642249667
offsetUTC 3600
updatestate 1
HTTP_CONNECTION:
FD 10
NAME
addr https://192.168.10.28:443
auth 0
buf
compress 1
displayurl https://192.168.10.28/eventstream/clip/v2
header HUE-Application-Key: Bgxxxxx
Accept: text/event-stream
host 192.168.10.28
httpdata : hi
das log bitte vom set HUEBridge1 reconnect sein.
Sollte da mehr kommen? Ich habe das gemacht und da kommen nur die 2 Zeilen ???
So, ich habe nochmal weiter getestet.
Auf einer anderen FhemInstanz mit Docker ist das gleiche Problem. Nächster Versuch auf einer normalen Raspberry Installation. Hier funktioniert es.
Scheint noch Probleme in einem DockerContainer zu machen. Hast du eine Idee @justme1968
Viele Grüße
warum tut ihr euch immer wieder diesen docker mist an. fast alles was das netzwerk angeht ist dort nicht plug&play.
in dem fall habe ich gerade keine idee, die verbindungen gehen alle vom modul aus. das sollte eigentlich der einfachere fall sein.
Docker hat für mich einiges an Vorteile -> Mehrere FhemInstanzen, Auf Synology Diskstation leicht zu installieren, die gemappten FhemOrdner können per TimelimeBackup gesichert werden, Mit einer Installation könnte ich keine 2 GAssisstant Verbindungen herstellen und und...) Das System läuft seit Umzug auf Synology/Docker super stabil.
Echt komisch was das ist. Liegt es vllt daran, dass Fhem einen anderen Port außerhalb hat (nicht 8083)? Kann ich in der PM irgendeine Logzeile hinzufügen um mehr Infos zu bekommen woran es scheitert?
Schönen Sonntag noch.
die ganzen vorteile habe ich mit echter virtualisierung auch ohne mir die ganzen nachteile zu erkaufen. auch auf einer synology mit dem virtual machine manager. und fhem selber läuft ganz problemlos nativ auf meiner diskstation.
und wie man sieht läuft es nur so lange stabil wie es keine probleme gibt :)
prinzipiell ist docker was das netzwerk angeht nicht transparent und es gibt hier eine ganze reihe threads deren bei denen docker die ursache des problems war und das ist noch ärgerlicher wenn man erst nach einigem hin und her drauf kommt.
aber zurück zum thema: wie gesagt baut im aktuellen fall fhem die verbindung auf. diese richtung sollte eigentlich tatsächlich problemlos gehen. und die bridge ist eine echte.
stell mal global auf verbose 5 und schau ob im log mehr zu sehen ist.
Ich habe nun nochmal weiter getestet. Dachte, wenn ich im Docker ein Fhem aufbaue, das im Host-Netzwerk läuft sollte es eigentlich gehen. Aber leider das geht auch nicht. Habe sogar die fhem.cfg von der Raspberry-Testinstallation genommen womit es auf dem Raspi funktioniert.
Allerdings konnte ich auf dem Docker "Fhem Host" ein Fehler im Log endlich sehen:
Nach dem Start habe ich nochmal ein "set HUEBridge1 reconnect" gemacht
Hier nochmal ein Vergleich zwischen Raspberry Testversion und Docker FhemHost. Der Unterschied ist die Nachricht mit dem "NonBlocking via https" ?
----------- Docker Fhem Host ---------------------
-------geht leider nicht -----------------
2022.01.16 22:24:58 5: Cmd: >set HUEBridge1 reconnect<
2022.01.16 22:24:58 4: HUEBridge_openEventStream: tying to connect to eventstream
2022.01.16 22:24:58 5: HttpUtils url=https://192.168.10.28/eventstream/clip/v2
2022.01.16 22:24:58 4: IP: 192.168.10.28 -> 192.168.10.28
2022.01.16 22:24:58 5: HttpUtils request header:
GET /eventstream/clip/v2 HTTP/1.1
Host: 192.168.10.28
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: keep-alive
Accept: text/event-stream
HUE-Application-Key: ooEIqreUStwwiwf0HvICxxxxxxxxxxxxxxxxxxxxxxx
2022.01.16 22:24:58 5: GET /fhem?room=HUEDevice&fw_id=20 HTTP/1.1
Host: 192.168.10.65:8083
Connection: keep-alive
Cache-Control: max-age=0
----------- Raspberry Testinstallation ---------------------
-------so geht es -----------------
2022.01.16 21:22:54 5: Cmd: >set HUEBridge1 reconnect<
2022.01.16 21:22:54 5: HttpUtils url=https://192.168.10.28/eventstream/clip/v2 NonBlocking via https
2022.01.16 21:22:54 4: IP: 192.168.10.28 -> 192.168.10.28
2022.01.16 21:22:54 5: HttpUtils request header:
GET /eventstream/clip/v2 HTTP/1.1
Host: 192.168.10.28
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: keep-alive
Last-Event-ID: 1642368154:0
HUE-Application-Key: wsjjiBK0LfAxa6s1VYIxxxxxxxxxxxxxxxxxxxxxxx
Accept: text/event-stream
2022.01.16 21:22:54 5: GET /fhem?room=HUEDevice&fw_id=294 HTTP/1.1
Host: 192.168.10.113:8083
Connection: keep-alive
Cache-Control: max-age=0
Hallo,
ich nochmal. Wahrscheinlich werden wir so schnell noch keine Lösung finden. Ich habe auf dem Raspberry auch Docker installiert und auch hier besteht das Problem, also kann man die Synology ausschließen. Ich hatte zwischendurch eine IOBrokerTestversion im Docker hochgefahren. Hier hat man mittlerweile auch schon ein hue-push-client für den Adapter. Da funktioniert es innerhalb Docker. Alles merkwürdig.
Bis eine Lösung da ist, werde ich in Fhem auf dem Raspberry die Bewegungsmelder und Switch pushen und es per MQTT schicken. Dann hört endlich das pollen auf.
Mir ist noch aufgefallen, dass die Zustände anders sind. Soll das so sein?
z.B. SwitchDimmer hat im State beim drücken den Wert "0100" u. "0101" und nicht "1000" und "1001". Wenn man dann weiterhin pollt, dann überschreibt er den Wert nach 1min wieder mit dem richtigen Wert -> also 0100 -> 0101 -> nach 1min dann wieder 1001
Gruß,
Stefan
das war ein tippfehler. im ersten post ist eine korrigierte version.
es gibt ganz oben noch mal eine neue version. mir ist gerade aufgefallen das die events des friends of hue taster (d.h. ohne batterie) noch falsch waren. die liefern komplett andere nummern als die dimmer taster und der smart button.
wenn es die nächsten tage keinen einwand gibt würde ich den aktuellen stand erst mal so einchecken.
Echt super, dass du die Events der neuen API jetzt auswertest.
Ich bin begeistert. Vielen Dank!
Allerdings sind mir noch
32 Dinge aufgefallen.
- Nach einem shutdown restart bleibt die HUEBridge bei mir immer in "EventStream
connecting". Ein "set HUEBridge reconnect" bringt sie dann in "connected".
Im Log steht:
HUEBridge: http request failed: https://192.168.178.52/auth/v1: Can't connect(2) to https://192.168.178.52:443: SSL connect attempt failed
HUEBridge: http request failed: https://192.168.178.52/eventstream/clip/v2: Can't connect(2) to https://192.168.178.52:443: SSL connect attempt failed
Die Temperatur vom Bewegungssensor wird um Faktor 100 zu klein dargestellt (z.B. 0.195 statt 19.5), da sie ja in HUEDevice.pm mit dem Faktor 0.01 multipliziert wird.- Ich habe eine Szene mit vielen Lampen.
Wenn ich diese aufrufe, dann wird ein langer Eventstream mit mehr als 4096 Bytes erzeugt.
Ich bekomme dann den Fehler: "HUEBridge: invalid json detected: .... "
Ich habe mir mal die Länge von $data ausgeben lassen, wenn das passiert.
Die Länge ist dann immer 4096 und $data ist abgeschnitten.
Probehalber habe ich das abgeschnittene $data zwischengespeichert und beim nächsten $data vorne angefügt.
Das funktioniert :D
Vielleicht kannst du ja noch so etwas ähnliches einbauen.
Warum aber nur maximal 4096 Bytes beim Callback ankommen, weiß ich nicht :-\
1. welche version verwendest du? in der version von heute sollte das eigentlich behoben sein.
2. ist seit ein paar tagen schon behoben
3. schaue ich mir an.
zu 1.: Mit der Version von heute geht's bei mir auch nicht. Vielleicht liegt's ja an meiner Konfiguration, da ein reconnect später sofort funktioniert
zu 2.: Sorry, habe ich erst heute gemerkt.
zu 3.: Super, danke.
Mir ist noch aufgefallen, dass ich im Log so etwas bekomme:
2022.01.17 17:44:22 1: PERL WARNING: Argument "22Z" isn't numeric in addition (+) at ./FHEM/99_Utils.pm line 117.
Liegt vermutlich am "Z" in der "creationtime": [{"creationtime":"2022-01-17T16:44:22Z", ...
1. bitte schau mal ob es beim starten http fehler von der bridge gibt wenn der eventstream nicht connected
3. ich habe ganz oben eine gepatchte HttpUtils.pm angehängt. damit werden die zerstückelten langen events korrekt zusammengebaut.
ich denke das rudi die änderung demnächst übernimmt: https://forum.fhem.de/index.php/topic,122066.msg1201344.html#msg1201344 (https://forum.fhem.de/index.php/topic,122066.msg1201344.html#msg1201344)
4. 30_HUEBridge.pm ist ebenfalls neu, der zeit fehler sollte auch behoben sein.
ok... letztes update für heute.
version und beschreibung ganz oben.
was mir gerade noch einfällt: ich habe den verdacht das das verbinden der events dann nicht funktioniert wenn die bridge überlastet ist. z.b. durch zu viele status abfragen. das könnte z.b. sein wenn beim starten von fhem alle sensoren auf einmal pollen. wenn man die events verwenden sollte das pollen der einzelnen devices eigentlich komplett unnötig sein. geht das verbinden dann beim starten besser?
Ich habe gestern Abend das Modul mit dieser Version ersetzt.
Jetzt habe ich zusätzlich Sensoren, die ich nicht kenne und wohl auch nicht habe.
HUESensor1
manufacturername Signify Netherlands B.V.
modelid PHDL00
name Daylight
und eine Anzahl von "Rocker support"
(Beispiel)
Name HUESensor161
manufacturername Philips
modelid HUELABSENUM
name Rocker support
type CLIPGenericStatus
Was ist das?
natürlich 'hast' du die. sonst würden sie ja nicht angelegt.
Daylight ist ein virtueller sensor in jeder bridge der für tageszeit abhängige dinge verwendet werden kann
die anderen sind irgendwelche hilfskonstruktionen die angelegt werden wenn du mit der app die tasten der diversen schalter konfigurierst.
ich weiß noch nicht genau ob und wie ich die unwichtigen automatisch ignorieren kann.
der knackpunkt ist: wenn ich geräte weg lasse und später ein event dafür kommt wird im log eine warnung angezeigt. ich könnte mir zwar im prinzip merken was ich weg gelassen habe, am besten merken könnte ich es jeweils in einem fhem device alles andere wäre deutlich aufwändiger. aber die devices wurden ja absichtlich nicht angelegt. und schon beisst sich die katze in den schwanz.
das einfachste ist du ignoriert die zusätzlichen devices einfach erst mal.
Zitat von: justme1968 am 18 Januar 2022, 09:10:36
das einfachste ist du ignoriert die zusätzlichen devices einfach erst mal.
Das tue ich auch, sind schon in einem separatem Raum.
Eine Zuordnung zur Realität wäre angenehm, aber ich kann die ganzen Sensoren namens "Rocker support" sind mir ein Rätsel. Ich vermisse nichts, deshalb ist ignorieren auch ok.
Habe die 3 neuen Dateien seit gestern Abend im Betrieb.
Lange Eventstreams gehen jetzt und der Zeitfehler ist auch behoben. Super, Danke.
Zum Problem, dass der Eventstream auf "connecting" bleibt:
Wie verhindere ich das Pollen? Habe jetzt "pollDevices" auf 0 gesetzt. Ist da richtig?
Dann bleibt der Eventstream aber immer noch auf "connecting".
Ich habe versuchsweise mal alle defines mit HUE ans Ende der fhem.cfg verschoben.
Dann wird im Log etwas anderes eingetragen.
Vorher:
2022.01.18 09:10:15 1: 1
2022.01.18 09:10:15 2: HUEBridge: http request failed: https://192.168.178.52/auth/v1: Can't connect(2) to https://192.168.178.52:443: SSL connect attempt failed
2022.01.18 09:10:15 1: 2 type:>application id< lastID:><
2022.01.18 09:10:20 1: 1
2022.01.18 09:10:20 2: HUEBridge: http request failed: https://192.168.178.52/eventstream/clip/v2: Can't connect(2) to https://192.168.178.52:443: SSL connect attempt failed
2022.01.18 09:10:20 1: 2 type:>event< lastID:><
Nachher:
2022.01.18 09:50:02 1: 1
2022.01.18 09:50:02 2: HUEBridge: http request failed: https://192.168.178.52/auth/v1: empty answer received
2022.01.18 09:50:02 1: 2 type:>application id< lastID:><
2022.01.18 09:50:02 1: 1
2022.01.18 09:50:02 2: HUEBridge: http request failed: https://192.168.178.52/eventstream/clip/v2: empty answer received
2022.01.18 09:50:02 1: 2 type:>event< lastID:><
Andere http-Fehler bekomme ich nicht.
pollDevices sollte auf 1 oder 2 stehen und alle intervalle aus den sensor definitionen müssen raus.
das bridge device sollte vor allen anderen hue devices in der config stehen.
auf welcher hardware läuft dein fhem? wie viele lampen und taster hat du an deiner hue bridge?
bitte probier noch mal das neueste bridge modul von gerade eben ganz oben im thread.
ich habe den automatischen retry geändert. damit sollte jeweils nach 2 sekunden automatisch ein weiterer versuch gemacht werden wenn der vorherige schief geht.
funktioniert das bei dir besser ?
Das neue 30_HUEBridge.pm funktioniert bei mir besser!
Ich bekomme zwar einmal die Fehler:
2022.01.18 13:24:33 2: HUEBridge: http request failed: https://192.168.178.52/auth/v1: Can't connect(2) to https://192.168.178.52:443: SSL connect attempt failed
2022.01.18 13:24:34 2: HUEBridge: http request failed: https://192.168.178.52/eventstream/clip/v2: Can't connect(2) to https://192.168.178.52:443: SSL connect attempt failed
2022.01.18 13:24:34 2: EventStream: terminated; retrying later
Danach geht der EventStream aber auf "connected".
Ich habe auch viel mit der Version von gestern rumprobiert, und es ist mir gelungen, dass die auch bei mir läuft.
Geholfen hat ein "attr initialUsbCheck disable 1" um beim Start den EventStream sofort auf "connected" zu bringen.
Die neue Version läuft auch ohne "disable".
Da scheint im Hintergrund wohl was zu blockieren, oder?
Vielen Dank für die schnelle Hilfe.
Hier noch die Antworten auf deine Fragen (wahrscheinlich nicht mehr wichtig ;D):
Hardware ist ein Raspberry Pi 4B.
Es erscheinen 10 Devices und 18 Sensoren im FHEM.
pollDevices 1 oder 2 machte keinen Unterschied. Blieb bei beiden auf "connecting".
es scheint irgend ein timing problem zu sein. sehr komisch.
aber wenn es jetzt im prinzip geht ist das schon mal gut.
ich lasse mir noch was einfallen um das polling automatisch zu deaktivieren oder zu reduzieren wenn die events vorhanden sind und checke dann mal langsam ein.
Komisch, ich weiß nicht was du alles verändert hast, aber nun funktioniert es auch alles im DockerContainer mit den neuen Dateien und direkt nach dem Neustart ;D
Ich habe allerdings auch mal USB auf disabled gesetzt, aber mit den alten Dateien ging es damit auch noch nicht.
Gruß,
Stefan
Hallo Justme,
ich habe sowohl die Philips HueBridge, als auch deCONZ /ConbeeII. Beide benutzen ja im Moment die 30_HUEBridge.pm.
Kann ich denn dann auch die neue 30_HUEBridge.pm mit der neuen push api unterstützung für beides (Philips HueBridge und deCONZ) benutzen, oder unterstützt die neue 30_HUEBridge.pm nur für die Philips HueBridge?
Hier im Thread habe ich nichts dazu gefunden.
Beste Grüsse, Jamo
ja. geht wie gehabt für beides. das modul erkennt welche event methode verwendet wird.
Hallo Andre,
mir ist gerade was aufgefallen. Ich habe ein HueSwitchDimmer, der wollte sein Batteriestand nicht mehr ordentlich übermitteln. Den habe ich nun gelöscht und neu angelernt. Bei dem ist komischerweise der State Modus wieder falsch und es fehlt die Anfangsziffer. Bei allen anderen die schon länger angemeldet sind, ist alles richtig.
-> Neu angelernter Dimmer
Internals:
CFGFN
DEF sensor 222 IODev=HUEBridge1
FUUID 61e7ccd1-f33f-96bc-70c8-18bd1c798b235828
FVERSION 31_HUEDevice.pm:0.254730/2022-01-16
ID S222
INTERVAL
IODev HUEBridge1
NAME HUEBridge1_HUESensor222
NR 50252
STATE 002
TYPE HUEDevice
inputs 4
lastupdated 2022-01-19 09:16:18
lastupdated_local 2022-01-19 10:16:18
manufacturername Signify Netherlands B.V.
modelid RWL021
name BadObenSwitch
on 1
productname Hue dimmer switch
reachable 1
swversion 6.1.1.28573
type ZLLSwitch
uniqueid 00:17:88:01:04:ec:ab:a7-02-fc00
v2_id bb563195-fb49-4b06-a563-461021079dc2
READINGS:
2022-01-19 10:15:57 battery 100
2022-01-19 10:15:57 batteryPercent 100
2022-01-19 10:15:57 reachable 1
2022-01-19 10:16:18 state 002
helper:
devtype S
fromAutocreate 1
reachable 0
update_timeout 1
capabilities:
inputs:
HASH(0x557e6b74a570)
HASH(0x557e6b6269e8)
HASH(0x557e6ae24458)
HASH(0x557e6b662f38)
configList:
events:
HASH(0x557e6a000190)
HASH(0x557e6b41c4a0)
HASH(0x557e6b57cbc0)
HASH(0x557e66a86ff0)
json:
v2_id bb563195-fb49-4b06-a563-461021079dc2
v2_service ea492ebc-e70d-4165-aa13-f2f4fad92e3b
state:
buttonevent 002
lastupdated 2022-01-19T09:16:18
setList:
Attributes:
IODev HUEBridge1
alias BadObenSwitch
group HUESensor
model RWL021
room HUEDevice
-> Bestehender Dimmer
Internals:
CFGFN
CHANGED
DEF sensor 46 IODev=HUEBridge1
FUUID 61e71fec-f33f-96bc-4335-40af594431b46e69
FVERSION 31_HUEDevice.pm:0.254730/2022-01-16
ID S46
INTERVAL
IODev HUEBridge1
NAME HUE_BadUnten_Schalter
NR 43312
STATE 4002
TYPE HUEDevice
inputs 4
lastupdated 2022-01-19 09:16:27
lastupdated_local 2022-01-19 10:16:27
manufacturername Signify Netherlands B.V.
modelid RWL021
name BadUntenSwitch
on 1
productname Hue dimmer switch
reachable 1
swversion 6.1.1.28573
type ZLLSwitch
uniqueid 00:17:88:01:03:e4:60:aa-02-fc00
v2_id 53d1ea7c-21fc-498c-b2dd-38fc1b75054f
READINGS:
2022-01-19 10:16:27 battery 100
2022-01-19 10:16:27 batteryPercent 100
2022-01-19 10:16:27 reachable 1
2022-01-19 10:16:27 state 4002
helper:
devtype S
reachable 0
update_timeout 1
capabilities:
inputs:
HASH(0x557e6ae0a888)
HASH(0x557e6b5b9fc0)
HASH(0x557e6b3f1328)
HASH(0x557e6ada0940)
configList:
events:
HASH(0x557e6b7240e0)
HASH(0x557e6b322828)
HASH(0x557e6b64a520)
HASH(0x557e6b48d288)
json:
diversityid 73bbabea-3420-499a-9856-46bf437e119b
manufacturername Signify Netherlands B.V.
modelid RWL021
name BadUntenSwitch
productname Hue dimmer switch
swversion 6.1.1.28573
type ZLLSwitch
uniqueid 00:17:88:01:03:e4:60:aa-02-fc00
capabilities:
inputs:
HASH(0x557e6b9ae2b0)
HASH(0x557e6b463a50)
HASH(0x557e6b53f010)
HASH(0x557e6b659668)
config:
battery 100
pending:
state:
buttonevent 4002
lastupdated 2022-01-19T09:16:27
swupdate:
lastinstall 2019-10-09T12:20:40
state noupdates
setList:
Attributes:
IODev HUEBridge1
event-on-change-reading .*
model RWL021
mqttPublish *:topic={"FHEM/$device/$reading"}
room 11_BadUnten
wenn beim fhem start das gerät in der bridge noch nicht bekannt war fehlt die gerätebeschreibung weil die daten nur ein mal ausgelesen werden. ich überlege mir was.
Ah okay, ein "set HUEBridge1 reconnect" klappte dann natürlich :D
kannst du bitte mal in deinem log schauen ob es etwas mit unknown event type oder unknown event etwa zu der zeit gibt als du den dimmer gelöscht und wieder angelegt hast?
Wenn ich das Device (Dimmer) in Fhem lösche und wieder mit Autocreate anlege funktioniert es danach wieder.
Habe dann den in der Hue App gelöscht und neu angelegt. Danach autocreate und der Fehler ist wieder da. Habe auf verbose 5 vorher gestellt, daher ist das Log sehr voll, aber ich habe diese Einträge gefunden:
2022.01.19 11:26:15.986 3: HUEBridge1: unknown event type add:
2022.01.19 11:26:15.986 3: HUEBridge1: unknown event type add:
2022.01.19 11:26:15.987 3: HUEBridge1: unknown event type add:
2022.01.19 11:26:15.987 3: HUEBridge1: unknown event type add:
2022.01.19 11:26:15.987 3: HUEBridge1: unknown event type add:
2022.01.19 11:26:15.987 3: HUEBridge1: unknown event type add:
2022.01.19 11:26:15.987 3: HUEBridge1: unknown event type add:
2022.01.19 11:26:15.987 5: HUEBridge1: got update event
2022.01.19 11:26:15.987 4: HUEBridge1: created from event: $VAR1 = {
'v2_id' => '3f577a9a-7ab4-49dc-a5a4-ca9b48c15c4e',
'v2_service' => '3f577a9a-7ab4-49dc-a5a4-ca9b48c15c4e',
'state' => {
'lastupdated' => '2022-01-19T10:26:15'
}
};
2022.01.19 11:26:37.682 4: HUEBridge1: create new sensor 'HUEBridge1_HUESensor225' for address '225'
2022.01.19 11:26:37.682 3: HUEBridge1_HUESensor225: I/O device is HUEBridge1
2022.01.19 11:26:37.683 4: using HttpUtils_NonblockingGet: GET sensors/225
2022.01.19 11:26:37.775 2: HUEBridge1: autocreate: created 0;0;1 devices (ignored 0;0;13)
2022.01.19 11:26:37.828 5: HUEBridge_dispatch: sensors/225
2022.01.19 11:27:12.151 5: HUEBridge_dispatch: event
2022.01.19 11:27:12.151 4: EventStream: connected
2022.01.19 11:27:12.151 5: HUEBridge1: EventStream: got id: 1642588032:0
2022.01.19 11:27:12.151 5: HUEBridge1: EventStream: got data: [{"creationtime":"2022-01-19T10:27:12Z","data":[{"button":{"last_event":"initial_press"},"id":"3f3ec831-1458-40ea-8974-eb4061d96542","id_v1":"/sensors/225","owner":{"rid":"8dd2b34d-b570-4fb8-97c4-f7f4e8d58a75","rtype":"device"},"type":"button"}],"id":"0423b8eb-e21d-4be7-900b-3c963c5ba027","type":"update"}]
2022.01.19 11:27:12.151 4: HUEBridge1: received: $VAR1 = [
{
'data' => [
{
'id_v1' => '/sensors/225',
'id' => '3f3ec831-1458-40ea-8974-eb4061d96542',
'button' => {
'last_event' => 'initial_press'
},
'owner' => {
'rid' => '8dd2b34d-b570-4fb8-97c4-f7f4e8d58a75',
'rtype' => 'device'
},
'type' => 'button'
}
],
'type' => 'update',
'id' => '0423b8eb-e21d-4be7-900b-3c963c5ba027',
'creationtime' => '2022-01-19T10:27:12Z'
}
];
2022.01.19 11:27:12.151 5: HUEBridge1: got update event
2022.01.19 11:27:12.151 4: HUEBridge1: created from event: $VAR1 = {
'v2_service' => '3f3ec831-1458-40ea-8974-eb4061d96542',
'v2_id' => '8dd2b34d-b570-4fb8-97c4-f7f4e8d58a75',
'state' => {
'lastupdated' => '2022-01-19T10:27:12',
'buttonevent' => '000'
}
};
sehr gut!
ganz oben gibt es noch mal eine version. die müsste damit klar kommen.
Zitat von: justme1968 am 19 Januar 2022, 12:15:36
sehr gut!
ganz oben gibt es noch mal eine version. die müsste damit klar kommen.
funktioniert ! Danke
Mit der neuen Version kommt, dass man das speichern soll "deleteAttr HUEBridge1 pollDevices" und die Meldungen sammeln sich.
das ganze ist seit eben eingecheckt und ab morgen per update verfügbar. mal sehen ob es überall so gut läuft...
Bekommt man die Meldung von dem Löschen der PollDevices denn irgendwie weg?
Lag es nun eigentlich an der httpUtils.pm, dass es im DockerContainer funktioniert?
Gruß,
Stefan
Hallo justme1968,
danke für deine Erweiterung. Habe den Stand von gestern bei mir am Laufen. Ohne Probleme!
Werde mir morgen den neusten Stand über Update holen.
Klasse.
Gruß Michael
@stera: die meldung sollte in der eingecheckten version nur ein mal erscheinen.
ich habe keine ahnung warum es bei dir plötzlich geht. wie gesagt gehen alle verbindungen von fhem aus und das sollte selbst mit docker immer gehen. da es bei dir auch mit manuellem reconnect nicht ging war es nicht das gleiche problem wie bei knorxi aber eventuell wurden die daten durch docker auf dem socket so unglücklich gestückelt das es ohne die httputils änderung garnicht ging.
Hallo Justme,
nach dem heutigen update, kommen bei mir für die 3 HueDimmer, die ich habe, sporadisch folgende Events, obwohl ich keinen Knopf gedrückt habe:
Es kommt immer die 3002, andere Events nicht.
[myHueDimmer] Name=HueDimmer1_Kueche, EVENT=3002, Room=Kueche
Internals:
DEF 172.21.0.33
EventStream connected
FUUID 5c42ee42-f33f-97bf-156f-3d2ea75368dbc5c7
FVERSION 30_HUEBridge.pm:0.255060/2022-01-19
INTERVAL 60
NAME PhilipsHue
NOTIFYDEV global
NR 2146
NTFY_ORDER 50-PhilipsHue
STATE connected
TYPE HUEBridge
apiversion 1.48.0
bridgeid 12345678
has_v2_api 1
host MEI.NE.IP.AD
mac 00:17:88:25:3f:fa
manufacturer Signify
modelName Philips hue bridge 2015
modelid BSB002
name Philips Hue
swversion 1948086000
updatestate 0
zigbeechannel 15
READINGS:
2021-06-09 15:48:24 alert none
2022-01-19 23:22:51 lastError parameter, xy, is not modifiable. Device is set to off.
2021-06-09 15:51:50 onoff 0
2021-06-09 15:51:50 pct 0
2021-06-09 15:48:24 reachable 1
2022-01-20 09:13:14 state connected
2021-09-18 21:37:25 swupdate ZGB_100B_010F - LedStrips-SAMR21 - 16.0
helper:
apiversion 77824
count 0
last_config_timestamp 1642666394
offsetUTC 3600
updatestate 0
HTTP_CONNECTION:
EventSource 1
FD 12
NAME
addr https://MEI.NE.IP.AD:443
auth 0
buf
compress 1
displayurl https://MEI.NE.IP.AD/eventstream/clip/v2
header Last-Event-ID: 1642651718:0
Accept: text/event-stream
HUE-Application-Key: 12345
host MEI.NE.IP.AD
httpdata
httpdatalen -1
httpheader HTTP/1.1 200 OK
Server: nginx
Date: Thu, 20 Jan 2022 05:08:38 GMT
Content-Type: text/event-stream; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
Cache-Control: no-store
Pragma: no-cache
Referrer-Policy: no-referrer
httpversion 1.1
hu_blocking 0
hu_inProgress HUEBridge_openEventStream:2204 HUEBridge_dispatch:110 HttpUtils_TimeoutErr:3428 HandleTimeout:696
hu_port 443
hu_portSfx
hu_sslAdded 1
incrementalTimeout 1
keepalive 1
lastID 1642666387:0
loglevel 4
method GET
noshutdown 1
path /eventstream/clip/v2
protocol https
redirects 0
timeout 3600
type event
url https://MEI.NE.IP.AD/eventstream/clip/v2
hash:
sslargs:
groups:
könnte es sein das ein button klemmt? bitte schau mal mit verbose 4 ins log und zeig was genau für ein event von der bridge kommt.
Nein, ein Button klemmt definitiv nicht, die Events sind erst nach update auf die neue version gekommen.
Ich habe jetzt erstmal die "interval" definition aus der DEF der HueDimmer rausgenommen, ich schau mal ob das die Ursache ist.
wenn du die aktuelle version aus dem update heute verwendest werden die intervalle automatisch deaktiviert sobald der eventstream steht. das sollte so auch im log stehen.
wie gesagt wäre es hilfreich die nakten bridge events aus dem log zu sehen.
aktuelle Version geht soweit ich feststellen kann prima, bis auf eine Warnung aus der Deconz Version "2.13.4"
Vielleicht ist das u.U. noch zu beheben.
2022.01.20 10:11:18 1: PERL WARNING: Argument "2.13.4" isn't numeric in numeric ge (>=) at ./FHEM/30_HUEBridge.pm line 483.
2022.01.20 10:11:18 1: stacktrace:
2022.01.20 10:11:18 1: main::__ANON__ called by ./FHEM/30_HUEBridge.pm (483)
2022.01.20 10:11:18 1: main::HUEBridge_fillBridgeInfo called by ./FHEM/30_HUEBridge.pm (552)
2022.01.20 10:11:18 1: main::HUEBridge_OpenDev called by ./FHEM/30_HUEBridge.pm (321)
2022.01.20 10:11:18 1: main::HUEBridge_Notify called by fhem.pl (3896)
2022.01.20 10:11:18 1: main::CallFn called by fhem.pl (3813)
2022.01.20 10:11:18 1: main::DoTrigger called by fhem.pl (677)
2022.01.20 10:11:25 1: PERL WARNING: Argument "2.13.4" isn't numeric in numeric ge (>=) at ./FHEM/30_HUEBridge.pm line 483.
2022.01.20 10:11:25 1: stacktrace:
2022.01.20 10:11:25 1: main::__ANON__ called by ./FHEM/30_HUEBridge.pm (483)
2022.01.20 10:11:25 1: main::HUEBridge_fillBridgeInfo called by ./FHEM/30_HUEBridge.pm (1717)
2022.01.20 10:11:25 1: main::HUEBridge_Parse called by ./FHEM/30_HUEBridge.pm (2466)
2022.01.20 10:11:25 1: main::HUEBridge_dispatch called by FHEM/HttpUtils.pm (647)
2022.01.20 10:11:25 1: main::__ANON__ called by fhem.pl (771)
sollte ab morgen weg sein
Zitatbitte schau mal mit verbose 4 ins log und zeig was genau für ein event von der bridge kommt.
Ich habe gesehen, ratman hat unter dem Thread [22.01.22] hue switch schaltet von selber dasselbe problem. Hier mein Log 4, das event kommt unter: 2022.01.20 13:10:20 3: [myHueDimmer] Name=HueDimmer1_Schlaf, EVENT=3002, Room=Schlaf
2022.01.20 13:09:20 4: PhilipsHue: message for unknown sensor received: PhilipsHue-S1
2022.01.20 13:09:20 4: PhilipsHue: message for unknown sensor received: PhilipsHue-S5
2022.01.20 13:09:20 4: PhilipsHue: message for unknown sensor received: PhilipsHue-S8
2022.01.20 13:09:20 3: PhilipsHue: message for unknown device received: PhilipsHue-51
2022.01.20 13:09:20 3: PhilipsHue: message for unknown device received: PhilipsHue-52
2022.01.20 13:09:59 4: PhilipsHue: dispatch
2022.01.20 13:09:59 4: name: EventStream: connected
2022.01.20 13:09:59 4: PhilipsHue: received: [
{
'data' => [
{
'type' => 'device_power',
'id' => '66214ac8-9e14-49c6-8cc5-fc2f9335cb35',
'id_v1' => '/sensors/6',
'owner' => {
'rid' => '177ed269-21fd-4926-a6b7-9105566e7416',
'rtype' => 'device'
},
'power_state' => {
'battery_state' => 'normal',
'battery_level' => 70
}
}
],
'id' => 'ebe32606-3dc2-4121-a952-c676b17a440a',
'creationtime' => '2022-01-20T12:09:59Z',
'type' => 'update'
}
]
2022.01.20 13:09:59 4: PhilipsHue: got update event
2022.01.20 13:09:59 4: PhilipsHue: created from event: {
'v2_service' => '66214ac8-9e14-49c6-8cc5-fc2f9335cb35',
'v2_id' => '177ed269-21fd-4926-a6b7-9105566e7416',
'state' => {
'lastupdated' => '2022-01-20T12:09:59'
}
}
2022.01.20 13:10:20 4: using HttpUtils_NonblockingGet: GET
2022.01.20 13:10:20 4: PhilipsHue: dispatch
2022.01.20 13:10:20 4: PhilipsHue: parse status message
2022.01.20 13:10:20 4: PhilipsHue: message for unknown sensor received: PhilipsHue-S1
2022.01.20 13:10:20 4: PhilipsHue: message for unknown sensor received: PhilipsHue-S5
2022.01.20 13:10:20 3: [myHueDimmer] Name=HueDimmer1_Schlaf, EVENT=3002, Room=Schlaf
2022.01.20 13:10:20 4: PhilipsHue: message for unknown sensor received: PhilipsHue-S8
2022.01.20 13:10:20 3: PhilipsHue: message for unknown device received: PhilipsHue-52
2022.01.20 13:10:20 3: PhilipsHue: message for unknown device received: PhilipsHue-51
2022.01.20 13:11:20 4: using HttpUtils_NonblockingGet: GET
2022.01.20 13:11:20 4: PhilipsHue: dispatch
2022.01.20 13:11:20 4: PhilipsHue: parse status message
2022.01.20 13:11:20 4: PhilipsHue: message for unknown sensor received: PhilipsHue-S8
2022.01.20 13:11:20 4: PhilipsHue: message for unknown sensor received: PhilipsHue-S5
2022.01.20 13:11:20 4: PhilipsHue: message for unknown sensor received: PhilipsHue-S1
2022.01.20 13:11:20 3: PhilipsHue: message for unknown device received: PhilipsHue-52
2022.01.20 13:11:20 3: PhilipsHue: message for unknown device received: PhilipsHue-51
laut log sendet tatsächlich die bridge ein event.
kommt bei jedem mal ein echtes event von der bridge? ändert sich lastupdated?
Echtes event von der Bridge, in dem Sinne, das ich das HueDimmer Event im Eventmonitor sehe, und dass das notify darauf reagiert.
Bei mir sind wie bei Ratman auf einmal wundersame Sachen passiert, die ich mir nicht erklären konnte, bis ich drauf gekommen bin, das es von den Dimmer Events kommt.
Last updated ändert sich nicht (timestamp ist also noch von gestern, der Auszug aus dem log ist ja von heute):
Und ja, ich hatte mir gestern schon die neue version aus dem svn gezogen.
Internals:
DEF sensor 6 IODev=PhilipsHue
FUUID 5c42ee43-f33f-97bf-71d8-09f4178d739ba478
FVERSION 31_HUEDevice.pm:0.255060/2022-01-19
ID S6
INTERVAL
IODev PhilipsHue
NAME HueDimmer1_Schlaf
NR 2203
STATE 3002
TYPE HUEDevice
has_v2_api 1
inputs 4
lastupdated 2022-01-19 18:16:00
lastupdated_local 2022-01-19 19:16:00
manufacturername Signify Netherlands B.V.
modelid RWL021
name HueDimmerSchlaf1
on 1
productname Hue dimmer switch
reachable 1
swversion 6.1.1.28573
type ZLLSwitch
uniqueid 00:17:88:01:03:a5:8a:65-02-fc00
v2_id 177ed269-21fd-4926-a6b7-9105566e7416
READINGS:
2021-02-04 10:33:41 BatterieWechsel 01.6.2020
2022-01-20 09:31:16 IODev PhilipsHue
2022-01-19 19:16:00 battery 69
2022-01-19 19:16:00 batteryPercent 69
2022-01-19 19:16:00 reachable 1
2022-01-19 19:16:00 state 3002
helper:
devtype S
reachable 0
update_timeout 1
capabilities:
inputs:
die creationtime im event (2022-01-20T12:09:59Z) ist aber von heute gerade eben.
es gibt also zwei fragen: warum sendet die bridge das event überhaupt, und warum haben trozdem lastupdated und lastupdated_local in den internals noch den wert von gestern...
mit echt meinte ich das die bridge einevent im event stream sendet. das ist noch kein event im fhem sinne.
es gibt drei 'events':
- das was die bridge sendet (steht im log hinter received:)
- das was das bridge modul daraus macht und ans device modul weiter gibt (steht im log hinter created from event)
- das was fhem erzeugt sobald sich ein reading ändert (nur das kann man im event monitor sehen)
wie kannst du ein event im eventmonitor sehen wenn das reading garnicht geändert wird?
Der Hue-Bewegungsmelder hat einen "Zustandssensor" (HueMotionSensorState).
Ich habe ein paar Regeln, die den "status" verändern.
Leider wird im Eventstream diese Änderung nicht übermittelt (hoffentlich bauen die API-Entwickler das noch ein).
Zumindest habe es mit folgendem Befehl nicht gesehen:
curl --insecure -N -H 'hue-application-key: <appkey>' -H 'Accept: text/event-stream' https://<ipaddress>/eventstream/clip/v2
In FHEM frage ich daher den Sensor mit INTERVAL alle 10s ab, um auf die Statusänderung reagieren zu können.
Sehe ich das richtig, dass diese Abfrage nun so nicht mehr funktioniert, da das Polling gelöscht wird, wenn der Eventstream aktiv ist?
Falls ja, kannst du vielleicht eine Ausnahme für diese Art von Sensoren einbauen?
Internals:
DEF sensor 21 10 IODev=HUEBridge
FUUID 5c44d944-f33f-8d65-3ce8-b9dc9f937ac3caec
FVERSION 31_HUEDevice.pm:0.255060/2022-01-19
ID S21
INTERVAL 10
IODev HUEBridge
NAME HueMotionSensorState
NR 431
STATE 0
TYPE HUEDevice
has_v2_api 1
lastupdated 2022-01-20 15:04:00
lastupdated_local 2022-01-20 16:04:00
manufacturername Philips
modelid PHA_STATE
name MotionSensor 18.Companion
on 1
reachable 1
swversion 1.0
type CLIPGenericStatus
uniqueid MotionSensor 18.Companion
READINGS:
2022-01-20 14:24:22 IODev HUEBridge
2022-01-20 16:04:00 reachable 1
2022-01-20 16:04:00 state 0
helper:
devtype S
update_timeout 1
configList:
json:
manufacturername Philips
modelid PHA_STATE
name MotionSensor 18.Companion
swversion 1.0
type CLIPGenericStatus
uniqueid MotionSensor 18.Companion
config:
state:
lastupdated 2022-01-20T15:04:00
status 0
setList:
Attributes:
IODev HUEBridge
alias Nachtlicht Zustand
group HUESensor
model PHA_STATE
room HUEDevice
das device sollte trozdem alle 60 sekunden über das pollen das in der bridge selber noch aktiv ist ausgelesen werden.
aber ab morgen wird das polling für ein device erst deaktiviert wenn das erste event für dieses device empfangen wurde. vielleicht magst du gleich schon mal testen ob das hilft.
wenn das nicht reicht und es aus irgendeinem grund trozdem manchmal events gibt könnte man überlegen ob man die CLIPGenericStatus sensoren vom deaktivieren ausnimmt. vom autocreate sind sie auch schon ausgenommen.
@Jamo: ich glaube ich habe das problem gefunden. beim genau hinschauen sieht man das die events von der bridge keine tastendrücke sondern batterie events sind. die wurden noch garnicht behandelt und deshalb ein leeres event an das fhem device weiter gereicht.
ich habe es gerade repariert und eingecheckt.
warum das battery event so oft von der bridge gesendet wird weiss ich nicht.
und warum dort aber ein fhem event erzeugt wird das dann deine notifys triggert verstehe ich nicht.
könntest du bevor du die neueste version verwendest mal schauen was genau im event monitor für ein event angekommen ist?
Zitatkönntest du bevor du die neueste version verwendest mal schauen was genau im event monitor für ein event angekommen ist?
Gerne, siehe Eventmonitor Auszug, diesmal habe ich den fhem.log mit reingeschrieben. Besagtes EVENT=1002 (diesmal ist es 1002) findest Du Zeile 21 von unten. Mir faellt auf, wie bei Ratman, hat das Event aber einen eigenartigen Zeitstempel. Das " [myHueDimmer] Name=HueDimmer1_Schlaf, EVENT=1002, Room=Schlaf" ist der log, mit dem namen der sub in der 99_MyUtils.pm
Jetzt mache ich mal das update au die neue Version und berichte . . .
2022.01.20 19:55:20 3 : PhilipsHue: message for unknown device received: PhilipsHue-51
2022.01.20 19:55:36 4 : PhilipsHue: dispatch
2022.01.20 19:55:36 2 : PhilipsHue: http request failed: read from https://MEI.NE.IP.AD:443 timed out
2022.01.20 19:55:36 2 : name: EventStream: terminated
2022.01.20 19:55:36 4 : name: EventStream: closing
2022.01.20 19:55:36 4 : name: EventStream: closed
2022.01.20 19:55:36 4 : name: EventStream: connecting
2022.01.20 19:55:36 4 : PhilipsHue: dispatch
2022.01.20 19:55:36 4 : name: EventStream: connected
2022.01.20 19:55:37 4 : PhilipsHue: dispatch
2022.01.20 19:55:37 4 : name: EventStream: connected
2022.01.20 19:55:37 4 : PhilipsHue: received: [
{
'type' => 'update',
'creationtime' => '2022-01-20T18:49:00Z',
'data' => [
{
'type' => 'light',
'color' => {
'xy' => {
'y' => '0.4147',
'x' => '0.4879'
}
},
'id' => 'b1cf4455-b3c8-4eb1-98bf-a3652ead7a80',
'id_v1' => '/lights/42',
'owner' => {
'rid' => '7057ec04-eb7a-4a77-a3a0-27331f4fc26d',
'rtype' => 'device'
},
'color_temperature' => {
'mirek' => 420,
'mirek_valid' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
}
}
],
'id' => '13c8f792-eab6-4fe1-85f9-60961a59a96a'
}
]
2022.01.20 19:55:37 4 : PhilipsHue: got update event
2022.01.20 19:55:37 4 : PhilipsHue: created from event: {
'state' => {
'colormode' => 'ct',
'xy' => [
'0.4879',
'0.4147'
],
'lastupdated' => '2022-01-20T18:49:00',
'ct' => 420
},
'v2_id' => '7057ec04-eb7a-4a77-a3a0-27331f4fc26d',
'v2_service' => 'b1cf4455-b3c8-4eb1-98bf-a3652ead7a80'
}
2022.01.20 19:55:37 4 : PhilipsHue: dispatch
2022.01.20 19:55:37 4 : name: EventStream: connected
2022.01.20 19:55:37 4 : PhilipsHue: received: [
{
'type' => 'update',
'id' => '661b23b7-e856-4ee4-9042-0752560a2a80',
'data' => [
{
'type' => 'light',
'color' => {
'xy' => {
'x' => '0.4879',
'y' => '0.4147'
}
},
'id' => 'b1cf4455-b3c8-4eb1-98bf-a3652ead7a80',
'id_v1' => '/lights/42',
'owner' => {
'rid' => '7057ec04-eb7a-4a77-a3a0-27331f4fc26d',
'rtype' => 'device'
},
'color_temperature' => {
'mirek_valid' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'mirek' => 420
}
}
],
'creationtime' => '2022-01-20T18:50:05Z'
}
]
2022.01.20 19:55:37 4 : PhilipsHue: got update event
2022.01.20 19:55:37 4 : PhilipsHue: created from event: {
'state' => {
'xy' => [
'0.4879',
'0.4147'
],
'ct' => 420,
'lastupdated' => '2022-01-20T18:50:05',
'colormode' => 'ct'
},
'v2_service' => 'b1cf4455-b3c8-4eb1-98bf-a3652ead7a80',
'v2_id' => '7057ec04-eb7a-4a77-a3a0-27331f4fc26d'
}
2022.01.20 19:55:37 4 : PhilipsHue: dispatch
2022.01.20 19:56:07 4 : PhilipsHue: dispatch
2022.01.20 19:56:07 4 : name: EventStream: connected
2022.01.20 19:56:07 4 : PhilipsHue: received: [
{
'data' => [
{
'power_state' => {
'battery_state' => 'normal',
'battery_level' => 76
},
'owner' => {
'rid' => '177ed269-21fd-4926-a6b7-9105566e7416',
'rtype' => 'device'
},
'id_v1' => '/sensors/6',
'id' => '66214ac8-9e14-49c6-8cc5-fc2f9335cb35',
'type' => 'device_power'
}
],
'id' => 'cfb71f6e-222d-4eb4-9dfb-1fe1acc814ca',
'creationtime' => '2022-01-20T18:56:07Z',
'type' => 'update'
}
]
2022.01.20 19:56:07 4 : PhilipsHue: got update event
2022.01.20 19:56:07 4 : PhilipsHue: created from event: {
'state' => {
'lastupdated' => '2022-01-20T18:56:07'
},
'v2_id' => '177ed269-21fd-4926-a6b7-9105566e7416',
'v2_service' => '66214ac8-9e14-49c6-8cc5-fc2f9335cb35'
}
2022.01.20 19:56:10 4 : using HttpUtils_NonblockingGet: PUT lights/42/state
2022.01.20 19:56:10 4 : PhilipsHue: dispatch
2022.01.20 19:56:10 4 : PhilipsHue: dispatch
2022.01.20 19:56:10 4 : name: EventStream: connected
2022.01.20 19:56:10 4 : PhilipsHue: received: [
{
'id' => 'cff081bf-51d4-40d9-9bcc-af7ed64942f8',
'data' => [
{
'color_temperature' => {
'mirek_valid' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'mirek' => 420
},
'owner' => {
'rtype' => 'device',
'rid' => '7057ec04-eb7a-4a77-a3a0-27331f4fc26d'
},
'color' => {
'xy' => {
'x' => '0.4879',
'y' => '0.4147'
}
},
'type' => 'light',
'id' => 'b1cf4455-b3c8-4eb1-98bf-a3652ead7a80',
'id_v1' => '/lights/42'
}
],
'creationtime' => '2022-01-20T18:56:10Z',
'type' => 'update'
}
]
2022.01.20 19:56:10 4 : PhilipsHue: got update event
2022.01.20 19:56:10 4 : PhilipsHue: created from event: {
'v2_id' => '7057ec04-eb7a-4a77-a3a0-27331f4fc26d',
'v2_service' => 'b1cf4455-b3c8-4eb1-98bf-a3652ead7a80',
'state' => {
'ct' => 420,
'lastupdated' => '2022-01-20T18:56:10',
'xy' => [
'0.4879',
'0.4147'
],
'colormode' => 'ct'
}
}
2022.01.20 19:56:20 4 : using HttpUtils_NonblockingGet: GET
2022.01.20 19:56:20 4 : PhilipsHue: dispatch
2022.01.20 19:56:20 4 : PhilipsHue: parse status message
2022.01.20 19:56:20 4 : PhilipsHue: message for unknown sensor received: PhilipsHue-S1
2022.01.20 19:56:20 4 : PhilipsHue: message for unknown sensor received: PhilipsHue-S5
2022.01.20 19:56:20 3 : [myHueDimmer] Name=HueDimmer1_Schlaf, EVENT=1002, Room=Schlaf
2022-01-20 19:17:23 HUEDevice HueDimmer1_Schlaf 1002
2022.01.20 19:56:20 4 : PhilipsHue: message for unknown sensor received: PhilipsHue-S8
2022.01.20 19:56:20 3 : PhilipsHue: message for unknown device received: PhilipsHue-52
2022.01.20 19:56:20 3 : PhilipsHue: message for unknown device received: PhilipsHue-51
2022.01.20 19:56:57 4 : using HttpUtils_NonblockingGet: PUT lights/42/state
2022.01.20 19:56:57 4 : PhilipsHue: dispatch
2022.01.20 19:56:58 4 : using HttpUtils_NonblockingGet: GET lights/42
2022.01.20 19:56:58 4 : PhilipsHue: dispatch
2022.01.20 19:57:00 4 : using HttpUtils_NonblockingGet: PUT lights/42/state
2022.01.20 19:57:00 4 : PhilipsHue: dispatch
2022.01.20 19:57:01 4 : using HttpUtils_NonblockingGet: GET lights/42
2022.01.20 19:57:01 4 : PhilipsHue: dispatch
2022.01.20 19:57:20 4 : using HttpUtils_NonblockingGet: GET
2022.01.20 19:57:20 4 : PhilipsHue: dispatch
2022.01.20 19:57:20 4 : PhilipsHue: parse status message
2022.01.20 19:57:20 4 : PhilipsHue: message for unknown sensor received: PhilipsHue-S1
2022.01.20 19:57:20 4 : PhilipsHue: message for unknown sensor received: PhilipsHue-S5
2022.01.20 19:57:20 4 : PhilipsHue: message for unknown sensor received: PhilipsHue-S8
2022.01.20 19:57:20 3 : PhilipsHue: message for unknown device received: PhilipsHue-52
2022.01.20 19:57:20 3 : PhilipsHue: message for unknown device received: PhilipsHue
Hi,
wollte nur der Vollständigkeithalber sagen, dass ich auch solche Effekte mit meinen Hue-Dimmer-Switches habe.... hoffen wir mal, dass es die Batterie-Events sind :*)
@Jamo: achtung: das ist nicht der event monitor. das ist das log. den eventmonitor finest du links unten in fhemweb.
wer schreibt das '[myHueDimmer] Name=HueDimmer1_Schlaf, EVENT=1002, Room=Schlaf' ins log? die hue module sind es nicht.
die zeiten der beiden zeilen: 2022.01.20 19:56:20 3 : [myHueDimmer] Name=HueDimmer1_Schlaf, EVENT=1002, Room=Schlaf
2022-01-20 19:17:23 HUEDevice HueDimmer1_Schlaf 1002
passen auch nicht zusammen.
Hallo Justme,
doch, ja klar, das ist der Eventmonitor. Ich habe erst links den Eventmonitor aufgerufen, dann ober im Eventmonitor das FHEM.log mit angeklickt, dann wird der inhalt vom logfile auch mit in den Eventmonitor geschrieben. Den Eventmonitor habe ich auf den Filter .*Hue.* gesetzt, damit ich nur die Events mit .*Hue.* logge.
Was ich Dir geschickt habe, ist die Kopie vom Eventmonitor, den ich solange laufen lassen habe, bis das HueDimmer event wieder auftritt.
PS: bei Ratman war doch auch was mit dem Zeitstempel, der nicht passt.
PS2: die neue Version von heute mit dem Fix Battery hilft nicht, die Events treten immer noch auf. . . .
Das '[myHueDimmer] Name=HueDimmer1_Schlaf, EVENT=1002, Room=Schlaf' kommt von folgendem notify / sub:
define HueDimmer_n notify HueDimmer._.*:.00. {myHueDimmer($NAME,$EVENT)}
sub myHueDimmer {
my $sub = 'myHueDimmer';
my $NAME = shift // return "Error, $sub: we need NAME as parameter!";
my $EVENT = shift // return "Error, $sub: we need EVENT as parameter!";
my @Device = split("_", $NAME);
my $Room = $Device[1];
my $enable = 0;
Log 3, "[$sub] Name=$NAME, EVENT=$EVENT, Room=$Room";
}
Hi,
Ich hab mal nen Event-Set von mir:
2022-01-20 19:53:00 HUEDevice OG_BAD_HUE_Schalter battery: 43
2022-01-20 19:53:00 HUEDevice OG_BAD_HUE_Schalter batteryPercent: 43
2022-01-20 19:53:00 HUEDevice OG_BAD_HUE_Schalter reachable: 1
2022-01-20 19:53:00 HUEDevice OG_BAD_HUE_Schalter 4002
Sehr bemerkenswert: das war um 22:05 .... Und gedrückt hatte ich natürlich auch nichts
ich glaube so langsam verstehe ich was passiert.
die bridge sendet ein battery event. da ist ein aktueller timestamp drin. dadurch wird lastupdated im device geändert (natürlich auch in der neuen version die du probiert hattest). irgendwann später pollt die bridge alle devices und bekommt den alten button status mit dem alten timestamp. da bisher nur verglichen wurde ob der neue timestamp ungleich ist statt tatsächlich auch größer wird für den alten tastendruck ein neues event erzeugt. und beim nächsten battery event geht es wieder von vorne los.
ich habe eben einen vorläufigen fix eingecheckt der das verhindern sollte. dann kann ich mir in ruhe was besseres einfallen lassen.
unabhängig davon ist mir aber noch völlig unklar warum dein dimmer (und einer von Ratman) scheinbar dauernd oder zumindest sehr oft battery events schickt. und warum nur der eine bzw. die beiden.
hallo justme,
mit dem neuen 31_HueDevice.pm startet fhem nicht mehr substr outside of string at ./FHEM/31_HUEDevice.pm line 1806.
Rückmeldung zum HueMotionSensorState:
Ich habe deine Version seit gestern Abend am laufen.
INTERVAL wird nicht gelöscht. Der "status" wird wie gewollt alle 10s abgefragt. Sieht also gut aus.
Allerdings gibt es ein neues Problem:
Wenn der "status" 0 ist dann wird er nicht geändert / erkannt.
Er bleibt dann auf dem vorherigen "status".
Alle anderen Werte (1,2,3) sind kein Problem.
Wenn ich den Sensor mit "Get" über /api/<username>/sensors/21 abfrage, so sehe ich dass der "status" 0 ist.
Selbst ein "set HueMotionSensorState statusRequest" bringt nichts.
ich denke ich habe beide probleme repariert.
es ist höchste zeit das ich den code teil für die update zeit komplett neu mache. der ist ursprünglich nicht von mir und hat wie man sieht ein paar probleme. eber erst mal muss mindestens so gut laufen wie die version ohne events.
Hallo justme,
der fix von heute morgen funktioniert immer noch nicht.
Allerdings sehe ich jetzt auch, das sich im Device (also im HueDimmer) zum Zeitpunkt des Events, sich das Reading 'batteryState normal' ändert, also deine Vermutung, dass es an den Batterie Readings liegt, macht Sinn. Ich hatte in dem Auszug vom Eventmonitor, den ich Dir geschickt hatte, das event-on-change-reading vom HueDimmer auf 'state' gesetzt, deswegen haben wir die Events / Änderungen vom batteryState nie gesehen. Kann ich Dir irgendwie noch helfen bei der Lösung?
Schau mal die timestamps der Readings von heute morgen (also das list ist von gerade):
Batterystate ist von gerade, state von gestern, obwohl das state event gerade reinkommt.
Internals:
DEF sensor 6 IODev=PhilipsHue
FUUID 5c42ee43-f33f-97bf-71d8-09f4178d739ba478
FVERSION 31_HUEDevice.pm:0.255280/2022-01-21
ID S6
INTERVAL
IODev PhilipsHue
NAME HueDimmer1_Schlaf
NR 2203
STATE 1002
TYPE HUEDevice
has_v2_api 1
inputs 4
lastupdated 2022-01-20_18:17:23
lastupdated_local 2022-01-20 19:17:23
manufacturername Signify Netherlands B.V.
modelid RWL021
name HueDimmerSchlaf1
on 1
productname Hue dimmer switch
reachable 1
swversion 6.1.1.28573
type ZLLSwitch
uniqueid 00:17:88:01:03:a5:8a:65-02-fc00
v2_id 177ed269-21fd-4926-a6b7-9105566e7416
READINGS:
2022-01-21 07:57:25 IODev PhilipsHue
2022-01-20 19:17:23 battery 76
2022-01-20 19:17:23 batteryPercent 76
2022-01-21 08:28:16 batteryState normal
2022-01-20 19:17:23 reachable 1
2022-01-20 19:17:23 state 1002
.
Attributes:
IODev PhilipsHue
event-on-update-reading state
model RWL021
room Lights,AllRooms->Schlafzimmer
wenn man nach einem problem mit events sucht ist es natürlich ziemlich doof wenn events ausgeblendet werden...
bitte stell verbose im device mal auf 4. da sollten die timestamps im log protokoliert werden.
ich melde mich nachher noch mal.
Bei mir geht's auch nicht.
Es liegt wohl daran, dass du deine richtige Änderung in 31_HUEDevice.pm, Zeile 1813 auskommentier hast ;):
#&& (!defined($readings{state}) || $readings{state} eq ReadingsVal( $name, 'state', '' ))
Wenn ich # entferne gehts ;D
So jetzt, schau mal 2022.01.21 11:29:28 3 :
Das ist wieder Eventmonitor, mit zusaetzlichen Eintraegen aus dem fhem.log.
Unten das list.
2022.01.21 11:28:28 4 : using HttpUtils_NonblockingGet: GET
2022.01.21 11:28:28 4 : PhilipsHue: dispatch
2022.01.21 11:28:28 4 : PhilipsHue: parse status message
2022.01.21 11:28:28 3 : PhilipsHue: data for unknown sensor received: PhilipsHue-S1
2022.01.21 11:28:28 3 : PhilipsHue: data for unknown sensor received: PhilipsHue-S5
2022.01.21 11:28:28 3 : PhilipsHue: data for unknown sensor received: PhilipsHue-S8
2022.01.21 11:28:28 3 : PhilipsHue: data for unknown device received: PhilipsHue-51
2022.01.21 11:28:28 3 : PhilipsHue: data for unknown device received: PhilipsHue-52
2022.01.21 11:28:57 4 : PhilipsHue: dispatch
2022.01.21 11:28:57 4 : PhilipsHue: EventStream: received: [
{
'id' => 'a265ecaa-2c3a-4736-80ae-7ba0acc1b1c1',
'data' => [
{
'type' => 'device_power',
'power_state' => {
'battery_state' => 'normal',
'battery_level' => 71
},
'id_v1' => '/sensors/6',
'id' => '66214ac8-9e14-49c6-8cc5-fc2f9335cb35',
'owner' => {
'rtype' => 'device',
'rid' => '177ed269-21fd-4926-a6b7-9105566e7416'
}
}
],
'creationtime' => '2022-01-21T10:28:57Z',
'type' => 'update'
}
]
2022.01.21 11:28:57 4 : PhilipsHue: EventStream: got update event
2022.01.21 11:28:57 4 : PhilipsHue: with part for resource type device_power
2022.01.21 11:28:57 4 : PhilipsHue: created from event: {
'v2_service' => '66214ac8-9e14-49c6-8cc5-fc2f9335cb35',
'state' => {
'lastupdated' => '2022-01-21T10:28:57',
'battery_state' => 'normal',
'battery' => 71
},
'v2_id' => '177ed269-21fd-4926-a6b7-9105566e7416'
}
2022-01-21 11:28:57 HUEDevice HueDimmer1_Schlaf batteryState: normal
2022-01-21 11:28:57 HUEDevice HueDimmer1_Schlaf batteryPercent: 71
2022-01-21 11:28:57 HUEDevice HueDimmer1_Schlaf battery: 71
2022.01.21 11:29:28 4 : using HttpUtils_NonblockingGet: GET
2022.01.21 11:29:28 4 : PhilipsHue: dispatch
2022.01.21 11:29:28 4 : PhilipsHue: parse status message
2022.01.21 11:29:28 3 : PhilipsHue: data for unknown sensor received: PhilipsHue-S1
2022.01.21 11:29:28 3 : PhilipsHue: data for unknown sensor received: PhilipsHue-S5
2022.01.21 11:29:28 3 : PhilipsHue: data for unknown sensor received: PhilipsHue-S8
2022.01.21 11:29:28 3 : [myHueDimmer] Name=HueDimmer1_Schlaf, EVENT=1002, Room=Schlaf
2022-01-20 19:17:23 HUEDevice HueDimmer1_Schlaf batteryPercent: 71
2022-01-20 19:17:23 HUEDevice HueDimmer1_Schlaf reachable: 1
2022-01-20 19:17:23 HUEDevice HueDimmer1_Schlaf battery: 71
2022-01-20 19:17:23 HUEDevice HueDimmer1_Schlaf 1002
2022.01.21 11:29:28 3 : PhilipsHue: data for unknown device received: PhilipsHue-51
2022.01.21 11:29:28 3 : PhilipsHue: data for unknown device received: PhilipsHue-52
2022.01.21 11:30:28 4 : using HttpUtils_NonblockingGet: GET
2022.01.21 11:30:28 4 : PhilipsHue: dispatch
2022.01.21 11:30:28 4 : PhilipsHue: parse status message
Internals:
DEF sensor 6 IODev=PhilipsHue
FUUID 5c42ee43-f33f-97bf-71d8-09f4178d739ba478
FVERSION 31_HUEDevice.pm:0.255300/2022-01-21
ID S6
INTERVAL
IODev PhilipsHue
NAME HueDimmer1_Schlaf
NR 2203
STATE 1002
TYPE HUEDevice
has_v2_api 1
inputs 4
lastupdated 2022-01-20_18:17:23
lastupdated_local 2022-01-20 19:17:23
manufacturername Signify Netherlands B.V.
modelid RWL021
name HueDimmerSchlaf1
on 1
productname Hue dimmer switch
reachable 1
swversion 6.1.1.28573
type ZLLSwitch
uniqueid 00:17:88:01:03:a5:8a:65-02-fc00
v2_id 177ed269-21fd-4926-a6b7-9105566e7416
READINGS:
2022-01-21 07:57:25 IODev PhilipsHue
2022-01-20 19:17:23 battery 71
2022-01-20 19:17:23 batteryPercent 71
2022-01-21 11:28:57 batteryState normal
2022-01-20 19:17:23 reachable 1
2022-01-20 19:17:23 state 1002
helper:
so...
ich habe die zeit behandlung komplett umgestellt. es sollte jetzt übersichtlicher sein und funktionieren.
wichtig ist:
- nach einem neustart kommen keine fhem events für alte werte
- beim regelmässigen pollen kommen keine fhem events für alte werte
- wenn events von der bridge kommen sollte es fhem events geben auch wenn das gleiche event (tastendruck)
mehrfach kommt.
dein list belegt meinen verdacht. mal sehen ob es mit der angehängten version auch bei dir geht.
wenn du im device verbose auf 4 stellst solltest du sehen wenn etwas ignoriert wird.
edit: der stand hier ist inzwischen eingecheckt
Hi,
habs mir mal runtergeladen und beobachte mal meine Events ...
VG
Zitatmal sehen ob es mit der angehängten version auch bei dir geht.
Works like a charme! Funktioniert einwandfrei, keine Auffäligkeiten.
Meine Musik jetzt nicht mehr ungewollt an und aus.
Danke ! ! !
PS: Das einzige was ich gesehen habe, ist das die Versionsnummer für Bridge und Device gleich geblieben ist, das müsste noch angepasst werden bevor die Version ins svn geht.
das klingt gut. d.h. auch beim fhem neu start kommen keine ungewollten events?
das ändern der version macht das svn beim ein- bzw beim auschecken.
Hallo justme,
gerade nochmal geschaut:
- Keine ungewollten Events mehr
- Nichts was mir im Logfile nach dem Neustart an Events aufgefallen waere.
Also für mich funktionierts, komisch das es beim ratman noch nicht geht.
PS: Einen habe ich: 2022.01.21 13:27:57 1: PERL WARNING: Use of uninitialized value $ts in numeric le (<=) at ./FHEM/31_HUEDevice.pm line 1810.
@knorxi & @Wardancer: Wie siehts bei euch aus?
mir ist nicht ganz klar welche daten hier rein kommen die die warnung erzeugen deshalb wird statt der warnung ab morgen etwas debug info ausgespuckt. wenn es dann noch mal passiert bitte posten.
Hallo,
hoffe mit meinem Anliegen bin ich hier richtig.
Seit dem Update von gestern funktionieren meine Bewegungsmelder von Xiaomi und Ikea nicht mehr.
In der Phoscon App wird Bewegung erfasst.
Gibt es hier einen Zusammenhang?
Danke und VG
Dieter
das update war von heute... die version für morgen sollte die probleme behoben haben.
wenn du nicht so lange warten kannst nimm bitte die version direkt aus dem svn.
hier genau das Gleiche ... ( neueste Version 25536 )
2022.01.21 16:21:17 1: PERL WARNING: Use of uninitialized value $ts in numeric le (<=) at ./FHEM/31_HUEDevice.pm line 1818.
2022.01.21 16:21:17 1: stacktrace:
2022.01.21 16:21:17 1: main::__ANON__ called by ./FHEM/31_HUEDevice.pm (1818)
2022.01.21 16:21:17 1: main::HUEDevice_Parse called by ./FHEM/30_HUEBridge.pm (130)
2022.01.21 16:21:17 1: main::HUEBridge_Read called by fhem.pl (3896)
2022.01.21 16:21:17 1: main::CallFn called by fhem.pl (774)
2022.01.21 16:21:17 1: PERL WARNING: Use of uninitialized value $lastupdated in concatenation (.) or string at ./FHEM/31_HUEDevice.pm line 1819.
2022.01.21 16:21:17 1: stacktrace:
2022.01.21 16:21:17 1: main::__ANON__ called by ./FHEM/31_HUEDevice.pm (1819)
2022.01.21 16:21:17 1: main::HUEDevice_Parse called by ./FHEM/30_HUEBridge.pm (130)
2022.01.21 16:21:17 1: main::HUEBridge_Read called by fhem.pl (3896)
2022.01.21 16:21:17 1: main::CallFn called by fhem.pl (774)
die Zeilennummern passen nicht zur version. hast du fhem neu gestartet nach dem du die files aus dem svn geholt hast?
Danke für den Hinweis, mea maxima culpa
habe nun 31_HUEDevice.pm 25538 2022-01-21 17:59:36 aus SVN genommen,
alle 15 HUE Devices getestet .... und ... klasse, alles läuft, keine Fehler mehr.
Danke für die tolle Arbeit.
Gruß,Uwe
Hier läuft auch alles super.
Vielen Dank Andre! Sehr gute Arbeit!
Gruß,
Stefan
Jo,
Bei mir auch....
Zitat von: justme1968 am 21 Januar 2022, 17:25:31
das update war von heute... die version für morgen sollte die probleme behoben haben.
wenn du nicht so lange warten kannst nimm bitte die version direkt aus dem svn.
Hallo justme,
nach Update von heute alles wieder ok.
Vielen Dank und schönes Wochenende.
VG Dieter
Hallo zusammen,
ich habe gestern von Version fhem.pl:25359/2021-12-20 auf fhem.pl:25544/2022-01-22 upgedatet, und damit die Push API Unterstützung bekommen. Es funktioniert alles soweit wie bisher. Nun werden aber Verbindungsprobleme für HTTPS Verbindungen zur Hue Bridge geloggt, und zwar ziemlich exakt 60 Minuten nach der letzten Aktion der Bridge. Parallel dazu laufen noch alle 60s HTTP Requests zur Bridge; die sind kurzlebig und haben das Problem nicht. Sonstige Performanceprobleme gibt es nicht, ich habe mit apptime nach Auffälligkeiten geschaut. Netzwerk ist ebenfalls stabil
Ich versuche das hier mal ausführlicher aufzudröseln, mit FHEM verbose logs und tcpdumps.
Hier die Definition der Bridge:
Internals:
DEF 192.168.10.207
EventStream connected
FUUID 5cb19795-f33f-99a2-dc4c-6b4eeea7efb297b8
FVERSION 30_HUEBridge.pm:0.255530/2022-01-24
INTERVAL 60
NAME Hue
NOTIFYDEV global
NR 210
NTFY_ORDER 50-Hue
STATE connected
TYPE HUEBridge
apiversion 1.48.0
application id 0c7aa15f-a4d5-42bf-8a29-a109653735ad
bridgeid 001788FFFE496484
has_v2_api 1
host 192.168.10.207
mac 00:17:88:49:64:84
manufacturer Signify
modelName Philips hue bridge 2015
modelid BSB002
name Philips hue
swversion 1949107040
updatestate 0
zigbeechannel 11
READINGS:
2021-12-04 19:40:12 lastError invalid value, <unknown>, for parameter, scene
2022-01-26 15:46:36 state connected
2022-01-25 12:09:02 swupdate ZGB_100B_0103 - 67.91.1
helper:
apiversion 77824
count 0
last_config_timestamp 1643208396
offsetUTC 3600
updatestate 0
HTTP_CONNECTION:
EventSource 1
FD 79
NAME
addr https://192.168.10.207:443
auth 0
buf
compress 1
displayurl https://192.168.10.207/eventstream/clip/v2
header Accept: text/event-stream
HUE-Application-Key: ...
host 192.168.10.207
httpdata
httpdatalen -1
httpheader HTTP/1.1 200 OK
Server: nginx
Date: Wed, 26 Jan 2022 14:44:41 GMT
Content-Type: text/event-stream; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
Cache-Control: no-store
Pragma: no-cache
Referrer-Policy: no-referrer
httpversion 1.1
hu_blocking 0
hu_inProgress HUEBridge_openEventStream:512 HUEBridge_fillBridgeInfo:571 HUEBridge_OpenDev:332 HUEBridge_Notify:3897 CallFn:3814 DoTrigger:678
hu_port 443
hu_portSfx
hu_sslAdded 1
incrementalTimeout 1
keepalive 1
loglevel 4
method GET
noshutdown 1
path /eventstream/clip/v2
protocol https
redirects 0
timeout 3600
type event
url https://192.168.10.207/eventstream/clip/v2
hash:
sslargs:
groups:
1:
class Living room
name Wohnzimmer
type Room
action:
alert select
bri 170
colormode xy
ct 447
effect none
hue 8253
sat 216
xy:
0.502
0.4259
lights:
12
11
2
5
sensors:
state:
v2_service:
2:
class Terrace
name Terrasse
type Room
action:
alert select
bri 254
colormode ct
ct 366
effect none
hue 8417
sat 140
xy:
0.4573
0.41
lights:
3
4
sensors:
state:
v2_service:
3:
class Living room
name Arbeitszimmer
type Room
action:
alert select
bri 254
colormode xy
ct 587
effect none
hue 3565
sat 250
xy:
0.561
0.4042
lights:
1
8
10
sensors:
state:
v2_service:
ignored:
Hue-S3 1
[...]
Attributes:
createGroupReadings 1
httpUtils 1
icon hue_filled_bridge_v2
key [...]
noshutdown 1
queryAfterSet 1
room Licht
Allgemein äussert sich das Problem so:
2022.01.25 15:12:27 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.25 16:12:28 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.25 17:12:30 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.25 18:12:32 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.25 21:20:47 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.25 23:27:01 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 00:42:16 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 01:42:16 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 02:42:18 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 03:42:20 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 04:42:22 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 07:35:42 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 10:34:58 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 12:17:03 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 13:17:03 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
Die 60 Minuten zählen ab dem Zeitpunkt, nachdem die letzte (Schalt)aktion über die Bridge durchgeführt wurde. Im Beispiel oben wurde gestern Abends, heute Morgen und am Mittag zum Testen geschaltet, was die Lücken >1h erklärt.
Auf dem Netzwerk sieht man, dass die HTTPS Verbindung aufgebaut wird, und Daten übertragen werden. Dann werden (bei mir) alle 20s (TCP) Keepalives zwischen Bridge und FHEM ausgetauscht. Wenn innerhalb von 60 Minuten eine Aktion auf der Bridge stattfindet, werden die Daten hierfür übertragen, danach geht es mit Keepalives weiter.
2022.01.26 10:34:58 4: Hue: EventStream: connecting
2022.01.26 10:34:58 5: HttpUtils url=https://192.168.10.207/eventstream/clip/v2 NonBlocking via https
2022.01.26 10:34:58 4: IP: 192.168.10.207 -> 192.168.10.207
2022.01.26 10:34:58 5: HttpUtils request header:
GET /eventstream/clip/v2 HTTP/1.1
Host: 192.168.10.207
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: keep-alive
HUE-Application-Key: ...
Accept: text/event-stream
Last-Event-ID: 1643186098:0
[...]
2022.01.26 11:16:42 4: Hue: dispatch: https://192.168.10.207/eventstream/clip/v2
2022.01.26 11:16:42 5: HUEBridge_dispatch: event
2022.01.26 11:16:42 5: Hue: EventStream: got id: 1643192202:0
2022.01.26 11:16:42 5: Hue: EventStream: got data: [{"creationtime":"2022-01-26T10:16:42Z","data":[{"id":"e67cdd1e-4bf4-4877-9364-f1a55527fd4e","id_v1":"/lights/1","on":{"on":true},"owner":{"rid":"916ef74f-7c9f-4f37-91b8-8ba15738dca2","rtype":"device"},"type":"light"}],"id":"28ce36f7-b001-41f1-9afa-2b64b17b498b","type":"update"}]
[...]
6116 10:34:58.432161498 192.168.10.240 → 192.168.10.207 TCP 74 46112 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=2316604012 TSecr=0 WS=1024
6117 10:34:58.432506281 192.168.10.207 → 192.168.10.240 TCP 66 443 → 46112 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=8
6118 10:34:58.432563551 192.168.10.240 → 192.168.10.207 TCP 54 46112 → 443 [ACK] Seq=1 Ack=1 Win=65536 Len=0
6119 10:34:58.435532623 192.168.10.240 → 192.168.10.207 TLSv1 571 Client Hello
[...]
8527 11:16:36.743239102 192.168.10.207 → 192.168.10.240 TCP 60 [TCP Keep-Alive] 443 → 46112 [ACK] Seq=1507 Ack=924 Win=31344 Len=0
8528 11:16:36.743314541 192.168.10.240 → 192.168.10.207 TCP 54 [TCP Keep-Alive ACK] 46112 → 443 [ACK] Seq=924 Ack=1508 Win=70656 Len=0
8529 11:16:42.781006405 192.168.10.207 → 192.168.10.240 TLSv1.2 395 Application Data
8530 11:16:42.781159357 192.168.10.240 → 192.168.10.207 TCP 54 46112 → 443 [ACK] Seq=924 Ack=1849 Win=72704 Len=0
[...]
8593 11:17:23.463271451 192.168.10.207 → 192.168.10.240 TCP 60 [TCP Keep-Alive] 443 → 46112 [ACK] Seq=7960 Ack=924 Win=31344 Len=0
8594 11:17:23.463331896 192.168.10.240 → 192.168.10.207 TCP 54 [TCP Keep-Alive ACK] 46112 → 443 [ACK] Seq=924 Ack=7961 Win=91136 Len=0
[...]
60 Minuten nach der letzten Aktion wird die Verbindung dann beendet/abgebrochen, und wieder neu aufgebaut:
2022.01.26 12:17:03 4: Hue: dispatch: https://192.168.10.207/eventstream/clip/v2
2022.01.26 12:17:03 5: HUEBridge_dispatch: event
2022.01.26 12:17:03 2: Hue: http request failed: read from https://192.168.10.207:443 timed out
2022.01.26 12:17:03 2: Hue: EventStream: terminated
2022.01.26 12:17:03 4: Hue: EventStream: closing
2022.01.26 12:17:03 4: Hue: EventStream: closed
2022.01.26 12:17:03 4: Hue: EventStream: connecting
2022.01.26 12:17:03 5: HttpUtils url=https://192.168.10.207/eventstream/clip/v2 NonBlocking via https
2022.01.26 12:17:03 4: IP: 192.168.10.207 -> 192.168.10.207
2022.01.26 12:17:03 5: HttpUtils request header:
GET /eventstream/clip/v2 HTTP/1.1
Host: 192.168.10.207
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: keep-alive
Last-Event-ID: 1643192222:0
Accept: text/event-stream
HUE-Application-Key: ...
2022.01.26 12:17:03 4: Hue: dispatch: https://192.168.10.207/eventstream/clip/v2
2022.01.26 12:17:03 5: HUEBridge_dispatch: event
2022.01.26 12:17:03 4: Hue: EventStream: connected
2022.01.26 12:17:03 5: Hue: ignoring: hi
2022.01.26 12:17:03 5: HttpUtils url=https://192.168.10.207/clip/v2/resource NonBlocking via https
2022.01.26 12:17:03 4: IP: 192.168.10.207 -> 192.168.10.207
2022.01.26 12:17:03 5: HttpUtils request header:
GET /clip/v2/resource HTTP/1.0
Host: 192.168.10.207
User-Agent: fhem
Accept-Encoding: gzip,deflate
HUE-Application-Key: ...
2022.01.26 12:17:03 4: https://192.168.10.207/clip/v2/resource: HTTP response code 200
2022.01.26 12:17:03 5: HttpUtils https://192.168.10.207/clip/v2/resource: Got data, length: 62905
2022.01.26 12:17:03 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 26 Jan 2022 11:17:03 GMT
Content-Type: application/json
Connection: close
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
Cache-Control: no-store
Pragma: no-cache
Referrer-Policy: no-referrer
2022.01.26 12:17:03 4: Hue: dispatch: https://192.168.10.207/clip/v2/resource
2022.01.26 12:17:03 5: HUEBridge_dispatch: resource
11710 12:16:26.503719258 192.168.10.207 → 192.168.10.240 TCP 60 [TCP Keep-Alive] 443 → 46112 [ACK] Seq=7960 Ack=924 Win=31344 Len=0
11711 12:16:26.503801439 192.168.10.240 → 192.168.10.207 TCP 54 [TCP Keep-Alive ACK] 46112 → 443 [ACK] Seq=924 Ack=7961 Win=91136 Len=0
11712 12:16:46.983819365 192.168.10.207 → 192.168.10.240 TCP 60 [TCP Keep-Alive] 443 → 46112 [ACK] Seq=7960 Ack=924 Win=31344 Len=0
11713 12:16:46.983909992 192.168.10.240 → 192.168.10.207 TCP 54 [TCP Keep-Alive ACK] 46112 → 443 [ACK] Seq=924 Ack=7961 Win=91136 Len=0
11714 12:17:03.005035541 192.168.10.240 → 192.168.10.207 TLSv1.2 85 Encrypted Alert
11715 12:17:03.005390150 192.168.10.240 → 192.168.10.207 TCP 54 46112 → 443 [FIN, ACK] Seq=955 Ack=7961 Win=91136 Len=0
11716 12:17:03.006250829 192.168.10.207 → 192.168.10.240 TLSv1.2 85 Encrypted Alert
11717 12:17:03.006338913 192.168.10.240 → 192.168.10.207 TCP 54 46112 → 443 [RST] Seq=956 Win=0 Len=0
11718 12:17:03.007641859 192.168.10.240 → 192.168.10.207 TCP 74 39094 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=2322728588 TSecr=0 WS=1024
11719 12:17:03.008054080 192.168.10.207 → 192.168.10.240 TCP 66 443 → 39094 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=8
11720 12:17:03.008190370 192.168.10.240 → 192.168.10.207 TCP 54 39094 → 443 [ACK] Seq=1 Ack=1 Win=65536 Len=0
Dann geht das Ganze wieder von vorn los.
Neben den HTTP Abfragen und obigen HTTPS Verbindungen gibt es auch noch eine kurzlebige HTTPS Verbindung, die nach dem Neuverbindungen aufgebaut wird, und nach ein paar Datentransfers ordentlich wieder abgebaut wird.
11732 12:17:03.119275801 192.168.10.240 → 192.168.10.207 TCP 74 39096 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=2322728699 TSecr=0 WS=1024
11733 12:17:03.119635071 192.168.10.207 → 192.168.10.240 TCP 66 443 → 39096 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=8
11734 12:17:03.119744351 192.168.10.240 → 192.168.10.207 TCP 54 39096 → 443 [ACK] Seq=1 Ack=1 Win=65536 Len=0
[...]
11866 12:17:03.358786646 192.168.10.207 → 192.168.10.240 TCP 60 443 → 39096 [FIN, ACK] Seq=65456 Ack=841 Win=30272 Len=0
11867 12:17:03.358811600 192.168.10.240 → 192.168.10.207 TLSv1.2 85 Encrypted Alert
11868 12:17:03.359013713 192.168.10.240 → 192.168.10.207 TCP 54 39096 → 443 [FIN, ACK] Seq=872 Ack=65457 Win=211968 Len=0
11869 12:17:03.359328609 192.168.10.207 → 192.168.10.240 TCP 60 443 → 39096 [RST] Seq=65456 Win=0 Len=0
11870 12:17:03.359432038 192.168.10.207 → 192.168.10.240 TCP 60 443 → 39096 [RST] Seq=65457 Win=0 Len=0
Viele Grüsse
Christian
hast du im netz irgendetwas zwischen fhem under der bridge? router, firewall oder ähnliches?
die verbidngun für die events ist das was du als lange verbindung die offen bleibt siehst. die wird von fhem zur bridge aufgebaut und per http keep alive offen gehalten. die bridge pushed darüber die events per sse/eventstream protokoll. da fhem aktuell nur hatt 1 spricht geht das per http keepalive und nicht per multiplexed streams. es kann sein das die bridge diese verbindung nach einer weile zu macht. das wird aber erkannt und neu verbunden. das zeigt sich aber nicht als timeout.
von den tcp keepalives bekomme ich auf anwendungsebene nichts mit. wenn sie ausbleiben ergibt das aber eventuell den timeout den du siehst. solche symptome würde ich erwarten wenn es eine firewall dazwischen gibt die nach einer weile unaktivität zu macht. in einem 'normalen' netz sollte das nicht passieren. bisher hat das auch noch niemand sonst beobachtet. deshalb ist es zumindest mal kein allgemeines problem.
ansonsten: die kurzen verbindungen sind das pollen alle 60 sekunden. das ist (noch) drin falls mit dem eventstream was schief geht. da es wie gesagt http 1 ist und nicht 2 sind das alles getrennte verbindungen statt die eventstream verbindung mit zu verwenden. deshalb hat das pollen auch keinen einfluss auf die timeouts des eventstream.
du siehst ich bin etwas ratlos...
Hi,
vielen Dank für Deine Erklärungen, das war sehr hilfreich. Server und Bridge hängen zusammen an einem Switch im selben VLAN/Netz, die Portstatistiken sehen soweit auch gut aus. Auf dem Linux Server läuft keine FW/iptables etc. ist aus. Das ist sehr wahrscheinlich nicht.
Ich hab mir die Captures nochmal genauer angeschaut. Die TCP Keepalives sendet die Bridge, FHEM ACKt die nur. Vielleicht ist das mit den HTTP Keepalives auch ein Missverständnis - HTTP Keepalives sind kein Äquivalent wie ein TCP Keepalive oder ein Protokoll NOOP/alive, zumindest sendet FHEM nichts aktiv periodisch raus. Muss es ja wahrscheinlich auch nicht, solange da nichts mit "state" dazwischen ist.
Nach 60 Minuten idle time (und kürzer als 20s nach dem letzten TCP Keepalive) wird ein GET /eventstream/clip/v2 in FHEM geloggt. Der kommt meiner Meinung nach aber gar nicht auf dem Netzwerkinterface des Servers raus. Vielmehr wird ein TLS Alert generiert und an die Bridge gesendet und gleichzeitig durch FHEM die Verbindung beendet:
11712 12:16:46.983819365 192.168.10.207 → 192.168.10.240 TCP 60 [TCP Keep-Alive] 443 → 46112 [ACK] Seq=7960 Ack=924 Win=31344 Len=0
11713 12:16:46.983909992 192.168.10.240 → 192.168.10.207 TCP 54 [TCP Keep-Alive ACK] 46112 → 443 [ACK] Seq=924 Ack=7961 Win=91136 Len=0
11714 12:17:03.005035541 192.168.10.240 → 192.168.10.207 TLSv1.2 85 Encrypted Alert
11715 12:17:03.005390150 192.168.10.240 → 192.168.10.207 TCP 54 46112 → 443 [FIN, ACK] Seq=955 Ack=7961 Win=91136 Len=0
11716 12:17:03.006250829 192.168.10.207 → 192.168.10.240 TLSv1.2 85 Encrypted Alert
11717 12:17:03.006338913 192.168.10.240 → 192.168.10.207 TCP 54 46112 → 443 [RST] Seq=956 Win=0 Len=0
Da hat die Bridge selber nicht drauf reagieren können; ausser, ebenfalls die Verbindung dann zu schliessen. Kann im Zusammenspiel mit dem Modul, timeouts und HTTPUtils noch was klemmen, was das hervorruft?
Viele Grüsse
Christian
wie gesagt sehe ich die tcp keepalives nicht auf anwendungsebene und ein normaler verbindungsabbruch sollte keine timeouts erzeugen sondern nur ein reconnect.
vom als layer sehe ich auch nichts, das behandeln die httputils routinen bzw. die perl IO::Socket::SSL automatisch. auch sollte das auf eine bereits ausgehandelte und stehende verbindung keinen einfluß haben. ausser es wird etwas neu ausgehandelt und hier geht etwas schief. hast du in global besondere ssl optionen gesetzt?
ich habe aktuell keine idee. da es wie gesagt bisher noch bei keinem anderen aufgefallen ist und auch bei auf unterschiedlichen systemen nicht auftritt kann es eigentlich kein allgemeines problem sein.
ich denke morgen noch mal in ruhe darüber nach.
ich habe eben herausgefunden was sich mit den weiter oben beschrieben candle und fire effekt einträgen in den neuen v2 resourcen machen lässt.
je nach leuchtmittel und aktueller firmware gibt es ab morgen ein v2effect kommando im device der lampen.
bei mir funktioniert es mit einem hue play lightstrip und diversen filament birnen. das ganze schaut recht überzeugend aus wenn man die lampen hell genug stellt.
das ganze ist auf philips seite noch nicht dokumentiert, kann sich also noch ändern und soll scheinbar erst in den nächsten wochen ausgerollt werden.
Hi,
Zitat von: justme1968 am 26 Januar 2022, 23:10:29
ich habe aktuell keine idee. da es wie gesagt bisher noch bei keinem anderen aufgefallen ist und auch bei auf unterschiedlichen systemen nicht auftritt kann es eigentlich kein allgemeines problem sein.
Da stimme ich Dir zu. Vielleicht ist bei mir auch einfach zu wenig los, ich hab nur ein paar Lampen (ca 6 Stück). Die werden Morgens und Abends eingeschaltet, und nach ein 1-2 Stunden wieder ausgemacht.
Ich hab dass abseits von FHEM mit "openssl s_client -connect <hue ip>:443" auf dem FHEM Server und 2 anderen Systemen nachgestellt. Nach dem GET Request lasse ich openssl weiterlaufen, und sehe Events eintrudeln. Diese Events sind entweder Schaltvorgänge, oder selten mal Statusmeldungen über die verbundenen Lampen. Die so geöffneten Verbindungen bleiben auch länger als 1h offen.
Wenn nichts geschalten wird, dann ist im Eventstream auch mal länger als 1h Ruhe. Wahrscheinlich schlägt dann bei mir der mit 3600s definierte Timeout zu: https://github.com/fhem/fhem-mirror/blob/2abc6ece1b0c2be37409ae9cf25b2697837819c3/fhem/FHEM/30_HUEBridge.pm#L464 (https://github.com/fhem/fhem-mirror/blob/2abc6ece1b0c2be37409ae9cf25b2697837819c3/fhem/FHEM/30_HUEBridge.pm#L464) Verkürze ich den, dann bricht die Verbindung in FHEM entsprechend schneller ab. Das Weglassen von IncrementalTimeout bringt keine Änderung.
Vielleicht habt ihr alle mehr Geräte, so dass öfters Statusmeldungen kommen?
Viele Grüsse
Christian
kannst du mal probieren ob es hilft wenn du zusätzlich zum timeout an dieser stelle noch incrementalTimout auf 1 setzt? hilft das schon? hilft es wenn du timeout noch deutlich erhöhst?
Hi,
Zitat von: justme1968 am 27 Januar 2022, 17:59:56
kannst du mal probieren ob es hilft wenn du zusätzlich zum timeout an dieser stelle noch incrementalTimout auf 1 setzt? hilft das schon? hilft es wenn du timeout noch deutlich erhöhst?
In meiner Version ist incrementalTimeout schon gesetzt (eine Zeile drunter). Ich hab das testhalber mal auf 0 gesetzt, es ändert sich dadurch aber nichts.
Den Timeout habe ich gestern Abend auf 4h hochgesetzt. Das hat geklappt, es kam keine Fehlermeldung mehr - es war aber knapp ;-) Um 23:32 Uhr kam Abends der letzte Statusevent, der nächste dann heute früh um 3:20 Uhr:
14d
id: 1643322735:0
data: [{"creationtime":"2022-01-27T22:32:15Z","data":[{"id":"a8c0d53a-ba0f-4854-89d4-43af69509fa0","id_v1":"/lights/11","owner":{"rid":"332e3b11-e86b-4a1f-bc5b-fe3765576956","rtype":"device"},"status":"connectivity_issue","type":"zigbee_connectivity"}],"id":"bbbefced-30ba-4422-b059-96f39c41d6bc","type":"update"}]
144
id: 1643322762:0
data: [{"creationtime":"2022-01-27T22:32:42Z","data":[{"id":"a8c0d53a-ba0f-4854-89d4-43af69509fa0","id_v1":"/lights/11","owner":{"rid":"332e3b11-e86b-4a1f-bc5b-fe3765576956","rtype":"device"},"status":"connected","type":"zigbee_connectivity"}],"id":"d1665aae-2463-49f9-89ff-5cf8ea119fc3","type":"update"}]
14d
id: 1643336436:0
data: [{"creationtime":"2022-01-28T02:20:36Z","data":[{"id":"a8c0d53a-ba0f-4854-89d4-43af69509fa0","id_v1":"/lights/11","owner":{"rid":"332e3b11-e86b-4a1f-bc5b-fe3765576956","rtype":"device"},"status":"connectivity_issue","type":"zigbee_connectivity"}],"id":"91699679-fad2-4636-9812-7ebd644ad82e","type":"update"}]
144
id: 1643336457:0
data: [{"creationtime":"2022-01-28T02:20:57Z","data":[{"id":"a8c0d53a-ba0f-4854-89d4-43af69509fa0","id_v1":"/lights/11","owner":{"rid":"332e3b11-e86b-4a1f-bc5b-fe3765576956","rtype":"device"},"status":"connected","type":"zigbee_connectivity"}],"id":"9b426a40-20e6-47ee-be2a-e5ca3fbb4a3b","type":"update"}]
Die Statusmeldungen werden durch sporadische Verbindungsprobleme einzelner Lampen getriggert. Vielleicht ist auch genau das, was meine Installation unterscheidet - die ist einfach zu stabil 8)
Wenn der Timeout prüfen soll, ob der Eventstream noch lebt, dann braucht es wohl eine periodische Abfrage seitens FHEM, dessen Ergebnis im Eventstream ausgegeben wird. Oder eine periodische (Alive) Nachricht von der Bridge. Das scheint aber aktuell nicht implementiert zu sein bzw. die Bridge setzt auf ihre TCP Keepalives.
Viele Grüsse
Christian
der timeout parameter der an httputils geht landet als Timeout in der perl socket routinen. eigentlich ist der auch nur für connect und accept. d.h. wenn die verbindung mal steht hat der timeout keine auswirkungen mehr. auch wenn ssl verwendet wird sollte der timeout sich nur auf den initialen verbindungsaufbau beziehen. allerdings ist in der perl doku auch dokumentiert das die auswirkung plattform und socket typ abhängig ist. windows verhält sich z.b. anders.
man könnte noch schauen ob SO_RCVTIMEO einen einfluß hat, aber das ist noch viel mehr plattformabhängig.
d.h. nichts genaues weiss man nicht. vielleicht hat es auswirkung auf das neu aushandeln der ssl schlüssel nach einer gewissen zeit. komisch ist dann aber das es bisher nur bei dir zu beobachten ist.
ich habe been eine version des bridge moduls mit dem neuen attribut eventstreamTimeout eingecheckt. das sollte dir helfen. versuch ruhig mal es auf 43200 (12 stunden) zu setzen.
Hallo,
auf die Gefahr hin, dass ich mich jetzt blamiere...
Aber warum erhalte ich ohne Ende Log-Einträge mit z.B. "data for unknown sensor received: hueBridge1-S86" für die ganzen Sensoren, die eigentlich schon im aktuellen Update automatisch "ignored" werden und per autocreate nicht angelegt werden können. Alle anderen Sensoren (z.B. daylight, etc.) habe ich bereits angelegt und erst einmal in einen sep. Raum verschoben.
Was muss ich denn tun, damit ich nicht jede 60 Sekunden 100 Zeilen ins Log geschrieben bekomme?
Ich habe wirklich schon danach gesucht, aber nichts Konkretes gefunden. Sorry.
Ich habe nun auch mal auf die neueste Version upgedatet. Nun ist mir aufgefallen, dass meine Hue Dimmerschalter manchmal ein eventtype initial_press ausgibt und somit meine Doif´s nicht richtig funktionieren. Manchmal springt er auch weiter auf short_release, aber halt leider nicht immer. Woran könnte das liegen?
@blackbite: die meldung sollten für die automatisch ignorierten sensoren natürlich nicht kommen. wenn doch: bitte log und get <bridge> sensors und get <bridge> ignored zeigen.
ansonsten: autocreate aktivieren oder set <bridge> autocreate verwenden und am besten nicht von hand selber anlegen.
@christian.71: welche events genau kommen hängt davon ab was die bridge sendet und das hängt vom konkreten modell des tasters ab und davon wie schnell oder langsam du drückst und loslässt. das es ein real
wenn man sehr schnell mehrfach klickt gibt es z.b. nur ein press und mehrere release.
bist du sicher das die doif die events genau genug spezifiziert? siehe auch hier: https://forum.fhem.de/index.php/topic,125768.msg1203970.html#msg1203970 und folgende.
ansonsten: list von device, vom doif und eventmonitor zeigen
@blackbite: wenn du auch noch eine alte bridge verwendest: ich habe ein problem gefunden und für morgen repariert. das modul hatte auch für alte bridges ohne v2 api versucht die sensoren automatisch anzulegen es dann aber wie vorgesehen nicht gemacht. und das immer wieder.
wenn du tatsächlich so viele sensoren hast das 100 zeilen zusammen kommen: die neue bridge mit dem v2 api und den events ist wegen der echten push events sehr viel besser dafür geeignet.
Hier mal mein Doif:
Der Hue Schalter wird dafür verwendet, den Klodeckel im Bad zu öffnen und zu schließen.
([Badschalter:state] eq "4002") (set Toilette cover off)
DOELSEIF ([Badschalter:state] eq "1002") (set Toilette cover on)
Und hier das list vom Schalter:
Internals:
DEF sensor 53 IODev=HUEBridge
FUUID 5c4f2d3b-f33f-45b6-1dbc-10449c530f07a095
FVERSION 31_HUEDevice.pm:0.255770/2022-01-28
ID S53
INTERVAL
IODev HUEBridge
NAME Badschalter
NR 29
STATE 1000
TYPE HUEDevice
has_events 1
inputs 4
manufacturername Signify Netherlands B.V.
modelid RWL021
name Badezimmer Schalter
on 1
productname Hue dimmer switch
reachable 1
swversion 6.1.1.28573
type ZLLSwitch
uniqueid 00:17:88:01:10:48:5a:02-02-fc00
v2_id 8edf9237-abe5-4f2a-8b70-88aab1af1a6b
READINGS:
2022-01-29 11:57:14 IODev HUEBridge
2022-01-29 13:08:36 battery 48
2022-01-29 13:08:36 batteryPercent 48
2022-01-29 13:05:00 batteryState normal
2022-01-29 13:08:36 eventtype initial_press
2022-01-29 13:08:36 input 1
2022-01-29 13:08:36 reachable 1
2022-01-29 13:08:36 state 1000
helper:
devtype S
update_timeout 1
capabilities:
inputs:
HASH(0x55dc16192120)
HASH(0x55dc16192348)
HASH(0x55dc16192570)
HASH(0x55dc16192798)
configList:
events:
HASH(0x55dc161ceb70)
HASH(0x55dc161d37c0)
HASH(0x55dc161d3850)
HASH(0x55dc161d6648)
json:
diversityid 73bbabea-3420-499a-9856-46bf437e119b
manufacturername Signify Netherlands B.V.
modelid RWL021
name Badezimmer Schalter
productname Hue dimmer switch
swversion 6.1.1.28573
type ZLLSwitch
uniqueid 00:17:88:01:10:48:5a:02-02-fc00
capabilities:
inputs:
HASH(0x55dc18991190)
HASH(0x55dc1768b860)
HASH(0x55dc175284a8)
HASH(0x55dc17428a80)
config:
battery 48
pending:
state:
buttonevent 1002
lastupdated 2022-01-29T12:08:36
swupdate:
lastinstall 2019-10-10T12:54:06
state noupdates
setList:
Attributes:
DbLogExclude .*
IODev HUEBridge
alias Badschalter
model RWL021
room HUEDevice,Zimmer->Badezimmer
und der Eventmonitor:
2022-01-29 13:08:00 HUEDevice Badschalter 1000
2022-01-29 13:08:00 HUEDevice Badschalter eventtype: initial_press
2022-01-29 13:08:00 HUEDevice Badschalter input: 1
2022-01-29 13:08:08 HUEDevice Badschalter input: 1
2022-01-29 13:08:08 HUEDevice Badschalter eventtype: initial_press
2022-01-29 13:08:08 HUEDevice Badschalter 1000
2022-01-29 13:08:08 HUEDevice Badschalter battery: 48
2022-01-29 13:08:08 HUEDevice Badschalter batteryPercent: 48
2022-01-29 13:08:08 HUEDevice Badschalter reachable: 1
2022-01-29 13:08:14 HUEDevice Badschalter input: 1
2022-01-29 13:08:14 HUEDevice Badschalter 1000
2022-01-29 13:08:14 HUEDevice Badschalter eventtype: initial_press
2022-01-29 13:08:16 HUEDevice Badschalter input: 1
2022-01-29 13:08:16 HUEDevice Badschalter eventtype: initial_press
2022-01-29 13:08:16 HUEDevice Badschalter 1000
2022-01-29 13:08:17 HUEDevice Badschalter eventtype: short_release
2022-01-29 13:08:17 HUEDevice Badschalter 1002
2022-01-29 13:08:17 HUEDevice Badschalter input: 1
2022-01-29 13:08:23 HUEDevice Badschalter input: 4
2022-01-29 13:08:23 HUEDevice Badschalter 4000
2022-01-29 13:08:23 HUEDevice Badschalter eventtype: initial_press
2022-01-29 13:08:24 HUEDevice Badschalter eventtype: short_release
2022-01-29 13:08:24 HUEDevice Badschalter 4002
2022-01-29 13:08:24 HUEDevice Badschalter input: 4
2022-01-29 13:08:27 HUEDevice Badschalter input: 4
2022-01-29 13:08:27 HUEDevice Badschalter 4000
2022-01-29 13:08:27 HUEDevice Badschalter eventtype: initial_press
2022-01-29 13:08:28 HUEDevice Badschalter input: 4
2022-01-29 13:08:28 HUEDevice Badschalter eventtype: short_release
2022-01-29 13:08:28 HUEDevice Badschalter 4002
2022-01-29 13:08:32 HUEDevice Badschalter eventtype: initial_press
2022-01-29 13:08:32 HUEDevice Badschalter 1000
2022-01-29 13:08:32 HUEDevice Badschalter input: 1
2022-01-29 13:08:33 HUEDevice Badschalter 1002
2022-01-29 13:08:33 HUEDevice Badschalter eventtype: short_release
2022-01-29 13:08:33 HUEDevice Badschalter input: 1
2022-01-29 13:08:36 HUEDevice Badschalter input: 1
2022-01-29 13:08:36 HUEDevice Badschalter eventtype: initial_press
2022-01-29 13:08:36 HUEDevice Badschalter 1000
2022-01-29 13:08:36 HUEDevice Badschalter batteryPercent: 48
2022-01-29 13:08:36 HUEDevice Badschalter battery: 48
2022-01-29 13:08:36 HUEDevice Badschalter reachable: 1
Ich muss eben ein paar Mal drauf drücken, wenn ich den state 1002 erreichen möchte. Das war eben vorher nicht so. Ich könnte aber natürlich das doif soweit umschreiben, dass er bei 1000 und 1002 reagiert.
das sind die tatsächlichen events die die bridge sendet. im gegensatz zu decons gibt es da aktuell ein limit auf die anzahl pro sekunde. wenn ich as richtig sehe sollte es mit press statt release also 1000 statt 1002 bei dir zuverlässig funktionieren
Zitat von: justme1968 am 29 Januar 2022, 13:26:26
das sind die tatsächlichen events die die bridge sendet. im gegensatz zu decons gibt es da aktuell ein limit auf die anzahl pro sekunde. wenn ich as richtig sehe sollte es mit press statt release also 1000 statt 1002 bei dir zuverlässig funktionieren
Ab und an triggert er ja doch die 1002, dann würde das doif mit dem Wert 1000 wieder nicht ansprechen. Ich habe das doif nun über das Reading "input" geändert, 1 für auf und 4 für zu. Bei dem reading unterscheidet er ja nicht, wie lange ich den Taster drücke. Das klappt nun zuverlässig.
Zitat von: justme1968 am 29 Januar 2022, 12:22:41
@blackbite: die meldung sollten für die automatisch ignorierten sensoren natürlich nicht kommen. wenn doch: bitte log und get <bridge> sensors und get <bridge> ignored zeigen.
ansonsten: autocreate aktivieren oder set <bridge> autocreate verwenden und am besten nicht von hand selber anlegen.
@christian.71: welche events genau kommen hängt davon ab was die bridge sendet und das hängt vom konkreten modell des tasters ab und davon wie schnell oder langsam du drückst und loslässt. das es ein real
wenn man sehr schnell mehrfach klickt gibt es z.b. nur ein press und mehrere release.
bist du sicher das die doif die events genau genug spezifiziert? siehe auch hier: https://forum.fhem.de/index.php/topic,125768.msg1203970.html#msg1203970 und folgende.
ansonsten: list von device, vom doif und eventmonitor zeigen
Danke f.d. schnelle Hilfe. Also ich habe 2 Bridges V2 und jede Menge Leuchtmittel & Sensoren. Gerade noch mal das System rebootet und der Log schmeißt weiterhin fleißig unknown sensors, die eigentlich ignored sein sollten:
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S90
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S198
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S119
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S200
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S144
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S147
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S74
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S120
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S145
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S11
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S142
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S208
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S143
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S22
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S65
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S197
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S199
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S146
2022.01.29 15:44:36 3: hueBridge2: data for unknown sensor received: hueBridge2-S209
2022.01.29 15:44:38 2: hueBridge1: EventStream: event for unknown device received, trying to refresh resouces
2022.01.29 15:44:39 2: Kueche_MDIR_HUE_1_Motion: bridge has events api, events connected, removing interval
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S33
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S32
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S90
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S74
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S75
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S59
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S89
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S104
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S107
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S42
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S106
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S13
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S105
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S85
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S36
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S58
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S34
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S45
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S43
2022.01.29 15:44:39 3: hueBridge1: data for unknown sensor received: hueBridge1-S86
2022.01.29 15:44:41 2: hueBridge1: http request failed: read from https://192.168.69.250:443 timed out
2022.01.29 15:44:41 2: hueBridge2: EventStream: event for unknown device received, trying to refresh resouces
2022.01.29 15:44:43 2: hueBridge2: http request failed: read from https://192.168.69.251:443 timed out
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S33
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S32
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S90
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S74
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S75
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S59
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S89
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S104
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S107
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S42
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S106
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S13
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S105
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S85
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S36
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S58
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S34
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S45
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S43
2022.01.29 15:45:32 3: hueBridge1: data for unknown sensor received: hueBridge1-S86
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S90
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S198
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S119
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S200
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S144
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S147
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S74
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S120
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S145
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S11
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S142
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S208
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S143
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S22
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S65
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S197
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S199
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S146
2022.01.29 15:45:33 3: hueBridge2: data for unknown sensor received: hueBridge2-S209
2022.01.29 15:46:29 2: AttrTemplates: got 255 entries
2022.01.29 15:46:38 2: Pergola_MDIR_HUE_1_Temp: bridge has events api, events connected, removing interval
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S33
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S32
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S90
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S74
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S75
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S59
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S89
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S104
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S107
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S42
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S106
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S13
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S105
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S85
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S36
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S58
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S34
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S45
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S43
2022.01.29 15:46:38 3: hueBridge1: data for unknown sensor received: hueBridge1-S86
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S90
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S198
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S119
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S200
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S144
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S147
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S74
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S120
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S145
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S11
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S142
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S208
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S143
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S22
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S65
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S197
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S199
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S146
2022.01.29 15:46:39 3: hueBridge2: data for unknown sensor received: hueBridge2-S209Hier ein get sensors der beiden Bridges:
ID NAME FHEM TYPE
1: Daylight HUESensor1 Daylight
3: Hue Switch SZ HUESensor3 ZLLSwitch
5: Hue Switch Marcel HUESensor5 ZLLSwitch
13: Licht-Status CLIPGenericStatus
14: Hue temperature sensor 2 HUESensor14 ZLLTemperature
15: Bad Sensor BZ_MDIR_HUE_1_Motion ZLLPresence
16: Hue ambient light sensor 2 HUESensor16 ZLLLightLevel
22: Hue temperature sensor 4 HUESensor22 ZLLTemperature
23: Gäste-WC Sensor WC_MDIR_HUE_1_Motion ZLLPresence
24: Hue ambient light sensor 4 HUESensor24 ZLLLightLevel
26: Hue temperature sensor 5 HUESensor26 ZLLTemperature
27: Küche Sensor Kueche_MDIR_HUE_1_Motion ZLLPresence
28: Hue ambient light sensor 5 HUESensor28 ZLLLightLevel
31: Hue Switch Bad HUESensor31 ZLLSwitch
32: Dimmer Switch 31 SceneCycle CLIPGenericStatus
33: HomeAway CLIPPresence
34: HUAWEI BLA-L29 Geofence
35: Hue Switch WC HUESensor35 ZLLSwitch
36: Dimmer Switch 35 SceneCycle CLIPGenericStatus
42: Samsung Galaxy Tab 2 Geofence
43: presenceState CLIPGenericStatus
45: presenceState CLIPGenericStatus
58: presenceState CLIPGenericStatus
59: textState CLIPGenericStatus
74: cycling CLIPGenericStatus
75: cycleState CLIPGenericStatus
76: Hue Switch Marlon HUESensor76 ZLLSwitch
85: cycling CLIPGenericStatus
86: cycleState CLIPGenericStatus
89: cycling CLIPGenericStatus
90: cycleState CLIPGenericStatus
91: Hue Button Marlon HUESensor91 ZLLSwitch
104: dimDirection CLIPGenericStatus
105: isDimming CLIPGenericStatus
106: slotState CLIPGenericStatus
107: cycling CLIPGenericStatus Hier die Zweite:
ID NAME FHEM TYPE
1: Daylight hueBridge2_HUESensor1 Daylight
2: Hue temperature sensor 1 hueBridge2_HUESensor2 ZLLTemperature
3: Flur UG Sensor Flur_UG_MDIR_HUE_1_Motion ZLLPresence
4: Hue ambient light sensor 1 hueBridge2_HUESensor4 ZLLLightLevel
5: Hue temperature sensor 2 hueBridge2_HUESensor5 ZLLTemperature
6: Keller Sensor Keller_MDIR_HUE_1_Motion ZLLPresence
7: Hue ambient light sensor 2 hueBridge2_HUESensor7 ZLLLightLevel
10: Hue Switch Keller hueBridge2_HUESensor10 ZLLSwitch
11: Dimmer Switch 10 SceneCycle CLIPGenericStatus
12: Hue temperature sensor 3 hueBridge2_HUESensor12 ZLLTemperature
13: Flur OG Sensor Flur_OG_MDIR_HUE_1_Motion ZLLPresence
14: Hue ambient light sensor 3 hueBridge2_HUESensor14 ZLLLightLevel
22: Licht-Status CLIPGenericStatus
23: Hue outdoor temperature sensor 1 Pergola_MDIR_HUE_1_Temp ZLLTemperature
24: Pergola Sensor Pergola_MDIR_HUE_1_Motion ZLLPresence
25: Hue outdoor ambient light sensor hueBridge2_HUESensor25 ZLLLightLevel
47: Terrasse Sensor Terrasse_MDIR_HUE_2_Motion ZLLPresence
48: Hue outdoor ambient light sensor hueBridge2_HUESensor48 ZLLLightLevel
49: Hue outdoor temperature sensor 2 Terrasse_MDIR_HUE_2_Temp ZLLTemperature
65: presenceState CLIPGenericStatus
74: presenceState CLIPGenericStatus
90: Terrasse and Gartenzaun, Vibrant CLIPGenericStatus
119: presenceState CLIPGenericStatus
120: textState CLIPGenericStatus
142: presenceState CLIPGenericStatus
143: textState CLIPGenericStatus
144: presenceState CLIPGenericStatus
145: textState CLIPGenericStatus
146: presenceState CLIPGenericStatus
147: textState CLIPGenericStatus
184: Hue Button Garten hueBridge2_HUESensor184 ZLLSwitch
197: dimDirection CLIPGenericStatus
198: isDimming CLIPGenericStatus
199: slotState CLIPGenericStatus
200: cycling CLIPGenericStatus
201: Flur EG Sensor Flur_EG_MDIR_HUE_1_Motion ZLLPresence
202: Hue ambient light sensor 5 hueBridge2_HUESensor202 ZLLLightLevel
203: Hue temperature sensor 5 hueBridge2_HUESensor203 ZLLTemperature
208: presenceState CLIPGenericStatus
209: textState CLIPGenericStatus
Ein get <bridge> ignored gibt auf beiden Bridges keinen Treffer zurück. Mir scheint, als würden die zu ignorierenden Sensoren nicht dauerhaft gesetzt bleiben. Ich meine, ich hätte beim get <bridge> sensors zwischendurch mal eine "ignored" gesehen, aber jetzt nach einem Neustart ist das wieder weg.
Hier noch die Attribute meiner Bridges. Wenn Du ein ellenlanges List der Bridges haben willst, sag bescheid. Die sind wirklich lang....
Attributes:
alias HUE Bridge 2
createGroupReadings 1
httpUtils 1
icon hue_filled_bridge_v2
key xxxxxxxxxxx
queryAfterSet 1
room Philips HUE
sortby 2 Schon mal Danke im Voraus. Ich hoffe, die Infos helfen
hast du autocreate aktiv?
gibt das get ignored etwas zurück wenn du vorher ein set <bridge> autocreate aufrufst?
hast du zufällig direkt oder indirekt define für die bridge neu aufgerufen? z.b. per modify? per config file editieren?
Zitat von: justme1968 am 29 Januar 2022, 16:24:29
hast du autocreate aktiv?
gibt das get ignored etwas zurück wenn du vorher ein set <bridge> autocreate aufrufst?
hast du zufällig direkt oder indirekt define für die bridge neu aufgerufen? z.b. per modify? per config file editieren?
Ein globales autocreate habe ich (wegen ständig nervender, sich verändernder Intertechno-Devices meiner Nachbarn) nicht aktiv. Ein autocreate auf einer der Bridges liefert mir:
created 0/0/0 devices (ignored 0/0/19) Wenn ich jetzt wieder ein
get <bridge> sensors ausführe, zeigt er die Senoren wieder als ignored an.
ID NAME FHEM TYPE
1: Daylight hueBridge2_HUESensor1 Daylight
2: Hue temperature sensor 1 hueBridge2_HUESensor2 ZLLTemperature
3: Flur UG Sensor Flur_UG_MDIR_HUE_1_Motion ZLLPresence
4: Hue ambient light sensor 1 hueBridge2_HUESensor4 ZLLLightLevel
5: Hue temperature sensor 2 hueBridge2_HUESensor5 ZLLTemperature
6: Keller Sensor Keller_MDIR_HUE_1_Motion ZLLPresence
7: Hue ambient light sensor 2 hueBridge2_HUESensor7 ZLLLightLevel
10: Hue Switch Keller hueBridge2_HUESensor10 ZLLSwitch
11: Dimmer Switch 10 SceneCycle (ignored) CLIPGenericStatus
12: Hue temperature sensor 3 hueBridge2_HUESensor12 ZLLTemperature
13: Flur OG Sensor Flur_OG_MDIR_HUE_1_Motion ZLLPresence
14: Hue ambient light sensor 3 hueBridge2_HUESensor14 ZLLLightLevel
22: Licht-Status (ignored) CLIPGenericStatus
23: Hue outdoor temperature sensor 1 Pergola_MDIR_HUE_1_Temp ZLLTemperature
24: Pergola Sensor Pergola_MDIR_HUE_1_Motion ZLLPresence
25: Hue outdoor ambient light sensor hueBridge2_HUESensor25 ZLLLightLevel
47: Terrasse Sensor Terrasse_MDIR_HUE_2_Motion ZLLPresence
48: Hue outdoor ambient light sensor hueBridge2_HUESensor48 ZLLLightLevel
49: Hue outdoor temperature sensor 2 Terrasse_MDIR_HUE_2_Temp ZLLTemperature
65: presenceState (ignored) CLIPGenericStatus
74: presenceState (ignored) CLIPGenericStatus
90: Terrasse and Gartenzaun, Vibrant (ignored) CLIPGenericStatus
119: presenceState (ignored) CLIPGenericStatus
120: textState (ignored) CLIPGenericStatus
142: presenceState (ignored) CLIPGenericStatus
143: textState (ignored) CLIPGenericStatus
144: presenceState (ignored) CLIPGenericStatus
145: textState (ignored) CLIPGenericStatus
146: presenceState (ignored) CLIPGenericStatus
147: textState (ignored) CLIPGenericStatus
184: Hue Button Garten hueBridge2_HUESensor184 ZLLSwitch
197: dimDirection (ignored) CLIPGenericStatus
198: isDimming (ignored) CLIPGenericStatus
199: slotState (ignored) CLIPGenericStatus
200: cycling (ignored) CLIPGenericStatus
201: Flur EG Sensor Flur_EG_MDIR_HUE_1_Motion ZLLPresence
202: Hue ambient light sensor 5 hueBridge2_HUESensor202 ZLLLightLevel
203: Hue temperature sensor 5 hueBridge2_HUESensor203 ZLLTemperature
208: presenceState (ignored) CLIPGenericStatus
209: textState (ignored) CLIPGenericStatus
Danach gibt ein
get <bridge> ignored auch erwartungsgemäß folgendes zurück.
hueBridge2-S11
hueBridge2-S119
hueBridge2-S120
hueBridge2-S142
hueBridge2-S143
hueBridge2-S144
hueBridge2-S145
hueBridge2-S146
hueBridge2-S147
hueBridge2-S197
hueBridge2-S198
hueBridge2-S199
hueBridge2-S200
hueBridge2-S208
hueBridge2-S209
hueBridge2-S22
hueBridge2-S65
hueBridge2-S74
hueBridge2-S90
Danach hören auch die Log-Einträge auf. Leider nur bis zum nächsten Neustart von FHEM.
Sag mir jetzt bitte nicht, dass ich das globale autocreate dauerhaft an lassen muss, damit das richtig funktioniert....
Bitte das autocreate der HUE-Bridge nicht an das globale autocreate koppeln. Von mir aus trigger ein set bridge autocreate nach einem global initialize...
Ich kann das Verhalten jetzt auch reproduzieren. Ohne globalem autocreate werden die unnötigen Sensoren nach Neustart wieder nicht ignoriert und Log füllt sich wieder. Mit globalem autocreate wird wohl nach Neustart auch ein set bridge autocreate getriggert und dann ignoriert er auch korrekt die Sensoren.
die interne ignored liste des moduls wird in der autocreate routine gefüllt.
natürlich ist das automatisch autocreate des moduls ans globale autocreate gekoppelt.dafür ist es ja schließlich da.
du kannst aber das globale autocreate aktivieren und nur für intertechno deaktivieren.
oder du baust dir selber ein notify auf initialize und rufst set <bridge> autocreate auf.
Vielen Dank!
Mit den ignores beim autocreate hatte ich früher mal Probleme, dass diese nicht richtig zuverlässig funktioniert haben. Ich lasse autocreate jetzt mal ne Weile an und schaue, was da so hoch kommt. Ansonsten wird wohl das notify herhalten müssen. Das war auch meine erste Idee mit global initialized ;) --> klappt nicht, da initialized scheinbar zu früh (findet keine ignored devices).
Wenn Du das Bridge autocreate zukünftig noch etwas unabhängiger machen kannst, sehr gerne.
Für den Moment bin ich mal soweit happy. Danke für die Unterstützung.
@christian.71: schau dir bitte mal die erklärung und die test version von hier: https://forum.fhem.de/index.php/topic,11020.msg1204325.html#msg1204325 an.
Zitat von: justme1968 am 28 Januar 2022, 11:43:12
d.h. nichts genaues weiss man nicht. vielleicht hat es auswirkung auf das neu aushandeln der ssl schlüssel nach einer gewissen zeit. komisch ist dann aber das es bisher nur bei dir zu beobachten ist.
ich habe been eine version des bridge moduls mit dem neuen attribut eventstreamTimeout eingecheckt. das sollte dir helfen. versuch ruhig mal es auf 43200 (12 stunden) zu setzen.
Vielen Dank für die schnelle Hilfe - das hat erwartungsgemäss funkioniert und bleibt jetzt ersteinmal so. Wenn mal Zeit ist, dann teste ich mal mit einer frischen FHEM Installation auf einem anderen System.
Viele Grüsse
Christian
Zitat von: justme1968 am 29 Januar 2022, 21:24:18
@christian.71: schau dir bitte mal die erklärung und die test version von hier: https://forum.fhem.de/index.php/topic,11020.msg1204325.html#msg1204325 an.
Ich habe mal die neue Version getestet, nun wird der richtige state angezeigt, auch ohne das Attribut queryAfterEvent. Es ist jetzt halt nur gefühlt etwas langsamer. Wenn man nicht unbedingt die Abfrage benötigt, ob lange gedrückt wurde, empfielt es sich das attribut "input" zu verwenden. Scheint auch ein neues attribut zu sein.
Nochmals vielen Dank für die schnelle Hilfe und das neue Modul. Ich finde es auch klasse, dass man nun auch die dynamischen Szenen aktivieren kann und der candle und fire Effekt kam auch bei der Frau gut an. ;D
Hallo,
seit den letzten Updates ist mir aufgefallen, dass meine Bewegungsmelder, egal ob über deConz od. Hue Bridge, nach einer motion - nomotion Folge ein weiteres motion erfolgt, ohne das Bewegung stattgefunden hat.
Muss ich hier nach den Updates noch etwas besonderes einstellen?
Danke im Voraus und VG Dieter
die ausgabe im event monitor und ein log mit verbose 4 wäre hilfreich.
Zitat von: justme1968 am 06 Februar 2022, 19:19:15
die ausgabe im event monitor und ein log mit verbose 4 wäre hilfreich.
Bei der Küche kann ich es nicht jedes mal reproduzieren, daher die Infos vom Schlafzimmer.
Bei Bewegung schaltet Licht ein.
Licht per Schalter ausgeschaltet.
Danach schaltet Licht wieder ein obwohl keine Bewegung stattgefunden hat.
Eventmonitor:
2022-02-07 06:30:44.026 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 06:30:44.038 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 06:30:44.045 HOMEMODE Home lastMotion: BM_Schlafzimmer_Motion
2022-02-07 06:30:44.060 HOMEMODE Home motionsSensors: BM_Flur_OG2_Motion,BM_Schlafzimmer_Motion
2022-02-07 06:30:44.060 HOMEMODE Home motionsSensors_hr: BM_Flur_OG2_Motion und BM_Schlafzimmer_Motion
2022-02-07 06:30:44.060 HOMEMODE Home motionsInside: BM_Flur_OG2_Motion,BM_Schlafzimmer_Motion
2022-02-07 06:30:44.060 HOMEMODE Home motionsInside_hr: BM_Flur_OG2_Motion und BM_Schlafzimmer_Motion
2022-02-07 06:30:43 HUEDevice BM_Schlafzimmer_Motion motion
2022-02-07 06:31:13.133 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 06:31:13.144 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 06:30:43 HUEDevice BM_Schlafzimmer_Motion temperature: 22
2022-02-07 06:30:43 HUEDevice BM_Schlafzimmer_Motion lastseen: 2022-02-07T05:30Z
2022-02-07 06:30:43 HUEDevice BM_Schlafzimmer_Motion battery: 95
2022-02-07 06:30:43 HUEDevice BM_Schlafzimmer_Motion reachable: 1
2022-02-07 06:30:43 HUEDevice BM_Schlafzimmer_Motion batteryPercent: 95
2022-02-07 06:32:11.163 HOMEMODE Home motionsSensors: BM_Schlafzimmer_Motion
2022-02-07 06:32:11.163 HOMEMODE Home motionsSensors_hr: BM_Schlafzimmer_Motion
2022-02-07 06:32:11.163 HOMEMODE Home motionsInside: BM_Schlafzimmer_Motion
2022-02-07 06:32:11.163 HOMEMODE Home motionsInside_hr: BM_Schlafzimmer_Motion
2022-02-07 06:32:14.043 DOIF di_Schlafzimmerlicht wait_timer: 07.02.2022 06:34:16 cmd_2_1 BM_Schlafzimmer_Motion
2022-02-07 06:32:14.055 HOMEMODE Home lastMotionClosed: BM_Schlafzimmer_Motion
2022-02-07 06:32:14 HUEDevice BM_Schlafzimmer_Motion nomotion
2022-02-07 06:32:14 HUEDevice BM_Schlafzimmer_Motion batteryPercent: 95
2022-02-07 06:32:14 HUEDevice BM_Schlafzimmer_Motion reachable: 1
2022-02-07 06:32:14 HUEDevice BM_Schlafzimmer_Motion lastseen: 2022-02-07T05:30Z
2022-02-07 06:32:14 HUEDevice BM_Schlafzimmer_Motion battery: 95
2022-02-07 06:32:14 HUEDevice BM_Schlafzimmer_Motion temperature: 22
2022-02-07 06:34:16.073 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 06:34:16.086 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 06:34:16.089 DOIF di_Schlafzimmerlicht wait_timer: 07.02.2022 06:39:16 cmd_2_3 BM_Schlafzimmer_Motion
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion temperature: 23
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion battery: 95
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion reachable: 1
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion batteryPercent: 95
2022-02-07 06:38:33.365 HOMEMODE Home prevMotionClosed: BM_Schlafzimmer_Motion
2022-02-07 06:38:33.365 HOMEMODE Home lastMotionClosed: BM_Schlafzimmer_Motion
2022-02-07 06:38:33 HUEDevice BM_Schlafzimmer_Motion nomotion
2022-02-07 06:38:33 HUEDevice BM_Schlafzimmer_Motion lastseen: 2022-02-07T05:38Z
2022-02-07 06:39:16.120 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_MotionLog:
2022.02.07 06:30:13.046 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 06:30:13.046 4: BM_Schlafzimmer_Motion: ignoring reading temperature with timestamp 2022-02-07 06:09:54, current reading timestamp is 2022-02-07 06:09:54
2022.02.07 06:30:13.046 4: BM_Schlafzimmer_Motion: ignoring reading lastseen with timestamp 2022-02-07 06:09:54, current reading timestamp is 2022-02-07 06:09:54
2022.02.07 06:30:13.047 4: BM_Schlafzimmer_Motion: ignoring reading battery with timestamp 2022-02-07 06:09:54, current reading timestamp is 2022-02-07 06:09:54
2022.02.07 06:30:13.047 4: BM_Schlafzimmer_Motion: ignoring reading reachable with timestamp 2022-02-07 06:09:54, current reading timestamp is 2022-02-07 06:09:54
2022.02.07 06:30:13.047 4: BM_Schlafzimmer_Motion: ignoring reading state with timestamp 2022-02-07 06:09:54, current reading timestamp is 2022-02-07 06:09:54
2022.02.07 06:30:13.047 4: BM_Schlafzimmer_Motion: ignoring reading batteryPercent with timestamp 2022-02-07 06:09:54, current reading timestamp is 2022-02-07 06:09:54
2022.02.07 06:30:44.007 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 06:30:44.007 4: BM_Schlafzimmer_Motion: bridge has events api: 0
2022.02.07 06:30:44.007 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 06:30:44.007 4: BM_Schlafzimmer_Motion: bridge has events api: 0
2022.02.07 06:31:13.093 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 06:31:13.093 4: BM_Schlafzimmer_Motion: ignoring reading state with timestamp 2022-02-07 06:30:43, current reading timestamp is 2022-02-07 06:30:43
2022.02.07 06:32:13.163 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 06:32:13.164 4: BM_Schlafzimmer_Motion: ignoring reading state with timestamp 2022-02-07 06:30:43, current reading timestamp is 2022-02-07 06:30:43
2022.02.07 06:32:13.164 4: BM_Schlafzimmer_Motion: ignoring reading batteryPercent with timestamp 2022-02-07 06:30:43, current reading timestamp is 2022-02-07 06:30:43
2022.02.07 06:32:13.164 4: BM_Schlafzimmer_Motion: ignoring reading lastseen with timestamp 2022-02-07 06:30:43, current reading timestamp is 2022-02-07 06:30:43
2022.02.07 06:32:13.164 4: BM_Schlafzimmer_Motion: ignoring reading battery with timestamp 2022-02-07 06:30:43, current reading timestamp is 2022-02-07 06:30:43
2022.02.07 06:32:13.164 4: BM_Schlafzimmer_Motion: ignoring reading reachable with timestamp 2022-02-07 06:30:43, current reading timestamp is 2022-02-07 06:30:43
2022.02.07 06:32:13.164 4: BM_Schlafzimmer_Motion: ignoring reading temperature with timestamp 2022-02-07 06:30:43, current reading timestamp is 2022-02-07 06:30:43
2022.02.07 06:32:14.020 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 06:32:14.021 4: BM_Schlafzimmer_Motion: bridge has events api: 0
2022.02.07 06:33:13.240 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 06:33:13.240 4: BM_Schlafzimmer_Motion: ignoring reading state with timestamp 2022-02-07 06:32:14, current reading timestamp is 2022-02-07 06:32:14DOIF
DEF ([BM_Schlafzimmer_Motion] eq "motion" and [?rr_Dieter:state] ne "asleep" and ([?BM_Schlafzimmer_Light_Temp:lux] < 40 or [?$SELF:oldbrightness] < 40))
(IF ([Schlafzimmerlicht:state] eq "off")(setreading $SELF oldbrightness 0))
(set Schlafzimmerlicht pct 80 : ct 270)
DOELSE
(set Schlafzimmerlicht off)
(set BM_Schlafzimmer_Light_Temp statusRequest)
(setreading $SELF oldbrightness 999)
FUUID 5e9c6e83-f33f-cd72-c206-920526946871ef82
FVERSION 98_DOIF.pm:0.255900/2022-01-30
MODEL FHEM
NAME di_Schlafzimmerlicht
NOTIFYDEV global,BM_Schlafzimmer_Motion
NR 351
NTFY_ORDER 50-di_Schlafzimmerlicht
STATE cmd_2
TYPE DOIF
VERSION 25590 2022-01-30 11:30:21
READINGS:
2022-02-07 06:39:13 Device BM_Schlafzimmer_Motion
2022-02-07 06:39:16 cmd 2.3
2022-02-07 06:39:16 cmd_event BM_Schlafzimmer_Motion
2022-02-07 06:39:16 cmd_nr 2
2022-02-07 06:39:16 cmd_seqnr 3
2022-02-07 06:39:13 e_BM_Schlafzimmer_Motion_STATE nomotion
2022-02-07 06:30:57 mode enabled
2022-02-07 06:39:16 oldbrightness 999
2022-02-07 06:39:16 state cmd_2
2022-02-07 06:39:16 wait_timer no timer
Regex:
accu:
collect:
cond:
BM_Schlafzimmer_Motion:
0:
&STATE ^BM_Schlafzimmer_Motion$
attr:
cmdState:
wait:
0:
0
0
1:
122
0
300
waitdel:
condition:
0 ::InternalDoIf($hash,'BM_Schlafzimmer_Motion','STATE') eq "motion" and ::ReadingValDoIf($hash,'rr_Dieter','state') ne "asleep" and (::ReadingValDoIf($hash,'BM_Schlafzimmer_Light_Temp','lux') < 40 or ::ReadingValDoIf($hash,'di_Schlafzimmerlicht','oldbrightness') < 40)
do:
0:
0 IF ([Schlafzimmerlicht:state] eq "off")(setreading di_Schlafzimmerlicht oldbrightness 0)
1 set Schlafzimmerlicht pct 80 : ct 270
1:
0 set Schlafzimmerlicht off
1 set BM_Schlafzimmer_Light_Temp statusRequest
2 setreading di_Schlafzimmerlicht oldbrightness 999
helper:
NOTIFYDEV global,BM_Schlafzimmer_Motion
event lastseen: 2022-02-07T05:38Z
globalinit 1
last_timer 0
sleepdevice BM_Schlafzimmer_Motion
sleepsubtimer -1
sleeptimer -1
timerdev BM_Schlafzimmer_Motion
timerevent lastseen: 2022-02-07T05:38Z
triggerDev BM_Schlafzimmer_Motion
DOIF_eventa:
cmd_nr: 2
cmd_seqnr: 3
cmd_event: BM_Schlafzimmer_Motion
cmd_2
DOIF_eventas:
cmd_nr: 2
cmd_seqnr: 3
cmd_event: BM_Schlafzimmer_Motion
state: cmd_2
timerevents:
lastseen: 2022-02-07T05:38Z
timereventsState:
lastseen: 2022-02-07T05:38Z
triggerEvents:
lastseen: 2022-02-07T05:38Z
triggerEventsState:
lastseen: 2022-02-07T05:38Z
internals:
all BM_Schlafzimmer_Motion:STATE
perlblock:
readings:
trigger:
uiState:
uiTable:
Attributes:
DbLogExclude .*
do always
wait 0,0:122,0,300Bewegungsmelder
DEF sensor 14 IODev=deCONZ
FUUID 5d66b736-f33f-cd72-dd21-9989c550f82c52ef
FVERSION 31_HUEDevice.pm:0.256000/2022-01-31
ID S14
INTERVAL
IODev deCONZ
NAME BM_Schlafzimmer_Motion
NR 283
STATE nomotion
TYPE HUEDevice
lastannounced 2021-12-30T23:57:26Z
manufacturername LUMI
modelid lumi.sensor_motion.aq2
name BM_Schlafzimmer
on 1
reachable 1
swversion 20170627
type ZHAPresence
uniqueid 00:15:8d:00:03:1b:29:de-01-0406
READINGS:
2022-02-04 16:55:19 IODev deCONZ
2022-02-07 06:38:33 battery 95
2022-02-07 06:38:33 batteryPercent 95
2022-02-07 06:38:33 lastseen 2022-02-07T05:38Z
2022-02-07 06:38:33 reachable 1
2022-02-07 06:38:33 state nomotion
2022-02-07 06:38:33 temperature 23
helper:
devtype S
state nomotion
update_timeout 1
configList:
json:
ep 1
etag bfe96e731d326b6afb2943221f1fe5eb
lastannounced 2021-12-30T23:57:26Z
lastseen 2022-02-07T05:38Z
manufacturername LUMI
modelid lumi.sensor_motion.aq2
name BM_Schlafzimmer
swversion 20170627
type ZHAPresence
uniqueid 00:15:8d:00:03:1b:29:de-01-0406
config:
battery 95
duration 90
temperature 2300
state:
lastupdated 2022-02-07T05:38:33.312
setList:
Attributes:
DbLogExclude .*
HomeModeAlarmActive armaway
HomeSensorLocation inside
IODev deCONZ
devStateIcon motion:people_sensor nomotion:message_presence
group motionDetector
icon motion_detector
model lumi.sensor_motion.aq2
room HUEDevice
userattr HomeModeAlarmActive HomeReadings HomeValues HomeSensorLocation:inside,outside
verbose 4Ich hoffe das sind die gewünschten Infos. Falls nicht, bitte Bescheid geben.
Danke schon mal für deine Hilfe.
VG Dieter
wenn ich mir den event monitor von oben anschaue sehe ich drei events bei denen es um bewegung geht.
2022-02-07 06:30:43 HUEDevice BM_Schlafzimmer_Motion motion
2022-02-07 06:32:14 HUEDevice BM_Schlafzimmer_Motion nomotion
2022-02-07 06:38:33 HUEDevice BM_Schlafzimmer_Motion nomotion
d.h. da ist kein weiteres motion.
das hier: 2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion temperature: 23
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion battery: 95
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion reachable: 1
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion batteryPercent: 95
2022-02-07 06:38:33.365 HOMEMODE Home prevMotionClosed: BM_Schlafzimmer_Motion
2022-02-07 06:38:33.365 HOMEMODE Home lastMotionClosed: BM_Schlafzimmer_Motion
schaut für mich so aus als ob die anderen readings etwas triggern.
sind deine regex genau genug?
Zitat von: justme1968 am 07 Februar 2022, 09:01:09
wenn ich mir den event monitor von oben anschaue sehe ich drei events bei denen es um bewegung geht.
2022-02-07 06:30:43 HUEDevice BM_Schlafzimmer_Motion motion
2022-02-07 06:32:14 HUEDevice BM_Schlafzimmer_Motion nomotion
2022-02-07 06:38:33 HUEDevice BM_Schlafzimmer_Motion nomotion
d.h. da ist kein weiteres motion.
das hier: 2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion temperature: 23
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion battery: 95
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion reachable: 1
2022-02-07 06:38:33.354 HUEDevice BM_Schlafzimmer_Motion batteryPercent: 95
2022-02-07 06:38:33.365 HOMEMODE Home prevMotionClosed: BM_Schlafzimmer_Motion
2022-02-07 06:38:33.365 HOMEMODE Home lastMotionClosed: BM_Schlafzimmer_Motion
schaut für mich so aus als ob die anderen readings etwas triggern.
sind deine regex genau genug?
Die 2 Zeilen vom HOMEMODE kann man ignorieren, damit schalte ich nichts.
Für den Bewegungsmelder bzw. das Licht im Schlafzimmer habe ich das besagt DOIF.
Was meinst du jetzt mit "sind deine regex genau genug?"?
ZitatDie 2 Zeilen vom HOMEMODE kann man ignorieren, damit schalte ich nichts.
trozdem sollte homemode hier nicht reagieren oder?
ZitatWas meinst du jetzt mit "sind deine regex genau genug?"?
mit denen spezifiziert ist worauf reagiert werden soll.
wie gesagt: zumindest im list sehe ich kein zweites motion. wie kommst du drauf das es eins gibt?
Zitat von: justme1968 am 07 Februar 2022, 09:28:48
trozdem sollte homemode hier nicht reagieren oder?
mit denen spezifiziert ist worauf reagiert werden soll.
wie gesagt: zumindest im list sehe ich kein zweites motion. wie kommst du drauf das es eins gibt?
Die Bewegungsmelder sind seit jeher in homemode angelegt, aber ohne Funktion.
Reagieren tut doch das DOIF mit "[BM_Schlafzimmer_Motion] eq "motion"
Oder verstehe ich dich falsch?
Ich behaupte nicht das es ein weiteres motion gibt.
Meine Vermutung ist nur, dass es mit den letzten Updates zu tun hat.
Vorher hatte ich diese Probleme nicht.
Muss nach den Neuerungen evtl. in den Devices etwas anders eingestellt werden?
Hi Andre,
ich habe seit dem Update auch Probleme mit Doppelevents bei Deconz/Conbee 2.
Zum Beispiel kommen die Events beim Drücken der Tradfri Shortcut Buttons doppelt an.
Bei mir sind die auch wirklich doppelt im Event Monitor sichtbar.
Allerdings habe ich zeitgleich zum FHEM Update auch Deconz geupdated.
Bin mir jetzt nicht sicher, ob es eher an Deconz liegt.
Kann man irgendwie recht einfach sehen was aus Deconz raus kommt?
mit verbose 4 (eventuell 5) siehst du was von aussen kommt und was das modul draus macht. wenn da was zu sehen ist bitte zeigen.
Und ich vermute das ist auch genau mein Problem.
bei dir ist zumindest im log oben klein doppeltes event zu sehen.
Zitat von: justme1968 am 07 Februar 2022, 10:15:39
bei dir ist zumindest im log oben klein doppeltes event zu sehen.
Hier mal das Log vom Bewegungsmelder + Schalter
2022.02.07 10:25:03.437 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 10:25:03.437 4: BM_Schlafzimmer_Motion: bridge has events api: 0
2022.02.07 10:25:03.438 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 10:25:03.438 4: BM_Schlafzimmer_Motion: bridge has events api: 0
2022.02.07 10:25:03.962 4: parse status message for Schalter_IKEA
2022.02.07 10:25:03.962 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:03.963 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:03.963 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:03.963 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:03.963 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:04.956 4: parse status message for Schalter_IKEA
2022.02.07 10:25:04.957 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:04.957 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:04.957 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:04.958 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:04.958 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:05.948 4: parse status message for Schalter_IKEA
2022.02.07 10:25:05.948 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:05.949 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:05.949 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:05.949 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:05.949 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:24:34, current reading timestamp is 2022-02-07 10:24:34
2022.02.07 10:25:06.158 4: parse status message for Schalter_IKEA
2022.02.07 10:25:06.158 4: Schalter_IKEA: bridge has events api: 0
2022.02.07 10:25:06.958 4: parse status message for Schalter_IKEA
2022.02.07 10:25:06.959 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:07.960 4: parse status message for Schalter_IKEA
2022.02.07 10:25:07.960 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:07.961 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:07.961 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:07.961 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:07.961 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:08.964 4: parse status message for Schalter_IKEA
2022.02.07 10:25:08.965 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:08.965 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:08.966 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:08.966 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:08.966 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:09.965 4: parse status message for Schalter_IKEA
2022.02.07 10:25:09.966 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:09.966 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:09.966 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:09.966 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:09.967 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:10.965 4: parse status message for Schalter_IKEA
2022.02.07 10:25:10.966 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:10.966 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:10.967 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:10.967 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:10.967 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:11.958 4: parse status message for Schalter_IKEA
2022.02.07 10:25:11.958 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:11.958 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:11.958 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:11.958 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:11.958 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.015 4: parse status message for Schalter_IKEA
2022.02.07 10:25:13.015 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.015 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.015 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.015 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.015 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.998 4: parse status message for Schalter_IKEA
2022.02.07 10:25:13.998 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.998 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.998 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.998 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:13.999 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:15.012 4: parse status message for Schalter_IKEA
2022.02.07 10:25:15.013 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:15.014 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:15.014 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:15.014 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:15.014 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:16.003 4: parse status message for Schalter_IKEA
2022.02.07 10:25:16.003 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:16.003 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:16.003 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:16.003 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:16.003 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:17.015 4: parse status message for Schalter_IKEA
2022.02.07 10:25:17.016 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:17.016 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:17.016 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:17.016 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:17.016 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:18.017 4: parse status message for Schalter_IKEA
2022.02.07 10:25:18.018 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:18.018 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:18.018 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:18.018 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:18.018 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:19.026 4: parse status message for Schalter_IKEA
2022.02.07 10:25:19.027 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:19.028 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:19.028 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:19.028 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:19.028 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:20.027 4: parse status message for Schalter_IKEA
2022.02.07 10:25:20.028 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:20.028 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:20.029 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:20.029 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:20.029 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:21.023 4: parse status message for Schalter_IKEA
2022.02.07 10:25:21.023 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:21.024 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:21.024 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:21.024 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:21.024 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:22.024 4: parse status message for Schalter_IKEA
2022.02.07 10:25:22.025 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:22.025 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:22.025 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:22.026 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:22.026 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:23.036 4: parse status message for Schalter_IKEA
2022.02.07 10:25:23.037 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:23.037 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:23.037 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:23.038 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:23.038 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:24.030 4: parse status message for Schalter_IKEA
2022.02.07 10:25:24.031 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:24.031 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:24.032 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:24.032 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:24.032 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:25.032 4: parse status message for Schalter_IKEA
2022.02.07 10:25:25.033 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:25.033 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:25.033 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:25.033 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:25.033 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:26.049 4: parse status message for Schalter_IKEA
2022.02.07 10:25:26.050 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:26.051 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:26.051 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:26.051 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:26.051 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:27.038 4: parse status message for Schalter_IKEA
2022.02.07 10:25:27.039 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:27.039 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:27.039 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:27.040 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:27.040 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:28.043 4: parse status message for Schalter_IKEA
2022.02.07 10:25:28.044 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:28.044 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:28.044 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:28.044 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:28.044 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:29.046 4: parse status message for Schalter_IKEA
2022.02.07 10:25:29.046 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:29.046 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:29.047 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:29.047 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:29.047 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:30.049 4: parse status message for Schalter_IKEA
2022.02.07 10:25:30.050 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:30.050 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:30.050 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:30.050 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:30.050 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:31.050 4: parse status message for Schalter_IKEA
2022.02.07 10:25:31.051 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:31.052 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:31.052 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:31.052 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:31.052 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:32.055 4: parse status message for Schalter_IKEA
2022.02.07 10:25:32.056 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:32.056 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:32.056 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:32.056 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:32.057 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:33.053 4: parse status message for Schalter_IKEA
2022.02.07 10:25:33.054 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:33.054 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:33.055 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:33.055 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:33.055 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:34.056 4: parse status message for Schalter_IKEA
2022.02.07 10:25:34.057 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:34.057 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:34.058 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:34.058 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:34.058 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:35.064 4: parse status message for Schalter_IKEA
2022.02.07 10:25:35.065 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:35.065 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:35.065 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:35.065 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:35.065 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:36.061 4: parse status message for Schalter_IKEA
2022.02.07 10:25:36.062 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:36.063 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:36.063 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:36.063 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:36.064 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:37.058 4: parse status message for Schalter_IKEA
2022.02.07 10:25:37.059 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:37.059 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:37.059 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:37.059 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:37.059 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:38.060 4: parse status message for Schalter_IKEA
2022.02.07 10:25:38.061 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:38.061 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:38.061 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:38.061 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:38.062 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:39.067 4: parse status message for Schalter_IKEA
2022.02.07 10:25:39.069 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:39.069 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:39.069 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:39.069 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:39.069 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:40.074 4: parse status message for Schalter_IKEA
2022.02.07 10:25:40.075 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:40.075 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:40.075 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:40.075 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:40.076 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:41.076 4: parse status message for Schalter_IKEA
2022.02.07 10:25:41.077 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:41.078 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:41.078 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:41.078 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:41.078 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:42.325 4: parse status message for Schalter_IKEA
2022.02.07 10:25:42.325 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:42.325 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:42.325 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:42.325 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:42.325 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:43.345 4: parse status message for Schalter_IKEA
2022.02.07 10:25:43.345 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:43.345 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:43.345 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:43.345 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:43.346 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:44.344 4: parse status message for Schalter_IKEA
2022.02.07 10:25:44.345 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:44.345 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:44.345 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:44.345 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:44.346 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:45.349 4: parse status message for Schalter_IKEA
2022.02.07 10:25:45.350 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:45.350 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:45.350 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:45.350 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:45.350 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:46.347 4: parse status message for Schalter_IKEA
2022.02.07 10:25:46.348 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:46.348 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:46.348 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:46.348 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:46.348 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:47.371 4: parse status message for Schalter_IKEA
2022.02.07 10:25:47.371 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:47.371 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:47.371 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:47.371 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:47.371 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:48.368 4: parse status message for Schalter_IKEA
2022.02.07 10:25:48.368 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:48.368 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:48.368 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:48.368 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:48.368 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:49.398 4: parse status message for Schalter_IKEA
2022.02.07 10:25:49.398 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:49.398 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:49.398 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:49.398 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:49.398 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:50.384 4: parse status message for Schalter_IKEA
2022.02.07 10:25:50.385 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:50.385 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:50.385 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:50.385 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:50.385 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:51.400 4: parse status message for Schalter_IKEA
2022.02.07 10:25:51.400 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:51.400 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:51.400 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:51.400 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:51.400 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:52.380 4: parse status message for Schalter_IKEA
2022.02.07 10:25:52.380 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:52.380 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:52.380 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:52.380 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:52.380 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:53.393 4: parse status message for Schalter_IKEA
2022.02.07 10:25:53.394 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:53.394 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:53.395 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:53.395 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:53.395 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:54.397 4: parse status message for Schalter_IKEA
2022.02.07 10:25:54.398 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:54.398 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:54.398 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:54.399 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:54.399 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:55.407 4: parse status message for Schalter_IKEA
2022.02.07 10:25:55.407 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:55.408 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:55.408 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:55.408 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:55.408 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:56.393 4: parse status message for Schalter_IKEA
2022.02.07 10:25:56.393 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:56.393 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:56.393 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:56.393 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:56.393 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:57.400 4: parse status message for Schalter_IKEA
2022.02.07 10:25:57.401 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:57.401 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:57.402 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:57.402 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:57.402 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:58.395 4: parse status message for Schalter_IKEA
2022.02.07 10:25:58.395 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:58.395 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:58.395 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:58.395 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:58.395 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:59.404 4: parse status message for Schalter_IKEA
2022.02.07 10:25:59.405 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:59.405 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:59.406 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:59.406 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:25:59.406 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:00.406 4: parse status message for Schalter_IKEA
2022.02.07 10:26:00.407 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:00.407 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:00.408 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:00.408 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:00.408 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:00.989 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 10:26:00.989 4: BM_Schlafzimmer_Motion: ignoring reading state with timestamp 2022-02-07 10:25:03, current reading timestamp is 2022-02-07 10:25:03
2022.02.07 10:26:01.024 4: parse status message for Schalter_IKEA
2022.02.07 10:26:01.024 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:01.024 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:01.024 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:01.024 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:01.024 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:01.407 4: parse status message for Schalter_IKEA
2022.02.07 10:26:01.408 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:01.408 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:01.409 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:01.409 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:01.409 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:02.407 4: parse status message for Schalter_IKEA
2022.02.07 10:26:02.408 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:02.408 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:02.408 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:02.409 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:02.409 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:03.409 4: parse status message for Schalter_IKEA
2022.02.07 10:26:03.410 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:03.410 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:03.411 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:03.411 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:03.411 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:04.407 4: parse status message for Schalter_IKEA
2022.02.07 10:26:04.408 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:04.408 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:04.408 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:04.408 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:04.408 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:05.421 4: parse status message for Schalter_IKEA
2022.02.07 10:26:05.421 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:05.422 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:05.422 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:05.422 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:05.422 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:06.419 4: parse status message for Schalter_IKEA
2022.02.07 10:26:06.420 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:06.420 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:06.420 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:06.421 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06
2022.02.07 10:26:06.421 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:25:06, current reading timestamp is 2022-02-07 10:25:06und hier noch mal vom Eventmonitor
2022-02-07 10:31:17.693 HOMEMODE Home prevMotion: BM_Schlafzimmer_Motion
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Light_Temp dark: 1
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Light_Temp lightlevel: 4772
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Light_Temp daylight: 0
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Light_Temp lux: 3
2022-02-07 10:31:20.591 DOIF di_Schlafzimmerlicht wait_timer: no timer
2022-02-07 10:31:20.596 DOIF di_Schlafzimmerlicht oldbrightness: 0
2022-02-07 10:31:20.603 DOIF di_Schlafzimmerlicht cmd_nr: 1
2022-02-07 10:31:20.603 DOIF di_Schlafzimmerlicht cmd_seqnr: 1
2022-02-07 10:31:20.603 DOIF di_Schlafzimmerlicht cmd: 1.1
2022-02-07 10:31:20.603 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 10:31:20.603 DOIF di_Schlafzimmerlicht cmd_1_1
2022-02-07 10:31:20.611 DOIF di_Schlafzimmerlicht cmd_nr: 1
2022-02-07 10:31:20.611 DOIF di_Schlafzimmerlicht cmd_seqnr: 2
2022-02-07 10:31:20.611 DOIF di_Schlafzimmerlicht cmd: 1.2
2022-02-07 10:31:20.611 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 10:31:20.611 DOIF di_Schlafzimmerlicht cmd_1
2022-02-07 10:31:20.617 HOMEMODE Home lastMotion: BM_Schlafzimmer_Motion
2022-02-07 10:31:20.629 HOMEMODE Home motionsSensors: BM_Flur_OG2_Motion,BM_Schlafzimmer_Motion
2022-02-07 10:31:20.629 HOMEMODE Home motionsSensors_hr: BM_Flur_OG2_Motion und BM_Schlafzimmer_Motion
2022-02-07 10:31:20.629 HOMEMODE Home motionsInside: BM_Flur_OG2_Motion,BM_Schlafzimmer_Motion
2022-02-07 10:31:20.629 HOMEMODE Home motionsInside_hr: BM_Flur_OG2_Motion und BM_Schlafzimmer_Motion
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Motion motion
2022-02-07 10:31:20.646 HUEDevice Schlafzimmerlicht onoff: 1
2022-02-07 10:31:20.646 HUEDevice Schlafzimmerlicht pct: 80
2022-02-07 10:31:20.646 HUEDevice Schlafzimmerlicht dim75%
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Light_Temp batteryPercent: 95
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Light_Temp reachable: 1
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Light_Temp lastseen: 2022-02-07T09:31Z
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Light_Temp battery: 95
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Light_Temp temperature: 23
2022-02-07 10:31:21.017 HUEDevice BM_Schlafzimmer_Light_Temp temperatur_real: 18
2022-02-07 10:31:24.713 DOIF di_Schlafzimmerlicht mode: enabled
2022-02-07 10:31:24.738 HUEDevice Schlafzimmerlicht onoff: 0
2022-02-07 10:31:24.738 HUEDevice Schlafzimmerlicht pct: 0
2022-02-07 10:31:24.738 HUEDevice Schlafzimmerlicht off
2022-02-07 10:32:01.072 DOIF di_Schlafzimmerlicht oldbrightness: 0
2022-02-07 10:32:01.079 DOIF di_Schlafzimmerlicht cmd_nr: 1
2022-02-07 10:32:01.079 DOIF di_Schlafzimmerlicht cmd_seqnr: 1
2022-02-07 10:32:01.079 DOIF di_Schlafzimmerlicht cmd: 1.1
2022-02-07 10:32:01.079 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 10:32:01.079 DOIF di_Schlafzimmerlicht cmd_1_1
2022-02-07 10:32:01.087 DOIF di_Schlafzimmerlicht cmd_nr: 1
2022-02-07 10:32:01.087 DOIF di_Schlafzimmerlicht cmd_seqnr: 2
2022-02-07 10:32:01.087 DOIF di_Schlafzimmerlicht cmd: 1.2
2022-02-07 10:32:01.087 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 10:32:01.087 DOIF di_Schlafzimmerlicht cmd_1
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Motion temperature: 23
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Motion battery: 95
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Motion reachable: 1
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Motion lastseen: 2022-02-07T09:31Z
2022-02-07 10:31:20 HUEDevice BM_Schlafzimmer_Motion batteryPercent: 95
2022-02-07 10:32:01.149 HUEDevice Schlafzimmerlicht lastseen: 2022-02-07T09:31Z
2022-02-07 10:32:01.198 HUEDevice Schlafzimmerlicht onoff: 1
2022-02-07 10:32:01.198 HUEDevice Schlafzimmerlicht pct: 80
2022-02-07 10:32:01.198 HUEDevice Schlafzimmerlicht dim75%10:31:20 wird hier doch nach 10:32 wiederholt. Oder sehe ich das falsch?
die beiden auszüge zeigen unterschiedliche zeiträume und helfen deshalb nicht weiter. wie soll ich denn die rein kommenden daten da den events zuordnen ?
das log geht von 10:25:03.437 bis 10:26:06.421 und der event monitor von 10:31:17.693 bis 10:32:01.198. ausserdem ist die genauigkeit der BM_Schlafzimmer_Motion einträge im eventmonitor anders als der doif einträge. warum ist das so?
zeig bitte auch mal ein list vom bridge device. ich habe keine websocket events gesehen. die sollten eigentlich auch da sein.
bitte stell man verbose auf 5 statt 4 und zeige auch die log eingträge vom bridge device.
Zitat von: justme1968 am 07 Februar 2022, 11:24:17
die beiden auszüge zeigen unterschiedliche zeiträume und helfen deshalb nicht weiter. wie soll ich denn die rein kommenden daten da den events zuordnen ?
das log geht von 10:25:03.437 bis 10:26:06.421 und der event monitor von 10:31:17.693 bis 10:32:01.198. ausserdem ist die genauigkeit der BM_Schlafzimmer_Motion einträge im eventmonitor anders als der doif einträge. warum ist das so?
zeig bitte auch mal ein list vom bridge device. ich habe keine websocket events gesehen. die sollten eigentlich auch da sein.
bitte stell man verbose auf 5 statt 4 und zeige auch die log eingträge vom bridge device.
2022.02.07 11:27:37.339 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:27:37.349 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:27:37.349 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:27:37.352 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:27:37.360 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:27:37.364 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:27:37.364 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:27:37.366 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:27:37.369 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:27:37.371 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:27:37.371 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:27:37.374 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:27:37.374 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:27:37.375 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:27:37.375 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:27:37.407 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:27:37.411 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:27:37.411 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:27:37.412 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:27:37.414 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:27:37.416 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:27:37.416 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:27:37.418 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:27:37.418 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:27:37.424 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:27:37.427 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:27:37.427 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:27:37.433 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:27:37.435 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:27:37.439 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:27:37.441 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:27:37.441 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:27:37.444 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:27:37.445 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:27:37.447 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:27:37.447 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:27:37.448 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:27:37.450 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:27:37.450 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:27:37.452 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:27:37.452 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:27:37.453 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:27:37.453 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:27:37.454 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:27:37.454 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:27:37.454 4: parse status message for Schalter_IKEA
2022.02.07 11:27:37.454 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:27:37.454 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:37.454 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:37.454 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:37.454 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:37.454 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:38.341 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:27:38.352 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:27:38.352 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:27:38.355 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:27:38.364 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:27:38.368 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:27:38.368 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:27:38.371 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:27:38.373 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:27:38.377 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:27:38.377 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:27:38.379 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:27:38.379 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:27:38.380 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:27:38.380 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:27:38.408 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:27:38.410 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:27:38.410 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:27:38.412 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:27:38.414 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:27:38.416 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:27:38.416 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:27:38.417 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:27:38.417 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:27:38.425 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:27:38.427 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:27:38.427 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:27:38.434 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:27:38.435 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:27:38.437 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:27:38.437 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:27:38.439 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:27:38.439 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:27:38.440 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:27:38.442 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:27:38.442 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:27:38.444 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:27:38.445 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:27:38.447 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:27:38.447 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:27:38.448 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:27:38.448 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:27:38.449 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:27:38.451 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:27:38.451 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:27:38.451 4: parse status message for Schalter_IKEA
2022.02.07 11:27:38.451 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:27:38.452 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:38.452 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:38.452 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:38.452 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:38.452 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:39.343 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:27:39.452 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:39.452 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:39.874 5: deCONZ: websocket data: {
't' => 'event',
'attr' => {
'swversion' => '20170627',
'uniqueid' => '00:15:8d:00:03:02:1a:d8-01-0400',
'name' => 'BM_Flur_OG2',
'modelid' => 'lumi.sensor_motion.aq2',
'type' => 'ZHALightLevel',
'manufacturername' => 'LUMI',
'lastseen' => '2022-02-07T10:27Z',
'id' => '26',
'lastannounced' => '2022-01-07T20:34:29Z'
},
'id' => '26',
'uniqueid' => '00:15:8d:00:03:02:1a:d8-01-0400',
'e' => 'changed',
'r' => 'sensors'
}
2022.02.07 11:27:39.875 5: deCONZ: websocket data: {
'state' => {
'lightlevel' => 1,
'lastupdated' => '2022-02-07T10:27:39.871',
'dark' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'lux' => 1,
'daylight' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' )
},
'e' => 'changed',
'uniqueid' => '00:15:8d:00:03:02:1a:d8-01-0400',
'r' => 'sensors',
't' => 'event',
'id' => '26'
}
2022.02.07 11:27:39.887 5: deCONZ: websocket data: {
'attr' => {
'type' => 'ZHAPresence',
'modelid' => 'lumi.sensor_motion.aq2',
'name' => 'BM_Flur_OG2',
'swversion' => '20170627',
'uniqueid' => '00:15:8d:00:03:02:1a:d8-01-0406',
'id' => '25',
'lastannounced' => '2022-01-07T20:34:29Z',
'lastseen' => '2022-02-07T10:27Z',
'manufacturername' => 'LUMI'
},
'id' => '25',
't' => 'event',
'r' => 'sensors',
'uniqueid' => '00:15:8d:00:03:02:1a:d8-01-0406',
'e' => 'changed'
}
2022.02.07 11:27:39.904 5: deCONZ: websocket data: {
't' => 'event',
'id' => '25',
'uniqueid' => '00:15:8d:00:03:02:1a:d8-01-0406',
'state' => {
'lastupdated' => '2022-02-07T10:27:39.902',
'presence' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
},
'e' => 'changed',
'r' => 'sensors'
}
2022.02.07 11:27:39.909 4: using HttpUtils_NonblockingGet: PUT lights/2/state
2022.02.07 11:27:39.950 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/lights/2/state
2022.02.07 11:27:39.950 5: HUEBridge_dispatch: lights/2/state
2022.02.07 11:27:40.345 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:27:40.355 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:27:40.355 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:27:40.358 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:27:40.369 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:27:40.376 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:27:40.376 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:27:40.378 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:27:40.381 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:27:40.383 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:27:40.383 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:27:40.403 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:27:40.403 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:27:40.415 4: using HttpUtils_NonblockingGet: PUT lights/2/state
2022.02.07 11:27:40.426 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:27:40.427 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:27:40.427 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:27:40.427 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:27:40.428 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:27:40.429 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:27:40.432 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:27:40.432 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:27:40.433 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:27:40.433 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:27:40.433 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:27:40.433 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:27:40.434 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:27:40.434 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:27:40.435 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/lights/2/state
2022.02.07 11:27:40.435 5: HUEBridge_dispatch: lights/2/state
2022.02.07 11:27:40.435 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:27:40.436 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:27:40.437 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:27:40.437 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:27:40.438 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:27:40.438 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:27:40.441 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:27:40.442 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:27:40.442 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:27:40.445 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:27:40.446 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:27:40.447 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:27:40.447 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:27:40.448 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:27:40.448 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:27:40.450 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:27:40.452 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:27:40.452 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:27:40.452 4: parse status message for Schalter_IKEA
2022.02.07 11:27:40.452 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:27:40.452 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:40.452 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:40.452 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:40.452 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:40.452 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:41.347 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:27:41.357 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:27:41.357 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:27:41.359 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:27:41.369 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:27:41.369 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:27:41.372 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:27:41.377 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:27:41.378 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:27:41.379 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:27:41.381 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:27:41.384 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:27:41.384 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:27:41.385 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:27:41.385 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:27:41.427 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:27:41.429 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:27:41.430 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:27:41.431 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:27:41.434 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:27:41.434 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:27:41.436 4: using HttpUtils_NonblockingGet: GET lights/2
2022.02.07 11:27:41.437 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:27:41.438 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:27:41.438 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:27:41.440 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:27:41.440 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:27:41.441 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:27:41.441 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:27:41.442 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:27:41.443 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:27:41.446 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:27:41.448 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/lights/2
2022.02.07 11:27:41.449 5: HUEBridge_dispatch: lights/2
2022.02.07 11:27:41.458 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:27:41.458 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:27:41.459 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:27:41.459 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:27:41.461 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:27:41.461 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:27:41.462 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:27:41.462 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:27:41.463 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:27:41.463 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:27:41.464 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:27:41.464 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:27:41.464 4: parse status message for Schalter_IKEA
2022.02.07 11:27:41.464 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:27:41.465 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:41.465 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:41.465 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:41.465 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:41.465 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:45.499 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:45.500 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:27:45.500 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:27:46.355 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:27:46.365 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:27:46.365 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:27:46.371 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:27:46.380 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:27:46.380 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:27:46.382 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:27:46.386 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:27:46.389 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:27:46.391 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:27:46.391 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:27:46.393 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:27:46.393 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:27:46.396 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:27:46.396 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:27:46.431 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:27:46.432 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:27:46.434 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:27:46.434 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:27:46.435 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:27:46.436 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:27:46.463 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:27:46.469 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:27:46.469 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:27:46.472 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:27:46.475 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:27:46.480 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:27:46.483 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:27:46.484 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:27:46.487 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:27:46.488 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:27:46.489 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:27:46.490 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:27:46.493 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:27:46.493 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:27:46.495 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:27:46.495 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:27:46.497 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:27:46.497 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:27:46.498 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:27:46.498 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:27:46.498 4: parse status message for Schalter_IKEA
2022.02.07 11:27:46.498 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:27:46.499 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:46.499 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:46.499 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:46.499 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:46.499 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 10:31:24, current reading timestamp is 2022-02-07 10:31:24
2022.02.07 11:27:46.499 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:27:46.499 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:27:46.500 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:27:46.500 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:27:46.950 5: deCONZ: websocket data: {
'attr' => {
'swversion' => '2.2.008',
'uniqueid' => '14:b4:57:ff:fe:d4:b9:49-01-1000',
'modelid' => 'TRADFRI on/off switch',
'type' => 'ZHASwitch',
'name' => 'Schalter_Schlafzimmer_3',
'lastseen' => '2022-02-07T10:27Z',
'manufacturername' => 'IKEA of Sweden',
'id' => '22',
'lastannounced' => '2022-01-22T16:53:51Z'
},
'id' => '22',
't' => 'event',
'r' => 'sensors',
'uniqueid' => '14:b4:57:ff:fe:d4:b9:49-01-1000',
'e' => 'changed'
}
2022.02.07 11:27:46.950 4: parse status message for Schalter_IKEA
2022.02.07 11:27:46.950 4: Schalter_IKEA: bridge has events api: 0
2022.02.07 11:27:46.952 5: deCONZ: websocket data: {
'uniqueid' => '14:b4:57:ff:fe:d4:b9:49-01-1000',
'e' => 'changed',
'state' => {
'buttonevent' => 2002,
'lastupdated' => '2022-02-07T10:27:46.947'
},
'r' => 'sensors',
't' => 'event',
'id' => '22'
}
2022.02.07 11:27:46.952 4: parse status message for Schalter_IKEA
2022.02.07 11:27:46.952 4: Schalter_IKEA: bridge has events api: 0
2022.02.07 11:27:46.952 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:27:46.965 4: using HttpUtils_NonblockingGet: PUT lights/15/state
2022.02.07 11:27:47.001 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/lights/15/state
2022.02.07 11:27:47.001 5: HUEBridge_dispatch: lights/15/state
2022.02.07 11:27:47.003 5: deCONZ: websocket data: {
'uniqueid' => '00:17:88:01:06:24:d3:de-0b',
'state' => {
'ct' => 270,
'bri' => 205,
'on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
'reachable' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'alert' => undef,
'colormode' => 'ct'
},
'e' => 'changed',
'r' => 'lights',
't' => 'event',
'id' => '15'
}
2022.02.07 11:27:47.015 5: deCONZ: websocket data: {
'r' => 'groups',
'state' => {
'any_on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
'all_on' => $VAR1->{'state'}{'any_on'}
},
'e' => 'changed',
'id' => '65520',
't' => 'event'
}
2022.02.07 11:27:47.015 5: deCONZ: websocket: assuming group 0 for id 65520 in event
2022.02.07 11:27:47.357 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:27:47.362 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:27:47.362 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:27:47.371 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:27:47.373 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:27:47.373 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:27:47.383 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:27:47.386 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:27:47.387 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:27:47.388 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:27:47.391 4: using HttpUtils_Nonblockingdas Log ist zu lang um es hier zu posten, hab mitten drin Teile gelöscht, ich weiß nicht was du benötigst und wie ich es dir liefern kann.
in diesem log ist genau ein einziges event von der bridge das etwas mit motion zu tun hat. für genau den gleichen zeitraum brauche ich den event monitor. wenn dort nicht mehr als ein motion event drin ist nützt es aber nichts.
ist es wirklich so schwer die richtigen infos zu liefern:
- event monitor und log vom gleichen zeitraum
- mit den gleichen geräten
- ohne von hand etwas zu editieren
Zitat von: justme1968 am 07 Februar 2022, 11:38:12
in diesem log ist genau ein einziges event von der bridge das etwas mit motion zu tun hat. für genau den gleichen zeitraum brauche ich den event monitor. wenn dort nicht mehr als ein motion event drin ist nützt es aber nichts.
ist es wirklich so schwer die richtigen infos zu liefern:
- event monitor und log vom gleichen zeitraum
- mit den gleichen geräten
- ohne von hand etwas zu editieren
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Light_Temp dark: 1
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Light_Temp lux: 3
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Light_Temp daylight: 0
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Light_Temp lightlevel: 4772
2022-02-07 11:39:52.327 DOIF di_Schlafzimmerlicht oldbrightness: 0
2022-02-07 11:39:52.336 DOIF di_Schlafzimmerlicht cmd_nr: 1
2022-02-07 11:39:52.336 DOIF di_Schlafzimmerlicht cmd_seqnr: 1
2022-02-07 11:39:52.336 DOIF di_Schlafzimmerlicht cmd: 1.1
2022-02-07 11:39:52.336 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 11:39:52.336 DOIF di_Schlafzimmerlicht cmd_1_1
2022-02-07 11:39:52.346 DOIF di_Schlafzimmerlicht cmd_nr: 1
2022-02-07 11:39:52.346 DOIF di_Schlafzimmerlicht cmd_seqnr: 2
2022-02-07 11:39:52.346 DOIF di_Schlafzimmerlicht cmd: 1.2
2022-02-07 11:39:52.346 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 11:39:52.346 DOIF di_Schlafzimmerlicht cmd_1
2022-02-07 11:39:52.352 HOMEMODE Home lastMotion: BM_Schlafzimmer_Motion
2022-02-07 11:39:52.365 HOMEMODE Home motionsSensors: BM_Flur_EG,BM_Flur_OG,BM_Flur_OG2_Motion,BM_Schlafzimmer_Motion,BM_Wohnzimmer
2022-02-07 11:39:52.365 HOMEMODE Home motionsSensors_hr: BM_Flur_EG, BM_Flur_OG, BM_Flur_OG2_Motion, BM_Schlafzimmer_Motion und BM_Wohnzimmer
2022-02-07 11:39:52.365 HOMEMODE Home motionsInside: BM_Flur_EG,BM_Flur_OG,BM_Flur_OG2_Motion,BM_Schlafzimmer_Motion,BM_Wohnzimmer
2022-02-07 11:39:52.365 HOMEMODE Home motionsInside_hr: BM_Flur_EG, BM_Flur_OG, BM_Flur_OG2_Motion, BM_Schlafzimmer_Motion und BM_Wohnzimmer
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Motion motion
2022-02-07 11:39:52.383 HUEDevice Schlafzimmerlicht onoff: 1
2022-02-07 11:39:52.383 HUEDevice Schlafzimmerlicht pct: 80
2022-02-07 11:39:52.383 HUEDevice Schlafzimmerlicht dim75%
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Light_Temp battery: 95
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Light_Temp temperature: 23
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Light_Temp batteryPercent: 95
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Light_Temp reachable: 1
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Light_Temp lastseen: 2022-02-07T10:39Z
2022-02-07 11:39:52.791 HUEDevice BM_Schlafzimmer_Light_Temp temperatur_real: 18
2022-02-07 11:39:52.988 HUEDevice Schalter_Schlafzimmer_2 batteryPercent: 67
2022-02-07 11:39:52.988 HUEDevice Schalter_Schlafzimmer_2 reachable: 1
2022-02-07 11:39:52.988 HUEDevice Schalter_Schlafzimmer_2 battery: 67
2022-02-07 11:39:53.001 HUEDevice Schalter_Schlafzimmer_2 battery: 67
2022-02-07 11:39:53.001 HUEDevice Schalter_Schlafzimmer_2 batteryPercent: 67
2022-02-07 11:39:53.001 HUEDevice Schalter_Schlafzimmer_2 reachable: 1
2022-02-07 11:39:57.070 DOIF di_Schlafzimmerlicht mode: enabled
2022-02-07 11:39:57.095 HUEDevice Schlafzimmerlicht onoff: 0
2022-02-07 11:39:57.095 HUEDevice Schlafzimmerlicht pct: 0
2022-02-07 11:39:57.095 HUEDevice Schlafzimmerlicht off
2022-02-07 11:40:00.426 HOMEMODE Home motionsSensors: BM_Flur_OG,BM_Flur_OG2_Motion,BM_Schlafzimmer_Motion,BM_Wohnzimmer
2022-02-07 11:40:00.426 HOMEMODE Home motionsSensors_hr: BM_Flur_OG, BM_Flur_OG2_Motion, BM_Schlafzimmer_Motion und BM_Wohnzimmer
2022-02-07 11:40:00.426 HOMEMODE Home motionsInside: BM_Flur_OG,BM_Flur_OG2_Motion,BM_Schlafzimmer_Motion,BM_Wohnzimmer
2022-02-07 11:40:00.426 HOMEMODE Home motionsInside_hr: BM_Flur_OG, BM_Flur_OG2_Motion, BM_Schlafzimmer_Motion und BM_Wohnzimmer
2022-02-07 11:40:01.330 DOIF di_Schlafzimmerlicht oldbrightness: 0
2022-02-07 11:40:01.339 DOIF di_Schlafzimmerlicht cmd_nr: 1
2022-02-07 11:40:01.339 DOIF di_Schlafzimmerlicht cmd_seqnr: 1
2022-02-07 11:40:01.339 DOIF di_Schlafzimmerlicht cmd: 1.1
2022-02-07 11:40:01.339 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 11:40:01.339 DOIF di_Schlafzimmerlicht cmd_1_1
2022-02-07 11:40:01.348 DOIF di_Schlafzimmerlicht cmd_nr: 1
2022-02-07 11:40:01.348 DOIF di_Schlafzimmerlicht cmd_seqnr: 2
2022-02-07 11:40:01.348 DOIF di_Schlafzimmerlicht cmd: 1.2
2022-02-07 11:40:01.348 DOIF di_Schlafzimmerlicht cmd_event: BM_Schlafzimmer_Motion
2022-02-07 11:40:01.348 DOIF di_Schlafzimmerlicht cmd_1
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Motion batteryPercent: 95
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Motion reachable: 1
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Motion lastseen: 2022-02-07T10:39Z
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Motion battery: 95
2022-02-07 11:39:52 HUEDevice BM_Schlafzimmer_Motion temperature: 23
2022-02-07 11:40:01.370 HUEDevice Schlafzimmerlicht lastseen: 2022-02-07T10:39Z
2022-02-07 11:40:01.467 HUEDevice Schlafzimmerlicht onoff: 1
2022-02-07 11:40:01.467 HUEDevice Schlafzimmerlicht pct: 80
2022-02-07 11:40:01.467 HUEDevice Schlafzimmerlicht dim75%
2022-02-07 11:40:05.765 DOIF di_Schlafzimmerlicht mode: enabled
2022-02-07 11:40:05.795 HUEDevice Schlafzimmerlicht onoff: 0
2022-02-07 11:40:05.795 HUEDevice Schlafzimmerlicht pct: 0
2022-02-07 11:40:05.795 HUEDevice Schlafzimmerlicht off[code]2022.02.07 11:39:52.955 5: deCONZ: websocket data: {
'r' => 'sensors',
'e' => 'changed',
'uniqueid' => '00:17:88:01:06:a7:03:91-02-fc00',
'id' => '21',
'attr' => {
'type' => 'ZHASwitch',
'modelid' => 'RWL021',
'name' => 'Schalter_Schlafzimmer_2',
'swversion' => '6.1.1.28573',
'uniqueid' => '00:17:88:01:06:a7:03:91-02-fc00',
'id' => '21',
'lastannounced' => '2022-02-07T07:29:22Z',
'lastseen' => '2022-02-07T10:39Z',
'manufacturername' => 'Philips'
},
't' => 'event'
}
2022.02.07 11:39:52.956 5: deCONZ: websocket data: {
'r' => 'sensors',
'uniqueid' => '00:17:88:01:06:a7:03:91-02-fc00',
'e' => 'changed',
'id' => '21',
'config' => {
'battery' => 67,
'group' => '20653',
'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'reachable' => $VAR1->{'config'}{'on'}
},
't' => 'event'
}
2022.02.07 11:39:52.989 5: deCONZ: websocket data: {
'e' => 'changed',
'uniqueid' => '00:17:88:01:06:a7:03:91-02-fc00',
'r' => 'sensors',
't' => 'event',
'attr' => {
'lastseen' => '2022-02-07T10:39Z',
'manufacturername' => 'Philips',
'id' => '21',
'lastannounced' => '2022-02-07T10:39:52Z',
'swversion' => '6.1.1.28573',
'uniqueid' => '00:17:88:01:06:a7:03:91-02-fc00',
'modelid' => 'RWL021',
'type' => 'ZHASwitch',
'name' => 'Schalter_Schlafzimmer_2'
},
'id' => '21'
}
2022.02.07 11:39:52.989 5: deCONZ: websocket data: {
't' => 'event',
'id' => '21',
'config' => {
'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'reachable' => $VAR1->{'config'}{'on'},
'group' => '20653',
'battery' => 67
},
'uniqueid' => '00:17:88:01:06:a7:03:91-02-fc00',
'e' => 'changed',
'r' => 'sensors'
}
2022.02.07 11:39:53.697 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:39:53.703 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:39:53.704 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:39:53.727 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:39:53.733 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:39:53.733 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:39:53.736 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:39:53.741 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:39:53.744 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:39:53.744 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:39:53.749 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:39:53.749 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:39:53.752 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:39:53.758 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:39:53.760 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:39:53.761 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:39:53.761 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:39:53.763 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:39:53.764 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:39:53.764 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:39:53.765 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:39:53.767 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:39:53.767 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:39:53.767 4: parse status message for Schalter_IKEA
2022.02.07 11:39:53.767 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:39:53.767 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:53.767 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:53.767 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:53.768 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:53.768 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:53.768 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:39:53.769 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:39:53.770 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:39:53.770 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:39:53.772 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:39:53.772 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:39:53.772 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:39:53.773 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:39:53.773 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:39:53.773 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:39:53.793 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:39:53.794 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:39:53.795 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:39:53.797 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:39:53.797 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:39:53.798 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:39:53.798 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:39:53.798 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:39:53.798 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:39:53.810 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:39:53.812 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:39:53.812 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:39:54.699 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:39:54.705 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:39:54.705 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:39:54.729 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:39:54.735 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:39:54.735 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:39:54.737 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:39:54.743 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:39:54.745 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:39:54.746 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:39:54.751 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:39:54.751 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:39:54.754 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:39:54.760 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:39:54.760 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:39:54.762 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:39:54.763 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:39:54.765 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:39:54.766 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:39:54.769 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:39:54.770 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:39:54.770 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:39:54.770 4: parse status message for Schalter_IKEA
2022.02.07 11:39:54.770 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:39:54.771 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:54.771 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:54.771 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:54.771 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:54.771 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:54.772 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:39:54.772 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:39:54.772 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:39:54.773 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:39:54.773 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:39:54.775 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:39:54.775 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:39:54.775 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:39:54.775 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:39:54.777 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:39:54.777 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:39:54.794 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:39:54.795 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:39:54.796 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:39:54.797 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:39:54.797 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:39:54.798 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:39:54.798 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:39:54.799 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:39:54.799 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:39:54.811 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:39:54.813 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:39:54.813 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:39:55.701 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:39:55.707 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:39:55.708 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:39:55.730 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:39:55.738 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:39:55.738 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:39:55.740 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:39:55.744 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:39:55.750 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:39:55.750 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:39:55.753 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:39:55.753 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:39:55.754 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:39:55.758 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:39:55.758 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:39:55.762 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:39:55.764 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:39:55.765 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:39:55.766 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:39:55.767 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:39:55.767 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:39:55.769 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:39:55.769 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:39:55.769 4: parse status message for Schalter_IKEA
2022.02.07 11:39:55.769 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:39:55.769 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:55.769 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:55.769 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:55.769 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:55.769 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:55.770 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:39:55.772 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:39:55.772 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:39:55.773 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:39:55.773 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:39:55.773 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:39:55.774 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:39:55.774 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:39:55.775 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:39:55.775 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:39:55.794 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:39:55.796 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:39:55.797 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:39:55.798 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:39:55.798 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:39:55.799 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:39:55.799 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:39:55.800 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:39:55.800 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:39:55.812 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:39:55.813 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:39:55.814 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:39:56.703 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:39:56.709 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:39:56.709 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:39:56.731 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:39:56.736 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:39:56.737 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:39:56.742 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:39:56.748 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:39:56.754 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:39:56.754 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:39:56.777 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:39:56.777 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:39:56.778 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:39:56.778 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:39:56.779 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:39:56.779 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:39:56.780 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:39:56.781 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:39:56.781 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:39:56.785 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:39:56.785 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:39:56.785 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:39:56.785 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:39:56.785 4: parse status message for Schalter_IKEA
2022.02.07 11:39:56.786 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:39:56.786 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:56.786 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:56.786 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:56.786 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:56.786 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:27:46, current reading timestamp is 2022-02-07 11:27:46
2022.02.07 11:39:56.786 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:39:56.786 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:39:56.787 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:39:56.787 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:39:56.787 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:39:56.787 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:39:56.788 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:39:56.788 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:39:56.788 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:39:56.788 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:39:56.804 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:39:56.807 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:39:56.808 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:39:56.811 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:39:56.811 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:39:56.813 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:39:56.814 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:39:56.814 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:39:56.815 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:39:56.815 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:39:56.821 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:39:56.821 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:39:57.035 5: deCONZ: websocket data: {
'e' => 'changed',
'uniqueid' => '14:b4:57:ff:fe:d4:b9:49-01-1000',
'r' => 'sensors',
't' => 'event',
'attr' => {
'swversion' => '2.2.008',
'uniqueid' => '14:b4:57:ff:fe:d4:b9:49-01-1000',
'modelid' => 'TRADFRI on/off switch',
'type' => 'ZHASwitch',
'name' => 'Schalter_Schlafzimmer_3',
'lastseen' => '2022-02-07T10:39Z',
'manufacturername' => 'IKEA of Sweden',
'id' => '22',
'lastannounced' => '2022-01-22T16:53:51Z'
},
'id' => '22'
}
2022.02.07 11:39:57.035 4: parse status message for Schalter_IKEA
2022.02.07 11:39:57.035 4: Schalter_IKEA: bridge has events api: 0
2022.02.07 11:39:57.036 5: deCONZ: websocket data: {
'uniqueid' => '14:b4:57:ff:fe:d4:b9:49-01-1000',
'state' => {
'buttonevent' => 2002,
'lastupdated' => '2022-02-07T10:39:57.033'
},
'e' => 'changed',
'r' => 'sensors',
't' => 'event',
'id' => '22'
}
2022.02.07 11:39:57.036 4: parse status message for Schalter_IKEA
2022.02.07 11:39:57.036 4: Schalter_IKEA: bridge has events api: 0
2022.02.07 11:39:57.036 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:39:57.045 4: using HttpUtils_NonblockingGet: PUT lights/15/state
2022.02.07 11:39:57.082 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/lights/15/state
2022.02.07 11:39:57.083 5: HUEBridge_dispatch: lights/15/state
2022.02.07 11:39:57.084 5: deCONZ: websocket data: {
'r' => 'lights',
'e' => 'changed',
'state' => {
'reachable' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
'alert' => undef,
'ct' => 270,
'bri' => 205,
'colormode' => 'ct'
},
'uniqueid' => '00:17:88:01:06:24:d3:de-0b',
'id' => '15',
't' => 'event'
}
2022.02.07 11:39:57.096 5: deCONZ: websocket data: {
'id' => '65520',
't' => 'event',
'r' => 'groups',
'state' => {
'all_on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
'any_on' => $VAR1->{'state'}{'all_on'}
},
'e' => 'changed'
}
2022.02.07 11:39:57.096 5: deCONZ: websocket: assuming group 0 for id 65520 in event
2022.02.07 11:39:57.421 5: deCONZ: websocket data: {
'attr' => {
'lastannounced' => '2022-01-13T01:46:53Z',
'id' => '13',
'ctmax' => 370,
'colorcapabilities' => 16,
'lastseen' => '2022-02-07T10:39Z',
'ctmin' => 200,
'manufacturername' => 'Neuhaus Lighting Group',
'modelid' => 'NLG-CCT light',
'type' => 'Color temperature light',
'name' => "K\x{c3}\x{bc}chenlicht",
'uniqueid' => '00:15:8d:00:02:40:f3:9e-01',
'swversion' => '1001-0007'
},
'id' => '13',
't' => 'event',
'r' => 'lights',
'uniqueid' => '00:15:8d:00:02:40:f3:9e-01',
'e' => 'changed'
}
2022.02.07 11:39:57.704 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:39:57.711 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:39:57.712 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:39:57.733 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:39:57.739 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:39:57.740 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:39:57.744 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:39:57.750 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:39:57.753 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:39:57.753 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:39:57.758 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:39:57.758 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:39:57.778 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:39:57.780 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:39:57.782 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:39:57.783 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:39:57.784 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:39:57.786 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:39:57.792 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:39:57.794 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:39:57.794 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:39:57.799 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:39:57.799 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:39:57.801 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:39:57.801 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:39:57.802 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:39:57.802 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:39:57.803 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:39:57.803 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:39:57.804 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:39:57.804 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:39:57.804 4: parse status message for Schalter_IKEA
2022.02.07 11:39:57.804 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:39:57.804 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:57.818 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:39:57.819 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:39:57.819 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:39:57.820 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:39:57.822 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:39:57.822 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:39:57.826 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:39:57.826 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:39:57.826 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:39:57.827 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:39:57.827 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:39:57.827 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:39:57.828 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:39:57.828 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:39:58.706 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:39:58.712 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:39:58.713 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:39:58.734 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:39:58.741 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:39:58.741 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:39:58.745 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:39:58.751 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:39:58.757 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:39:58.757 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:39:58.769 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:39:58.769 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:39:58.778 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:39:58.781 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:39:58.781 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:39:58.781 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:39:58.783 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:39:58.784 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:39:58.785 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:39:58.786 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:39:58.786 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:39:58.788 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:39:58.789 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:39:58.789 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:39:58.789 4: parse status message for Schalter_IKEA
2022.02.07 11:39:58.789 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:39:58.790 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:58.790 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:58.790 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:58.790 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:58.790 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:58.791 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:39:58.791 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:39:58.791 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:39:58.791 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:39:58.792 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:39:58.793 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:39:58.793 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:39:58.794 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:39:58.794 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:39:58.818 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:39:58.820 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:39:58.820 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:39:58.821 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:39:58.823 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:39:58.823 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:39:58.824 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:39:58.824 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:39:58.824 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:39:58.824 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:39:58.825 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:39:58.825 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:39:59.708 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:39:59.713 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:39:59.713 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:39:59.736 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:39:59.742 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:39:59.742 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:39:59.747 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:39:59.753 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:39:59.757 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:39:59.757 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:39:59.761 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:39:59.761 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:39:59.780 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:39:59.782 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:39:59.785 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:39:59.786 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:39:59.789 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:39:59.789 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:39:59.790 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:39:59.793 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:39:59.794 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:39:59.794 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:39:59.798 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:39:59.800 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:39:59.801 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:39:59.801 4: parse status message for Schalter_IKEA
2022.02.07 11:39:59.801 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:39:59.801 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:59.801 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:59.801 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:59.801 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:59.801 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:39:59.802 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:39:59.802 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:39:59.803 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:39:59.803 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:39:59.804 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:39:59.804 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:39:59.805 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:39:59.805 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:39:59.819 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:39:59.820 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:39:59.821 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:39:59.822 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:39:59.823 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:39:59.823 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:39:59.824 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:39:59.825 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:39:59.825 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:39:59.825 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:39:59.826 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:39:59.826 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:40:00.710 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:40:00.717 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:40:00.717 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:40:00.738 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:40:00.745 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:40:00.745 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:40:00.749 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:40:00.755 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:40:00.759 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:40:00.759 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:40:00.763 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:40:00.763 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:40:00.780 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:40:00.782 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:40:00.782 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:40:00.783 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:40:00.785 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:40:00.785 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:40:00.785 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:40:00.786 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:40:00.788 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:40:00.788 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:40:00.788 4: parse status message for Schalter_IKEA
2022.02.07 11:40:00.788 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:40:00.788 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:00.788 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:00.788 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:00.788 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:00.788 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:00.789 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:40:00.789 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:40:00.791 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:40:00.793 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:40:00.793 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:40:00.793 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:40:00.795 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:40:00.795 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:40:00.798 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:40:00.800 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:40:00.800 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:40:00.821 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:40:00.830 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:40:00.832 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:40:00.832 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:40:00.843 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:40:00.843 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:40:00.844 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:40:00.844 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:40:00.845 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:40:00.845 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:40:00.846 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:40:00.846 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:40:01.278 4: using HttpUtils_NonblockingGet: GET
2022.02.07 11:40:01.300 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201
2022.02.07 11:40:01.300 5: HUEBridge_dispatch
2022.02.07 11:40:01.303 4: deCONZ: parse status message
2022.02.07 11:40:01.305 4: parse status message for Schalter_IKEA
2022.02.07 11:40:01.305 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:40:01.306 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.306 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.306 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.306 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.306 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.310 4: parse status message for BM_Schlafzimmer_Motion
2022.02.07 11:40:01.310 5: BM_Schlafzimmer_Motion: using offsetUTC 3600 from bridge
2022.02.07 11:40:01.310 4: BM_Schlafzimmer_Motion: ignoring reading state with timestamp 2022-02-07 11:39:52, current reading timestamp is 2022-02-07 11:39:52
2022.02.07 11:40:01.339 4: using HttpUtils_NonblockingGet: PUT lights/15/state
2022.02.07 11:40:01.455 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/lights/15/state
2022.02.07 11:40:01.455 5: HUEBridge_dispatch: lights/15/state
2022.02.07 11:40:01.456 5: deCONZ: websocket data: {
't' => 'event',
'id' => '15',
'state' => {
'colormode' => 'ct',
'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'reachable' => $VAR1->{'state'}{'on'},
'alert' => undef,
'bri' => 205,
'ct' => 270
},
'e' => 'changed',
'uniqueid' => '00:17:88:01:06:24:d3:de-0b',
'r' => 'lights'
}
2022.02.07 11:40:01.468 5: deCONZ: websocket data: {
'e' => 'changed',
'state' => {
'any_on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'all_on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' )
},
'r' => 'groups',
't' => 'event',
'id' => '65520'
}
2022.02.07 11:40:01.468 5: deCONZ: websocket: assuming group 0 for id 65520 in event
2022.02.07 11:40:01.711 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:40:01.717 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:40:01.717 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:40:01.740 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:40:01.749 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:40:01.749 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:40:01.752 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:40:01.756 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:40:01.758 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:40:01.758 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:40:01.761 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:40:01.761 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:40:01.781 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:40:01.783 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:40:01.783 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:40:01.785 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:40:01.786 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:40:01.788 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:40:01.789 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:40:01.789 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:40:01.790 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:40:01.790 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:40:01.790 4: parse status message for Schalter_IKEA
2022.02.07 11:40:01.790 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:40:01.791 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.791 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.791 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.791 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.791 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:01.792 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:40:01.793 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:40:01.793 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:40:01.795 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:40:01.797 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:40:01.798 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:40:01.799 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:40:01.800 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:40:01.800 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:40:01.801 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:40:01.801 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:40:01.822 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:40:01.824 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:40:01.824 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:40:01.831 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:40:01.832 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:40:01.833 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:40:01.833 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:40:01.834 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:40:01.835 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:40:01.835 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:40:01.836 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:40:01.836 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:40:02.714 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:40:02.721 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:40:02.722 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:40:02.742 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:40:02.749 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/12
2022.02.07 11:40:02.749 5: HUEBridge_dispatch: sensors/12
2022.02.07 11:40:02.753 4: using HttpUtils_NonblockingGet: GET sensors/11
2022.02.07 11:40:02.758 4: using HttpUtils_NonblockingGet: GET sensors/13
2022.02.07 11:40:02.763 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/11
2022.02.07 11:40:02.763 5: HUEBridge_dispatch: sensors/11
2022.02.07 11:40:02.765 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/13
2022.02.07 11:40:02.766 5: HUEBridge_dispatch: sensors/13
2022.02.07 11:40:02.782 4: using HttpUtils_NonblockingGet: GET sensors/20
2022.02.07 11:40:02.785 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/20
2022.02.07 11:40:02.785 5: HUEBridge_dispatch: sensors/20
2022.02.07 11:40:02.786 4: using HttpUtils_NonblockingGet: GET sensors/21
2022.02.07 11:40:02.788 4: using HttpUtils_NonblockingGet: GET sensors/22
2022.02.07 11:40:02.789 4: using HttpUtils_NonblockingGet: GET sensors/15
2022.02.07 11:40:02.792 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/21
2022.02.07 11:40:02.792 5: HUEBridge_dispatch: sensors/21
2022.02.07 11:40:02.793 4: using HttpUtils_NonblockingGet: GET sensors/18
2022.02.07 11:40:02.795 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/22
2022.02.07 11:40:02.795 5: HUEBridge_dispatch: sensors/22
2022.02.07 11:40:02.795 4: parse status message for Schalter_IKEA
2022.02.07 11:40:02.795 5: Schalter_IKEA: using offsetUTC 3600 from bridge
2022.02.07 11:40:02.796 4: Schalter_IKEA: ignoring reading lastseen with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:02.796 4: Schalter_IKEA: ignoring reading reachable with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:02.796 4: Schalter_IKEA: ignoring reading batteryPercent with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:02.796 4: Schalter_IKEA: ignoring reading battery with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:02.796 4: Schalter_IKEA: ignoring reading state with timestamp 2022-02-07 11:39:57, current reading timestamp is 2022-02-07 11:39:57
2022.02.07 11:40:02.797 4: using HttpUtils_NonblockingGet: GET sensors/16
2022.02.07 11:40:02.799 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/15
2022.02.07 11:40:02.799 5: HUEBridge_dispatch: sensors/15
2022.02.07 11:40:02.800 4: using HttpUtils_NonblockingGet: GET sensors/26
2022.02.07 11:40:02.801 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/18
2022.02.07 11:40:02.801 5: HUEBridge_dispatch: sensors/18
2022.02.07 11:40:02.803 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/16
2022.02.07 11:40:02.803 5: HUEBridge_dispatch: sensors/16
2022.02.07 11:40:02.805 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/26
2022.02.07 11:40:02.805 5: HUEBridge_dispatch: sensors/26
2022.02.07 11:40:02.822 4: using HttpUtils_NonblockingGet: GET sensors/25
2022.02.07 11:40:02.824 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/25
2022.02.07 11:40:02.824 5: HUEBridge_dispatch: sensors/25
2022.02.07 11:40:02.831 4: using HttpUtils_NonblockingGet: GET sensors/2
2022.02.07 11:40:02.833 4: using HttpUtils_NonblockingGet: GET sensors/4
2022.02.07 11:40:02.834 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/2
2022.02.07 11:40:02.834 5: HUEBridge_dispatch: sensors/2
2022.02.07 11:40:02.835 4: using HttpUtils_NonblockingGet: GET sensors/7
2022.02.07 11:40:02.836 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/4
2022.02.07 11:40:02.836 5: HUEBridge_dispatch: sensors/4
2022.02.07 11:40:02.837 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/7
2022.02.07 11:40:02.838 5: HUEBridge_dispatch: sensors/7
2022.02.07 11:40:03.715 4: using HttpUtils_NonblockingGet: GET sensors/10
2022.02.07 11:40:03.721 4: deCONZ: dispatch: http://192.168.178.50/api/71D1867201/sensors/10
2022.02.07 11:40:03.722 5: HUEBridge_dispatch: sensors/10
2022.02.07 11:40:03.744 4: using HttpUtils_NonblockingGet: GET sensors/12
2022.02.07 11:40:03.750 4: deCONZ: dispatch: http
@dk3572,
da sieht man nur jeweils ein Event für die Bewegung bevor es dann immer irgendwann wieder auf 0 geht.
Dürfte also eigentlich nicht am HUE Modul liegen.
Falls es wirklich irgendwas mit dem Update zu tun hat, würde ich tippen es entstehen mehr ANDERE Events als früher und dein Notify / Doif ist evtl.nicht spezifisch genug und triggert durch etwas anderes erneut.
@Andre,
danke für die Info, werde mir das mal mit Verbose 4 bei mir anschauen.
Grüße,
Tobias
Ok, habs mal kurz getestet.
Log:
2022.02.07 11:54:22.006 4: parse status message for TradfriShortcutButton01
2022.02.07 11:54:22.006 4: TradfriShortcutButton01: ignoring reading state with timestamp 2022-02-07 11:53:23, current reading timestamp is 2022-02-07 11:53:23
2022.02.07 11:54:26.810 4: parse status message for TradfriShortcutButton01
2022.02.07 11:54:26.810 4: TradfriShortcutButton01: bridge has events api: 0
2022.02.07 11:54:26.848 4: parse status message for TradfriShortcutButton01
2022.02.07 11:54:26.848 4: TradfriShortcutButton01: bridge has events api: 0
Events:
2022-02-07 11:54:26 HUEDevice TradfriShortcutButton01 1002
2022-02-07 11:54:26 HUEDevice TradfriShortcutButton01 1002
Sind das dann wohl tatsächlich 2 Events die da von Deconz an FHEM weitergereicht werden (oder sogar 3, aber der erste ist ein altes Event welches FHEM schon kannte)?
wenn ein ignoring reading ... auftaucht wird kein event erzeugt weil der timestamp schon da war (d.h. der timestamp ist identisch wie hier oder älter) . das betrifft die daten die durchs regelmässige pollen rein kommen. das pollen sollte nach dem das erste echte push event gekommen ist automatisch für das device deaktiviert werden und nur noch die bridge sollte alle 10 minuten pollen.
für die beiden events die noch übrig bleiben schalte mal verbose auf 5. in der bridge und dem device. dann siehst du was genau reingekommen ist.
Ok, Deconz sendet wohl wirklich doppelt.
Die Zeitstempel sind verschieden.
Dann versuche ich mal herauszufinden warum... :-\
2022-02-07 12:22:48 HUEDevice TradfriShortcutButton01 1002
2022-02-07 12:22:48 HUEDevice TradfriShortcutButton01 1002
2022.02.07 12:22:48.170 5: conbee2: websocket data: {
'r' => 'sensors',
't' => 'event',
'id' => '30',
'state' => {
'buttonevent' => 1002,
'lastupdated' => '2022-02-07T11:22:48.166'
},
'uniqueid' => 'b4:e3:f9:ff:fe:62:0f:0d-01-1000',
'e' => 'changed'
}
2022.02.07 12:22:48.170 4: parse status message for TradfriShortcutButton01
2022.02.07 12:22:48.170 4: TradfriShortcutButton01: bridge has events api: 0
2022.02.07 12:22:48.170 5: TradfriShortcutButton01: using offsetUTC 3600 from bridge
2022.02.07 12:22:48.194 5: conbee2: websocket data: {
'r' => 'sensors',
'state' => {
'buttonevent' => 1002,
'lastupdated' => '2022-02-07T11:22:48.191'
},
'id' => '30',
't' => 'event',
'uniqueid' => 'b4:e3:f9:ff:fe:62:0f:0d-01-1000',
'e' => 'changed'
}
2022.02.07 12:22:48.194 4: parse status message for TradfriShortcutButton01
2022.02.07 12:22:48.194 4: TradfriShortcutButton01: bridge has events api: 0
2022.02.07 12:22:48.194 5: TradfriShortcutButton01: using offsetUTC 3600 from bridge
ja. wenn da zwei mal websocket data steht kommen zwei events von der bridge. hier auch mit zwei leicht unterschiedlichen timestamps.
unabhängig davon: mich wunder auch noch das bridge has events api: 0. für deconz sollte das eigentlich immer auf 1 stehen. kannst du mal bitte ein list von deinem bridge device zeigen.
Zitat von: justme1968 am 07 Februar 2022, 12:40:04
ja. wenn da zwei mal websocket data steht kommen zwei events von der bridge. hier auch mit zwei leicht unterschiedlichen timestamps.
unabhängig davon: mich wunder auch noch das bridge has events api: 0. für deconz sollte das eigentlich immer auf 1 stehen. kannst du mal bitte ein list von deinem bridge device zeigen.
kommen wir hierdurch meinem Problem auch auf die Schliche od. soll ich noch irgendwelche Infos liefern?
dein problem habe ich bisher in keinem deiner logs sehen können. weder doppelte daten von der bridge noch doppelte events. deshalb immer noch die vermutung das bei dir irgendetwas auf die falschen events reagiert.
Zitat von: justme1968 am 07 Februar 2022, 12:51:31
dein problem habe ich bisher in keinem deiner logs sehen können. weder doppelte daten von der bridge noch doppelte events. deshalb immer noch die vermutung das bei dir irgendetwas auf die falschen events reagiert.
Das wiederholte Einschalten tritt auch auf wenn das Licht nicht per Schalter sondern per Alexa ausschalte.
Also kann es am Schalter schon mal nicht liegen denke ich.
Ein List von meinem DOIF habe ich dir gezeigt. Was sollte an dem nicht passen?
Und wie bereits geschrieben, es tritt alles erst seit den letzten Updates der beiden Hue Module auf.
zu doif kann ich dir nichts sagen. das verwende ich nicht.
so lange es keine falschen (doppelte) events im event monitor gibt und du mir nicht die dazu gehörenden log einträge der bridge zeigen kannst liegt es nicht am modul.
@dk3572
Du reagierst im DOIF zumindest mal auf den Zustand und nicht auf das Event.
Bin da in DOIF nicht tief genug drin. Kann es sein, dass jedes Event von dem Device das DOIF triggert und solange das Reading den richtigen Wert hat wird ausgeführt?
Ich würde auf einen eventbasierten Trigger (siehe DOIF Doku) umstellen und ansonsten einen Mitschnitt vom Eventmonitor (vom gesamten Zeitraum des doppelten Auslösens) mal im DOIF Unterforum einstellen.
IMO kein Thema für justme1968.
Dass dein DOIF Trigger nicht genau genug definiert ist kann durch das Modulupdate sichtbar geworden sein, aber ich glaube die Ursache liegt nicht im HUE Modul.
@Andre, hier das List von der Bridge:
Internals:
DEF 172.17.2.43
FD 37
FUUID 5e18f15d-f33f-01b6-150d-24922bf5c8bda904
FVERSION 30_HUEBridge.pm:0.256160/2022-02-02
INTERVAL 60
NAME conbee2
NOTIFYDEV global
NR 160
NTFY_ORDER 50-conbee2
PORT 35876
STATE connected
TYPE HUEBridge
apiversion 1.16.0
bridgeid 00212EFFFF051AB5
buf
host 172.17.2.43
is_deCONZ 1
mac 06:1b:78:89:ad:ba
manufacturer Royal Philips Electronics
modelName Philips hue bridge 2015
modelid deCONZ
name Phoscon-GW
swversion 2.14.1
updatestate 0
websocket 1
websocketport 443
zigbeechannel 15
READINGS:
2022-02-01 10:59:03 groups 5
2022-02-03 15:56:02 lastError resource, /lights/2/state, is not modifiable. Device is not reachable.
2022-02-01 10:59:03 lights 12
2022-02-01 10:59:03 rules 0
2022-02-01 10:59:03 scenes 0
2022-02-01 10:59:03 schedules 0
2022-02-01 10:59:03 sensors 31
2022-02-07 13:50:22 state connected
helper:
apiversion 69632
count 1
last_config_timestamp 1644238222
offsetUTC 3600
updatestate 0
groups:
1:
etag fcd93240398bdc622dcbaf96aabbd191
id 1
name Test
type LightGroup
action:
alert none
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
lights:
scenes:
state:
4:
etag 0861ee0d63bc4cfc4fecd867260c7595
id 4
name TRADFRI on/off switch
type LightGroup
uniqueid cc:cc:cc:ff:fe:2c:3f:db
action:
alert none
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
3
lights:
scenes:
state:
5:
etag 0861ee0d63bc4cfc4fecd867260c7595
id 5
name TRADFRI remote control
type LightGroup
uniqueid bc:33:ac:ff:fe:1b:50:32
action:
alert none
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
29
lights:
scenes:
state:
6:
etag bb1eda3791b0342a75d84c532fe0a2c0
id 6
name TRADFRI SHORTCUT Button
type LightGroup
uniqueid b4:e3:f9:ff:fe:62:0f:0d
action:
alert none
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
30
lights:
scenes:
state:
7:
etag 0861ee0d63bc4cfc4fecd867260c7595
id 7
name TRADFRI SHORTCUT Button
type LightGroup
uniqueid b4:e3:f9:ff:fe:67:b3:1f
action:
alert none
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
31
lights:
scenes:
state:
ignored:
lights:
1:
colorcapabilities 31
ctmax 500
ctmin 153
etag 9adcf3d9355830eb17e4406c92e572f4
lastannounced 2021-11-25T05:07:53Z
lastseen 2022-02-07T12:50Z
manufacturername Philips
modelid LCT007
name Laterne
swversion 5.127.1.26420
type Extended color light
uniqueid 00:17:88:01:10:37:93:51-0b
state:
alert none
bri 128
colormode ct
ct 429
effect none
hue 13879
sat 189
xy:
0.4923
0.4151
11:
etag 09499b6f649bd8c5a6bd05f6f9a15580
lastannounced
lastseen 2022-02-07T12:49Z
manufacturername dresden elektronik
modelid ConBee II
name Configuration tool 11
swversion 0x26670700
type Configuration tool
uniqueid 00:21:2e:ff:ff:05:1a:b5-01
state:
12:
etag 4f8f6db4ca71f4e693d72122ea4fe6f8
lastannounced 2021-11-25T14:44:13Z
lastseen 2022-02-07T12:49Z
manufacturername Philips
modelid LWV001
name Filament 2
swversion 1.55.8_r28815
type Dimmable light
uniqueid 00:17:88:01:09:9b:f2:dd-0b
state:
alert none
bri 3
13:
colorcapabilities 0
ctmax 65279
ctmin 0
etag 90c835948b0dd06629e9a222974eba43
lastannounced 2021-10-13T13:55:25Z
lastseen 2021-10-13T13:57Z
manufacturername Philips
modelid LTA005
name Color temperature light 13
swversion 1.78.1
type Color temperature light
uniqueid 00:17:88:01:0b:7e:83:09-0b
state:
alert none
bri 32
colormode ct
ct 454
2:
colorcapabilities 31
ctmax 500
ctmin 153
etag 25fb64011961e8e67b1c706ebed5ec30
lastannounced 2021-11-28T13:20:03Z
lastseen 2022-01-23T09:38Z
manufacturername Philips
modelid LCT012
name E14 Birne
swversion 1.46.13_r26312
type Extended color light
uniqueid 00:17:88:01:03:61:10:80-0b
state:
alert none
bri 153
colormode ct
ct 366
effect none
hue 8418
sat 140
xy:
0.4573
0.41
3:
colorcapabilities 31
ctmax 500
ctmin 153
etag 7a275561de2650ceef652fc703944fa7
lastannounced
lastseen 2022-02-07T12:49Z
manufacturername Philips
modelid LST002
name Bodenleiste Küche
swversion 5.127.1.26420
type Extended color light
uniqueid 00:17:88:01:02:16:02:72-0b
state:
alert none
bri 37
colormode ct
ct 400
effect none
hue 8115
sat 168
xy:
0.4768
0.4136
4:
colorcapabilities 31
ctmax 500
ctmin 153
etag 8e178cb5678d733ded2ba8f5cc2e0179
lastannounced
lastseen 2022-02-07T12:49Z
manufacturername Philips
modelid LST002
name Küchenschrank
swversion 1.46.13_r26312
type Extended color light
uniqueid 00:17:88:01:02:9c:3e:89-0b
state:
alert none
bri 153
colormode ct
ct 377
effect none
hue 8331
sat 149
xy:
0.4633
0.4114
5:
colorcapabilities 31
ctmax 500
ctmin 153
etag 456c583aad45831f0db4148c6f2baf75
lastannounced
lastseen 2022-02-07T12:49Z
manufacturername Philips
modelid LST002
name TV Backlight
swversion 5.127.1.26420
type Extended color light
uniqueid 00:17:88:01:01:1c:ac:ad-0b
state:
alert none
bri 102
colormode ct
ct 384
effect none
hue 8259
sat 156
xy:
0.4681
0.4123
6:
etag b6dd7c0efb859dd12f2e3fee2767c408
lastannounced 2021-10-13T21:41:54Z
lastseen 2022-02-07T12:50Z
manufacturername Philips
modelid LWB006
name HUE White Ersatzbirne 1
swversion 5.38.2.19136
type Dimmable light
uniqueid 00:17:88:01:10:43:6b:65-0b
state:
alert none
bri 253
7:
etag 3194a5b12b4f4d4e4ad224d48ad308b6
lastannounced 2022-01-16T12:46:19Z
lastseen 2022-02-07T12:50Z
manufacturername Philips
modelid LWB006
name HUE White Ersatzbirne 2
swversion 5.38.1.15095
type Dimmable light
uniqueid 00:17:88:01:10:4f:58:f9-0b
state:
alert none
bri 128
8:
etag 76ca511230881286b09ad242242bd922
lastannounced 2022-02-01T11:16:48Z
lastseen 2022-02-07T12:49Z
manufacturername Philips
modelid LWB006
name Lampe Schrank Lenn
swversion 5.127.1.26420
type Dimmable light
uniqueid 00:17:88:01:10:5c:65:10-0b
state:
alert none
bri 254
9:
etag 6cedeab4a0285701dfc4add051eae988
lastannounced 2021-11-24T18:43:23Z
lastseen 2022-02-07T12:49Z
manufacturername Philips
modelid LWV001
name Filament 1
swversion 1.55.8_r28815
type Dimmable light
uniqueid 00:17:88:01:08:13:19:73-0b
state:
alert none
bri 3
scenes:
Attributes:
alias Conbee II
group Zigbee
httpUtils 1
key F0408BBFE6
room hidden
danke. ich habe den fehler der die ursache für das fehlende abschalten des pollings war gefunden. das sollte ab morgen auch bei deconz gehen.
das hat aber nichts mit dem doppelten auslösen zu tun. da scheinen wirklich mehrfache events zu kommen. keine ahnung warum das so ist. vielleicht mal dort nachfragen.
Ich hab gerade nochmal ein Update von der deconz VM mittel apt-get dist-upgrade durchgeführt.
(Das list hat schon die neuste Version drin.)
Mir ist vorhin nämlich aufgefallen, dass die Shortcut Buttons in Phoscon unter Schalter auch nicht mehr aufgetaucht sind.
Hatte plötzlich eine 1,5 Jahre alte Deconz Version drauf.
Keine Ahnung ob bei deren Quellen da neulich was schief lief.
Hatte da ebenfalls per apt-get dist-upgrade das System geupdated.
Ist damit auf alle Fälle gefixt. :)
Danke dir für die Hilfe, hab immerhin Einiges gelernt über den Datenaustausch Deconz -> Fhem. ;)
Zitat von: Thyraz am 07 Februar 2022, 13:20:59
@dk3572
Du reagierst im DOIF zumindest mal auf den Zustand und nicht auf das Event.
Bin da in DOIF nicht tief genug drin. Kann es sein, dass jedes Event von dem Device das DOIF triggert und solange das Reading den richtigen Wert hat wird ausgeführt?
Ich würde auf einen eventbasierten Trigger (siehe DOIF Doku) umstellen und ansonsten einen Mitschnitt vom Eventmonitor (vom gesamten Zeitraum des doppelten Auslösens) mal im DOIF Unterforum einstellen.
IMO kein Thema für justme1968.
Dass dein DOIF Trigger nicht genau genug definiert ist kann durch das Modulupdate sichtbar geworden sein, aber ich glaube die Ursache liegt nicht im HUE Modul.
Es war wohl nach den Updates genau dies das Problem.
Habe die DOIF geändert in [BM_Schlafzimmer:"^motion"] und nun scheint es zu funktionieren.
Vielen Dank für eure Hilfe und den richtigen Tipp ;)
VG Dieter
@Andre ich ab nochmal eine Frage die mir bei dem Thema kam:
Ich hab hier im Forum schonmal Hilfe gesucht, weil sich ein DOIF von mir nach einem FHEM Crash / Restart selbstständig gemacht hatte.
Das DOIF hat auch auf Events eines Ikea Shortcut Buttons gelauscht.
Da ich DOIF im Verdacht hatte, habe ich das damals dort angefragt aber nie lösen können.
Nachdem ich nun die Logik gesehen habe, wie das HUE Modul anhand der Timestamps entscheidet ob der Status des Conbee neu ist oder nicht, kam mir aber eine neue Idee:
- Ich drücke den Button kurz. Fhem erkennt das, löst das Event aus und merkt sich den Timestamp als letztes abgearbeitetes Event aus Deconz
- Irgendwas löst irgendwann das speichern des Statefiles aus
- Ich drücke den Button lang. Fhem löst das Event aus und merkt sich nun diesen Timestamp als letzten.
- Der Fhem Rechner crashed bevor das Statefile geschrieben wurde.
- Nach dem Reboot wenn Fhem und Deconz gestartet sind, kommt (per Poll?) der letzte Longpress nochmal rein.
- Normal würde der alte Longpress (in meinem Fall war der einen halben Tag her) wegen bekanntem Timestamp ignoriert werden. Der Timestamp wurde aber nicht ins Dateisystem (statefile) geschrieben.
- Der alte Longpress löst daher erneut ein Event aus und lauschende Notifies / DOIFs lösen nochmals aus.
Wäre das Verhalten so möglich und ggf. eine Erklärung für das von mir beobachtete Verhalten?
Je nachdem was man über den Event auslöst kann das etwas spooky sein. ;)
Sei es der Staubsaugerroboter startet oder das Radio geht plötzlich an ...
Oder hast du da eine Logik drin welche den Timestamp gegen die aktuelle Uhrzeit prüft und bei zu großen Abweichungen keine Events wirft?
das ist im prinzip möglich. betrifft aber so auch alle anderen dinge die sich auf den vergleich mit einem vorherigen zustand (z.b. über OldReadingsVal) verlassen. wenn der alte zustand nicht zuverlässig ist gibt es ein problem.
dazu gibt es mehrere mögliche lösungen, die alle ebenfalls irgendwelche nachteile haben:
- nach einem neustart wird grundsätzlich die erste zustandsänderung ignoriert -> es gehen möglicherweise
zustände verloren
- nach einem neustart werden grundsätzlich die ersten daten die durch pollen rein kommen ignoriert
das geht nur auf systeme bei denen die bridge auch events sendet.
- für sensoren grundsätzlich nicht mehr pollen wenn es events gibt. geht nur wenn es (zuverlässige) events
gibt und das weiss ich eigentlich erst nach dem das erste event gekommen ist. wie merke ich mir das wenn
ich mich nicht darauf verlassen kann das die readings nach dem neustart stimmen?
- man baut irgendwelche höchstalter für die daten ein. problem: wie alt ist alt genug zum ignorieren?
die frage ist halt: was ist wichtiger, das der interne zustand nach einem neustart so schnell wie möglich stimmt und eventuell events doppelt kommen oder das niemals falsch ausgelöst wird und eventuell events verloren gehen. eventuell ist je nach sensor typ das eine oder das andere besser.
wie wäre ein attribut mit dem man 1., 2. oder 3. von oben und zusätzlich 4. konfigurieren kann?
ganz unabhängig davon eine geschichte: vor ein paar wochen hat der rollladen hier im schlafzimmer angefangen zu spinnen und ist mitten in der nacht mehrfach auf oder zu gefahren. nach langem suchen habe ich dann eine tablet ui installation an der wand als verantwortlichen gefunden. irgend ein netzwerk problem hat dazu geführt das das ding der meinung war jemand hat es von hand bedient.
Ok, das mit dem Rollladen ist auch gruselig. ;D
Ja, es hängt wirklich vom Gerätetyp ab, welches Verhalten man will.
Bei einem Temperatursensor will man mit Sicherheit den letzten Wert erhalten.
Bei einem Tastendruck dürfte es hingegen fast immer unerwünscht sein.
Das geht ja aber noch weiter: Bei einem Taster interessiert der letzte Batteriewert ja hingegen schon wieder.
Man müsste also tatsächlich nach Art des Sensorwertes und des Timestamp-Alters Events ignorieren.
Zumindest bei Deconz heißen die Events ja entsprechend, dass man das erkennen könnte, z.B. buttonevent
Aber keine Ahnung wie das bei der Hue-Bridge ist.
Und wahrscheinlich hast du das Ganze ja eher generisch aufgebaut, damit du solche Sachen nicht nachpflegen musst.
Man könnte halt höchstens eine Abfrage reinmachen, wenn der Event einer von bestimmten Typen ist und Älter als ein paar Minuten, dann ignorieren.
Alles andere läuft normal durch wie bisher, dann wäre es nur eine an an einer Stelle zu pflegende Ausnahme.
An sich betrifft das ja auch nur Dinge wie Taster und Bewegungsmelder.
Die Sache mit den vorgeschlagenen Attributen wäre eine Alternative um es den User steuern zu lassen, das wäre für mich auch ok.
Allerdings muss der User sich erstmal des Problems bewusst sein, damit er das dann selbst anpasst.
Ich habe jedenfalls recht lange gebraucht um zu kapieren was da passiert ist. ;)
Und da es ein extremer Edge-Case ist, ist es die Frage ob das den Aufwand wert ist.
Daher evtl. eher die Frage: Ist das mit einfachen Ausnahmen für Tastendruck und Bewegung im Modul realisierbar, so dass es automatisch klappt?
Wenn nein -> Problem ignorieren, da es wahrscheinlich eh fast nie auftritt.
P.S. Offtopic, aber da du ein alter FHEM Hase bist: Kann an das State-File manuell speichern, ohne die Config zu speichern?
Zweiteres würde ich ungern automatisieren, das state-file öfter zu speichern würde für solche Fälle (und FHEM Abstürze anderer Art) ja allgemein nicht schaden.
edit: {WriteStatefile()} sollte helfen.
an dem sonderfall bei den readings bin ich immer noch am überlegen. ich habe aber noch keine gute idee. und da es noch nie thema war vermute ich das es schon ein sonderfall ist.
vielleicht erübrigt sich das ganze aber auch wenn die events so zuverlässig funktionieren das ich das pollen als backup komplett deaktivern kann.
ein {WriteStatefile()} jede stunde habe ich schon 'immer' in meiner config.
Ich habe seit der Umstellung sehr häufig folgende Meldung im Log:
deCONZ: websocket: event for unknown device received: deCONZ-G65520
Ich nutze einen ConBee II und ein set autocreate liefert created 0/0/0 devices (ignored 0/0/0)
Hat jemand eine Idee, wie ich das Gerät identifizieren oder ignorieren kann?
ich vermute du hast nicht die neueste version...
siehe hier: https://forum.fhem.de/index.php/topic,125764.msg1205130.html#msg1205130 (https://forum.fhem.de/index.php/topic,125764.msg1205130.html#msg1205130)
Du meinst die neueste Version des Moduls? Das letzte FHEM update lief gestern, sollte also passen.
was sagt version 30_HUEBridge.pm in fhem ?
version 30_HUEBridge.pm
File Rev Last Change
30_HUEBridge.pm 25616 2022-02-02 17:18:07Z justme1968
doif.js 24438 2021-05-14 18:08:18Z Ellert
fhemweb.js 25523 2022-01-20 19:44:28Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
Im Filesystem ist die Datei vom 6.2.
-rw-r----- 1 6061 6061 111803 Feb 6 21:46 30_HUEBridge.pm
-rw-r----- 1 6061 6061 95127 Feb 11 20:48 31_HUEDevice.pm
zeig mal bitte das log mit verbose 5 so das das event zu sehen ist.
verwendest du zufällig gerade deconz szenen wenn das passiert ?
schau mal ob die meldungen mit der angehängten version weg sind.
Zitat von: justme1968 am 12 Februar 2022, 22:16:35
zeig mal bitte das log mit verbose 5 so das das event zu sehen ist.
022.02.13 07:47:18.445 4: using HttpUtils_NonblockingGet: PUT lights/13/state
2022.02.13 07:47:19.762 5: deCONZ: websocket data: {
'r' => 'lights',
'id' => '13',
'uniqueid' => '00:17:88:01:02:9d:64:60-0b',
'state' => {
'sat' => 232,
'xy' => [
'0.5751',
'0.3814'
],
'reachable' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'on' => $VAR1->{'state'}{'reachable'},
'effect' => 'none',
'bri' => 24,
'hue' => 4806,
'ct' => 500,
'alert' => undef,
'colormode' => 'hs'
},
't' => 'event',
'e' => 'changed'
}
2022.02.13 07:47:19.786 5: deCONZ: websocket data: {
'state' => {
'all_on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
'any_on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
},
'id' => '65520',
'r' => 'groups',
't' => 'event',
'e' => 'changed'
}
2022.02.13 07:47:19.786 2: deCONZ: websocket: event for unknown device received: deCONZ-G65520
2022.02.13 07:47:19.787 4: deCONZ: dispatch: http://192.168.42.142/api/9F4E96F773/lights/13/state
2022.02.13 07:47:19.787 5: HUEBridge_dispatch: lights/13/state
2022.02.13 07:47:20.471 4: using HttpUtils_NonblockingGet: PUT lights/13/state
2022.02.13 07:47:20.476 4: deCONZ: dispatch: http://192.168.42.142/api/9F4E96F773/lights/13/state
2022.02.13 07:47:20.476 5: HUEBridge_dispatch: lights/13/state
2022.02.13 07:47:20.477 5: deCONZ: websocket data: {
'r' => 'lights',
'id' => '13',
'uniqueid' => '00:17:88:01:02:9d:64:60-0b',
'state' => {
'bri' => 128,
'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'effect' => 'none',
'reachable' => $VAR1->{'state'}{'on'},
'sat' => 232,
'xy' => [
'0.5751',
'0.3814'
],
'colormode' => 'ct',
'alert' => undef,
'ct' => 370,
'hue' => 4806
},
'e' => 'changed',
't' => 'event'
}Zitat von: justme1968 am 12 Februar 2022, 22:16:35
verwendest du zufällig gerade deconz szenen wenn das passiert ?
Ich habe keine Szenen in Phoscon angelegt und steure meine Leuchten über set Befehle.
Zitat von: justme1968 am 12 Februar 2022, 22:22:11
schau mal ob die meldungen mit der angehängten version weg sind.
Habe die Version eingespielt und beobachte heute.
Ich habe jetzt auch mal die Test-Version bei mir eingespielt.
das umlenken der 65-tausender All-Lights-Gruppe zu Group0 scheint zu funktionieren. (musste allerdings die ID in Zeile 154 anpassen)
Die Events landen in der Group0
2022.02.13 14:45:13 5: xx.GW.deCONZ: websocket data: $VAR1 = {
'state' => {
'all_on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
'any_on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
},
'id' => '65516',
't' => 'event',
'e' => 'changed',
'r' => 'groups'
};
2022.02.13 14:45:13 5: xx.GW.deCONZ: websocket: assuming group 0 for id 65516 in event
wie an anderer Stelle geschrieben bei mir hat die neue All-Light-Gruppe die ID 65516
vielleicht könnte man das als Attribut machen, das man, wie in meinem Fall, die im Notfall selber einstellen kann.
Ich habe auch noch eine Group65519 bei der werden die Readings nach wie vor aktualisiert, diese erscheinen aber nicht im Log.
Internals:
.FhemMetaInternals 1
DEF group 65519 IODev=xx.GW.deCONZ
FUUID 5eb170d1-f33f-e180-e31e-6189e91baa5faff9
FVERSION 31_HUEDevice.pm:0.256480/2022-02-07
ID G65519
INTERVAL
IODev xx.GW.deCONZ
NAME xx.GW.deCONZ_Group
NR 775
STATE on
TYPE HUEDevice
lights 1
name deconz
type LightGroup
.attraggr:
.attreocr:
.*
.attrminint:
READINGS:
2022-02-13 06:16:02 .associatedWith xx.GW.ConBee
2022-02-13 06:13:31 IODev xx.GW.deCONZ
2022-02-13 15:01:05 alert
2022-02-13 15:01:05 all_on 1
2022-02-13 15:01:05 any_on 1
2022-02-13 15:01:05 bri 0
2022-02-13 15:01:05 colormode
2022-02-13 06:16:02 ct 0
2022-02-13 15:01:05 effect
2022-02-13 06:16:02 hue 0
2022-02-13 15:01:05 onoff 1
2022-02-13 15:01:05 pct 100
2022-02-13 06:16:02 reachable 1
2022-02-13 15:01:05 sat 0
2022-02-13 06:16:02 state on
2022-02-13 06:16:02 xy 0,0
helper:
alert
all_on 1
any_on 1
bri 0
colormode
ct 0
devtype G
effect
hue 0
onoff 1
pct 100
reachable 1
sat 0
state on
update_timeout 1
xy 0,0
json:
etag aa5a61e214369b0d6bccf9b835c22708
id 65519
name deconz
type LightGroup
action:
alert none
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
lights:
1
scenes:
state:
lights:
1 1
scenes:
Attributes:
DbLogExclude .*
IODev xx.GW.deCONZ
alias deConz
cmdIcon on:general_an@green off:general_aus@gray
color-icons 2
createActionReadings 1
createGroupReadings 1
delayedUpdate 1
devStateIcon on:deconz@green off:deconz@lightgreen .*:deconz@yellow
event-on-change-reading .*
group HUE-Group
room hidden
sortby 01
userattr createActionReadings:1,0 createGroupReadings:1,0
schau mal bitte in dem oben verlinkten beitrag den link zu github an. die nummer der gruppe die deconz für die alle gruppe verwendet ist scheibar auf deconz seite konfigurierbar. ansonsten habe ich das gefühl das das eigentliche problem auf deconz seite liegt. die biegen die gruppe 0 auf eine der 0xffxx gruppen um, biegen die events aber nicht wieder zurück auf gruppe 0 wie im api vorgesehen ist. oder zumindest sollten sie die gruppen für die events erzeugt werden auch in der liste alller gruppen mit aufführen.
wenn keine meldungen erzeugt werden taucht diese gruppe vermutlich beim get groups mit auf. kannst du versuchen rauszufinden woher diese gruppe kommt
Die Gruppe 65519 wurde damals automatisch im deconz erstellt, in Ihr ist nur der ConBee2 enthalten.
Im FhEM habe ich die Gruppe erstellt (weil mich die die Meldungen im Log neugierig gemacht hatten, was das für eine Gruppe ist).
Diese hohen ID's kannte ich bis dahin nur von der Tradfri. da beide Systeme (deconz-GW und Tradfri-GW) eine Zeitlang parallel liefen und die Lampen und Rollos nach und nach zur deconz gewandert sind,
könnte ich mir vorstellen das deconz da irgendetwas übernommen hat und die anderen 65er ID's durch gelöschte/alte Geräte intern noch reserviert sind.
Aber ich schau mal ob ich in den deconz-Eingeweihten was finde.
Naja fast wie erwartet.
Die gelb markierten sind Gruppen die es damals auf der Tradfri gab.
und scheinbar hat deconz auch schon mal eine All-Gruppe erstellt und wieder gelöscht.
bis ID 23 das war ich auf der deconz.
Aber im Endeffekt ist es mir auch egal. wie die All-Lights gruppe heisst und ob es sie gibt.
Ich will diese nicht schalten.
Wollte nur zeigen das die neue All-Lights nicht unbedingt die 65520 haben muss.
Zitat von: justme1968 am 12 Februar 2022, 22:22:11
schau mal ob die meldungen mit der angehängten version weg sind.
Seit ich diese Version nutze, ist die Meldung nicht im mehr im Log zu finden. Scheint für mich also zu funktionieren.
Vielen Dank für den schnellen Support justme1968!
Ich habe im Log Freezemeldungen, die eigentlich immer (meist auch nur) meine "Friends of Hue" Schalter enthalten. Leider aller paar Minuten.
Das war auch schon im früheren Modul so.
Hat jemand einen Hinweis ob das abstellbar ist und wo?
Zitat2022.03.23 10:34:41 1: [Freezemon] Lahmheit: possible freeze starting at 10:34:40, delay is 1.247 possibly caused by: fn-ReadFn(myHmUART) tmr-HUEDevice_GetUpdate(Wandschalter_WZ_Treppe) tmr-HUEDevice_GetUpdate(Wandschalter_Kue_1) tmr-HUEDevice_GetUpdate(Wandschalter_Kue_2) tmr-HUEDevice_GetUpdate(Wandschalter_WZ_Sofa) tmr-HUEDevice_GetUpdate(Wandschalter_WZ_vorn)
Das sind alle FoH-Schalter.
GetUpdate deutet darauf hin die daten nicht aus einem event kommen sondern vom pollen. wie oft pollst du? es kann sein das einfach die bridge überlastet ist und nicht schnell genug antwortet. hast du HttpUtils aktiviert?
wie oft passiert das? sobald es die events gibt sollten die einzelnen devices garnicht mehr einzeln gepollt werden.
ist pollDevices aktiv?
Danke für die Hinweise, das hilft sicher.
Hier erstmal ein List der Bridge (Geräte entfernt).
Internals:
DEF 192.168.178.66
EventStream terminated; retrying later
FUUID 5e5593c0-f33f-23c4-96c6-7b5335903f39b042
FVERSION 30_HUEBridge.pm:0.257690/2022-03-03
INTERVAL 60
NAME HueBridge
NOTIFYDEV global
NR 666
NTFY_ORDER 50-HueBridge
STATE connected
TYPE HUEBridge
apiversion 1.50.0
bridgeid 001788FFFE6B0EE7
has_v2_api 1
host 192.168.178.66
mac 00:17:88:6b:0e:e7
manufacturer Signify
modelName Philips hue bridge 2015
modelid BSB002
name Wormser 34 Hue
swversion 1950111030
updatestate 0
zigbeechannel 15
READINGS:
2022-03-22 22:28:33 groups 9/16
2022-01-20 11:35:56 lastError resource, /groups/8, not available
2022-03-22 22:28:33 lights 11/16
2022-03-22 22:28:33 rules 51/128
2022-03-22 22:25:34 scenes 19/32
2022-01-28 16:19:48 schedules 0
2022-03-22 22:28:33 sensors 10/16
2022-03-23 11:10:59 state connected
2022-03-17 15:59:40 swupdate BSB002 - 1.50_SR2.1
helper:
apiversion 78336
count 0
last_config_timestamp 1648030258
offsetUTC 3600
updatestate 0
HTTP_CONNECTION:
EventSource 1
NAME
addr https://192.168.178.66:443
auth 0
buf
displayurl https://192.168.178.66/eventstream/clip/v2
header Accept: text/event-stream
HUE-Application-Key:lgelöscht
host 192.168.178.66
httpdata
httpdatalen -1
httpheader HTTP/1.1 200 OK
Server: nginx
Date: Tue, 22 Mar 2022 22:28:53 GMT
Content-Type: text/event-stream; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
Cache-Control: no-store
Pragma: no-cache
Referrer-Policy: no-referrer
httpversion 1.1
incrementalTimeout 1
keepalive 1
loglevel 4
method GET
noshutdown 1
path /eventstream/clip/v2
protocol https
redirects 0
timeout 3600
type event
url https://192.168.178.66/eventstream/clip/v2
hash:
sslargs:
Attributes:
httpUtils 1
icon hue_filled_bridge_v2
key gelöscht
room System->HUEDevice
verbose 3
Ich habe jetzt "HttpUtils" aktiviert, mal beobachten.
Ich habe die Hilfe zu pollDevices so verstanden, dass bei v2 dieses Attribut gelöscht wird.
Wo sehe ich eigentlich ob Modul und API aktuell sind?
Wie oft es passiert? So aller 2-3 Minuten, manchmal ist der Abstand größer.
Meine Freezemeldungen sind leider immer noch da.
HttpUtils hat keine Änderung gebracht.
Es ist ja auch das hmUart gelistet UND: es kann/können durchaus auch "false positive" sein.
Soll heißen, nicht alles was von FreezeMon gemeldet wird ist auch TATSÄCHLICH ein Freeze, es gibt auch "Konstellationen", wo es für FreezeMon nur so "aussieht"...
Für genauere Analyse müsste man bei FreezeMon einige Einstellungen machen und dann genau(er) prüfen, ist aber hier (aktuell) eher "OT"!?
Gruß, Joachim
Hallo Andre,
ich hatte nochmal den Fall, dass bei einem FHEM Neustart ein alter Tastendruck eines Zigbee Tasters als "neues Event" gewertet wurde und das SmartHome sich "verselbstständigt" hat.
Dürfte irgendwas mit der Zeitumstellung zu tun gehabt haben.
Ich hab wohl mittlerweile ein AT, welches das State-File zyklisch sichert, aber der Neustart den ich wöchentlich Nachts durchführen lasse war zufällig zu nah an der Zeitumstellung.
Dadurch scheint die Kombination Conbee2/Deconz und FHEM wohl der Meinung gewesen zu sein, dass das Event noch unbekannt war.
Da das Ganze immer noch seltene Randerscheinungen bleiben dürften, ein Wunsch / Vorschlag um das relativ unkompliziert zu umgehen (siehe dein Zitat unten):
Einfach ein Attribut, welches man den HUEDevices verpassen kann, mit dem man sagt "Du bist ein Device welches Events bekommt und somit nicht Pollen muss und im aktuellen Fall auch nicht Pollen soll".
Das könnte man dann z.B. Tastern zuweisen, Thermometern dafür nicht.
So kann der User das sauber bestimmen wenn er sich die Mühe machen will.
Das HUEBridge Modul muss es aber nicht selbstständig herausfinden (was wie von dir gut beschrieben ja nicht wirklich klappen kann).
Wenn man es noch feiner bestimmen will, könnte das Attribut auch eine Liste von Readings aufnehmen welche nicht gepollt werden sollen.
Dann könnte man battery etc. noch weiter zyklisch abholen lassen.
Aber darf auch gern die einfachere Version sein, wer weiß wer das außer mir jemals nutzen wird. ;)
Zitat von: justme1968 am 08 Februar 2022, 09:04:47
das ist im prinzip möglich. betrifft aber so auch alle anderen dinge die sich auf den vergleich mit einem vorherigen zustand (z.b. über OldReadingsVal) verlassen. wenn der alte zustand nicht zuverlässig ist gibt es ein problem.
dazu gibt es mehrere mögliche lösungen, die alle ebenfalls irgendwelche nachteile haben:
- nach einem neustart wird grundsätzlich die erste zustandsänderung ignoriert -> es gehen möglicherweise
zustände verloren
- nach einem neustart werden grundsätzlich die ersten daten die durch pollen rein kommen ignoriert
das geht nur auf systeme bei denen die bridge auch events sendet.
- für sensoren grundsätzlich nicht mehr pollen wenn es events gibt. geht nur wenn es (zuverlässige) events
gibt und das weiss ich eigentlich erst nach dem das erste event gekommen ist. wie merke ich mir das wenn
ich mich nicht darauf verlassen kann das die readings nach dem neustart stimmen?
- man baut irgendwelche höchstalter für die daten ein. problem: wie alt ist alt genug zum ignorieren?
die frage ist halt: was ist wichtiger, das der interne zustand nach einem neustart so schnell wie möglich stimmt und eventuell events doppelt kommen oder das niemals falsch ausgelöst wird und eventuell events verloren gehen. eventuell ist je nach sensor typ das eine oder das andere besser.
wie wäre ein attribut mit dem man 1., 2. oder 3. von oben und zusätzlich 4. konfigurieren kann?
ganz unabhängig davon eine geschichte: vor ein paar wochen hat der rollladen hier im schlafzimmer angefangen zu spinnen und ist mitten in der nacht mehrfach auf oder zu gefahren. nach langem suchen habe ich dann eine tablet ui installation an der wand als verantwortlichen gefunden. irgend ein netzwerk problem hat dazu geführt das das ding der meinung war jemand hat es von hand bedient.
Zitatich hatte nochmal den Fall, dass bei einem FHEM Neustart ein alter Tastendruck eines Zigbee Tasters als "neues Event" gewertet wurde und das SmartHome sich "verselbstständigt" hat.
Sowas hatte ich letzte Nacht auch. Ich habe gesehen dass ein Event von mehreren Dimmern und auch DeConZ Buttons ausgelöst wurde (logfile). Im Dimmer oder Button selber ist das Reading ''state'' aber noch mehrere Tage alt.
Um das Problem abzufangen, frage ich jetzt im notify das Readingsage des state vom jeweiligen Device ab. Nach einem Tastendruck sollte das event sofort kommen, also readingsAge < 5 Sekunden.
##########################################################
# HUE DIMMER
# notify definition with Sub
# defmod HueDimmer_n notify HueDimmer._.*:.00. {myHueDimmer($NAME,$EVENT)}
##########################################################
sub myHueDimmer {
my $sub = 'myHueDimmer';
my $NAME = shift // return "Error, $sub: we need NAME as parameter!";
my $EVENT = shift // return "Error, $sub: we need EVENT as parameter!";
# [myHueDimmer] Name=HueDimmer1_Wohn, EVENT=2002
Log 3, "[$sub] Name=$NAME, EVENT=$EVENT";
# In case of a Ghost event, the ReadingsAge of the state of the physical button is too old
if (ReadingsAge($NAME,'state',8) < 4) {# prevent ghost events, checking ReadingsAge
# Hier Auswertung des Events und triggern einer Aktion
}
else {Log 3, "[$sub] GHOST Event, Name=$NAME, EVENT=$EVENT";}
}
Danke für die Rückmeldung.
Dann bin ich ja doch nicht ganz allein. 8)
Auf die Idee es mit so einem Workaround zu versuchen kam ich gar nicht.
Klar, dass Readingsdatum auf den Timestamp von Deconz zu setzen klingt aus Modulsicht logisch,
aber mir war nicht bewusst, dass Entwickler das in FHEM so umsetzen können.
Den ganzen Funktionen zum Updaten der Readings kann ja eigentlich gar kein Zeitstempel mit übergeben werden:
https://wiki.fhem.de/wiki/DevelopmentModuleAPI
PS: Ich habe oben noch das notify mal als codeschnipsel eingefügt.
@Thyraz: doch das geht über einen kleinen umweg und das macht das modul auch. die hauptsächlichen einschränkungen dabei sind:
- der long poll update um frontend zeigt den falschen (aktuellen) timestamp und nicht den tatsächlichen
nach einem refresh ist das aber ok
- mit filelog kann es probleme geben wenn die reihenfolge der einträge nicht stimm. das passiert
aber hier nicht.
beim mehrmals drüber nachdenken ist mir die idee gekommen das man pro reading über ein attribut konfigurieren könnte das kein event erzeugt wird wenn das reading älter als x sekunden ist.
damit müssten sich eigentlich alle problemfälle abdecken lassen.
eine weitere möglichkeit wäre das man das pollen komplett deaktiviert wenn das erste event kommt. ich weiss aber noch nicht wie wir damit umgehen das die events ausbleiben könnten.
Du müsstest diese Info per Device eben so abspeichern, dass du es noch nach dem Restart weißt.
Also irgendwo persistent und nicht flüchtig.
Pollen generell deaktivieren nach dem ersten Event (das könntest du ja durchaus persistent machen, so dass die Info nach einem Neustart immer noch da ist) würde ich nicht machen.
Bei manchen Geräten will man ja dennoch den letzten Wert, auch wenn FHEM ggf. wegen Wartungsarbeiten mal down war.
Die erste Idee klingt aber gut so. :)
@Jamo, danke für deinen Workaround, bau ich dann vorerst auch mal so ein.
Hallo,
ich möchte nur sagen, dass das Triggern mit "alten Events" bestimmt keine sehr seltenen Einzelfälle sind.
Bei mir wurden in der Nacht der Zeitumstellung alle DOIFs, welche per Tastendruck mit IKEA-Buttons toggeln, ausgelöst.
Ich würde mich daher auch über ein "ReadingsAge"-Attribut freuen.
Grüße
Ich setz mal noch nen Link zu dem Thread, da dort auch jemand auf das Problem gestoßen ist:
https://forum.fhem.de/index.php?topic=127046.msg1215955#msg1215955
Hallo,
seit dem Update auf die neue Version erhalte ich nun (mit Unterbrechungen) im stündlichen Rhythmus die folgenden Logeinträge:
2022.04.12 01:04:04 2: Philips_HUE: http request failed: read from https://IPADR:443 timed out
2022.04.12 01:04:04 2: Philips_HUE: EventStream: terminated
Das Attribut "eventstreamTimeout" (undokumentiert in Commandref) deutet auf eine pot. Lösung hin.
Gibt es hier Erfahrungswerte für einen "richtigen" Wert? In welcher Einheit erfolgt die Wertangabe und gibt es ggf. negative Auswirkungen wenn der Wert zu groß gewählt wird ?
Danke für eine Prüfung und Rückmeldung,
Obi-Wan
Zitat2022.04.12 01:04:04 2: Philips_HUE: http request failed: read from https://IPADR:443 timed out
Womoeglich haengt das mit einem anderen Problem zusammen: https://forum.fhem.de/index.php?topic=127077
Zitat von: rudolfkoenig am 12 April 2022, 14:31:26
Womoeglich haengt das mit einem anderen Problem zusammen: https://forum.fhem.de/index.php?topic=127077
Stimmt, könnte passen.
Allerdings kann ich bei meiner Installation keinerlei Verzögerungen beim Zugriff der Weboberfläche oder den Schaltvorgängen feststellen, reboots waren in letzter Zeit ebenfalls nicht notwendig und fhem.pl läuft noch in der auch von Heiko im zitierten Thread für gut befundenen Version 25777/2022-03-05
Insofern würde ich in diesem Fall eher auf ein lokales Thema im Zusammenspiel des HUEBridge-Moduls mit der HUEBridge tippen.
die hue meldungen haben ziemlich sicher eine andere ursache.
die bridge nimmt mit aktueller firmware weniger parallele verbindungen an als vorher. signify empfiehlt sogar nur eine http/2 verbindung zu verwenden und dort einzelne steams zu verwenden. alternativ eine queue für http/1.x
fhem kann ersteres (noch) nicht und letzteres ist aktuell nicht eingebaut da es eine größere änderung im modul wäre.
da die meldungen normalerweise vom pollen kommen und nicht vom schalten sollte es wenig bis keine negativen auswirkungen haben. alles was das pollen verringern kann hilft aber. da es in der aktuellen version den event support gibt und das pollen für sensoren eigentlich automatisch verhindert wird wenn events gekommen sind wäre die frage ob eventuell diese änderungen manchmal nicht greifen oder die bridge aus anderen gründen ausgelastet ist.
der zweite fall in dem es solche meldungen gibt ist der normale ab und wieder aufbau des event streams. da die verbindung absichtlich zu und wieder aufgemacht wird sollte es eigentlich garkein meldung geben. das scheint nur manche installationen zu betreffen. mir ist noch nicht ganz klar ob es speziell welche mit wenigen events sind oder welche mit vielen. hier sollte das setzen von eventstreamTimeout auf einen großen wert helfen. der wert ist in sekunden zu verstehen. probieren kann man ruhig 86400 oder ähnliches.
OK verstehe, hier noch mehr Details zu meiner lokalen Installation hier: Ich ziehe die FHEM Produktivumgebung aktuell auf eine neue HW um - aus Zeitgründen Stück für Stück und daher laufen, soweit nötig/möglich auch einige Module parallel auf dem Alt- und Neusystem.
Auf dem Altsystem läuft 30_HUEBridge.pm:0.242960/2021-04-21 und erzeugt keinerlei der o.a. Logeinträge wohingegen auf dem Neusystem 30_HUEBridge.pm:0.257690/2022-03-03 läuft und die geschilderten Logs in schöner Regelmäßigkeit erzeugt.
Ich werde also sobald möglich das HUE-Modul auf dem Altsystem deaktivieren und mal beobachten wie und ob sich das Logverhalten auf dem Neusystem verändert, komisch ist nur das die Abbrüche bislang nur auf dem Neusystem erfolgen. Hilft das nicht werde ich wie vorgeschlagen den Timeout entsprechend hochsetzten.
Danke und Gruß,
Obi-Wan
Update:
Abschalten des Altsystems brachte keine Veränderung im Logverhalten. Gestern Abend dann Timeout auf 28800 gesetzt, seit 27 Stunden keinen einzigen Logeintrag mehr....
Zitat von: uge am 29 März 2022, 10:07:50Hallo,
ich möchte nur sagen, dass das Triggern mit "alten Events" bestimmt keine sehr seltenen Einzelfälle sind.
Bei mir wurden in der Nacht der Zeitumstellung alle DOIFs, welche per Tastendruck mit IKEA-Buttons toggeln, ausgelöst.
Ich würde mich daher auch über ein "ReadingsAge"-Attribut freuen.
Grüße
Hallo,
ich schließe mich hier mal an, mir ist nach der Zeitumstellung genau das gleiche passiert, fast alle meine Ikea Tradfri Geräte haben sich nach der Zeitumstellung eingeschaltet, kann man dieses extrem lästige Verhalten nicht irgendwie beheben? Ich hatte hier einen Thread dazu erstellt und wurde dann darauf hingewiesen dass dieses Verhalten schon seit Jahren bekannt ist, aber nicht gefixt wird (danke @Jamo für) :-(
https://forum.fhem.de/index.php?topic=137714.new#new