HY368 thermostat mode "heat" ignores setpoint

[Hypfer]

Describe the bug

Setting the thermostat mode to heat causes it to open the valve 100% all the time with no regard for the setpoint.

Steps to reproduce the behavior

1. Set thermostat to heat
2. Observe the room getting warmer beyond the setpoint

Expected behavior

Auto should use the schedules configured in the device while heat should be manual control without schedules.

Environment

• Host system: Pi 3B+
• Running method: Raspbian
• Firmware version: 26330500
• deCONZ version: 2.05.83
• Device: RaspBee I

[Arquiteto]

Did you set the mode directly via REST API or through some other software?

[Arquiteto]

Also, this thermostat only got support on deCONZ 2.05.85

[Hypfer]

Also, this thermostat only got support on deCONZ 2.05.85

root@phoscon:/usr/share/deCONZ/plugins# zgrep deconz /var/log/dpkg.log.1 | tail -n3
2020-10-01 18:29:41 status unpacked deconz-dev:armhf 2.05.83-raspbian-buster-beta
2020-10-01 18:29:41 status half-configured deconz-dev:armhf 2.05.83-raspbian-buster-beta
2020-10-01 18:29:41 status installed deconz-dev:armhf 2.05.83-raspbian-buster-beta

root@phoscon:/usr/share/deCONZ/plugins# ls -lah
total 2.4M
drwxr-xr-x  2 root root 4.0K Oct  1 18:27 .
drwxr-xr-x 10 root root 4.0K Oct  1 18:27 ..
-rwxr-xr-x  1 root root 2.1M Sep 26 09:13 libde_rest_plugin.so
-rwxr-xr-x  1 root root  39K Sep 26 09:13 libde_signal_plugin.so
-rwxr-xr-x  1 root root 189K Sep 26 09:13 libstd_otau_plugin.so
root@phoscon:/usr/share/deCONZ/plugins# strings libde_rest_plugin.so | grep tuya
tuya.cpp

Not sure what is going on here since I am in fact able to control these thermostats 🤨 Maybe the model number on the box is misleading or something like that?

Did you set the mode directly via REST API or through some other software?

I'm using the home assistant deconz integration which calls the REST API with a {"mode": "heat"} payload as it can be seen here: https://github.com/home-assistant/core/blob/6c3362217efad87426f674e0a4b8e61bfab051d0/homeassistant/components/deconz/climate.py#L113

here: https://github.com/Kane610/deconz/blob/a62856fcd8db09b3d5a965eaba0923f8fd9b69bc/pydeconz/deconzdevice.py#L27

and here: https://github.com/Kane610/deconz/blob/a62856fcd8db09b3d5a965eaba0923f8fd9b69bc/pydeconz/api.py#L107

[Arquiteto]

I'm using the home assistant deconz integration which calls the REST API with a {"mode": "heat"} payload as it can be seen here:

Yep, that is the problem I found with HA as well, but it's problem with how HA handles REST API regarding Tuya termostats. Check here: https://dresden-elektronik.github.io/deconz-rest-doc/sensors/#changestate

Normally REST API uses "mode" for theremostats, but with Tuya it uses "preset", because they have different options. Unfortunately HA code doesn't reflect that yet.

[Hypfer]

Ah! I see.

There doesn't seem to be an issue in neither the core HA repo nor in the pydeconz one. Should I open one?

[Hypfer]

Why is it different though? What is the purpose of mode for Tuya Thermostats?

[Hypfer]

At least the second question can be answered with this:

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3024#issuecomment-661691948

[Arquiteto]

Well, this are the modes that are supported in deCONZ: off, auto, cool, heat, emergency heating, precooling, fan only, dry, sleep Meanwhile Tuya valves offer different capabilities (this is what you can configure via Tuya app and gateway):

• holiday - away mode with low temp
• auto - schedule set in thermostat
• manual - manual control
• comfort - comfort temp that you can set in app
• eco - eco temp that can be set in app
• boost - boost mode (100% for a predefined time, default 30min, you can set that on valve)
• complex - mixed mode, meaning it was in schedule mode but it was overriden manually

The modes in "mode" parameter don't cover those from Tuya, so I guess that's why different key. The problem is also HA only supports limited key of values in mode domain. Zigbee2MQTT engineeres solved that by adding second key "preset" for integration of this valves into HA. Unfortunately I don't think I have a screenshot of that.

So I'd say an issue on HA core would be in place. It would be nice to have at least 'eco' 'comfort' and 'holiday' modes available, but I didn't have time to post it yet.

[Hypfer]

This issue could be solved by a minor change remapping current mode heat to emergency heating and instead having current preset manual as mode heat (and maybe preset manual as well?)

emergency heating fits the behaviour (100% valve open all the time) much better. This would also fix compatibility with home assistant by keeping the deconz rest api consistent.

[Mimiix]

Asked @Smanar to check in on this one.

[Smanar]

Hello, yes it s possible, we can remap some command from HA "auto" > preset = comfort "heat" > preset = boost

But for "off" ? preset don't permit to set "off", and boost is not permanent, it s a timed feature. For me @vegetate7 have realy found the good way

From HA, I can set "mode" in HA meaning ("off" to close valve, "heat" to open valve, "auto" to pass control to presets). And from REST-API I can select presets (one of "holiday", "auto", "manual", "confort", "eco", "boost" and "complex").

[vegetate7]

"heat" > preset = boost

"boost" is time limited.

And WRT "emergency heating" mode. As I can see from HA code, the generic "climate" component doesn't have "emergency heating" mode. Some customized interation (I found it in Elk-M1) have it as one-way mapping actual thermostat device working mode to HA displayed thermostat entity mode. But not to set mode on device. So I do not think it is an option. At least until HA makes the "climate" integration more friendly for customization.

[Hypfer]

But why would heat as a mode be a temporary status such as boost @Smanar ?

@vegetate7 it doesn't matter that there's no emergency heating in HA. We don't need to make everything available to them.

To get the API consistent and therefore also get it working in HA, we just need to change the heat mode to preset manual. Everything else can stay as it is now.

While having off as 0% and heat as 100% is in itself consistent, there's no thermostat which works like that, because thermostats are called thermostats and not valves. They care about their setpoint.

[Mimiix]

To get the API consistent and therefore also get it working in HA, we just need to change the heat mode to preset manual. Everything else can stay as it is now.

As we discussed before: We are looking to make the thermostats / valves behave the same in the api. That way, The HA integration, HomebridgeHue, HueEssentials and Iobroker can implement it properly. We had a discussion last night with the devs, i am not sure what will be next. I'll let you know.

[Hypfer]

In that case, we should make sure to implement thermostats as thermostats and not valves 👀

[Mimiix]

Updated my comment ^^

[Smanar]

While having off as 0% and heat as 100% is in itself consistent, there's no thermostat which works like that, because thermostats are called thermostats and not valves.

I m agree for me 0% / 100 % / auto is only for valve, and preset for thermostat. Valve are actionner and thermostat commander (in theory)

But TRV are realy like thermostat, and have preset or schedule (or just setpoint) , realy hard to make the use of valve different than the thermostat one. But it s possible to add or remove "mode" or "preset" according to device.

[stale[bot]]

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[Hypfer]

Still an issue

[Smanar]

Give me your device, and what you want I change, There is so much tuya device, I m totaly lost. I Need:

• the device name
• the type, valve or thermostat
• if it support "preset"
• if it support "mode"

and not possible making something "general"

[Hypfer]

Okay It's this device:

It is a thermostat which currently opens 100% when setting its mode to heat via the REST interface.

Instead, setting its mode in deconz to heat should activate the tuya preset manual

[Smanar]

So for this one you want to disable the "mode" , because it s a thermostat, or just let the "off" / "auto" to enable /disable the device, and use "preset" instead for setting ?

But if the "heat" is actualy working (with "mode") it mean the device realy have this feature (and not all have it), this device have a "force heat" feature like valve.

In fact tuya device use 3 "mode"

• the dp = 0x016c with mode = heat/auto
• the dp = 0x046a with mode = auto/heat/off
• the dp = 0x0165 with mode = off / manu

And from the code, your device use the 2nd, heat = Force heat, if you want to use the setpoint you need to be on "auto".

And it seem your device support "mode" but "preset" too.

[Hypfer]

I want to have a proper abstraction of vendor-specific details in DeCONZ. As of now, the REST API is not the DeCONZ API but rather the Tuya API, however that's only true for tuya devices.

It shouldn't matter how tuya devices work internally. Instead, changing the mode in a sensor config should work exactly the same no matter who made that thing.

To quote the documentation:

	Sets the current operating mode of a thermostat.Generally supported values are: off, auto, cool, heat, emergency heating, precooling, fan only, dry, sleep

Therefore, also this thermostat in this issue should work like every other thermostat, which works out to the following modes

• off - Off
• auto - Use internal schedules or something like that
• cool - not present
• heat - Heat to setpoint. not just open the valve 100% all the time
• emergency heating - maybe open the valve 100% all the time. maybe not present
• precooling - not present
• fan only - not present
• dry - not present

Also, we should really remove the preset option from the sensor config, since that is a vendor specific quirk and that doesn't make sense for a generic API. There must be a vendor-agnostic abstraction to that, however that's out of scope for this issue.

In any case, it makes a lot more sense for this project to just support some features of a device while being consistent with other vendors instead of cramming all the functionality in here by breaking the interface completely.

It makes absolutely no sense that an API caller must know what device vendor they're talking to to know which command is appropriate to achieve the desired outcome.

What if TuYa starts making lights? Will it be impossible to turn them on via the API by sending them a state, just because tuya decided to call the state something different internally? I think you get my point

[vegetate7]

It is not thermostat. It is thermostatic valve. Which is actually thermostat + on/off switch. And have not abstraction at all. We've just approach better control to both functions. Therefore 'preset' controlling "internal schedules or something like that" of thermostat and 'mode' controlling valve.

If we'll have ZHA TRV abstraction - will do this. But while no - it is very disputable which way is better, but calling to "this is standart" is not the argument. Because there is no standart.

[Smanar]

It s your device ? https://pl.aliexpress.com/item/4001065130284.html If yes he is right, this one is not a thermostat.

I will explain my problem. there is some thermostat that have physicaly 2 buttons.

• the first can make on/off at least but "Force heat" too.
• the second one is the preset, it s "auto" but with diffrent setting like "holiday" or "eco", but can have too the "force heat"

I don't see other way than making 2 fields "mode" and "preset", not my fault if some device have the "force heat" on the first button and other on the second one.

And some thermostat have only one button, but with 2 fonctions or 10, so to choose beetwen "mode "or "preset" ....

In my mind I wanted to put only "mode" or only "preset", third app can reconize the device like that, but not possible for thermostats that have 2 buttons.

I m agree with you, I m trying to keep the "mode" general using vendor-agnostic abstraction, so if a device have the on/off fonction on the first button, this one will be "mode", it s prioritary, if the "force heat" is on the second one, sorry, it wll be in "preset"

PS: Im using the word "button" but it can be "command" in reality.

[Hypfer]

It is not thermostat. It is thermostatic valve.

You're right, sorry. That got lost in translation. In german, you have a Ventil (Valve) and a Thermostat (Thermostatic Valve) which is what led to this confusion

[Smanar]

Np, ^^, but the situation is still not perfect. If I m right on HA, you have only off / auto / heat used systematicaly for thermostat device ?

[Hypfer]

Yep. HA looks like this:

[Smanar]

Yes so was like in my memory, this device is perfect for valve. They are using : Auto / Force heat (without setpoint) / off.

It s for that by defaut the "heat" don't take care of setpoint, else it s the "auto" mode.

[Hypfer]

What it should do is to have Auto (respecting the internal schedule), Heat (respecting the setpoint) and Off

[Smanar]

Heat (respecting the setpoint) is auto too. Heating something respecting a value is regulation. Not all device support schedule, but all have the "heating according a value"it s the basic working mode, Schedule is a preset.

[Hypfer]

I'm 99% sure that every other Thermostatic Valve which is currently implemented in DeCONZ doesn't have "heat" mapped as 100% valve open.

[irekzielinski]

I have the same valve and control via REST api works well (HA integration is not amazing as Auto/Heat/Off modes don't match what REST has).

I have howerver a problem: If screen is off on the device - sending a REST command shows "success" message. But when I wake up the device it's clear that command was ignored / not received. When screen is lit - REST messages work as expected (can for example put device into holiday mode, change heatsetpoint, etc).

Does anyone else see this issue?

ps. I am on 2.07.00, firmware: 26660700

[Smanar]

Ha yes, right, good catch, but are you sure it s a valve and not a thermostat ? I know some thermostat have a display and this one can be turned "off" (IDK for valve). For bulb for exemple, deconz check the device state, and send an error message if the device is "off". But nothing like that on thermostat side.

Wich one command are working or are ignored when the device is "off". And BTW have you the manufacture name of your device ?

[irekzielinski]

but are you sure it s a valve and not a thermostat ? Not 100% what is the difference. But maybe the details I provide will clarify this.

Wich one command are working or are ignored when the device is "off". And BTW have you the manufacture name of your device ?

This is my device (I think the same as @Hypfer has): https://pl.aliexpress.com/item/4001043738901.html?spm=a2g0s.9042311.0.0.7a895c0fzE96Gx

This is how it reports in the deconz REST api:

I just noticed there is both "mode" and "preset" - not sure what is the difference. I have been using "preset" via REST api, and for example if I set it to "holiday" - I can see airplane symbol appearing on the screen. So this setting work.

This is how I set the target temperature and preset via REST (this seems to work ONLY when device is awake (screen lit)). Rest API always says "success" anyways as in this example:

Thanks!

update: I can also control temperature and "mode" using Home Assistant - again screen has to be lit for action to happen. If screen is off - value will be updated in REST api, but not applied to the device.

[Smanar]

So I need to make an error message :

• if the mode = 'off"
• Only for setting the setpoint

"mode "and "preset" are working if the mode = "off" ?

[irekzielinski]

@Smanar I tested "mode" field (both via REST and via HA). Mode for me works:

• off - will close valve (and display OF)
• heat - will fully open valve (and display ON)
• auto - will open/close based on target temperature setting (displays current temp, and valve position?)

My problem: changing "mode" (or "preset" or "heatsetpoint") will work only when screen is lit. As soon as screen turns off - changing settings via HA or REST does nothing (REST API shows "success", but device ignores it). I think device gets the message: I sent message via REST, and could see blue dot in VNC (I think this means communication with the device in progress).

Is there a command to wake the screen? Maybe that shoud be sent before changing "mode"/"preset"/"heatsetpoint"?

[irekzielinski]

"mode "and "preset" are working if the mode = "off" ?

I tried to set "holiday" preset when "mode" == "off", but no airplane symbol got displayed on the screen. So likely some combinations are of mode and preset are not correct.

[vegetate7]

BTW, just for an info. Returning to where this thread started. recent HomeAssistant 2020.12 version started supporting 'preset' for climate devices! (and tilt on covers, but I have not any to look)

[vegetate7]

@irekzielinski , have you tried to change one setting per command?

[Smanar]

For exemple for bulb, if the bulb is "off" you have an error message if trying to send command, I want to do same for TRV. ATM deconz send the request, display "ok", but the device don't react to order (because it was "off").

I can do that, for all command if the device is on mode = off ?

[irekzielinski]

I can do that, for all command if the device is on mode = off ?

I think we talk about different problem. My issue is that I can't change anything when screen is off (not "mode" == "off", but when screen of the device switches off backlight).

For example: I can enable via REST api (or HA) "mode" = "off", and I will hear valve closing - but only if I recently touched the device and screen is active. If I do the same after screen went to sleep REST command to change mode will be ignored.

Can you change a mode from "off" to "heat" when screen of the device has backlight off? After you wake the device (by pressing on it) - does show you the mode set via REST api?

[Smanar]

I think we talk about different problem. My issue is that I can't change anything when screen is off (not "mode" == "off", but when screen of the device switches off backlight).

Ha right, sorry in my mind was same, but it s strange, you can have the display off, but the device working so how you can change the temperature setting ? You have tried whith the original gateway, to check if it s the normal working mode ?

BTW if you have deconz, you can too just wake up the device with touching it (no more action/commad), and looking if you have in deconz log (deconz/help with info and info_L2) a line starting with "debug tuya", to find if there is a command to just wake up the device.

[vegetate7]

Can you change a mode from "off" to "heat" when screen of the device has backlight off?

I can. I have two of those, one exact same, other slightly different, both installed in hard to reach places and mode/preset/setheatpoint works flawlessly without manually awakening.

After you wake the device (by pressing on it) - does show you the mode set via REST api?

No. REST API change setting after device report. And the device reporting very seldom (or even never, may be) if nothing changed. If some setting changed - the device reporting it immediately.

[Hypfer]

You people do realize that it's an absolutely awful idea to mix different topics in a single issue, right?

[irekzielinski]

I can. I have two of those, one exact same, other slightly different, both installed in hard to reach places and mode/preset/setheatpoint works flawlessly without manually awakening.

I think I might have a faulty device then. Sorry for highjacking the thread :(

[Smanar]

You people do realize that it's an absolutely awful idea to mix different topics in a single issue, right?

Right ^^, sorry

[Smanar]

You people do realize that it's an absolutely awful idea to mix different topics in a single issue, right?

Right ^^, sorry, I have bad reflex.

[Hypfer]

Since 100% of these devices died on me due to the battery cover becoming loose with no mechanical stress whatsoever, I really don't care about this issue anymore.

Feel free to change the API however you like in whatever ways you deem reasonable.

[hackacad]

You submitted a software enhancement request and closed it because you had hardware issues. You‘re talking about FOSS on your profile but use this thread to complain about your personal problems. Thanks!

This issue is now resolved and nobody should/would care about the issue itself. Thanks for that, too.