Although I’m not managing to contribute original material here, I have three Vera systems… used to be four before a VeraLite went belly up.
One of these is a Vera Edge that I’m using for testing, currently 7.30. In my house, though, I’ve been through quite a number of evolutions, including X-10, Z-wave, and Zigbee. For some lighting and sensors, I’m moving towards Zigbee, partly because Vera has been so unreliable. Along the way, I’ve replaced quite a number of plugin wall sockets, Fibaro door sensors, and some unreliable multi sensors… all good candidates for testing.
I use my home as a test bench… for all of you guys.
And have additional units on the side to play around with and have a couple of extra devices which were cheap and I purchased as backup originally.
I have a Vera Edge with 4 Motion Sensors (Neo CoolCam), 2 Door Sensors (Fibaro), 5 Mains Plugs (Neo CoolCam), 1 Qubino light control and 1 other Light Control (don’t remember the brand).
Not a big installation, no big problems, only some of the plugs frequently come to offline. Reported to Neo support, not solved for the time being. Hope new upgrade 7.30 will reduce this problem.
BTW, I just upgraded to 7.30 without major problems. Only one of the plugs was offline, I have to exclude/include it and some of the motion sensors were "waiting for wakeup to…), just a touch on them and everything seems to work OK… My fingers are still crossed, of course.
I have a spare Vera edge and I will usually upgrade that first, then restore my backups to it and take the plus offline. If that works ok for a day or so I’ll upgrade my plus and switch back to it via a restore from backup.
This is why I got bitten by the 7.30 Charlie Foxtrot, my Edge has been completely fine through this and only my Plus has been impacted.
I decided to keep my Plus running my house after all the issues so I could help find them and help Vera fix them. So yeah, taking one for the team!
No, one of the cool things about Z-wave and the Vera implementation is you can backup and restore your Z-wave network to a totally Vera different controller and everything keeps on working.
This is one of the strengths of Z-Wave and Vera. If your main controller hardware dies, simply restore a full backup from the main to another controller. At that point, the secondary becomes the main and everything works. The Z-Wave network is not the immediate problem if both controllers are powered up. The “new” controller will have the same network config as the old and you may end up with duplicate IP addresses if you have a static IP configured, which can cause more immediate problems.
My secondary controller is normally used for testing new devices, plug-ins and firmware without jeopardizing the primary controller, but is always available to replace the main if it fails. I also have an Atom from the beta program which controls two plug-in modules and an Edge running 7.30, paired with one dimmer, while I wait for the devs to add web access to the new Linux firmware.
S2, while theoretically increasing security, does remove this valuable feature as @rafale77 indicates. That’s a serious problem for me. I travel a great deal for work, and my configuration allows me to remotely restore a backup and swap out controllers (including remotely controlling power to each Vera individually) thus insuring that the family isn’t literally left in the dark if the primary controller fails.
After over 2 months of running with the disabling of wakeup arr/nnu and nearly 2 months of extending wakeup intervals, I wanted to list out all the problems it solved so that people car refer to it if they encounter these:
The obvious is the extended battery life especially on FLiRs like the zwave locks which used to burn out my lithium battery within 1-2 months. Now after two months without changing the batteries, they are all still showing 100% and are still running strong. Likewise my econet vent for which I had to recharge the batteries about every 6 weeks are at the very least extending their battery life by 3x from the current battery level reading. It is also too soon to assess the battery life on all my sensors but I get the feeling they may multiply even more.
My Aeon HEM which often used to stop updating data from one of the two child devices at least once every two weeks… completely stopped doing so.
I have a handful of Leviton 4 button scene and zone controllers with an embedded relay which would lose its association about once every two months, requiring a power cycle to recover. This is completely eliminated.
The frequency at which I get delayed scene or even simple command execution dramatically decreased… by at least 10X. I rarely encounter issues like these any more.
Luup reload but you already knew that.
Random can’t detect devices… Completely eliminated.
Frequency of missed sensor trips and untrip dramatically decreased. It still very occasionally misses untrips which I identified in the logs as associated with a “got CAN” and tardy event and sometimes wake-up polls.
Strangely high probability of secure key exchange failure during secure device inclusions. Eliminated.
Please post your observations here and I will put them up on one of the top 4 posts.
As a newbie to Vera, can I embed the Lua code in a scene (added in the section “execute the following Luup code:”) and then run it from there?
For example, create a set of “system admin” scenes that are manually triggered and have no device actions other than executing the Luup code. The two scenes from this thread would be:
1 - a scene that disable the nightly network heal
2 - another scene that disables polling of battery devices.
That way I don’t have to go back and find the Lua code in these posts and can more easily run the scene after future FW upgrades or after adding a new battery powered device.
