Possible method to use different temp sensors based on schedule?

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.

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. :slight_smile:

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?

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

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

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.

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:

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:

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?

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.

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.

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

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

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.

(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.

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

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)

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.

1 Like

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

Download the Hubitat app