Author Topic: Securing and stabilizing the Vera by taking it off the grid  (Read 10776 times)

Offline Mike Yeager

  • Hero Member
  • *****
  • Posts: 582
  • Karma: +9/-12
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #75 on: June 23, 2018, 04:41:53 pm »
In the long run, I can see Vera no longer being part of my setup. I went over a week and then got a luup restart for no reason I can see. I have one device that sometimes loses sync between the Vera and Home Assistant. Working on that. The little Raspberry Pi computers are the I will not swear....

Offline jeubanks

  • Full Member
  • ***
  • Posts: 223
  • Karma: +11/-4
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #76 on: June 23, 2018, 05:36:35 pm »
In the long run, I can see Vera no longer being part of my setup. I went over a week and then got a luup restart for no reason I can see. I have one device that sometimes loses sync between the Vera and Home Assistant. Working on that. The little Raspberry Pi computers are the I will not swear....

One cool thing about Home Assistant and the rPI's is that the pi is cheap so you can buy more and offload things and use stream to keep the home assistant instances in sync through MQTT. 

HomeSeer has this built in using remote plugins.  You can run the plugins on a remote system, even a Pi and connect to the Master HS server

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1345
  • Karma: +67/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #77 on: June 24, 2018, 11:01:53 am »
I have now moved all the code I had which made use of the lua socket out of the vera as I found out the problem repeated again after a few hours: Found out the vera had done a spontaneous full reboot and upon recovery, disabled the lua socket. It means that I have no scene which communicates with the outside world. The vera only responds to API requests/polls.
What I am finding strange is that any type of reboot will not recover the vera which means that the blockage must be written somewhere that is not in the user_json.lua and persists after a full reboot and is a state that is likely purposely written in the code following some failed server connection attempt in spite of the vera knowing it has no internet connection. Why would you do this MCV developers?

As a reminder, if I give internet access to the vera and run a luup reload, I will recover all functionalities. I can then block the vera again and reboot at will without losing these functionalities until a spontaneous and unwanted luup reload or full vera reboot which I now believe is caused by the vera attempting to call home in an attempt to download files and sync apps I never installed and did not need to begin with. Again why would you allow such nasty behavior MCV?
openLuup (97 devices, 134 scenes, 20 apps) controlling HomeAss + VeraPlus (138 zwave nodes, 8 Zigbee nodes, 205 devices, 20 scenes , 2 app) Bridged to Homekit and Alexa. VeraPlus ExtRooted!

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1345
  • Karma: +67/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #78 on: June 24, 2018, 08:17:06 pm »
Few updates:

I have now migrated all possible logic to openLuup. Only remaining scenes are turn on and off scenes for lights triggered by scene controllers.

In the process of deleting scenes from the vera I noticed that intermittently the lua socket comes back to life as I have a notification set in my startup lua to notify me of luup reloads. The startup lua however seem to trigger with quite a bit of delay as if the vera was trying to reach the internet for some time and then load the startup lua and scnes only after that internet check times out. This could also explain why it sometimes won?t load at all if the whole process takes too long.

I have done everything I can to make the vera work. In this condition, it just did another spontaneous reload. It already has near nothing in it besides the zwave and zigbee devices...
openLuup (97 devices, 134 scenes, 20 apps) controlling HomeAss + VeraPlus (138 zwave nodes, 8 Zigbee nodes, 205 devices, 20 scenes , 2 app) Bridged to Homekit and Alexa. VeraPlus ExtRooted!

Offline therealdb

  • Full Member
  • ***
  • Posts: 171
  • Karma: +2/-0
  • Automate all the things!
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #79 on: June 26, 2018, 12:19:19 pm »
I'm about to move some logic to openluup as well.
In my quest to have a stable system, I managed to get incredible stability by not reloading neither rebooting anything.
I managed to get 5 days with no luup reloads.

I found that by not executing tasks from 2 to 4 am I got a very stable system.
That's probably because Vera is underpowered and incredibly not well engineered - albeit mono tasking.
I'm an engineer myself and I can see the smell of bad architecture...
Vera Edge EU, Fibaro FGRM 222 (12), Fibaro FGS 223 (20), Fibaro FGS 222 (5), Fibaro Universal Binary Sensor (2), Fibaro Plug (3), NeoCoolCam Door Sensor (3), NeoCoolCam PIR (2), Nest (3), Home Server running my own integrations, Harmony Hub, OpenSprinkler, Personal Weather Station, Sonoff TH & more

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 859
  • Karma: +63/-8
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #80 on: June 29, 2018, 08:28:35 pm »
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.

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1345
  • Karma: +67/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #81 on: June 29, 2018, 10:03:34 pm »
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.

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.
1. 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.
2. 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.
openLuup (97 devices, 134 scenes, 20 apps) controlling HomeAss + VeraPlus (138 zwave nodes, 8 Zigbee nodes, 205 devices, 20 scenes , 2 app) Bridged to Homekit and Alexa. VeraPlus ExtRooted!

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1345
  • Karma: +67/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #82 on: July 04, 2018, 04:09:05 pm »
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:
Code: [Select]
/etc/cmh-raand edit the cmh-ra.conf file and change the
Code: [Select]
RA_DISALLOWED=0from 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:

Code: [Select]
01 07/04/18 12:59:38.154 FileUtils::ReadURL 28/resp:0 user: pass: size 1 https://vera-us-oem-device12.mios.com/device/device/device/XXXXXX/localdevices response:  <0x75785867>
01 07/04/18 13:00:21.155 FileUtils::ReadURL 28/resp:0 user: pass: size 1 https://vera-us-oem-device12.mios.com/device/device/device/XXXXXX/localdevices response:  <0x75785867>

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.
« Last Edit: July 04, 2018, 05:36:51 pm by rafale77 »
openLuup (97 devices, 134 scenes, 20 apps) controlling HomeAss + VeraPlus (138 zwave nodes, 8 Zigbee nodes, 205 devices, 20 scenes , 2 app) Bridged to Homekit and Alexa. VeraPlus ExtRooted!

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1345
  • Karma: +67/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #83 on: July 05, 2018, 12:15:09 pm »
While the vera runs a lot smoother I have been digging into the logs and in the forum as I am still observing the following type of errors:

Code: [Select]
01 07/05/18 9:06:20.361 RAServerSync::SendAlert 0x17929f0 retries 4 failed  age: 35403 file: /etc/cmh/persist/a_1530806267_1530771377_13c2ca8 err: 8 sess:  serv: /vera-us-oem-event11.mios.com <0x769ae520>
01 07/05/18 9:07:20.128 RAServerSync::SendAlert 0x17929f0 retries 5 failed  age: 35463 file: /etc/cmh/persist/a_1530806267_1530771377_13c2ca8 err: 8 sess:  serv: /vera-us-oem-event12.mios.com <0x769ae520>

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.
« Last Edit: July 05, 2018, 02:49:43 pm by rafale77 »
openLuup (97 devices, 134 scenes, 20 apps) controlling HomeAss + VeraPlus (138 zwave nodes, 8 Zigbee nodes, 205 devices, 20 scenes , 2 app) Bridged to Homekit and Alexa. VeraPlus ExtRooted!

Offline therealdb

  • Full Member
  • ***
  • Posts: 171
  • Karma: +2/-0
  • Automate all the things!
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #84 on: July 10, 2018, 02:24:55 am »
Have you considered a small custom application on a local pi just to absorb the errors? It should be doable with low effort.
Vera Edge EU, Fibaro FGRM 222 (12), Fibaro FGS 223 (20), Fibaro FGS 222 (5), Fibaro Universal Binary Sensor (2), Fibaro Plug (3), NeoCoolCam Door Sensor (3), NeoCoolCam PIR (2), Nest (3), Home Server running my own integrations, Harmony Hub, OpenSprinkler, Personal Weather Station, Sonoff TH & more

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1345
  • Karma: +67/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #85 on: July 10, 2018, 09:29:37 am »
Have you considered a small custom application on a local pi just to absorb the errors? It should be doable with low effort.

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.
openLuup (97 devices, 134 scenes, 20 apps) controlling HomeAss + VeraPlus (138 zwave nodes, 8 Zigbee nodes, 205 devices, 20 scenes , 2 app) Bridged to Homekit and Alexa. VeraPlus ExtRooted!

Offline therealdb

  • Full Member
  • ***
  • Posts: 171
  • Karma: +2/-0
  • Automate all the things!
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #86 on: July 10, 2018, 11:38:43 am »
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 :)
Vera Edge EU, Fibaro FGRM 222 (12), Fibaro FGS 223 (20), Fibaro FGS 222 (5), Fibaro Universal Binary Sensor (2), Fibaro Plug (3), NeoCoolCam Door Sensor (3), NeoCoolCam PIR (2), Nest (3), Home Server running my own integrations, Harmony Hub, OpenSprinkler, Personal Weather Station, Sonoff TH & more

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1345
  • Karma: +67/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #87 on: July 12, 2018, 09:37:20 pm »
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.
openLuup (97 devices, 134 scenes, 20 apps) controlling HomeAss + VeraPlus (138 zwave nodes, 8 Zigbee nodes, 205 devices, 20 scenes , 2 app) Bridged to Homekit and Alexa. VeraPlus ExtRooted!

Offline akbooer

  • Master Member
  • *******
  • Posts: 6179
  • Karma: +276/-69
  • "Less is more"
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #88 on: July 13, 2018, 02:34:37 am »
...it needs to be a json server handling https and the 200 OK response apparently no longer works. It requires a key... this is way too much work.

Exactly.  That's rather why I gave up on it!
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1345
  • Karma: +67/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #89 on: July 13, 2018, 10:36:31 am »
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.
openLuup (97 devices, 134 scenes, 20 apps) controlling HomeAss + VeraPlus (138 zwave nodes, 8 Zigbee nodes, 205 devices, 20 scenes , 2 app) Bridged to Homekit and Alexa. VeraPlus ExtRooted!