Karol
October 26, 2021, 10:41pm
1
Hi. I think I have some issues with expirity binding. Sometimes when expire time is set to 1s, expire binding deactivates switch only after 2s. Any clue what could be the cause?
PS I have kinda big configuration/environment (things: 265, items: 1716, rules: 1546), so maybe here the problem lies?
rossko57
October 26, 2021, 10:52pm
2
I don’t know if this minor bug was imported to OH3 (the OH2 expire implementation was a separate binding).
opened 08:55PM - 10 Oct 19 UTC
closed 11:54PM - 10 Oct 19 UTC
expire binding, OH2.4 stable, oracle java build 1.8.0_181-b13, Windows 7
expi… re binding exhibits a one second error in expiration delays, when expressed in seconds.
Demonstration
`Number testNum "num [%d]" {expire="10s, command=-1", autoupdate="false"}`
small rule to repeat trigger-expire sequence
```
rule "slippage demo"
when
Item testNum received command
then
testNum.postUpdate( testNum.state as Number + 1)
end
```
Begin demo sequence by posting any update to Item testNum
events.log results
```
2019-10-10 21:14:11.370 [vent.ItemStateChangedEvent] - testNum changed from NULL to 0
2019-10-10 21:14:21.479 [ome.event.ItemCommandEvent] - Item 'testNum' received command -1
2019-10-10 21:14:21.487 [vent.ItemStateChangedEvent] - testNum changed from 0 to 1
2019-10-10 21:14:32.480 [ome.event.ItemCommandEvent] - Item 'testNum' received command -1
2019-10-10 21:14:32.489 [vent.ItemStateChangedEvent] - testNum changed from 1 to 2
2019-10-10 21:14:43.482 [ome.event.ItemCommandEvent] - Item 'testNum' received command -1
2019-10-10 21:14:43.489 [vent.ItemStateChangedEvent] - testNum changed from 2 to 3
2019-10-10 21:14:54.481 [ome.event.ItemCommandEvent] - Item 'testNum' received command -1
2019-10-10 21:14:54.488 [vent.ItemStateChangedEvent] - testNum changed from 3 to 4
```
State changes represent "start expire timer", commands represent "expired"
We'd expect a few milliseconds taken to process event bus and rule, but there is an unexpected one second component as well. This one second error is consistent across settings for e.g. 1s, 60s, 180s etc.
This one second slippage only seems to happen if the expiry time is specified in seconds.
Expiry times given in minutes e.g. `{expire="1m, command=-1"}` are reasonable accurate, to a few milliseconds.
I've observed, but not entirely confirmed, that the very first expire time cycle after editing the Item _does_ seem to be on schedule - this is shown in the log snippet. It seems it is subsequent "reschedules" of expire that add the unwanted second.
No-one should expect great timekeeping accuracy from expire binding, but this issue becomes significant for those wishing times in the under-10s area.
First time expires were accurate, subsequent expiresalways +1 sec - but only if time expressed in seconds.
