Thermostat Controller 2.0 to allow for dynamic temp sensor placement (feature request)

[manuelangelrivera]

Been using the Thermostat Controller for some time now and recently migrated to ver 2.0.

My use case, I have disparate temperature sensors deployed across my home on each room.
So depending on the time of day and other variants, I have grouped those temperature sensors and then use @bravenel app "Average Temperature" in combination with a rule to append that averaged result to a global variable. That global variable has a virtual sensor temp driver connector counterpart which then finally I use as my temp sensor for the Thermostat Controller app.
What I have accomplished with this, much like common comercial thermostat (Ecobee), now I am able to isolate temp sensor individually, so in a matter of speaking, AC zones based on only sensor that I desire during that scenario. For example, during my night mode, I would swap the grouping of averaged sensor to pass only the sensors in my master room.
Effectively, I have turned my dumb thermostat into a "smart" one.

The problem I have with this current design is that the way that Bruce's "Average Temperature" app works, I have to provision several child processes to fit my various scenarios and then this "Average Temperature" app would be triggering the average process depending on any of the grouped sensor changed status.
Then all those child processes would be looping in the background for all the App child regardless of if I need them or not.
As you could expect, the frequency of looping updates of each APP child iteration and the time spent processing the rule for the dynamic placement can become unruly, it will take a toll on my general hub utilization and affect my performance responsiveness.

What I propose is to incorporate this feature into the Thermostat Controller as averaging is already baked in, but unalterable unless you interact with the HUB gui and change it manually.
Ideas that I think it would be the most effective:
-Update RuleMachine, and introduce a new rule that would allow to swap/change/alter the sensors for the Thermostat Controller.
-Modify Thermostat Controller code and implement something similar to rules, where if an expression is met, dynamically change the sensor grouping.
-Or... please, please, introduce a RuleMachine action where you can select a group of sensors and perform math operations or even a dedicated routine to average a group of sensors.
RuleMachine in its current state can't do math in significant way, unless you dedicate a variable and do the current variable math action, which has been proven to be either too limited or would require countless of line of code to accomplish any math operation.

To briefly overview the design I currently use:
-This is Bruce's APP child processes (Notice that I have reduced to only 5 to be able to maintain adequate performance):

-Global Variable that serves as placeholder for the dynamic grouping:

-RuleMachine that swaps sensor grouping averages value towards the sensor place holder for the controller:

-Finally, the controller:

Thanks for your time and effort.

[csteele]

Critical item... there's no looping.

Each temp sensor sends a Z-radio message and that becomes an Event. Events are the "energy food" of Hubitat. Every Event is subscribed to by apps and when an Event arrives, the actions result. In other words, if the temp sensors don't send a message for an hour, then Average is doing nothing for an hour. When an Event arrives and the Average App is actually subscribed to it, the Average App gets pulled in from the DB and run, passing the Event to the App. The App does the averaging and updates a value and that App memory is freed.

The Average App is driven exclusively by the quantity of Sensors you select and the Parameters you've set for them. If you picked 3 seconds temp updates, then that's what they would do and your hub would be quite overworked. Temp updates at 10-15 mins would, conversely, be a good balance for less than 15 sensors.

[bravenel]

It sounds as though what you need is averaging per mode. It would be a straight-forward change to the Average Temperatures app to allow that. Same change conceivably could be done to Thermostat Controller directly.

Like this:

If using modes, there would a page that opens to set them up:

Then, as the modes change, it simply uses a different set of sensors to drive the rest of Thermostat Controller.

Would this work for you?

[manuelangelrivera]

Thats a way doing it. But in my scenario I have a 2 story house with two thermostats and over 7 rooms between two floors. I need to be able to change the thermostat sensors based on presence using my 2 per room motion sensors. They way you propose the flow is to create a mode for each possible scenario and then apply a per mode basis. What I would like to be able to do instead, is to change the Thermostat Controller appointed provisioned temp sensors on the fly rather than governed by modes, and have the controller reinitialize and re-average with the updated sensor grouping, then whenever an "expression" met. This way I don't need any external app to help me average. Maybe allow a rulemachine action to change the sensors configured at the controller. Or instead, means to easily perform avg's in rule machine and then pass that calculation to a global variable, similar as the "placeholder" method I am using currently.

In summary, the way I have its working exactly as I intend, but I thought there is room for improvements and a more streamline way of doing it if only I had the right features.
Thanks for looking and your hard work.

[bravenel]

@manuelangelrivera

the way I have its working exactly as I intend, but I thought there is room for improvements and a more streamline way of doing it if only I had the right features.
Thanks for looking and your hard work.

Unfortunately, what you describe is a tremendous amount of complexity to embed in an app like Thermostat Controller. I certainly understand what you want to do, but introducing dynamic sensors into Thermostat Controller is effectively introducing the conditional logic of Rule Machine, which makes no sense to do.

So, using RM to change the sensors in use in Thermostat Controller? I will look at that idea. You'd still have the same logic in RM you have now, but just different actions embedded in it.

[manuelangelrivera]

Thanks @csteele. Currently the way I designed it is to have inmediate average calculation upon new sensor telemetry updated. In other words. the "Average Temp" app is constantly looping and if sensor change is detected it will trigger the app and perform the average that then is passed to the placeholder. I want it to be realtime everytime a new average has been calculated, yes. Then my rule would trigger upon a new average calculation is updated which will determine what average to place at my appointed placeholder sensor, which is the provisioned sensor for my thermostat controller.
My main point of grief, I would like to eliminate any average app's by using the thermostat controller already baked in function and only average the sensors that I need per my required scenario or "expression". The way that is working now, I am calculating all averages at once for all my possible scenarios. Then I pass only the single average of just one scenario to the therm controller. So if we were to have an action rule to modify the existing sensor grouping to the controller, I would not need at all the avg'ing app to begin with and then I pass only the sensors I need per basis. This would allow me to exactly set my thermostat to react to only to the temperature sensors I want, without having to shift into a whole new mode and all that entices.

[manuelangelrivera]

Thanks for your promptness. Then a simple RM action that would allow to change sensor grouping would be ideal for my use case. As this would allow me to eliminate the need of the avg app and I can then use the controller instead for my averages during my specific "expressions" are met within RM.
Thanks for considering it and keep up the fantastic work.

[mrandy]

A related question as here is the problem I am trying to solve: I have remote temp sensors in all the bedrooms upstairs but sometimes one room will get very hot while the others are still pretty cold. Many times this is time of day related and based on where the sun is shining at the moment. Is there anyway to dynamically change the weight of a sensor based on the overall average of all sensors. If its winter I want my coldest sensors to take priority. If its winter I want my warmest sensors to take priority.

[bravenel]

@mrandy

Is there anyway to dynamically change the weight of a sensor based on the overall average of all sensors.

Yes, it is now possible to use a variable for the weight setting (a number or decimal). You'd have to have a rule that sets the variable per your desired logic.

[manuelangelrivera]

Thank you for your work good Sir. I will do some testing and see how will behave and post back with my findings or succes.

[manuelangelrivera]

@bravenel I thank you for including this marvelous addition to our Virtual Thermostat template. I have been a first adopter of it since its origin and your team just have made it even better. After having test it on my live production "aka home ;-)" I have to say it is working as indicated. Much appreciated.