All my devices were set not auto configure, but the new firmware upgrade ignores this setting.
Release Notes - UI7 - Vera Firmware Update - v.7.0.31 (1.7.4954/1.7.4955/1.7.4956) - February 19th, 2020
But is it a “new” device if it already existed on the system on firmware 7.29 before the firmware update. Shouldn’t it just reconfigure the existing device and keep the same IDs ?
And it ignoring the Auto Configure set to No is also concerning.
Apparently, it cannot be ignored. I dont’ remember exactly what I did, probably it was a mixed approach.
Feb 20, Feb 21, 2020: Updated two VeraEdge units at two different locations. One location worked fine, excepting the loss of wattage display on my metered outlets (I see a hot fix is coming). The other location required me to upload the backup I took before applying the firmware change, as all room & device names, location, scenes, et al were gone after firmware was applied. Yes, I did the obligatory ctrl-F5 incantation after the control came back from the firmware update, but no luck on recovering my devices name, etc.
Additionally, I lost the Sonos app from the ‘My apps’ page, but the functionally still exists for the device. I must include that I used the modified version from GitHub https://github.com/toggledbits/Sonos-Vera.
I have 2 Neo plugs
One “Default”, one “no”
ID’s are same, all scripts, based on plugs, are Ok.
The vera update caused reboot / luup restart. That’s why the HUE devices disappeared not immedialty after the HUE hub update but after the vera update. I guess the code which syncs the devices with the hub and VERA will run only during the initialization / boot process.
I modified the HUE plug-in lua code by replacing the manufacturer name from “Signify…” to “Philips”.
I imported an backup that still contains all my HUE devices and replaced the lua file with my modificated code. Now it continues to work fine.
I’ve been lurking on this Topic, mostly because I never again want to be an early adopter of any new Vera firmware release (especially with a fun weekend coming up!).
But I did want to jump in and suggest that, when posting about our upgrade experiences, we include some basic system info, like:
- Total number of devices paired;
- Vera model being used;
- Number (or names) of plug-ins installed;
- Whether restoring from Backup was required;
So far, it looks like a mixed bag, although I’m certain threads of this nature tend to be dominated (rightly so) by users who’ve had negative experiences, which serves as a warning to others. (THANK YOU, btw!)
I’m going to continue holding out until next week. In the meantime, I’ll devote my Vera time to cleaning house (removing any end-of-life items, like dead remotes, unused apps, obsolete Scenes, etc.) so that my Plus has as much internal memory available for the upgrade process. [In the back of my lay mind, this just feels important.]
GOOD LUCK, ALL!
@thorazine, The upgrade is unfortunately not fully reversible. I discussed that elsewhere. You would have to ask support to do complete refresh. At the same time I would not recommend that.
The biggest reason why you want this firmware is explained in the first 4 posts of this thread:
Thanks @Sorin orin for intervening. Really appreciate your inputs. It actually corresponds very well to my experience. I have a number of unsupported devices in setup, all working perfectly… until they become officially supported. This is silly but I understand the underlying logic. As @therealdb said, a good practice would be to turn off auto configure. The problem for @thorazine is that his backups need to already have all these devices set with auto configure off. I would recommend support to do this: Attempt to pick on his user-data.json from the latest backup on the server and edit every device on it to turn off auto configuration. Save it and put it back on the backup and have @thorazine restore from it.
To the general public, and to the mios devs, auto anything on the vera has almost generally been a disaster and must be used cautiously. If for anything, the one thing I would want to automate on the configuration would be to disable all the mios auto stuff. I don’t mean to be offensive here but you really need to wake up and smell the coffee. A lot of what is below, I have explained before.
- The auto heal called nightly heal is a bad idea. There is never a good time for a heal besides the time when the users decides to do it. You cannot predict when the users will not use their homes. I am very grateful to be able to disable this nonsense. Thank you @edward.
- The setting of 1800s wakeup interval for battery device at inclusion is stupid. Why not leave it alone as default or read it back from the device instead configuring to such a low interval? You had be go back and reset this on over 50 devices after I discovered what was going on.
- The wakeup nnu which is an automated partial heal at each device wakeup is absurd and after disabling it for some time and observing it, I would recommend you delete it from the firmware altogether. It serves no purpose and only destroys the network. (battery operated devices don’t need to know their neighbors, they don’t repeat signals and this is just the start… if the device woke up and the vera got the wake up frame, why the heck would it ever need an NNU??? This, I call dumb and dumber). Thank you @edward again for allowing us to disable it.
- Wakeup polling which, even though they merely last 1s each, are completely unnecessary and should be configurable on a per device basis and not automatically enabled across the board. They still wastefully clutter the network’s precious bandwidth. This should be on the to do list.
- Auto configure might work for some devices at inclusions but even when it works, I would recommend to disable it upon successful configuration. Why? This is one case but you have these cases of data corruption leading to child device number iterations going up to wazzoo. Luckily this can be done in the firmware by disabling the auto configuration tag both for the devices and the zwave menu (default behavior) for new inclusions. If you want to do auto configuration, do it right, test it on all kinds of cases and cover all the cases. If not, just don’t implement it.
I know you guys (UI7 devs) were trying to make things easier on UI7 but automating things and taking decisions away from users but… you went too far too quickly and without sufficient testing. In that case, it’s better to roll back and let the users choose. You should make better use of beta community feedback with a much more frequent release and test schedule in smaller change increments.
@RitterIwan, in which file did you make that change and was it on 1 place only or several?
Fellow lurker here, who followed every post and patiently waited to upgrade the VeraPlus from 7.29 - today. It all went very quickly and smoothly, no new issues at all.
In addition to a Vera USB > GE/CADDX security system (using @FUTZLE’s plugin) I have a modest size network of 18 Zwave devices, with only a couple of other minor plugins and no scenes. Vera was quite stable for me before and I expect it to continue to be.
Looking forward, I am mainly concerned about the CADDX plugin and the Vera > pyvera/Home Assistant bridge if I am able to stay with VeraPlus as my device hub. Meanwhile, it’s great to see EZLo putting considerable effort in supporting and improving this venerable hub.
I KNOW I want this update but I’m also wary of it… I put in a support ticket two days ago via the link on my VeraPlus Controller and opened up the support hole. I have not heard back from Support yet but do want a head’s up before they start updating my system.
I’m especially concerned about Pool Control which is a custom plugin that only I and a few others use thanks to @rstrouse .
Please let me know the status of support. I’ll be patient though…
Were you able to resolve your Control4 integration issue? I’ve been toying with the idea of bridging my two systems together, hopefully this doesn’t kill that.
That sounds good. But I’m no programmer unfortunatly.
Is there an ‘easy’ way to walk me through this?
Where can I modify the Hue Plugin lua code?
It turned out to be a separate issue - though super coincidentally aligned with the Vera upgrade. IGMP stopped working on the VLAN and the Control4 was losing connection with its lighting controllers. Disabling IGMP snooping fixed the issue. (How IGMP snooping was enabled, I’ll never know.) I saw nothing in the 7.0.30/31 notes about IGMP or multicast changes in the Vera side, so I have to imagine it is just a coincidence. 7.0.31 working peachy with Control4 currently.
Mine is a Hub v2 running 1935144040 and was last updated on the 28th of Jan.
@Sorin I don’t like doing this (calling Someone out by name) but I’m going to because it’s frankly pathetic!
It took 5 days to get a response to my support ticket (214679) and when Estefanía Díaz finally replied, it was bloody obvious she didn’t read a single thing I wrote. FFS she even asked which device # I was referring to when I provided this info!
It’s also bloody obvious from the info I provided that I had tried multiple times to include/exclude the device I’m having issues with and yet she asks me to try it again.
To say I’m cross right now is an understatement!
This is not a one off unfortunately. I emailed them a few months ago with a support issue. The first question support asked was to turn on Remote Access for them. My first sentence and last sentence in my email was the access code. You are right some of the support staff do not read the support question.
@Sorin needs to weed these ppl out, they are not doing the right thing by Ezlo or their customers!
Still no return from support… What a headache