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.
Thanks for the pointer! I had already mentioned those above.
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:
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).
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).
This can be achieved by setting the target temperature via a http request, or via the physical up/down buttons on the device.
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....
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.
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.
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 ?
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.
