Event bus: updating many items at once

Setup, Configuration and Use Runtime
1

Hi,

I have a general question regarding the event bus. When a binding updates many items at once, will the “changed” events be fired after the last update?

Example: My PIR sensor sends an EnOcean telegram to OpenHAB. Besides other information, the telegram contains the motion status (motion / no motion) and the brightness. The EnOcean binding parses this telegram and sets the two items. We do not know which item gets set first.

Now I want to write a rule that when motion is detected AND the brightness is below X, the light should be switched on. Can I be sure that this rule does NOT take the brightness value from the PREVIOUS telegram?

rule "Motion to light"
when
    Item pir_motion changed to ON
then
    if ((lightswitch.state == OFF) && (pir_brightness.state < 300|lx)) {
        lightswitch.sendCommand(ON);
    }
end

Thanks!
Dominik

2

Not sure how the Enocean binding works. But what I experienced with other bindings is that if the rule needs more than one item state for the workflow it’s better to give OH some time to catch up all item states by adding a short delay at the beginning of the rule. You can do this with a sleep (be very careful here and use just very short delay, my personal limit is 100ms, further information Why have my Rules stopped running? Why Thread::sleep is a bad idea ) or a timer. How long the delay should to be is depending on different influences like binding technology, size of your installation or system resources.

3

Events are fired in parallel. There is no guarantee of the timeliness of their delivery nor that they are delivered in order.

Sebastian’s suggestion is one way.

Another way would be to trigger the Rule on both the motion and the brightness Item changing. Then set a timestamp. The first time the Rule fires it sets a timestamp and flag to indicate which Item fired. Then the second time it fires it checks and sees that the other Item updated recently enough that they came from the same event and do the action.

4

Recent relevant posting

5

It’s true that many threads (from thing handlers, rules, etc) can inject events onto the event bus, and that those threads all can execute in parallel (mostly, to the extent there are limits on thing handler threads, rule threads, etc.). As a result, your statement about timeliness of delivery and order or delivery is true.

But when it comes to processing events on the event bus, back when I was doing some performance testing I seem to recall a discussion that there is only one thread processing events on the bus.

A quick look at the most active threads on my system seems to confirm that.

 2283751   OH-EventHandlerExecutor-1
 1947990   OH-OSGiEventManager
 302036    OH-EventHandlerWatcher-1

So, I’m not disagreeing with you at all. Getting things onto the event bus is somewhat non-deterministic. But, once those events are on the bus, they’re processed sequentially. I also recall that there are config parameters where you can configure the number of threads (the current default is 1).

There’s a very long discussion here (most of which I’ve since forgotten), which you can read if you have insomnia one night. LOL

1 Like