Delays with version 3.0.1.124

[akurz]

I restarted the HS3 server because of some Windows Updates, and after HS3 started up again I sometimes get delays!

Most of the time it's working great, but then suddenly, there is 10-15 minutes where everything is horrible delayed. I use 311 MHz motion sensors as light trigging aswell as Z-wave motion sensors, and there's no difference in delay between the two. The delays can be up to a couple of minutes.

Then, 10-15 minutes later, everything is working like there was no problem. Wait a few hours and I get a new 10-15 minutes of delays.

I'm on .130 if it matters.


This happened right before the last "fifteen minutes of delays":

jun-22 11:30:45	 	Z-Wave Warning	Z-NET #1: Device (Node 28) woke up, but queued command failed to be sent. Command=Poll Device
jun-22 11:30:44	 	Z-Wave	Wake-Up Util Proc for (Diverse Z-Wave Vannsensor kjellergang, Root) handling: Poll Device
jun-22 11:30:44	 	Z-Wave	Z-NET #1: Device (Node 28) woke up and Poll Device for Diverse Z-Wave Vannsensor kjellergang, Temperature 2 was successfully sent.
jun-22 11:30:43	 	Z-Wave	Wake-Up Util Proc for (Diverse Z-Wave Vannsensor kjellergang, Root) handling: Poll Device
jun-22 11:30:43	 	Z-Wave	Z-NET #1: Wake-Up Notification Processing for Node 28 (Diverse Z-Wave Vannsensor kjellergang, Root)
jun-22 11:30:43	 	Z-Wave	Z-NET #1: Z-Wave Wake-Up Notification Received for Node 28
jun-22 11:28:24	 	Z-Wave	Z-NET #1: Z-Wave Wake-Up 'No More Info' Notification sent to Node 29(2. etg LH-rom Vindussensor, Root).
jun-22 11:28:23	 	Z-Wave	Z-NET #1: Wake-Up Notification Processing for Node 29 (2. etg LH-rom Vindussensor, Root)
jun-22 11:28:23	 	Z-Wave	Z-NET #1: Z-Wave Wake-Up Notification Received for Node 29

I don't think it's a coincidense. But it might be.

Hi Moskus,

I'm getting these errors a lot with the latest plugins as well - I've already asked about them a few posts earlier - but even though my log is full of them I don't get any perceivable delays.

Alex

[rjh]

You are seeing the messages because you have "log polling" enabled in the Z-Wave plugin. As for an error, that means the device did not respond when it woke up. When a device wakes up it only stays awake for a short time. If HS does not communicate with it fast enough it goes back to sleep. Maybe the PC was busy. You can monitor and see if the error appears on the same device multiple times, there may be an issue with that device. Some errors are probably normal, especially now that I have raised priority on commands. Handling wakeup stuff is not as important as an event controlling a device, the wakeup will be handled the next time the device wakes up.

Hi Moskus,

I'm getting these errors a lot with the latest plugins as well - I've already asked about them a few posts earlier - but even though my log is full of them I don't get any perceivable delays.

Alex

[Moskus]

You are seeing the messages because you have "log polling" enabled in the Z-Wave plugin. As for an error, that means the device did not respond when it woke up. When a device wakes up it only stays awake for a short time. If HS does not communicate with it fast enough it goes back to sleep. Maybe the PC was busy. You can monitor and see if the error appears on the same device multiple times, there may be an issue with that device. Some errors are probably normal, especially now that I have raised priority on commands. Handling wakeup stuff is not as important as an event controlling a device, the wakeup will be handled the next time the device wakes up.

I have disabled polling for ALL battery devices, and restarted the plugin. That did the trick, the Z-wave network is now the fastest it has ever been.

[akurz]

Hi Rich,

Yes, I'm aware that I see these log entries because I've turned on poll logging. Turning it off again would of course mean I'm not going to see these messages anymore, but that's not exactly the kind of "solution" I'm after.

I'm familiar with this kind off errors and they typically have no adverse effect of any kind. What I'm saying is that with later versions of the plugin - I can't say exactly when it started - they are MUCH more frequent than they used to be. And honestly, the only company I'm used to getting responses from along the lines of "yes, we know there's errors, but that's save to ignore" is Microsoft. Normally errors mean there's something not quite as it should be.

I'm really not polling a lot here - only a few values from battery powered devices, and the way it looks HS is able to poll all kinds of devices except battery. Here's an example of a device that has a couple of values polled:

Jun-25 00:44:30	 	Z-Wave Warning	Z-Net Wohnzimmer: Device (Node 30) woke up, but queued command failed to be sent. Command=Poll Device
Jun-25 00:44:30	 	Z-Wave	Wake-Up Util Proc for (Modules Z-Wave Fibaro Hall PIR) handling: Poll Device
Jun-25 00:44:30	 	Z-Wave	Z-Net Wohnzimmer: Device (Node 30) woke up and Poll Device for Erdgeschoss Flur Helligkeit was successfully sent.
Jun-25 00:44:30	 	Z-Wave	Wake-Up Util Proc for (Modules Z-Wave Fibaro Hall PIR) handling: Poll Device
Jun-25 00:44:30	 	Z-Wave	Z-Net Wohnzimmer: Device (Node 30) woke up and Poll Device for Erdgeschoss Flur Temperatur was successfully sent.
Jun-25 00:44:30	 	Z-Wave	Wake-Up Util Proc for (Modules Z-Wave Fibaro Hall PIR) handling: Poll Device
Jun-25 00:44:30	 	Z-Wave	Z-Net Wohnzimmer: Device (Node 30) woke up and Send Other Data command was successfully sent.
Jun-25 00:44:30	 	Z-Wave	Wake-Up Util Proc for (Modules Z-Wave Fibaro Hall PIR) handling: Send Other Data
Jun-25 00:44:30	 	Z-Wave	Z-Net Wohnzimmer: Wake-Up Notification Processing for Node 30 (Modules Z-Wave Fibaro Hall PIR)
Jun-25 00:44:30	 	Z-Wave	Z-Net Wohnzimmer: Z-Wave Wake-Up Notification Received for Node 30

And here's another one polling only the battery value:

Jun-25 00:59:35	 	Z-Wave Warning	Z-Net Wohnzimmer: Device (Node 66) woke up, but queued command failed to be sent. Command=Poll Device
Jun-25 00:59:35	 	Z-Wave	Wake-Up Util Proc for (Modules Z-Wave Fibaro The Button Pool) handling: Poll Device
Jun-25 00:59:35	 	Z-Wave	Z-Net Wohnzimmer: Wake-Up Notification Processing for Node 66 (Modules Z-Wave Fibaro The Button Pool)
Jun-25 00:59:35	 	Z-Wave	Z-Net Wohnzimmer: Z-Wave Wake-Up Notification Received for Node 66

So you can see that no matter how many values I poll - they all happen within a second after wake-up and it's always the battery value that bounces. The affected devices are from different manufacturers (Vision, Aeon, Fibaro) but show the exact same behavior. Also they happen pretty much every time a battery value is involved, so it's unlikely that a device has an issue or my PC or Z-Wave net are overly busy. It's something that changed only recently and it seems like it's been introduced with a change in the plug-in.

Luckily I've never had any delay issues. That would be really bad. This one is just slightly irritating but certainly something I could live with if need be.

Cheers,
Alex

You are seeing the messages because you have "log polling" enabled in the Z-Wave plugin. As for an error, that means the device did not respond when it woke up. When a device wakes up it only stays awake for a short time. If HS does not communicate with it fast enough it goes back to sleep. Maybe the PC was busy. You can monitor and see if the error appears on the same device multiple times, there may be an issue with that device. Some errors are probably normal, especially now that I have raised priority on commands. Handling wakeup stuff is not as important as an event controlling a device, the wakeup will be handled the next time the device wakes up.

[Guest]

Some errors are probably normal, especially now that I have raised priority on commands. Handling wakeup stuff is not as important as an event controlling a device, the wakeup will be handled the next time the device wakes up.

Hmmm ... Since this change in priority (have tried 130 and 131), I've been experiencing a specific problem with my battery powered motion sensors. One Everspring motion sensor randomly does not register a motion or no-motion status. However, observation of the LED indicator on the motion sensor indicates the sensor has detected motion and the reset. And one of my Aeotec Multi-sensors randomly registers an error status after detecting motion and timing out. That is annoying since I use these motion sensors to trigger lighting. I've had no changes to my system apart from upgrading the Z-Wave plugin to 130 and 131. I didn't have this problem on 128 and prior. Could it be that my problem is related to the mentioned change in priority?

Also I am noticing that the node routes (not only battery powered) are changing dynamically to some criteria I don't understand. Previously I could set a route (full optimisation or manually) for a device and it would stick. Now if I establish a route (full optimisation or manually) which works upon testing, I can come back in a few hours and find that the route has changed. The routes also do not look to be optimal as they appear to be taking very long multiple hops when there are much nearer neighbors. The hops I see now are radically different to what I have been used to observing on previous Z-Wave plugins. Was there a change in the way routes are optimised?

I've tried optimising and manually setting the routes the old fashioned way in the devices' Z-Wave tab/controller node info interface, as well as in Z Seer+. In both cases I am observing this dynamic routing changes.

Andrew

-----------------------------------

Current Date/Time: 6/25/2017 11:00:18 AM
HomeSeer Version: HS3 Standard Edition 3.0.0.318
Linux version: Linux hometrollerSEL 3.16.0-031600-generic #201408031935 SMP Sun Aug 3 23:56:17 UTC 2014 i686 i686 i686 GNU/Linux System Uptime: 2 Days 12 Hours 10 Minutes 6 Seconds
IP Address: 192.168.100.101
Number of Devices: 212
Number of Events: 186
Available Threads: 199

Enabled Plug-Ins
2.0.47.0: BLBackup
2.0.35.0: BLLAN
3.0.0.5: CM15A
1.0.0.0: drhsEventEnabler
3.0.0.103: HSTouch Server
3.0.1.84: PHLocation
3.0.4.8: SDJ-Health
3.0.5917.35093: UltraLog3
3.0.1.131: Z-Wave

[integlikewhoa]

Hmmm ... Since this change in priority (have tried 130 and 131), I've been experiencing a specific problem with my battery powered motion sensors. One Everspring motion sensor randomly does not register a motion or no-motion status. However, observation of the LED indicator on the motion sensor indicates the sensor has detected motion and the reset. And one of my Aeotec Multi-sensors randomly registers an error status after detecting motion and timing out. That is annoying since I use these motion sensors to trigger lighting. I've had no changes to my system apart from upgrading the Z-Wave plugin to 130 and 131. I didn't have this problem on 128 and prior. Could it be that my problem is related to the mentioned change in priority?

Also I am noticing that the node routes (not only battery powered) are changing dynamically to some criteria I don't understand. Previously I could set a route (full optimisation or manually) for a device and it would stick. Now if I establish a route (full optimisation or manually) which works upon testing, I can come back in a few hours and find that the route has changed. The routes also do not look to be optimal as they appear to be taking very long multiple hops when there are much nearer neighbors. The hops I see now are radically different to what I have been used to observing on previous Z-Wave plugins. Was there a change in the way routes are optimised?

I've tried optimising and manually setting the routes the old fashioned way in the devices' Z-Wave tab/controller node info interface, as well as in Z Seer+. In both cases I am observing this dynamic routing changes.

Andrew

-----------------------------------

Current Date/Time: 6/25/2017 11:00:18 AM
HomeSeer Version: HS3 Standard Edition 3.0.0.318
Linux version: Linux hometrollerSEL 3.16.0-031600-generic #201408031935 SMP Sun Aug 3 23:56:17 UTC 2014 i686 i686 i686 GNU/Linux System Uptime: 2 Days 12 Hours 10 Minutes 6 Seconds
IP Address: 192.168.100.101
Number of Devices: 212
Number of Events: 186
Available Threads: 199

Enabled Plug-Ins
2.0.47.0: BLBackup
2.0.35.0: BLLAN
3.0.0.5: CM15A
1.0.0.0: drhsEventEnabler
3.0.0.103: HSTouch Server
3.0.1.84: PHLocation
3.0.4.8: SDJ-Health
3.0.5917.35093: UltraLog3
3.0.1.131: Z-Wave

Your motion sensor can probley be fixed with the solution I had to do. Read back a bit on my posts and you'll see what i was told and had to fixed.

[Guest]

Your motion sensor can probley be fixed with the solution I had to do. Read back a bit on my posts and you'll see what i was told and had to fixed.

Thanks for your pointer. It's a long thread and I haven't been able to keep up.

I see your and others discussions related to routing behavior change, and the Aeotec Multi-Sensor 6.

I take it the workaround you refer to is this advice which is specifically for the Multi-Sensor 6:

Your perimeter #5 change to 2 worked like a charm and its now instant. So why did that fix it?
1 = send Basic Set CC.
2 = send Sensor Binary Report CC.

But that does not solve the Ecolink motion sensor problem which makes up the majority of my motion sensors

Seems that in trying to fix the delay problem, the command priority fix has introduced a new problem

[Guest]

OK, I think I see what is happening with my motion sensors (and also door sensors now) that occasionally and randomly are not indicating a change in status since I began using plugin 130 and 131.

To troubleshoot, I've focused in on one particularly problematic motion sensor whose status often appears to get stuck on 'motion detected'. Here are my observations.

• Motion sensor is located one concrete floor above my office where the Smartstick+ is located. It is a year old and been located in this same position since I installed it. It has always worked reliably until now.
• Since installation, I've noted that the 'last working route' has always gone through 1 or 2 routing nodes after doing a full-optimisation. And the nodes used to stick.
• Since using plugin 130 and 131, a full-optimisation sometimes results in a route through one other node which I would consider normal for it's location based on above prior experience, but sometimes results in a direct route which I've never seen it use before.
• Observations of the node routing for the sensor since using 130/131 also reveals that it changes occasionally between one or two routing nodes, and a direct route for no reason I can detect.
• When I've had problems with the sensor not registering a change in status, a look at the node routing always indicates that it is set to or has changed to a direct route. In other words, the problem only appears when the sensor is using a direct route.

I've since made the same observations with another motion sensor and a couple of door sensors which have also randomly but very occasionally not been changing their status. In each case, checking their last working route shows that they are using a direct route, when my year long experience with these sensors is that they have always used 1 or 2 routing nodes, and never a direct route.

My 2 cents worth. Wondering if others are having the same experience.

This problem is wreaking havoc with the reliability of my motion and door sensors so I need to find a solution. Can anyone tell me where I can get the Z-Wave plugin 128 or prior so I can revert?

[Guest]

Here are the screenshot proofs of my observations. This is my staircase Ecolink motion sensor.

At approx 5.56 pm, the Last Working Route = Node 2

Checked the Last Working Route at 8.11 pm when I returned home to find the motion sensor stuck and find that the Route = Direct.

The motion sensor status has been stuck on Motion since approx 6 pm (Last Change), over 2 hours.

Hope someone can explain what is happening with my sensors?

[rjh]

Note that HS does not have any affect on the routing. The routing choice is done in the Z-Wave interface with the Sigma code, we cannot affect it in any way. So if routing is the issue, its maybe due to some other changes in your devices. The routing code is closed source and we really don't know how it works.

I cannot think of any reason that the latest version would affect this. The handling of notifications has not changed. I guess you could go back to a previous version and see its better.

To go back, all the versions are on our server so you can grab the zip by just changing the URL, so for build 128 the url is:

http://homeseer.com/updates3/HSPI_ZWave_3.0.1.128.zip

Copy the EXE to your HS folder and the DLL files to bin/Z-Wave

OK, I think I see what is happening with my motion sensors (and also door sensors now) that occasionally and randomly are not indicating a change in status since I began using plugin 130 and 131.

To troubleshoot, I've focused in on one particularly problematic motion sensor whose status often appears to get stuck on 'motion detected'. Here are my observations.

• Motion sensor is located one concrete floor above my office where the Smartstick+ is located. It is a year old and been located in this same position since I installed it. It has always worked reliably until now.
• Since installation, I've noted that the 'last working route' has always gone through 1 or 2 routing nodes after doing a full-optimisation. And the nodes used to stick.
• Since using plugin 130 and 131, a full-optimisation sometimes results in a route through one other node which I would consider normal for it's location based on above prior experience, but sometimes results in a direct route which I've never seen it use before.
• Observations of the node routing for the sensor since using 130/131 also reveals that it changes occasionally between one or two routing nodes, and a direct route for no reason I can detect.
• When I've had problems with the sensor not registering a change in status, a look at the node routing always indicates that it is set to or has changed to a direct route. In other words, the problem only appears when the sensor is using a direct route.

I've since made the same observations with another motion sensor and a couple of door sensors which have also randomly but very occasionally not been changing their status. In each case, checking their last working route shows that they are using a direct route, when my year long experience with these sensors is that they have always used 1 or 2 routing nodes, and never a direct route.

My 2 cents worth. Wondering if others are having the same experience.

This problem is wreaking havoc with the reliability of my motion and door sensors so I need to find a solution. Can anyone tell me where I can get the Z-Wave plugin 128 or prior so I can revert?

[Moskus]

I still see some insane delays in my system, especially when running events like "All Off" (when we're going out). It takes up to 3-4 minutes just to turn off all lights.

I'm guessing that there's a node or two that is having problems, but I can't for the life of me figure out which ones. It seems like the errors are happening on random which makes it hard to find....

1. I find one node misbehaving (using a lot of time when testing, dropping out, etc).
2. Optimize it, or set new routes manually.
3. Everything seems to be very good.

12 hours later there's a new node that is misbehaving...
It wasn't like this before upgrading to .124, but it has been this way ever since. Downgrading to .110 (which I was on before) didn't help.

[Guest]

I still see some insane delays in my system, especially when running events like "All Off" (when we're going out). It takes up to 3-4 minutes just to turn off all lights.

I'm guessing that there's a node or two that is having problems, but I can't for the life of me figure out which ones. It seems like the errors are happening on random which makes it hard to find....

1. I find one node misbehaving (using a lot of time when testing, dropping out, etc).
2. Optimize it, or set new routes manually.
3. Everything seems to be very good.

12 hours later there's a new node that is misbehaving...
It wasn't like this before upgrading to .124, but it has been this way ever since. Downgrading to .110 (which I was on before) didn't help.

Are your routes changing (to something suboptimal), even after setting them manually? That is what I am experiencing. I've never seen routes change so frequently by themselves as it is on these latest plugin builds. Makes me wonder why there are such elaborate ways to manually set the routes (eg. in ZSeer+) when they never stick.

[Moskus]

Are your routes changing (to something suboptimal), even after setting them manually? That is what I am experiencing. I've never seen routes change so frequently by themselves as it is on these latest plugin builds. Makes me wonder why there are such elaborate ways to manually set the routes (eg. in ZSeer+) when they never stick.

I haven't checked, but I'm now writing down what I'm setting the new routes to. I'll check later.

However, I'm getting dropped frames even with directly communicating nodes.

[Moskus]

Are your routes changing (to something suboptimal), even after setting them manually? That is what I am experiencing. I've never seen routes change so frequently by themselves as it is on these latest plugin builds. Makes me wonder why there are such elaborate ways to manually set the routes (eg. in ZSeer+) when they never stick.

NOOO!

You are right! Setting routes manually has no effect, at least so it seems. I have a few nodes that seems to think that direct connection is best even though it isn't (which is strange to me). But setting a new router on another node or optimizing another node, seems to reset the route I set previously!

All that work for nothing...

[Moskus]

I also sometimes see some strange result if I'm optimizing a node multiple times with Z-Seer. Say I'm optimizing 4 times. The two first times, the node is set to communicate directly with Z-NET. The third, it's set to route through two other nodes. But then the next time again, it is communicating directly.


Same with testing a node: On the first run test 1-7 is flying by, then 8-10 is dropping out. Waiting three seconds before another run, and every test (1-10) is flying by again. Waiting yet a little more before doing another run, and now test 5, 6 and 7 is dropping out.

I really don't get this.
(Z-seer seems to be crashing more than before)