Event Scheduler

Hi All

First of all, Thanks Kai for dedicating so much of yout time and other resources, you have really created something wonderful and amazing here, i am sure you folks have heard it a million times, but i haven’t said it yet :wink:

As mentioned by many users on google groups, is there a plan to support event scheduler on openhab2?

I know we can use GCal binding with openhab, but that doesnt provide the flexibilty as we have for switching on and off the lights.


can you elaborate a bit on what an “Event Scheduler” is for you in contrast to something you would get from a calendar binding?

I guess he means something like locally managed time tables, e.g. for doing a weekly heating schedule.

Well, we are currently working on a new rule engine concept at Eclipse, see https://www.eclipse.org/forums/index.php/t/860533/.
This will allow to plug in all kinds of new trigger mechanisms. So there can potentially also be a scheduler trigger. The tricky question will be on how to configure it, I guess…

Hi Thomas

By Event scheduler, as Kai put it, heating schedule.
Let me take an example, lets say, I am in India and it burns out here in the evening and afternoon because of heat waves.
By Event Scheduler, i am requesting for a mechanism by which we can set the drapes closing at 9 am and schedule this event to occur everyday of the week.

I am suggesting on weekly basis but if we add a calender, then we can have it from any date to any date.

Am I making any sense?


A maker of smart thermostats, Ecobee, has a nice concept of a weekly schedule, and a good UI to control it. It has definable modes (which it calls comfort settings) and activities that span time ranges throughout the day (or overnight). It comes with pre-defined modes named sleep, wakeup, away and home, but you can add your own named modes and activities.

In Ecobee’s context, you choose your heat and cool setpoints and a few other things. An implementation for openHAB could instead use a rule body, opening/closing blinds, turning on/off lights, music, changing heat/cool setpoints, or anything you can do in a rule.

Below is an example UI:

Hi Kai, Thomas, Watou

This interface looks cool. However i would like to add a few things:
This should be the interface which would show all the scheduled events, Lets call this Screen 1
Screen 1 should have Add Event link and Schedule Event Link.
On Add Event, we are redirected to a new page (lets say Screen 2) where in user can define what all actions will openhab take as part of event (such as turing on AC, lights etc) somethign like a drap and drop.
On Schedule Event, we are rediected to a new page which lists all the present event which we can schedule individually using a start time, date(s) or day(s) (whichever seems better or both :))


I dont have much knowledge about openhab’s architecture (since i am new and havent dived into the code yet) but i was thinking in terms of a binding (for scheduling) which would store all the events and when a time comes (lets say Monday morning 11:00 AM) would post the rule onto the event bus (or execute the rule as it currently executes. What do you think, am i on the right track?


Beside the rule engine, there is also the question how to implement it into the ui. When it comes to date time items, we need something like the colorpicker. To define either a wake-up timer or select a start or end event of something.
But for heating schedules this is not even enough. For this we need several timeslots over a day.
Right now my heating time are from rules, bit from a user perspective, I would be nice to be able to configure them more easily.

Actually no. This is not about creating a binding, it is about creating a rule trigger - that’s why I referred above to the new rule engine concept, which will make that possible.

I’m also quite interested in this topic, and it’s something I’ve been thinking about on and off for a while…

I’ve messed around with a couple of interfaces in HABmin - just playing at the moment as I’m not sure how I want the UI to look, and I also don’t know how the backend will ultimately work…

For the backend, I fully agree with Kai - this needs to be linked to the new rule engine. I’m not completely sure where that’s at as there has been some discussion a while ago, although I see some recent PR activity, so hopefully this might become clearer in future…

For the UI, I’ve toyed with two interfaces, and HABmin currently incorporates them both (for playing only). One is a calendar style…

and the other a timeline style…

The idea (not implemented) is to be able to add new events/schedules into the list - they can be dragged around in the interfaces, and linked to either a rule, or just a command (so you don’t have to create a rule when all you want to do is send a single command to turn the coffee machine on at 6am).

Currently this is implemented using a couple of plugins, so it’s really just templating and playing at the moment so that I can get a feel for how it looks etc. I think it would be an interesting discussion to get a few ideas for UIs, and I also like the simplicity of the EcoBee interface that @watou posted…

Any thoughts on event schedulers would be of interest I think :smile:


1 Like

Just fyi: I have spend almost the whole two last working weeks on that. The work is currently done on the branch from which the PR originates and you see many sub-PRs being merged into it: https://github.com/marinmitev/smarthome/pulls?q=is%3Apr+is%3Aclosed
But there is also still a bit to work on before I consider the rule PR to be ready to be merged - if you are interested, have a look here: https://github.com/marinmitev/smarthome/issues


Thanks. I can really believe it - it was a big PR! I’ll take a look at the current status - I’m interested to see if my comments made it into the latest version :smile:


I cannot really remember which comments you refer to. If you feel that something is not righ, feel free to add another issue on the issue list link above :slight_smile:

Will do - I was commenting on adding some additional lifecycle events associated with initialising and disposing of rules (and maybe a couple of others, but I forget now…). I’ll have a look and see where it’s at anyway.



Sounds like https://github.com/marinmitev/smarthome/issues/33

No - I didn’t mean SSE, I meant lifecycle within the rule itself…

I just did a quick scan of the discussion on Eclipse - the things I was after were persistent variables, comment blocks (although we may have agreed not to both on that, I’d need to re-read in a bit more detail), and an initialisation and termination block…


Ah, now I remember :smile:
You are right that that might have been lost again on the way, so feel free to enter an issue and link to the past discussion about that.

Is that for all of the features or did some make it through already?

  • Persistent variables
  • Initialisation / termination blocks
  • Comments
  • Persistent variables: I think this is at the moment out of scope since this can be a service that is used by the different module handlers. I am thinking about needing something like this for making the current DSL rules (and there global variables) work in the new engine
  • Initialisation/termination blocks: This is something you should indeed follow up on by entering an issue
  • Comments: Afair, we agreed that we do not need any specific comment properties in JSON, since we already have the description property which is meant to add helpful information.

The OpenSprinkler UI for scheduling is very nice. Since OpenSprinkler is already included in openHAB, the consideration of this UI would seem reasonable for expanded duties beyond irrigation.

1 Like

Hi Kai,

  • Ok for persistent variables. I really think this is a must have - if rules can’t maintain state between each execution cycle then their use is very limited. However, if this is already in the pipeline then fine.
  • I’ll add a bug for these blocks…
  • No - the description was something that was provided by the ‘block supplier’, and not entered by the user. So, it might say for example, “this block compares two numbers”. The description is localizable, and fixed. What I wanted to see was the ability of the user to be able to add a comment - they might say “I’m comparing X and Y to see whatever because of something…” to remind themselves what the block does in their particular use case. If we want rules to be share-able, then user defined comments in rules are (I think) a must have.