Well I guess my idea didn't work. Sorry about that. The only other thing I could think of, you have a zwave node acting funny, which is a really tough thing to find sometimes. I've had a light switch in the past that was starting to go bad, but things would work, most of the time, except when commands would get routed thru it before HS. I happened across a random error that pointed it out after months of pulling my hair trying to find the problem. It was causing delays everywhere in my system.
-
-
Interesting - why the heck it it even sending to node 30 (multisensor) at that point anyhow? How is that node configured? Is polling enabled, and if so what rate? Battery or USB powered?Comment
-
I think you might be on to something. It's currently usb powered and polling was enabled on all child devices. I've set polling to 0 for all of them to see if that helps.Originally posted by zwolfpack View PostComment
-
May or may not be off-topic? but useful none then less i think!
Try not to overlook the use of 'at least' command in events... for example if gate has been open for at least 5 seconds then trigger zwave device!
All my delays of 5-10 seconds vanished completely after i did some common sense maintenance on my events. Did not think that the same event would be triggering the same zwave device over and over and over and over again...
Using the becomes or exactly command dropped resources on zwave engine to minimum!Comment
-
Do you mind sharing a sample event and it's accompanying logs? I ask this because in my current setup, I have a few events I need to trigger on state changes and would rather not adding a 5-10 second delay on their states for the action to occur. It makes sense in a lot of situations though.Originally posted by deanrparry View PostComment
-
May have found something. Found 4 nodes (all being reported as Sigma Switch multilevel) that I cannot control and they are not responding. Gonna try to use the 'Remove bad node' function under Z-wave control and get rid of them. Hopefully that helps if it was contributing to the issue.
If it isn't one thing, it's another. Encountering another issue now trying to remove these bad nodes. Cross posted here.Comment
-
Removed the nodes I cannot control and found that polling was set at random times on quite a few devices a friend helped me setup. Removed polling from just about everything and went through the manufacturer documentation and set them based on their recommendations as needed. Have not noticed any delays since I last posted here so that's a good sign.Comment
-
Wow, I've a same issue happening since few days, z-wave devices have delays of around 5-6 secs if triggered from Events or Alexa, operating them from the App or Web has no delays.
All my z-wave devices has set to 0 polling. But I do have a failed node due for replacement, do not want to simply delete it else I'll have to modify events that include the device. That node was connected to a ceiling fan and got burned twice, so in the process of finding proper protection mechanism before I put another module there.Jun-26 09:55:48 Z-Wave Device: Living Lights Watts 1 (Entrance) Set to 0 (0 Watts)
Jun-26 09:55:43 Device Control Device: Living Lights Entrance to Off (0) by/from: CAPI Control Handler
Meanwhile, I think optimizing the z-wave network should remove any routing using the failed node & fix the delay, will try that.
EDIT: Discovered that the delay is happening from the app/web also, and is limited to one particular node, I guess need to check its routing.Comment
-
I may have an answer to your zwave delayed command problem that solved the same problem I was having.
Short answer: Power cycle all your zwave nodes. Yep, that means going to your breaker box and turning all the breakers off for a couple of minutes and then back on. (Think Jurassic Park, the first one, where they power cycled the system.)
My equipment: HS3Pro on a homebuilt PC, zwave usb smartstick on a long usb extension positioned up high for maximum range
Explanation: So, I have about 65 or so nodes, mostly light dimmers, homeseer brand. I have scenes setup on a lot of them to do different things like set dim levels for the great room, the movie scene which turns off all lights visible to the great room and so forth. If the system set idle for a while the first scene I activated would work, then the next scene would have a delay, sometimes up to a couple of minutes. It was never the same length of delay. All the scenes were affected. Today I started digging into the log, turning on zwave logging of everything and discovered that each time a scene was activated, homeseer then polled that originating device for it's status. For the switches I used the most, homeseer came back with an error saying it couldn't determine the status of it or something. Because homeseer was momentarily waiting on the polling result to proceed any further, it caused a delay executing the next scene. I could see the command que build up if I activated a lot of scenes at once while this was happening. After trying rescanning everything, and almost losing the entire configuration, it dawned on me, just power cycle the affected switch. So I did and it started communicating when it came back. So then, just like Jurassic Park (the first one), I took the whole house offline, waited like two minutes, and turned it all back on. Effectively power cycling everything. Now it all works like a charm. I can activated scene after scene after scene as fast as I can and it keeps up almost instantly.
So what caused it: Current theory by me says the power glitches I get, the really fast ones in the middle of the day from lightening storms or even my neighbors turning on their pivot irrigation, caused the switches to get into some kind of error state where they stopped sending but could still receive. Almost every switch I had was affected. What finally clued me in was a last ditch idea to update the firmware and with that I discovered homeseer wouldn't retrieve the current firmware version.
I'd to know if this solves anybody else's problem.
Thanks.Comment
Comment