Aquara Multi Sensors (Temperature/Pressure/Humidity) no longer reporting temperature

[UppyJC]

Describe the bug

Since upgrading to latest deCONZ version, Aquara Multi Sensors (Temperature/Pressure/Humidity) no longer reporting temperature. API reports null values, Phoscon reports 0 degrees. Pressure and humidity values fine.

Deleting and re-adding sensors makes no difference.

Working correctly on previous version, but can't remember which version that was!

Steps to reproduce the behavior

Add any sensor of affected type to deCONZ. Observe null temperature value in API and 0 temperature value in Phoscon. Humidity and pressure values report correctly.

Expected behavior

Temperature value reports correctly in API and Phoscon.

Screenshots

Environment

• Host system: PC
• Running method: Windows
• Firmware version: (26580700)
• deCONZ version: (2.15.02)
• Device: ConBee II
• Do you use an USB extension cable: Yes
• Is there any other USB or serial devices connected to the host system?: No

deCONZ Logs

Additional context

[Mimiix]

What does the respective clusters show in deCONZ?

Also, did you try this?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Xiaomi:-Lost-devices-or-functional-issues

[UppyJC]

Yes, I have re-paired one of the sensors and read node descriptors and simple descriptors.

There is a reading in deCONZ as shown of the screenshot below, but the API and Phoscon both still report null/0 respectively.

I have 11 of these sensors and they're all exhibiting exactly the same behaviour from the same time (when I upgraded to the latest deCONZ version).

[nunoary]

I see the same behavior. It was working fine with version 2.14.01 but after installing version 2.15.01 the sensors no longer report temperature.

I did some tests and noticed that if I turn off the DDF of these sensors (put the status in "Draft") the sensors work correctly and report the temperature again. But if you put it back in "Gold" the sensors stop reporting the temperature again. This happens to my sensors "lumi.weather" and "lumi.sensor_ht".

I saw in another post that this bug had been fixed in version 2.15.01 but it seems that it remains.

[DNC74]

as wished by @Mimiix an edit and copy from https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5978 :

Describe the bug

My installation was on 2.14.01 where anything was running fine. With the update to 2.15.00 to 2.15.02 versions the reporting of battery levels of all my Aquara WSDCGQ11LM sensors stopped, while all other sensor values from these sensors are working as expected. Any other paired devices to my Conbee I stick are working flawless as well.

Steps to reproduce the behavior

Add Aquara Multi Sensors (Temperature/Pressure/Humidity) WSDCGQ11LM sensors to deCONZ. Observe null battery values in Phoscon and API. Temperature, Humidity and Pressure values are reported correctly.

Expected behavior

Getting Battery values as in versions before 2.15.x

Environment

• Host system: Synology DS1817+
• Running method: Virtual Machine Ubuntu 18.04.6 LTS
• Firmware version: 26390500
• deCONZ version: 2.15.02 non-gui
• Device: ConBee I
• Do you use an USB extension cable: yes
• Is there any other USB or serial devices connected to the host system? no

deCONZ Logs

log.txt

I can see battery values arriving in the logs for Xiaomi Contact sensors lumi.sensor_magnet.aq2 for example

12:12:13:233 ZCL attribute report 0x00158D00031B307E for cluster: 0x0000, ep: 0x01, frame control: 0x1C, mfcode: 0x115F
12:12:13:233 0x00158D00031B307E extract Xiaomi special attribute 0xFF01
12:12:13:233    01 battery 3005 (0x0BBD)
12:12:13:233    03 Device temperature 19 °C
12:12:13:233    04 unknown 17320 (0x43A8)
12:12:13:233    05 RSSI dB (?) 39 (0x0027)
12:12:13:233    06 LQI (?) 4294967296 (0x0100000000)
12:12:13:233    0a Parent NWK 21757 (0x54FD)
12:12:13:233    64 on/off 0

but similar messages for the Xiaomi Multi sensors lumi.weather are missing.

Screenshots

All those Sensors are the same and behave the same as descibed above:

Additional context

I see differences in regards to battery in /usr/share/deCONZ/devices/xiaomi/xiaomi_wsdcgq11lm_temp_hum_press_sensor.json (non-working) vs. /usr/share/deCONZ/devices/xiaomi/xiaomi_mccgq14lm_openclose_sensor.json (working). Maybe there is the culprit?

[manup]

Can anybody where the problem happens please send me the zll.db file (or Phoscon App backup) to mpi@dresden-elektronik.de. I have an assumption that the cause is a leftover in database from v2.15.x – v2.15.1 regression.

[UppyJC]

Database file sent to you as requested!

[manup]

Thanks, I had a look the database looks alright :thinking: Is Basic/Gold enabled in the control panel?

Panels → Control → Basic → Gold

[manup]

Also if Gold is already enabled, a log with following settings (incl. DDF) would be helpful Help → Debug view:

[UppyJC]

Gold is enabled - log is attached, complete with waiting for an update from the affected sensors. Still all reporting null/0 temperatures.

(Log removed because most of it was irrelevant to the issue. Oops.)

[manup]

Not quite this is mostly from the Develco Meter, and one hourly report from Xiaomi motion sensor. I'd like to check the temperature reports which look like:

16:23:49:856 00:0d:6f:00:0b:ec:8a:a9-01-0402/state/temperature expression: Item.val = Attr.val + R.item('config/offset').val --> 1587
16:23:49:867 ZCL attribute report 0x000D6F000BEC8AA9 for cluster: 0x0402, ep: 0x01, frame control: 0x08, mfcode: 0x0000 

0x0402 is the temperature cluster, the first line is how the value is processed via DDF.

[UppyJC]

Apologies!

15:34:56:941 ZCL attribute report 0x0015BC001B02243D for cluster: 0x0702, ep: 0x02, frame control: 0x18, mfcode: 0x0000 15:35:01:437 ZCL attribute report 0x00158D0007BC141E for cluster: 0x0402, ep: 0x01, frame control: 0x18, mfcode: 0x0000 15:35:01:438 00:15:8d:00:07:bc:14:1e-01-0405/state/humidity expression: Item.val = Attr.val + R.item('config/offset').val --> 4205 15:35:01:465 ZCL attribute report 0x00158D0007BC141E for cluster: 0x0405, ep: 0x01, frame control: 0x18, mfcode: 0x0000 15:35:01:467 00:15:8d:00:07:bc:14:1e-01-0403/state/pressure expression: Item.val = Attr.val + R.item('config/offset').val --> 1009 15:35:01:475 ZCL attribute report 0x00158D0007BC141E for cluster: 0x0403, ep: 0x01, frame control: 0x18, mfcode: 0x0000 15:35:01:938 ZCL attribute report 0x0015BC001B02243D for cluster: 0x0702, ep: 0x02, frame control: 0x18, mfcode: 0x0000

Sensor report included above, complete with preceding and following lines. 0x402 attribute report is received, but it doesn't appear to do anything with it.

[manup]

Thanks, yes exactly this. A classical "impossible"... for humidity and pressure it works but somehow the state/temperature isn't processed although the high level code is correct. I'm debugging with your db in my setup. Something is missing, perhaps during the load of the resources. (tomorrow I get a the sensor myself and can to some live tests)

[LeoeLeoeL]

I don't know if the problem is the latest version of Deconz. I stay with 2.15.0. Yesterday my Aqara Multi Sensor stopped to update Humidity. I re-paired again and noticed in Phoscon version changed. Before there was a date (2016 etc.) now there is 3000-0001

[LeoeLeoeL]

I don't know if I can use this thread (device is the same) but even after many re-pairs and change of battery, humidity stops to update after 30 minutes from pairing while temperature continues. For pressure I don't know; It's steady according MET reports. As written before, version 3000-0001 is strange. Is the new DDF? my other 2 Aqara sensors (motion and contact) continue to have the "date" notation for version.

[manup]

The 3000-0001 is the attribute SwBuildId from the Basic Cluster which is used by most devices, but for Xiaomi the Date Code attribute is a better choice, I'll update the DDF to use that instead.

Got myself the sensor today and start to make some tests to see where it fails, I use @UppyJC database for that, hopefully it can be reproduced.

[LeoeLeoeL]

It could be hard to find the problem. Now, after the "nth" re-pairing, it's working The peaks at the end of the graph are because I took sensor in the hand to verify if it was still working :)

[LeoeLeoeL]

Anyway , it's very strange. 3 days without problems. Maybe the sensor likes its "new" router.

[MrMarkus42]

I've got the same problem. I've upgraded today to 2.15.03 and all my Aquara-Temp sensors report "0" Degrees within Phoscon oder Home-Assistant. Hoewever tha values are transmitted:

"11:03:40:478": { "e": "changed", "id": "62", "r": "sensors", "state": { "lastupdated": "2022-05-01T09:03:39.798", "temperature": 2545 }, "t": "event", "uniqueid": "00:15:8d:00:07:55:b0:09-01-0402" } }

[MrMarkus42]

Strange: Phoscon is reporting "0" Home Assistant is reporting the correct value.

[LeoeLeoeL]

I update too but all 3 values are OK in Phoscon too. I saw the version came back as a date.

[Smanar]

Strange: Phoscon is reporting "0" Home Assistant is reporting the correct value.

Not possible, HA and phoscon use the same API and use the sames values, the problem is elsewhere.

[MrMarkus42]

The problem is solved after rebooting my Raspberry 2 times.

[peer69]

Last working version for Aquara Temp Sensors was 2.13.1 for me. With 2.14.1 Temps were still reported but battery value wasnt at all. With 2.15.3 an OSRAM Smart+ Motion Sensor shows similar behaviour and reports "0" as Battery Value.

Is there a workaround to set a "dummy" battery value to get rid of low battery warnings?

[manup]

Is there a workaround to set a "dummy" battery value to get rid of low battery warnings?

Hmm, the battery state should be reported or read after ~1 hour for the OSRAM Smart+ Sensor (modelid: Motion Sensor-A).

[peer69]

Well, in my case, it doesnt. For testing purposes I have rolled back my installation to version 2.12.6 which seems to work a lot more stable for me than recent versions. All my sensors report the battery state correctly and some erratic serial connection errors (deCONZ apparently losing connection to the Conbee II Stick and reconnecting) are gone as well. At least for my setup this is definitely caused by something introduced in newer versions of deCONZ.

[SVH-Powel]

Well, in my case, it doesnt. For testing purposes I have rolled back my installation to version 2.12.6 which seems to work a lot more stable for me than recent versions. All my sensors report the battery state correctly and some erratic serial connection errors (deCONZ apparently losing connection to the Conbee II Stick and reconnecting) are gone as well. At least for my setup this is definitely caused by something introduced in newer versions of deCONZ.

Yes, I did also roll back. I have 10 Aqara sensors and they started to fail one by one. I rolled back to previous stable version and all sensors started to work again.

[wvuyk]

@manup I have had users complaining on not updating sensor readings of these Aqara sensors. With the latest release 2.15.3 several users (but also with other issues) tell me they can resolve it on this level by going to control in deCONZ and enable Gold, Silver and Bronze en subsequently disabling DDF and re-enabling DDF. From that point on the Aqara sensors start reporting again. The same is reported for users that use Blitzwolf plugs.

Not sure, but maybe an area to look into?

[manup]

The upcoming v2.16.0-beta milestone should address this and several sensor issues when moving from legacy code paired sensor to DDF.

For the Xiaomi temperature, humidity the config/temperature where exposed and being 0, since these have a proper temperature sensor only state/temperature is exposed now with PR https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6025

[UppyJC]

Still seeing the same issue with 2.16.0, which I installed this evening. Extract from the debug log shows exactly the same behaviour for each of the climate sensors - I've pasted one below.

22:17:01:049 ZCL attribute report 0x00158D0007B893A5 for cluster: 0x0402, ep: 0x01, frame control: 0x18, mfcode: 0x0000 22:17:01:051 00:15:8d:00:07:b8:93:a5-01-0405/state/humidity expression: Item.val = Attr.val + R.item('config/offset').val --> 5052 22:17:01:087 ZCL attribute report 0x00158D0007B893A5 for cluster: 0x0405, ep: 0x01, frame control: 0x18, mfcode: 0x0000 22:17:01:090 00:15:8d:00:07:b8:93:a5-01-0403/state/pressure expression: Item.val = Attr.val + R.item('config/offset').val --> 1007 22:17:01:099 ZCL attribute report 0x00158D0007B893A5 for cluster: 0x0403, ep: 0x01, frame control: 0x18, mfcode: 0x0000

[tarasfilonenko]

Still seeing the same issue with 2.16.0, which I installed this evening. Extract from the debug log shows exactly the same behaviour for each of the climate sensors - I've pasted one below.

22:17:01:049 ZCL attribute report 0x00158D0007B893A5 for cluster: 0x0402, ep: 0x01, frame control: 0x18, mfcode: 0x0000 22:17:01:051 00:15:8d:00:07:b8:93:a5-01-0405/state/humidity expression: Item.val = Attr.val + R.item('config/offset').val --> 5052 22:17:01:087 ZCL attribute report 0x00158D0007B893A5 for cluster: 0x0405, ep: 0x01, frame control: 0x18, mfcode: 0x0000 22:17:01:090 00:15:8d:00:07:b8:93:a5-01-0403/state/pressure expression: Item.val = Attr.val + R.item('config/offset').val --> 1007 22:17:01:099 ZCL attribute report 0x00158D0007B893A5 for cluster: 0x0403, ep: 0x01, frame control: 0x18, mfcode: 0x0000

Can confirm. Same issue on 2.16.0. Removed and re-added sensor multiple times, issue persists.

[manup]

Small update, we did quite some tests with this but can't reproduce the issue. It's really weird, I also deleted the ZHATemperature sensor from sensors and sub-devices tables, and it was correctly restored based on the DDF. Another test was to set the reachable to false, but this was also correctly set after receiving a report from the sensor.

The state/temperature "can not" be null it should be set to 0 initially if not set. For example when I load the zll.db you've send me in my setup the output looks like this:

{
    "config": {
        "battery": 82,
        "offset": 0,
        "on": true,
        "reachable": false
    },
    "ep": 1,
    "etag": "6a2aa0eda71c5cb8b30afb308254f360",
    "lastannounced": null,
    "lastseen": "2022-05-23T17:25Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Cloakroom climate",
    "state": {
        "lastupdated": "none",
        "temperature": 0
    },
    "type": "ZHATemperature",
    "uniqueid": "00:15:8d:00:07:b8:93:a5-01-0402"
}

Only when I disable DDF support in config.ini (or via gui) it's:

[ddf-filter]
bronze=0
gold=0
silver=0

{
    "config": {
        "battery": 82,
        "offset": 0,
        "on": true,
        "reachable": false
    },
    "ep": 1,
    "etag": "2e9ef39d156fc9f1fab964d16ed461b3",
    "lastannounced": null,
    "lastseen": "2022-05-23T17:25Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.weather",
    "name": "Cloakroom climate",
    "state": {
        "lastupdated": "none",
        "temperature": null
    },
    "type": "ZHATemperature",
    "uniqueid": "00:15:8d:00:07:b8:93:a5-01-0402"
}

[UppyJC]

How strange! Quite an interesting issue. I've ended up turning off DDF completely and that's restored the temperature readings. I'll run with it off for now as I know the devices are supported without!

[nunoary]

I also see this issue on my system. With the DDF activated the sensors do not update the temperature values, when deactivating the DDF they work fine. The problem is when I restart deCONZ, it activates the DDF and I have to deactivate it again.

I have four WSDCGQ11LM and two WSDCGQ01LM, all have the same behaviour.

The version I'm using right now is v2.16.0-beta

[CherAlban]

I just installed v2.16.1-beta and the problem persists on all my sensors

[kimmeld]

I just installed v2.16.1 and have the same issue. Editing the relevant DDF (xiaomi_wsdcgq11lm_temp_hum_press_sensor.json) and changing it to Bronze (I changed the DDF instead of switching DDF off globally since it’s just this one type of device that isn’t working) makes it work correctly.

If another zcl.db would help I can provide it.

[MrSolo570]

I just installed v2.16.1 and have the same issue. Editing the relevant DDF (xiaomi_wsdcgq11lm_temp_hum_press_sensor.json) and changing it to Bronze (I changed the DDF instead of switching DDF off globally since it’s just this one type of device that isn’t working) makes it work correctly.

If another zcl.db would help I can provide it.

Can you explain for a noob how to make it work again? I have the same issue with one sensor

[manup]

Did another test today on a Pi3 to rule out that Qt or OS version may have an impact here, but sensor works normally and reports all values.

One thing which is different is that my sensor shows a firmware version 2016, the problematic ones appear to be newer. It would be really strange if the temperature report is different between versions but who knows..

Can anybody provide a log with APS, APS_L2 and ZCL options enabled where a message as ZCL attribute report 0x00158D0007B893A5 for cluster: 0x0402, ep: 0x01, frame control: 0x18, mfcode: 0x0000 pops up? The related APS lines would help to check if the payload format is different compared to the 2016 version.

[kimmeld]

Hey @manup,

I enabled those debugging options, but didn't get a ZCL attribute report line. I played around with the debugging options and also enabled INFO and INFO_L2 and started getting that line.

I got a report from a sensor with firmware version 20191205. deCONZ is 2.16.1 on Windows 10.

Here's what the relevant lines (I think) in the log look like:

19:01:57:907 APS-DATA.indication srcAddr: 0xcd17, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0402, lqi: 255, rssi: -29
19:01:57:908    asdu: 18550a000029710a
19:01:57:909 APS-DATA.indication from child 0xCD17
19:01:57:910 Node data 0x00158d00054c562c profileId: 0x0104, clusterId: 0x0402
19:01:57:934 0x00158D00054C562C: update ZCL value 0x01/0x0402/0x0000 after 0 s
19:01:57:934 [INFO] - No button map for: lumi.weather, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0402, command: 0x0A, payload: 000029710A, zclSeq: 85
19:01:57:935 ZCL attribute report 0x00158D00054C562C for cluster: 0x0402, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
19:01:57:935    payload: 000029710a
19:01:57:936 don't create binding for attribute reporting of sensor Office Sensor
19:01:57:936 don't create binding for attribute reporting of sensor Office Sensor
19:01:57:937 don't create binding for attribute reporting of sensor Office Sensor
19:01:57:938 Websocket 192.168.11.80:59740 send message: {"attr":{"id":"8","lastannounced":null,"lastseen":"2022-06-01T01:01Z","manufacturername":"LUMI","modelid":"lumi.weather","name":"Office Sensor","swversion":"20191205","type":"ZHAHumidity","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0405"},"e":"changed","id":"8","r":"sensors","t":"event","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0405"} (ret = 328)
19:01:57:939 Websocket 192.168.11.80:59738 send message: {"attr":{"id":"8","lastannounced":null,"lastseen":"2022-06-01T01:01Z","manufacturername":"LUMI","modelid":"lumi.weather","name":"Office Sensor","swversion":"20191205","type":"ZHAHumidity","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0405"},"e":"changed","id":"8","r":"sensors","t":"event","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0405"} (ret = 328)
19:01:57:941 Websocket 192.168.11.80:59740 send message: {"attr":{"id":"7","lastannounced":null,"lastseen":"2022-06-01T01:01Z","manufacturername":"LUMI","modelid":"lumi.weather","name":"Office Sensor","swversion":"20191205","type":"ZHATemperature","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0402"},"e":"changed","id":"7","r":"sensors","t":"event","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0402"} (ret = 331)
19:01:57:943 Websocket 192.168.11.80:59738 send message: {"attr":{"id":"7","lastannounced":null,"lastseen":"2022-06-01T01:01Z","manufacturername":"LUMI","modelid":"lumi.weather","name":"Office Sensor","swversion":"20191205","type":"ZHATemperature","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0402"},"e":"changed","id":"7","r":"sensors","t":"event","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0402"} (ret = 331)
19:01:57:944 Websocket 192.168.11.80:59740 send message: {"e":"changed","id":"7","r":"sensors","state":{"lastupdated":"2022-06-01T01:01:57.934","temperature":2673},"t":"event","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0402"} (ret = 164)
19:01:57:945 Websocket 192.168.11.80:59738 send message: {"e":"changed","id":"7","r":"sensors","state":{"lastupdated":"2022-06-01T01:01:57.934","temperature":2673},"t":"event","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0402"} (ret = 164)
19:01:57:946 Websocket 192.168.11.80:59740 send message: {"attr":{"id":"9","lastannounced":null,"lastseen":"2022-06-01T01:01Z","manufacturername":"LUMI","modelid":"lumi.weather","name":"Office Sensor","swversion":"20191205","type":"ZHAPressure","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0403"},"e":"changed","id":"9","r":"sensors","t":"event","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0403"} (ret = 328)
19:01:57:947 Websocket 192.168.11.80:59738 send message: {"attr":{"id":"9","lastannounced":null,"lastseen":"2022-06-01T01:01Z","manufacturername":"LUMI","modelid":"lumi.weather","name":"Office Sensor","swversion":"20191205","type":"ZHAPressure","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0403"},"e":"changed","id":"9","r":"sensors","t":"event","uniqueid":"00:15:8d:00:05:4c:56:2c-01-0403"} (ret = 328)

Does this help any?

[kimmeld]

Hey @MrSolo570 ,

In your deCONZ install there will be a devices directory - mine is C:\Users\ha_user\AppData\Local\deCONZ\devices, but yours will likely be different.

From here, go the xiaomi directory and open the file for your sensor (xiaomi_wsdcgq11lm_temp_hum_press_sensor.json is the one I used), then find the line that reads "status": "Gold", and change Gold to Bronze. Restart deCONZ and the sensor will now be using the old working code, not the new DDF code.

[SwoopX]

@kimmeld Yes, thanks a lot. That helps to make one step further.

@manup Apparently, something goes horribly wrong with the marked code

as this is the only place where message 19:01:57:910 Node data 0x00158d00054c562c profileId: 0x0104, clusterId: 0x0402 can be generated and this part actually shouldn't have been executed. However, a websocket event seems to have been emitted. Looks ok for me, or is is malformed?

[manup]

I just installed v2.16.1 and have the same issue. Editing the relevant DDF (xiaomi_wsdcgq11lm_temp_hum_press_sensor.json) and changing it to Bronze (I changed the DDF instead of switching DDF off globally since it’s just this one type of device that isn’t working) makes it work correctly.

@manup Apparently, something goes horribly wrong with the marked code

If the the DDF is still marked as Bronze the code is right here since the managed() wouldn't be set.

I'll check the ASDU next and compare with my sensor to see if there is anything notable.

[SwoopX]

Hm, did I misunderstand and the log was running on Bronze?

[manup]

The ZCL Frame looks ok to me:

ASDU: ZCL Frame

18 Frame Control
   0-1 global command
   2   not manufspecific
   3   direction server to client
   4   disable default response

55    Seq. no

0a    CmdID Attribute Report

0000  AttrID
29    Datatype s16

710a  Measured Value (26.73)

[manup]

Crazy idea but could it be that somehow the files like devices/generic/items/state_temperature_item.json are messed up in the problematic setups?

[UppyJC]

Mine looks ok, but not 100% sure if it's valid as I don't know what I'm looking for exactly!

[manup]

{
    "schema": "resourceitem1.schema.json",
    "id": "state/temperature",
    "datatype": "Int16",
    "access": "R",
    "public": true,
    "description": "The current temperature in °C × 100.",
    "parse": {
        "at": "0x0000",
        "cl": "0x0402",
        "ep": 0,
        "eval": "Item.val = Attr.val + R.item('config/offset').val",
        "fn": "zcl"
    },
    "default": 0
}

And there is UTF-8 in the temperature file, this shouldn't be a problem, but who knows....

In the DDF Editor the temperature item should look like this:

[UppyJC]

You're onto something...

[manup]

Hurr this looks surely wrong, also the right side with all that duplicates :thinking:

[UppyJC]

It looks very wrong! I think I might be able to see why it's doing it now. Give me a few minutes to play with my setup, and I will report back.

[manup]

Ok, I've just did a small test on my Win11 box and installed deCONZ also to use home directory, work fine here.