Possible method to use different temp sensors based on schedule?

[badbob]

My idea is to use different set of temperature sensors to trigger a thermostat depending on the time of day. For example, during the day, I only care about the temperature of the office and living room. But during the night, I only care about the temperature of the bedrooms.

One idea was to set in Thermostat Controller the weight of ignored sensors to zero so the ignored rooms have no influence over the averaged temp, but there doesn't seem to be a rule function to do that. My current idea is to create separate Thermostat Controller instances for DAY and NIGHT, with each instance configured with desired sensors. Then have a scheduled rule run to toggle the on/off state of the Controllers, which essentially links/unlinks them from the physical Thermostat. So a thermostat that is set to off and free (from controlling the real thermostat) would have no effect on managing the temperature, leaving the "on" ones to affect the thermostat. Does this seem like something that will work or is there a better way? I'm sure I can replace all this with rules but rules take more work to maintain.

Next issue is seeing if there is a way to integrate this on/off task with the Thermostat Scheduler, but probably not. Haven't found a rule function that can determine the named schedule in use (eg: Night, Wake) or trigger on schedule change. I do dislike having to duplicates schedules in the Scheduler and in Rules.

[csteele]

Is this the same discussion from over there?

It feels like you're focused on Thermostat Scheduler as the centerpiece of your design. However, I think you're aware that it isn't going to work for you. I'm convinced you see it as a good starting point, but it's an App that is mimicking the scheduler inside a common thermostat. I know, for instance, it is better than the Scheduler built into my Honeywell WiFi Thermostat. Yet that hasn't convinced me to change over to the Thermostat Scheduler. I've created my own rules to augment the schedule I set inside my Thermostat years ago, before Thermostat Scheduler's release,

The Rule that Bruce created yesterday is a great example, offering options I didn't have back in RM2 days.

[badbob]

That other thread is for using the lowest or highest values among sensors instead of the average.

The real innovation I'm trying to figure out in this thread is using different temperatures sensors for the same thermostat over the course of a day. No point heating rooms with no one in them.

I already have the Thermostat Scheduler in place so I'm just seeing if I can still include it or if I should just replace it. I do see how it tries very hard to mimic the scheduler of real-world thermostats, including the limitations. I do like how it has a GUI.

Could there an alternative GUI app to schedule rules, perhaps with option to pass in parameters (I can pass in heat setpoints)? Actually, I should look into seeing if I can create a scheduler gui using the dashboard, but not sure if there is a tile for picking times and a way to trigger an update rule schedules.

Now I'm curious about this Rule by Bruce you mentioned; have a link?

[csteele]

Thermostat Controller: get lowest/highest instead of average from sensors?

Ah, you know it would have helped to start here instead of where you did. You don't need Thermostat Controller for this, a simple rule can do it. The Heating rule: [Screenshot 2022-11-20 at 9.44.26 AM] Notice setting the Heating Setpoint to 75. This is an arbitrary value, presumed here to be high enough to drag all of the temperatures up to 70. It could be 80, or whatever it takes. The idea is that we want the thermostat calling for heat. Then the Wait for Expression is the test that o…

[badbob]

Oh, that's Bruce. Just clicked his profile.

[badbob]

In this old thread asking for the same thing, it is mentioned that this can be accomplished with restriction settings in the controller:

Thermostat Controller App - Rules to Change config?

I think the way to accomplish this that is the most straight forward is to give the app the same Restrictions options that you can find in Simple Automation Rule. This way, the app could be scheduled to only apply control during certain time periods, days of the week, etc, and to be disabled by switches, etc. With this addition, two instances could control the same real thermostat with different sensors for different times, modes, etc.

Looking at the restriction settings, the wording is a bit confusing (seems like it's saying the controller is restricted to only running at these times (is the mentions of the scheduler instead of controller a typo?) but then there is an option to turn off the thermostat when it's restricted, which is the opposite of running.

If I enable "Turn thermostats off when restricted", then is the controller only ON during the specified starting/ending times and OFF all other times? That would do what I want. But if it's the opposite, then it wouldn't work for me since I have separate schedules for weekend and weekday.

[bravenel]

@badbob

is the controller only ON during the specified starting/ending times and OFF all other times?

Yes.

Back to what @csteele had to say above. You could do this much easier than using Thermostat Scheduler, using two rules and a Hub Variable. The Hub Variable would be used to hold the desired setpoint, and one rule would set that on a per mode basis, like this:

This rule uses Simple Conditional Actions to set the variable to the desired setpoint for that mode.

Then the second rule would be the one I showed earlier, but using that variable for the setpoint:

[badbob]

I think we're getting the two threads mixed up. This thread is about using different sensors depending on the time of day.

So I thought about setting up multiple Controllers with restrictions to ensure only one is active at once and HOPING that once a Controller becomes active, the setpoint of the related Controller device will get pushed to the real thermostat (no rules needed?). But it looks like this idea was already discussed back in 2020 but unclear if it really works and even if it does, was considered a hack:

Virtual thermostat controls physical thermostat

I've been musing about the idea that multiple instances is not really the best way to do what you'd use them for -- viz, changing what sensors are used for different periods of the day, or different modes, etc. While, with restrictions, it can be made to work, it falls into what I would consider a kludge. That got me thinking about Thermostat Scheduler, and thinking that really what is needed is not multiple instances of the controller, but a way to tell one controller how to adjust for differ…

If it helps, the chart below is what I'm trying to achieve. I thought I would need four controllers if trying the restriction option.

It's getting a bit hard to manage. It's also confusing that each controller app instance also creates a controller device. Does the controller device's setpoint get pushed to the controlled thermostat's setpoint?

[badbob]

My my. This is a pleasant surprise with the new update. How long was this new feature baking?

I was also wondering what's the deal with these modes (away, day, evening, night) when they don't match the modes used in the thermostats. Turns out, there is a MODE MANAGER. Perhaps modes can be used as an alternative to the Scheduler. Oh how deep is this rabbit hole.

[badbob]

So I think I have everything in place to change heat setpoint and used sensors based on scheduled mode changes.

1. setup some global variables:
   

   

2. setup mode schedules:
   

   

3. create rule to trigger on mode change to set temps and sensors used.
   

   

[badbob]

It's starting to get daunting as I may have 7-8 modes to account for:
morning, afternoon, evening, away and double that for weekend/weekday

[bravenel]

Inquiring minds want to know: is all of this complexity really necessary? Why don't you use Thermostat Scheduler for the setpoints per mode?

[bravenel]

BTW, I had started on extending Thermostat Controller to allow sensors per mode, but didn't get it finished in time for the 2.3.4 release. I'll probably pick that up again in the not distant future.

[badbob]

@bravenel

Inquiring minds want to know: is all of this complexity really necessary?

(I FINALLY figured out how to quote... like a point-and-click adventure game)
It seems pretty straight-forward (traditional scheduled setpoints + new scheduled sensor weighing). I guess it's complicated since it takes many separate components to realize it. Also, trying to figure out how to make it work is fun. If only all my other network equipment was so customizable.

@bravenel

Why don't you use Thermostat Scheduler for the setpoints per mode?

Just figured out that Thermostat Scheduler can be switched to Hub Modes scheduling. So now I should use both Mode Manager and Thermostat Scheduler.

[badbob]

@bravenel

BTW, I had started on extending Thermostat Controller to allow sensors per mode, but didn't get it finished in time for the 2.3.4 release. I'll probably pick that up again in the not distant future.

Wondering how useful will this be for me. I currently have four modes (morning, afternoon, evening, and away) and the sensors used depends on if it's weekend or weekday (don't even want to think about adhoc events and holidays).

I current have a rule to change the sensors used based on current mode and if it's weekday or weekend. To switch to a rule-less configuration based only on mode, I would need to create separate modes for weekday and weekend:

morning-weekday, afternoon-weekday, evening-weekday
morning-weekend, afternoon-weekday, evening-weekday
away (weekday or weekend doesn't matter)

Seems about the same amount of work either way.

And I also want to tweak the sensors even more based on presence state of people (hence my feature request: [Feature Request] Allow global variable in Therm Controller sensor weight field)

[bravenel]

@badbob

Wondering how useful will this be for me.

Well, irrespective, this will be in the next release. There was someone else who said they could use it. Possibly will add time periods next. Time periods allow for separate groups of days with different schedules, so would allow separate sensors as well.

Also, variables for weight will be in the next release.

[badbob]

@bravenel

Well, irrespective, this will be in the next release. There was someone else who said they could use it. Possibly will add time periods next. Time periods allow for separate groups of days with different schedules, so would allow separate sensors as well.

Also, variables for weight will be in the next release.

Cool! Looking forward to it. More options are good for everyone.

[badbob]

Noticed that it's not possible to specify the weight variables when specifying the controller's sensors. Which is fine as I think I'm switching tactics and no longer dynamically assigning sensors to controllers and just focusing on the temp weight:

• Manually add ALL sensors to controller and specify a weight variable for each.
• Have a rule per sensor that triggers when the temperature changes:
  • if temp is >= controller's setpoint, set weight variable to 0. This ensures a minimum temperature across all sensors.
  • if room's occupant is not present, set weight variable to 0
  • Otherwise, set weight variable to 1