Use MQTT for Shelly Thermostatic Radiator Valves

I found the answer in this interesting article:
If a set point is manually entered when a schedule is running, the new set point will override the schedule until the next time a temperature change is defined in the schedule.

So if you change the setpoint temperature manually via the buttons, that afterwards you also manually need to change the setpoint again (only if you want to go back to the original scheduled temperature). The display on the TRV shows the current temperature and the set point as it is being adjusted.

Read some other interesting things in that same article:

  • TRV will perform its automatic calibration so it understands the fully open and close limits of the radiator valve.
  • A schedule can consist of up to five unique profiles and each profile can consist of up to 20 temperature changes at different times during the day.

That means it times how long it takes to drive from open to closed (and probably back again).

1 Like

There was an occasion recently where an unattached TRV went into a 'continuous calibration' mode (in/out/in/out repeat) after the battery went flat. Once installed on the Radiator, it was able to calibrate correctly and sorted itself out.

I drive my TRV using MQTT and request status every 37 seconds, but this does need to be reviewed, no need for that frequency with such a slow system attached. One of the messages that comes back is the battery charge level, I monitor this and send a Telegram message when it gets to 30%. Commands are only sent when the value changes (Filter node).

With restarts when the flow is modified (such as after installation of OTGW) it would seem that the battery life is a solid 3 months, once everything settles down I am sure this can be extended by quite some time. The other precaution taken i that if the heating is not required all comms are blocked except a 12 hour Status request to check batter level.

There is currently a problem with the PID control as it seems to close the valve after every command, but to be honest, I think that a change to the persistence value in the PID node will sort this out. Consequently, at the moment, the valve is just used as Open/Shut, which to be honest, works well enough.

Unfortunately, I have been rather busy recently with Family stuff, so not been able to check it out.

HTH

Thanks for sharing your experiences!!

So you measure the frequency often, to control the temperature yourself.

Do you have any idea about:

  1. Would it be a decent setup to leave control to the trv itself, by uploading a schedule via Node-RED. And so let the TRV do the necessary to follow that schedule?
  2. Why my 'info' messages (see my second post above) arrive automatically at such weird timings? I have no idea at which conditions the trv decides to send an info message...

Which PID node are you using? If it is node-red-contrib-pid then I should be able to help with this. In fact I would be fascinated to see how it works with that valve as I am thinking of trying one myself.

1 Like

@BartButenaers You can leave the TRV to control itself, but I do like to be able to tweak things. We are quite frugal with our heating (as are we all!), e.g. during the afternoon, we have the temperature set so that we aren't cold, but, it might be considered cool to visitors. I can then set a Manual Temperature which is suitable for them. You could do this by sending a one off, but for me, being able to control the temperature through Node-RED gives me a visual status of what is going on. I had a lot of help recently generating a basic flow for setting a schedule. This could be modified to add days of the week if needed.

From memory, the status is sent on the TRV's schedule, which was why I started to request the status for my own convenience.

@Colin The problem is probably mine, and yes, I am using your Node. What happens is that as a new PID value is sent, the TRV closes and then opens to the correct percentage, which seems a waste of battery to me, and provides some 'noise pollution' which being an Engineer, I hear every time it operates and to be honest, grates on my nerves!! I have not isolated the cause of the problem yet, but as I can see it on the graph of the output of the PID Node. This suggests that it might be from there. Basically, the Valve is being commanded to Close and Open at very change. I need longer to tie it down.

I will need to get back into this in the New Year, but Grandchildren's Birthdays, Christmas and Family visits will get in the way until then!

Our first cold snap, the new boiler misbehaving so that we had minimal heat (boiler @ 38deg!) and a week away have not helped!

1 Like

Add a debug showing what is going into the PID node and check that all the messages have good PV values. Check that you are not accidentally sending in something with one of the topic values that mean things to the node.

1 Like

Provided the clock on the TRV is set correctly I would have thought that sending a schedule would be the way to go. I thought the whole point of an automated TRV is that it has its own controls. There are still loads of things that can be controlled from Node-red, modes, away days etc

A good point raised in another thread is that it is worth setting up a monitor of TRV temperature against room temperature to track any variations between the schedule and real life, just to reassure yourself that they are working OK.

Most battery operated devices seem to have a mind of their own on when they report back, but obviously the fewer reports there are the longer the battery lasts

That is quite short in comparison to the 2 years that the mention all over the web...
I'm very curious if it will be better if I upload the schedule via Node-RED, and then let it live its own life as much as possible...

@Colin I will re-activate the Debug Nodes, however, the graph has been showing valid OP and SP values with PV showing the current temperature of the room, that is until I re-arranged the flows taking functions away from my Opto22 Controller and passing them to Node-RED. I just need to sit and sort those out. When it was controlling, other than tweaking the Values, it did appear to be controlling correctly, even if it was 'slightly' underdamped with it's wildly swinging values!! Time is what is needed, however, my current thinking is that for now ON/OFF control is fine with the inertia of the system. In the interests of this application, I can pursue the PID route further, but it would mean more power consumption.

@BartButenaers Running the Shelley as a stand-alone has to be the way to preserve Battery Power. My current thoughts are to load the schedule once a day, with overrides sent as an when. TRV complete with Battery Status (I think) will come back as you load the new schedule, but loading this once a day means that the TRV does not need to keep reconnecting to Wi-Fi, which has to go a long way to save the battery, gathering ststus at the same time would not be too great an overhead for the battery once connected.

Of course, as with all sales literature, what is advertised and 'real world' figures are like Chalk and Cheese, but then we, as the consumer, have come to expect that! :rofl:

@mudwalker,
That is indeed a good approach I think. At least if the TRV does a good job on its own...
But then our Node-RED is still in control, with minimum of communication.

I had a look at your flow last night, but I didn't find any ways to set the schedule via Node-RED and MQTT to the TRV. But perhaps I have overlooked it. And I didn't find it in the Shelly API docs or on the web either. So if you have any simple examples, I would appreciate a lot if you could share it.

Sorry to disturb you this much, because I realize you are very busy at the moment. But the wife at the moment has the impression that the Shelly TRV is just one of those many devices I bought, which will never see the daylight...

When you said

I thought you meant that the output of the PID node went to 0 and immediately back to a good value again without a change in input temperature. That is why I suggested checking what is going into the PID node to make sure there are no spurious temperature values or auto/manual switch or similar going into the node.

@BartButenaers I currently read Context Memory for the current setpoint and then feed this in through Change Node 'set msg.setpoint'. I can look at sending a schedule to the TRV over the next 'few' days, it is not something I have investigated yet, just 'thinking out loud'.

@Colin Let me set things back up so that the new flow sends and reads the new data locations correctly and I can start looking at the operation again.

It is not a problem asking questions, I can have a think, the problem is being able to get the time to play in the lead up to Christmas. My programming skills are rudimentary and it can take me a while to complete what others may consider a simple task. I am in awe at the number of pieces of code that members of the Forum just rattle off to help someone with their problems, I read these and get little pointers as to what might help my application!

So, the ball is in my court for both these things and going the alternative route for the schedule means that running the PID would defeat the object of 'minimum' communication with the Shelly. But as Colin is interested in seeing the PID run in this particular application, I would like to try to oblige. I do have a second TRV, but it is just a bit too wide to fit the current radiator inlets!

1 Like

Oh thinking out loud is appreciated a lot. I will try to think out loud also :wink:

I must admit that I am kind of surprised that it is so hard to find simple examples. Perhaps it is somewhere available and easy to find, but then I have overlooked it...

Via some facebook folks I finally found this link from Shelly support. Note that you need to create an account first and press numerous confirmation buttons.

On that link you will find a nice overview of multiple http commands for the TRV. I will share a copy of the content here, for easy access. BUT ALL CREDITS GO TO Devil, THE AUTHOR OF THE ARTICLE IN THE ABOVE LINK !!!!*

  • Auto Temp Control:

    http://192.168.xxx.xxx/settings/thermostat/0/?target_t_enabled=1
    

    ON = 1 , OFF= 0

  • Auto Temp Control ON and set Target-Temp:

    http://192.168.xxx.xxx/settings/thermostat/0?target_t_enabled=1&target_t=10
    

    Target-Temp. 4-31 degree

  • Auto Temp Control OFF and set Valve-Position:

    http://192.168.xxx.xxx/thermostat/0?pos=10
    

    Valve-Position in percent 0-100 (%)

  • Switch Schedule ON/OFF:

    http://192.168.xxx.xxx/settings/thermostat/0?schedule=0
    

    ON = 1 , OFF= 0

  • Switch Schedule ON/OFF and set Schedule Profil 1-5:

    http://192.168.xxx.xxx/settings/thermostat/0?schedule=1&schedule_profile=1
    

    ON = 1 , OFF= 0
    Profil = 1-5

  • Boost Start in Min:

    http://192.168.xxx.xxx/thermostat/0?boost_minutes=10
    
  • Switch Accelerated heating (reduce time to reach the target temperature):

    http://192.168.xxx.xxx/settings/thermostat/0/?accelerated_heating=0
    

    ON = 1 , OFF= 0

  • Set minimum position of valve in percent:

    http://192.168.xxx.xxx/settings/thermostat/0?valve_min_percent=0
    

    Valve-Position in percent 0-10 (%)

  • Set Display brightness :

    http://192.168.xxx.xxx/settings/?display_brightness=1
    

    1=Low, 4=Normal, 7=High

  • Display Rotate screen (180°):

    http://192.168.xxx.xxx/settings/?display_flipped=1
    

    ON = 1 , OFF= 0

  • Child Lock:

    http://192.168.xxx.xxx/settings/?child_lock=1
    

    ON = 1 , OFF= 0

  • Calibration:

    http://192.168.xxx.xxx/calibrate
    
  • Change timer profiles:

    http://192.168.XXX.XXX/settings/thermostats/0?schedule_profile=1&schedule_rules=0830-0123456-18.5,1030-0123456-20.5
    

    schedule_profile: the profile number 1 (linvingroom)

    schedule_rules: each entry must be separated by a comma

    • Each block can be seen here separately separated by the hyphen/minus (-) (0830-0123456-20.5)

    • First block (0830): Time hour and minute written together, note leading zero in example 08:30

    • Second block (0123456):

      • 0 = Monday
      • 1 = Tuesday
      • 2 = Wednesday
      • 3 = Thursday
      • 4 = Friday
      • 5 = Saturday
      • 6 = Sunday

      In the example they specified from Monday to Sunday

    • Third and last block (18.5): The desired temperature in the example 18.5°C

Thanks to this article from Devil, at least I know now what the information in all the blocks of the schedule command mean :+1:

BTW after reading Devil's article, it indeed seems that the Shelly API contains similar information:

So it is all in the API documenation, and if you know the correct keywords you can find it...

1 Like

Don't bother about it if that is not the route you intend to go. In fact the likelihood of me actually using this device in the near future is pretty low, there are just so many things to play around with that I never get round to doing half of the things I dream of.

1 Like

Found this in the Shelly API documentation:

Device state is reported periodically, every 30 seconds by default. This can be changed by setting a new period for updates: mqtt_update_period under /settings. A value of 0 will disable periodic updates.

1 Like

The Shelly API Documentation is my 'goto' for all things API, I am also registered in the Forum, which I then look through if I can't find/understand things in the API documentation, sometimes the nudge is just enough to make the fog clear.

I see how to upload a profile, thank you, and will have a look through the implementation in any 'quiet times' available to me, may take a while. Status is not something I need all the time, other than for archival purposes, but that is more the Engineer in me with the Data being available, rather than it being needed (if it is available, archive it!). In fact, most messages to the TRV I only send when things change, although I may check flow parameters every 30 secs, they will only be sent if something has changed.

The flow I originally posted (referenced above) was one to show that operation was possible and contained belt and braces logic as far as I understood at the time, the original 'original' included HTTP commands because one of my Shellys would not respond to MQTT (firmware problem, now fixed).

@Colin In that case, I will leave the PID part in the flow for now so that it is available to re-implement. You never know, I might get some time to go back to it. I do want to resolve the apparent close/open situation on any change in output from the PID - whether PID based (Persistence?) or Shelly based, just because it i there!

Please be aware that if f I get a problem in things like this, it is usually because I have only understood 90% of the requirements, and not because of any bad node/flow. That 10% can be a 'Killer' for me! :rofl:

FWIW, current state with 'original' basic test flows...

TRV flow.json (73.7 KB)

(Too big to show as </>)

ADDED:
There has been an historic problem with http/API calls. You will often see this (or similar)...
http://XXX.XXX.XXX.XXX/settings/thermostats/0

What you need is...
http://XXX.XXX.XXX.XXX/settings/thermostat/0
*Note the removed 's' of 'thermostats'

So, this HTTP request is confirmed as working...
http://XXX.XXX.XXX.XXX/settings/thermostat/0?schedule_profile=1&schedule_rules=0830-0123456-18.5,1030-0123456-20.5

1 Like

Does this also apply to TRV's ie. battery powered devices ? sounds like overkill/battery killer.