I’ve noticed through testing that a group.sendCommand(ON)/(OFF) with a switch is MUCH MUCH fast (instant vs 10+ seconds) vs a Dimmer in that same group. When I change the rule to set the dimmer item specifically to 0 vs off and 100 vs on it happens a half second faster than the switch. This is really frustrating when it comes to say using a group that includes a switch and a dimmer because a switch won’t respond to a 0 or 100 so I have to use a on/off. Which begs the question what is the purpose of a group if it makes organizing easier but the delay is such that its essentially worthless? Why is this? What causes a z wave dimmer to take so much longer to respond to what is essentially a turn off/on command?
Hi @dhog12,
10+ seconds is a very long time, and something seems wrong. Have you tried enabling more detailed logging to see what is going on behind the scenes?
Regards,
Burzin
Sure have. Which log file should I post? Events log, openahab log, audit log? I’ve been down this road before the log file ends up being huge so I need to find a way to pair it down and only post what is needed. Should I delete all logs and then run an on/off group scenario and then run an on/off group call + 0/100 specific dimmer call, would that be helpful?
events.log extract would be useful for initially isolating your problem.
It will show your ON/OFF or numeric command to the Group, and then the individual commands being passed along to member Items, with timestamps.
I’m expecting that to show no problem there.
Then you can move on to looking at why a shotgun blast of multiple commands to the binding doesn’t perform well. Some technologies do not manage the queue well. I think zwave tries its best, but of course it depends on the mesh which can ultimately only handle one command at a time.
I believe people have in the past found one poorly performing actor messing a group up.
Hi @dhog12,
Do as @rossko57 says.
Should I delete all logs and then run an on/off group scenario and then run an on/off group call + 0/100 specific dimmer call, would that be helpful?
Unless you are seriously short on storage space, which is probably a larger problem to address first, there’s no need to delete the logs. When I’ve enabled TRACE logging or had to deal with large log files, I’ve done something like this.
- Enable TRACE logging, which goes to the openhab.log file
- Do something like “tail -f /var/log/openhab2/openhab.log > /home/pi/Trace_Log.txt” This will redirect output to a smaller file that will be easier to parse.
- Run your test
- After your test completes (i.e. the dimmer turns on), CTRL-C to end the tail redirect
- Disable TRACE logging.
- Download the TRAC_Log.txt file and attach it to a post.
As @rossko57 says, you’ll also need the event logs to make sense of things.
Regards,
Burzin
There is definitely a queuing problem going on. I attached I think events.log (23.9 KB) openhab.log (1008.1 KB) all the relevant files but let me know if I missed one. The group call definitely seems to cause some problems, maybe I’m old school writing the logic and it could be improved.
homeitems.txt (12.6 KB) homerules.txt (4.5 KB) homesitemap.txt (3.7 KB)
additional files for reference
its the backyard section of the sitemap I’m trying to test but I noticed the living room scene also suffers from the same issue.
HI @dhog12,
There’s a lot going on, and I think you need to tell us what to focus on. It can probably probably be pieced together from what you sent, but I don’t know that many people will have the time or patience for that.
Per the event log, when did you trigger the scene, what items and rules where involved with that that?
I noticed Java exceptions and validations errors at startup, and a typo in a rule (from the rules, it looks like you corrected that.) Related directly to Z-Wave, I noticed thing discovery going on and at least one zwave communication error with one of the nodes.
Regards,
Burzin
Golly yes, I only looked at events.log and the zwave is in turmoil.
@dhog12 can you confirm this was just after boot up, at 22:10? There is lots of initialization going on amongst zwave Things which doesn’t leave much time for doing your commands.
I note the Astro binding is re-initializing too.
There are some trivial unrelated things you can fix to reduce clutter in openhab.log
2020-06-18 22:11:10.607 [WARN ] [.core.internal.i18n.I18nProviderImpl] - Could not set new location: "38.023363, -78.619380", keeping old one, error message: null
Check your location/locale settings in PaperUI
2020-06-18 22:11:15.880 [DEBUG] [core.karaf.internal.FeatureInstaller] - Failed uninstalling 'openhab-ui-dashboard': Feature named 'openhab-ui-dashboard/0' is not installed
2020-06-18 22:11:15.890 [DEBUG] [core.karaf.internal.FeatureInstaller] - Failed uninstalling 'openhab-misc-gcal1': Feature named 'openhab-misc-gcal1/0' is not installed
I think these may relate to unwanted bindings specified in your addons.cfg file
2020-06-18 22:11:19.463 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'home.items', using it anyway:
Duplicate ModelItem 'grpBackyard'
Duplicate ModelItem 'grpBackyard'
Bit more relevant, review your Item configuration
2020-06-18 22:11:21.146 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'home.sitemap', using it anyway:
Sitemap should contain either only frames or none at all
Linkable widget should contain either only frames or none at all
Review your sitemap structure
2020-06-18 22:11:36.714 [WARN ] [gcal.internal.GCalPersistenceService] - gcal-persistence:calendar_name must be configured in openhab.cfg. Calendar name or word "primary" MUST be specified
I don’t know anything about gcal, but it appears unhappy
Ah - I found a trivial fix!
Great, let me tackle all these things and see if it makes any difference. Thanks for pointing all this out.
I can confirm this was all after boot up. I deleted all the logs and then restarted openhab2 so as to give as little log data to go through as possible before I started adjusting the lights to test response time.
lat/long fixed now, thank you
@rossko57 is there a way to manually uninstall things? I thought I might use gcal awhile back so I installed it to try it out but I just don’t use it. I click the uninstall button in paperui and it says it is uninstalling but never finishes. When I later go back to it says its still installed.
Never had this trouble, I know people do. You can’t trust PaperUI whirly-busy-wheel much.
Stop openHAB, edit your addons.cfg to remove it, reboot.
Alright, so after fixing all the issues you brought up and conducting further tests I’ve concluded the following about my current setup
- putting a dimmer and a switch in the same group is a no go, my setup for whatever reason just either causes a non-response or an unacceptably long response
- putting dimmers in their own group and switches in their own group and calling each group individually to turn things on/off works reliably but the response time is still too long (less though than the bullet above)
- calling devices specifically (no group calls) works quickly and reliably, its disappointing the two above won’t work reliably but it looks like I have no other choice than to abandon the use of groups
The use of groups is not of itself a problem. The use of group commands produces a rapid-fire burst of individual commands, which it seems your zwave struggles to process. Splitting into two groups obviously reduces the size of the burst.
There may be improvements to be had from improving your zwave mesh, but in most cases that is a lot of work. Sometimes it is worth reviewing if you have unnecessary traffic like frequent polling, or traffic to sleeping or missing nodes.
You’ll find rule techniques in this forum to simulate group command behaviour by “slugging” i.e. delaying each command a fixed time. Sometimes the effects are preferable, as you can control the sequence.
@rossko57 thank you for the further feedback/advice, in the case of my set up it seems that just calling each individual item in my rule is going to make the most sense, you’re right maybe its the Aeotec controller but queuing, when left up to the controller, seems to make things worse
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.