Delays with version 3.0.1.124

[integlikewhoa]

Check each child device on those Aeon's - the device scan (or rescan) has an annoying habit of assigning polling values to every child device. Would love to see that fixed for the ZW100 in Homeseer as its not even necessary to poll them at all - they have a number of different ways to set up reporting in the parameters that work well.

For that matter, I would like to see the arbitrary assignment of polling values completely removed from the rescan function, as well as any custom changes to the device. I hate being forced to rescan something, and then having to redo all my custom icons and settings for that device because rescan reverts to defaults.

I have removed polling on all the children (did that yesterday, problem still there). They are all USB powered and I have the auto reporting based on value changes not time or polling.

[rmasonjr]

For that matter, I would like to see the arbitrary assignment of polling values completely removed from the rescan function, as well as any custom changes to the device. I hate being forced to rescan something, and then having to redo all my custom icons and settings for that device because rescan reverts to defaults.

+1
I never understood HS enabling polling on devices that report usage automagically.

[Moskus]

That root device 'Unknown' drives me nuts when it occurs. There is an hs. command that is supposed to fix the icon and reset it but it has never worked for me. Rescan doesn't fix it either. The only success I have ever had when a device changes the root is to remove and re-add it from scratch. Annoying.

As far as I know setting a polling value in the root only commands it to poll every child device, and not the root itself. From what I have read on the boards, the root icon getting changed is a database anomaly and not a result of the polling. Rich can probably speak more to this though.

Yeah, but these devices have NEVER had polling enabled.

But that gave me an idea. I enabled some logging of poll commands misc. other things. Here's what's going on:

jun-13 20:30:08
Z-Wave Warning 
Z-NET #1: Device (Node 40) woke up, but queued command failed to be sent. Command=Poll Device 


jun-13 20:30:08 * 
Z-Wave 
Wake-Up Util Proc for (0. etg Kjellerstue Bevegelsessensor, Root) handling: Poll Device 

jun-13 20:30:08 * 
Z-Wave 
Z-NET #1: Wake-Up Notification Processing for Node 40 (0. etg Kjellerstue Bevegelsessensor, Root) 
jun-13 20:30:08 
* 
Z-Wave 
Z-NET #1: Z-Wave Wake-Up Notification Received for Node 40

There is a 12 hour poll interval on the battery sensors, but that's set by HS not me. This happens every hour. But only with Everspring sensor, it seems like Fibaro and AeoTech sensors are unaffected. I just restarted, so I'll check the logs tomorrow morning.

If there's a poll scheduled by each battery powered device, but it never runs.... would that result in a backlog of polls?

[randy]

+1
I never understood HS enabling polling on devices that report usage automagically.

This was fixed in 3.0.1.128.

3.0.1.129 was just posted in the beta section, but I don't know what changed.

[rmasonjr]

This was fixed in 3.0.1.128.

3.0.1.129 was just posted in the beta section, but I don't know what changed.

ah - thanks Randy!

[Moskus]

This was fixed in 3.0.1.128.

3.0.1.129 was just posted in the beta section, but I don't know what changed.

Wow.. I just installed .128. No change log?

[bebaldin]

I'm not sure if my problem is related or not, but I added two more Multisensor 6's to one I had already installed.

After installing the new ones and trying to put an event to turn on a light I get a huge delay. I also have a delay on my previous events (open pantry door turn on light). After not walking or using the new installed motions on the mulitsensors for a bit everything returns to normal and pantry or closet lights will turn on right away when door is opened. Until I walk infront of the new motions again and that seems to put a lock on everything.

This actually sounds like a routing issue than polling. Check the poll queue on the z-wave configuration page. If polling is an issue, you will see the poll queue sit above zero for more than just a couple of seconds, and you will see the command queue sit above zero. Anytime I am chasing a polling issue, I see the exact same thing.

Look at your node information page and see what the last known good routes were for your sensors and your target devices. Ideally, these should be direct or have as few hops as possible. If you have one that has 3-4 hops then this can cause activation lag. I generally follow the following procedure for any new device that I add:

Add the device through inclusion.
Immediately rescan the device again upon inclusion, watching the log closely for any anomaly in class or child creation.
Rescan a second time to make sure all stays 'in the black'.
Perform a full optimization on the node, and then an audit to ensure that the neighbors list is Excellent.

This almost always ensures proper routing for me. Make sure you watch the association creations in the scans, and that the full optimization correctly adds the routing to your controller. If your device has problems with classes or child devices after this procedure, remove it and start over. Once you have a device that exhibits problems like these, its time to cut your losses. The chance of a successful repair of missing command classes is just about nil in my experience.

If you can get classes, routing, associations and polling all working together, your activations should work almost instantly.

One other thing I have found - it's sometimes helpful to check the detailed logs and watch the comms in realtime. I have been able to find rogue devices flooding the network with traffic by doing this. Had a Enerwave SC7 scene controller with a stuck button that played havoc just the other day. Only way I found it was through the detailed logs.

One other thing I remember from doing my ZW100s (I have 21 of them) - look at the light on the sensor when the motion trips, and see how long it stays on. If it is a long time, like 5 seconds, the sensor isn't communicating well to the controller and a rescan / optimize might be useful. I also change the reporting on mine (parameter 5) from 1 to 2 for the basic report, which makes the activation a little snappier.

What I like to do is to write an event for each device that sets up the parameters. This allows me to manually trip the event for any device, and instantly push out my customizations to it. Helps me to remember what I did for each:

IF This event is MANUALLY triggered Submit Submit Make changes to this trigger or condition. Submit Add a trigger or condition.
Then Set Configuration Parameter 3 on device Node 2 Hallway Multisensor: Hallway N to value 240 (2 bytes). Submit Submit Make changes to this event action. Delete this action. Submit
Then Set Configuration Parameter 4 on device Node 2 Hallway Multisensor: Hallway N to value 1 (1 bytes). Submit Submit Make changes to this event action. Delete this action. Submit
Then Set Configuration Parameter 5 on device Node 2 Hallway Multisensor: Hallway N to value 2 (1 bytes). Submit Submit Make changes to this event action. Delete this action. Submit
Then Set Configuration Parameter 101 on device Node 2 Hallway Multisensor: Hallway N to value 241 (4 bytes). Submit Submit Make changes to this event action. Delete this action. Submit
Then Set Configuration Parameter 111 on device Node 2 Hallway Multisensor: Hallway N to value 300 (4 bytes).

This is a sample of one of my ZW100s - it sets up a variety of motion sensing and sensitivity, reporting, and time functions on the sensor. These seem to work best for me but there are a lot more params that you can experiment with. I do this type of thing for every single device on my networks.

[bebaldin]

Yeah, but these devices have NEVER had polling enabled.

But that gave me an idea. I enabled some logging of poll commands misc. other things. Here's what's going on:

jun-13 20:30:08
Z-Wave Warning 
Z-NET #1: Device (Node 40) woke up, but queued command failed to be sent. Command=Poll Device 


jun-13 20:30:08 * 
Z-Wave 
Wake-Up Util Proc for (0. etg Kjellerstue Bevegelsessensor, Root) handling: Poll Device 

jun-13 20:30:08 * 
Z-Wave 
Z-NET #1: Wake-Up Notification Processing for Node 40 (0. etg Kjellerstue Bevegelsessensor, Root) 
jun-13 20:30:08 
* 
Z-Wave 
Z-NET #1: Z-Wave Wake-Up Notification Received for Node 40

There is a 12 hour poll interval on the battery sensors, but that's set by HS not me. This happens every hour. But only with Everspring sensor, it seems like Fibaro and AeoTech sensors are unaffected. I just restarted, so I'll check the logs tomorrow morning.

If there's a poll scheduled by each battery powered device, but it never runs.... would that result in a backlog of polls?

Yes, that is certainly possible. Watch the poll queue closely on that for a day to see if your queue is steadily moving up.

I wrote an event to flush the polling queues every hour from my networks to keep that from occuring.

[bebaldin]

This was fixed in 3.0.1.128.

3.0.1.129 was just posted in the beta section, but I don't know what changed.

I can confirm that the fix does not work on the ZW100A sensors. I have rescanned several of them since I installed 128, and they picked up arbitrary polling values that I had to clear out.

[integlikewhoa]

I agree my problem seems like the sensor is not reporting to HS fast or correctly. Watching the device in HS3 it doesn't show tripped for some time.

They are direct in the rounting and are not far away. I have tried to Optimize and rescan more then once.

Only thing I notice is these sensors are version 1.07 vs. my old one I have no problems with is v1.06.

The green light does stay solid for some time.

I also have z-Seer+ and played with them in there also. No issues noticed.

I will have to play with the z-wave debug logs more now that I found out how to turn them on.

[S-F]

A negative result may still be useful? I am not seeing any of these issues at all. Z-Wave is just as robust as ever. For the record the only battery powered device I have is a single door lock. I never had any happy times with battery powered Z-Wave devices so I sent them all to my HA graveyard box in a dusty corner of the basement. I'm saving up for a hydraulic press to send them all to crush land. Along with my Vera. I'll make a youtube video or something of that. It's going to be a liberating day! I can almost taste it.

[bebaldin]

Wow.. I just installed .128. No change log?

I definitely want to know what has changed between 128 and 129 before I take the plunge...

[bebaldin]

I agree my problem seems like the sensor is not reporting to HS fast or correctly. Watching the device in HS3 it doesn't show tripped for some time.

They are direct in the rounting and are not far away. I have tried to Optimize and rescan more then once.

Only thing I notice is these sensors are version 1.07 vs. my old one I have no problems with is v1.06.

The green light does stay solid for some time.

I also have z-Seer+ and played with them in there also. No issues noticed.

I will have to play with the z-wave debug logs more now that I found out how to turn them on.

All of my sensors are 1.07 firmware. Try the parameter 5 change to 2 and see if that does anything for you on those new sensors.

If you see a large lag between the time that you trip the sensor and the time the log reports it, and you definitely know that polling or routing are not the culprit, look for a rouge device. It doesn't take but one device chattering to screw up an otherwise good network!

[bebaldin]

A negative result may still be useful? I am not seeing any of these issues at all. Z-Wave is just as robust as ever. For the record the only battery powered device I have is a single door lock. I never had any happy times with battery powered Z-Wave devices so I sent them all to my HA graveyard box in a dusty corner of the basement. I'm saving up for a hydraulic press to send them all to crush land. Along with my Vera. I'll make a youtube video or something of that. It's going to be a liberating day! I can almost taste it.

My Vera Plus met Mr. 12 Gauge when I moved to HS. It was glorious.

[integlikewhoa]

I definitely want to know what has changed between 128 and 129 before I take the plunge...

My Z-Seer+ quit working with 129, but I haven't tried a restart or any other fixes yet.