New feature suggestion

[info@kaeseler.dk]

Hi Steve

Thank you so much for providing this plug-in. I am truly impressed and super satisfied. I have been trying to do a "bit" of programming myself to manage my 14 circuit under-floor heating (currently, meaning running for the last 2 years, only with virtual devices, to see if everything works or not). And after hundreds of hours of struggling and swearing, I find your plug-in, which is much, much better.

I have two suggestions, which would make a lot of sense and value - for me at least.

1. create some sort of a parent device which could be used to store global values for at-home-, night- and vacation temperatues as well as weather compensation values. The various VSTAT devices could then either use global or local values depending on whatever is checked on that VSTAT.

Most of my rooms would have the same "needs", however they may follow different schedules (e.g. juniors room, as he is home earlier than we are). Maybe the storage room in the basement could have lower temperatures, but that room could then just use local values set.

2. also the parent device could have two "some-heating-on" and "some-cooling-on" devices, which should be switched on if just one of the underlying VSTAT devices have the heating or cooling on. That would allow to switch on the heating system pump, if necessary and switch off again when all valves are closed. Of course I could create an event to switch on the pump if one (or more) of the 14 under floor heatings is on (but that would be a long and ugly OR-statement in Homeseer).

Thanks again for a super plug-in.

Best regards
Rene
Copenhagen

[SteveMSJ]

Hi Rene,

Thnaks for your interest and ideas.

1. create some sort of a parent device which could be used to store global values for at-home-, night- and vacation temperatues as well as weather compensation values. The various VSTAT devices could then either use global or local values depending on whatever is checked on that VSTAT.

Most of my rooms would have the same "needs", however they may follow different schedules (e.g. juniors room, as he is home earlier than we are). Maybe the storage room in the basement could have lower temperatures, but that room could then just use local values set.

This is not something I had really thought about but now seems like a good idea particularly for people using a large number of VStats. I need to give it some thought.

The simplest way to implement it would be to have some global values you could set on the Config page and then the option in each VStat for each SetPoint, etc to sync with the global setting.

However, my initial thoughts are to have a dummy VStat without sensors, modes or controls and then in any other VStats be able to choose which parameters track the dummy VStat. This could include the schedules as well as SetPoints and compensation values. So, changing say a Day SetPoint in the dummy VStat would change the corresponding SetPoint in any VStats where that was linked. Similarly updating the schedule in the dummy could update the schedules in any other VStats that were linked.

In fact, maybe it should be possible to have more than one dummy Control VStat so you could effectively have groups of VStats with various parameters linked to a particular Control VStat. Perhaps rather than dummy VStats the VStats should be configured as Master and Slaves with checkboxes in the slaves to select which features are synced with the Master.
It's already getting complicated to implement but I like the idea so I will explore it further when I have time.

2. also the parent device could have two "some-heating-on" and "some-cooling-on" devices, which should be switched on if just one of the underlying VSTAT devices have the heating or cooling on. That would allow to switch on the heating system pump, if necessary and switch off again when all valves are closed. Of course I could create an event to switch on the pump if one (or more) of the 14 under floor heatings is on (but that would be a long and ugly OR-statement in Homeseer).

I have a long standing plan to implement what I was thinking of as a Boiler Control device. This would have multiple inputs which could be devices controlled by the the VStats or valves or whatever, plus one output Control. For each input you would be able to define a trigger level. So not just Off and On but say above 5%. The output Control would be turned On if any of the trigger conditions were met or Off in none of them were. Whilst I see it as a boiler control it could be turning anything On/Off.

I think this sound like what you are describing as well?

It is in my long term plans but I'm afraid you will need to use events for now. It's not necessary for my current setup because my VStats control Zone Valves in the heating system. The Valves control the boiler directly so if any valves open the boiler turns on.

Steve

[info@kaeseler.dk]

Hi again Steve

Yes, yes, yes...

Your drafted solutions would all work. Both the idea of having global values set as part of the parameters. But also the idea of inheriting values from one, or even better a couple of, template-vstats. I could absolutely use that. That would also be an easy way to have common schedules for several rooms (in stead of exporting/importing those) :-)

Maybe it could then also be possible to set the mode-value for a group of vstats using that template-device. I could use that too, because I have my alarm system connected to Homeseer, so I have an easy way to determine the status change to out of the house/sleeping, so it would be nice to be able to set the mode of all vstats accordingly.

Also the solution having a boiler control device would nicely be able to switch on / off the pump for my manifold managing the underfloor heating. That is today managed by my off the shelf Wavin underfloor heating manifold.

Even if I tried hard, I do not think I can come up with additional ideas. But, I will not promise that. :-)

Thanks again for considering these additions.

[metkhoo]

Instead of a single ‘global’ vstat why not just have a two new fields on every the vstat 1) “is template” ( radio button) and 2) “inherit from” (dropdown with a ‘none’ option) which defines another a “parent” from which values will be called. That way any vstat could become a template or inherit values from any other template. Also by toggling these fields all you need to do is hide or make read only the irrelevant fields for the choice made.
just a thought...
/Marcus

[SteveMSJ]

Instead of a single ‘global’ vstat why not just have a two new fields on every the vstat 1) “is template” ( radio button) and 2) “inherit from” (dropdown with a ‘none’ option) which defines another a “parent” from which values will be called. That way any vstat could become a template or inherit values from any other template. Also by toggling these fields all you need to do is hide or make read only the irrelevant fields for the choice made.
just a thought...
/Marcus

Hi Marcus,

I'm actually well on with implementing this feature and what I am doing is a Master and Slave arrangement not dissimilar to what you are suggesting.
What I have is that now any VStat can be set to be a Slave and for that VStat you can choose a Master from a drop down of all your existing VStats. You can assign any number of Slaves to each Master and have any number of Masters.

In the Slaves configuration you can choose which features are synced to the Master. It could be as simple as just the Schedules.
With SetPoints you will also have the option of setting a temperature offset. So for example you could have a Slave that follows changes to the High SetPoint of the Master but offset by +0.5 degrees.



Any changes to a Master VStat will pass through to any Slaves where the parameters are set to be synced.

This is a pretty fundamental change to the way the pi works so is taking some time to implement, but I think it provides good flexibility. I will post a beta when I have it ready for testing.

Steve

[metkhoo]

Sounds amazing Steve.

[metkhoo]

Does it mean you could build a hierarchy so that slaves can themselves be masters to other slaves??
/Marcus

[SteveMSJ]

Does it mean you could build a hierarchy so that slaves can themselves be masters to other slaves??
/Marcus

The way I have it configured at the moment a Slave cannot also be a Master. I did this to avoid the risk of setting up circular loops. I'm not sure I can envisage a situation where you would want Slaves of Slaves, but if you have a scenario let me know.

Steve

[metkhoo]

I was just thinking theoretically as it were 😊....

[info@kaeseler.dk]

Sounds great Steve
I am truly impressed that you are already working on this. Our IT at work could learn a bit here about being agile and how to ensure a short time to market :-) Looking forward to test. :-)

[metkhoo]

Sounds great Steve
I am truly impressed that you are already working on this. Our IT at work could learn a bit here about being agile and how to ensure a short time to market :-) Looking forward to test. :-)

🤣

[SteveMSJ]

Sounds great Steve
I am truly impressed that you are already working on this. Our IT at work could learn a bit here about being agile and how to ensure a short time to market :-) Looking forward to test. :-)

Thanks for the kind words.

I am about to post a beta for testing with the Master/Slave features incorporated.
I think I will start a new thread in the forum so please post any questions or comments in that thread.

Steve