dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 498 forks source link

MoesGo (Tuya) Smart Thermostat BRT-100 #5153

Closed alinfulgusin closed 2 years ago

alinfulgusin commented 3 years ago

Device

Screenshots

https://zigbee.blakadder.com/Beca_BRT-100.html https://www.amazon.de/-/en/Thermostat-Operated-Radiator-Regulator-Compatible/dp/B0972YM58R/ref=sr_1_5?dchild=1&keywords=heizk%C3%B6rperthermostat+moesgo&qid=1626946864&sr=8-5

Basic

Identify

Alarms

Device Temperature

Groups

Scenes

On/Off

Level Control

Color Control

Simple Metering

Diagnostics

Other clusters that are not mentioned above

EmJay276 commented 2 years ago

Hi, I've read the issue but it's not clear to me now if the device is already working? Is there already support for the BRT-100 thermostat in the stable version or a beta?

Smanar commented 2 years ago

The code is still on test, to use it https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5153#issuecomment-886041215

EmJay276 commented 2 years ago

Thanks @Smanar I didn't notice the trv41 branch in your fork! I've ordered several BRT-100, I will test it next week when i got them.

EmJay276 commented 2 years ago

I got my Thermostats (T) today and was able to build a docker image from your branch für my unraid server the conbee 2 stick is connected to.

The current temperature ("temperature": 2200,) is shown and updated correctly in all three instances T <-> Phoscon <-> HA Temperature should be "17:13:43:423 Tuya debug 5 : Status: 1 Transid: 19 Dp: 515 (0x02,0x03) Fn: 0 Data 220" => is 22°C

The current mode is not shown in Phoscon or HA, the states changes are

Temperature setting is not working: (0x02,0x02) 17:16:44:222 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 0126020200040000001a 17:16:44:222 Tuya debug 5 : Status: 1 Transid: 38 Dp: 514 (0x02,0x02) Fn: 0 Data 26 => 26°C But half degrees set on the thermostat are not recognized in the log! 26°C => Data 26 26.5°C => Data 26

Battery is propably: (0x02,0x0E) 17:17:58:813 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 012e0e02000400000064 17:17:58:813 Tuya debug 5 : Status: 1 Transid: 46 Dp: 526 (0x02,0x0E) Fn: 0 Data 100 => 100%

The valve setting does not change in the Phoscon REST Api, stays ("valve": 5) all time for me. So I have no idea what the valve setting is, in the log nothing changed when the valve moved.

Smanar commented 2 years ago

The current mode is not shown in Phoscon or HA, the states changes are

Corrected, was using 0x02 0x01 instead of 0x04 0x01 but on the code it s "preset" and not "mode".

But half degrees set on the thermostat are not recognized in the log

For here, we can do nothing the tuya request only use full value.

The code already use 0x02 0x0E for battery, it s not working ? it's config/battery.

So I have no idea what the valve setting is, in the log nothing changed when the valve moved.

Yes, I m not finding information for it too, on the code you are using ATM, the "valve" is automatically added on device that use "preset", even if the device don't use it.

To test "preset"

cd deconz-rest-plugin
git pull
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins
EmJay276 commented 2 years ago

I did some more testing, tried to trigger the window open icon (no luck, even in the fridge) Here is what I came up with:

0x00,0x65 ??? Had it just once 18:07:00:125 Tuya : Schedule command 18:07:00:125 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 01d4650000240600280b1e2a0d1e2c111e2e0600300c002e0e1e2c111e2a0600260c1e280e1e2a121e28 18:07:00:125 Tuya debug 5 : Status: 1 Transid: 212 Dp: 101 (0x00,0x65) Fn: 0 Data 0 18:07:00:125 Tuya : Schedule data error

0x01,0x04 boost enabled true/false Data 0 - false Data 1 - true

0x01,0x0D Key lock Data 0 => false Data 1 => true

0x02,0x02 Temperature setting Data 24 => 24°C and 24.5°C

0x02,0x03 Current temperature Data 200 => 20°C

0x02,0x05 Boost heating Data 5, 4, 0 If not activated 0, if just activated 5, then immediately 4 => Minutes left ?

0x02,0x0E Battery(?) Data 100 - all the time

0x02,0x68 Probably valve opening state (state to set I think, its reported just before it moves) 0 => closed 100 => completely open Data 0, 25, 50, 75, 100

0x04,0x01 Heating mode Data 0 => Programmed mode Data 3 => Holiday mode Data 1 => Manual mode

0x04,0x07 Valve symbol Data 0, 1 Data 0: symbol shown => valve open (all states slightly to all the way) Data 1: symbol not shown => valve closed

0x04,0x09 ??? Data 1 - all the time

One of the ??? could be the 6 in a circle symbol turned on (=> its Saturday) and one the "room temperature" symbol shown.

EmJay276 commented 2 years ago

The current mode is not shown in Phoscon or HA, the states changes are

Corrected, was using 0x02 0x01 instead of 0x04 0x01 but on the code it s "preset" and not "mode".

I will check and let you know later today

But half degrees set on the thermostat are not recognized in the log

For here, we can do nothing the tuya request only use full value.

(y)

The code already use 0x02 0x0E for battery, it s not working ? it's config/battery.

Its working, sry didn't see it in the HA (y)

So I have no idea what the valve setting is, in the log nothing changed when the valve moved.

Yes, I m not finding information for it too, on the code you are using ATM, the "valve" is automatically added on device that use "preset", even if the device don't use it.

See my last comment, I've found the value for the valve setting and the valve for the symbol showing (perhaps usable for heating?)

EmJay276 commented 2 years ago

Update to 0x01,0x04:

Seems like I could trigger it in the fridge (temp <15-16°C?), but not sure. perhaps the windows open "sensor"?

18:34:59:711 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 02990401000101 18:34:59:711 Tuya debug 5 : Status: 2 Transid: 153 Dp: 260 (0x01,0x04) Fn: 0 Data 1

EmJay276 commented 2 years ago

The current mode is not shown in Phoscon or HA, the states changes are

Corrected, was using 0x02 0x01 instead of 0x04 0x01 but on the code it s "preset" and not "mode".

But half degrees set on the thermostat are not recognized in the log

For here, we can do nothing the tuya request only use full value.

The code already use 0x02 0x0E for battery, it s not working ? it's config/battery.

So I have no idea what the valve setting is, in the log nothing changed when the valve moved.

Yes, I m not finding information for it too, on the code you are using ATM, the "valve" is automatically added on device that use "preset", even if the device don't use it.

To test "preset"

cd deconz-rest-plugin
git pull
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

Preset is used correctly now, It's read and wrote correctly for "auto", "holiday" and "manual", but I have several other modes in HA which could obviously not be set.

grafik

I will dig a bit in the HA manual to find what we should use.

EmJay276 commented 2 years ago

For here, we can do nothing the tuya request only use full value.

Sry didn't make clear the temperature setting isn't working at all. The targeted temperature isn't read correctly nor send to the thermostat.

Smanar commented 2 years ago

It's because HA use a general preset, it can't use a different preset by device, even deconz don't know workng and not working command.

But the only ones programmed for this device are

                            if (data == 0) { preset = QLatin1String("auto"); } //programming
                            else if (data == 1) { preset = QLatin1String("manual"); } //manual
                            else if (data == 2) { preset = QLatin1String("temporary_manual"); } //temporary_manual
                            else if (data == 3) { preset = QLatin1String("holiday"); } //holiday

0x00,0x65

This a schedule command, I m on it for another device, not enought time for the moment.

For the 0x01,0x04 the 0x01 mean it s a bool command, so it's a on/off or a true/false But don't found what is it ...

0x02,0x68

Probably valve opening state (state to set I think, its reported just before it moves)

Exactly, have added it.

Sry didn't make clear the temperature setting isn't working at all. The targeted temperature isn't read correctly nor send to the thermostat.

Corrected, was using (0x02,0x67) instead of (0x02,0x02)

Can try the new version.

Edit : 0x01 0x04 is the boost enabled true/false

EmJay276 commented 2 years ago

Edit : 0x01 0x04 is the boost enabled true/false

Checked it, confirmed

EmJay276 commented 2 years ago

Sry didn't make clear the temperature setting isn't working at all. The targeted temperature isn't read correctly nor send to the thermostat.

Corrected, was using (0x02,0x67) instead of (0x02,0x02)

There is a conversion problem (seems like factor 10 in the log) Set on T => No change in HA

Set in HA => Result on T HA 15.5 => T 27 HA 15 => T 22 HA 14.5 => T 17 (it sends Data 145)

Edit: Conversion problem fixed in my fork / pull request https://github.com/Smanar/deconz-rest-plugin/pull/103

Smanar commented 2 years ago

So the only missing feature is the boost. I can use config/mode = "heat" to trigger the boost, but to turn it off , you will neeed to use config/mode = off or auto ?

EmJay276 commented 2 years ago

So the only missing feature is the boost. I can use config/mode = "heat" to trigger the boost, but to turn it off , you will neeed to use config/mode = off or auto ?

Using the "heat" button to tricker the boost seems meaningfull, but I wasn't able to stop the boost by setting a new temperature or changing the mode. If I "press" any button on the device it automatically stops the boost mode.

acitvate boost: 15:03:28:483 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00910401000101 15:03:28:483 Tuya debug 5 : Status: 0 Transid: 145 Dp: 260 (0x01,0x04) Fn: 0 Data 1 press any other button 15:03:52:460 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00910401000100 15:03:52:461 Tuya debug 5 : Status: 0 Transid: 145 Dp: 260 (0x01,0x04) Fn: 0 Data 0 15:03:52:528 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00920502000400000000 15:03:52:528 Tuya debug 5 : Status: 0 Transid: 146 Dp: 517 (0x02,0x05) Fn: 0 Data 0 15:03:52:460 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00910401000100 15:03:52:461 Tuya debug 5 : Status: 0 Transid: 145 Dp: 260 (0x01,0x04) Fn: 0 Data 0 15:03:52:528 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00920502000400000000 15:03:52:528 Tuya debug 5 : Status: 0 Transid: 146 Dp: 517 (0x02,0x05) Fn: 0 Data 0

Is there any way to send a PUT(?) request to the device by the console I have? Would be way easier if I can figure out what to do and you implement it (sry I'm a C++ noob^^)

Perhaps sending (0x02,0x05) Fn: 0 Data 0 => 0 time boost remaining would be a solution.

Smanar commented 2 years ago

I think

Status: 0 Transid: 145 Dp: 260 (0x01,0x04) Fn: 0 Data 1

Enable the boost, and

Status: 0 Transid: 145 Dp: 260 (0x01,0x04) Fn: 0 Data 0

Disable it

But If I use the "heat" to start the boost, wich one you want to disable it ? "off" or "auto", I think "auto" will be the more logic ?

EmJay276 commented 2 years ago

I think "off" is more logic, the "auto" mode is the internally programmed mode on the thermostat with its different temperatures depending on the day and time. I think this "auto" mode programming can not be changed by HA, right?

I want to automate the setting on the Thermostat via HA and external temp sensors, so my Thermostats need to be probably always in manual mode.

grafik

EmJay276 commented 2 years ago

Perhaps it would be most logic if "boost" will be just another preset for HA? Then the "mode" would be preserved after ending the boost (same would be the case for "off")

I'm not sure if the thermostat can be turned "off" without lowering the temperature, therefore the "off" button in HA could be used to stop boosting.

EmJay276 commented 2 years ago

If you stop boosting by the "+" or "-" button on the device, the preset is not again broadcasted.

Boosting: 17:11:19:995 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b90401000101 17:11:19:996 Tuya debug 5 : Status: 0 Transid: 185 Dp: 260 (0x01,0x04) Fn: 0 Data 1 17:11:20:111 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00ba0502000400000005 17:11:20:112 Tuya debug 5 : Status: 0 Transid: 186 Dp: 517 (0x02,0x05) Fn: 0 Data 5 17:11:20:268 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00bb6802000400000064 17:11:20:269 Tuya debug 5 : Status: 0 Transid: 187 Dp: 616 (0x02,0x68) Fn: 0 Data 100 17:11:19:995 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b90401000101 17:11:19:996 Tuya debug 5 : Status: 0 Transid: 185 Dp: 260 (0x01,0x04) Fn: 0 Data 1 17:11:20:111 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00ba0502000400000005 17:11:20:112 Tuya debug 5 : Status: 0 Transid: 186 Dp: 517 (0x02,0x05) Fn: 0 Data 5 17:11:20:268 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00bb6802000400000064 17:11:20:269 Tuya debug 5 : Status: 0 Transid: 187 Dp: 616 (0x02,0x68) Fn: 0 Data 100 17:11:21:346 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00bb0202000400000013 17:11:21:346 Tuya debug 5 : Status: 0 Transid: 187 Dp: 514 (0x02,0x02) Fn: 0 Data 19 17:11:21:465 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00bc0502000400000005 17:11:21:466 Tuya debug 5 : Status: 0 Transid: 188 Dp: 517 (0x02,0x05) Fn: 0 Data 5 17:11:21:580 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00bd0e02000400000061 17:11:21:580 Tuya debug 5 : Status: 0 Transid: 189 Dp: 526 (0x02,0x0E) Fn: 0 Data 97 17:11:21:700 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00be0904000101 17:11:21:700 Tuya debug 5 : Status: 0 Transid: 190 Dp: 1033 (0x04,0x09) Fn: 0 Data 1 17:11:21:819 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00bf0401000101 17:11:21:820 Tuya debug 5 : Status: 0 Transid: 191 Dp: 260 (0x01,0x04) Fn: 0 Data 1 Press "-" or "+" 17:11:35:054 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00bf0401000100 17:11:35:054 Tuya debug 5 : Status: 0 Transid: 191 Dp: 260 (0x01,0x04) Fn: 0 Data 0 17:11:35:124 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00c00502000400000000 17:11:35:124 Tuya debug 5 : Status: 0 Transid: 192 Dp: 517 (0x02,0x05) Fn: 0 Data 0 17:11:37:825 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00c00202000400000013 17:11:37:825 Tuya debug 5 : Status: 0 Transid: 192 Dp: 514 (0x02,0x02) Fn: 0 Data 19 17:11:37:941 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00c10502000400000000 17:11:37:941 Tuya debug 5 : Status: 0 Transid: 193 Dp: 517 (0x02,0x05) Fn: 0 Data 0 17:11:38:062 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00c20e02000400000064 17:11:38:062 Tuya debug 5 : Status: 0 Transid: 194 Dp: 526 (0x02,0x0E) Fn: 0 Data 100 17:11:39:784 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00c26802000400000000 17:11:39:784 Tuya debug 5 : Status: 0 Transid: 194 Dp: 616 (0x02,0x68) Fn: 0 Data 0

If the "home"/"mode" button is pressed, the boosting is stoppend and the new preset announced Boosting: 17:10:36:337 Tuya debug 5 : Status: 0 Transid: 175 Dp: 260 (0x01,0x04) Fn: 0 Data 1 17:10:36:455 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b00502000400000005 17:10:36:456 Tuya debug 5 : Status: 0 Transid: 176 Dp: 517 (0x02,0x05) Fn: 0 Data 5 17:10:36:574 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b16802000400000064 17:10:36:575 Tuya debug 5 : Status: 0 Transid: 177 Dp: 616 (0x02,0x68) Fn: 0 Data 100 17:10:37:622 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b10202000400000013 17:10:37:623 Tuya debug 5 : Status: 0 Transid: 177 Dp: 514 (0x02,0x02) Fn: 0 Data 19 17:10:37:739 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b20502000400000005 17:10:37:740 Tuya debug 5 : Status: 0 Transid: 178 Dp: 517 (0x02,0x05) Fn: 0 Data 5 17:10:37:860 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b30e02000400000061 17:10:37:861 Tuya debug 5 : Status: 0 Transid: 179 Dp: 526 (0x02,0x0E) Fn: 0 Data 97 "home" / "mode" / "preset" button pressed 17:10:38:663 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b30401000100 17:10:38:664 Tuya debug 5 : Status: 0 Transid: 179 Dp: 260 (0x01,0x04) Fn: 0 Data 0 17:10:38:783 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b40502000400000000 17:10:38:784 Tuya debug 5 : Status: 0 Transid: 180 Dp: 517 (0x02,0x05) Fn: 0 Data 0 17:10:38:898 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b50104000100 17:10:38:899 Tuya debug 5 : Status: 0 Transid: 181 Dp: 1025 (0x04,0x01) Fn: 0 Data 0 17:10:38:898 Tuya debug 4 : Address 0x84FD27FFFE8AE403 Payload 00b50104000100

EmJay276 commented 2 years ago

Perhaps this table from the manual I just found (backside :D ) is helpfull. Temperature compensation (A1) and the open windows detection (A2, A3?, A4?) would be also great to have.

grafik

Smanar commented 2 years ago

The temperature compensation I m on it too, but for other devices, ATM is totlay broked https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5484 The windows open feature is already avaialble no, at least the on/off, I m seing the time setting and valve set is removed ? You don't have a config/windowopen_set ?

Perhaps it would be most logic if "boost" will be just another preset for HA?

Yes, I think too but ATM

As this device don't use config/mode (and BTW I will remove it in next PR) I can create a config/boost command, you will be able to use it for yourself, but will take more time to have it on an official version (ATM all is focused on DDF file)

It's like you want.

EmJay276 commented 2 years ago
* On HA "heat" is a "force heat" so a kind of boost.

I think thats the most logic way so I would suggest it this way and leave the presets aside at first. Usage example

As this device don't use config/mode (and BTW I will remove it in next PR) I can create a config/boost command, you will be able to use it for yourself, but will take more time to have it on an official version (ATM all is focused on DDF file)

So this device won't make it into the next release even if the basic functionality is working? :(

Smanar commented 2 years ago

So this device won't make it into the next release even if the basic functionality is working? :(

You will have it, as you are able to compile it, but I can't promise for the rest, if you take a look in PR list, you will see so much of them in waiting list. ATM we can't include device using c++ code and need to use DDF, but Tuya is special, the DDF part for it is not finished.

Coming home => heat == boost
Turn off == stop boost

In my mind it s more logic to take "heat" and "auto", "heat = boost and "auto" = return to normal mode. sure you want to take mode=off to turn off the boost ?

EmJay276 commented 2 years ago

In my mind it s more logic to take "heat" and "auto", "heat = boost and "auto" = return to normal mode. sure you want to take mode=off to turn off the boost ?

Sry I ment the "off" button in HA not the "off" mode. In HA the "action" - heat / off is different from the presets, I would suggest not to change the preset if "boost" is enabled/disabled for the device. Just leave the preset in the case as it is.

red = heat = boost blue = off = stop boost green = presets (holiday, auto, manual)

grafik

Smanar commented 2 years ago

In blue it's the "off" used by other uers to turn "off" the TRV (no heating at all), it s the "mode" = "off"

But yes, can use this one, it's just something to remember when using the device.

Have updated the code, you can update yours and test mode = off/heat.

EmJay276 commented 2 years ago

I tried the new version but it's not working. No request ist sent to the device from HA (according to the log). In the API "config" the "on" is changing (heat => "on": true, off => "on": false)

I also noticed sometimes (very few times) the "heat" in HA and the device don't match, but I couldn't reproduce it yet.

EmJay276 commented 2 years ago

I thought a bit about the behaviour I would expect using the "heat" and "off" button in HA.

Edit: If I think about it a bit more (for example in the summer), I would expect to turn the thermostat completely off (min temperature?) if I press "off".

EmJay276 commented 2 years ago

Ahhhh now I got it. The device has no "config/mode" according to the API that's why we were talking at cross purposes 🙈

All I have is

{ "config": { "battery": 100, "heatsetpoint": 1900, "locked": false, "offset": 0, "on": false, "preset": "manual", "reachable": true, "schedule": {}, "schedule_on": false, "setvalve": false, "windowopen_set": false }, "ep": 1, "etag": "b4f5adc7b1f88748588c142c0e8aea61", "lastannounced": "2021-11-15T19:07:18Z", "lastseen": "2021-11-15T21:17Z", "manufacturername": "_TZE200_b6wax7g0", "modelid": "TS0601", "name": "Thermostat 4", "state": { "lastupdated": "2021-11-15T21:58:37.529", "on": false, "temperature": 2000 }, "type": "ZHAThermostat", "uniqueid": "84:fd:27:ff:fe:8a:e4:03-01-0201" }

Smanar commented 2 years ago

Edit: If I think about it a bit more (for example in the summer), I would expect to turn the thermostat completely off (min temperature?) if I press "off".

We have tried it, not a success, because for exemple when setting the setpoint at 0°C is a heat mode too, so the TRV make same "mode report" or "preset report" than if you have set 30 °C. If the device don't have "off" mode, simulate it is realy boring.

Ahhhh now I got it. The device has no "config/mode" according to the API that's why we were talking at cross purposes 🙈

He yess, have re-enabled it, can remake a pull.

EmJay276 commented 2 years ago

the config: mode is not updated if boost is activated on the device (stays "null" in the API) Also the HA "heat"/"off" is not written to config: mode, it keeps changing config: on: true/false

Smanar commented 2 years ago

the config: mode is not updated if boost is activated on the device (stays "null" in the API)

My bad, have corrected the code again

Also the HA "heat"/"off" is not written to config: mode, it keeps changing config: on: true/false

This is strange, I will ask someone about that.

Kane610 commented 2 years ago

If the device doesn't report a mode the integration will send True/False to "config" "on"

https://github.com/home-assistant/core/pull/43781/files

EmJay276 commented 2 years ago

My bad, have corrected the code again

The mode is now correctly read from the device into the config: mode. The default value for config: mode is "null", is this intenionally? It will never go back to "null" and stay "heat" or "off"

EmJay276 commented 2 years ago

If the device doesn't report a mode the integration will send True/False to "config" "on"

https://github.com/home-assistant/core/pull/43781/files

The device seems to report a mode to HA, see below

grafik

EmJay276 commented 2 years ago

Ok thats weird, I added manually a third mode "auto" and removed it again (HA restart and reload of plugin) and now I have these 3 modes ["auto","heat","off"] and the boost is working correctly 🏆

In my mind it s more logic to take "heat" and "auto", "heat = boost and "auto" = return to normal mode. sure you want to take mode=off to turn off the boost ?

now I also understand what you ment here and I agree, it should be boost =>mode: "heat", stop boost => mode: "auto". But both settings from HA mode: "auto" and mode: "off" should stop the boost if it was activated.

Edit: The default mode for the device should also be "auto", an mode: "off" does not exist for the device I think.

Smanar commented 2 years ago

If the device doesn't report a mode the integration will send True/False to "config" "on"

Lol, I realy need, the book of "the hidden feature of the HA plugin"

The default value for config: mode is "null", is this intenionally? It will never go back to "null" and stay "heat" or "off"

Null mean "unknow", it s before the plugin have a mode. After that It switch from heat to off.

Have updated the code again to use heat/auto.

Kane610 commented 2 years ago

Lol, I realy need, the book of "the hidden feature of the HA plugin"

It is all based on the quirks of the rest api plugin ;)

EmJay276 commented 2 years ago

Have updated the code again to use heat/auto.

Seems good so far, it's working.

The "off" mode/button in HA of course can't be send to the device, but I would expect as user to do something if the button is pressed instead of throwing ths error in HA :D

grafik

Would it be an idea to set the preset to manual AND trigger a force close? "Priority Judgement: In manual mode [= preset manual], Set to force close > Start low-temperature protection to force opening > Test window - opening to force closing > Boost heating"

I don't know how to trigger it, but there seems to be a force setting of the device https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html

Edit: Found the force close command in the manual "Manual Mode [= preset manual] - [...] When set temperature is lower than the 'minimum temperature', the valve is closed (forced close)" Minimum temperature of the device is 5-15°C (default 5°C), so just preset => manual AND temper => 4°C and we trigger a force close for all cases

Smanar commented 2 years ago

If you want I can send request

If you set mode=off, it s easy, but you will not have a return mode = off, so it can't be displayed in HA for exemple, you will have as return the preset and the setpoint. It s not a real command "off state"

EmJay276 commented 2 years ago

Yes I think that would work

HA off button =>

And I think we could use it for mode=off from device to HA too!

If you set the temperature on the device to lower than 5°C, it shows "OF" instead of the temperature on the display and sends Data 5 for 0x02,0x02

In HA the minimum temperature your can set is 7°C (prob. default), so we could just use 5°C for setting the mode to off.

HA and the device won't be consistent for 5°C and 5.5°C set on the device, but I dont think anyone want to set his device to less than 6°C.

Smanar commented 2 years ago

Already tried ^^, not working.

The temperature heatpoint and the preset are separate command on tuya. So when you receive the preset = manual, you haven't the temperature. And you can't use the memorised value for the heatsepoint in the tuya request, because this value is limited too in deconz and can't memorise value < 5 °C.

EmJay276 commented 2 years ago

How about just use 5°C as "off"?

HA: off button =>

Device: 0x02,0x02: Data 5

Edit: I think it is a negligible usecase that the preset: auto on the device itself is configured to set 5°C

Smanar commented 2 years ago

Can try the last pushed version pls ?

EmJay276 commented 2 years ago

If I press "off" in HA the mode is not set in the API and this error is reported Fehler beim Aufrufen des Diensts climate/set_hvac_mode. /sensors/5/config/mode Could not set attribute

EmJay276 commented 2 years ago

Setting it on the devide (5°C or off) is reported correctly to HA as mode: off

EmJay276 commented 2 years ago

I think here is the "off" missing https://github.com/Smanar/deconz-rest-plugin/blob/83b5521c741a361bccb4e5fa29f43f35abe1a0da/thermostat.cpp#L103 so just use RConfigModeValuesTuya1 ?

Edit: seems working https://github.com/Smanar/deconz-rest-plugin/pull/104 I don't know if RConfigModeValuesTuya4 is used anywhere else, so I didn't remove it

EmJay276 commented 2 years ago

Found another usecase that will be inconsistent, but negligible in my point of view:

One more question, is it possible to "fix" the history for the heating diagram in HA? It's using the mode: heat to detect if the device is heating, but we changed it to trigger the boost mode if activated (instead of showing if the valve is open). grafik

Smanar commented 2 years ago

Or does HA also send the heatsetpoint to the api if the mode is changed

Nope, if you change the preset/mode it s change only that. But If I m right you will have the setpoint to 5°C AND the mode=off, no ?

It's using the mode: heat to detect if the device is heating

You are sure of that ? because if you set "auto" the TRV is heating too.

EmJay276 commented 2 years ago

It's using the mode: heat to detect if the device is heating

You are sure of that ? because if you set "auto" the TRV is heating too.

The device is heating, yes. But HA does not "detect" it is heating, if the valve opens/closes we set the state: on: true/false, but HA does only use it, to detect heating if there are no modes reported by the device. See https://github.com/Kane610/home-assistant/blob/e6f7e28b6fce87d9150983226fbaac06727c5633/homeassistant/components/deconz/climate.py#L102-L103

EmJay276 commented 2 years ago

There is also a boost preset in the generic HA constants, but not used in generic_thermostat https://github.com/home-assistant/core/blob/edd068d6ebd549be99a88f0349072541efa6375b/homeassistant/components/climate/const.py#L45 I will try some changes in the code tomorrow, perhaps change the "boost" from mode: heat to a preset or something similar.