[expire] one second error in expiration period

[Rossko57]

expire binding, OH2.4 stable, oracle java build 1.8.0_181-b13, Windows 7

expire 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.

[9037568]

You said it:

No-one should expect great timekeeping accuracy from expire binding,

[rkoshak]

For those who do need good time keeping or times under 10s, there is a PR on the openHAB-Scripters Helper Library that implements this Binding that does support subsecond accuracy. https://github.com/openhab-scripters/openhab-helper-libraries/pull/259 This can help get you buy until there is a replacement for this 1.x version binding.

[Rossko57]

Great response, very encouraging, will ensure openHAB maintains truly high standards.