Wanted to gather some thoughts and clarification if I may ask some peoples experience / opinions.
I have UI5 Vera 3 with the following settings under setup > zwave setting > options:
Ticked - By default Vera should automatically configure devices
Unchecked - Use Z-Wave version 3.20 instead of 2.78 IMPORTANT: Read this first
Unchecked - Use Vera routing instead of Z-Wave (requires 4.5)
Unchecked - Limit neighbors to Z-Wave discovery (requires Vera routing)
Ticked - Poll nodes learn more
Under setup > zwave setting > Repair I have:
Ticked - Re-configure all the devices when done.
Unchecked - Only update Vera routing (overrides other settings)
I have understood this set up to be best for me as it allows me maximum control of my mesh by disabling nightly heals if errors are detected etc. and also by allowing for me to view and manage the report to identify what is, and is not, on the fringes of the mesh that then perhaps thus needing more work for a better route.
I notice in most devices I have the following settings:
Autoroute (I understand this to be populated by a ?heal? but I am unsure if it gets rid of old data as part of this?)
ManualRoute (the field that if populated overrides ?Autoroute? and is blank unless manulay set.)
Neighbours (I understand this to be populated by a ?heal? but I am unsure if it gets rid of old data as part of this?)
I would like to somehow remove all info from each node so as to imitate a blank mesh ? to emulate a circumstance where each node has just been added and is unsure of its place in the mesh and or its neighbours. Could this be done by manually editing each of the above fields so they are bank? (Autoroute, neighbours, ManulaRoute) and then following this do a ?heal? so everything is refreshed to an optimised state? (Thus removing any old data not otherwise done so in a ?heal??)
I hope the above explanation of my thinking is clear; I welcome thoughts and experience of others. I am aware there is current reading on this and I have read the majority of it already but it all seems quite theory based and I have struggled to ascertain what is ?best practice? alongside what has worked best for users generally?
I have a mixture of repeaters (mains powered devices) and battery operated devices. Around 25 nodes in total.
My end goal is to be comfortable in the understanding that my mesh network is as optimised as it can be after the process (the process being discussed here) until such time as a node is moved or removed or another added, where by it would then be relevant once more to repeat the prior mentioned ?process? to ensure optimisation once more.
You’ve deviated pretty far from the defaults, which is something I don’t like to do without very specific reasons.
Why? It defaults to the newer 3.20
Unchecked - Use Vera routing instead of Z-Wave (requires 4.5)
Why? it defaults to checked. Though you would need to change the Z-Wave version above first.
I have understood this set up to be best for me as it allows me maximum control of my mesh by disabling nightly heals if errors are detected etc. and also by allowing for me to view and manage the report to identify what is, and is not, on the fringes of the mesh that then perhaps thus needing more work for a better route.
Disabling nightly heals are a valid option if your have a stable and properly working Z-Wave network. But, unless your network is large, or the nightly heal routinely "breaks" your routes, I would not turn it off. But, I would not argue against it either.
I will however argue against “maximum control of your mesh” or manual changes to routing if you do not have a specific need for it or you do not have a complete understanding of how the routing works.
Autoroute (I understand this to be populated by a ?heal? but I am unsure if it gets rid of old data as part of this?)
Each heal will rewrite the Autoroute field as needed.
ManualRoute (the field that if populated overrides ?Autoroute? and is blank unless manulay set.)
Yes.
Neighbours (I understand this to be populated by a ?heal? but I am unsure if it gets rid of old data as part of this?)
Each heal will rewrote the Neigbors field as needed.
I would like to somehow remove all info from each node so as to imitate a blank mesh ? to emulate a circumstance where each node has just been added and is unsure of its place in the mesh and or its neighbours. Could this be done by manually editing each of the above fields so they are bank? (Autoroute, neighbours, ManulaRoute) and then following this do a ?heal? so everything is refreshed to an optimised state? (Thus removing any old data not otherwise done so in a ?heal??)
I would not recommend this. It may work if most of your nodes are close to Vera but it is more likely to make many nodes unreachable, requiring many heals to get them back and possibly some exclude/includes before Vera figures it all out again, and you are right back where you started.
My preference is to use Vera’s defaults as much as possible. If I have a large network or one where heals break routes frequently, I might disable nightly heals. But, more often I will allow nightly heals and just restrict Automatically configure for the specific problem nodes.
Finally, as a last resort, I will use manual routes for a few problematic outliers. But, manual routing for many nodes is very cumbersome and impractical. If you feel that that is necessary, you almost certainly need to add more modes.
@ Z-Waver thank you for your reply. So perhaps I should add a small amount of history. I began ?tinkering? with the mesh when my systems started doing silly things and things slowly. The troubleshooting of this as I am sure you and others know can be annoying and lengthy. I initially looked to my mesh as the issue and then alongside this my wider system. See here:
I have since made excellent progress and have transitioned from many Lua code in scenes that trigger other scenes to using PLXX plus have updated all plugins plus have reduced the amount of plugins as a direct result of using PLXX as had a reduced need for virtual switches and timers; I have also moved Vera logging to USB and Datamine to NAS.
This then ? now greatly improved, brings me back to the mesh again, to ensure it is optimised as a closing element to this ?service? of my Vera unit. I think I can say my mesh network was not the main culprit even though I initially though it was. (I believe you helped me also in some previous / initial threads prior to the above mentioned one when I was dabbling with troubleshooting)
As such perhaps I am better now to return to enabling all the default options and allowing Vera to do its thing once more, to see if in fact over time things improve?
@Z-Waver and @oTi@ I have previously run Vera with 3.2 enabled but removed it as part of my desire for increased control and improved response from my network ? the specific reason for disabling it I now cant reference (embarrassing) but I believe from memory I had read in a post that if I was not using USB controllers nor the nightly heals so as such not mios routing over z wave routing, that the 2.78 was better. I am now guessing not.
So perhaps given my history and present / recent improvements, I should return my system to its default and see how things go? If battery operated devices routinely get excluded from the mesh than I should override this manually in each troublesome device so it is left alone and then follow this change with a heal on just that node? One final thought; if the heal is done around 2am ? my set up for OS reboot of the entire system at 3am daily is likely a bad idea given heals normally take circa 3 hours?
I won’t tell you what to do either way. The setup/configuration is too complex, at this time, for me to tell you what you do or do not need to do. I was simply explaining how I do it and discouraging changes from the defaults without knowing why and what the results will be.
If battery operated devices routinely get excluded from the mesh than I should override this manually in each troublesome device so it is left alone
It doesn't hurt to try and see if it works, but if they routinely disappear from the network, my recommendation would be to add intermediate nodes.
and then follow this change with a heal on just that node?
If you tell Vera not to configure the device, attempting to heal the device should have no effect on it.
One final thought; if the heal is done around 2am ? my set up for OS reboot of the entire system at 3am daily is likely a bad idea given heals normally take circa 3 hours?
Yes, I would say that this is a bad idea. Although, I believe that heals are supposed to resume if this happens, I would recommend that you change your reboot time to prior to the heal. Perhaps 1:00 or 1:30 would be a better reboot time.
@ Z-waver Thank you for that. I think I will return to default settings and do some tests over time to see if I have issues or not and then if I need to work with, or indeed around, individual battery operated nodes.
I agree it will be best to move the reboot to 1am and shall do this.
I will report back my findings on how things go for me however in the mean time if others have too had similar thoughts as me please do share your experience.
This would explain the [tt]AutoRoute[/tt] and [tt]ManualRoute[/tt] variables. I wouldn’t worry about them when running with 2.78 (they will be ignored). And with 3.20, but Vera routing disabled, you may want to manually clear out the [tt]ManualRoute[/tt] vars, where they exist.
Personally, I have been running 3.20 since it was available. But without externally-supplied routing (i.e. Vera or user); and so without any automatic nightly heal.
If you do elect to go back to 3.20, be sure to make a backup (database + zwave) beforehand, run ‘the hack’ to convert the database, and then back up again.
thank you for the info on rolling back up to 3.2 - will follow the wiki and your advices.
But without externally-supplied routing (i.e. Vera or user); and so without any automatic nightly heal.
if you have no vera routing or user routing how do you optimise? or do you mean you disable vera routing and don’t add manual routes but do run heals via the options tab when required?
Whenever a node does not respond immediately anymore (i.e. retry counter increments), I use the [tt]Update Neighbor Nodes[/tt] button for that node; which I consider a spot heal.
so I shall go back to normal defaults and then try either as I stated above or without nightly heals and just doing update neighbour nodes on any odd slow devices.
I will report back after a short period to update on how I got on.
2.78 brings with it SIS support, and as such MCV recommended I move to have that in order to support my Danfoss Living Connect valves (as they kept dropping offline).
Not sure if you have any devices that benefit/need SIS - but wanted to flag it just I case you reverted to it for a similar reason as I did.
While I’m on 2.78, I still have Vera Routing checked too
I believe I read that the vera routing deals with a certain zwave vulnerability that Aron @ MCV fixed with the “vera Routing” that, amongst other things, allowed for a more intelligent scan of the mesh supporting devices further away from vera in the mesh more proactively. I am of course going from vague memory here as I have read so much on this area recently that it is all a little bit of a blur. @Zwaver and other seniors here have far more in-depth understanding. Do have a search of the site for some background reading as there is a far bit - I would advise getting a warm drink and getting the reading glasses out though, I rolled my eyes when I first discovered how complex this ‘seemingly initially basic’ area actually is.
It does seem overall that there is not “golden rule” or “best practise” for a mesh set up. It seems it is necessary to understand ones own mesh, its number of nodes, types of nodes, etc. to then be able to understand how best to manage it. Weather to choose 3.2 or 2.78 is one choice with a possible reason such as that described by @Parkerc (SIS support) or perhaps the desire for USB remote secondary controller support as discussed on the wiki. Automatic heals if a non optimised network is seen by Vera during the day is useful for automated optimisation but if it finds a battery operated device (for example) that does not wake up in time it may kick it out of the mesh; as such a choice has to be made as to if this is or is not a benefit on your mesh based on the individual set up or perhaps if you do keep auto heals but exclude each trouble some device individually.
I am still working through what is best fro me but I can say for sure that it is certainly worth understanding as much about the elements as possible to understand what may then work best in your set up specifically. As a foot note I first though it was a slow mesh causing my system, to slow when in fact it was bad use of lua and too many plugins that was primarily causing my issues so if you too are looking to debug / optimise I would consider looking at your wider system and taking the time to review each element. lengthy but in my case completely worth it.
Bit of a ramble - apologies - but aside from the joys of Vera I can say the recent works I have done on my wider system have been a good education with great results and has made me feel far more in control of what to try and optimise and more importantly perhaps, why to do so.
Presumably, newer is better. So 3.20 is the default. As was brought up, the Z-Wave manufacturer did drop a feature, so if you need that / other devices get confused etc., you may want to revert to / stick with the older version.
Version 3.20 allows external routing, i.e. a route can be supplied to the Z-Wave chip. [tt]Vera routing[/tt] takes advantage of that. Presumably, more is better. So that is the default. It allows Vera, i.e. MCV, to implement their own neighbor discovery algorithm and their own routing algorithm for what they consider optimized routes, e.g. minimize hop counts, minimize latency, etc. As opposed to what the Z-Wave chip might do natively (e.g. any working route is a good route). And, apart from algorithms, it provides visibility into what the actual route is.
To keep things optimized and automatic, a [tt]heal[/tt] process is kicked off at night whenever some routing issue was detected. In my opinion, this process may, or may not work so well, or just take too long, or you may not like the results, or all the magic; in which case you could turn [tt]Vera routing[/tt] off and leave it to the native functionality of the Z-Wave chip.
OK… thanks. That [mostly] makes sense to me. I’m having serious issues with a Leviton controller that’s being discussed in this thread (i don’t want to get into double posting), and routing/mesh may be the issue. http://forum.micasaverde.com/index.php/topic,21241.0.html
Thanks for help!
Best Home Automation shopping experience. Shop at Ezlo!
