I have several HAC01 sensors connected to normal light switches and also an FGPB101 Fibaro button to set scenes. I’ve setup several rules to react to the buttons and e.g. switch on some Hue lights and most of the time the delay is good. (About 1 second until the light get’s switched on) But sometimes it takes up to 5 seconds and more until the light is turned on or a scene is set.
The problem is that I don’t know where this delay originates. It could be on the ZWave binding or a delay until the rule gets triggered. Is there a way to measure the delay between the arrival of a ZWave Paket and execution of a rule? And would it e.g. be possible to improve the rule execution? (I already tried to increase the Quartz thread count)
I would encourage you to look at your logs to find out what is wrong with your system. As a general rule, there should be very small delays in the system - a few hundred milliseconds. If you are seeing longer delays, then either something is timing out in the zwave binding, or something else in the system has a problem.
In either case, you need to look at the logs to see what is happening, and try to resolve that before anyone can answer the question of how to improve it.
If it were me, I would get the logs and first feed them into the online log viewer to understand what is happening in the ZWave network. IF that looks ok, then I would look further into the logs to see what else is delaying things.
Hi Chris, thanks for the quick answer. The problem is that I cannot tell when the problem occurs. Most of the time the delay is ok. If I enable a trace log for ZWave I would have a massive log in just a few minutes. (I have about 30 Zwave devices)
Is it maybe possible to configure the logging to only keep the logs from the last 10 Minutes? Maybe by setting log4j.appender.zwave.maxFileSize?
Don’t use a trace log - just use a debug log. I know this is still large, but it shouldn’t be too bad and the log cycle should keep it to a manageable size. I think by default it will keep 10 logs each 10MB.
Maybe there’s some other magic you can use to tune the files - I’m sure there is but I’m not an expert in this so you’d need to play around…
If you don’t get the logs then I’m not sure how else to proceed.
Ok I will try to find the corresponding logs if the problem occurs again. By the way, I am using a nightly build of the ZWave binding. (From 23.02.2017) Could this cause such problems?
Irrespective of version the transactions should be fast.
That said I would suggest to use a newer one as there have been some fixes in the core to solve some 5 second delays associated with threads. Also Zwave will have updated the database which can cause such delays if it’s wrong as well.
Hi Harry, thanks for the link. It is possible that I have the same problem. I have separate rule files for scene buttons and light buttons and the long delay often occurs if I press one of the buttons after a few hours. (e.g. if I return home from work and try to turn on the light or a scene for the first time since I went out of the house)
Is this a problem that was fixed in the ZWave binding and what config param do you mean?
@TheNetStriker: Yes i think we do have the same problem. In my case i just need to wait 10-15min after that i will have a 5sec delayed rulecheck. For example on my remote NODON or on my motion detector.
No, it is not a bug in zwave binding, perhaps zwave database as chris mentioned. The reason for thes problem is some issue on the thread pool. I think it got solved in latest snapshots but i have not tried some of that at all.
For me: I tried the suggestion from kai → setting the safeCall to 10…
I just started using openHAB. Regarding the delay I noticed every time the counter of the controller is raised, there is a delay of 5 seconds in sending the Light on and/or Light off command. That never happens just after a restart or fresh boot (systemctl restart openhab2). Furthermore it happens at random, with one exception. When I stop testing for more than 2 hours and start again, the first time the light will respond immediately. It like something is queueing until a refresh occurs.
What might by worth saying: I deleted several multiple times. That because I found did not configure the Fibaro fmgs-001 eye-ball correctly. I could not address the motion alarm. I deleted all and created everything again using . I think I’d better restore the backup I made after the first complete install, instead of deleting things. Deleting does not cleanup the jsondb completely.
But first I will try to debug
Configuration:
Platform: raspberry pi 3 / z-wave module RazBerry
OS hassle-free install. Uname -r: Linux openHABianPi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux
Hi Ben, I just found out that the situation in my ZWave network improved a bit by setting the “Polling Interval” of every ZWave device higher. (In my case to 6 hours) This is only a polling check to see if the device is still online, so it should not delay anything else than this check. Maybe this will help you too.
Thank you David for your prompt response. But I get the idea I have a completely different issue. I do not know when it started but openHab detects the same fgms-001 eyeball twice, once as node 4 and also as node 5. I think my best option is to start from scratch and see whether the same problem occurs again. I would not be surprised I messed something up, nevertheless I think openHab should be aware it offers to add the same thing twice.
Mind the zwave device numbers. Normally I use habMin to add Things but that does not immediately show the device number, therefore I made a screen copy open the paper UI, but habMin behaves the same way.
I assumed that device number was pulled from the device and would be different for each device, some kind of a serial number. I am almost certain I did something wrong. But I’am not sure what. I did not exclude the device, I used openhab-cli to clear all Things, Items and Links and configured everything again using habMin. Maybe that was the mistake I made.
I restored the backup and after that openHab came up with only one Fibaro fgms-001 eye-ball.
It did not solve the delay that sometimes occurs when switching on the Light after a Motion detection event occurred. Something causes the “Frames cancelled” is increased on the Controller. I will dig deeper.
Regarding the delay in Switching on the light after motion has been detected I think I found what is causing it in my case. I have 1 light switch(Fibaro Dimmer 2) and 2 motion detectors (Fibaro eyeball FGMS001) and the delay only occurred for 1 of the motion detectors. Comparing the configuration of both motion sensors revealed only 1 difference in the configuration of the Association Groups. The 1 responding well only had the the zwave controller defined at the Lifeline. The other one had besides of the Lifeline also the zwave controller and the Fibaro dimmer 2 defined in the Motion BC group. I do not have the knowledge why, but after clearing the settings in the Motion BC group both motion sensors work flawlessly. It must have been the configuration of the Motion BC group causing the zwave controller to report Cancelled Frames. Whenever Cancelled Frames were reported, which did not happen every time, there was a delay of 5 seconds.
