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
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
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?
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 {
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.
May you post some example rules that are working for you?
I try to learn about the use of rules and I did some experiments with my Ikea tradfri bulbs.
I got a lot of problems with the syntax and type conversions
I give you an example:
I wanted to get a value from a slider and use this to set the red part of a rgb bulb
I had to get this value (0-100) and convert it to 0-255
This is what I had to do
var Number rgb_red_slide = RGB_Lamp_01_red.state as DecimalType // get the value of rgb_red_slider
logInfo("RGB","slide:" + rgb_red_slide.toString)
var Number rgb_red = rgb_red_slide * 2.55
logInfo("RGB",rgb_red.toString)
var myFloat = new Float(Float.parseFloat(rgb_red.toString))
logInfo ("RGB","myFloat: " + myFloat.toString)
var myIntRGB = Math.round(myFloat)
logInfo ("RGB","myInt: " + myIntRGB.toString)
var newColor = new Color(myIntRGB,0,0)
logInfo("RGB","RGB Color: " + newColor.toString)
The code runs, but I have no idea why something like
var myIntRGB = Math.round(rgb_red)
does not work
but
var myFloat = new Float(Float.parseFloat(rgb_red.toString))
var myIntRGB = Math.round(myFloat)
works
I found the Class definition.
https://eclipse.org/smarthome/documentation/javadoc/org/eclipse/smarthome/core/library/types/HSBType.html
It’s a little hard to convert the types as some constructors does not exist and I had to use some static
call HSBType.fromRGB(int r, int g , int b)
var newHsb = HSBType.fromRGB(rgb_red_slide.intValue,green.intValue,blue.intValue)
Hey All,
Thank you Neil for this great job, the binding is very useful and should be officially released in OH2 official bindings.
However, i am facing a very weird issue recently occurred with no main reason. The issue is the Status of the timer keeps triggering On and Off all time when the current time passed the On and Off timers. Noting that it was working perfectly during the last month.
For example, if the On timer is 10:30 and Off timer is 10:35 while the current time is 10:36 and above.
in the logs it keeps giving frequently the below messages:
2017-12-31 10:39:11.423 [INFO ] [ding.timer.handler.DailyTimerHandler] - Cancelling current job [org.eclipse.smarthome.core.thing.internal.ThingImpl@36b50f48]
2017-12-31 10:39:11.424 [INFO ] [ding.timer.handler.DailyTimerHandler] - Scheduled OFF job for h[10] m[24] s[0]
2017-12-31 10:39:13.852 [INFO ] [ding.timer.handler.DailyTimerHandler] - Cancelling current job [org.eclipse.smarthome.core.thing.internal.ThingImpl@36b50f48]
2017-12-31 10:39:13.857 [INFO ] [ding.timer.handler.DailyTimerHandler] - Scheduled ON job for h[10] m[20] s[0]
2017-12-31 10:39:14.257 [INFO ] [ding.timer.handler.DailyTimerHandler] - Cancelling current job [org.eclipse.smarthome.core.thing.internal.ThingImpl@36b50f48]
2017-12-31 10:39:14.260 [INFO ] [ding.timer.handler.DailyTimerHandler] - Scheduled ON job for h[10] m[20] s[0]
2017-12-31 10:39:15.901 [INFO ] [ding.timer.handler.DailyTimerHandler] - Cancelling current job [org.eclipse.smarthome.core.thing.internal.ThingImpl@36b50f48]
2017-12-31 10:39:15.904 [INFO ] [ding.timer.handler.DailyTimerHandler] - Scheduled ON job for h[10] m[20] s[0]
Can please someone advise what could be the problem exactly? Actually i am relying a lot on this timer to activate many things in OH items on a specific time of the day.
Thank you in advance.
Hello,
would a new version of this binding be possible? The persistence of the data does not always seem to work. Since OH snapshot 2.3 I got a lot of this messages:
2017-12-31 19:00:38.799 [INFO ] [ding.timer.handler.DailyTimerHandler] - Cancelling current job [org.eclipse.smarthome.core.thing.internal.ThingImpl@ab2f0ffb]
2017-12-31 19:00:38.806 [INFO ] [ding.timer.handler.DailyTimerHandler] - Scheduled ON job for h[5] m[45] s[0]
2017-12-31 19:00:38.913 [INFO ] [ding.timer.handler.DailyTimerHandler] - Cancelling current job [org.eclipse.smarthome.core.thing.internal.ThingImpl@39487177]
2017-12-31 19:00:38.918 [INFO ] [ding.timer.handler.DailyTimerHandler] - Scheduled ON job for h[5] m[45] s[0]
2017-12-31 19:00:39.406 [INFO ] [ding.timer.handler.DailyTimerHandler] - Cancelling current job [org.eclipse.smarthome.core.thing.internal.ThingImpl@82518b3]
2017-12-31 19:00:39.411 [INFO ] [ding.timer.handler.DailyTimerHandler] - Scheduled ON job for h[17] m[15] s[0]
2017-12-31 19:00:40.080 [INFO ] [ding.timer.handler.DailyTimerHandler] - Cancelling current job [org.eclipse.smarthome.core.thing.internal.ThingImpl@82518b3]
2017-12-31 19:00:40.082 [INFO ] [ding.timer.handler.DailyTimerHandler] - Scheduled OFF job for h[17] m[30] s[0]
It’s a great extension to control timers via GUI. I do not want to miss it anymore.
Thank you very much
LukaNoah
Hello,
Today the Timer Binding is back to work again, i am not sure if it was a due to the 31th day of the month or it’s the last day of the year, i think I should wait for another month that has 31 days and I will highlight on this bug again.
Happy New Year !!
Hey.
Sorry I’ve been busy and still haven’t been progressing my adoption of openhab2 so things went a bit quite.
I think I know why the restart/persistance stuff might not work so I will have a go at fixing that as soon as I can.
I will look at the constant scheduling as well there are 31 days in January - so if it happens again then please let me know.
Neil
Ok the issue reported above with the log spamming is a bug that only happens on the last day of the year - so I’ve got 360 days to fix and upgrade 
Neil