@martiniman I don’t know what you are trying to do here.
Your switch expire binding means, verbosely, “whenever the expireTimerSwitch1m receives either an update or command that is not ON, one minute later, post the command ON to it if no update or command arrives within that minute. But if an update or command does come in during that minute, if it’s not ON, reset the expiration to happen a minute later than that. If an update or command comes in that is ON, cancel the expiration.”
Your rule says, verbosely, “whenever something sends the expireTimerSwitch1m item an ON command, immediately send it an OFF command.”
Knowing what you would like to accomplish is the only way to offer further help!
Oh! This is really better accomplished with a cron-based rule. If you are having a problem using Time cron triggers in rules, please try to make that work instead of this less concise and more burdensome alternative:
String EveryMinute { expire="1m,RUN" }
rule "Start Every Minute Expiration"
when
System Started
then
EveryMinute.postUpdate("IDLE")
end
rule "Do Something Every Minute"
when
Item EveryMinute changed to "RUN"
then
// do stuff
EveryMinute.postUpdate("IDLE")
end
I also want to voice my compliments for this binding. It has cleaned up a lot of my code, and really simplified some monitoring rules that I use for various computers in my network. For example, if my MQTT server dies, my systems cannot communicate. So I setup an MQTT String item linked to the $SYS/uptime topic on my MQTT server, with an expire statement. If it expires, the value gets set to “DOWN,” which triggers an alert.
One circumstance that it will not catch, however, is if MQTT fails to connect from the beginning (e.g., MQTT is down at startup). What would be the recommended way to catch this? Should I have a startup rule that sets my expire Items to some arbitrary value (e.g., “INIT”) to start the expire timer running?
I don’t know if updating the state of an item in a startup rule would work, in case the Expire binding isn’t yet listening. But you might be able to start a 5-second timer in a startup rule, which, when the timer expires if the state of the item is still UNDEF, post an update to some other value.
I haven’t thoroughly tested it myself yet but so far it appears to work with sendCommand from a System started rule. So far this seems to kick off the Expire binding.
But I’ve not fully tested this yet and my system may have the timing just right that Expire always loads before System started rules fire.
Are you sure?
I am happy to switch if it is working for what I need it too.
I see that at present daily updates seem to kill certain functionalities… maybe I wait for 2.1
Hmmm, almost.
I switched about three months ago and it was not too easy when your are coming from openHAB1.
My main problem was: defining EVERYTHING through text files (like in openHAB1) does not work because some bindings do not support it yet (e.g. zwave).
So one has a mix of text and GUI defined configs and that is sometimes a little complicated.
I’ve been using this for a while now on OH 1.8 and OH2.0, no problems, although I wish it could do fractions of a second too so I could use it with my battery operated doorbells. Leaving the bell operated for a full second each time with a small 9V battery operated bell kills the battery
I originally tried to use a wireless doorbell, but the false alarms were a problem. The 433MHz band is very busy around me so that rules out a lot of stuff…
However, I am also a root cause analyst, and as such try to fix the root cause rather than applying a band aid. While I love the expire binding; asking it to fit your unique problem is barking up the wrong tree.
I haven’t looked into solutions, but I am sure, there may be a better product, than the one your are using?!
Maybe the current door bell can be modified to use a LiPo battery or solar panel to charge, etc. to prevent the 9V from going flat too quickly?!
TBH I totally understood what you meant Right now I just use this
rule"Doorbell"
when Item Doorbell changed then
if (Doorbell.state == ON) {
Thread::sleep(250)
Doorbell.sendCommand(OFF)
}
end
which does the trick - I had moved to using expire with 1 second as part of a general simplification of my rules, and thinking that the extra time didn’t matter that much. However after a couple of weeks later I discovered the battery was flat for the first time.
Given that the batteries last for several months with the rule above it’s OK reverting back to the rule
I use the expire binding to check the state of my OneWire Sensors (that are sometimes behaving not as stable as I wish they would - but that’s another story). Anyhow, those OneWire Sensors return decimal values so I…
Number myOneWireSensor { onewire="deviceId=26.DCD984000003;propertyName=temperature;refreshinterval=10;tukeyfilter", expire="30m,-99"}
So when the OneWire Sensor fails, the Expire Binding set the value to -99 and a watchdog Rule is able to send out some warning notification. That nice. On the other hand the -99 value is ruining all my graphs.
I tried to set the value to an UNDEF state but that’s obviously not allowed.
I am on 1.8.3 (and thought the PaperUI is only for OH2??)
