Long story short there are three areas of weakness:
Memory both DRAM and NAND flash. DRAM is you have a lot of plugins → use openluup
NAND flash… bad partitioning → extroot
mios server stability → Take it off the server and mod the vera scripts to disable all the various tunnels and services which depend on the servers
network/internet monitor. Related but not quite to 2. I disabled the network monitor which serves to reload luup whenever the network interface drops which is completely unnecessary with the version of openWRT it is currently running. I believe this is a legacy program.
All of these made huge improvements to my system. I am not seeing devices stop working or dropping off my network. I now have two very solid networks: Zigbee and ZWave. I believe a lot of the stop working are due to unwanted luup reloads which is vera’s automated response to almost anything. It breaks more things than it fixes and must be prevented at all cost and this is valid for the full power cycle as well to a lesser extent. It can cause a number of data corruption. Now back on your device issues… they maybe zwave network issues, device issues or vera corruption related… On the network side, I found that vera on a large network polls way too often and unnecessarily for the network’s health and I have also completely disabled auto polling. I am also using USB sticks for both zwave and zigbee seeing that the antenna on the vera is extremely weak.
Cross posting from another thread here to answer a question I got also from in a few PMs as it was getting off topic.
It will be for me a slow step by step process because the vera has become more stable over the past year with 7.30 and 7.31. If this wasn’t the case, I think I would have migrated sooner. I do not intend to migrate the whole system. Only the part which is problematic which is the vera. I have neutered the vera so much that it is only a zwave+zigbee to IP controller for openluup. It appears to me that only the zwave portion is flawed.
For Z-wave the choices I have been considering are Homeseer and Z-way. There is also hubitat and all the openzwave based controlllers (HA, OpenHab, Domoticz) but they do not support S2 security. If I am going to make spend the time and energy, I might as well get something extra for it right? @akbooer has a “test” version of a bridge to Z-way which I have been playing with and I am pretty close. Creating a Homeseer bridge is also a possibility but I still dislike the VB, Windows base core. I have a free version I could use but I am taking the z-way shortcut for now.
If this is succesful, I am likely then going to move the handful of zigbee devices to HA and bridge them in through @rigpapa’s sitesensor and get rid of the vera completely.
Yes, I have been exchanging with AK over the past few days and suggested some fixes for a few devices not being ported correctly. My zway is on the same network as the vera so openluup now sees everything double. . I think I am close. Maybe another couple of weeks to get me even more comfortable with zway and I will start migrating by swapping the controller ids.
Is this how you plan to migrate your devices to a new ZWave controller? I too feel the gravitational pull from Vera’s traditional controller to their new cloud-based platform. As such, I’ve been hunting for a new place to lay my head. It saddens me but I feel like we’re being left behind a bit.
Two things are holding me back:
My never-ending trust/faith in humans/companies. They won’t REALLY do that (desert us), will they? (wink)
Over 100+ Zwave devices that I would have to exclude/include and migrate logic. (not to mention MySensors, and other integrations)
Just curious if there’s a more elegant solution to move ZWave devices…
That’s the beauty of zwave. It actually gives me goose bumps when I hear people taking the route of excluding/including when they have a device problem. It often is not helpful and lays in the same tone of “I don’t know what is going on, let’s just start from scratch” mentality similar to the abusive luup reload plaguing the vera. No I have no intention of migrating by excluding/including.
Zwave networks have the advantage over zigbee to be able to have multiple controllers. You can read up on it. I posted about this also elsewhere on this forum. I technically had up to 5 controllers on my network at one point testing simultaneously HA, vera, Hubitat, z-way and homeseer. You should be able to have one true primary with all others being secondary. For me swapping the controller ID is for those devices which only accept 1 controller in their lifeline association group and I have quite a few. It means that these devices either do not report instant status or wakeup or send their mainstream data to more than one controller and often that controller ID needs to be node 1. Newer devices allow for multiple lifeline controller association. You can also backup your zwave dongle and copy it over to another dongle. I even tested having two controllers with the same node id 1 (this makes a mess don’t do it).
So yeah I plan on cloning my vera zwave dongle onto my z-way dongle and vice versa… That would be the end of my migration. I had initially cloned the internal zwave data from my vera to a USB stick… so I am actually already running the vera on a USB dongle but short of doing that, one could play musical chair by shifting and excluding controllers alternatively until reaching the node id 1 for the dongle you want and then set that dongle to be SUC/SIS or true primary.
I run homeseer on linux and its solid. There are some 3rd party plugins that don’t work but nothing I have really missed from windows, other than fully local voice recognition. And maybe being able to run blue iris on the same box when I pull the trigger on more than on IP cam.
I find the plugin cost to be overblown/ overwrought. There are plenty of free plugins and unless you just like having a painfully heterogeneous system, most users only need a few plugins. I run half as many plugins on HS as I did on vera because the core platform is better.
I do think with the pi4 that they need to loosen the plugin restriction on HSpi (and I live under that threshold even thoug my system supports nigh unlimited plugins). And hopefully the HS4 zigbee support is better than ezlo/veras but I dont think that module is out until summer.
Note that I don’t care for plugins since I am only looking for a zwave controller with an external API.
So far just looking at the engine itself the pros and cons between zway and homeseer are:
HomeSeer has a better forum and better support. It has arguably slightly better device support and development. I ran it on the pi and it was free so cost is not an issue. It can run on any hardware. I do not like its UI.
zway has its software licence in the uzb key which means you cannot use any hardware. The uzb is cheap enough but this far the firmware upgrade has been painful. The expert UI is very intuitive and is conducive to very good understanding of the zwave network. Above it all, it already has a bridge for openluup making migration much easier. For my application though, it comes out to be more expensive than HomeSeer due to the cost of the license.
If I am not fully satisfied with Z-Way, I will definitely consider putting together a HomeSeer bridge.
So far with zway, I have found 3 device functions I would lose vs the vera:
My Leviton 4 button scene controllers lose the ability to change their LED colors. I use this as a visual house mode indicator…
I cannot reset the HEM counter through the bridge. The function in zway is available from the expert level API but not from the virtual device level which the bridge uses.
Maybe an artifact of me not having switched the controller ids yet but I cannot complete the interview of my thermostat so I am missing the fan control and the mode control is only partial. Oddly I can control all these from the expert level. Not at the virtual device level… So maybe it will be a limitation of dealing with the higher level API.
I may be wrong, but it should not be too difficult to use the ‘expert’ API for controlling specific ZWay devices. The complexity mostly arises from the device status and configuration side of the interface.
If you can find an HTTP request that the advanced interfaces uses, then the plugin should be able to use it.
Use your browser developer tools to look at the traffic generated by the advanced interface when you use that to do the action. I’m slowly working through the advanced API docs and trying to reconcile what it does with the way that the virtual device interface presents things. Nightmare.
I think I will do the jump too. The easy way should be to install a new little box with Zway, put this controller into the “same” zwave network as vera and all my device should appear in zway and still have vera working properly ?
I was suspecting something like that. I will try this when I get home. Thank you!
In short yes. Put the vera in inclusion mode and the zway controller in learn mode. The zway will get itself added to the network and will acquire the security key from the vera (secure key exchange). It took me a couple of trial and error to get the security key to exchange properly but this was back when the vera was very chatty with insane overhead. This should enable your zway to control all you devices but not all sensors will report back to zway yet. You can then run the equivalent to the vera configuration by interviewing all the nodes.
As I said some devices will not like accept more than 1 lifeline associations and some nodes will not like having anything but node 1 as its lifeline associations. This will depend on your devices and if you have devices like these, you will have to swap node ids between your controllers. I have done this a few times in the past…
I bought two Veras. I paid for vera plugins. Not sure why I wouldn’t pay for Homeseer. Having said that, I have several free HS plugins from non HS devs. Last time I checked, there were 75+ free plugins. It’s up to devs to charge or not. If most HS plugins have a cost, I guess those devs want to code for a living.
Mine runs for months on end without issue so if it has a memory leak, it’s a darned slow one. I haven’t topped 6 months of run time yet but the power outage outlasted my UPS so we’ll see how it goes this year.
Age of a code base doesn’t bother me. Having 20 years of experience is a nice thing. And they have experience manufacturing a host of zwave devices as well as making controllers, which gives them insights. Not to mention a solid revenue stream outside their controller.
I’d like vera/ezlo to get to the point HS is at, with a varied product line that hits a lot of the market. Competition is good. I look at the light switches that come from zooz, innovelli and homeseer and want that kind of variety in the controller space. Hubitat is probably putting some leverage on HS. Sadly, more than vera is right now.
I don’t have an issue with hass.io or hass-core or whatever it got renamed to last month, I just don’t have the time to spend on fighting with yaml or whatever. I spent that energy during the ipchains/iptables, perl/python/php eras of linux. Now I will spend a modicum of money to save that time and energy for other things. Not Control4/Savante money, but still, money. I used to spend that money on vera until the “dark times” drove me away.
For those of us who just want it work out of the box, hass.io ain’t ever going to be the option we choose. I avoided hubitat because their cpu is dinky and I knew it would have performance problems at scale and that’s what’s happening now. Isy is in need of a total platform refresh, even if their core real-time OS is rock solid. These days you need the option of the cloud even if you dont want to depend on the cloud, and adding a polyglot server sounds awfully close to yaml files. So…Homeseer.
Let’s see if EzLo can get back in the market with a good product and win back some mind share.
Not a huge fan of HomeSeer myself, but let’s face it, it works and as I said is one of the only two local processing solutions available with the more advanced features. All of the open source versions are based on openzwave which I have tinkered with as well but is still a bit too cumbersome to setup and does not support S2 and Smartstart besides a much more complete control over command class frames with a friendly interface. I am a big proponent of opensource myself and use Home Assistant pretty extensively. Just not for zwave and for automation because… yeah I don’t love yaml. So for me it is either zway or HomeSeer bridged into openluup.
And if you don’t think S2 matters, look at all the thread about new devices failing configuration, and association in the past 2 days alone… These devices all support S2.
And shall I add, I am very much saddened as well as disappointed that vera couldn’t cut it. It had so much potential but at the end I feel that the lack of discipline and consistency along with a poor design in the software made it unscalable. There are so many good ideas and so many things well done on the UI. It just was not released, tested properly and above all was never designed to be able to handle more than a handful of devices and even so, not reliably enough to be in home security.
Not quite sure what you’re meaning here? There’ve been lots of times in the past that people have asked for this sort of list (on a ‘normal’ Vera) with solutions provided (sometimes by me!)
Examples here:
Is this a question about something different, or am I missing something?
As noted in one of the posts above, AltUI has the Table Devices page with an option to include ALTID. Also, the openLuup Console has also has a similar page, and I could easily add ALTID to that too.
. I think I am close. Maybe another couple of weeks to get me even more comfortable with zway and I will start migrating by swapping the controller ids.