Thanks, @neil_renaud, this is pretty interesting.
As commented on the PR already, I am not sure whether this use case might “bend” the idea of a binding a bit too much.
You should note that bindings are not the only kind of add-on for ESH/openHAB2, but the one meant to mainly connect real hardware to items (which should be functions for operation and not administration).
I think what we should strive for is to have such triggers as modules for the new rule engine. We already have support for generic CRON expressions, and a certain “time of day”, you can find the code here. Imho it would make a lot of sense to help improving the features of that rule trigger or optionally define an additional trigger type, which could focus on more powerful scheduling options than the “core” type does. Wdyt?
I’m not advocating for or against this new binding, but I can’t see a big difference (in terms of logic behind it) between this binding and Expire/Astro binding. All of them are meant to make a time of a day/timer/time based actions easier to implement. And, from the user point of view, it’s much easier to use (and maintain) e.g. items using expire binding, than making a rule based on a timer. Also, there are other bindings that aren’t hardware related - like Weather and Air Quality binding. Just my 2 cents.
@Kai - I understand what you are saying that it stretches the concept of a binding, the ‘hardware’ it is interacting with is the system clock. I understand what you are saying about the rule engine but I see Timers more as “Things” in my home automation system that I want to interact with. I want them in the UI and I want to be able to change them - I see that as more of a fit to a Thing/Binding than a rule.
Whilst the one timer implemented so far does match a daily rule quite well as a thing it has the advantage that it can be modified by rules. E.g. you could make it so rules change the time it runs based on other state in the system. Also if you have an “Away” style switch set up when it is set to AWAY then the timers can be programatically disabled using rules.
I don’t believe rules have this ability? They seem much more a set up once and leave it with very few changes. Also one of the timers I plan to do is a specfic date/time timer. So if you are going away you can setup the timer to turn everything back on the day before you come home… with my binding you could set that timer up once and then just update the date/time/enabled as needed.
Roles absolutely have this ability. You just have to code it into the rule itself.
The thing is that Things are supposed to be set and don’t touch like you assumed rules worked. If you have a date time that schedules when an event is to be generated in the future, that date time is a state that properly belongs in an Item, linked to a channel on a binding.
Also, there is no way I know of to change a date time through any of the existing UIs. So how does one change it? Either they create a new thing, which will require updating your rules anyway so you are not saving anything by using this binding.
This really is a crosscutting concern that is bigger than just a binding. I would heed Kai’s advice and help to get this functionality into the does engine and the UIs. I just don’t see how this as a binding solves the real issues with scheduling events.
Yeah but that is poor in my opinion - I can’t disable a rule without adding extra code, probably a fake item to take a variable just to make rules work… hence the binding which removes all that. I’ve got 10 or so rules - doing it in the rule I’d have to copy and paste the same rule code over and over again.
Sorry I think I’ve been a bit loose with my definition here. The timer is a thing - the date time etc is an item (state). See
the screenshot in my second post.
See my screen shot again - I’ve got an hours, minutes and second items that can all be set as numbers using the standard UI. You are right Openhab is missing a date/time picker in the UI for the DateTimeType unfortunately I’m not a web developer so can’t really help here even though it is desperately needed.
Well, schedulings it’s a big gap from openhab… There is no way to configure schedulings using UI. We are assuming that all the users are programmers, and should learn how to code and what is one cron expression. Caldav isn’t solution to this problem, is just one workaround. I hope we can prioritize this topic soon.
I prefer to not share everything with Google, so this binding could be very helpful to me.
I sense a bit of negativity in this thread and I think that’s a shame. Sure, getting it into the core may be the better place for it, but for sure it will not make it into the “really soon now” 2.1 version. And if it misses the one after (Jan/Feb '18?) then it will be the one somewhere mid next year may be… in the mean time this binding could then serve as a nice workaround.
Also, there are other bindings that are not related to a hardware device, e.g. the Expire binding and many find it useful as well.
As for the use cases it should support; if it supports anything Cron can do then I think most use cases are covered. Cron has been around for ages and if it was missing something then for sure it would have been added a long time ago.
I would love to be able to get rid of these hardcoded Cron triggers in my rules and replace them by this binding so that I can modify them via the sitemap.
Yes, good point…
there is another binding (caldav binding) which can inter operate with i.e. owncloud. But to be honest, it’s a lot of work to setup owncloud only for openHAB…
We recognize scheduling is a problem in OH. I believe there are issues already open to address it and there have already been some changes made to the core to facilitate it (e.g. event triggers from channels like in the Astro binding).
There are numerous existing workarounds for solving this problem, all of which are unsatisfactory in one way or another.
Given the limitations of bindings and the UIs, this binding too will be unsatisfactory.
Given the above, I think we would rather you spend your effort on this adding the capability to the core and UIs rather than implementing what would amount to another unsatisfactory workaround.
In short, we recognize the problem. Many of us do not recognize a new binding being significantly better than existing workarounds and would rather you spent the effort making a truly satisfactory solution to this much needed and requested feature of OH. This would mean following the advice of our fearless leader and working on the core rather than a new binding.
But, should you decided to make a new binding, I’m certain it would be welcomed with open arms and much appreciation.
Thanks for the good summary @rlkoshak - that’s exactly what I’d wish for.
I think the only “negativity” in this thread is the fact that openHAB currently does not have a usable scheduling features and thus everyone is frustrated about having to workaround this.
But I indeed pledge for a clean and future-proof solution of the problem, not creating a slighly better workaround.
When I talk about the rule engine, I mainly have the NEW rule engine in mind, not the existing Xtext/DSL one.
With the trigger modules I pointed to, it is clear that its design is meant to be easily extensible. So while it comes with CRON support by default, we can add CalDAV triggers, custom scheduling config triggers and any other kind of trigger we might think of in future.
With adding the JSR223 support recently, we did a first major step towards getting this rule engine used productively for scripted rules (in Javascript or Python - but please note that this still seems to be buggy, so it still needs to be stabilised. I just wanted to give an example where we are heading wrt rules).
So while this means that the feature has to be discussed/defined/implemented in the core (and thus ESH), I think this will clearly be the right choice in the long term for everyone.
Kai - is there an update on when it may be ready? The new rule engine was first mentioned Aug 2015: Event Scheduler. The reason I went for a binding is it take a couple of hours to create vs the months of effort that a rule engine has already consumed.
I also fear that a new rule engine won’t cover things properly - for example is it possible that we’d be able to… “Alexa ask Openhab to set my Sprinker timer to 7:00pm”? That could be possible with a binding…
Isn’t the answer a DatePicker like the ColourPicker to be able to set Date/Time items in the UI? I’ve not looked yet but assume there isn’t one in OH2. Then suddenly timers (as opposed to schedules) become almost a perfect complement to the UI?
Hey Neil,
that’s an interesting binding idea. I’d agree with others that you should not name it “Timer” as this term is heavily linked to the Timer class.
There is an earlier thread on an actual Timer binding with similar ideas you might be interested in: Timer Binding discussion
As Kai said, this usecase might be better implemented by rule engine modules.
I’m certainly up for suggestions on the name - I decided to implement this after my daughters “Morning Timer” (which turns her lights on to wake her up) needed the time changed in the middle of the night due to her having a bad nights sleep - in the end I had to just disable it as I wasn’t going to mess with rules and vi at 3:30am in the morning. Anyway that is how it got the name timer
Interesting thread you linked to - I feel we come from the same place. Having read your thread (but skipped the examples) I think maybe the thing I don’t make clear is I never expect this to replace complex timers in rules (e.g. the ones that require state and some of the examples in that thread obviously wouldn’t work with my binding).
Instead I look at this as a really simple way to do really simple timers - which for me is the vast majority of them.
Since there is a big debate about usefulness of this binding, you can always make it as a separate .jar add-on (not included in the official build), and share it in this topic, so, people who need it could use it.
Well, it is available since a while. It is in a shape where it can do basic stuff, but if nobody contributes to it to make it more versatile, it won’t change much. That’s why I suggest to help using/testing/improving it!
is it possible that we’d be able to… “Alexa ask Openhab to set my Sprinker timer to 7:00pm”?
Yes, absolutely as a rule can easily be constructed through code and added to the rule engine. So the really cool thing is that you will actually SEE all those “verbally defined” rules in the rule engine, just like any other rules you might have defined. Having some rules being hidden in some binding does not at all sound desirable to me.
First, thank you for your contribution! Though this subject in openHAB is a big one, and has no clear end game yet, your "binding will appeal to many new users that are unfamiliar with hard coding. Personally, I believe having a core ability to build sitemaps visually as well…i don’t really like the look of the options out there…(liked project rotini, but I got has taken a larger, more profitable track…i get it…)
I will definitely utilize this binding as it fills the gap we currently have quite well. I get that the core needs something better…and I get that rules work…but being able to switch times on the fly, is a great option…
Just because I can see both sides of the coin here…negativity…not really…but definitely feel like the op is being told his work is pointless and doesn’t help solve anything…my question would be…without a proper core scheduler in place, why not build a better mousetrap that appeals to many at this point in time?
