Closed d-litvinov closed 1 year ago
With 2.09 deconz does definitely not work at all.
I m trying to recompile. Effectively even on my version, I miss the node name, so there is something not working.
Ok, find it, you can try the last code, have replaced unix epoch.
I have the same ZigBee thermostat. Currently running on my Raspberry :
Version 2.07.00 / 15.11.2020 Firmware 26390500
The thermostat is displayed as "light" and at "sensors" - but still does not seem to work correctly - so far, as normal as I read here.
Should you manage to integrate the device correctly, will it then also be possible to set values? How long will it take until the update will be officially available? Hope it's okay that I ask these questions here.
The "sensor" one not working ? Do you have the device JSON ? The device is working, ATM I think it just have the time synchronisation problem.
Thanks for your late reply - no closing time?
The sensor is displayed under "Sensors" with 20°C - but if I click on it, only "Manufacturer, Product, Status (Unavailable) and Version (Unknown).
I have connected to the gateway via websocket, I do not receive any messages with the temperature value.
This is the only message from the device:
{ attr: { id: '5', lastseen: '2021-01-13T20:12Z', manufacturername: '_TZE200_aoclfnxz', modelid: 'TS0601', name: 'Smart plug 5', type: 'Smart plug', uniqueid: '5c:02:72:ff:fe:ae:82:ea-01' }, e: 'changed', id: '5', r: 'lights' t: 'event', uniqueid: '5c:02:72:ff:fe:ae:82:ea-01' }
Update: and i get also a Message if i change the Heatpoint
You haven't the device JSON, you are using third app ? Not possible using only Phoscon.
This websocket is from the light entry, this one is useless.
Lol, and there is no realy closing time, and soon holidays for me.
Hi @Smanar ,
I did some testing and sniffing again. The new code compiles and is working with the v2.09 thx for the effort. However, if you have received payload 0034 you are responding with 3400 instead. Secondly.. PayloadSize is never == 0, it is always two bytes (the if condition however works). So responding with a "08" before the time code is also wrong, instead the prefix must be 0000. lastly.. epoch calculation is using mode 1.
however, I was able to get it working with some changes :-)
direction must be "Client to Server" otherwise the time doesn't get accepted!
diff --git a/tuya.cpp b/tuya.cpp
index b73b479..98b0cd7 100644
--- a/tuya.cpp
+++ b/tuya.cpp
@@ -929,12 +929,13 @@ void DeRestPluginPrivate::handleTuyaClusterIndication(const deCONZ::ApsDataIndic
quint32 time_local_time = 0xFFFFFFFF; // id 0x0007 LocalTime
//quint32 time_valid_until_time = 0xFFFFFFFF; // id 0x0009 ValidUntilTime
- getTime2(&time_now, &time_zone, &time_dst_start, &time_dst_end, &time_dst_shift, &time_std_time, &time_local_time, 0);
+ getTime2(&time_now, &time_zone, &time_dst_start, &time_dst_end, &time_dst_shift, &time_std_time, &time_local_time, 1);
QByteArray data;
//Always 8 (size)
- data.append(0x08);
+ data.append((qint8) (0));
+ data.append((qint8) (0));
// Add UTC time
data.append((qint8)((time_now >> 24) & 0xff));
@@ -968,8 +969,9 @@ void DeRestPluginPrivate::handleTuyaClusterIndication(const deCONZ::ApsDataIndic
QByteArray data;
//Add the "magic vlaue"
- data.append((qint8)((payloadSize >> 8) & 0xff));
- data.append((qint8)(payloadSize & 0xff));
+ data.append((qint8) (0));
+ data.append((qint8)((payloadSize >> 8) & 0xff));
+ //data.append((qint8)(payloadSize & 0xff));
// Add UTC time
data.append((qint8)((time_now >> 24) & 0xff));
@@ -1145,7 +1147,7 @@ bool DeRestPluginPrivate::SendTuyaCommand( const deCONZ::ApsDataIndication &ind,
task.zclFrame.setSequenceNumber(zclSeq++);
task.zclFrame.setCommandId(command); // Command
task.zclFrame.setFrameControl(deCONZ::ZclFCClusterCommand |
- deCONZ::ZclFCDirectionServerToClient |
+ deCONZ::ZclFCDirectionClientToServer |
deCONZ::ZclFCDisableDefaultResponse);
// payload
@@ -1178,4 +1180,4 @@ bool DeRestPluginPrivate::SendTuyaCommand( const deCONZ::ApsDataIndication &ind,
processTasks();
return true;
-}
\ No newline at end of file
+} ```
Thank you very much for your answer.
Sorry that I have to ask another stupid question: I can not use the thermostat via websocket connection (e.g. set temperature)?
How does HomeAssistant work then, for example?
So far all my devices (window sensor, temperature sensor, socket switch) have sent their values happily. Had hoped so I could use the thermostat also.
edit: tried the device with home-assistant but also not working :-( after resetup my raspberry the device isn't even found as "Sensor" anymore
@k3mpaxl
direction must be "Client to Server" otherwise the time doesn't get accepted!
Realy nice catch, I haven't see this bug, and I think will never see it. I Think I will check it in other issue I have for tuya device.
I have started to correct the code but the part PayloadSize is never == 0
is not for you, it s for other device, that don't work like yours (I think they exist or zigbee2mqtt is totaly wrong).
Your device will use the part else {}
And in this part epoch is mode 1
If your device reach the first part there is another problem.
And I don't understand why you need data.append((qint8) (0));
in the magic number ? On your log the answer is for exemple
000b 5ffb12aa 5ffb20ba
Just reversing is not enought ?
data.append((qint8)((payloadSize >> 8) & 0xff));
data.append((qint8)(payloadSize & 0xff));
Replaced by
data.append((qint8)(payloadSize & 0xff));
data.append((qint8)((payloadSize >> 8) & 0xff));
@SChristophS The device send information trought the websocket, and you use the API to send it command, like the setpoint.
Try to include it 2 time, without deleting it. If you realy can't, can you show me the manufacture name of the device ? (visible in log, in HA, in deconz GUI)
@k3mpaxl
direction must be "Client to Server" otherwise the time doesn't get accepted!
Realy nice catch, I haven't see this bug, and I think will never see it. I Think I will check it in other issue I have for tuya device.
I have started to correct the code but the part
PayloadSize is never == 0
is not for you, it s for other device, that don't work like yours (I think they exist or zigbee2mqtt is totaly wrong). Your device will use the partelse {}
And in this part epoch is mode 1If your device reach the first part there is another problem.
And I don't understand why you need
data.append((qint8) (0));
in the magic number ? On your log the answer is for exemple000b 5ffb12aa 5ffb20ba
Just reversing is not enought ?
data.append((qint8)((payloadSize >> 8) & 0xff)); data.append((qint8)(payloadSize & 0xff));
Replaced by
data.append((qint8)(payloadSize & 0xff)); data.append((qint8)((payloadSize >> 8) & 0xff));
I would suggest, that you build one routine that takes the payload the client sends and use this as prefix for the response. That will cover all devices with different client payloads. I‘ve got multiple tuya devices here, however not one is using the „08“ prefix. Zigbee2mqtt is wrong I‘d think and they accidentally had luck with 08 once...
Regarding the if payloadSize == 0 condition: The zigbee radiator thermostats I have send 0000 as payload. This payload is true for payloadSize == 0 and the responses i have sniffed we’re definitely wrong! 08 was prefixed to the year2000 epoch, but it has to be 0000 and the Linux epoch. Since I‘ve patched and recompiled the code as mentioned in my previous post, all devices have the correct time and they don‘t spam the gateway with requests that often any more. With a non-working time sync, the devices asked almost every 20 seconds.. now its about every 4 hours.
Btw.. in deconz 2.09 the thermostats aren’t displayed anymore.. i can only see them in the api / iobroker.
EDIT: the reversed order should work..
> data.append((qint8)(payloadSize & 0xff));
> data.append((qint8)((payloadSize >> 8) & 0xff));
I would suggest, that you build one routine that takes the payload the client sends and use this as prefix for the response. That will cover all devices with different client payloads. I‘ve got multiple tuya devices here, however not one is using the „08“ prefix. Zigbee2mqtt is wrong I‘d think and they accidentally had luck with 08 once...
It's that I m doing. If payloadSize (need to change the variable name) is not 0, I m adding it as "magic value". If this one is 0x0000, I using 0x0008 instead. So if noone of your device use the prefix 0x0000, noone of them will use this part ? Or you have device using payloadSize == 0x0000 and that need to use it too for response ?
Regarding the if payloadSize == 0 condition: The zigbee radiator thermostats I have send 0000 as payload. This payload is true for payloadSize == 0 and the responses i have sniffed we’re definitely wrong! 08 was prefixed to the year2000 epoch, but it has to be 0000 and the Linux epoch. Since I‘ve patched and recompiled the code as mentioned in my previous post, all devices have the correct time and they don‘t spam the gateway with requests that often any more. With a non-working time sync, the devices asked almost every 20 seconds.. now its about every 4 hours.
Ha ok, so you mean for both method ( the one with 0x0000 > 0x0008 and 0x000X > 0x000X) we need to use the Unix epoch ? Can explain lot of think ....
Thanks for the feedback.
With repeated sensor searches it finally worked.
Unfortunately, the Device in HomeAssistant doesn't work 100% correctly either - even though it's on (I hear the relay clicking and the display on the device also says heat) it shows "Aus/Off".
But I still wonder why I can't see the current temperature via WebSocket message - is it not forwarded? I don't understand why HomeAssistant (apparently also via websocket?) can communicate with Phoscon but I can't?
But I still wonder why I can't see the current temperature via WebSocket message - is it not forwarded?
But you are seing it no ? What is 19.5 ? Phoscon don't support all devices. For the "Aus/Off", I haven't the device, but I think it s the "mode"/"preset" problem, this device is not a TRV, so it probably don't have "mode".
But you are seing it no ? What is 19.5 ? Only in HomeAutomation - but not if i monitor the WebSocket-Connection in my nodeJS Script using
ws_ZigBee.on('message', function message(data, flags) {});
For the "Aus/Off", I haven't the device, but I think it s the "mode"/"preset" problem, this device is not a TRV, so it probably don't have "mode".
Okay :-( Thanks for the info
If you have it in HA, you need to have it in nodeJS Too, deconz use the same websocket for all clients connected to it.
@k3mpaxl
The zigbee radiator thermostats I have send 0000 as payload. This payload is true for payloadSize == 0 and the responses i have sniffed we’re definitely wrong! 08 was prefixed to the year2000 epoch, but it has to be 0000 and the Linux epoch.
Can you confirm me, you have device that use payload = 0x0000 that need to use "magic value" (To be sure the 0x0008 value is nor working for them). So if they use 0x0000,I need to send 0x0000 then the unix epoch ?
Have modified the code to use Unix epoch for all.
With repeated sensor searches it finally worked.
Did you use Tuya Convert to install Tasmota on it or do you use the stock firmware? In which mode the sensor has to be? The flashing display showing a Wifi Symbol or showing a leaf symbol?
With repeated sensor searches it finally worked.
Did you use Tuya Convert to install Tasmota on it or do you use the stock firmware? In which mode the sensor has to be? The flashing display showing a Wifi Symbol or showing a leaf symbol?
Hi @Amiga4000,
there are devices that support WiFi and the other ones support zigbee. There isn't a version available that supports both (as far as I know). The WiFi version can be converted with "Tuya Convert" (see more info here: https://github.com/klausahrenberg/WThermostatBeca ) and then the china cloud features are removed. The zigbee thermostats that I use still have stock firmware and are integrated into my zigbee network. As some features are not integrated yet Smanar and I are currently focussing on the time sync feature.
The WiFi Symbol is not visible on the zigbee thermostats during normal operation. - only during the pairing. The leaf symbol hasen't appeared on my devices so far..
Hope my answers help.
@Smanar : I'm testing the time sync responses with 08 now..
@k3mpaxl
The zigbee radiator thermostats I have send 0000 as payload. This payload is true for payloadSize == 0 and the responses i have sniffed we’re definitely wrong! 08 was prefixed to the year2000 epoch, but it has to be 0000 and the Linux epoch.
Can you confirm me, you have device that use payload = 0x0000 that need to use "magic value" (To be sure the 0x0008 value is nor working for them). So if they use 0x0000,I need to send 0x0000 then the unix epoch ?
Have modified the code to use Unix epoch for all.
Hi @Smanar , I've tested your code from tuyaspecial branch and it looks good. Time Sync is working fine. Time sync requests with 0000 didn't occor today very often, these HY368 devices have changed their initial 0000 payload for 0003 today. After re-joining a new device it asks with payload 0000 once, but the response with 08 prefix causes the device to re-request the time with a different payload. Once the different payload was chosen, your code will send the time with the correct payload prefix and the device accepts it.
21:19:53:580 Tuya debug 4 : Address 0x60A423FFFE9F5B7C , Command 0x24, Payload 0000
21:19:53:581 Tuya debug 1 : Time sync Request21:19:53:581 Send Tuya Command 0x24 Data: 000860049be96004a9f9
21:19:56:663 Tuya debug 4 : Address 0x60A423FFFE9F5B7C , Command 0x24, Payload 0010
21:19:56:664 Tuya debug 1 : Time sync Request21:19:56:664 Send Tuya Command 0x24 Data: 001060049bec6004a9fc
My personal opinion here is: hardcoding 0008 or 08 as prefix is a mistake from zigbee2mqtt and can be removed.
@Smanar
A new task for you to increase compatibility with tuya: If a device sends command 0x01, could you implement a success message pls? That will increase battery life for battery powered tuya devices.
It is only a success message, shouldn't be difficult?
Here are some screenshots:
After re-joining a new device it asks with payload 0000 once, but the response with 08 prefix causes the device to re-request the time with a different payload
Realy strange ^^, something to explore here. But right I will totally remove the part with payload = 0x0000, will see what will happen if the payload have 0x0000 for the answer too.
For the succed message, it s already in code too, strange it s not working, perhaps have a mistake somewhere https://github.com/Smanar/deconz-rest-plugin/blob/tuyaspecial/tuya.cpp#L179 You haven't it on your sniff and using this branch ?
The WiFi version can be converted with "Tuya Convert" (see more info here: https://github.com/klausahrenberg/WThermostatBeca ) and then the china cloud features are removed.
Thanks for the link! I'll try to sell my zigbee device and buy this one!
The WiFi version can be converted with "Tuya Convert" (see more info here: https://github.com/klausahrenberg/WThermostatBeca ) and then the china cloud features are removed.
Thanks for the link! I'll try to sell my zigbee device and buy this one!
I think newer devices can't be flashed any more without soldering some wires. Sorry, tuya Convert is not working at the moment.
@Smanar anything to sniff or test? :-) When will it be pushed/merged to main repo?
Yeah just ATM ^^ I have updated the PR https://github.com/dresden-elektronik/deconz-rest-plugin/pull/4087 with the time synchronisation correction.
But lot of changes, can have broken something.
git clone https://github.com/KPWhiver/deconz-rest-plugin.git
not particulary deconz-integration question, rather device related: I'm experiencing 2 issues with the thermostat:
Has somebody had such issues and resolved them?
For 1 it s exactly for that the PR is done, time synchronisation. For 2 it s perhaps hardware ? The sensor is probably not made to mesure air temperature ? But this PR correct too some missing request for tuya (like temperature)
Yeah just ATM ^^ I have updated the PR #4087 with the time synchronisation correction.
But lot of changes, can have broken something.
git clone https://github.com/KPWhiver/deconz-rest-plugin.git
I'm testing the code with deconz version 2.09.01. Compiled without issues and it started fine... I'll give feedback regarding time sync after 24 hours of testing.
k3mpaxl
Time synchronization is working fine since your last change on PR #4087 . Right now, I looked into the API and found that the "lastupdated" field doesn't get updated - is this correct? All other sensors have lastupdated refreshed regularly.
How ALL tuya devices look like:
How HUE devices look like:
Yep it's "normal", this correction will be in the PR for the tuya siren, I m waiting for manup validate the first one first, to avoid conflict. I will ask him some news.
Nice reverse engineering, thanks for your work, hope to see it soon in officiall Version supported.
2. I've connected the thermostat instead of non-smart one (DEVIreg Opti), leaving existing temp sensor connected. Moes\Tuya thermostat shows improper current temp (e.g. it raised from 19 to 20 degrees during 1 hour of work, while floor has heated significantly).
I found out that I have installed existing NTC temp sensor to be 15kOhm, while Tuya is bundled and requires NTC 10kOhm. I'm hesitant to pull old sensor, doubting that will succeed in pushing new one via tube under the floor. Found one hardware method to change expected resistance. Is there a possibility to re-program Thermostat to work with 15kOhm one (i.e. remap resistance-temp values just in software)?
P.S. also found out that with connected improper NTC sensor, thermostat seems not to recognise it at all and thus disregards its readings completely. So that shown temp (and above mentioned in the quote increase from 19 to 20 degrees celsius - represents temp read from another sensor placed within thermostat itself. I blow with the hairdryer to the vent holes from below - and temp increased momentarily.
@Smanar
I'm hoping you or someone can help. I've successfully paired this in Deconz. It shows up in Home Assistant fine... However, when I use automation to turn it on (when Living Room Temp is less than target Temp) although the automation kicks in, it doesnt turn the boiler on. To be clear, it DOES change the boiler to "heat" but this doesnt seem to be actually turning the boiler on. Essentially, I just need this to act as an on/off switch for the boiler, my automations do the rest. My current code is below, and I'm telling it to turn mode to "heat" or "off" but I'm just wondering should I be using something else?
action:
or
action:
Ok so i can be wrong, (lot of tuya stuff) But from that I have read on this issue
Mode = auto > don't work Mode = on > enable the display Mode = off > disable the display
You need to use "preset" field, from the code can work with
if (data == 0) { preset = QLatin1String("holiday"); }
else if (data == 1) { preset = QLatin1String("auto"); }
else if (data == 2) { preset = QLatin1String("manual"); }
else if (data == 3) { preset = QLatin1String("comfort"); }
else if (data == 4) { preset = QLatin1String("eco"); }
else if (data == 5) { preset = QLatin1String("boost"); }
else if (data == 6) { preset = QLatin1String("complex"); }
So try with "boost" ?
I noticed that thermostat by default uses air temp in the room (sensor from below thermostat's control panel), and to read under-floor NTC sensor value one needs to hold "Temp down" button for 5 sec. I couldn't find any temp values inside deConz, and HomeAssistant shows default air value for the Climate entity. How can I change actual temp value to the NTC sensor's one? (I'm interested in heating the cold ceramic tiles themselves, not the whole room's air)
@Shurov if you can see the value on the device, can you try to catch the command using logging ? You need to see something like
11:40:03:323 Tuya debug 4 : Address 0x60A423FFFE9F4FA7 Payload 06c1100200040000000e
11:40:03:323 Tuya debug 5 : Status: X Transid: XXX Dp: XXX (0xXX,0xXX) Fn: 0 Data 14
with the temperature value as data (can be 10 or 100)
@Smanar, there are lots of such duplicated lines (~100 blocks of 2 lines that you've mentioned) each 2 minutes. But those 100 blocks consist of 2 different types (so ~50 blocks of each type):
14:04:45:162 Tuya debug 4 : Address 0x5C0272FFFED75152 Payload 025b100200040000000e
14:04:45:200 Tuya debug 5 : Status: 2 Transid: 91 Dp: 528 (0x02,0x10) Fn: 0 Data 14
14:04:45:200 Tuya debug 4 : Address 0x5C0272FFFED75152 Payload 025e2404000101
14:04:45:236 Tuya debug 5 : Status: 2 Transid: 94 Dp: 1060 (0x04,0x24) Fn: 0 Data 1
14:04:50:304 [INFO] - No button map for: TS0121, unicast to: 0x0000, endpoint: 0x01, cluster: BASIC (0x0000), command: 0x0A, payload: 01002040E2FF201E, zclSeq: 99
14:04:50:305 ZCL attribute report 0x842E14FFFEF25A26 for cluster: 0x0000, ep: 0x01, frame control: 0x18, mfcode: 0x0000 ```
14:04:45:200 Tuya debug 5 : Status: 2 Transid: 91 Dp: 528 (0x02,0x10) Fn: 0 Data 14
This one is a setpoint on a moe device, the value need to be *2 so the temperature can be 28°C ?
14:04:45:236 Tuya debug 5 : Status: 2 Transid: 94 Dp: 1060 (0x04,0x24) Fn: 0 Data 1
The type 0x04 is enum type, so it's to select a mode for exemple, can't be a temperature
I could try sniffing the packets next week. The original app supports a selection of sensors.
Ok so i can be wrong, (lot of tuya stuff) But from that I have read on this issue
Mode = auto > don't work Mode = on > enable the display Mode = off > disable the display
You need to use "preset" field, from the code can work with
if (data == 0) { preset = QLatin1String("holiday"); } else if (data == 1) { preset = QLatin1String("auto"); } else if (data == 2) { preset = QLatin1String("manual"); } else if (data == 3) { preset = QLatin1String("comfort"); } else if (data == 4) { preset = QLatin1String("eco"); } else if (data == 5) { preset = QLatin1String("boost"); } else if (data == 6) { preset = QLatin1String("complex"); }
So try with "boost" ?
Thank you for this - that's really interesting. So if I am trying to turn the Boiler on I can see that I'd probably use the "boost" preset. If I am trying to turn if off I would use Holiday? Also, any idea what the command for that would be in Home Assistant? At the moment I'm using
Good question, but i realy don't remember.
Mode = off > disable the display
It don't disable the working mode too ?
Else you can turn off manually the device and check log with "info", you will see the command used by the device.
Good question, but i realy don't remember.
Mode = off > disable the display
It don't disable the working mode too ?
Else you can turn off manually the device and check log with "info", you will see the command used by the device.
Do you mean use the "listen to events" thing and listen to deconz? Then if I turn the boiler on manually it will tell me what command happens to turn it on or off?
Depend if you have the GUI or not, on the GUI go on deconz/help/log with "info" enabled, you can too have them using logging on third app. If you set the command manualy on the device you will see in deconz log like this
11:40:03:323 Tuya debug 4 : Address 0x60A423FFFE9F4FA7 Payload 06c1100200040000000e
11:40:03:323 Tuya debug 5 : Status: 6 Transid: 193 Dp: 528 (0x02,0x10) Fn: 0 Data 14
It will be the command used by the device, I m able to find them in the code. But I think mode = off can work to disable it.
Hello, for users that have this device (and the last deconz version) How is working mode and preset for you ?
It seem there is some strange reaction:
1 - mode = off 2 - mode = heat 3 - preset = program > the preset go to "program" then to "auto" 4 - mode = off > the preset return to "program"
Its s same for you ?
Hi, I've just purchased this thermostat and testing it. As @Shurov mentioned it's probably set by default to internal temperature sensor instead of NTC. There should be some configuration like it's also in z2m copying code here for further reference:
moes_thermostat_sensor: {
key: ['sensor'],
convertSet: async (entity, key, value, meta) => {
if (typeof value === 'string') {
value = value.toLowerCase();
const lookup = {'in': 0, 'al': 1, 'ou': 2};
utils.validateValue(value, Object.keys(lookup));
value = lookup[value];
}
if ((typeof value === 'number') && (value >= 0) && (value <= 2)) {
await tuya.sendDataPointEnum(entity, tuya.dataPoints.moesSensor, value);
} else {
throw new Error(`Unsupported value: ${value}`);
}
},
},
there is quite difference between measured temperature by thermostat and actual temperature in room...do we know if we can set the temperature difference/offset?
@Smanar I don't see any preset inside HA. However if I change mode to head it goes to off automatically.
this is what I see in HA
If there is something what I can help with, just let me know.
Ha yes, but I don't found information about this feature on z2m page https://www.zigbee2mqtt.io/devices/BHT-002-GCLZB.html Do you know how work the "sensor" command ? I see there is 3 mode, but I don't know the impact on the Thermostat.
And BTW I remember issues on this device https://easydomoticz.com/forum/viewtopic.php?f=15&t=11833&start=50
Have made a code change, but don't find someone to test it. If you can on your side ? need someone with the device and a Linux machine with full/real OS
The code change was because you can send preset to the device, the device have good reaction, but return can be bad.
@Smanar sorry for delay I was off for a few days. Regarding sensor, I can't find any info in zigbee thermostat documentation however in wifi docs there is following information (code 4):
I will try to reach out to moes support but that could take some time. Would you be able to prepare something like above and I will test it?
I can even test other features (have linux and mac computers and also HA installed on intel nuc) if you give me an instructions.
EDIT even on their page they mention it in point 5.
The page was translated by "google translate" on my side, difficult to understand ^^. But it s just say there is mode IN/AL/OU but not the difference, It's like you can use a sensor on the room and connect it to this thermostat, but how ....
It seem this device have a temperature compensation AND dead zone, and I think the code use "offset" for the dead zone, so the first one is not used.
I can edit code to use the "offset" for the temperature compensation (I don't think there is user that use the dead zone ATM) I can too make a corrective to test for the "mode change" But ATM https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5733
So will be only for you, time the code will be unlocked again, and yes, if you want to make a try I will provide all command lines if you are on a real/complete OS.
Device
Screenshots
deconz version 2.05.81