Indeed, and in general I’m quite happy with the work you guys are doing. I have what I would consider a fairly expansive setup with many dozens of devices, plugins, and scenes, and things have been working quite well up till now. I also understand that bugs happen (I’m a developer myself, and can’t claim to have released anything bug-free), so it doesn’t bother me that there were issues with this release - I assume they will be fixed, and life goes on. It was just that response of “this is expected” that was a bit off-putting to me 
2 Likes
[quote=I just upgraded my Vera Edge from 1.7.3500 to 1.7.4969 (7.31 incl hotfix). Before I did the upgrade I have set all my devices to autoconfigure = OFF using your code.
All went fine! I did some checks and everything seems to be working.
[/quote]
So in my case the upgrade went very good. But please take into account that it concerns a Vera Edge where I installed recently 31 zwave nodes and these plugins: Reactor, Switchboard, Housemode and AltHue (next to the annoying plugins that are preinstalled by Vera Sercomm camera, Apexis camera, Ezlo camera, Amazon Alexa and Google Home…)
Also I did all my automations so far in Reactor.
So no old plugins and no scenes had to be transformed to the new firmaware.
I notice someting very odd though: at all the child devices I suddenly cannot change the room anymore in the usual way. This field just dissappeared ??? I only can change room now via advanced → params and enter the room number here in the field room (after checking the correct room number that vera has assigned). This is applicable for all the zwave devices, not for child devices created by plugins.
So not very user friendly and again workarounds needed
I also hope lessons are learned and also from the learned lessons.
Can someone point to the code for disabling autoconfig on existing devices in bulk? Couldn’t find it via a few different searches.
Really? The link to the post is just a few posts above yours.
Yeah weird, that post is garbled for me (has broken HTML in it), and the link was broken, but other ones looks fine, so not sure what is going on the the forum there. Doh!
For k, v in pairs(luup.devices) do
if v.device_num_parent == 1 then
luup.variable_set("urn:micasaverde-com:serviceId:HaDevice1", "AutoConfigure", "0", k)
end
end
This also in the top 4 post of the Zwave on vera explained thread which I posted for people to use for reference.
Thank you Sorin.
Should I open a ticket for that ?
Many thanks Rafale77, the scene works again.
That is totally unacceptable!
Reading all of this confirms my gut feeling I will definitely not upgrade my Vera Plus this time.
Doing so will for sure break my setup, the Visonic plugin that I use is not maintained anymore with nobody able to check if it will survive 7.0.31
The Vera “does what it needs to do” at the moment so I seek comfort in the “if it ain’t broke, don’t fix it” mantra 
Big THANK YOU!!! @Sorin
Support team did their magic… (not sure what they did but it required creation of another user account … i guess so they can check and replicate issue at their end)
Just need to check geofencing and if that works i’m back to where I was before upgrade.
On another note… new firmware seem to be much faster. both the mobile app and web interface are much more responsive
1 Like
Thank you, I’m happy that the team managed to get you back on track.
I’m sorry for the trouble, to begin with.
I was in a similar situation relying on GE/CADDX security panel plugin which hasn’t been supported for years. This capability was the sole reason I got my first Vera many years back and without it working, I would need to move on.
I went ahead with the 7.0.31 upgrade on my VeraPlus and it’s working fine as a Z-Wave hub + security plugin with all else (UI, scenes, etc) being handled by Home Assistant on a RasPi.
The only issue I had was a ZCombo smoke/CO detector was showing “waiting on wakeup to configure device”. To clear this, I pushed the test button on the detector to wake it then selected “configure node right now” in the Vera UI. This worked to clear the message but had the ill effect of removing the daughter CO device!
Vera Support was contacted and they first suggested restoring the Z-Wave backup. This worked to restore the missing CO device, but the “waiting on wakeup…” message returned. To confirm this wasn’t a one off issue, I tried to wake/reconfigure again and the CO device went away again. Support then said I needed to exclude/include it again, which I hoped to avoid.
All in all, not a big deal. just restore the Z-Wave network and ignore the message.
@Sorin, I know that there is probably nothing you can do and it is a fundamental design issue with the way the engine is built. I also know that it isn’t the focus of the management and this has been a problem for many years. I sense from the few interactions I had with some of the devs that there is also a great amount of pride holding this flawed design and little motivation to revert flawed implementations but I will ask it again:
- Please eliminate all data manipulation routines run during the luup engine loading. I mean all of them. Do not set devices as unconfigured, Do not delete children devices even if they are orphan, Do not create devices. Nothing. This needs to stop. The loading should be a plain reading of the user-data.json and should be done within 1s or 2s. Not 1 minute.
- Move all of these user-data.json manipulations into a dedicated menu screen where errors and warning in the configurations are listed and allow users to either ignore them or suggest a course of action instead of doing them without user authorization.
- Stop trying to reconfigure the devices when there is nothing to do and the changes are only on the controller side. Example? Changing polling rate of a device or upgrading firmware of any kind. These are also a source of data corruption.
This is what I mean by treating user data as sacred. As it is the firmware is corrupting user data by design and as a side effect makes the luup reloading taking much too long to be (ab)used the way you are (ab)using it.
4 Likes
@Sorin: this is a bug in the new firmware! Can you please ensure that this is noted and will be solved in next firmware upgrade
Field to change room name (“assigned to room”) has suddenly disappeared for all child devices of all zwave devices.
What happens if you set “childrensameroom” to 0 in his master device?
That is possible and then you can assign the child devices to another room but first you have to check what the vera-nr of this room is and change it in the child device by going to advanced and change the field “room”.
So you still can change the room number of child devices but it is extra work so not user friendly
Hi Main,
With what browser do you get that issue? I have several controllers running at 7.0.31 but not having the issue you have (I tried; Firefox, Chrome, Edge).
Cheers Rene
I use Chrome. Will try Edge tomorrow