Event Scheduler

Here are some examples of shedulers:

http://www.switchking.se/images/stories/switchking/screenshots/client/v3.0/SKMainDevicesBig.PNG
And:

I agree with your scheduling requirements:

  • Different modes like Home, and Away .
  • Weekday based scheduling: Mo-Fri, weekends eg. “Do this on Mo, Tu and Fri”
  • Relate to sunset/rise “I want my lamps to turn on 20 min before sunset” or " Lamps should be turned on at 06:00 and be on until at least 08:00. if it is dark and 08:00 they should stay on, but no longer than to 09:00"

One of these examples above have javabeans code that execute, Before, On , After the sheduled event: Return code of “Before” determines if event occurs. “On” is executed (iirc) instead of the event. “After” always runs. In my view, triggered code is a nice way of being able to extend the scheduled for more complicated scenarios.

In one you create sceduled for a device, in the other you create scedules, and attach devices to that schedule. (again IIRC)

The examples I’ve given maneuver devices using Tellstick, but I think that in OH it should trigger events.(?)

First and foremost the discussion should be about functional requirements and end user experience.

Hi all.
For the last ten years I’ve been using a solution built by myself and a friend in PHP/MySQL (and used by a few hundred people over the world). I’m starting to think about move over to openHAB instead (as both user and contributor). I’m a bit confused though to see that scheduling doesn’t seem to be available, I thought that was one of the cornerstones of most home automation.

So I’d just like to put in my five cents about features that would be useful:

First natural thing would be to do something on specific times and weekdays. For example the following schedule in our interface that for every mon-fri turns on some lamps at 05:50, off again 08:10, on again when it’s getting dark (below 100 lux) and then off again at 23:00:

I think our notion of a “schedule” containing “activations” is kinda natural.

Another thing that we’ve got that I wouldn’t want to be without is a function that allows me to schedule that my engine should be warm at 07:00 every morning. The system then turns the engine heater on at the right time before departure (we’re using the formula (-temp/10 * 60) + 60 for this, with a roof of 120 minutes).

So is there any ongoing work on this? Anywhere I could kick in and start helping?

1 Like

Nice to see swedish :slight_smile: !

I haven’t seen any work, and I agree with basically everything you say.
Yes, weekdays is a reasonable way of scheduling.
( day of month, and 1st weekend of … etc may be handy at a later stage)

Your tool seems tp be structured as:
ScheduleID
Events connected to the schedule
Timings for the schedule.

Which makes sense to me.

1 Like

Yep, I had to change the browser language to english to take the screenshot, but of course the device names is still in swedish :wink:

I think maybe it would be enough with a scheduler handling week days and let the gcal integration (no idea what the status of that is though) handle stuff happening more seldom or more irregular than that, not to overcomplicate things. But that’s just another five cents :slight_smile:

1 Like

I think we should ping @Kai to give us the current state about implementation of a scheduler … and give him the chance to meet a possible new contributor :slight_smile:

There has been some work on the core infrastructure to support this (Event Triggers) but the UI is probably a long way off. Perhaps this would be a good place you can contribute.

Right now scheduling is handled in Rules. If you want to schedule based on solar events (e.g. sunset, sunrise, etc) there is a binding that will create an event that can trigger a rule at those events or an offset from those events. For things that should happen at certain set times there are cron triggers that allow one to trigger a rule based on a cron expression.

Finally, there are some examples showing how to schedule things to occur based on editible times. This is the best we have for a UI right now and it is not satisfying.

So OH has full support for scheduling, just not through a UI… yet.

Also, be aware that OH is currently in a transition from text based to UI based configuration and administration. Before now managing scheduling in Rules handled 75-90% of all use cases.

There has been much discussion on this forum about this topic.

Any contributions would likely involve the core Eclipse SmartHome so that is where I would start.

Finally, one popular way to managing scheduling, particularly recurring schedules (i.e. daily) is through a state machine as documented here which coule easily be expanded to support day types as well.

Oh, and I completely forgot about bindings that support calendar integration.

Thanks for jumping in @rlkoshak! This week is indeed a bad time to ping me about bigger concepts, I am drowning in work for the OH2 release :wink:
But be assured, I’d like to follow up on this as well. In the meantime, I would also invite @kgoderis to the discussion, because he did a lot of work around CalDAV and using calenders for scheduling!

Until openHAB has its own scheduler, you can use the Google Calendar binding - e.g. GCAL bindings - refreshed version, and then schedule commands through your Google calendar (or use the caldav binding if you want to use some other calendar - https://github.com/openhab/openhab1-addons/wiki/CalDAV).

From my understanding, the google calendar binding relies on a working internet connection. So if for any reason there is no connection, then some actions could fail. Right?

If so, I would prefer a solution which works local. Just my two cents. :wink:

The Caldav binding allows you to use any caldav compatible server. I have used this using Baikal running on my internal lan.

The contribution I have in the pipe implements to a large extend (e.g. based on the relevant RFCs) a fully functional CalDAV server, that wil run in the openHAB core.

It will allow users to use any CalDAV compatible client (e.g. MS Outlook, Mac OS X Calendar,…) to manipulate the execution of Rules. It will use a similar syntax as the existing Google binding to define how Rules will be executed.

Today in OH2, based on Eclipse Smarthome, there are - in short - two ways to define Rules. One is via the Domain Specific Language, e.g. .rules files, inherited from OH1. The other one is via Automation, the new automation infrastructure.

The contribution needs Automation-based rules to work properly. That implies two options:

  • Modify the “DSL” RuleEngine so that any Rule in a .rule is transformed into an Automation Rule
  • Waiting for the “DSL” RuleEngine to be phased out alltogether. This is the “plan” anyways going forward

Option 1 I have the necessary code in place, but I have put it on hold as there are other contribution to the Automation code base that are discussed, and have an impact on what I wrote
Option 2 depends on an alternative way to define and manage Rules in openHAB. There is some UI development ongoing, but I have not followed it lately.

I someone is tempted to push this a bit forward, you are welcome! Myself I am quite short on time to do it anyways.

I don’t think Caldav is a good way forward.
Event scheduling should not be spread over several tools.
First agree on the requirements, then and only then, start looking at solutions.
Otherwise there is a risk that we end up with a handful of solutions where no one is good enough.

Any solution that isn’t 100% local and doesn’t trigger events relative to sun opens up for more solutions to the same problem.

Unfortunately when one is dealing with an open source platform, multiple solutions to the same problem is inevitable. The is no agreement on the requirements. Everyone has their own and if able provides a solution of their own. That is the nature of open source development.

And as @kgoderis said, it works with any caldav client so there is no dependence on an external cloud service. So this service is local and we ashtray have a binding whose purpose is to schedule things according to the sun.

[quote=“rlkoshak, post:48, topic:1329”]
The is no agreement on the requirements. Everyone has their own and if able provides a solution of their own. That is the nature of open source development.
[/quote]But that is a matter of decision, just like all architectural decisions that have been taken on OH should work and behave.
surely the community can discuss and agree on functions and a roadmap for implementing them.

Yes but the community isn’t going to refuse to accept a solution that someone has already implemented. At least this community won’t. Thus the will be multiple solutions. And often the first one that ends up working gets the most users.

An most people have a CalDav server of any kind running anyway. So it is rather convenient to be able to schedule stuff from every device that supports a syncable calender.

You may consider IFTTT but you need to be connected to the Internet for the schedule to work

Hello all,
I’m starting having “deep playing” with Openhab2 (as I like to have it live on my home ASAP) and I’m actually try to understand which will be the best way to manage schedules.
I read through this thread and saw a new Automation infrastructure would be the right choice (as it is the choice for the future ).
I’d like to understand more on the status of this… as well as how to use it :slight_smile:
Can you please help me in understand?

I also saw a good (IMHO) UI approaches from @chris as well as @erland_lestander (they are not so different, IMHO) and other.
Maybe Chris’ one advantage is it is already available in HABmin… (and aligned with look and feel I like…)
But again I’d like to understand which is the status for having a working UI…

Best Regards,
Leonardo

PS
FYI now I’m using OH2 with ZWave probes (Fibaro), thus monitoring only.
Next step will be include actuator (thus acting also)

I shall hope this scheduler gui will be in OH2 soon :slight_smile:

All - I’ve just created an alpha version of a timer binding - that can be used to do a form of scheduling whilst a proper UI is implemented: New Binding - Timer/Scheduling Binding