I started with OpenHAB back in 1.6 something, and have most of the lights in my home connected to it. I also have a couple of towel heaters that are controlled by a z-wave relay. It is primarily around these towel heaters I base my use case around.
So a bit of background: The heaters where on a timer through rules, where I calculated and displayed the end time and let them be active for four hours after turn-on. When I updated to 2.x these rules where not ported because of various reasons. I was never really satisfied with them either.
What I wanted was a way of changing the time on the fly. Such timer would also be beneficial to other use cases as well.
I have proofed on concept and inserted into my OpenHAB at home a timer binding with the following features:
Guaranteed to only running one timer per thing
Time to timeout settable through channel (defaults back to item property)
Timer remains modifiable during countdown
Time left and calendar end time exposed as channels
Create and bind timers to item channels purely through PaperUI
Timer is activated by either channel change or timeout change
I still have timers in my rules, and they do have their uses. This binding does not replace them fully, nor should it. I do however think it have a place in more complex scenarios.
What do the community think about abstract bindings? I think I remember @Kai arguing against it. I do however think there is a place for such building blocks. Alternatively how should I implement it?
I am happy to explain more if someone wants to know more!
I’ve written a procedure to handle most of my timers. Each timers are bound to an item.
I can controll what will happen
set the item to a state if timer ends
cancel timer with no state change on item
cancel timer with state change on item
Can this be handled by this timer binding too?
I have a second mostly similar procedure called escalation timer
mostly the same, but at every timer end an excalation action is done and timer rescheduled to 50% of last timer value
I use this one to send alerts if something which should be closed or must be done in a time frame was not done. I will get an hint in decreasing time frames.
Windows was open and I forgot to close it. The timer will give me a hint to close it until it is closed or timer value is 0 due to decreasing timer values.
Yes, I can reschedule. I have two channels: EndTime - the time the timer will end/ended. This can be set to another calendar time. TimeLeft - A human readable string with time left rounded to either closest minute or second depending on time left. This is also updated more often closer to the end.
By sending a string to TimeLeft the time left can be altered. Examples:
+20m Add 20 minutes to the timeout. If the timer was off, it will turn on.
-1h15m Remove one hour and 15 minutes from timer. If the time left is lower than this. Time out immediately
120m Set the remaining timeout to 2 hour regardless of previous timeout. If the timer was off, it will turn on.
I have not considered escalation as you describe but was thinking of “time left gates”. Ex. Gates at 1 day, 1 hour and 15 minutes before timeout. You travel for the weekend and one day before coming back home, the heater is ramped up, 1 hour before, ventilation is ramped up and 15 minutes before the lights are turned on. I’t is just a thought at the moment though.
Another question. What is triggered it the timer ends? Just this switch “TriggerOff:Switch”. How to know to which the timer was related to?
Can there be bound something to the timer to know which item needs something.
How will a rule look like? Is there a function available like “member of” to know which timer ends?
rule "Variable initial setzen"
Item TriggerOff changed to OFF
All I can offer is indeed, Kai has argued that Expire never should have been a binding in the first place. And I’ve also seen arguments that functionality like this really belongs in the core, not as a binding. I tend to agree. Also, I believe that a feature like this is at least being talked about being needed in the core for OH 3.
I don’t have any objection to mostly abstract add-ons along the lines of these on principal. But this particular one is too fundamental I think and needs to go into the core, not as an add-on. I also think that in some cases similar to this one, a Python library module in Scripted Automation (which will be the default in OH 3) might be more appropriate in some cases.
I think this can be best explained with the Law of the instrument, freely translated in: If all you have are things, everything looks like a channel. And because items/channels are well supported to be configured in both files and UI it’s convenient to build a binding that uses channels to make certain functionality possible. Especially scheduling related functionality isn’t available as a core concept. Of course it’s possible to do something, but with limitations. That makes it difficult to add functionality like suggested here.
In the current state of openHAB it would probably be best implemented as a custom Trigger with parameters, but there is no super user friendly way in the userinterface to configure this smoothly at this moment. I guess this is something that needs attention, and also might require some deep thoughts and knowledge of the whole system to come up with a great solution.
I didn’t mean to imply it was. I only reference it because at this time it’s the most mature and has the most modules written in it.
My understanding is that all modules written in any language will be available to all languages. But maybe I’m wrong. I’ve been told point blank to shut up when it comes to these topics so I guess I’ve overstepped my proscribed allowed discussion once again.
It strikes me there are two distinct sets of timing needs.
What we might call the simple timer- that we might use for “motion detect turns on light for 5 minutes” tasks.
In a home automation system, this looks pretty clearly a core function.
Expire type tasks fall here -single duration, one event
What we might call the scheduler - that we might use for “heating on 1030-1600 on Thursdays” tasks.
Given that we’d likely want to update one of many individual settings, have different events triggered here and there,this has all the feel of Thing in our current structure. Some “external object” to which we can address commands and get status and events back.
Whether you call the machinery that operates that a binding or a service or a built in module doesn’t matter.
I see your point, I just have trouble to see how to proceed. Personally for me, the core is largely unknown territory, hence my initial question.
I have to confess I haven’t looked that much into Scripted Automation. I have kind of waited as the path for openHAB have been in kind of a flux. Perhaps it is time to find time to look at it again.
The main pet peeve I have with the rules is that they aren’t very modular in nature. Just writing a reusable function feels like a chore. I hope Scripted Automation will alleviate these problems. With that in mind it is easy to go the Lets make a binding route, even though it might be the wrong approach. What I miss is instead of writing rules and in those adding items, write a rule and then attach that rule to an item. Or at least write a logic concept and then apply that over several different items.
I will look into that. Do you have some good binding/code that exemplifies triggers I can look at?
As an example for how that’s not strictly necessary see JSR223 Jython Replacement for Expire Binding. As a challenge I wrote a drop in replacement for the Expire binding using Scripted Automation. And by drop in I mean drop in, you don’t need to do anything except leave your expire configs on your Items. The rules do the rest. So yes, you can write a Rule and attach the Item to the Rule the same way you would to a binding. In this case, the expire binding config turns into Item Metadata when you uninstall the binding. Item metadata is available in Rules so I can iterate over all the Items that have an expire tag and dynamically create triggers to a Rule or Timers or whatever for those Items.
I’m not proposing this as an approach to use for this topic in particular, I only bring it up as an example for how a lot of the limitations one has with Rules DSL are not there in Scripted Automation.
Based on a couple of comments in the issues I saw from Kai and Scott my understanding was that Python would be installed and enabled by default. But I’ve repeated such information I’ve seen before and was told to stop because I’m “getting people’s hopes up”. So now I pretend I don’t know what is planned, what is in work, what the original vision of scripted automation was and strictly focus on what is possible now. This whole thread shows that apparently I can’t help my self.
It certainly is. And within those categories there is also different levels of complexity needs. I still use rule timers in my setup and this timer binding won’t replace those. At the same time the cron functionality in rules is also just fine for a lot of use cases. I don’t think there is a good catch all, neither that a catch all would be a good idea.
I really like that. Had I started with this binding/idea earlier, that might actually have been my approach. To clarify. I have had this idea for at least one year, during which openHAB have shed Eclipse smarthome, gained a few minors and changed (vastly improved) build system.
I have also considered making the core idea with timer a separate program in some new fancy or exotic language and hook it up to openHAB through MQTT.
This is to say, like every other person with a family and in the middle of the career, time is the commodity I lack the most.
I’ve had a very similar idea for a couple years, with similar things being higher priorities for my time than trying to develop it.
In my imagination, you could create a thing for each timer they you want. The timer would have channels for hours remaining, minutes remaining, minutes, seconds, days, etc… Also a switch that flips when the time runs out, and a switch that controls whether the timer is running or not. Maybe one that caused it to start over when it finishes too. Any item receiving a command would cause the thing’s time remaining to update appropriately.
The need this would fill for me is any type of timer that I might want to adjust. I make some good use of the expire binding, but it’s annoying that to change the times it uses requires opening up my items file and changing the times.
Well good luck on developing a solution. It will be interesting to watch what happens with core too. If you find a solution for your use case, please share it here.
Rich, your histrionics have gone too far. I usually just turn and walk in the opposite direction of melodrama, but this and some of your other recent comments are attacks on me and my character. This is very unexpected, especially for a moderator of this forum who is representing the openHAB foundation. Your posts are forcing me to share our interaction with the community so that they can make up their own minds about your disparaging remarks.
In response to a post in which you stated as fact something that has not yet been finalized…
… I sent you a friendly PM to make sure that you were aware that what you stated was one of several options being considered and that nothing was final. My intent was to help you in preserving your credulity and to prevent people in the future from being confused if a different direction was chosen.
Your response was a harsh rebuke and a circular argument where you stated you’d continue communicating things as you understood them until things had been finalized. The next time you posted similar information about the future of automation…
…I replied with…
You then PMed me again to aggressively inform me that you would refrain from communicating in the forum about automation in OH 3.0 until it has been released. I’ve never told you to shut up or even suggested that you stop speaking about automation. All I have tried to do is raise your awareness to the fact that OH 3.0 automation design decisions are not finalized, so that your communications reflect the true state of things. However, you are still communicating definitive statements about things that have still not been finalized…
My intent was only to help you and others, and I don’t know why this is such a big trigger for you. Your innuendoes and insinuations are damaging on many levels and completely uncalled for.
I’ve not named you by name in any of my public posts. But you made it clear to me at that you don’t want me taking about it so I won’t. I slipped up in this thread. I may slip up again. I apologize in advance.
I’ll await public the 3.0 announcements before opining, projecting, or repeating anything I’ve seen in other public forums or postings.
I thought this is what was asked of me.
Point at one definitive statement I’ve made since then and I’ll delete it. I’ve been very careful to say “I think”, “this is my impression” etc. If that’s too definitive I apologize. I’ll try extra hard not to post any more…