A feature request, unless available and I'm missing it:)
Ability to assign day-mode (ie Wake, Night etc) to a temp sensor.
For example: Wake is set to main level temp sensor while Night or "Sleep" is set to upstairs Master Bedroom temp sensor.
I'm about to transition from ecobee, which has this option, to a z-wave thermostat and this one feature is a deal breaker for us because otherwise in order to sleep comfortably you need to make a lot of usually inaccurate assumptions about the difference in temp downstairs vs upstairs and daytime vs night time and how that changes throughout the seasons.
I understand this can potentially be solved via node-Red but am hoping for an easy solution within the hubitat scheduler (or similar app/rule option) before digging into that.
First of all, Thermostat Scheduler does not work with temperature sensors, just with thermostats.
Second, you can do what your describing pretty easily for a temperature sensor. Create a virtual temperature sensor. This offers a command to set its temperature. Create a rule, triggered by a change in either real temperature sensor. When the mode is Wake, set the virtual temperature sensor to one sensor, and for Sleep to the other sensor (you will need Custom Action to set it). Now, this virtual temperature sensor has the value you want at any given time, changing as those real sensors change.
So now the issue is how to control your Z-Wave thermostat so that it is acting based on the external temp sensors instead of its own internal temperature sensor. In effect you want to usurp its normal functioning. You could create a virtual thermostat that you can manage with Thermostat Scheduler. And use a rule or two to control the real thermostat based on what the virtual thermostat does, and control the virtual thermostat temperature from your virtual temperature sensor from above. Or, short-circuiting some of this complexity, you could dispense with the virtual temperature sensor completely, and as described in the previous paragraph, control the virtual thermostat temperature with a rule as described.
I guess the final part of this is how you take control of the Z-Wave thermostat so you are forcing it into heating and cooling operation as determined by your virtual thermostat. One obvious way to do this is to simply manipulate its setpoints. When your virtual thermostat calls for cooling, you push the real thermostat's cooling setpoint down, thus causing it to start cooling. Etc.
Ok thanks for the guidance. Any idea if what you described would also allow for manual inputs at the thermostat itself...for example the DAY mode is running but it's still too warm so my wife walks up to the thermostat to turn it down 2 degrees.
The thermostat is ultimately the device that is controlling your HVAC system. All we're doing is manipulating it. If you use Thermostat Scheduler to set a cooling setpoint for it, even through an indirect scheme, it still is going to have a setpoint that is calling for cooling. So yes, if you manually lower that setpoint, that's going to change the way it operates.
This idea from my prior post is not simple, and needs to be carefully constructed.
Please add a optional fan setting (auto/high/medium/low/quiet) to the thermostat scheduler, where a scheduled event may change the temperature and/or fan setting.
It will remain up to the device driver as to whether & how the fan directive is used.
If not present, default to the current behavior (which seems to be setting the fan to "high").
I'm missing what this has to do with scheduling a thermostat. Are you talking about the HVAC fan mode? Or about a separate fan device? Thermostat Scheduler is an HVAC thermostat controller. Most thermostats only support on/auto for HVAC fan control.
Wake: 8AM, cooling set point OFF, mode Fan, fan speed high (ie., allow the room to get warm during the day, but keep the air moving)
Evening: 8p, cooling set point 68F, fan high (ie., cool off the room quickly, allow the fan to be loud)
Night: 9p, cooling set point 70F, fan quiet (ie., keep the room cool overnight, at a low fan volume)
I'm talking about HVAC fan control at the moment -- but TS wouldn't need to know the hardware specifics, just the capabilities of the thermostat.
While TS could control physical thermostats (and, by extension, the devices attached to the thermostat), I think that the greatest potential is in using TS to manage virtual thermostat devices. The virtual thermostat (which could control a smart window AC, an HVAC unit, a heater-only unit, a smart fan, variable speed pumps on a hot-water heating system, etc) can provide fan control that's consistent with the physical device, if it has fan control.
A better way to word the feature request might be that TS should allow control of all the features exposed by the thermostat itself (including fan speeds, if available).
This would allow users to configure heating/cooling/fan schedules from a single interface (Thermostat Scheduler) while automating multiple devices with differing capabilities. Obviously, it's up to the user to enable the controls (ie., fan values) appropriate to the device being scheduled. This is consistent with the current design of Thermostat Scheduler (ie., I use it to control my baseboard hot-water radiators, but don't try to enable 'cooling' in those schedules).
That new fan control looks nice to have. I use rules and my PM2.5, CO2, and VOC sensors to push the fans, but that would head off the problem before it occurred.
However Iām here for troubleshooting help. I recently replaced an ecobee with a $20 - $10 coupon with a GoControl. I cannot use the stock driver because it canāt be exported to google home and I want the capability to voice control. So I'm using the BPTWorld one. Below is my screenshot of thermostat scheduler, the relevant logs, and the device itself. I first noticed the proble the very next day and it happens every morning that high or low is wrong, I ignored the first two as stabilization. Iāve not yet turned on the pc so these are from my iPad and in safari since iOS chrome doesnāt support client certificates.
Sure, sorry for the lag but I was on the treadmill and then recovering with a mindless iOS game. Still no PC because Iāve been asked to stay really low key and mentally recover from way overdoing it on the 4th.
Last night it switched fine, this morning it was wrong again. This time it was doubly wrong, it set to 73/76 instead of 73/77. That is invalid according to the 4 degree setpoint spread requirement, Both still have null set point in the logs. In the process of screen grabs I noticed that when I went to the gear on the scheduler app that it fixed the problem.
A possible clue is that viewing the events triggered changes. The log shows 3 setpoints commands right after I hit that page. The normal heat and cool and then a second cool immediately.
Iāve had both the Nest e (first smart home purchase) and the latest Ecobee (won from TVA) required the cloud which is suboptimal. And the nest device itself ran extremely hot, while the ecobee caused dozens of connection errors, but they were consistent. I donāt even have a complex schedule. No days or times, just day (home) / night / away (rarely). Iām not sure a different zwave or zigbee thermostat will help since itās the native hub scheduler with an issue. I suppose there is always using my Homebridge/HomeKit with a HomeKit compatible non-cloud thermostat, but then I have to change my air quality maker api scripts to feed homebridge via mqttt.
Ok, this shows the three hits when I hit the settings icon this morning that fixed it like I mentioned above No one manually manipulated the thermostat or even has good access to Hubitat.
Edit: just be be clean the 6am set to 77 (from 75) did not work properly. It set to 76. The one of the three triggered when I manually viewed the page did.
Just to cutoff requests to use the stock driver, Iād be happy to when it allows me to share it with google. Fix the missing attributes/subclasses/whatever in stock and Iāll switch right then.
If you're using a custom driver for these, I can't really help figure out what's going on. What driver is this? It's showing "physical" for events that should be "digital". The logs for Thermostat Scheduler clearly show setting the thermostat setpoints to 73 and 77, while the thermostat logs show 76. I can't tell you why that is, other than to make the observation that the 76 is coming from the driver, not from the app.
So for now, you'd have to use the built-in driver and show failures with it for me to be in a position to see what's going on. I'm not requesting that you use it, just making the observation that I can't dig into this with the driver you are using. It's also worth noting that at this point the only anomaly shown with Thermostat Scheduler is the third duplicative setpoint event at 10:27. You said, "right after I hit that page", but I don't know what that means. Do you mean hitting the button "Set Scheduled Setpoints"?
I don't know why the 10:27 event shows the 3 setpoint events. I'm not able to reproduce that behavior.
I would suggest that you remove this instance of Thermostat Scheduler and recreate it. Meanwhile, a new version of Thermostat Scheduler will be in the next release. The only thing in it that bears on this is the bug in the log text where it says null.
