You can use google calendar to schedule items in a very free way… see http://docs.openhab.org/addons/io/gcal/readme.html for details (I did not test this under OH2 yet, but I used it with OH1)
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.
2 Likes
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… 
I don’t think it is negativity so much as:
-
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.
Hello!
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.
Best regards,
Davor
1 Like
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.
The jar is available here: https://github.com/foxy82/openhab2-addons/releases/download/Timer_Alpha1/org.openhab.binding.timer-2.1.0-SNAPSHOT.jar
3 Likes
Thank you for the link.
Best regards,
Davor
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?
1 Like
The argument is what is being proposed:
-
It does not solve the UI problem. You will still have to hard code the times. There is no current method to set a date time so one is still stuck with the awkward step of using separate Items for each part of the DateTime and having a separate entry on the sitemap for each.
-
Given that and given other limitations of bindings, the proposed binding would only be a minor improvement over what exists today. One that many might argue is not worth the effort. All it really buys you is the ability to create some Things and a bunch of Number Items to schedule an Event at some point in the future. It really is only a slight improvement over the Alarm Clock examples.
-
This is a feature that will be implemented into the core, hopefully soon. So any Binding that gets written along these lines will become redundant in the near future. Contributions to OH are precious and I for one hate to see effort that ultimately would be thrown away in the long run.
-
We are not arguing that the effort of creating a scheduler capability is not wanted or needed. We just think a Binding is not the best approach and would rather OP spend the time implementing it as part of the core rather than writing a band aide that will become redundant and no longer needed in the near future. In my opinion, building a binding would be wasted effort in the long run whereas OP contributing to the core would be a permanent improvement.
-
I also said, should the advice of the developers and maintainers be ignored and a binding created, I’m sure it would be welcomed as an addition to OH, at least as long as it takes for the feature to be added to the core.
The work is not pointless. It just would be far more valuable directed elsewhere.
And I agree that the core would be better than a band aid. That being said, the op said he doesn’t know code, therefore can’t help there. As it may only be a slight improvement, it’s still an improvement. Also, seems the op has already written the binding, in only a couple hours of time. It will take far longer to put this into the core.
This binding has come in very hand for controlling my Aquaponic unit pumps, fish tank lighting and bedside lamps. It was all working rather well, until I found I had a need to restart the Raspberry Pi regularly, due to some other bug in an unrelated logging application. I discovered that all the bindings settings are lost on reboot of the RasPi. I have tried to use a persistence service to retain the settings, but could not get that to work, I am not a coder, but have tried to search the forum/internet for a solution to plug into the source code that is available on the OP’s Git Hub page. But this is all very foreign to me.
Can someone please point me to where I can read up on how to ensure that a bindings settings are retained on restart?
I assume the persistence should do this. Look at mapdb (http://docs.openhab.org/addons/persistence/mapdb/readme.html)
There are details of configuration here: http://docs.openhab.org/configuration/persistence.html
I think what you need is something like this:
Strategies {
default = everyUpdate
}
Items {
- : strategy = everyChange, restoreOnStartup
}
Do that and see if it works for other items as well to ensure its not a binding specific issue.
Neil
It seems that Persistence does not solve the issue.
When the server is restarted, the timer binding is added., it goes from uninitialized to initializing, then persistence is added, and the settings are restored. It then goes from initializing to online. It then proceeds to set all the settings back to defaults.
I deleted all other persistence and rules just to make sure there was nothing else interfering…
Have a similar problem (managing water for the garden ) and rather new to openhab.
running openhabian on a raspberry 3.
how did you install the Timer binding ?
I downloaded the “org.openhab.binding.timer-2.1.0-SNAPSHOT.jar” from the second link in post 1, and placed it in the /usr/share/opehhab2/addons folder.
Restarted openHAB and it was available to manually add as new things. I then set up some rules to act on other item states, based on the state of the timer status item.