@jey-cee deCONZ (läuft auf einem alten Raspberry) macht standardmäßig kaum Logging. Ich müsste erst mal rausfinden, mit welchen Logging-Einstellungen ich solche Events erfasse, ohne massiv Daten auf die SD-Karte zu schreiben. Das Problem tritt ja nur sehr unregelmäßig auf.

@jey-cee Minuten vor und nach diesem Abschnitt sind im Log nur deconz.0-Einträge mit "Websocket message: {"attr" ...", die regulär alle paar Sekunden gelogt werden. Sonst rein gar nichts.

Hallo deconz-Experten,

Ich betreibe eine kleine Anzahl an Zigbee-fähigen Leuchtmitteln am deconz-Adapter. In der Regel steuere ich diese über yahka-Verknüpfungen bzw. über HmIP-Taster via blockly-Script.

Alle paar Wochen, zu unterschiedlichen Zeiten, schaltet sich eine dieser Lampen ungewollt ein, und fast alle Lampen waren schon mal betroffen. Ich kann ausschließen, dass diese Events durch Nutzeraktivitäten getriggert werden. Heute Nacht war das Schlafzimmer betroffen. Ich habe vor ein paar Wochen das deconz- Logging auf debug umgestellt und sehe das folgende:

2022-07-29 02:34:05.484  - debug: deconz.0 (4435) Websocket message: {"e":"changed","id":"6","r":"lights","state":{"alert":null,"bri":58,"colormode":"hs","ct":201,"effect":"none","hue":11352,"on":false,"reachable":true,"sat":71,"xy":[0.3484,0.3638]},"t":"event","uniqueid":"00:15:8d:00:04:20:1e:2f-01"}
2022-07-29 02:34:05.484  - debug: deconz.0 (4435) Event has state-tag
2022-07-29 02:34:05.511  - debug: deconz.0 (4435) alert: null
2022-07-29 02:34:05.514  - debug: deconz.0 (4435) bri: 58
2022-07-29 02:34:05.516  - debug: deconz.0 (4435) Websocket message: {"attr":{"id":"5","lastannounced":"2022-06-28T06:48:40Z","lastseen":"2022-07-29T00:34Z","manufacturername":"Paulmann Licht","modelid":"500.45","name":"Fensterlicht Wohnzimmer","swversion":"1400-0001","type":"Dimmable light","uniqueid":"00:15:8d:00:05:81:67:e5-01"},"e":"changed","id":"5","r":"lights","t":"event","uniqueid":"00:15:8d:00:05:81:67:e5-01"}
2022-07-29 02:34:05.517  - debug: deconz.0 (4435) Event has attr-Tag
2022-07-29 02:34:05.563  - debug: deconz.0 (4435) colormode: hs
2022-07-29 02:34:05.609  - debug: deconz.0 (4435) ct: 201
2022-07-29 02:34:05.653  - debug: deconz.0 (4435) effect: none
2022-07-29 02:34:05.698  - debug: deconz.0 (4435) hue: 11352
2022-07-29 02:34:05.745  - debug: deconz.0 (4435) on: false
2022-07-29 02:34:05.789  - debug: deconz.0 (4435) reachable: true
2022-07-29 02:34:05.833  - debug: deconz.0 (4435) sat: 71
2022-07-29 02:34:05.877  - debug: deconz.0 (4435) xy: 0.3484,0.3638
2022-07-29 02:34:06.537  - debug: deconz.0 (4435) Websocket message: {"attr":{"colorcapabilities":0,"ctmax":65279,"ctmin":0,"id":"6","lastannounced":"2022-07-29T00:34:05Z","lastseen":"2022-07-29T00:34Z","manufacturername":"Paulmann Licht","modelid":"500.49","name":"Wandlicht Schlafzimmer","swversion":"1400-0001","type":"Extended color light","uniqueid":"00:15:8d:00:04:20:1e:2f-01"},"e":"changed","id":"6","r":"lights","t":"event","uniqueid":"00:15:8d:00:04:20:1e:2f-01"}
2022-07-29 02:34:06.538  - debug: deconz.0 (4435) Event has attr-Tag
2022-07-29 02:34:06.555  - debug: deconz.0 (4435) Websocket message: {"e":"changed","id":"6","r":"lights","state":{"alert":null,"bri":58,"colormode":"hs","ct":201,"effect":"none","hue":11352,"on":true,"reachable":true,"sat":71,"xy":[0.3484,0.3638]},"t":"event","uniqueid":"00:15:8d:00:04:20:1e:2f-01"}
2022-07-29 02:34:06.555  - debug: deconz.0 (4435) Event has state-tag
2022-07-29 02:34:06.571  - debug: deconz.0 (4435) Websocket message: {"e":"changed","id":"65520","r":"groups","state":{"all_on":false,"any_on":true},"t":"event"}
2022-07-29 02:34:06.582  - debug: deconz.0 (4435) Websocket message: {"e":"changed","id":"5","r":"groups","state":{"all_on":false,"any_on":true},"t":"event"}
2022-07-29 02:34:06.586  - debug: deconz.0 (4435) alert: null
2022-07-29 02:34:06.591  - debug: deconz.0 (4435) bri: 58
2022-07-29 02:34:06.606  - debug: deconz.0 (4435) Code 200: Request succeded get group attributes 65520: {"action":{"alert":"none","bri":127,"colormode":"hs","ct":0,"effect":"none","hue":0,"on":false,"sat":127,"scene":null,"xy":[0,0]},"devicemembership":[],"etag":"a0f459d1057dbe6a48d818c316b2a66c","id":"65520","lights":["1","3","5","8","2","4","7","9","6"],"name":"All","scenes":[],"state":{"all_on":false,"any_on":true},"type":"LightGroup"}
2022-07-29 02:34:06.608  - debug: deconz.0 (4435) colormode: hs
2022-07-29 02:34:06.629  - debug: deconz.0 (4435) Code 200: Request succeded get group attributes 5: {"action":{"alert":"none","bri":127,"colormode":"hs","ct":0,"effect":"none","hue":0,"on":false,"sat":127,"scene":null,"xy":[0,0]},"devicemembership":[],"etag":"23d0ed578ea35e49993d565af90ffde4","id":"5","lights":["8","7","9","6"],"name":"Schlafzimmer","scenes":[],"state":{"all_on":false,"any_on":true},"type":"LightGroup"}
2022-07-29 02:34:06.632  - debug: deconz.0 (4435) ct: 201
2022-07-29 02:34:06.637  - debug: deconz.0 (4435) effect: none
2022-07-29 02:34:06.685  - debug: deconz.0 (4435) hue: 11352
2022-07-29 02:34:06.730  - debug: deconz.0 (4435) on: true
2022-07-29 02:34:06.736  - debug: deconz.0 (4435) reachable: true
2022-07-29 02:34:06.748  - debug: deconz.0 (4435) sat: 71
2022-07-29 02:34:06.759  - debug: deconz.0 (4435) xy: 0.3484,0.3638

Ich sehe hier zwei Events - das "Fensterlicht Wohnzimmer" war aus und blieb aus, das "Wandlicht Schlafzimmer" war aus und wurde eingeschaltet. Kann man hieraus irgendwie erkennen, was diese Events getriggert hat? Wenn nein, was kann ich noch tun, um diesem Phänomen auf den Grund zu gehen?

Gruß
Michael

km200 (Buderus) auch:

2021-08-11 17:37:16.339 - info: km200.0 (22247) State value to set for "km200.0.heatSources.info" has to be type "string" but received type "object"
2021-08-11 17:37:16.347 - info: km200.0 (22247) State value to set for "km200.0.heatSources.info" has to be type "string" but received type "object"
2021-08-11 17:37:19.553 - info: km200.0 (22247) State value to set for "km200.0.heatingCircuits.hc1.currentOpModeInfo" has to be type "string" but received type "object"
2021-08-11 17:37:19.556 - info: km200.0 (22247) State value to set for "km200.0.heatingCircuits.hc1.currentOpModeInfo" has to be type "string" but received type "object"
2021-08-11 17:37:32.461 - info: km200.0 (22247) State value to set for "km200.0.recordings.heatSources.actualPower._Months" has to be type "string" but received type "object"
2021-08-11 17:37:32.463 - info: km200.0 (22247) State value to set for "km200.0.recordings.heatSources.actualPower._Months" has to be type "string" but received type "object"

Kommentiert unter https://github.com/frankjoke/ioBroker.km200/issues/59#issuecomment-896948783
Gab allerdings schon länger keine Updates mehr für diesen Adapter ...

ioBrokerChecker created this issue in frankjoke/ioBroker.km200

closed Compatibility check to js-controller 3.3 and Admin5 React UI #59

Ich habe hm-rpc.2 jetzt zweimal über die "Geräte neu einlesen (einmalig)"-Funktion neu gestartet: Einmal mit Haken bei "Geräte nicht löschen bei Adapterstart" gesetzt, und einmal ohne. Die Logfile-Einträge sind in beiden Fällen praktisch identisch, und in beiden Fällen wurde das influxdb-Logging nicht disabled.
Kann ich also davon ausgehen, dass die Deaktivierung des Loggings in meinem Fall oben ein Bug ist?

@paul53 Ich kann das zumindest auch indirekt belegen. Aus dem Log der CCU3:

Aug 21 18:29:06 de.eq3.cbcs.server.core.framehandling.HMIPNetworkManagementHandler INFO  [vert.x-eventloop-thread-0] AP 3014F711A0001F9A4989xxxx: Device included 3014F711A000019BE98Bxxxx 

Der Timestamp 18:29:06 ist identisch mit dem "xmlrpc <- newDevices" Event in der hm-rpc.2-Instanz oben im Log.

@paul53 sagte:

Wenn neue Geräte eingelesen werden sollen, muss die Option "Geräte neu einlesen (einmalig)" aktiviert und gespeichert werden, was einen Neustart der Instanz zur Folge hat.

In meinem Fall (der hier im Log erfasst ist) habe ich lediglich das neue Gerät an der CCU angelernt. Das Einlesen am iobroker habe ich nicht selbst veranlasst. Das hat die hm-rpc.2-Instanz ohne mein Zutun ausgelöst. Ich schwör!

@paul53 Habe das im Text auf "hm-rpc-Adapter" korrigiert. Soweit ich das beobachten konnte, betrifft es aber nur die Instanz, die für HmIP-Geräte zuständig ist.

Die Einstellung war mir bisher nicht aufgefallen - habe das mal aktiviert. Bin nicht 100% sicher, aber ich meine, bei einem normalen Adapter-Neustart wären die Logging-Einstellungen erhalten geblieben. Und streng genommen kommt es ja beim Zufügen von neuen Geräten an der CCU ja nicht zu einem echten Adapter-Neustart, oder doch?

Hi,

ich habe ein lästiges Problem mit dem hm-rpc-Adapter:
Sobald ich an der CCU3 ein neues HmIP-Gerät anlerne, erstellt der hm-rpc-Adapter den kompletten Objekt-Baum neu und verliert dabei die Einstellungen für das Logging von Objektwerten. Konkret schreibe ich Temperatur und Luftfeuchtigkeit meiner HmIP-Thermostate in eine Influx-DB; diese Einstellung deaktiviert sich von selbst.

Hier ein stark gekürzter Auszug aus dem Log nach dem Anlernen eines Hm-IP-Tasters:

2020-08-21 18:29:06.207 - info: hm-rpc.2 (24924) xmlrpc <- newDevices 4
2020-08-21 18:29:06.709 - info: hm-rpc.2 (24924) obsolete device 0000DA499Cxxxx deleted
2020-08-21 18:29:06.711 - info: hm-rpc.2 (24924) Delete channel hm-rpc.2.0000DA499Cxxxx.0
2020-08-21 18:29:06.713 - info: hm-rpc.2 (24924) obsolete channel 0000DA499Cxxxx.0 "0000DA499C6771.0" deleted
2020-08-21 18:29:06.714 - info: hm-rpc.2 (24924) Delete channel hm-rpc.2.0000DA499Cxxxx.1
2020-08-21 18:29:06.716 - info: hm-rpc.2 (24924) obsolete channel 0000DA499Cxxxx.1 "0000DA499C6771.1" deleted
[...]
2020-08-21 18:29:07.138 - info: hm-rpc.2 (24924) new HmIP devices/channels after filter: 4
2020-08-21 18:29:18.411 - info: hm-rpc.2 (24924) xmlrpc -> getParamsetDescription ["001F9A49897270:50","VALUES"]
2020-08-21 18:29:21.966 - info: influxdb.0 (1873) disabled logging of hm-rpc.2.000A9A499Exxxx.1.HUMIDITY
2020-08-21 18:29:22.092 - info: influxdb.0 (1873) disabled logging of hm-rpc.2.000A9A499Exxxx.1.ACTUAL_TEMPERATURE
[...]
2020-08-21 18:29:38.017 - info: hm-rpc.2 (24924) xmlrpc -> getParamsetDescription ["001F9A49897270:49","VALUES"]
2020-08-21 18:29:38.077 - info: hm-rpc.2 (24924) xmlrpc -> getParamsetDescription ["001F9A49897270:48","VALUES"]
[...]
2020-08-21 18:30:01.610 - warn: hm-rega.0 (1292) Object hm-rpc.2.00189A498Dxxxx.2 is invalid: obj.type has to exist
2020-08-21 18:30:01.615 - warn: hm-rega.0 (1292) This object will not be created in future versions. Please report this to the developer.
2020-08-21 18:30:01.621 - info: hm-rega.0 (1292) renamed hm-rpc.2.00189A498Dxxxx.2 to "HmIP-SWD 00189A498Dxxxx:2"

Kann man irgendwie verhindern, dass das Logging der Werte in dieser Situation deaktiviert wird? Wenn nein, gibt es eine Methode, das Logging über den influxdb-Adapter per Script neu zu aktivieren (vielleicht getriggert durch diese "disabled logging" Events)?

Und was sollen mir die Warnungen der hm-rega.0-Instanz sagen?

Gruß
Michael

Kurzes Update für's Archiv: Ich sehe gerade, dass die fehlenden "Relay0"-Objekte jetzt da sind. Ich hatte zwischenzeitlich mal auf MQTT umgestellt und dann wieder zurück nach CoAP gewechselt ... vielleicht hat das ja den Knoten gelöst. Egal - hauptsache es geht jetzt.