I am interested if there is anything I can do to improve the performance of my rules that use ZWave inputs to trigger outputs in rules.
For example:
Aeotec motion sensor triggers
Rules executes
Triggers Fibaro light to switch on
Approx time from motion to light on is 500ms to 1000ms.
I know this is could be due to a large number of reasons. I don’t believe it is any of the following OpenHAB machine cpu. My only guess is that there is something that could be improved in the ZWave network to reduce the route.
Any ideas or is this performance within an acceptable range?
Not without you following the binding instructions for when things do not go as planned and posting some unfiltered DEBUG logs.
Only your system knows why it behaves like it does…
You can replace “simple” rules with associations. Eg. Instead of write a rule if motion is triggered then switch light on, you can associate the motion sensor directly to the light. Only disadvantage OH is out of the equation.
This could already be the reason. From my experience the Aeotec motion sensors are not very sensitive and responsive compared to e.g. the Fibaro devices (FGMS001). I replaced a lot of Aeotec motion sensors with the Fibaro FGMS001 and this alone already accelerated the response time by approximately 500ms.
So a lot of hops from the sensor and a lot of hops back takes a bit of time.
If the route is not good you may have a few reties in here and that may explain the variation.
Direct association would help in this situation if the devices are close as it would be a single hop direct communication. If it is not then you will not gain a lot.
Next the Fibaro switch can have a delay with certain parameters set. What delay when controlled from openHab? Any delay?
Next if you are using security, this has a cost in response times.
Lastly and probably most common too much underlying traffic. Reduce the amount of reporting, polling and wake up. High levels of underlying traffic would cause the variation again.
That was also my reasoning when I bought them.
The Fibaro devices also fit into the Aeotec mounts, you just need a small srew and a small nut for that. So I use the Aeotec mounts now with the Fibaro devices. And now I also use the Fibaros as main powered devices with a 230V-3V mini transformer so I do not need to change batteries anymore.
So do I (5V also does it). Only annoyance is I haven’t found a really proper way to fix the cables.
And remain aware that they still act like wireless devices (routing etc).
I agree, I did some soldering to fix the cables (not really nice but as they are on the backside inside the battery compartment you can’t see it).
I also use them as flush mounted devices within the normal light switch boxes. I designed a special mounting for this by CAD and made it with my 3D printer:
I do not know if this applies, but another brand of sensor that has both battery and USB power has this caveat, according to their support.
If you expect to run it on USB power, it must be on USB power when including into the network. Otherwise it behaves like a battery powered device even when USB powered. Tat was not mentioned in their documentation.
Yes, this is always required for all devices that can be used in dual power mode. You must include the device as it is used - I know that Aeon documentation does say this somewhere at least
