# Use MQTT for Shelly Thermostatic Radiator Valves

**URL:** <https://discourse.nodered.org/t/use-mqtt-for-shelly-thermostatic-radiator-valves/72368>\
**Category:** Hardware\
**Created:** [17 December 2022 21:05 UTC](https://discourse.nodered.org/t/use-mqtt-for-shelly-thermostatic-radiator-valves/72368 "2022-12-17T21:05:35Z")\
**Posts on this page:** 6\
**Page:** 4

<div class="post-metadata">

**Author:** ![BartButenaers](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bartbutenaers/32/10476_2.png) [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)\
**Post date:** [29 January 2023 22:00 UTC](https://discourse.nodered.org/t/use-mqtt-for-shelly-thermostatic-radiator-valves/72368/61 "2023-01-29T22:00:13Z")

</div>

Thanks everybody

> [@Steve-Mcl](#):
>
> Have you tried the [Shelly node](https://flows.nodered.org/node/node-red-contrib-shelly)s Bart?

Hey Steve,  
I had initially started with that node, but I left it aside because I wanted to use mqtt instead of http. But yes indeed, now that we are back at http I might give it a shot again. Althought that node mentions the same message properties that are confusing me.

> [@juntiedt](#):
>
> just in case you haven't seen this link

Thanks for the pointer! I had already mentioned those above.

> [@mudwalker](#):
>
> as I do it through MQTT

Do you mean http? Or mqtt? Because I thought you also had dropped mqtt because it is not fully featured for their trv's at the moment yet?

Ok, my problem was not each http request individually, but the whole setup based on all these http request. Have re-read everything again, and I assume the _ **different modes** _ of the TRV can be summarized like this:

1. If you want to control the _ **position of the valve** _ yourself, you set _ **automatic mode OFF** _ (i.e. `target_t_enabled=0`). We will stay in this mode until the automatic mode is turned ON, or until a schedule is active (and a next setpoint arrives).

2. If you want to control the _ **target temperature** _ yourself, you set _ **automatic mode ON** _ (i.e. `target_t_enabled=1`). Then the TRV will calculate the position of the valve, to make sure the target temperature will be reached in time. We will stay in this mode until the automatic mode is turned OFF, or until a schedule is active (and a next setpoint arrives).

3. If you want want to set target temperatures _ **automatically** _ by the TRV, then set \ ***schedule ON** (i.e. `schedule=1`) and select 1 of the 5 available schedules (via `schedule_profile`). As a result the TRV will calculate the position of the valve, to make sure the target temperature will be reached at the specified timestamps. We will stay in this mode until a request arrives to set the valve position (see 1) or to set the target temperature (see 2). But as long as the schedule mode is ON, the schedule will take control back as soon as the next setpoint in the active schedule arrives.

I think I understand it now....

Just need to find a good balance between reading temperature often enough to show it as a reliable value on my dashboard, but not too often to avoid the battery becoming empty too quickly....

---

<div class="post-metadata">

**Author:** ![mudwalker](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@mudwalker](https://discourse.nodered.org/u/mudwalker)\
**Post date:** [30 January 2023 11:32 UTC](https://discourse.nodered.org/t/use-mqtt-for-shelly-thermostatic-radiator-valves/72368/62 "2023-01-30T11:32:03Z")

</div>

Hi Bart,

I send my commands through HTTP, some of the commands Shelly can use do not seem to work when using MQTT. It might be me at fault here, but initially Shelly had not implemented all commands available through MQTT. So, yes, you are correct!

My intention was to use MQTT, but due to the above, I abandoned it other than for the ongoing Position Control as I felt that would use less power than the HTTP method. (Basically, I have confused myself here!)

1 & 2 - See the 'Shelly TRV Experiments' in the 'dirty' flow that was sent. I build the TRV message by adding the topic messages to the HTTP request.

1. Yes, you can see the Profile (1-5) Inject Nodes. I am not using profiles as I control my Boiler through Opentherm Gateway and need to drive the TRV and Boiler in parallel (hence the JSON routine we worked on).

My thought on readings is that a Central Heating System has a large thermal mass (heating, or cooling) and the only thing that really affects this is a door or window opening. However, once the door or window is closed after a brief period, the comfort will return reasonably quickly. If they are open for a long time, then maybe the heating should be switched off - the world has a massive thermal mass and takes a lot of your heating to try to warm it up!

So, if the temperature feedback is updated every five or even ten minutes, does it matter? The answer for that is, as you say, a balance between a reliable value and battery depletion.

I was using Colin's PID loop, which is impressive, but I found that it wasn't really needed with the thermal mass, so have gone to a straight On/Off or Open/Closed control of the valve.

---

<div class="post-metadata">

**Author:** ![WhiteLion](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/whitelion/32/12266_2.png) [@WhiteLion](https://discourse.nodered.org/u/WhiteLion)\
**Post date:** [15 February 2023 22:03 UTC](https://discourse.nodered.org/t/use-mqtt-for-shelly-thermostatic-radiator-valves/72368/63 "2023-02-15T22:03:01Z")

</div>

Well, after reading most of this topic I got rid of my hopes:  
copy cating a m/nice MQTT flow and saving a lot of work 🙂  
Are there any updates for Shelly TRV available to fix MQTT functionality ?

---

<div class="post-metadata">

**Author:** ![mudwalker](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@mudwalker](https://discourse.nodered.org/u/mudwalker)\
**Post date:** [16 February 2023 12:13 UTC](https://discourse.nodered.org/t/use-mqtt-for-shelly-thermostatic-radiator-valves/72368/64 "2023-02-16T12:13:44Z")

</div>

Yes, there have been updates, but last time I tried, I couldn't get the calls I wanted to work using MQTT. Could be me, but I do know there was an original problem with some calls when they first came out.

---

<div class="post-metadata">

**Author:** ![msillano](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/msillano/32/17424_2.png) [@msillano](https://discourse.nodered.org/u/msillano)\
**Post date:** [7 April 2023 09:31 UTC](https://discourse.nodered.org/t/use-mqtt-for-shelly-thermostatic-radiator-valves/72368/65 "2023-04-07T09:31:25Z")

</div>

I used TRV Thermostatic radiator Valve SEA801-ZIGBEE (Tuya compatible).  
Using Zigbee devices has some advantages:

- Zigbee mesh extends regardless of WiFi coverage area.
- All Zigbee devices add only one WiFi client (the Hub).
- The hub is always connected (powered via USB) and therefore you have a stable MQTT connection.

Details (data-points and capabilities) of the device are available here [https://github.com/msillano/tuyaDAEMON/blob/main/devices/TRV\_Thermostatic\_Radiator\_Valve/device\_TRV\_Thermostatic\_Radiator\_Valve.pdf](https://github.com/msillano/tuyaDAEMON/blob/main/devices/TRV_Thermostatic_Radiator_Valve/device_TRV_Thermostatic_Radiator_Valve.pdf)

4 TRVs have been in use for two years, with an IOT development environment in node-red ([tuyaDAEMON](https://github.com/msillano/tuyaDAEMON)), without any problem.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [6 June 2023 09:32 UTC](https://discourse.nodered.org/t/use-mqtt-for-shelly-thermostatic-radiator-valves/72368/66 "2023-06-06T09:32:07Z")

</div>

Closed on 6 June 2023 09:32 UTC

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

[Previous page](https://discourse.nodered.org/t/use-mqtt-for-shelly-thermostatic-radiator-valves/72368.md?page=3)