Moved virtually everything to openLuup and it works extremely well. The Vera 3 is now pretty much just a z-wave radio. Every scene in Vera just calls a scene on openLuup and openLuup does the work. There is no code in any of the Vera scenes, except to call consolidated code (that calls openLuup), that is put in place during the luup engine restart. I don’t use battery operated z-wave devices, excepting minimotes, which are scene controllers.
The end of the month is imminent and that’s the only time I see a luup engine restart ie it does it at the end of every month; not sure if it’s GMT or local time. Keep an eye out and see if you can catch it. Would like to know if it’s built into the firmware (likely) or initiated remotely.
[quote=“a-lurker, post:81, topic:199140”]Moved virtually everything to openLuup and it works extremely well. The Vera 3 is now pretty much just a z-wave radio. Every scene in Vera just calls a scene on openLuup and openLuup does the work. There is no code in any of the Vera scenes, except to call consolidated code (that calls openLuup), that is put in place during the luup engine restart. I don’t use battery operated z-wave devices, excepting minimotes, which are scene controllers.
The end of the month is imminent and that’s the only time I see a luup engine restart ie it does it at the end of every month; not sure if it’s GMT or local time. Keep an eye out and see if you can catch it. Would like to know if it’s built into the firmware (likely) or initiated remotely.[/quote]
You are lucky to be able to run UI5… I now have a z-way server up and running on a my pine64 but unfortunately it seems like my forgotten zwave stick is not compatible with it. I have not yet completely decided which way to go to replace the vera but it will definitely on the pine 64.
Home Assistant with Zigbee/Zwave combo stick which I think would be more responsive but would be a lot of of work since there is no plugin on openLuup.
Z-way with with UZB1 and Zigate, both of which have openLuup plugins which rely on polling the remote radio controller much like the vera.
I will test the latter first. Working with the vera has been much too frustrating and time consuming over the years.
I was looking through vera logs and found out that in spite of the vera reporting no internet connections and not connected to any account as I removed my vera from my account, it is constantly trying to reach the mios event logger. There is an RAserversync failure flooding the logs and upon digging around and trying to stop the init.d RAsync service, I found that I could stop this by going into:
/etc/cmh-ra
and edit the cmh-ra.conf file and change the
RA_DISALLOWED=0
from 0 to 1
After doing this, my UI7 has become disturbingly faster
Next event I am seeing reaching out to the mios server is this one:
The vera seems to have quite a few of these embedded calls which need to be disabled to make it stable when offline but the RAserversync was the most frequent.
Edit: This RAserversync might be my discovery of the year on the vera: I no longer see the beachball when I open my device page and scroll down the page. The pages load instantly. The lag and slowness on the zwave side seems to have also disappeared. It may also be the cause of overloading of the vera and all the spontaneous luup reloads. I will report back. It is funny I am finding this the day before I am getting my UZB1 stick to startup my z-way server to replace the vera but ohh well…
Edit2: So the description people have made of Homeseer speed, I am seeing it now. I had alexa open 5 shades at the same time which used to start only acting some time after Alexa said “ok” and would be completely out of sync now they practically start at the same time and before Alexa can respond. I am so not used to it that it startles me.
While the RA tunnel is dead and every single event creates a file in the /etc/cmh/persist/ folder and the vera is still attempting to send these events to the event server.
The event in question actually also shows up on the GUI “task” line which displays
“##device name## Device changed state - waiting to upload”
I was wondering what this meant before. It is pretty clear now but I don’t know how to stop the RAserversync. I already deleted the content of the persist folder but every new event creates a new file which the vera wants to “sync”.
Edit:
I found a potential solution/work around to this problem: I installed Vera Alert so it can act as a secondary event server the vera can sync with so it clears the persist folder and doesn’t accumulate. Since I have the vera firewalled the vera alert plugin is technically not doing anything besides clearing the event/alerts which accumulate on the vera.
Key question is whether responding to the alteventserver instead of the primary server is sufficient, and what the response from the server should be. It is a good idea though, I will give it a try.
If you just “fake” the original DNS entry and map it to your local web server, it should be easy and no alternate server could be required at all.
I think they just check for a “200 OK” response, but you can double check it with a proxy running on your box, to inspect the kind of requests that are made to the remote server.
I agree that it seems to be a lot of effort for a thing that should be doable in the firmware, but it’s not impossible at all to fool a web request
Tried this. I was able to redirect to the default server but it needs to be a json server handling https and the 200 OK response apparently no longer works. It requires a key. I have not setup a proxy to inspect the calls but this is way too much work. I have asked CC this time to see if they can disable it.
In order for support to look at disabling the Raserversync functionality, I reconnected my vera and I observed a significant increase in lag of zwave sensor reports and zwave commands executions (sometimes up to 1min). At this point you can’t win: Either live with regular engine crashes due to luup reloads or live with an overwhelmed vera excessively communicating with the mios servers. I just hope CC will be able to disable this server sync.
So sorry to hear that.
Last year I had to deal with a major internet fault and I had to buy a 4G modem just to let the Vera stay up.
I also wish they spend more time in the core (stability, drivers) and less in bell and whistles…
So… After concluding with CC (grateful for the help by the way and the efforts going all the way to the dev team) that the RAServerSync function is hard coded deep into the vera engine, I went on to learn a little more about the intricacies of zwave to see if it would be wise for me to gradually migrate my entire zwave network to either Home Assistant with the HUBZB stick or Zway with a UZB.
I dug out an old mini PC running on a 4W Celeron N2807 I had shelved a long time ago and started building a device bridge running both Zway and HomeAssistant on Ubuntu 64bit. I started playing around with a dummy test zwave network. Threw in a vera edge in it as well to test controller shifts from UI7 etc… Well I decided to add both to my production setup and see how they fare after getting more comfortable with zwave.
After adding the second controller (Zway), I realized the vera had lost it’s zigbee network. Recovering from backup did not help and I ended up having to downgrade the firmware to 7.0.26 and recover from the same backup. This time it worked. I have also shifted the primary controller from the vera to Zway along with the SUC/SIS roles so the vera is now completely a secondary. The vera has definitely been running on eggshells and have data corruption at any time. I have multiple evidences of devices disappearing from the UI and reappearing because it is still in the zwave network, with a new ID and requiring reconfiguration, suddenly having a different wakeup frequency and therefore causing them to go “not detected”. A quick backup reload took care of it but gosh… what a finicky piece of software.
Zway sees all the devices but I will need quite some time to configure all 130+ nodes into devices I can then move into openLuup. In the meantime the vera is not affected.
Decided to use openZwave to add the zwave radio of my HUZBZ to my network as well. (I am also testing the Zigbee part of the stick and it works quite well). Now the shock: I can’t figure out how this was done but a large number of my devices are starting to show up with their Vera names on Home Assistant. It appears that the device names on the vera are somehow communicated to Home Assistant through Zwave. This is brilliant! Locks, Vents (show up as dimmable lights), switches and most sensors are configured correctly. Now only if there was a Hass plugin on openLuup…
So after playing with controller shifts moving the primary around on my network I now have only 1 primary: The HUBZB (the combo stick which has Zigbee and Zwave) running on Homeassistant (based on openzwave for zwave and bellows for zigbee). I have also enabled SIS functionality on the HUBZB. I now have 3 fully functional hubs on the zwave network.
I ran a few tests and learned a few new things which I am sure one could find through some research but I thought I would report here anyway.
I still have not figured out how to move the secure key around from one controller to another so that they can all control the locks, garage doors etc… Luckily I do not have a ton of secure devices (Maybe 20 out of 135) so I could just reset and pair them at the time of migration.
A number of sensors when the associations are set properly can actually update status on multiple hubs however others only can accept 1 and some even need the hub to be on device id “1”. This means that if I really want to migrate completely without resetting and redoing my network I will have play dominos to make whichever main controller I want to use to be id “1” and would save me all the time with redoing associations. The vera does not make this easy as it increments device id number from the last paired device instead of going for the lowest available number like the other 2 controllers do. Luckily I only need 2 controllers to get this done and I have 3.
Zway offers a lot more control and understanding over the entire zwave network and I now feel I was blind using the vera. The latency the vera has are due to its radio being backed up with commands being queued and a large network definitely makes it worse because of the polling frequency Vera uses by default which is higher than the others.
I tried the “RA_DISALLOWED=1” in cmh-ra.conf but if I reboot Vera it goes back to “=0”. I could re-write the file with every reboot, but I’m not sure it will be effective after boot. Anyone else have this problem? I’m doing it on VeraSecure (what a joke for a name, “Secure” myA&*&).
[quote=“ZW-Tom, post:95, topic:199140”]I tried the “RA_DISALLOWED=1” in cmh-ra.conf but if I reboot Vera it goes back to “=0”. I could re-write the file with every reboot, but I’m not sure it will be effective after boot. Anyone else have this problem? I’m doing it on VeraSecure (what a joke for a name, “Secure” myA&*&).
Tom[/quote]
Yeah I am with you. I had the same problem and ended up editing the cmh_ra in the /cmh/init.d folder to make it “exit” from the beginning so that even if the script starts, it ends right away without starting the tunnel.
[quote=“rafale77, post:96, topic:199140”][quote=“ZW-Tom, post:95, topic:199140”]I tried the “RA_DISALLOWED=1” in cmh-ra.conf but if I reboot Vera it goes back to “=0”. I could re-write the file with every reboot, but I’m not sure it will be effective after boot. Anyone else have this problem? I’m doing it on VeraSecure (what a joke for a name, “Secure” myA&*&).
Tom[/quote]
Yeah I am with you. I had the same problem and ended up editing the cmh_ra in the /cmh/init.d folder to make it “exit” from the beginning so that even if the script starts, it ends right away without starting the tunnel.[/quote]
I added the following to the Startup Lua and it works:
os.execute(“sed -i ‘s/RA_DISALLOWED=0/RA_DISALLOWED=1/’ /etc/cmh-ra/cmh-ra.conf”)
End of the month last night - here are the monthly restart messages for my two Veras. Presume this is built into the firmware (seems most likely). Does not having a net connection at this time cause problems?
There is a monthly luup restart? I had no idea! I guess I had so many mysterious restart before that it was the least of my concerns. If you don’t have any cloud related plugins, the restart don’t need net access. What requires access to the vera server are “events”. “alarms”, “device no longer detected”, “device detected again” etc…
Sure enough I too got a Luup reload on Sept 1 00:00… Took 35s to complete so I have a notification recorded at 00:00:35. so much for my reliability test.
