I’ve been told by support that many of my issues stem from having migrated from a Vera Lite to a Vera Plus and that the only way to “fix” things is to rebuild… So, until i find a suitable replacement, i am going to bite the bullet and rebuild the entire Vera configuration (including z wave network ) from scratch since it has been driving the wife absolutely insane when things work one day, but not the next. To that end, any pointers on the best way to approach this? my though was to leave the Vera where it is, reset it and upgrade it to the latest version, then start including devices (after factory resetting them) one by one starting with the ones closest to the vera and moving outward. I’m dreading the idea of doing this on 30 plus devices including locks, but if i don’t, since the wife can’t leave the house either, I’ll probably end up being fed to the dogs. I’ll take any hints that will delay my imminent demise.
I did essentially that a few years ago. It’s not as bad as it sounds. Once you get the firmware upgraded and have a clean system with no devices, I’d suggest excluding all your devices first. After that, build the network out with AC powered devices as you suggest. Once you have that, I’d let it settle overnight, then add your battery devices. Some useful tips here.
Forgive my extreme skepticism given the symptoms you have.
Maybe if you could describe how many of them are secured and how many are battery operated, we could have a better assessment as to what is going on.
There is some truth to what they told you but much too often they use the findings from some corner cases like these migration from a zwave 300series to 500series and generalize it to everyone while in reality the problem is within the vera.
I did it while my network was relatively small (~30 devices so I was willing at the time) and it made absolutely no difference. Unless they can tell you exactly what part of the migration is causing your problems to the finest details, I wouldn’t do it. This is what made me go investigate deeper and deeper.
Inconsistency day to day is very unlikely related to anything with migrated from a vera lite. It would have to be a rare case of poor routing when transitioning from the mios routing table to the zwave one and this is supposed to be addressed by a few nightly heals. Even then the true root cause is from horrendous design of the vera command queue which is worsen by bad routing and zwave chattiness. They are giving you a shotgun solution akin to the luup reloads: “No idea what is going on, let’s reboot”, or “ohh device is malfunctioning, no idea what’s going on, just exclude and reinclude it” which is the dumbest thing you can do to it unless the device supports security and the security key exchange failed at inclusion, and to be fair, there isn’t much more they can do. It will just keep you busy for some time doing all this work and you likely will end up with the same problems.
It is way too much shotgunning instead of troubleshooting which would lead to finding root cause and addressing that to prevent problems from reoccurring.
One alternative to doing this would be to reconfigure every device manually but it would be quite similar to the exclusion and reinclusion given how the vera handles configurations. It would lead you to the same result which again, I am dubious that it would fix it.
@rafale77 thanks for the input… my network is probably 15 or so switches and dimmers, several plugin modules (i.e. light and dimmers as well), 3 battery powered door locks with security exchanges, five newer Zooz devices (dimmer / relay combo and some plug modules) that use secure exchange, a couple of thermostats, and about 10 battery operated sensors ( contact and motion). i have more, but these always give me all kinds of trouble, so i have not included them yet. my issues are mostly around adding devices. the latest zooz devices show up in the interface, but don’t report back their status. i can turn them on and off via the UI, but when operated manually they don’t update. This morning, the thermostat was showing a setting of 73 degrees on the UI, but it was 67 degrees at the thermostat. if i send it commands from the UI, eventually it kicks on to the setting it was supposed to be on and then updates itself at the thermostat. BTW this was the incident that drove the wife over the edge…
Not sure what else you would need from me, but happy to share anything you guys may need to steer me in the correct direction. I agree with you that it is probably busy work to do what i was planning on doing, but it at least let’s me tell the support folks that everything is base-lined per their recommendations. I would much rather fix my existing setup, but not sure where to start.
You seem to be having some zwave association issues. Since the communication itself does not appear to be a problem, it isn’t a mesh issue. Your devices are not reporting status to the vera properly and this is likely because they are not configured to do so.
To fix this, go into the device’s advanced configurations and add the vera (I suppose node 1) to all of them in the association group 1 which in zwave terms is called the lifeline and is the controller to which the device is supposed to be sending its status.
This should be a start. We can then take things in steps to see where it goes.
Thank you for trying to help me, i sincerely appreciate it and really value your input. Looked in the UI and for some reason their association number (AssociationNum) was set to 3… changed that, but they are still not updating correctly. i did a luul.reload() after changing them. i am attaching 3 pictures of the device.
First picture turned the device on, dimming set to 100%. the light does come on in the room.
Second, i used the UI to turn the device off. Note that dimming shows 100% and the UI icon still depicts on. the light turns off in the room.
Third, from the “off” position above, i dimmed it to 50%, that did turn the on swich in the UI to on. the light is at 50% in the room
still not updating if i do any actions on the switch itself.
My memory of the vera UI is fading away so bear with me…
Where do you see the AssociationNum? Is it a variable under advanced?
If so, it is the wrong place to look. I think you need to look under advanced/option or advanced/settings. It should be called “user associations”
This is not a variable stored by the vera. It is one stored in the device and you might need to get an updated from the device first to see what it is set at.
yeah, i was just looking at that… i think i changed a variable and not set the group. let me fix that and try again, will report shortly.
ok, read a bit on how to set the association, set it to 1 (Zwave). now the device reports “Failed at: Setting user association”
Make sure you set group 1 as 1. Your vera is at node “1” correct?
This failure should never happen unless your zooz dimmer does not support associations which I doubt or you set a group which doesn’t accept it.
well, i run a bit of lua at startup to get my device and node ID’s… when i get that table and sort by node id, this is the top few that i get. the “override” devices are virtual switches from rigpapa’s Switchboad plugin. i wonder if that is messing up my associations?
|_Scene Controller||DEVICE ID||2||NODE ID||=||1|
|Home Override||DEVICE ID||297||NODE ID||=||1|
|Outdoor Switch||DEVICE ID||4||NODE ID||=||2|
|Winter Override||DEVICE ID||298||NODE ID||=||2|
|Manual Thermostats||DEVICE ID||299||NODE ID||=||3|
|Away Override||DEVICE ID||300||NODE ID||=||4|
|Door Open Override||DEVICE ID||301||NODE ID||=||5|
This is bizarre. Why would a virtual device have a node ID? The vera typically uses the attribute “altid” to report the nodeid. Virtual devices should have this field empty. Where does this lua code get the Node ID?
If it is the altid, you definitely have a problem. These need to be unique and you have multiple devices sharing the same id. Delete the altid from the virtual switches and try setting user associations again… though I wouldn’t know why it would affect it.
well, i was assuming that the id field in luup.devices was just the node id, but in reading the docs, it says:
id : (string) If this device has an internal ID that is specific to the device, it is contained here. For example, for Z-Wave devices this is the Node ID, and for Insteon device it is the Insteon ID.
switchboard devices must use this field for some reason…
You are right. It is the correct field. For zwave devices it is the node id, for other types of devices, it could be something else. So indeed it should not affect the user association assignment.
ok, so i set the association per the image below…
now, i am unsure if i shoud select the zwave device or the _Scene Controller?
Device still shows as “Failed at: Setting user association” and does not respond to any commands.
I am not sure whether you should pick _scene Controller or zwave either. I don’t quite even understand why you would have both and even a 3rd one. I am also not quite sure what this bottom part does.
The lack of control over the network on the vera was the reason why I added a secondary controller to configure devices.
When you click on “View” what do you see? The vera should be sending an association command class get and report back the value of the association. I really don’t know why this would fail. I have never seen this on z-way.
view just shows which ones you selected… let me mess around and try the scene controller.
ok, selecting scene controller sets the association to 2…
Well this is odd. Really not sure why it would do that.
The device numbering on the vera is very confusing and I am afraid it is confusing itself. Even when I was using the vera I was using zway to check on the associations and reconfigure them as you can see below. It was a breeze.
i do have a UZB that i purchased to upgrade firmware on some devices, but don’t have zway. i am going to see what i can do about getting my hands on it to see if i can fix the association issues. @rafale77, where you cloning your network to the uzb, fixing it in zway and then cloning it back?