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! 
