Seasons greetings. As many, I am trying to take a bit of time to iron out some kinks. I have issues with slow or non responsive z wave devices. I have removed all unwanted plugins. I have updated remaining plugins. I have run “top” from ssh and now showing fairly consistent maximum readings of 92% mem and 14%CPU. Before clean up it was 132% mem and 25% CPU. so I am no longer “running dead”.
I have also removed variable container in replacement for MultiSwitch in order to aid any problem resolution - info I have gathered from general threads on forum here suggested VC can cause issues similar to those I am facing.
I have then gone round all battery operated devices and set them to “No” under “automatically configure” so I can run a heal without them being configured as they often got pushed off the mesh. mistake made here. I should have done each one by one but instead did them all at the same time and things began to get worse.
I am now removing each battery device and re adding it and setting each as I want it from the outset. I have tried waking each device for it to configure but this fails to work and as such all battery operated device stay with a blue circle stating they are waiting to wake up to be configured. I have read on the forum that many battery operated devices waiting to be configured can break / cause the z wave network to cease working properly - I think this is now my case until I fix each battery operated device.
As such:
Is this the best setting on each device to stop Vera updating the device and the wider mesh
Is there another way to have Vera heal the network but ignore battery operated devices?
If I do continue as described above - will doing an “update neighbours” be the same as a mini heal if you will, on each battery operated device - thus optimising each device once all set up since it will be excluded from the wider heals when done?
Thank you in advance. Looking forward to having z wave nodes respond immediately again instead of taking 30 seconds plus!
[quote=“LightsOn, post:1, topic:184964”]I have issues with slow or non responsive z wave devices. I have removed all unwanted plugins…[/quote]Have you examined the log to try to determine where the delay lies. Is it Vera, routing, or the device?
I am now removing each battery device and re adding it and setting each as I want it from the outset. I have tried waking each device for it to configure but this fails to work and as such all battery operated device stay with a blue circle stating they are waiting to wake up to be configured.
This sounds like a routing issue. Is the the mesh sparse in the problematic areas?
I have read on the forum that many battery operated devices waiting to be configured can break / cause the z wave network to cease working properly
This should not have a negative effect on the Z-Wave network mesh. It may create a queuing/blocking issue on Vera though. This may seem to be be a distinction without a difference, but they are not the same and take different solutions to resolve.
1) Is this the best setting on each device to stop Vera updating the device and the wider mesh
It is if you only wish to prevent updates to certain devices while leaving others to be updated. If you want to completely stop network heals and reconfigures, then turn off Vera/Mios routing.
2) Is there another way to have Vera heal the network but ignore battery operated devices?
I can't think of one at the moment. But realize that Vera configuring a battery operated device will not break the network, as battery operated devices do not act as routers. But, if Vera chose an inappropriate route for an intermediate node that was on the path to the battery operated device, it might seem that way. The logs may or may not be helpful here.
3) If I do continue as described above - will doing an "update neighbours" be the same as a mini heal if you will, on each battery operated device - thus optimising each device once all set up since it will be excluded from the wider heals when done?
I'm not sure about this. It shouldn't hurt to try it though.
I think you should look at the logs and see just what is happening. Choose a problem node, send a command and see just what is happening and when. It’ll probably help to look at the AutoRoute for that node, to see what paths Vera thinks it should take.
It might also be helpful to look for an external cause. It may be that Vera is at fault, but it may also be that a route has been degraded by external factors like new obstacles(new or relocated furniture/appliances), new electronic devices(baby monitors), or a failing Z-Wave node.
Hi @ Zwaver, thank you for taking the time to reply.
Have you examined the log to try to determine where the delay lies. Is it Vera, routing, or the device?
? I have reviwed the logs but I cant determine if the issue is vera or routing. I am not that experienced in understanding logs yet but am learning. Would could I look for to identify an issue one way or the other? I am view logs via info viewer and logging to usb.
This sounds like a routing issue. Is the the mesh sparse in the problematic areas?
? No. Quite the opposite. Each battery operated device is no more than a few meters from a 3in1 sensor that acts as a repeater so as such should have no issue in communicating in the mesh. Some of the devices had worked fine and still do even though they no wont wake to configure after the change I made for Vera to not auto configure them. I think this issue is down to many needing configuration and it blocking things up. I run a heal and this seems to never complete properly in that looking at the progress it finds no good routes for any device. The status page never shows a report either. I hope this will change once all devices are configured properly?
This should not have a negative effect on the Z-Wave network mesh. It may create a queuing/blocking issue on Vera though. This may seem to be be a distinction without a difference, but they are not the same and take different solutions to resolve.
? I agree you are most likely correct here. What would I want to see in the logs to confirm this?
It is if you only wish to prevent updates to certain devices while leaving others to be updated. If you want to completely stop network heals and reconfigures, then turn off Vera/Mios routing.
? I have this disabled already to avoid automatic heals. However I still want to on occasions run heals on the mesh. As such, when I do run the heal, I want to exclude the battery operated devices so I see this option as the only way to achieve this as I understand it?
I can’t think of one at the moment. But realize that Vera configuring a battery operated device will not break the network, as battery operated devices do not act as routers. But, if Vera chose an inappropriate route for an intermediate node that was on the path to the battery operated device, it might seem that way. The logs may or may not be helpful here.
? I agree and it is for this reason I feel it best to exclude them from the mesh heals. Thus being able to manually update neighbours and hopefully not having a heal choose less optimal routes for the node in question.
I’m not sure about this. It shouldn’t hurt to try it though.
? Agreed ? I have read several post that state people are unsure if an update of neighbours is as effective and one may hope. With this in mind perhaps I may be better setting manual routing given I can easily tell which repeater node is closest and thus likely best to be the route to use?
I think you should look at the logs and see just what is happening. Choose a problem node, send a command and see just what is happening and when. It’ll probably help to look at the AutoRoute for that node, to see what paths Vera thinks it should take.
? I have run a test on one node that is showing a waiting to wake up to configure as a result of my changing its auto configuration setting. I have pressed configure now and then woke it up and in the logs I see:
o 02 12/29/14 10:09:30.964 JobHandler::Run job#71 :pollnode_wake #137 dev:1071 (0x13cb5a0) N:137 P:20 S:0 is 36.400220000 seconds old <0x2c3f9680>
o 02 12/29/14 10:09:30.965 ZW_Send_Data node 137 NO ROUTE (nil) <0x2c3
It might also be helpful to look for an external cause. It may be that Vera is at fault, but it may also be that a route has been degraded by external factors like new obstacles(new or relocated furniture/appliances), new electronic devices(baby monitors), or a failing Z-Wave node.
? I agree this needs to be considered but felt best to first start eradicating ll node issues individually ? e.g have all configured and set as required and heals working as expected etc. then if problem persists look at external factors. A heal when working as wanted should identify the best routes for nodes in the heal process. I can optimise each battery node path manually. So if I got to that stage and still had issues I guess external factors such a baby monitors etc can be the only thing left?
I will update again as I progress today volo me fortuna
I have noticed one battery door sensor has begun working again. it has no wake up to configure device message. I checked its settings tab and it is the one I changed back to auto configure last night. as such it seems to have fixed itself.
As a result - despite it not being the outcome I seek - I have set all back in the hope the system goes back to not having any devices requiring configuration. this would hopefully allay any thoughts over the issue of many devices requiring configuration causing an issue. if this is the case I can look at each one by one.
along side this. I have removed a battery operated device and re included it. I then set the device to not be configured “NO” in settings. it required the normal wake up to configure it. forcing wake up once again does nothing. so - could it be that it is only the minimote that allows this setting where as most other devices don’t like this setting and as such then refuse to wake up to configure?
There’s an awful lot of information here that, to me, seems contradictory and confusing?
I have reviwed the logs but I cant determine if the issue is vera or routing. I am not that experienced in understanding logs yet but am learning. Would could I look for to identify an issue one way or the other? I am view logs via info viewer and logging to usb.
While it is tedious and confusing, you must simply look through an entire sequence of events, after a problem command has been issued, to see if there are any delays, reties, or error messages... Anything that might lend a clue to the issue with that device.
Each battery operated device is no more than a few meters from a 3in1 sensor that acts as a repeater so as such should have no issue in communicating in the mesh.
We can hope, but we should not assume this. Also, it is important to remember that there may be other intermediate nodes in the route. A single node could impact several devices or even an entire network if it is a "gateway" node.
I run a heal and this seems to never complete properly in that looking at the progress it finds no good routes for any device. The status page never shows a report either.
So no routes for ANY device? Your previous posts stated issues only with battery operated devices. Is the issue with the entire network?
The two lines from your log file does not contain near enough information or context to surmise anything at all.
I have removed a battery operated device and re included it. I then set the device to not be configured "NO" in settings. it required the normal wake up to configure it. forcing wake up once again does nothing.
I would have expected this. You told it not to configure and then woke it. There is nothing for it to do, unless it is tripped. Were you hoping it would do something else? What?
could it be that it is only the minimote that allows this setting where as most other devices don't like this setting and as such then refuse to wake up to configure?
Again I am confused. What is the minimote about? What setting are you talking about?
Battery operated devices sleep 99% of the time. When tripped, they send the alert and then go back to sleep. At a scheduled interval they wake for a short period. Vera can use this time to poll or configure the device, if she wishes. If you tell Vera not to configure, she might poll at the scheduled wake up to check device presence and battery level, but that is all.
Agreed ? I will endeavour to be clearer and more specific as I do appreciate the help.
While it is tedious and confusing, you must simply look through an entire sequence of events, after a problem command has been issued, to see if there are any delays, reties, or error messages… Anything that might lend a clue to the issue with that device.
? Okay ? as I progress I shall read more. I have read the wikki so I understand format a little better now. So far logs are not showing anything that immediately shows any issues. I am sure they will in due course and I shall look further for each specific issue as I go.
We can hope, but we should not assume this. Also, it is important to remember that there may be other intermediate nodes in the route. A single node could impact several devices or even an entire network if it is a “gateway” node.
? This is an interesting thought. My Vera is in the loft ? not central in the house. perhaps all end up routing through one 3in1 node somewhere (hall landing perhaps) and as such I get ?bottle necks? ? certainly worth exploring further in due course. Perhaps consider a relocation to a more central position.
So no routes for ANY device? Your previous posts stated issues only with battery operated devices. Is the issue with the entire network?
? This is something I have noticed whilst doing these works. The issues primarily are indeed the battery operated devices not waking to configure when set to not be effected by vera. But also this wider process is to support resolution of a slow network mesh. 30 seconds plus in some cases to respond to commands. This has not always been like this so here I am trying to tidy up the system and resume it to working order. After a manual heal with stress test I used to be able to view a report / star rating etc. this never shows when a heal is done now and on viewing the progress of a heal it states no good routes are found? Things are working on the wider mesh ? just slowly ? so routes must be there just not optimised?perhaps?
The two lines from your log file does not contain near enough information or context to surmise anything at all.
? Yes agreed ? I will spend more time reviewing logs and ask specifics when I appear to find a more suitable anomaly.
I would have expected this. You told it not to configure and then woke it. There is nothing for it to do, unless it is tripped. Were you hoping it would do something else? What?
Again I am confused. What is the minimote about? What setting are you talking about?
? Agreed I threw a curve ball here ? apologies. I have a minimote ? this device is fine. It has been set under settings to not be configured by vera. The same as I have been trying to do here with all other battery operated devices. On the minimote it does not hold a blue marker stating it is waiting to be woken to configure it ? it is just all working and as normal. It will not be included in a heal as a result of the setting. In contrast the other battery operated devices, and in the specific test mentioned on that of a door sensor. When the device is set to not be auto configured, setting saved, and vera dance complete; it now constantly has a blue marker stating it is waiting to be woken to configure. This in turn causes vera to then repeatedly state it is configuring devise. Vera is repeatedly hoping the device will awaken to be configured. Of course this is problematic. This behaviour is not seen on the minimote ? also a battery operated device. This hopefully examples my confusion and misunderstand of what I am expecting. I would like the same outcome as with the minimote. I would like for the battery operated devices to be not configured in a heal and allow for me to manually mange them ? but in trying to achieve this they all stay with a blue line stating they need to awake to configure and vera constantly is trying to configure them?
Battery operated devices sleep 99% of the time. When tripped, they send the alert and then go back to sleep. At a scheduled interval they wake for a short period. Vera can use this time to poll or configure the device, if she wishes. If you tell Vera not to configure, she might poll at the scheduled wake up to check device presence and battery level, but that is all.
? Agreed but in my case I also find that on a heal if the battery operated devices are included ? they sometimes have settings changed that are not optimal as a result of them not waking up in time. This then is a back track not a step forward. If I can set them to not be included as part of this ? manually optimise there settings ? I can then ensure that when a heal is done I am not at risk of degrading any battery operated routes as a result of them being asleep so much.
[quote=“LightsOn, post:6, topic:184964”]When the device is set to not be auto configured, setting saved, and vera dance complete; it now constantly has a blue marker stating it is waiting to be woken to configure. This in turn causes vera to then repeatedly state it is configuring devise. Vera is repeatedly hoping the device will awaken to be configured. Of course this is problematic.[/quote]Try waking the device and then clicking Configure node right now.
Done that and the device never wakes. Very odd. Only works on the minimoye as previously mentioned. I have for now retirned them to be configured and have relocayed vera. I am now just tidying up some last inclushions etc. Then will run a network mesh wode heal. From there I plan to revoew the logs for each problem device. Its a start of a plan
Okay so the restore worked but some recent items went un recognised so i removed the thermostat nd re added it as i did with a hspo2 sensor. all working great.
went to include a 3in1 and smoke detector and no cigar - they wont include properly - they get seen but never configure. i remove them and they do not get removed. just a message stating 0 nodes removed. another frustrating hurdle. i have been at these 2 devices all day and they just wont play ball. i even have a spare new 3in1 and that has the same result.
I also notice a heal only take 5 minutes - i think there might be another issue here but logs show nothing.
[quote=“LightsOn, post:11, topic:184964”]went to include a 3in1 and smoke detector and no cigar - they wont include properly - they get seen but never configure.[/quote]Hav eyou tried waking them and then configure node right now?
i remove them and they do not get removed. just a message stating 0 nodes removed.
What does this mean? Please describe your process. Are you deleting from the dashboard or are you excluding the device? If you are excluding, as you should be, are you trying to do it in situ or are you moving the device close to Vera or the Vera close to the device?
I also notice a heal only take 5 minutes - i think there might be another issue here but logs show nothing.
Depending on the number of nodes, this may not indicate a problem. Especially if you have disabled the configuring of battery operated devices.
Yes, tried waking then configureing node right now. No cigar.
When I remove them I exclide them using full power and then I get the message removed 0 nodes. I also remove via deleting manualy if devices remain. I have tried all these process with vere in situ and also located next to said nodes.
I gave up on stopping battery powered devices for now as per above posts due to the system not behaving as expected and a a result slowing down progress. I have around 20 repeayer nodes and about 10 battery powered nodes. I also have lightwave switches jit tjese are not relervant here. With all included bar the two problem devices a heal should take at at least 1 hour to allow for battery devices to wake so there must be a bug or something somewhere.
I also regularly get the failed to go into learning mode quirk.
You put a device next to Vera and try to exclude and it fails to exclude? That sounds like a broken device or a broken Vera.
You stated earlier that you have a Minimote. Can you exclude the device with the Minimote? If not, I would suspect the device is the problem. If you can exclude it, can you then include it with Vera again?
It’s starting to sound like your Z-Wave network is a wreck. If your equipment is not bad, it may be worth considering a complete wipe and begin anew. I’m usually opposed to this type of heavy handed action and would recommend having support look at it before doing so. But from your descriptions so far, it sounds like you may be beyond simple repair.
I have not tried with the minimote but can. it does not get used much but is more just there and working if needed.
I have tried exclude and re include with 4 devices since the prior “role” issue and repair. 2 removed and included fine. hspo2 and also thermostat. the later 2 did not, a smoke sensor and three in one. I had a spare 3in1 sensor so got this out and tried excluding then including that - same issue.
I too think it is likely I have a mesh wreck or problematic vera - I have suspected this for some time. all seems slow and buggy and has for a while. I am very reluctant to back up everything and start a fresh yet in my heart I know its the best approach. or likely is. Obviously as you say I need support to look at it first however as I will lose at minimum 2 days getting back to where I am.
I will go and open a support ticket now and see what they say.
Best Home Automation shopping experience. Shop at Ezlo!
