Just tested the issue I was seeing and can confirm it's now fixed.
Thanks again.
1 Like
Same here. Seems to work fine now. Thanks for the quick response.
Would love to see a feature in a future release that allows for remote temperature sensor to be used (Similar to Keep Me Cozy on ST).
1 Like
Yeah, I actually started down this path when I first started developing Thermostat Scheduler. Are you referring to a remote temperature sensor in addition to the thermostat, or as a replacement to the thermostat?
1 Like
Great question.. right now I ported over Keep Me Cozy II which replaces the thermostat temp with a remote temp and serves my need. My specific use case is a thermostat in one of the worst possible places for temperature monitoring. If you used a remote sensor in addition to the thermostat how would you envision that working? Would you average between the two? or some other method?
Either / both.
That is the main thing that makes me not switch from Ecobee to a more local/zwave/zigbee solution. On multiple of my 4 thermostats I run off of a remote sensor and ignore the built-in thermostat temp reading because it is in the wrong location or inaccurate.
Where inaccurate, simply adjusting setpoint based on the other remote temp doesn't work as the thermostat location either has a vent blowing right on it, gets hot air from outside, etc. Making the built-in temp unreliable altogether. Sometimes it is unresponsive to temp changes, other times it will read completely incorrect and go a different direction altogether than the real temp (due to some of the reasons above).
Obviously the best answer would be to move the thermostat. But instead of that I went the Ecobee remote sensor route.
The replace is the easier one to do, but still raises some issues about how the thermostat is controlled. This isn't really within the direct scope Thermostat Scheduler. One way to go about this would be to use a Virtual Thermostat, feeding temperatures from the remote sensor into it, and taking it's operating state events to control the real thermostat with simple triggers in RM. With this approach, the Virtual Thermostat could be put into Thermostat Schedule, who wouldn't know or care that it was this odd contraption. Our Virtual Thermostat driver does not implement this at the moment, but could in a future release without a lot of effort.
Using additional sensors raises all sorts of very thorny issues and is why I didn't go down that path. Basically, I'd have to implement all thermostat logic, which is non trivial, in an app. I realized pretty quickly that we aren't really in the software thermostat business, while folks like Honeywell and Nest are.
1 Like
I was actually working on a smart app to do something similar.
I wanted to get away from relying on the ecobee sensors alone for adjusting temperature in the house and allow the use of other sensors as well.
Some of the logic included pairing a temp sensor with motion sensor so I know what to exclude/exclude in temperature calculations. Unpaired sensors will always be included. I also looked at including sensor with motion in the last X mins. Also had a few other items I used for calculations.
The only thing that bugged me is that the thermostat would keep changing. So if I set it to 21, it would go up and down to try and keep things even. This would confuse the others in the house.
So for now I have my ecobee sensors managing it still.
1 Like
I've been looking for a similar solution for my home. The problem I have is the missing dynamics currently supplied by my thermostat.
I have baseboard Hot water heat with the water coming from a boiler. This type of system suffers from significant time lag. The old mechanical thermostats used an "anticipator" function to turn the boiler off before the target heat has been reached, allowing the temperature to "coast" to the correct value.
I haven't figured how to do this with a (any) hub based controller and a remote thermometer. I need to qualify that by saying for me a cloud based solution is not acceptable.
@bravenel Is there any access to which of the time periods, Wake, Leave, Return, Night, etc is currently active in the scheduler so that it could be displayed in a dashboard tile as an attribute? If not would it be possible to add?
1 Like
I'm trying to figure out Thermo Scheduler too... I had it so my temps changed at the right times, and also when all my presence fobs were gone it correctly switched to the specified temp. But it did not seem to know when we returned. The temp stayed at the Away state when I got back home. In desperation I adjusted it manually on the device, and now it is just staying at that temp instead of changing to the next scheduled temp when the time arrives. I tried going to the devices page and pressing some of those buttons to see it it would go back to the desired schedule, but no. I tried the Auto button, the Config and the Refresh. That just messed it up totally. The "target Temp" is now 64 when its supposed to be 70. What am I doing wrong? What tells it you are no longer away? And how do I get it back on schedule?
You can check the App Events from the App status page (gear icon). It sounds like this is a thermostat issue if you can't control it from the device page. What kind of thermostat is it?
RT 101. Right now, it should have the heat set point at 70. But it's stuck on 64. Also, what is the "thermostatSetpoint"? I don't have anything set to to 73. Why are there three set points? Here's what the log says... I'll go click the gear in a minute:
dev:1382019-02-19 06:30:43.224 pm infoThermostat Downstairs thermostatSetpoint is 73Ā°F
dev:1382019-02-19 06:30:42.176 pm infoThermostat Downstairs thermostatFanMode is auto
dev:1382019-02-19 06:30:40.240 pm infoThermostat Downstairs thermostatOperatingState is idle
dev:1382019-02-19 06:30:38.179 pm infoThermostat Downstairs coolingSetpoint is 82Ā°F
dev:1382019-02-19 06:30:36.218 pm infoThermostat Downstairs heatingSetpoint is 64Ā°F
dev:1382019-02-19 06:30:34.182 pm infoThermostat Downstairs thermostatMode is auto
dev:1382019-02-19 06:30:32.179 pm infoThermostat Downstairs humidity is 20%
dev:1382019-02-19 06:30:30.385 pm infoThermostat Downstairs humidity is 20%
dev:1382019-02-19 06:30:30.174 pm infoThermostat Downstairs temperature is 67Ā°F
dev:1382019-02-19 06:30:29.371 pm infoThermostat Downstairs battery is 100%
dev:1382019-02-19 06:30:21.884 pm warnconfigure...
OK... the gear icon info says that it thinks the time period is "evening". But why it's set for 64 instead of 70.
Does this look normal?
| timeHandler | 2019-02-20 6:15:00 AM PST | PENDING | 0 15 6 * * ? | |
|---|---|---|---|---|
| timeHandler | 2019-02-19 9:00:00 PM PST | PENDING | 0 0 21 * * ? | |
| timeHandler | 2019-02-20 6:00:00 PM PST | PENDING | 0 0 18 * * ? |
Sorry I'm making a mess of this question. Here is what the gear icon says:
One thing I notice is that it mentions the "Return" time period, which I was using at first, but then I deleted in in favor of one called "Evening" I wonder if that messed it up. I notice that these rules get stuck to devices even after you delete them. Maybe I should throw out this instance of ThermoScheduler and start again?
| atTime1Evening | time | 6:00 PM |
| atTime1Night | time | 9:00 PM |
| atTime1Return | time | |
| atTime1Wake | time | -6:15 PM |
| cool1Evening | decimal | 78 |
| cool1Leave | decimal | |
| cool1Night | decimal | 82 |
| cool1Return | decimal | |
| cool1Wake | decimal | 78 |
| deletePeriod1Evening | bool | |
| deletePeriod1Night | bool | |
| deletePeriod1Wake | bool | |
| ecoSet | decimal | |
| heat1Evening | decimal | 70 |
| heat1Leave | decimal | |
| heat1Night | decimal | 64 |
| heat1Return | decimal | |
| heat1Wake | decimal | 68 |
| manCoolPt | decimal | |
| manHeatPt | decimal | |
| manHold | bool | |
| manMode | enum | |
| morePeriods0 | bool | |
| morePeriods1 | bool | |
| schedType | bool | |
| therm | capability.thermostat | Thermostat Downstairs |
| time1Evening | enum | A specific time |
| time1Night | enum | A specific time |
| time1Return | enum | A specific time |
| time1Wake | enum | A specific time |
| timeAway | bool | true |
| timeAwayCool | decimal | 82 |
| timeAwayHeat | decimal | 64 |
| timePeriod0 | text | Evening |
| timePeriod1 | text | |
| useDays | bool |
Event Subscriptions
Source Event Handler Filter
| Farmhouse Hubitat (Location) | thermSched | extHandler | false |
| Farmhouse Hubitat (Location) | mode | timeAwayHandler | false |
Application State
Name Value
| coolingSetpoint | 82.0 |
| currentN | 1 |
| currentPeriod | Evening |
| ecoSet | |
| firstTime | true |
| heatingSetpoint | 64.0 |
| manHold | |
| modeTable | {} |
| numberOfTimePeriods | 1 |
| oldLabel | Thermostat Downstairs |
| oldOrder | [Wake, Evening, Night] |
| schedType | true |
| timeAway | true |
| timeSort | [Wake, Evening, Night] |
| timeTable | {Night={Thu={heat=64.0, cool=82.0, time=9:00 PM}, Tue={heat=64.0, cool=82.0, time=9:00 PM}, Wed={heat=64.0, cool=82.0, time=9:00 PM}, Sat={heat=64.0, cool=82.0, time=9:00 PM}, Fri={heat=64.0, cool=82.0, time=9:00 PM}, Mon={heat=64.0, cool=82.0, time=9:00 PM}, Sun={heat=64.0, cool=82.0, time=9:00 PM}}, Evening={Thu={heat=70.0, cool=78.0, time=6:00 PM}, Tue={heat=70.0, cool=78.0, time=6:00 PM}, Wed={heat=70.0, cool=78.0, time=6:00 PM}, Sat={heat=70.0, cool=78.0, time=6:00 PM}, Fri={heat=70.0, cool=78.0, time=6:00 PM}, Mon={heat=70.0, cool=78.0, time=6:00 PM}, Sun={heat=70.0, cool=78.0, time=6:00 PM}}, Wake={Thu={heat=68.0, cool=78.0, time=6:15 AM}, Tue={heat=68.0, cool=78.0, time=6:15 AM}, Wed={heat=68.0, cool=78.0, time=6:15 AM}, Sat={heat=68.0, cool=78.0, time=6:15 AM}, Fri={heat=68.0, cool=78.0, time=6:15 AM}, Mon={heat=68.0, cool=78.0, time=6:15 AM}, Sun={heat=68.0, cool=78.0, time=6:15 AM}}} |
Scheduled Jobs
Handler Next Run Time Prev Run Time Status Schedule
| timeHandler | 2019-02-20 6:15:00 AM PST | PENDING | 0 15 6 * * ? | |
| timeHandler | 2019-02-19 9:00:00 PM PST | PENDING | 0 0 21 * * ? | |
| timeHandler | 2019-02-20 6:00:00 PM PST | PENDING | 0 0 18 * * ? |
What I was suggesting is that you click on Events on that App Status page. That will show you what Thermostat Scheduler did. So you can see if it is doing what you expect or not. I think you will find that the issue lies with the thermostat itself.
Oh, sorry. I didn't notice the "events" tab,
So, if this is the app sending instructions, it stopped yesterday morning. My fobs left, and it seems to have correctly gone into Away... but when I came back for an hour, it apparently never resumed the schedule. (Is it supposed to? With no documentation I can find, I really don't understand what the app can or should do). Anyway, it never resumed schedule. Then I left town for a day, and returned late afternoon on the 19th. I see it never registered me leaving again or coming back, either yesterday or today. At 9:27 am on the 18th, everything stopped while I was "Away".
| ThermoScheduler | Days/Times Schedule Away | Cooling Setpoint 82.0 | 2019-02-18 09:27:19.238 AM PST |
|---|---|---|---|
| ThermoScheduler | Days/Times Schedule Away | Heating Setpoint 64.0 | 2019-02-18 09:27:19.205 AM PST |
| ThermoScheduler | Days/Times Schedule | Cooling Setpoint 78.0 | 2019-02-18 06:15:00.314 AM PST |
| ThermoScheduler | Days/Times Schedule | Heating Setpoint 68.0 | 2019-02-18 06:15:00.267 AM PST |
| ThermoScheduler | Days/Times Schedule | Cooling Setpoint 82.0 | 2019-02-17 09:00:00.270 PM PST |
| ThermoScheduler | Days/Times Schedule | Heating Setpoint 64.0 | 2019-02-17 09:00:00.235 PM PST |
| ThermoScheduler | Days/Times Schedule | Cooling Setpoint 78.0 | 2019-02-17 06:00:00.156 PM PST |
| ThermoScheduler | Days/Times Schedule | Heating Setpoint 70.0 | 2019-02-17 06:00:00.138 PM PST |
| ThermoScheduler | Days/Times Schedule | Cooling Setpoint 78.0 | 2019-02-17 03:58:07.817 PM PST |
| ThermoScheduler | Days/Times Schedule | Heating Setpoint 68.0 | 2019-02-17 03:58:07.790 PM PST |
I am going to ask this question here in hopes that it clears my situation up without going into a long drawn out post.
I thought that by setting a time/day schedule and an away setpoint that my thermostat would run on it's schedule when I am home (home mode) and hold at the away temp (away mode) until I returned home (home mode).
I found that upon returning the temp would stay at the away hold temp until the next time/day event in the schedule.
I solved this by creating rules that set the temperature appropriately depending on the time of day of my arrival. It then seems to carry on with it's time/day schedule.
What I am finding now is that the temperature is set at the away temperature upon departure but the schedule takes over again at the next time/day event.
Should it not stay at the away setpoint until the mode becomes home upon my arrival.
Guess this is still the long version. Sorry
I found that by setting thermostat scheduler into hold and then run again immediately it forces it to update the setpoint(s) to what they currently should be. I use it if I have made any changes to settings in RM, I set it to hold, make the changes and then run and it immediately takes up the new settings whereas otherwise it would wait until the next time change. So if you created a rule that did that on return from away it would fix it I think. Ideally scheduler would do that automatically but it is a work round.
1 Like
While the thread is revived, I thought I'd bump my request for the current active time period to be made available as an attribute or similar so that it could be displayed in a dashboard.
The current setpoints are obviously available through the thermostat itself, but it would be very helpful for an "at a glance" check as to the state of the scheduler.
3 Likes
