From what I can see on the UI, there is no support for scheduling - “in the morning turn the heat up, then turn it down when I leave, then turn it up when I come home”.
Ideally that should be editable from the UI (albeit with some fiddliness), and easily editable from the Web UI.
It probably should have a level of indirection: the scheduling sets a state (e.g. at 0600 set the state to “morning”), and then the settings are set when entering that state (for state morning, set target temp to 78F). That would allow easy overrides of the temperature - it will automatically reset on the next state change - as well as editing a state and its entry conditions.
That would also allow things like “hey smartwatch, when you see me get out of bed around 0600, send a message to change to morning”.
These are exactly the types of improvements I’d like to see made. I have a whole list of these types of features. I thought I posted about one on here, but I can’t find it now. The short version is that a calendar should be shared with the thermostat and if there’s going to be movie night, it should look at who will be there and figure out what an appropriate temperature would be for that set of people (and there’d have to be way to set a profile for each person so it knows Hans likes it 24-28C and Juan likes it to be 18-26 or whatever). The thermostat would only know about events that it was invited to in order to maximize privacy. That’s what I expect of a “smart” thermostat to live up to the name.
My hack to do scheduling was to set up a few cron jobs. It got the job done and kinda ruined my motivation to knuckle down and learn enough OpenHAB to knock that out in a proper way.
I thought I shot high… Looking at participants in an event and trying to select a temperature for all of them? That’s… aggressive. It will probably be an over-constrained equation with no solution.
Yeah, it may be aggressive, but it’s what I want so I’m going to go for it anyway… if I can only find the time.
And if there is no solution for a given set of people, I expect to the code to just do the best it can. The algorithm might start with something like “take the center point of everyone’s range and then average them” and then it can get smarter from there (or maybe that will suffice, only testing will determine that).
Let me give you my counter-proposal: A series of simple, user defined state machines.
The first would be the operating state of the thermostat. It would define the actual relay states. For my application (heat pump with 2nd stage gas), it would start out with IDLE, FAN, “HEAT PUMP”, “GAS HEAT”, “COOLING”, “BOOST HEAT”, “BOOST COOL”.
The user can define additional state variables - more on this later, but I’ll give an example here: I would define a variable “Constraint” with “None”, “Gas only”, “Electric only” - that would allow me to prevent using gas heat if the propane delivery is late and I’m low, or prevent electric if I am in a power failure and running on generator.
Next would be a state machine for Goal - this sets temperature limits. The user can define any Goal they want, defaults would be “Sleeping”, “Awake”, “Away”, but you could add e.g. “Working”, “Movie”, “Wake up” or what have you.
Next would be a Day of week state machine.
Then there would be a “type of day” machine - “Work day”, “Weekend”, “Vacation”. You could add e.g. “Work from home”.
State machines get and send messages - getting a message can change state, and state changes can cause messages to be sent. Messages can also be sent on times (a la cron) or in response to UI or other drivers.
All messages are sent to all state machines - they are free to ignore anything they don’t need to process.
For the purposes of this example, {foo} is message source foo - a state machine name, or some other system resource.
(narf) is a message.
{foo}.(narf) is state machine foo’s response to getting message narf.
So you can have things like this:
{cron at midnight} Send(New Day)
{Day of week}.(New Day) advances {Day of week}'s state variable to “Tuesday” and Send(IsWorkDay)
{Type of Day}.(IsWorkDay) sets state to “Work Day”, Schedule (isWakeup) at 0600, Schedule (IsAway) at 0800, Schedule (IsHome) at 1700, Schedule (IsSleeping) at 2200.
{Goal}.(isWakup) sets state to Wakeup, sets the temp limits.
Operating state evaluates temps and does its thing.
Operating state might see temp is X below setpoint and think about going to GAS HEAT, but see Constraint = Electric only and instead go to electric.
Of course other things could participate - you could have a Google Calendar reader looking for calendar events with a special string in them, and doing things like “If event contains “#HestiaPi Vacation” then send a (Vacation) message”, and the Type Of Day machine might go to Vacation mode and not leave it due to the messages from the Day Of Week mode. Or you could have some form of instant messaging client do the same sort of thing.
I missed this when it was first posted.
I do not remember anymore when this was added. But I think the iCalendar binding was available in OH 2.5 (seems to be in the docs so yes). This lets you use any iCal calendar to create events in OH. That is the most direct approach to achieve this.
The supported Channels on the 2.5 version of the binding are somewhat limited but the latest version supports a few more. But I don’t think even it gets the list if invitees so you’d have to encode that into the text of the event somehow and parse the people and their preferred temp ranges from that.
I don’t think this is really all that hard to achieve, assuming you can figure out the algorithm to choose the appropriate temperature. The calendar stuff is already done for you.
There’s also a third partyextension (not really a plugin) that provides a scheduler interface for OH. That might be worth looking at.
There is also a “Time of Day” state machine which I originally came up with way back in OH 1.6 days and have kept up. Today it’s a rule tempalte that can be just installed and configured. But this can be used to schedule regular time of day based events. It even uses ephemeris so you can have different time of day events for holidays than work days (for example).
Beyond that, the existing rules for HestiaPi are a state machine approach as well, though admittedly a bit more comoplicated than I would have liked. I always wanted to go back and simplify but most of what I need to do so are only available in newer versions of OH.
This is built into OH since 3.2 (IIRC) through Ephemeris. It supports not only week day and weekend, but holidays as well as the ability to define custom types of days (e.g. trash day, birthdays). It pulls the default list of holidays based on your regional settings.