Multiple Thermostat Scheduler

[spknapp]

Yay!

OK. We'll get you going Steve.
Try 2.01.04. (just the .ash file again)

That fixed it!

Thanks, Greg, for all the fun things you've given us on this board!

[Wadenut]

That fixed it!

Thanks, Greg, for all the fun things you've given us on this board!

No problem. Do let us know how it goes.
I know there's room for some improvement. I need to do a bit more clean up of the code, and I'd like to devise a better method of defining a new delayed start recurring item. Other than that, I've been using it here for about a week now and I've tested with both Zwave and X10 stats as well as the virtual stats.
I think the doc could use some improvement as well which is why feedback is important.

[spknapp]

No problem. Do let us know how it goes.
I know there's room for some improvement. I need to do a bit more clean up of the code, and I'd like to devise a better method of defining a new delayed start recurring item. Other than that, I've been using it here for about a week now and I've tested with both Zwave and X10 stats as well as the virtual stats.
I think the doc could use some improvement as well which is why feedback is important.

I do have a question so far: is there an easy way to define a "simple" schedule without having to input every day and every setpoint for it? What I'm talking about is to define, say:

M-F 5:30 raise the setpoint (so it's warm to get ready for work)
M-F 7:00 lower it (so it cools during the day)
M-F 17:30 raise the setpoint (this gets the house warm to come home to)
S&S 7:30 raise the setpoint (heat for the weekend)
all days 23:00 lower the setpoint (cool for sleeping)

The only way I see to do this is define 5:30 for each day M, T, W, T, F raise setpoint (5 events), 7:00 each day M, T, W, T, F lower setpoint (5 more events), 17:30 each day M, T, W, T, F raise set point (5 more events), then define 23:00 all days lower setpoint. Maybe if you could put multiple days in the day field like "Mon,Tue,Wed,Thu,Fri"?

FWIW

P.S. Document under "Data Fields" still says

Plugin: This field is currently not used and will in future support multiple Plugins simultaneously.<O</O

[Wadenut]

I do have a question so far: is there an easy way to define a "simple" schedule without having to input every day and every setpoint for it? What I'm talking about is to define, say:

M-F 5:30 raise the setpoint (so it's warm to get ready for work)
M-F 7:00 lower it (so it cools during the day)
M-F 17:30 raise the setpoint (this gets the house warm to come home to)
S&S 7:30 raise the setpoint (heat for the weekend)
all days 23:00 lower the setpoint (cool for sleeping)

The only way I see to do this is define 5:30 for each day M, T, W, T, F raise setpoint (5 events), 7:00 each day M, T, W, T, F lower setpoint (5 more events), 17:30 each day M, T, W, T, F raise set point (5 more events), then define 23:00 all days lower setpoint. Maybe if you could put multiple days in the day field like "Mon,Tue,Wed,Thu,Fri"?

FWIW

P.S. Document under "Data Fields" still says

Currently no. I'd have to think hard on that one. It would likely require restructuring the data file as well.

I had a feeling I'd missed that in the doc. Fixed. I didn't bother to increment the version number.

[Wadenut]

I do have a question so far: is there an easy way to define a "simple" schedule without having to input every day and every setpoint for it? What I'm talking about is to define, say:

M-F 5:30 raise the setpoint (so it's warm to get ready for work)
M-F 7:00 lower it (so it cools during the day)
M-F 17:30 raise the setpoint (this gets the house warm to come home to)
S&S 7:30 raise the setpoint (heat for the weekend)
all days 23:00 lower the setpoint (cool for sleeping)

Thought about it. It can be done. I'll define another rule type and maintain the current structure.
It would be Day1-Day2. I thought of perhaps something like Thu-Mon so you could span two weeks as well, but I think that might be too much a nightmare.
Edit: Come to think of it, you may still need two rules for Sat-Sun. Let me think about what I can do.

Give me a day or two. (no pun intended)

all days 23:00 lower the setpoint (cool for sleeping)

This can be done now. Just enter a time without any month or day. It will execute every day.

[spknapp]

Currently no. I'd have to think hard on that one. It would likely require restructuring the data file as well...

No problem; just asking.

Thanks again for all your hard work, Greg.

[spknapp]

(Referring to All Days 23:30...) This can be done now. Just enter a time without any month or day. It will execute every day.

Right, I got this one figured. Thx.

No problem; just asking.

Thanks again for all your hard work, Greg.

Thought about it. It can be done. I'll define another rule type and maintain the current structure.
It would be Day1-Day2. I thought of perhaps something like Thu-Mon so you could span two weeks as well, but I think that might be too much a nightmare.

Give me a day or two. (no pun intended)

Our replies crossed in the mail.

No rush Greg. take some time to do your (paying?) day job.

[Wadenut]

No rush Greg. take some time to do your (paying?) day job.

No problem there. I'm retired. They actually pay me to stay home now. I can put all that energy I used to expend programming PLC's into having fun.

[kesterf]

Greg,

I appreciate your response to my post on the 1st. You made some very good points in response to my "dream sheet" of scheduler ideas.

1) Automatic "Season" change over based on outside temp setpoint (I'm currently using a RFXrec433 with the HS RFXCom Plugin and Oregon Scientific THGN132ES Temp Sensor) The script should select a winter vs summer schedule automatically depending on the "Season"

I'd be interested in how I'd make that decision. Here at least, in the Spring, we might have several days of warm weather followed by another deep freeze. Vice Versa in the Fall. On my system, switching the tstat back and forth from heat to cool, winter to summer, repeatedly would throw everything into chaos... especially my fuel usage statistics.

I agree. As I mentioned, I'm still pretty new to the HomeSeer family. Maybe an easier way to accomplish this is a seperate event toggle the mode of the T-Stat from Heat to Cool and vice versa. It could be based on user input or on the outside air tempurature being above or below a setpoint for a certain number of days.

2) Three types of schedules a "14-Day", "Away (Vacation)" and "Override (Stay Home)". I think two versions of each schedule would be required to accommodate the "Season" mode. Other option would be an temp offset. For example, in the summer we tend to set the T-Stat at 70 degree's F, but in the winter it's usually at 73 degree's F.
___a) "14 day schedule" normal work schedule. I have every other Friday off which requires a 14 day schedule.
___b) "Away" (Vacation) Schedule used when we are away from the house for extended periods.
___c) "Override" (Stay Home) Schedule used when we stay home rather than going to work

You can do this now by entering items for Home and Away modes separately. I'll likely maintain this feature in v2. An item can be scheduled for any: Day of the week, Month, Time of day, or any combination (Monday+January+12:20+Home or Tuesday+11:30+Away, etc). I may add a second field to track the status or value of a second device as well. This could be your Season.
I'm currently working to add "days to repeat" items, intended for those on irregular work schedules. This is proving to be difficult to do while maintaining the existing formats which mimic a thermostats built in schedule.
The plan is to make this as flexible as possible.

Okay

3) When shifting the scheduler into the "Away" or "Override" mode, it should have a two choices for automatically returning to the "14-day schedule.
___a) a check box to return to normal schedule after midnight on the day it's placed in over-ride mode or
___b) a date box that allows you to enter the date the system should return to the normal 14 day schedule.

This could get complicated.

Maybe an easier way would be to modify the Home/Away Virtual Device to have three choices: Home, Over-ride and Away. The schedule could then have lines Home (Normal Schedule), Over-ride (Used for days it's necessary to deviate from the normal schedule) and Away (used to put the t-stats into "vacation mode"

4) It would also be nice to be able to use alternate temp sensors based on the time of day as a poor man's HAVC zone control (or a simpler option may be to average them). For example, One of my AC units serves our Great Room, Master Bedroom and Office. I have a Temp Sensor in the Great Room and the Master Bedroom. It would be nice to control the A/C unit using the Great Room Temp Sensor during the day and using the Master Bedroom Temp Sensor after we go to bed.
5) Option to prevent multiple A/C units from running at the same time.

This is only intended to schedule setpoint changes on individual thermostats. The original idea was to mimic an actuall scheduling thermostat while under HS control.
I may look at adding additional conditions to items in the list later on in the project.

Certainly something that can come later. I'm still having a bit of trouble getting reliable service from my RFXCom, but I think I figured out the problem this weekend. It was a dumb newbie mistake. A didn't save changes in HSProtect after installing the drivers.

Learning some VB and/or VB.Net won't hurt anyone. I think HS is intended to be a little more than a 'consumer' product which is why these tools are made available to us.

Enough of a teaser. I think V2 will turn out to be a universal thermostat scheduler. The approach I'm taking will make any setpoint changes by running a single automatically scheduled event. Thus, this doesn't have the overhead of a plugin.

I agree on learning VB.net. It's just finding the time. I used to know VB and VBA pretty well but it's been over 10 years since I've worked with them. I'm looking forward to your new universal thermostat scheduler. I'm astounded at the generosity of so many experts on this forum. Hopefully, someday, I'll be able to do the same. I would have liked to volunteer as one of your beta testers, but I'm just running z-wave t-stats. Additionally, I'm not sure I'm knowledgeable enough to articulate/troubleshoot problems and since I'm still part of the working masses, finding time to enhance my home auto system is hit and miss.

Forrest

[Wadenut]

Maybe an easier way would be to modify the Home/Away Virtual Device to have three choices: Home, Over-ride and Away. The schedule could then have lines Home (Normal Schedule), Over-ride (Used for days it's necessary to deviate from the normal schedule) and Away (used to put the t-stats into "vacation mode"

Actually, this field was intended to look at the device satus, which choices are On or Off. Later on, perhaps we can add the Device value as well. This would give you virtually unlimited choices.

It would still be up to you to set that value by some other means to determine your season, etc.

Actually, you could get creative now and look at the status of this device in a schedule to determine whether the mode should be changed during a particular month for instance. The device status would be set by your own script based on the temperature conditions you've mentioned.
IE: May & Home is On --> set Mode Cool. (Just because the field is named Home, doesn't mean you couldn't use it for any other condition you like)

[Wadenut]

V2.01.05 is available

This adds support for day of week spanning in a single schedule
IE: Mon-Fri or January + Mon-Fri

Weekends, "Sat-Sun", are a special case due to spanning two consecutive weeks which need to be calculated up to a year or more in advance. This will be dealt with in the near future.

Only the VBEN file and the doc (now PDF) were changed.

[Wadenut]

2.02 Posted.
- I believe this includes everything that's been requested.

- Adds Weekend support. "Sat&Sun" as well as the ability to secify a day range spanning consecutive weeks; as well as a month range spanning two consecutive Years ie. "Dec-Mar".


- "Home" condition field accepts device values or device value ranges. This can be used for seasonal schedules by defining device values (yourself) to represent seasons. For instance: 1=Spring, 2= Summer, ... 4= Winter. The field also accepts "Home","Away","On" and "Off"
You would then enter a Value in the Home Field of 1-4 to have a schedule execute only during Spring and Fall... Clear as mud?

(For now, I've retained the heading "HOME" as this is the original purpose of the field. Can someone perhaps suggest a more inclusive title? No more than 6 characters please.)

This has been tested with the "ZWave Thermostats" and "DooStat" plugins as well as with "Virtual" thermostats created by the user.

Enjoy

[kesterf]

Greg,

Where are you posting the script?

Forrest

[Wadenut]

You'll find the link at the top of this thread

[kesterf]

Thanks. I'm hoping to have some extra time to set it up this weekend since I'll have 4 days off.