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

Offline Don Phillips

  • Hero Member
  • *****
  • Posts: 1323
  • Karma: +35/-32
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #30 on: June 04, 2018, 08:39:12 pm »
Wireless locks scare the heck out of me, and not just because Vera might hiccup and unlock all the doors. There are too many ways they can be compromised, and the latest security flaw in Z-Wave means all these locks could be compromised. I did automate the garage door when I first started with Vera four years ago. It seemed cool to be able to operate the door remotely, until the door opened all by itself for no apparent reason. I removed the control, but still have the door position sensor so I can check it remotely.

I use PLEG to start a 10 minute timer for the garage overhead door and a 1 minute timer for the front door. If the garage overhead door is open for 10 minutes, I get a reminder every 10 minutes the door is still open. Similarly, the front door will send me a message every minute.

With PLEG I have not experienced as many failures during a LUUP reload, however, they tend to happen about once a week. This morning, at 5:30 am, I had a LUUP restart, after my bedroom fan was turned off and my wife's nightstand light turned to 15% but before the night stand could ramp up to 100% and House Mode changed from Night to Home. So after my shower and getting dressed, I enter the living room and I am getting motion notifications on my phone. Sure enough, still on Night Mode.

Annoying but not catastrophic.
Vera 3, 1.7.1030, CT101, Everspring motion sensor, GE/Jasco switch, Leviton outlet, AeonLabs sensor, NuTone garage door, Blue Iris, Sricam SP011, iPhone locator, APCUPSD, VeraMate, VeraAlerts, PLEG, House Modes, Countdown Timer, DVR, Virtual/Multi Switch, Weatherunderground, LB60Z-1 bulb, Hue, Alexa

Offline HSD99

  • Sr. Member
  • ****
  • Posts: 282
  • Karma: +11/-0
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #31 on: June 04, 2018, 10:24:12 pm »
Annoying but not catastrophic.
I think everyone who goes down the HA path needs to make their own risk assessment when automating a task. "Annoying but not catastrophic" is a pretty good benchmark.

I actually added a fail-safe to the garage door so it could be opened remotely in an emergency. The output from the Z-Wave pulse relay goes through a series of relays that are controlled by a LAN-based system that is not connected to Vera and has no automation capabilities. The four series relays must all be set to the correct state to pass the pulse relay signal on to the garage door opener. The relays can be programed for an "ON" time, then they reset. You set the four relays to the correct state (kind of a hex lock code) and have 2 minutes to have Vera send a door command. I also set up alerts similar to yours when the door is open.

Probably overkill, but I had the relay system in the parts bin. ;D

Offline Tillsy

  • Full Member
  • ***
  • Posts: 207
  • Karma: +12/-4
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #32 on: June 04, 2018, 10:40:44 pm »
With PLEG I have not experienced as many failures during a LUUP reload, however, they tend to happen about once a week. This morning, at 5:30 am, I had a LUUP restart, after my bedroom fan was turned off and my wife's nightstand light turned to 15% but before the night stand could ramp up to 100% and House Mode changed from Night to Home. So after my shower and getting dressed, I enter the living room and I am getting motion notifications on my phone. Sure enough, still on Night Mode.

Annoying but not catastrophic.
Agree not catastrophic, lives and safety are not at risk, but it is an immense failure - that things can and do randomly fail leaving your home in an unpredictable, frustrating, and potentially unprotected state.

As someone who has had a setup that has been suffering an extreme number of such failures, I have accelerated the window of time my wife has taken to become fed up.  Having things half happen, not happen, or even happen when they shouldn't has driven her up the wall.

So while not catastrophic, over time it really does become unacceptable.  Lights left on, windows or doors left open, things left in night mode, security potentially not armed, things staying dim when they need to be bright, etc won't put lives at risk but they'll drive your family insane.

Personally I'm at a point where I am having to be very careful and thorough with my next step, as I've pushed my wife so far my next step needs to either work or I simply give up and rip everything out.  Given all my problems have simply been with Vera being insanely under resourced and bug ridden, rather than being a design flaw with Z-Wave itself (security concerns aside), I am confident I can nip this... but I am equally confident there is no way Vera is capable of achieving that.

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1246
  • Karma: +62/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #33 on: June 05, 2018, 12:16:10 am »
One more step taken today: I have now removed my mobile apps and I am considering removing my production vera from my vera account next since they are no longer talking anyway but am hesitating because some of the settings still require to connect to the server and login which I am finding absurd but is explained by the vera?s lack of local security...
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 HSD99

  • Sr. Member
  • ****
  • Posts: 282
  • Karma: +11/-0
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #34 on: June 05, 2018, 10:21:31 am »
One more step taken today: I have now removed my mobile apps and I am considering removing my production vera from my vera account next since they are no longer talking anyway but am hesitating because some of the settings still require to connect to the server and login which I am finding absurd but is explained by the vera?s lack of local security...
Good luck with this---I wonder if you'll be able to remove your production Vera without it being online? Or, if you have to be online to remove it, will the Vera servers send something to the unit that will cause you problems? 

Offline HSD99

  • Sr. Member
  • ****
  • Posts: 282
  • Karma: +11/-0
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #35 on: June 05, 2018, 10:52:06 am »
I treat these random Luup reloads as if they were system crash and they really are since they can have dreadful consequences... As some other forum members have experienced, it can destroy your house if one is not careful: If the vera is controlling irrigation or HVAC or even security devices. I have experienced flooding of my yard because the vera rebooted while in the middle of a scene. Imagine your locks forgetting to lock etc... These must be taken seriously. I have written code now in my startup lua to prevent many of the catastrophes but one can't use the vera beyond lighting if it is as unreliable as it is. (the worst you would get is coming to the house lighting up like a Christmas tree out of control). I have now removed all the files associated with the rogue vera apps and the unit seems to still be fine.
I am now also suspecting than there is correlation on one of my sensors having false trips and its battery status changing so it seems that using NiMH rechargeable batteries (low voltage) making it report 1% even when full addresses the problem since it never changes battery level.
This is a question about the report generated by System Monitor:

Last CMH Reboot 08:47:46 Wed 14 Feb 2018
Last Vera Restart 19:31:15 Wed 16 May 2018
Last Luup Restart 01:00:55 Tue 05 Jun 2018

I know that Last Vera Restart indicates a soft reboot---you'll see this entry after sending a reboot command from the UI. I'm not sure what Last CMH Reboot indicates---is this a power-cycle boot?

I'm now running SysMon on both the production and test system, and I see a Last Luup Restart every morning at 1:01 AM on both systems. This is when the Linux server finishes the Z-Wave/config backup script. I just noticed this today, and the logs have rotated out so I can't see what happened. I can test this by forcing the backup script to run, but have some other tests running so I won't get to it for a few days. I notice that a "Reload Engine" command is a complete forced shutdown and restart of Luup by looking at the logs, and is indicated in SysMon's "Last Luup Restart" report. I'm not sure why Vera needs to do this after creating a backup.

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1246
  • Karma: +62/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #36 on: June 06, 2018, 12:47:48 am »
Will try to answer your questions:

1. I do not get a Luup reload after my backup script. Proof is I go much more than 24hr between reloads and I am backing up every 24 hrs. There must be something going on in your system causing this.
2. My understanding of the 3 categories of reload:
CMH Reload is when the reload is triggered through the mcv server.
The Vera restart is a full restart of the OS
Luup reload is a restart of the Luup engine only.
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: 1246
  • Karma: +62/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #37 on: June 06, 2018, 12:49:34 am »
One more step taken today: I have now removed my mobile apps and I am considering removing my production vera from my vera account next since they are no longer talking anyway but am hesitating because some of the settings still require to connect to the server and login which I am finding absurd but is explained by the vera?s lack of local security...
Good luck with this---I wonder if you'll be able to remove your production Vera without it being online? Or, if you have to be online to remove it, will the Vera servers send something to the unit that will cause you problems?

Yes you can remove a vera from your account without it being online. I have done it on my test unit. The worry if it is online when you do it is that it may do a factory reset on your vera...
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 Don Phillips

  • Hero Member
  • *****
  • Posts: 1323
  • Karma: +35/-32
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #38 on: June 06, 2018, 09:03:40 pm »
CMH Reload is when the reload is triggered through the mcv server.

That explains why I may go months between CMH reloads even if I do a factory reset, firmware update, and restore from backup.
Vera 3, 1.7.1030, CT101, Everspring motion sensor, GE/Jasco switch, Leviton outlet, AeonLabs sensor, NuTone garage door, Blue Iris, Sricam SP011, iPhone locator, APCUPSD, VeraMate, VeraAlerts, PLEG, House Modes, Countdown Timer, DVR, Virtual/Multi Switch, Weatherunderground, LB60Z-1 bulb, Hue, Alexa

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1246
  • Karma: +62/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #39 on: June 07, 2018, 11:38:05 pm »
Played some more with the vera being blocked from the internet and here are some observations:

1. With the vera setup with local NTP, When the vera has no internet access, it actually reports the last vera restart correctly by getting time from the local NTP server. When it has internet access then during the OS boot process, it will report Jan1 00:00 2000 UTC as the last reboot time. This is quite interesting. It means that it is not actually using the NTP settings and must be updating the OS time from somewhere else.

2. With the files for the Sercomm camera plugin and Alexa removed the vera seems to go nuts after a few minutes and will no longer run any lua code. The Zwave driver and the UI still work but test lua and scenes / startup lua will stop working after a few minutes. I could not reboot, reload luup or do anything from the advanced menus and had to go unplug the vera to get it to reboot. Not sure why MCV wants us to keep these 2 plugins so desperately. I will just let it be but it remains a mystery. The vera would sometimes go into an infinite luup reload loops or would load correctly and then lose it completely after sometime and go into a full reboot. I don't understand how the reboot behavior could be so random and inconsistent with 3 different hard reboot leading to 3 different behaviors.

3. The weather logo at the top right is actually obtained from yahoo.com. I noticed it from my dns server logs.

Overall for those who think the vera can work without internet, it really cannot. The core engine is much too unstable and luup reloads constantly leads to the vera looking for something from their server or elsewhere on the net. It is taking me a lot of work to figure out what these items are and I wish vera was more transparent about them.
« Last Edit: June 07, 2018, 11:47:44 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 HSD99

  • Sr. Member
  • ****
  • Posts: 282
  • Karma: +11/-0
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #40 on: June 08, 2018, 11:34:08 pm »
Will try to answer your questions:

1. I do not get a Luup reload after my backup script. Proof is I go much more than 24hr between reloads and I am backing up every 24 hrs. There must be something going on in your system causing this.
2. My understanding of the 3 categories of reload:
CMH Reload is when the reload is triggered through the mcv server.
The Vera restart is a full restart of the OS
Luup reload is a restart of the Luup engine only.
Thank you. I'll look into why I get a LUUP restart after the backup. And thanks for the info on CMH Reload---that was the one I really couldn't figure out. Is this something that Vera might do when CS works on a unit, or do they reach out and do this at other times?
The full restart of the LUUP engine seems unnecessary, as it's easy to simply re-read the config files when something changes. It may be that Vera doesn't have enough confidence in their software and figure that a full restart is required to make sure everything gets properly initialized.

Offline HSD99

  • Sr. Member
  • ****
  • Posts: 282
  • Karma: +11/-0
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #41 on: June 08, 2018, 11:40:34 pm »
Played some more with the vera being blocked from the internet and here are some observations:

1. With the vera setup with local NTP, When the vera has no internet access, it actually reports the last vera restart correctly by getting time from the local NTP server. When it has internet access then during the OS boot process, it will report Jan1 00:00 2000 UTC as the last reboot time. This is quite interesting. It means that it is not actually using the NTP settings and must be updating the OS time from somewhere else.

2. With the files for the Sercomm camera plugin and Alexa removed the vera seems to go nuts after a few minutes and will no longer run any lua code. The Zwave driver and the UI still work but test lua and scenes / startup lua will stop working after a few minutes. I could not reboot, reload luup or do anything from the advanced menus and had to go unplug the vera to get it to reboot. Not sure why MCV wants us to keep these 2 plugins so desperately. I will just let it be but it remains a mystery. The vera would sometimes go into an infinite luup reload loops or would load correctly and then lose it completely after sometime and go into a full reboot. I don't understand how the reboot behavior could be so random and inconsistent with 3 different hard reboot leading to 3 different behaviors.

3. The weather logo at the top right is actually obtained from yahoo.com. I noticed it from my dns server logs.

Overall for those who think the vera can work without internet, it really cannot. The core engine is much too unstable and luup reloads constantly leads to the vera looking for something from their server or elsewhere on the net. It is taking me a lot of work to figure out what these items are and I wish vera was more transparent about them.

This is extremely useful. I was afraid that Vera really was too tied to outside connectivity to work properly without it and that seems to be the case.

The issues with the Sercoom and Alexa plugins are troubling as it appears that they can cause the entire LUA subsystem to crash if they are not present. This implies that they contain key system code, even though they are supposed to be application-specific.

Thank you for taking on this no doubt frustrating project!

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1246
  • Karma: +62/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #42 on: June 09, 2018, 05:03:10 am »
I have gotten pretty close to losing it tonight and throwing my vera in the garbage. Out of the blue the vera suddenly stopped running any sort of lua code either in scenes or in the lua code test screen. I noticed the problem when I had a scene which turns some lights on and then turns them off through a lua code. The scene would trigger and execute the non lua portion and then not the lua codes. I then started to run some tests:
If I copy and paste my scene lua code into the test screen, the vera would say the scene executed even though it wouldn't do anything. Any edit of the lua code on the screen would lead to an error. I ran a luup reload, same result. I ran a full reboot, same result. I then reopen my firewall to let the vera have internet access and did a luup reload, problem is still there. Then did a full reboot of the vera and... problem is gone. Exact same lua code I also validated on openLuup. It seems like the vera at some point tried to access the mcv server for some reason and decided it would not run any more lua code when it couldn't reach it. At this point I removed my vera from my account and will migrate all of my remaining scenes to openLuup and will be seeking to replace it as soon as I can.
The claim that the Vera can run without an internet connection is fake news.

In the process of all my luup reloads and reboots, I have noticed again a great amount of random NTP sync timing with the luup reload times varying from the Dec 31st 1999 to correct time supporting my claim that the vera hardware is much too slow for its OS causing severe intrinsic timing issues with jobs hanging and not finishing as expected and going completely out of sync. Not every reboot leads to the same outcome. This is insane. I think I saw someone turn his into a wireless router... It seems like it is all it could be good for. It is a bottom of the barrel wireless router with a zwave radio.
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 HSD99

  • Sr. Member
  • ****
  • Posts: 282
  • Karma: +11/-0
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #43 on: June 09, 2018, 11:36:37 am »
Ugh.

Your experience has convinced me to leave things as they are. My local NTP server is working fine with Vera, and I use my VPN for remote access. Both systems are stable (enough) and I don't need to rush into making changes. I suppose I'll eventually look at Homeseer, since I have several Linux servers and a decent Win 10 24/7 system that could easily support it. With the investment I have in Z-Wave and some Zigbee devices, the cost of the HS software is not out of line.

Offline rafale77

  • Hero Member
  • *****
  • Posts: 1246
  • Karma: +62/-23
Re: Securing and stabilizing the Vera by taking it off the grid
« Reply #44 on: June 09, 2018, 04:31:37 pm »
Lets see how this goes... I moved 36 scenes now from the vera to openLuup. (71 down to 35). What is left is pretty difficult to move since it has Trigger lua code or are attribute changes which openLuup does not change remotely.
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!