The Vera Community forums have moved!

General => General => Topic started by: rafale77 on May 12, 2018, 06:53:48 pm

Title: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on May 12, 2018, 06:53:48 pm
I have been working on slowly making my vera plus just a bridge due to its hardware limitations, disproportionately overambitious integration and poor core software development.
As the next step in this journey, now that I have absolutely no plugin integration requiring internet access, I have decided to block all internet traffic to and from the vera unit and see how it fares and wanted to share my experience and maybe get inputs from people who have already done so:

1. First thing to do is to disable the auto-update from the apps which are left. For me it was easy as I only have ALTUI, System Monitor and one instance of the countdown timer left.
2. Ohh I forgot those 2 absurdly useless plugins from vera: The Sercomm IP Camera and the Amazon Alexa Helper. I tried deleting them thinking they could not be re-downloaded after my vera has no internet access. Well I was right but the vera after about a minute post luup reload tries to get them again, post an "error in scene or plugin" in the luup task bar (The blue message bar) and I discover that it  disables its network socket. Basically all scenes continue to work unless it is required to send anything over http. The log shows that there is an AutoPluginInstall function which failed. I decided to let it redownload them and now I am seeing
Code: [Select]
This plugin is automatically available on all Vera controllers and does not need to be manually enabled. on the "my apps page" for these two plugins. I can't say I am pleased. MCV: Your hardware is not capable of handling all the integrations you are throwing at it. Please allow your customers not to download software they do not use. Or if you want to do so, upgrade your hardware by 2-3 generations on memory and CPU. Heck, my coffee machine has more processing power and memory than the vera.
3. The vera seems to be... less prone to random luup reloads. I am running the bet 26b firmware.
4. My access through VPN and Homewave to the vera is now much faster through VPN having bypassed the mcv cloud server.
5. No more "your vera is offline-online" nonsense. It is permanently offline  :P
6. I setup all my notifications through Homeassistant and Pushover which is much more reliable and has less latency.
7. I think the system is more secure now having cut off one uncontrolled access path to my home.
8. Great reliability improvements overall as I won't have unwanted downloads onto my Vera updating files sending data etc.
9. I lose the daily automatic backup and log transfer... So I have to backup locally and log onto a USB stick.
10. As many people already know here, keeping time between reloads is a big issue for the vera. I did set it to read time from my local NTP server so it doesn't need to access a public NTP. What puzzles me is, the vera updates the user json file regularly. It is how it is able to remember status of devices between reloads. Why not get the time from the last modified date of the user json file by default before going for the NTP server??? At least it won't be off by 19 years.

Overall pretty happy with the outcome and I may keep it longer than I initially thought if it stays this way.

Update: For those who want to go straight to the point. I have posted the script files and instructions to implement this in post #175 and #176.
Title: Re: Securing the Vera by taking it off the grid
Post by: therealdb on May 13, 2018, 06:09:49 am
What puzzles me is, the vera updates the user json file regularly. It is how it is able to remember status of devices between reloads. Why not get the time from the last modified date of the user json file by default before going for the NTP server?

Last year I had to deal with sporadic internet access and frequent reboots due to construction and change in my electrical setup. I opened a ticket and they told me that persistent time was in their radar. One year later, no joy.
Title: Re: Securing the Vera by taking it off the grid
Post by: rafale77 on May 13, 2018, 08:33:14 pm
So even with the two rogue apps installed, I am still occasionally seeing Luup reloads failing to complete. It seems to be timing out. In which case I have to disable my firewall blocking rules just for it to complete reload and then re-enable. I am suspecting it to be due to ALTUI. Will see with more testing. That being said, I have not seen a single sponteneous unwanted luup reload which is encouraging.
Title: Re: Securing the Vera by taking it off the grid
Post by: rafale77 on May 14, 2018, 01:31:52 pm
One further update: I had a scene mistakenly run this morning because of a failing
Code: [Select]
return luup.is_night() returning true when it is supposed to be false.

When I go run this in the test Lua code, it returns correctly and the time on the vera is correct.

This is going to push me to move my time related scenes from the vera to openLuup.
I am 100% convinced now that the reliability issues of the vera are related to the UI7 trying to do too many things on a very limited CPU. I believe that the scene failed because it Luup.is.night code did not return fast enough for the scene to continue correctly. I am still quite frequently seeing the UI missing zwave sensors untrip messages. It happens on all kinds of sensors, not a single type. It is also very inconsistent: The same sensor untrips fine for days and just once out of the blue would remain tripped until I go back and trip the sensor and untrip it but walking in front of it or opening and closing a door. It ultimately is problem of jobs and threads running out of sync with others and a fundamental architectural design flaw of the UI and gets worse as the system grows and more functionalities and integrations are added. I do not believe that there is an issue with the zwave or zigbee radio or network since the inconsistencies occurs even when they are not involved. A number of complex plugins which had occasional reliability issues, run perfectly once moved to openLuup. I also am convinced the many random Luup Reloads are triggered due to accumulation of errors related to job completion timing issues.



Title: Re: Securing the Vera by taking it off the grid
Post by: rafale77 on May 18, 2018, 01:16:18 am
One interesting discovery... When the vera runs a luup reload without internet, it actually skips the loading of a few things. One of them is its lua socket so it is essentially not capable of reaching other ethernet connected devices through lua code. So I am currently having to open access to the vera, run a luup reload and then close access again. This is a bit absurd, not having internet access or access to the vera server does not mean we don't want the vera to communicate on a network...
Title: Re: Securing the Vera by taking it off the grid
Post by: HSD99 on May 18, 2018, 07:57:33 am
rafale77, thanks for this thread. I've been moving in this direction myself, albeit much more slowly. I haven't done the detailed analysis of Vera's interactions with the outside world that you have, but have certainly seen that the system relies on outside connectivity to a much greater extent that I had first believed. Here's what I've done to date:

1. NTP redirected to local server on my LAN
The issue of system time is frustrating. Local NTP insures that Vera will be able to get system time when required, but, as you point out, using the timestamp on the most recent checkpoint makes more sense than resetting the time to January 1, 2000. Loss of time across programed events (Luup restarts) is simply poor system architecture.

2. All access to Vera from outside is done via VPN (no use of Vera's relay servers)

3. Cloud backup-I'm OK with this, but wish there was an option to backup to a local network drive instead of, or in addition to, the Vera cloud.

Again, thanks for documenting your experiences.
Title: Re: Securing the Vera by taking it off the grid
Post by: rafale77 on May 18, 2018, 09:06:39 am

3. Cloud backup-I'm OK with this, but wish there was an option to backup to a local network drive instead of, or in addition to, the Vera cloud.


I have good news for you... I have done this:

I created a cron job to run a bash script daily and create a local backup. Just replace the necessary input with yours and then edit your cron jobs. I am doing this on the VM which runs openLuup but it can be done on any computer on your network.
Here is the bash script:

Code: [Select]
#!/bin/bash

backup_location=#path to your local backup folder#
max_number_of_backups=30 #I want to keep a month's worth of backup#

# Setup environment
. /etc/profile >/dev/null 2>&1

# Go to Vera backups directory
cd $backup_location

# Create a date-specific backup name
export BACKUP_NAME=vera_`date +%Y%m%d`.tgz

# Backup ZWave dongle to Vera (this is async and takes time to complete)
wget -O /dev/null "http://#veraip#:3480/data_request?id=action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=BackupDongle&Restore="

# Wait for Zwave backup to complete (actual time depends on # of zwave devices -- do the timing and adjust)
sleep 60

# Backup Vera (whcih will now include ZWave backup)
/usr/bin/wget -O "${BACKUP_NAME}" http://#veraip#/cgi-bin/cmh/backup.sh?external=1

function number_of_backups() {
    echo `ls -1 $backup_location | wc -l`
}


function oldest_backup() {
    echo -n `ls -1 $backup_location | head -1`
}


while [ $(number_of_backups) -gt $max_number_of_backups ]
do
    rm -rf "$backup_location/$(oldest_backup)"
done

exit 0

Edit:

To complete the instructions in case people are less familiar with linux:

1. Create a text file above and name it "verabackup.sh" or whathever you want to call it. Remember to edit the ip address of the vera, the number of files you want to keep and the path to the folder where you want the backups to be saved.
2. Copy that file to a folder you like just remember it's path on the server you want your backups to be.
3. Make this sh file executable by sending the command:
Code: [Select]
chmod a+x verabackup.sh from the folder where this script file is
4. Edit your crontab by executing
Code: [Select]
crontab -e and at the very end of the file add
Code: [Select]
0 4 * * * /path_to_script/backupvera.sh Don't forget to replace the path and the name of your script file. This is for the script to run at 4am everyday. You can change this to whenever you want. The first 0 is the minutes and the 4 is the hour. Do not forget the asterisks.
5. Save the file and you are good to go.
Title: Re: Securing the Vera by taking it off the grid
Post by: HSD99 on May 18, 2018, 10:03:24 am
Good news indeed!

Figuring out how to do a network backup was a future project for a Saturday with absolutely nothing else to do. I'm on the road next week, but will take a crack at this when I return.

+1, with thanks!
Title: Re: Securing the Vera by taking it off the grid
Post by: rafale77 on May 20, 2018, 04:04:32 am
Post 1000 and I hope to make this one useful and helpful:

I created a schematic of how my entire home automation system works and decided to share it.
After months of tinkering I have settled with a 3 controller system which is 100% local.
My graph shows all the Cloud APIs and connections needing an internet connection in blue and all the Local APIs in green with local communications in brown.

1. My main controller is openLuup running on a VM on my NAS. It shows all of my devices and runs most of the automation.
2. I have now successfully fire-walled the vera completely from the internet. I am still seeing it as the most unreliable of the 3 controllers and have dumbed it down quite a bit and will still continue as much as I can. It is essentially now a glorified zigbee and zwave radio with minimal amount of scenes I have kept there to reduce latency for scenes which are triggered by zigbee and zwave devices.
3. Home Assistant runs a number of cloud integration devices which are not available on vera/openLuup running on another VM. It is a secondary controller acting essentially as a bridge for openLuup. I am fairly new to it and I know I could consolidate a few more things within this controller.

Conceptually the vera is now like a Smartthing except that I have replaced the unreliable ST cloud processing with my NAS running a combination of openLuup and Home Assistant. In my view, with UI7 the Vera controllers really aren't capable of being more than a radio: As you can read through a number of thread in this section of the forum. The hardware is just much too limited between the slow CPU and lack of memory/storage causing a number of issues as setups grow larger and I am continue to discover has fundamental reliability flaws. The major advantages of this architecture is, resilience to internet outage, as it would just cutoff inputs a few sensors and actions of even fewer ones, and reliability. I still get occasional mysterious luup reloads on the vera but it is much less frequent and less critical.

For this milestone post I wanted to especially thank all the folks on this forum who contributed to this setup and from whom I have learned:
@amg0 for ALTUI, ALTHue and Iphone Locator
@Akbooer for openLuup
@Reneboer for Harmony
@watou for Ecobee
@lolodomo for Sonos
@futzle for Countdown Timer
@blakem for VRainsensor
@airedale for Plantlink
@Rigpapa for SiteSensor
@intventlr for Homewave
@bwssytems for the ha bridge
@hackworth for the Homekitbridge
Title: Re: Securing the Vera by taking it off the grid
Post by: Don Phillips on May 20, 2018, 10:09:32 am
+1 for the shout outs and glimpse into your setup.
Title: Re: Securing the Vera by taking it off the grid
Post by: Mike Yeager on May 20, 2018, 09:04:11 pm
I may be headed in this general direction as well. I've just gotten into HomeAssistant and it's another learning curve, but my RPi house controller (I have other processes running on it for over a year now) has been rock solid. How does HomeAssistant handle Vera doing a Luup restart? Does it catch the actions up afterwards or are they lost?
Title: Re: Securing the Vera by taking it off the grid
Post by: rafale77 on May 20, 2018, 11:53:39 pm
I may be headed in this general direction as well. I've just gotten into HomeAssistant and it's another learning curve, but my RPi house controller (I have other processes running on it for over a year now) has been rock solid. How does HomeAssistant handle Vera doing a Luup restart? Does it catch the actions up afterwards or are they lost?

Having played with Home assistant now for a while, I don't think it will have as frequent polling rate as openLuup. This means that a Luup reload will not affect it much. If it happens while a command is sent, the vera may still execute it when it comes back up. This is the reason why I am still maintaining openLuup as my main controller: I am more comfortable with lua coding and the interface. Home Assistant's GUI while very configurable is still not as functional as ALTUI in my opinion. The lower poll frequency also means that you will have more latencies between the controllers.

For the past couple of days, I have been fighting with the vera having random luup reloads, losing time in spite of having set the ntp servers to local and losing its lua http socket. I finally got to the bottom of it this morning. It appears that I had set up my firewall a little too aggressively and blocking vera from some of the local network communications. I think I  have now resolved most of the problems. What I am left is still random luup reloads, and intermittent periods of long delays in zwave commands and even occasional complete miss of a signal or command. Upon full vera reboot, I sometimes observe that the vera takes a long time before it get's its ntp time and therefore goes off executing unwanted things. It's not a big deal if you expect it and do not reboot the vera so often which I don't, but it is something to be aware of. It's not quite there yet but this is the right direction to get the vera more reliable. My overlay partition is stable at 54-55% used space with now only 2 plugins: Countdown timer and System Monitor.

Back to Home Assistant, I am considering using the sonos component with the embedded TTS function to replace the http API I am currently running for all the announcements and the roomba component to replace my separate API. This would consolidate a little.
Title: Re: Securing the Vera by taking it off the grid
Post by: Mike Yeager on May 21, 2018, 08:28:54 am
I like openLuup as well but never had much luck running it on an RPi. Once I upgrade my NAS, I may try it there. Right now I have it running only on Vera itself. Are you still running it on the Vera?
Title: Re: Securing the Vera by taking it off the grid
Post by: rafale77 on May 21, 2018, 09:49:28 am
You can't run openLuup on the vera, you maybe talking about ALTUI? openLuup is basically a vera emulator you can run on any hardware which then connects to the vera through a bridge and controls it.
Title: Re: Securing the Vera by taking it off the grid
Post by: Mike Yeager on May 22, 2018, 05:52:05 pm
Sorry, I lump OpenLuup in with AltUI seeing as it's the front end anyhow. Yes, I'm running AltUI on the Vera...
Title: Re: Securing the Vera by taking it off the grid
Post by: rafale77 on May 22, 2018, 06:42:17 pm
Ok then to answer your original question, I just removed it from my vera. I will install it only when I need it as I really prefer it to the Vera UI but I am trying to stabilize the vera so to be on the safe side I am dumbing it down as much as possible to see how stable it can be. The recent rash of report of storage related crashes lead me to monitor this.

Remaining issues:
1. I am still seeing random luup reloads like most of us albeit not very frequently (once every 1-2 days). I have gone over 15 days in the past without one with a lot of modifications on the vera back on 7.0.20 but it seems the new firmware introduced a few new quirks. It reminds me a bit of the old Windows XP days when the computer could not run more than a few hours without crashing/rebooting but things are gradually improving. (much better than the 1-2 times a day when the vera had internet access)
2. One event of the lua socket crash out of the luup engine after I changed my firewall settings and I recovered just with a luup reload. I have no idea why. This time it was not caused by my firewall since it can recover even with it on and it seems to be a fluke I cannot reproduce.
3. The biggest issue I have is I am still having random security sensor triggers (rare, once every few days) and frequent miss of untrip signals from motion and door sensors. They always trip perfectly but often do not untrip. I have notifications setup to troubleshoot this. I suspect it is due to the size of my network. I can actually see the LED on my sensors blink when they transmit, the vera just completely misses them. Again it is random, varies a lot in frequency and affects every sensor type and model I have so it is definitely a controller/zwave network issue.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager on May 26, 2018, 08:49:29 pm
I have been looking at HomeAssistant, but I'm not sure about it. Still learning, but I'm really no looking to spend a ton of time learning to script different things. That's the main reason I got away from ZWay. While it can be fun, I have a life outside of trying to turn a light on when a certain set of conditions are met. PLEG handles this fairly easily, as does Rules Engine to some extent.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on May 26, 2018, 09:24:54 pm
I am with you. I have learned enough lua now to be dangerous so I don't want to go spend the time to learn python or javascript. I have better things to do. The learning on home assistant is only to configure it. Even though I had to fix a bug in python on one of the components, overall I am not spending any more time on it.

The main purpose of this endeavor is to make the entire system more reliable. I have been doing some bug fixes on some plugins and openLuup and have gotten close to ideal reliability... except for the vera which still remains the most unreliable element of the system:

- It still has random luup reloads every few days I can't figure out. It now has no plugins but still runs all the scenes which are triggered by zwave devices. How much further do I need to dumb it down?
- I still experienced a scene running during daytime while it had a luup.is_night conditional. It is random and not reproducible. I am totally convinced that it is a job completion timing issue inside the vera which I have never seen on openLuup. It could very well be also the reason for the luup reloads
- The good news is, over the past week, I have not had any random tripping of devices and have not noticed any failure to untrip so the zwave side seems to be stabilizing.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager on May 28, 2018, 04:42:23 pm
I'm okay with Python. I have played with a little bit of LUA that I've picked up on here. I don't mind having to do a little bit of programming here and there at all. I've got a network of Arduino devices using XBee radios that communicate with a central control program on an RPi3. It's heavily modified code from Dave's "Desert Home" project, so it's not my original code and I take no credit for his hard work. I have heavily modified it and rewritten some portions of it to do what I wanted it to do. I've also ported it to Python 3 as Dave is still running Python 2. I did it because I'm going to try to figure out how to integrate it with HomeAssistant...
Title: Re: Securing the Vera by taking it off the grid
Post by: HSD99 on May 29, 2018, 08:18:29 pm

3. Cloud backup-I'm OK with this, but wish there was an option to backup to a local network drive instead of, or in addition to, the Vera cloud.


I have good news for you... I have done this:

I created a cron job to run a bash script daily and create a local backup. Just replace the necessary input with yours and then edit your cron jobs. I am doing this on the VM which runs openLuup but it can be done on any computer on your network.
Here is the bash script:

Code: [Select]
#!/bin/bash

backup_location=#path to your local backup folder#
max_number_of_backups=30 #I want to keep a month's worth of backup#

# Setup environment
. /etc/profile >/dev/null 2>&1

# Go to Vera backups directory
cd $backup_location

# Create a date-specific backup name
export BACKUP_NAME=vera_`date +%Y%m%d`.tgz

# Backup ZWave dongle to Vera (this is async and takes time to complete)
wget -O /dev/null "http://#veraip#/data_request?id=action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=BackupDongle&Restore="

# Wait for Zwave backup to complete (actual time depends on # of zwave devices -- do the timing and adjust)
sleep 60

# Backup Vera (whcih will now include ZWave backup)
/usr/bin/wget -O "${BACKUP_NAME}" http://#veraip#/cgi-bin/cmh/backup.sh?external=1

function number_of_backups() {
    echo `ls -1 $backup_location | wc -l`
}


function oldest_backup() {
    echo -n `ls -1 $backup_location | head -1`
}


while [ $(number_of_backups) -gt $max_number_of_backups ]
do
    rm -rf "$backup_location/$(oldest_backup)"
done

exit 0

Edit:

To complete the instructions in case people are less familiar with linux:

1. Create a text file above and name it "verabackup.sh" or whathever you want to call it. Remember to edit the ip address of the vera, the number of files you want to keep and the path to the folder where you want the backups to be saved.
2. Copy that file to a folder you like just remember it's path on the server you want your backups to be.
3. Make this sh file executable by sending the command:
Code: [Select]
chmod a+x verabackup.sh from the folder where this script file is
4. Edit your crontab by executing
Code: [Select]
crontab -e and at the very end of the file add
Code: [Select]
0 4 * * * /path_to_script/backupvera.sh Don't forget to replace the path and the name of your script file. This is for the script to run at 4am everyday. You can change this to whenever you want. The first 0 is the minutes and the 4 is the hour. Do not forget the asterisks.
5. Save the file and you are good to go.
The script is returning a 404-Not Found for this:
# Backup ZWave dongle to Vera (this is async and takes time to complete)
wget -O /dev/null "http://#veraip#/data_request?id=action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=BackupDongle&Restore="

Testing the http call in a browser also results in a 404 error.

I checked and dongle is not being dumped. I've looked through the alleged documentation on the MiOs wiki but can't find anything useful. The main backup is working correctly and generates the proper .tzg backup file.

Any insights  would be most appreciated!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on May 29, 2018, 09:31:03 pm
Mine has been running for a few weeks now. I just checked I forgot the port number for the vera for the dongle call.

it should be
Code: [Select]
wget -O /dev/null "http://#veraip#:3480/data_request?id=action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=BackupDongle&Restore="
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on May 30, 2018, 12:07:31 am
D'oh!  I should have seen that...still jet lagged.  :-[

Working now. Thanks!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on May 31, 2018, 09:52:18 am
The backup scripts are running for both VPs. I added a test in the cron script for successful completion of each backup. If there is a failure, the script emails me.  An additional benefit of the local Vera backup is that the server has a RAID array, and also writes a nightly backup to an external USB 3.0 drive. Thanks for the tip!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on May 31, 2018, 11:10:08 am
Glad you got it working. Backups and backups of backups are great indeed.

My system has been settling and strangely I have not had any false positive on security sensors and have had fewer undetected sensor untrip in the past few days. I hope it will stay that way. The Vera still does random Luup reloads every 30-80 hours.

I turned by old Vera edge and upgraded it to the latest firmware and ssh into it to find out that it?s storage drive has a number of bad sectors. I had retired it 2 years ago when it suddenly lost all of its zwave devices out of the blue and kept wanting downgrade to a certain firmware when I contacted support. (Spent hours and hours trying to figure it out at the time). Given how the UI7 works and the very frequent update and rewriting of the user-data.json file, if one has a very large system, the file can start getting very big even if it is compressed. Mine was a couple of 100KB. In spite of being SLC NAND flash with very good endurance, the fact that the Veras have very little storage and a portion of it gets rewritten every few seconds, the NAND cell certainly worn off relatively quickly (~1year). There is just not to many NAND cell to do wear leveling on assuming that the OS or the drive FW does it. This was probably the reason for my impression that I had frequent data corruption and... gremlins in my setup.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on May 31, 2018, 02:40:05 pm
Yup. Backups with backups are good.

I've wondered about wear-leveling, with the system checkpoint occurring every 6 minutes, plus who knows what else? My user_data.json.lzo file is around 182KB. I wonder if some of the odd crashes some folks have had are due to FLASH errors? The OpenWRT docs are vague on what wear-leveling mechanism is used. I assume the NAND flash is directly connected to the SOC, so management is coming from the OS or other software.

Both my systems are stable. The production system, running 1.7.3232, just works. I don't pay much attention to LUUP reloads, but they don't seem to occur very often. The test system, using the latest firmware, runs System Monitor---the last LUUP restart was a couple of weeks ago and may have been me playing with a camera.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on June 02, 2018, 02:54:29 pm
Upgraded the production system to 1.7.3831 this morning, after a couple of weeks of testing on the secondary system. The production system had 66% used in the overlay partition before the upgrade. No issues during the upgrade, other than taking a couple of minutes longer than expected, no doubt due to upgrading the Z-Wave firmware on the co-processor. Everything is working, and there were some icon changes that had to be addressed by changing category/subcategory settings. The icons now do a better job of representing the actual device type. so no problem.

The overlay partition is now at 81%. I can see why folks who started with an almost full overlay had upgrade issues. As has been mentioned before, this upgrade comes with all the Z-Wave upgrade files for all regions. See the attached file. There's ~ 1.8MB of unused Z-wave 6.1 .hex files, and at least 720KB of unneeded Z-wave 4.5 files.  A forum member noticed this and deleted the unnecessary  files and replaced them with 0 length files to avoid Vera automatically replacing them. It would obviously be much easier for the install script to delete the superfluous files, freeing up ~ 2.5MB of precious overlay space.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 02, 2018, 10:02:13 pm
Well, for me blocking all communications from the vera from the internet has prevented it from getting any of the files back and I have indeed also deleted all of the unused files.
You are lucky to have such long intervals between luup reloads... Mine still reloads every ~36-45h for no apparent reason.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on June 03, 2018, 08:53:57 pm
I don't monitor LUUP reloads on the production system. I had installed System Monitor last year, and it seems that the frequency of LUUP reloads increased, so I removed it. I'll be keeping a close eye on it for the next few days. The upgraded system seems stable and everything is working.

I'll be following you lead on taking Vera off-line, as soon as I'm home for a couple of weeks. I don't want to make major changes and head out of town as the family doesn't appreciate it when Vera goes off the rails. :(
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 03, 2018, 09:50:07 pm
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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on June 03, 2018, 11:45:28 pm
All true.

I don't use Vera for anything mission-critical--no HVAC, or locks of any kind. The HVAC system is pretty fancy and has a thermostat that's really a terminal for the processor in the system. The only "smart" T-stat that will work with the system is the vendor's own, and it's ridiculously overpriced, is cloud-based, and gets some of the worst reviews imaginable. The stock non-automated T-stat works great, and there's no reason to have it be part of Vera.

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.

There's an electric wall heater and a wall-mount AC unit in the shop outbuilding. These are both on Z-Wave outlets, but since they take care of themselves, there's no danger if they get turned on unintentionally. The remote control is to either heat or cool the shop before use; convenient but not essential. And there is a scene that turns them both off at 11PM just in case we forget.

And as far as irrigation goes, I had a battery-powered irrigation hose timer fail in the "on" position when I was out of town. You can imagine the result, so no automation for irrigation, Vera or otherwise.

I use Vera for lighting, where failures are annoying but not disastrous. I also am careful not to write scenes with delays, for obvious reasons. I run with as few plugins as possible (Countdown Timer, DelayLight, Wunderground and couple more that are solid) and don't want to interface to external cloud systems.

I bought Vera as an experiment, to see if low-cost home automation was ready for the masses. HINT: It's not, but I'm not convinced that any of the other solutions out there would be that much better. I don't think Vera's hardware is that bad---I've built much-higher performance real-time control systems with much less powerful hardware. Vera's problems are on the software and corporate management side, and in fact Z-Wave itself in 2018 is a primitive, low-performance HW/SW solution. That said, my Vera has been very stable since summer of 2017 when I rebuilt it from scratch (I had carried over a config from a VL) and I'm pretty happy with it.

So I'll follow your lead and take Vera off-line as time permits.  If I decide to get a fancier system in the future, I'll probably look at Homeseer as I have a 24/7 Win 10 box that should handle it with ease.  Thanks again for sharing your experiences.

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Don Phillips 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 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
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Tillsy 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 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? 
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Don Phillips 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 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!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager on June 09, 2018, 08:05:51 pm
I haven't messed with removing the Vera from the internet, but I have begun porting things over to HomeAssistant. I've removed several plugins and I haven't had a Luup restart that I didn't initiate in days. I'm still in the process of moving things but the end result for now will be the Vera running the devices and some basic automation tasks. Eventually, I may move all the automation off of it. PLEG will be the absolute LAST plugin I remove from the Vera. It's simply too necessary to live without. Honestly, it's what makes Vera work. If only some other plugins were as well supported...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 09, 2018, 08:34:04 pm
I haven't messed with removing the Vera from the internet, but I have begun porting things over to HomeAssistant. I've removed several plugins and I haven't had a Luup restart that I didn't initiate in days. I'm still in the process of moving things but the end result for now will be the Vera running the devices and some basic automation tasks. Eventually, I may move all the automation off of it. PLEG will be the absolute LAST plugin I remove from the Vera. It's simply too necessary to live without. Honestly, it's what makes Vera work. If only some other plugins were as well supported...

Vera works well with Home Assistant providing the low level device support. 

It's actually kinda funny the two most popular (consumer) systems on the market are both nothing without their star Plugins.  (Vera+PLEG) (SmartThings+WebCoRE)

I'm currently working on a plugin to integrate Vera into HomeSeer in the same way Home Assistant does.  I'm early stages though so my plugin is not as refined as Home Assistant's vera component.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 09, 2018, 09:05:39 pm

Vera works well with Home Assistant providing the low level device support. 

It's actually kinda funny the two most popular (consumer) systems on the market are both nothing without their star Plugins.  (Vera+PLEG) (SmartThings+WebCoRE)

I'm currently working on a plugin to integrate Vera into HomeSeer in the same way Home Assistant does.  I'm early stages though so my plugin is not as refined as Home Assistant's vera component.

PLEG seemed to be way overkill when I first looked at it and by the time I potentially would have needed it, I had learned enough LUA that I could code it all myself.

I am finding it quite odd to want to integrate the vera into HomeSeer. As you can see on my first page, the way I build my system, the master is OpenLuup which treats the Vera and HomeAssistant as bridges to other devices. The ultimate goal would be to get rid of the vera which is a glorified zwave and zigbee bridge. Knowing that Homeseer handles zwave, why would you want to integrate it into Homeseer?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 09, 2018, 09:08:08 pm

Vera works well with Home Assistant providing the low level device support. 

It's actually kinda funny the two most popular (consumer) systems on the market are both nothing without their star Plugins.  (Vera+PLEG) (SmartThings+WebCoRE)

I'm currently working on a plugin to integrate Vera into HomeSeer in the same way Home Assistant does.  I'm early stages though so my plugin is not as refined as Home Assistant's vera component.

I am finding it quite odd to want to integrate the vera into HomeSeer. As you can see on my first page, the way I build my system, the master is OpenLuup which treats the Vera and HomeAssistant as bridges to other devices. The ultimate goal would be to get rid of the vera which is a glorified zwave and zigbee bridge. Knowing that Homeseer handles zwave, why would you want to integrate it into Homeseer?

The ONE thing Homeseer lacks is Zigbee device support in any real manner.  So I'm going to use the Vera Plus as a Zigbee controller :)
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 09, 2018, 09:14:47 pm

The ONE thing Homeseer lacks is Zigbee device support in any real manner.  So I'm going to use the Vera Plus as a Zigbee controller :)

 :o :o :o

Can't be serious. Is the Zigbee support sufficient on the Vera? I bought a Zigbee stick back in France which I will pick up when I get back which has a plugin on openLuup. Actually it is so small I probably should have asked my family to mail it to me but oh well...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 09, 2018, 09:23:43 pm

The ONE thing Homeseer lacks is Zigbee device support in any real manner.  So I'm going to use the Vera Plus as a Zigbee controller :)

 :o :o :o

Can't be serious. Is the Zigbee support sufficient on the Vera? I bought a Zigbee stick back in France which I will pick up when I get back which has a plugin on openLuup. Actually it is so small I probably should have asked my family to mail it to me but oh well...

What the Conbee?  For deConz?  I found deConz to be useless for me.  The very limited number of Zigbee devices I have the Vera works for me until I replace them with either a Zigbee device that works with one of my other Hubs (philip, osram, or deconz) or I find a suitable z-wave replacement.  Currently I have some NYCE motion sensors and you can't beat zigbee for motion sensors.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 09, 2018, 09:26:50 pm
The Zigate

https://zigate.fr

https://www.kickstarter.com/projects/1361563794/zigate-universal-zigbee-gateway-for-smarthome

https://github.com/vosmont/Vera-Plugin-ZiGateGateway
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 09, 2018, 09:45:44 pm
The Zigate

https://zigate.fr

https://www.kickstarter.com/projects/1361563794/zigate-universal-zigbee-gateway-for-smarthome

https://github.com/vosmont/Vera-Plugin-ZiGateGateway

From the supported devices it's basically the same a deConz....
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 09, 2018, 09:54:01 pm
Did not know the Deconz. The zigate should support all the generic HA stack though so I have good hope that it covers at least what the vera covers.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 09, 2018, 10:00:08 pm
Did not know the Deconz. The zigate should support all the generic HA stack though so I have good hope that it covers at least what the vera covers.

The problem with deDeconz and possibly with ZiGate is the software layer supporting the ZigBee clusters and device responses through the ZiGate or deConz REST interfaces.  Any of them "can" support any ZHA compliant device with the USB sticks they use.  It's all in the software "knowing" about the devices.  It seems all of the Zigbee solutions out there currently are targeting the easy/cheap entry to market of lights and cheap Xioami devices.  Me.. I have motion sensors from one brand that I want supported.... that's it...that's all I want... unless someone can save me and provide a suitable alternative of a non zigbee motion sensor that is FAST to respond and reset and double look like an eyeball or a hockey puck (ZSE02)
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: cybrmage on June 09, 2018, 11:36:33 pm
The problem with deDeconz and possibly with ZiGate is the software layer supporting the ZigBee clusters and device responses through the ZiGate or deConz REST interfaces.

Me.. I have motion sensors from one brand that I want supported.... that's it...that's all I want...

deConz has very active development for device support. If you want a device supported (and it's not a device that only one in 6 billion people would buy), you should visit their Github page (https://github.com/dresden-elektronik/deconz-rest-plugin) and post a request for support in the issues section. You will probably be asked for logs of device information and some testing of beta builds... If you're not willing to help, then you really don't want the device supported.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 09, 2018, 11:44:58 pm
The problem with deDeconz and possibly with ZiGate is the software layer supporting the ZigBee clusters and device responses through the ZiGate or deConz REST interfaces.

Me.. I have motion sensors from one brand that I want supported.... that's it...that's all I want...

deConz has very active development for device support. If you want a device supported (and it's not a device that only one in 6 billion people would buy), you should visit their Github page (https://github.com/dresden-elektronik/deconz-rest-plugin) and post a request for support in the issues section. You will probably be asked for logs of device information and some testing of beta builds... If you're not willing to help, then you really don't want the device supported.

I have posted in the github for it.  Not a single response.  I guess nobody else likes NYCE sensors. 
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 10, 2018, 12:47:49 pm

On a separate topic, I have now added the combo stick which came with the hubitat to my zwave network which now has 134 nodes (132 devices + the vera and the hubitat) both are primary. I plugged the stick back into the hubitat and was able to control lights. I however have been reading on home assistant support of that combo zwave/zigbee stick and am starting to fantasize about setting up another home assistant instance on a pine64 to completely replace the vera. I am just not sure home assistant will support the vast variety of devices I have. It is all open zwave based. Then again, I would need a home assistant bridge into openLuup which I might consider creating. Given the API, it would be much easier than hubitat.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 11, 2018, 03:09:49 pm
Does anyone have any idea why Vera is probing my network?  It looks like it's from the stupid camera app but I'm not sure.  Hundreds of these in my LuaUPnP.log and for multiple IP addresses.  Looks like it's doing a probe of my subnet looking for a connection.

 FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/SDK/activateStatus response:  <0x76edc520>
01      06/11/18 14:55:37.130   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/SDK/activateStatus response:  <0x76edc520>
01      06/11/18 14:55:52.131   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:07.132   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:22.133   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:37.134   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:52.135   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: tomtcom on June 11, 2018, 10:13:49 pm
I believe it is caused by having upnp enabled which is needed for network discovery.
Does anyone have any idea why Vera is probing my network?  It looks like it's from the stupid camera app but I'm not sure.  Hundreds of these in my LuaUPnP.log and for multiple IP addresses.  Looks like it's doing a probe of my subnet looking for a connection.

 FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/SDK/activateStatus response:  <0x76edc520>
01      06/11/18 14:55:37.130   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/SDK/activateStatus response:  <0x76edc520>
01      06/11/18 14:55:52.131   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:07.132   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:22.133   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:37.134   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:52.135   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>

Sent from my VS995 using Tapatalk

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 12, 2018, 09:18:34 am
I believe it is caused by having upnp enabled which is needed for network discovery.
Does anyone have any idea why Vera is probing my network?  It looks like it's from the stupid camera app but I'm not sure.  Hundreds of these in my LuaUPnP.log and for multiple IP addresses.  Looks like it's doing a probe of my subnet looking for a connection.

 FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/SDK/activateStatus response:  <0x76edc520>
01      06/11/18 14:55:37.130   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/SDK/activateStatus response:  <0x76edc520>
01      06/11/18 14:55:52.131   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:07.132   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:22.133   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:37.134   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>
01      06/11/18 14:56:52.135   FileUtils::ReadURL 28/resp:0 user: pass: size 1 http://192.168.10.41/util/query.cgi response:  <0x76edc520>

Sent from my VS995 using Tapatalk

Kinda fun when upnp is not enabled then???  I've been watching my logs a lot over the last several days doing other dev work and I've seen a lot of those messages.  Some I would say could be uPnP related, but most of them look like they are the Camera app probing to find cameras.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: tomtcom on June 12, 2018, 04:11:53 pm
 :)

Seems at least 2 years old >>
http://forum.micasaverde.com/index.php?topic=40530.0

According to that post, Vera's app which hasn't been updated in a long time or their VistaCam firmware for that matter, could think it's lost connection causing this. I do recall these and I think I've seen them in my logs recently too.

Do you implicitly specify the MAC address for the camera? I have had to do this a number of times otherwise I got connection errors in the UI. Since I doubt you are seeing any errors in the UI, that may not help any.

Normally we would try to remove the app and see if the logs persist but that Apexis app or the other camera app will reinstall itself anyways. I never found much resolutions to most of Vera's logging anyhow and gave up unless a UI problem was reporting an error.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 12, 2018, 05:03:05 pm
:)

Seems at least 2 years old >>
http://forum.micasaverde.com/index.php?topic=40530.0

According to that post, Vera's app which hasn't been updated in a long time or their VistaCam firmware for that matter, could think it's lost connection causing this. I do recall these and I think I've seen them in my logs recently too.

Do you implicitly specify the MAC address for the camera? I have had to do this a number of times otherwise I got connection errors in the UI. Since I doubt you are seeing any errors in the UI, that may not help any.

Normally we would try to remove the app and see if the logs persist but that Apexis app or the other camera app will reinstall itself anyways. I never found much resolutions to most of Vera's logging anyhow and gave up unless a UI problem was reporting an error.

I have no cameras in Vera.  This Vera Plus is a clean factory reset with only a couple of devices in it for some testing I'm doing.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 12, 2018, 05:26:27 pm
This is pretty nasty... Likely some left over code for a plugin which somehow got integrated in the firmware. Only if we could find where it is a get rid of it.

As an update, I now got 60hrs with the vera blocked from the internet without a luup reload. As I am travelling, I got some zwave devices reporting missing though and won?t get to it until I get back. I suspect I can wake them up or reboot them to see if it is a device issue but these are devices which have never failed before. It will be interesting when I get back.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager on June 13, 2018, 02:48:17 pm
On the topic of Zigbee motion sensors, I wish I could find some of them.... Everywhere I looks seems to either be out of not carrying them any longer...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: tomtcom on June 13, 2018, 08:19:47 pm
:)

Seems at least 2 years old >>
http://forum.micasaverde.com/index.php?topic=40530.0

According to that post, Vera's app which hasn't been updated in a long time or their VistaCam firmware for that matter, could think it's lost connection causing this. I do recall these and I think I've seen them in my logs recently too.

Do you implicitly specify the MAC address for the camera? I have had to do this a number of times otherwise I got connection errors in the UI. Since I doubt you are seeing any errors in the UI, that may not help any.

Normally we would try to remove the app and see if the logs persist but that Apexis app or the other camera app will reinstall itself anyways. I never found much resolutions to most of Vera's logging anyhow and gave up unless a UI problem was reporting an error.

I have no cameras in Vera.  This Vera Plus is a clean factory reset with only a couple of devices in it for some testing I'm doing.

Now that I think about it, you have verified the camera app isn't installed? For all reports I have seen this is baked into the firmware and downloads automatically. This is part of their method to ensure a camera added has the software it needs. In UI6 it wasn't there there I remember and I think you had to download it.

Others have complained that it gets redownloaded as soon as you uninstall it.

If it's not there, I'm sorry, don't mean to go on a wild goose chase.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 14, 2018, 02:29:15 am
Probably referring to the sercomm camera plugin which is inexplicably force loaded in the last 3 firmwares. It initially could be removed but would come right back due to a plugin sync function I found in the logs and now can?t be removed at all in the last release in spite I of all the requests on this forum to get rid of it. Pretty exhasperating to me...

I am now getting close to 100h without a luup reload while being completely offline and I still have the same 4 devices which are not detected for the past 3 days. I might be getting somewhere. My hubitat is on the same network and I discovered is very easy to configure, at least for all the power switches.
I also discovered that the latest firmware removed the armed disarmed switch for the sirens  and defaulted my sirens to disarmed which I think disables them... another undocumented change.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 19, 2018, 05:22:54 pm
Removing more and more content from the vera. I am continuing to find new elementary issues with data corruption this morning with the vera going into infinite loop of vera reloads until I did a factory reset and recovered from backup without any apparent error in the logs. I have practically given up on vera now. My architecture is continuously changing and going away from vera dependance:
Homekit bridge and Xandem now connected to openLuup instead of the vera. Number of scenes down from over ~120 to 34. Devices down from ~280 to 200.

Next: moving Homewave and HABridge away from the Vera
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager on June 21, 2018, 04:44:56 pm
I have moved quite a bit to HomeAssistant and allowed it to take over some things I was trying to do with the Vera. I noticed that stability returned after removing the ping sensor, ecobee, and multiswitch plugins. I'm not suggesting that either of these may have been causing my issues. They all seemed to be well executed plugins. I also had some outside python scripts accessing the Vera data through http that might have been loading it up and causing issues. Either way, at this time it's basically radios and it's solid. Still have PLEG doing some things. It's a must on this box...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Tillsy on June 21, 2018, 07:27:07 pm
You're right - Vera becomes quite stable once you have removed all devices from it ;)
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 21, 2018, 11:56:03 pm
You're right - Vera becomes quite stable once you have removed all devices from it ;)

Yup.  With little to no plugins Vera runs well as a radio box.  I get the feeling the Mios system and Vera were not intended for what they are marketing and instead are meant as control boxes for other systems to interface with.  Makes since with their extensive Interface API for other systems to hook into with.  That's about the only thing well documented about Vera.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 22, 2018, 01:21:41 am
I have been going back and forth for some time thinking I could keep the vera as my radio bridge and control everything else through openLuup and Home assistant. Every time I got to some level of hope that it will stabilize, the vera eventually craps out one way or another: Either luup engine, zwave network management, worse yet data corruption.

Eliminating plugins does help but I am now looking for an alternative radio with an API. Another Home assistant instance on a raspberry pi was an option but I am now also considering Zway... Homeseer I think is too spendy for what I want to do with it.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks on June 22, 2018, 08:23:40 am
I have been going back and forth for some time thinking I could keep the vera as my radio bridge and control everything else through openLuup and Home assistant. Every time I got to some level of hope that it will stabilize, the vera eventually craps out one way or another. Either luup engine, zwave network management, worse yet data corruption.

Eliminating plugins does help but I am now looking for an alternative radio with an API. Another Home assistant instance on a raspberry pi was an option but I am now also considering Zway... Homeseer I think is too spendy for what I want to do with it.

Yeah after a certain point of number of devices the Vera stability still tanks.  It's odd as some people can have hundreds of devices in their system and have absolutely zero problems.  (so claimed).  Then others have only a dozen or more and they have a nightmare experience.

I didn't look into Zway too much.  Keep us posted if you go that route.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager on June 22, 2018, 10:04:18 pm
Rafael77, I have a ZWay module. I got away from it due to lack of support. I didn't want to have to spend a weekend programming simple things that weren't available or customizing modules every other day. Now, if HomeAssistant supports it, that's a different story. The software that came with it at the time left a lot to be desired...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on June 23, 2018, 03:14:54 am
Rafael77, I have a ZWay module. I got away from it due to lack of support. I didn't want to have to spend a weekend programming simple things that weren't available or customizing modules every other day. Now, if HomeAssistant supports it, that's a different story. The software that came with it at the time left a lot to be desired...

Yeah I hear you but the idea for me is to just use it as a device bridge and then use a plugin into openLuup.

I came home tonight to find out after a few tests that my vera did a luup reload which killed its lua socket module again... which means that any luup calls calling for any http communication fails with no error. The rest of lua codes still work. Luup reload and reboot don't do anything. I have to reopen my firewall and do a luup reload to make it work again. What a disaster this vera is! I still have no idea what caused the reload as I was far away and absolutely no event occured, I already don't have any plugins and then I get this random death of the lua socket which can't be reloaded without an access to some server.

Edit: I might have accidentally discovered something: I am using a pihole as a DNS server and have been setting my vera with a DHCP reserved IP. As a result the vera had partial access to the internet through the DNS server although all of its direct attempts to the vera servers were blocked by the firewall. I have now set it up with a static IP but this time using a DNS on the internet it cannot access since it is blocked by my firewall. The result is that the UI no longer shows that internet access is "ok". I assume that this changes some behaviors within the OS and that it will no longer try to reach anything on the internet which I hope will stop some of the erratic behavior it's been displaying.
Ohh well I just have to move the rest of my scenes out of the vera...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager 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....
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: jeubanks 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
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: therealdb 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...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: a-lurker 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: therealdb 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: therealdb 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 :)
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: akbooer 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!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: therealdb on July 14, 2018, 03:42:21 am
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...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on July 18, 2018, 08:47:03 pm
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.

1. 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.

2. 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...

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: akbooer on July 19, 2018, 02:17:30 am
Now only if there was a Hass plugin on openLuup...

The REST API documented here: https://developers.home-assistant.io/docs/en/external_api_rest.html looks like a good place to start.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on July 27, 2018, 04:22:39 pm
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.
1. 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.
2. 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.
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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: ZW-Tom on August 20, 2018, 07:28:33 pm
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
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on August 21, 2018, 10:37:09 pm
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

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.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: ZW-Tom on August 24, 2018, 12:40:39 am
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

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.

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")

Tom
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: a-lurker on August 31, 2018, 07:45:50 pm
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?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on August 31, 2018, 07:54:27 pm
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?

Well now I know your timezone...

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...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on September 01, 2018, 03:10:01 am
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.

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: akbooer on September 01, 2018, 03:16:57 am
Watch for a reload when the clocks change back from DST too!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on September 01, 2018, 03:47:54 am
These calls seem to be buried into the LuaUPnP program. I wish I could get the code to modify it... It's very frustrating. Between this, the cumulative Event server calls, the poor command queue management and the nightly heals, these 4 "features" are killing this platform.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: therealdb on September 01, 2018, 11:30:53 am
Same here. I got a luup reload at 0:00 local time.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager on September 01, 2018, 06:39:33 pm
Same here. Got the alert at 12:00:31am...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on September 01, 2018, 07:55:15 pm
I really fail to understand the logic behind a monthly Luup Reload. So is it "Our program is so buggy that we have no idea how to fix it so let's reboot it once a month!"??

Why not every other minute? My system seems reasonably stable now but why oh why would you implement a forced power cycle on an arbitrary schedule? What if I was doing something important right at that moment?

To the new owners... before you start trying to add more features, please fix the code!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: a-lurker on September 01, 2018, 10:13:44 pm
Quote
Why not every other minute?
As we know, many Veras do restart often. As did mine, until I relieved them of a lot of plugin duty, by transferring them to openLuup 8)

To be fair; I would suggest a lot of plugins need a bit more work; probably including some of my own:  https://github.com/a-lurker?tab=repositories
The new owners could work out which ones, by analysing the thousands of Veras hooked up to their servers.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: akbooer on September 02, 2018, 02:40:17 am
I really fail to understand the logic behind a monthly Luup Reload. So is it "Our program is so buggy that we have no idea how to fix it so let's reboot it once a month!"??

The one other thing that it would simplify, which I learned when implementing openLuup, is repeating monthly timers.  This is actually a tricky area because of the different month, and year, lengths.  This might seem trivial, but it's not.  The same is absolutely true of the two DST changes a year, otherwise you have to cope with missing, or repeated, time intervals.

So there are excuses, but perhaps no real reasons.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on October 24, 2018, 02:20:03 pm
Making progress:

There is a network monitor program which can cause havoc running in the background on the vera if one wants to isolate it from the outer world. Upon killing it, I started getting a full vera reboot every 10hours. I just found out why this morning. The log rotate script (/usr/bin/Rotate_Logs.sh), which is a cron job, includes code to either reload luup or reboot the vera if the network monitor fails. The reason for it is to be able to upload logs to the mios servers. These reload functions and network checks are active even if you have the "upload logs to the mios server" disabled in the vera. I also noticed that it copies logs from one folder to another before uploading which is absurd because one is a symbolic link of the other so it is actually overwriting itself. Way to increase NAND cell wear!
The 10hr interval was due to the time the size of the log was just right to do a rotate. I ended up commenting out a lot of the code to prevent Luup Reloads and Vera Reboots as I am convinced that the reload would not fix any problem. This is another example of "I don't know where the bug is so let me just reboot" instead of looking for the bug. Instead of fixing anything, it is actually increasing data corruption probability and is likely going to get the vera into an infinite reload loop.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Sorin on October 25, 2018, 05:29:19 am
se reload functions and network checks are active even if you have the "upload logs to the mios server" disabled in the vera. I also noticed that it copies logs from one folder to another before uploading which is absurd because one is a symbolic link of the other so it is actually overwriting itself. Way to increase NAND cell wear!

To address your concern about NAND wear. Everything that is stored in /tmp folder, is NOT stored on the onboard NAND, but in RAM.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on October 25, 2018, 12:07:00 pm
se reload functions and network checks are active even if you have the "upload logs to the mios server" disabled in the vera. I also noticed that it copies logs from one folder to another before uploading which is absurd because one is a symbolic link of the other so it is actually overwriting itself. Way to increase NAND cell wear!

To address your concern about NAND wear. Everything that is stored in /tmp folder, is NOT stored on the onboard NAND, but in RAM.

Unless it is in the /tmp/log/cmh... which is where these logs are getting copied from and too. Yes the rest is in the RAM.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on October 30, 2018, 05:07:58 pm
I think I am pretty close to where I can be on this topic. It seems like I am now able to almost run forever without Luup reloads due to internet connection drops, network errors or any memory issues. The one leftover source of Luup reload might be within the zwave network which I hope, the Luup engine code is not allowing.

Disabling "networkmonitor" aka "NM" by adding an exit 0 into it's start script has made the vera much snappier and the modification to my LogRotate.sh script has eliminated the vera reloads. I have fixed the absurd mios system time resetting scripts and am now fully relying on the native openWRT scripts for it. The main source of available memory drop  is also the logging mechanism... so the log rotate reliability's key.

I also disabled the MiOSRestApi.sh which contains functions to make calls to the MIOS API server and now prevents it from checking for new firmware updates amongst other things and possibly could be preventing the zwave automated nightly heals. This is making me wonder about the monthly Luup reload too and the end of the month is coming...

Other mods: I updated the "serialapi_controller_static_ZM5304_US.hex" to the latest version (6.81) I obtained from Silabs though this does not seem to matter so much, it is now matching the firmware SDK  as it seems vera did not update it as part of the firmware upgrade as the original file looks older and smaller. I have rewritten some of the scripts to make the internet led depend on successful ntp server checks rather than the networkmonitor which I disabled, and service to be linked to the Luup engine status.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: sebby on October 30, 2018, 06:05:26 pm
I think I am pretty close to where I can be on this topic. It seems like I am now able to almost run forever without Luup reloads due to internet connection drops, network errors or any memory issues. The one leftover source of Luup reload might be within the zwave network which I hope, the Luup engine code is not allowing.

Disabling "networkmonitor" aka "NM" by adding an exit 0 into it's start script has made the vera much snappier and the modification to my LogRotate.sh script has eliminated the vera reloads. I have fixed the absurd mios system time resetting scripts and am now fully relying on the native openWRT scripts for it. The main source of available memory drop  is also the logging mechanism... so the log rotate reliability's key.

I also disabled the MiOSRestApi.sh which contains functions to make calls to the MIOS API server and now prevents it from checking for new firmware updates amongst other things and possibly could be preventing the zwave automated nightly heals. This is making me wonder about the monthly Luup reload too and the end of the month is coming...

Other mods: I updated the "serialapi_controller_static_ZM5304_US.hex" to the latest version (6.81) I obtained from Silabs though this does not seem to matter so much, it is now matching the firmware SDK  as it seems vera did not update it as part of the firmware upgrade as the original file looks older and smaller. I have rewritten some of the scripts to make the internet led depend on successful ntp server checks rather than the networkmonitor which I disabled, and service to be linked to the Luup engine status.

I hope you are in the process of creating some sort of tutorial for the rest of us to follow...  Keep up the good work! watching this thread closely.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: tomtcom on October 31, 2018, 01:27:24 pm
Lol, I am too. This is probably my favorite thread on this forum!

Sent from my VS995 using Tapatalk

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 01, 2018, 12:04:17 am
Lol, I am too. This is probably my favorite thread on this forum!

Sent from my VS995 using Tapatalk




I definitely will. I am even considering writing a script you can execute to do all of this in one shot. So far it?s been holding up. I have not had any spontaneous reload since but for the sake of testing did a few reloads manually. I will now let it be for a month and see if it ever reloads.
Available memory has been oscillating between 180MB and 203MB.
On a different note I just wish mcv would provide a LuaUPnP test program like they used to on UI5 for windows so that I could run some test on another platform.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 01, 2018, 10:05:09 am
Got the luup reload from 1 day 1s of the month which I haven?t found how to disable. The interesting thing I learned is the total time it takes to run each reboot and reload on my system. Knowing how many devices I have and my startup lua runs a number of functions to establish variable watches, my full reboot takes ~1m40s and the Luup reload takes 33s. My openLuup which runs a lot more devices, plugins and all my automation, reloads in less than 3s on a single threaded VM...

It appears also that somehow I have managed to disable the automated nightly heal. As ALTUI is reporting that my latest heal is 4 days old. This would be interesting as I have not yet figured out where or how this happened. I am wondering if it is really not happening or if it is the logging of that event that is no longer occurring. In any case, I started thinking about creating a script to hack the time on the vera, which obviously would mess the logs too, to prevent all these unneeded time dependant events.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 03, 2018, 01:46:56 pm
I am sharing the summary of all the mods I did to the Vera Plus to stabilize it and essentially disconnect it (almost completely) from the mios server.
This was done on firmware 7.0.26.01 (1.7.3831) as the latest release had catastrophic issues with secure class devices on my system. In spite of the help I have gotten from hours on the phone with the mcv support team I had not been able to get my vera to be a reliable, set it up and forget it system until now. It took a lot of testing and onion peeling of the system to conclude that vera is trying to do too much with too little. openLuup was one major leap toward stability but the occasional vera crash still were annoying and required interventions.

With all these mods, my vera has not had any luup reload or vera reboots except for the 1st of the month at midnight.
I practically eliminated all the weird "device not detected" and data corruption issues.
I somehow may have also disabled the nightly heal, though I am trying to confirm this as I used to have very random heal events as reported by ALTUI which have not reproduced in a week.
All plugins not relying on the MIOS servers work. All scenes and Lua code, startup Lua all work. I am only disabling the internet connectivity checks and and the underlying services connecting to the mios servers. The App Store which uses regular http calls still works.

What no longer works:

-Firmware automated check with the mios server
-vera notifications (I am using pushover, if you use vera alert, you likely don't care)
-vera mobile apps as they rely on a remote access relay (I am running everything off of Homewave and openLuup and have stopped using the slow buggy iOS app years ago)
-logging to mios server. All the logs will remain local

The one service I have not been able to disable and still preventing the vera from running completely without the internet is the event server to which the vera sends alerts and accumulate unless either one dumps the files and does a luup reload or allow the vera to connect to its mios event server. This is all in spite of CC agent great help and attempts. The call is unfortunately made within the LuaUPnP program which is the vera engine itself and is a C++ compiled binary.

So here are the mods:

1. Unrelated to disconnection but purely for stability/reliabilty, I extrooted the vera
see here: http://forum.micasaverde.com/index.php/topic,103140.0.html

The main reasons for doing it are:
 a. High number of people, including myself reporting NAND flash failure due to excessive write cycles on a very limited amount of storage.
http://forum.micasaverde.com/index.php/topic,109476.0.html
 b. Limited storage has caused havoc on firmware upgrades recently to the point of bricking vera units.

Unfortunately I have only been able to make this work on the VeraPlus. The Vera Edge and older Veras do not seem to want to mount the external drive on boot.
This is low risk for anyone to try since a failure would just make you boot from the original vera NAND flash

2. Modified 6 files in the /usr/bin folder
  a. mios-services.sh Killed the service functions
  b. MIOSRestApi.sh Disabled all the MIOS server calls
  c. Start_networkmonitor.sh Disabled the network monitor which is a source of Luup reloads, uses resources and is practically useless. It checks for network and internet connectivity and reboots/reloads which is the last thing I wanted it to do. It also seems to slow down the vera
  d. sync.time.sh disabled. One of many time sync scripts. This one is redundant and obsolete
  e. Start_LuaUPnP.sh Very slight mods to control the service led on the unit. Since network monitor is disabled, this LED would be off even when the vera is up and running. I made it depend on the vera engine only.
  f. Rotate_Logs.sh. Removed a nonsensical reload and reboot script which would cause the vera to reboot upon server connection failure even if you have log uploading disabled. I also brute forced disabled the log uploading.

3. Modified files in /etc/init.d

check_internet, tunnels_manager.sh, wan_failover, cmh-ra, wol, all disabled for obvious reasons.
mios_fix_time.sh, modified to eliminate a strange time reset to Jan1st 2000 but I guess I could disable this script altogether given the number of redundant time resetting scripts.

4. Updated the zwave sdk API to 6.81 (in /etc/zwave) to match with the zwave chip firmware. I guess it is either a mistake of the firmware or mcv purposefully wanted to save 20KB of space by keeping a 2 year old version of the file.

I have attached a zip file to decompress and upload on the vera and run modvera.sh which will update all the files and reboot the vera in one shot.

Usage of the file: decompress and SCP into the vera. Copy the entire folder. No SSH into the vera and go into the folder and type the following:

Code: [Select]
chmod +x modvera.sh
./modvera.sh
At the end of the script you will get an ash error which is due to the fact that the script deleted itself so you can ignore it.

In combination with openLuup running all my automation and plugins, I now finally have a stable system!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Sender on November 03, 2018, 03:10:55 pm
Rafale, wow! Good description. Though for me this is a bridge too far...

I want to suggest Melih to read ypur post very carefully because the reasons you did all this, I also have them.

Especially the buggy gen5 secure class zwave support (nonsupport) is breaking up all I have had running fine until this release. It is the culprit of all issues I have on my system.

Keep up the good work!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: markd on November 03, 2018, 03:36:19 pm
Great write up and I really appreciate all the investigative work you have done.  I have no idea what most of what you have written means as I'm not technical but I believe it keeps pressure on Vera to get things sorted....or I'll be joining the crowd moving elsewhere unless we see something soon.  Not the six months that keeps getting mentioned.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 03, 2018, 07:32:55 pm
Ran the script on my test Vera Plus with no issues. I'll keep an eye on things and report back.

Thanks for all of the good work!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 03, 2018, 09:59:50 pm
Thank you for testing. I just installed this on a test vera running the latest 4001 7.0.27 firmware as well and not problems. There is actually no difference in os build between these two versions so the difference is only between the two programs. I will also write a script to revert it in case it is needed.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 04, 2018, 01:48:14 am
Attached is the undo script.

To use it, upload to vera and do

Code: [Select]
chmod +x UnModVera.sh
./UnModVera.sh
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 04, 2018, 12:57:16 pm
Thanks for the undo script! 

Things are running fine, but this test unit is lightly loaded, so I'll add some devices over the next few days to make the test more useful.

FYI, ALTUI shows a Z-Wave heal occured at 1:00AM today. I'll keep an eye on this.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 04, 2018, 11:39:07 pm
Interesting that you still have a nightly heal. I had a luup reload at 1am this morning due to the daylight saving time change and I was expecting it. The luup engine does not like time changes. I have gotten to the point of wondering if it actually also reloads when there is an ntp time adjustment...
This is such a poor design. Imagine a plane rebooting its engine and instruments mid air because its clock time drifted or because it lost communication with its black box... This is exactly what the vera does. Why would one allow a peripheral function in your software to trigger a full reboot of the system?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 08, 2018, 12:55:57 pm
Thanks for the undo script! 

Things are running fine, but this test unit is lightly loaded, so I'll add some devices over the next few days to make the test more useful.

FYI, ALTUI shows a Z-Wave heal occured at 1:00AM today. I'll keep an eye on this.

Let me know how things are going. I am still not seeing any nightly heal on my unit. I don?t know how it got disabled. It might be in the zwave stick with something I did with another controller but I thought it was triggered by the controller and not by the zwave chip. After the reboot of the 1st second of the month, I have not had any reload. I have since done some more tweaking of the service LED behavior so it better follows the luup engine status. I also upgraded all the non kernel packages of OpenWRT on my unit which include lighttpd, which is the webserver, OpenSSL, busybox and lua libraries. It took some tweaking (symbolic links) of the library files. The Vera Plus is running on a version of OpenWRT which officially does not support it?s CPU (MT7621ST). It is supposed to support the older CPU of the vera edge MT7620 but I guess they are similar enough that they can share the same packages. The kernel is very old...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 08, 2018, 03:01:23 pm
It still shows a nightly heat at 1:00AM. Does it log the start or the end of the heal?  I'm heading out of the country on business and won't be able to play around with this for a couple of weeks.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 08, 2018, 05:28:50 pm
It looks like it marks the start... I can?t imagine it finish every night at the same time.
I am on business travel overseas myself.
I played around with a second test unit and found out that the log rotation is a very large contributor to the reloads either by running out of memory while rotating logs or from the script itself calling for a reload when the rotation fails or when it lost its network monitor.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: sebby on November 09, 2018, 08:46:39 am
Hi rafale,
i notice that you do all your external integration (Alexa, Sonos, etc.) through either HA or OpenLuup.  For those of us that may not want to roll out multiple systems and only want something like the native Alexa integration, do you know where in the scripts you modified MIOS hid those settings?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 09, 2018, 11:18:17 am
Actually the Alexa integration may still work after my mod. The sonos one for sure does. I am isolating my vera from the internet only through my firewall and only one way. Meaning nothing on the internet can initiate a call to the vera but the vera can reach the internet because of the event server problem I described previously.

All the local integrations like sonos work for sure. Alexa is going through the habridge at the point for me and I don?t know whether it relies on the mios server (cloud to cloud, Alexa device ->amazon server ->mios API server or ra sever->vera) or whether it connects directly to the amazon server from the unit. If it does call the mios servers there can be many:
The MIOS_Rest_api maybe one, the cmh_ra+tunnels_manager would be the other (remote access tunnel). You could then delete these two files before running the script.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: sebby on November 09, 2018, 12:03:09 pm
I'll check those files.  i ran the script and the native alexa stopped working.  i ran the undo script and everything was back to normal.  it must rely on the MIOS servers for some of the integration.  THanks for providing all this!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 12, 2018, 04:50:07 pm
After a week just got a luup reload corresponding to the time of a daily zwave data backup triggered by my remote server. I am guessing that it either locked up the LuaUPnP for too long or that the system ran out of memory while doing it. I am going to try increasing the cache memory cache dump frequency.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Jamr on November 15, 2018, 11:53:37 am
I apologize for this as I am sure you are aware of this and probably has been discussed in this thread but just finding this out about this is a little depressing as I do want true internet independence.
Apparently our Vera's do not have a built in clock and thus can not schedule any automation when it is not on line.
As I would like to create some automation that is internet independent, I was just wondering how you guys are overcoming this?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 15, 2018, 11:59:00 am
I apologize for this as I am sure you are aware of this and probably has been discussed in this thread but just finding this out about this is a little depressing as I do want true internet independence.
Apparently our Vera's do not have a built in clock and thus can not schedule any automation when it is not on line.
As I would like to create some automation that is internet independent, I was just wondering how you guys are overcoming this?

No need to apologize. I may even include this in my mod script but I did this such a long time ago...

http://forum.micasaverde.com/index.php?topic=33038.0

The vera (re)sets the time 5 times everytime it boots as I explained in this thread

http://forum.micasaverde.com/index.php?topic=108394.0


 
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 19, 2018, 01:12:16 pm
Going on 9th day without a Luup reload. I think the only unwanted luup reloads left are the time change and 1st of the month and zwave related ones.

And oddly I am also not seeing any nightly heal for the past month which is making my zwave network very happy and stable. I still don't know how I disabled it though.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 19, 2018, 02:52:01 pm
Still seeing the nightly heal. I wonder what's different?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 19, 2018, 04:57:42 pm
One thing I am speculating on the nightly heal:

My vera is a secondary controller on my network. Because of the HUBZB stick I am using with home-assistant, which I believe the firmware is preventing from being a secondary, I monkeyed around the network (with primary shifts) to have home-assistant/openzwave as the unique primary and SUC/SIS. (I have 3 controllers on my network). When I loaded home-assistant, I set it up with autoheal disabled around the date it stopped the nightly heal. This may have sent a signal to the entire network including the vera.

I was convinced that the nightly heal was a function called by the luup engine and not self driven by the zwave chip but I might be wrong. It could be also that my previous nightly heals were triggered by home assistant and that I had no vera caused nightly heal since it was a set as a secondary.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 19, 2018, 07:40:01 pm
Looking through the forum, I found a number of posts suggesting that the heal is now driven by the Z-Wave co-processor. This would align with your scenario where your primary controller has possibly told the secondary controllers not to perform the heal.

It seems odd that the Z-Wave co-processor would be time-of-day aware.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 20, 2018, 02:13:40 am
Yes, that would be very interesting as I don't know how that zwave radio chip would know the time.

I don't know how much longer the new ownership will take before releasing UI8 and luup engine but in the meantime, I now have a reasonably stable system which required a lot of work and task/plugin and automation offloading/disabling.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 20, 2018, 01:39:08 pm
We should ask @amg0 as ALTUI is what reports the heal and allows you to perform one on demand. He must have better knowledge of the where and how heals occur.

Rather than a time-aware Z-Wave chip, it seems more likely that the heal is a built-in function of the Z-Wave co-processor, but that it must be triggered by a command from the host.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: amg0 on November 20, 2018, 03:19:58 pm
We should ask @amg0 as ALTUI is what reports the heal and allows you to perform one on demand. He must have better knowledge of the where and how heals occur.

Rather than a time-aware Z-Wave chip, it seems more likely that the heal is a built-in function of the Z-Wave co-processor, but that it must be triggered by a command from the host.
There is no control of the heal I am aware of now.
Note  that the zwave device ( usually device 1 ) supports a up plan action called HealNetowrk with some parameters, that may be a way to trigger Heal but I have not tried and think I remember reading that with newer zwave firmware the heal was not controllable any more.

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 20, 2018, 05:15:55 pm
Thanks amg0. When you mentioned newer firmware, I suppose you are referring to the vera firmware because all other controllers I have (ZWay and home assistant) both still control the nightly heal regardless of the zwave firmware.

I am fairly certain that I have not had any nightly heal in weeks. It used to be very noticeable when it was healing as I had crazy lags at hours I am still awake. I have triggered a manual heal in the past on the vera which left me with 5 devices showing undetected (while still working perfectly) so I am really not keen on doing a vera heal.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: amg0 on November 21, 2018, 07:57:07 am
Thanks amg0. When you mentioned newer firmware, I suppose you are referring to the vera firmware because all other controllers I have (ZWay and home assistant) both still control the nightly heal regardless of the zwave firmware.

I am fairly certain that I have not had any nightly heal in weeks. It used to be very noticeable when it was healing as I had crazy lags at hours I am still awake. I have triggered a manual heal in the past on the vera which left me with 5 devices showing undetected (while still working perfectly) so I am really not keen on doing a vera heal.

I would agree. from the back of my memory I think they were talking the zwave chip firmware ( which some VERA firmware did update at some point )
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 26, 2018, 02:44:30 pm
Just had a Luup reload caused by the zwave command queue being overwhelmed so this confirms that there is a weakness in handling a long list of zwave commands. I just don't know what the limit is...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 26, 2018, 03:54:23 pm
I determined that the variable zwave_heal, reported by ALTUI under the Table Controllers menu, really seems to  indicate a Z-wave save. It will update anytime the Z-Wave network is backed up. Therefore, I'm not sure when the automatic heal runs.

There is a "Z-Wave Heal" button in ALTUI that generates this output in the blue banner on the test system:

Heal Stage : SUCCESS! Z-Wave network heal successful
Heal : Node 7 0 good routes out of 0
ZWave : Configuring Z-Wave devices in your system.

The zwave_heal timestamp did not update.

I'm not sure what all this means. 
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 26, 2018, 03:58:45 pm
I determined that the variable zwave_heal, reported by ALTUI under the Table Controllers menu, really seems to  indicate a Z-wave save. It will update anytime the Z-Wave network is backed up. Therefore, I'm not sure when the automatic heal runs.

That's interesting as I am not seeing this at all. My zwave network is being backed up by the vera daily yet ALTUI's last heal date is from over a month ago.

There is a "Z-Wave Heal" button in ALTUI that generates this output in the blue banner on the test system:

Heal Stage : SUCCESS! Z-Wave network heal successful
Heal : Node 7 0 good routes out of 0
ZWave : Configuring Z-Wave devices in your system.

The zwave_heal timestamp did not update.

I'm not sure what all this means. 

I believe this only checks whether the device is reachable and updates neighbor nodes.

Also I often have luup reloads due to command queue issues when I have a device go out of battery and becoming unresponsive. There is some work needed to in the luup engine to handle situations with no ack better.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 26, 2018, 04:03:09 pm
I'm running a slightly modified version of the daily backup script you kindly supplied a while back. The zwave_heal timestamp updates every night when the backup runs on both Vera Plus hubs.

Perhaps try a manual Z-wavre backup and see if the timestamp changes?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 26, 2018, 04:37:35 pm
I just did and it did not update the timestamp. My previous experience with it also never had the time stamp correspond to a backup time. It was always some random time between midnight and 3am. It is currently stuck in October.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 26, 2018, 05:38:21 pm
Stranger and stranger...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 26, 2018, 06:21:36 pm
maybe amg0 can chime in? I am also wondering if it is the time when the zwave dongle is backed up and sent to the mios server. Since I killed the tunnel to mios it can't send anything there anymore.
@HSD99 did you apply all the mods I made? Maybe you are still connected to the server?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 26, 2018, 06:39:32 pm
@rafale77, my test unit has the mods in your script applied to it. My production system is still on the grid. They both perform the same way as far as the Z-Wave back-up/zwave_heal timestamp is concerned. 

The Mios gateway sees the test unit as being off-line.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on November 26, 2018, 09:45:36 pm
And you are on the latest UI7 firmware and ALTUI version? (I doubt the ALTUI version does anything but just in case). This is quite strange. I am on the 1.7.3831 which is the one before last. I have a test unit on 1.7.4001 on which I just tried to run a manual zwave backup and also did not update the zwave_heal timestamp. Actually starting a manual heal on the test unit doesn't update the timestamp either... I have no zwave device on that unit so I am not sure what is happening with it.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on November 26, 2018, 10:06:41 pm
Both units are on 1.7.4001 with the latest ALTUI. The test unit only has 3 Z-Wave devices. Neither unit controls Zigbee devices. The production machine is extrooted.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Sender on December 07, 2018, 08:42:25 am
Going on 9th day without a Luup reload. I think the only unwanted luup reloads left are the time change and 1st of the month and zwave related ones.

And oddly I am also not seeing any nightly heal for the past month which is making my zwave network very happy and stable. I still don't know how I disabled it though.

Rafale, how are you monitoring luup reloads?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on December 07, 2018, 09:16:47 am
Going on 9th day without a Luup reload. I think the only unwanted luup reloads left are the time change and 1st of the month and zwave related ones.

And oddly I am also not seeing any nightly heal for the past month which is making my zwave network very happy and stable. I still don't know how I disabled it though.

Rafale, how are you monitoring luup reloads?

I have a notification setup at the end my startup lua. Everytime my startup lua is run, it sends a notification through pushover so I get an alarm on my phone. I used to use the vera push notification service but the mios server was too unreliable, sporadically having a lot of delays or even being down so I switched to pushover on home assistant. To the vera it is just an http post call to my home assistant bridge.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: akbooer on December 07, 2018, 11:13:38 am
FWIW, I monitor the uptime of my Veras (as tracked by EventWatcher and archived in openLuup's Data Historian.)

Compare and contrast the current uptimes of my three Veras and two openLuup installations!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on December 07, 2018, 11:28:20 am
Very Nice AK. I think I will end up setting something like this up at some point.

My last Luup reload as of now is the dreaded midnight on the first of the month (PST) so it?s been over 7 days. The last unexpected reload was seemingly after I had scenes overload the zwave command queue due to a device having ran out of battery and therefore not responding to a command and clogging the command queue. I am hoping to be to hit a month. Let?s see how this goes.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on December 10, 2018, 12:07:02 pm
Sigh. Had to do a couple of luup reloads:

1. The vera somehow completely lost control of zwave after I got home one night. The house mode change causes a lot of zwave commands and the queue appears to have been too much to handle this time because it was combined with one of my ecovent having run out of battery. The vents and my Yale locks are battery operated but are considered always on devices so they are relays in the network mesh. I ended up deciding to manually reload luup and got everything working again before changing batteries on the vent.
2. Another of my vents ran out of battery and this time the vera reloaded luup on it's own after 10min of inability to send any zwave commands.

During a luup reload, the zwave API library does not appear to be reloaded so the command queue is definitely in the luup engine and seems poorly written to handle large queues. Having observed how Zway handles it, the vera has a lot to catch up to.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: akbooer on December 10, 2018, 12:34:47 pm
Having observed how Zway handles it, the vera has a lot to catch up to.

...I didn't think that you were a fan of ZWay any more?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on December 10, 2018, 01:00:20 pm
Having observed how Zway handles it, the vera has a lot to catch up to.

...I didn't think that you were a fan of ZWay any more?

Got me on that one. Zway is definitely not my bridge and I am not actively using it. I have just been using it as a tool to compare.
Lots of pros and cons to balance for a device bridge.

ZWay:
Pros: Very good/transparent zwave API/queue handling, supported by openLuup
Cons: slow support when it exists. No support for secure class key input. All kinds of firmware upgrade problems.

Hubitat:
Pros: Device support (inherited mostly from SmartThing). Good support and stability.
Cons: No official local API so it is difficult to control from another controller. Designed to be a standalone controller.

Vera:
Pros: Zwave and Zigbee(plus and secure) device support. support secure class key input.
Cons: underpowered Hardware for the software it runs. Obsolete OS. Poor Stability and zwave command queuing.

Homeassistant/openZwave:
Pros: With the combo stick, supports zwave and signee. Free. Very well supported by community. Supports secure key input.
Cons: Less readable command queue compared to Zway. No openLuup plugin. Device support is WIP.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: niharmehta on December 11, 2018, 02:30:22 am
I have had an interesting experience over the last couple of years with vera.  Except for some exceptions,  once I isolated Vera to its own subnet/vlan on my network it can go several weeks without an unplanned LUUP reload. I get notifications via Vera Alerts when a reload occurs. This is with about 60 devices,  at least a dozen plugins (including cloud dependent), Hass integration, and several Imperihome tablets always polling.   I am (and usually in the past have) running the latest on my Vera Plus.   

I do have others issues with some Zwave devices dropping and some logging issues I encountered, however from the constant LUUP restarts,  isolating it to its own quiet subnet has solved the problem for me.  If any of you just want to try stabilizing your Vera,  I recommend trying it.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: tomtcom on December 12, 2018, 12:40:18 pm
Hi rafale77, how do you view or leverage the z-wave queue you talked about several times in this thread? I use Elvira the excel file to view the logs which is very helpful but I'm not sure where else to look to see something like this.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on December 12, 2018, 05:19:38 pm
It is indeed by looking at the LuaUPNP logs. I am comparing them to the queue list from Z-way and can observe the behaviors and their differences.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: a-lurker on December 12, 2018, 07:21:37 pm
Not sure if this helps but the logviewer plugin will display pretty detailed Z-Wave info (thanks to GenGen's additions) when logging is switched to verbose mode. However that in its self can cause restarts:

http://forum.micasaverde.com/index.php?topic=13477.0

Picks up popcorn ready for next installment.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on December 13, 2018, 12:11:04 am
Just to give you an idea of the difference observed:

I just had a Luup crash and reload after manually sending 7 consecutive commands to a zwave device through the vera within a short period of time, not allowing the first command to complete with even an ack before sending the 7th.
In comparison I have done the same on Zway and have reached over 500 commands in the queue. (half of the commands in the queue are often waiting for ack response from the zwave radio so ~200.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: therealdb on December 13, 2018, 01:27:08 am
I have a lot of Figaro FGS223 and since every command is sent from 2 to 5 times before being executed, I can confirm that massive number of commands (ie changing house mode to switch off all lights) may cause such weirds behaviors and have luupnp engine restarted.
But there?s hope, since it?s not that difficult to implement a robust queue. Let?s hope they will invest in this area under the new effort.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: tomtcom on December 13, 2018, 11:36:41 am
It is indeed by looking at the LuaUPNP logs. I am comparing them to the queue list from Z-way and can observe the behaviors and their differences.

Are you using debug log level then to see these levels in your log?

LV_ZWAVE            40
LV_SEND_ZWAVE       41
LV_RECEIVE_ZWAVE    42

I am trying to diagnose delays to scenes for basic functions and comparing the references you are making to queuing and seeing if I have any of the same issue. It will help me determine if the devices are a problem or the core luup engine and how it is written that you have mentioned a lot in this thread.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on December 13, 2018, 11:49:36 am
I have enabled:
Show polling activity
Show individual jobs
Verbose logging

and yes debug enabled.

I am now very easily able to reproduce the Luup reload by overwhelming the command queue. Since most of my commands are issued from openLuup, I am even thinking about creating a buffered queue on the verabridge. The vera still polls a number of devices in spite of having disabled device polling from the zwave menu... I am thinking about testing a Lua code to disable device polling on all zwave devices, device by device but polling is not the main issue from what I can see.

Code: [Select]
for k, v in pairs(luup.devices) do
 local var= luup.variable_get("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings",k)
 local bat =  luup.variable_get("urn:micasaverde-com:serviceId:ZWaveDevice1", "WakeupInterval",k)
   if var ~= nil  and bat ~= nil then
     if var ~= 0 then
     luup.variable.set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings", "0", k)
     luup.variable.set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollNoReply", "0", k)
     luup.variable.set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollRatings", "5.0", k)
     end
   end
end
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Don Phillips on December 13, 2018, 08:07:46 pm
I do not have a very large network and I was experimenting with Reactor while using PLEG. Some of my z-wave commands were duplicated in both to see which one I liked.  When PLEG and Reactor tried to run some things at 5:30 am, I would get a couple of the commands to work - turn off ceiling fan, start to ramp up the nightstand Hue lamps, and then nothing. A couple of minutes later, a LUUP reload message on Pushover. Most times that was it, Z-wave commands did not complete, probably because Reactor and PLEG were no longer triggering since the conditions were satisfied.  Occasionally, PLEG and Reactor would finish ramping up the nightstand lights, disarming Blue Iris, setting house mode to Home, setting the thermostat temperatures, turning on a wall outlet, etc. I let it go a couple of weeks and it was very consistent behavior.


Either Vera did not like the duplicate commands, or both were sending too many to fast, or both were stacking the z-wave commands too high, or the Reactor and PLEG just do not play well together.  After that experiment, I disabled all of the Reactor devices (they are still there and they trigger. They just do not trigger scenes). Vera went back to being stable most of the time.   
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on December 14, 2018, 12:36:50 pm
Thanks Don,

This is another confirmation to me of the limitations of the luup engine's lack of command queuing. Like you, what I am observing is that once it is overwhelmed, it just hangs, crashes and then reloads ignoring all the commands in between from or to devices.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 13, 2019, 04:57:04 am
Latest iteration of my mod script tested on firmware 1.7.26 and 1.7.27:

I am basically keeping a record of the mods I made to my Vera Plus and wrote a script with the included files so I can remember and recover in case of unit failure. I am sharing it for those who want to try it.
As a reminder, this requires extroot for the reason that the mods require more disk space to install. I did a lot of trial and errors testing, soft bricking my test unit but thanks to the extrooting, it was very easy to debrick it. With extrooting, these mods are completely risk free.
Summary of what this does:

1. Eliminates 3 of the 5 scripts which sync time at startup and at the same time making it more reliable at boot. Now the vera only runs ntpclient as the resident ntp service.
2. Updates the Zwave serial API file to the latest version 6.81.3
3. Eliminates the remote access tunnel to the mios server
4. Eliminates the Relay again to the mios server
5. Eliminates the network monitor and internet connection check which can reboot the vera
6. Disables the MiOS API server functions eliminating various mios cloud functionality
7. Fix the backup function. I think mcv got a little too cute with it, having too many variations of the backup. I got it to be the same files every time.
8. Massive updates to the OS libraries and programs. The most noticeable will be busybox from 1.19 to 1.23 and lighttpd from 1.4.32 to 1.4.46. A lot of these were compiled with Chaos Calmer but appear to work fine on the Vera's barrier breaker. The UI now feels snappier.
9. installed nano and set it up as the default editor. (I am not a fan of vi)

Adding a disclaimer which I was just reminded to do and I thought was very important.

These mods, because they prevent the vera from connecting to the mios servers, also prevent support from logging into your account and help you help you troubleshoot issues. I have taken upon myself to troubleshoot my issues by 1. having a test unit which is extrooted so I can always go back to factory firmware/config and 2. understanding the various scripts and various logic layers. The issue is not so much that vera will not support you, it is that they cannot easily do so by preventing them from accessing your unit. There remains potention issues which these mods do not fix. A few I know of and worth mentioning: 1. data corruption which is more of a hardware/firmware design long term reliability problem 2. a zwave stack to vera program command queue weakness. 3. A couple of issues not related to vera itself but more on the specific vera chip side which I have not really gotten to the bottom of and sometimes require excluding and reincluding the device. (dongle data base issue in the zwave chip itself) which I am able to observe with a secondary zwave controller.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 18, 2019, 12:46:59 pm
Offering now Version 3 of my mods.

The big change comes from the fact that I managed to create my own cross compiling environment for the vera plus linux kernel and platform.

Change log from V2.

Updated busybox to latest stable 1.29.3. If you wonder what this does, it is the base script interpreter and tools of the OS. For me it made the vera run distinguishably  faster. You will actually feel it from web UI. It also includes security updates. One significant thing I have noticed is that a few of my secure class sensors which was an absolute pain to configure (with or without inclusion) because I was suspecting them to respond in the zwave network at a rate which the vera could not keep up with, are now much easier to configure. The overall retry required when trying to re-configure devices has also significantly decreased.
Updated nano to 3.2
Updated lighttpd which is the webserver to latest stable 1.4.52. It has performance and security upgrades
Updated luasocket, luasec, luafilesystem to latest. (this I do not know whether it had an effect. To me it did not break anything)
Other various library updates and patches to scripts to make them work with these updates.

File has become too big for me to attach here. I will find a way to host it.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: markd on January 18, 2019, 03:00:20 pm
This is too complex for me to understand and deploy but it interests me that the work you are doing to stabilise Vera and the progress you've made appears to be more than what Vera have done in the last six months. 
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on January 18, 2019, 03:54:53 pm
I am so tempted to try this as I'm getting somewhat ticked with the amazing ability of Vera to simply lose stuff and be generally a bit not great.

If it all goes wrong, is there a simply roll back? e.g. Reset, log in, restore backup?

Cheers!

C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 18, 2019, 04:26:23 pm
I would tend to recommend to do this combined with extroot because then, all you have to do is unplug the external SSD and the vera boots from default and all your changes are undone. As long as you have backups, you can then plug the drive back in, extroot again, and only run whatever you needed to run. I am actually blown away by how much faster the vera interface feels now... This makes me suspect that the program was written and tested on a much faster machine and then compiled to run on the little embedded machine.

I could go back and rewrite a revert script but value is a limited. A factory reboot and recover from backup should do that for you. I am only modifying files in the rootfs which gets overwritten by the vera firmware updates. I am not modifying the kernel or upgrading the operating system. I am just upgrading packages within the operating system, some at the system level.

Note. The ZIP file is 2MB... I will get to it after work today.

Edit: Attached of a screenshot of the login prompt. :D
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on January 18, 2019, 04:36:15 pm
Awesome, thanks!

I'm probably not going to be able to do this for a week or so, but I need to take some leave so....

C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: tomtcom on January 18, 2019, 07:05:23 pm
Always watching and reading the thread, thanks for the work, if things go sour with Vera's new battle plan I know there are options for my future ha needs.

Sent from my VS995 using Tapatalk

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 19, 2019, 04:24:12 am
Here you go. I made the effort to pretty it up a little and now it gives you also the option to NOT take the vera offline if you so desire but will still upgrade the various packages within OpenWRT.

There are three files but due to size limitations, I am having to post them into 2 different posts.
Download all three files and unzip them which will give you 3 folders.
You have multiple options to get the files on the vera:
 -SCP them on
 -If you have your logs setup on a USB stick, you can remove it from the vera, put the files on the stick next to your logs and then plug it back on the vera. The folders will then be in /tmp/log/cmh
 -if you have extrooted your vera, you can do the same as above by putting the 3 folders on the second partition as you know where it is.

Upgrade process is to enter the VeraMods folder and execute the modvera.sh file

Code: [Select]
cd VeraMods
./modvera.sh
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 19, 2019, 04:25:40 am
And this is the third zip file...

Please make sure than all three folders are in the same location on your drive. You do not need to merge the content.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 30, 2019, 01:52:34 pm
As many of us have been anxiously waiting and expecting any sort of information regarding the new products and platform resulting from the takeover, I have continued to seek continuous improvement of the stability of my setup while looking at what problems people on the forum are reporting. I am at this point not really looking for anything more from vera in terms of functionality besides the request I have made a number of times for:
1. an Offline mode which would not rely at all on any of the vera cloud services which this thread has been mostly about and I have achieved almost all of it besides the single even server requirement.
2. A Zwave command queue which is really now mitigated by my use of AKbooer's excellent openLuup.

I have now updated the vera plus with upgraded packages, the most useful ones being: busybox (system command interpreter) and lighttpd(webserver). I even noticed that mios, own repo now offers some updated packages as well.

I have binned the vera problems into two separated categories:
1. The hardware which I am convinced was just sourced from an OEM (Sercomm) and on which Vera slapped their program without even modifying the firmware. What we call firmware updates for the vera are in reality only firmwares for the zwave and zigbee radio processors and the vera program called LuaUPnP. They are not firmware for the vera device which normally includes a bootloader, a kernel and an operating system. It is massively underpowered if you look at three areas:
         a. Plugins and integrations due to the lack of CPU power, storage space and to a lesser degree on the plus, RAM. There is really plenty of storage on the device but the vera is only using 8.6MB of the 128MB available for its real use, actually to be fair, 20MB is used if we include the ROM and I suspect is caused by a proprietary partition table imposed by the OEM. The resolution to this for me has been to offload all my plugins and integrations to openLuup.
         b. The CPU and network socket cannot keep up with the amount of communication required to both talk to all the vera services and your own integration. I managed to cause a complete system reboot by sending too many requests. No clear resolution on this unless... I can change hardware.
         c. The vera uses SLC NAND for it's storage which is very good as it is a high endurance memory. Unfortunately as I mentioned above, it is restricting itself to a tiny area of it's NAND cells to write of its data which eventually will cause wear and memory cell failure and data corruption which many have experienced. I calculated the lifetime for my use case to be 4-8 years given the frequency and amount of data which is written. extrooting essentially resolves this problem. I have had no data corruption since I did it.

2. Software
        a. Autoconfiguration of devices, works most of the time but I found, goes a little too far in its automation and tends to be buggy. It requires a lot of maintenance as well. It creates attributes, and variables on its own but sometimes does it wrong and then comes back to check and ... causes a luup reload because it's not right and can enter an infinite loop of luup reloads. Thankfully I have ALTUI to stop this insanity which is short of manually modifying the user-data.json file.
        b. Looking at all the shell code, it is actually pretty resilient but some of the scripting is obsolete and conflicts with each other. I was able to correct most of it in my mods. (example of time keeping, backup mechanism etc...)
        c. Luup reloads: the LuaUPnP program tends to abuse of Luup reload commands for no particular reason on UI7 at least. Many times a change of an attribute or exiting of a page will cause a luup reload. I would have preferred a reload button at the top of the page and eliminate all the auto reloads. It would resolve a lot of the problem in "a" as well. There are actually two types of luup reloads. One which is triggered by the program itself and another which is caused by a crash of the luup engine and is more dangerous since data could be lost and corrupted: The vera uses what it calls NVRAM: It is a misnomer in vera's lingo as it is really a ramdisk: It is a volatile file system, basically a virtual drive stored in RAM which is the exact opposite of the nvram which is a portion of RAM stored in a hard drive. You will see it as tmpfs drive. This drive recreated at every boot and is where the vera writes all its logs and configurations and only every few minutes writes them down to the NAND flash which is non volatile and will remain at reboot. However if the luup engine reloads while it was writing something, chances are that you will have a problems when it loads back up. That's why there is a recovery mechanism with multiple versions of the user data. The luup engine also restarts every 1st of the month at midnight, and every time the system time changes.

So in conclusion of all this is while I was able to workaround the software issues, I am facing the possibility that all I have left is the hardware. And while I managed to address the storage problem, the CPU and the network socket could not be changed... or could it?   ;D  :P ;)
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rigpapa on January 30, 2019, 02:24:35 pm
b. The CPU and network socket cannot keep up with the amount of communication required to both talk to all the vera services and your own integration. I managed to cause a complete system reboot by sending too many requests. No clear resolution on this unless... I can change hardware.

A good bit of experimentation on my part recently, along with that of reneboer and akbooer, have revealed a few interest points on this that I would perhaps point away from hardware.

The network socket issue breaks into three classes on its own:

1) The luup request system, appears to have some kind of concurrency issue in which hitting it with too many simultaneous requests leads to a reload. In my own testing, the results are somewhat random, which is to say I can get it fail, but how long it takes varies--sometimes immediately, sometimes only after several minutes of a punishing request load. I have not noticed that CPU load is a factor when the crash occurs.

2) The built-in <incoming> mechanism by which many plugins communicate on sockets with their interfaced devices has some quirks and bugs, but more importantly, the current mechanism of receiving "raw" data (raw protocol on the socket) returns one byte at a time to the handler, rather than a block of all available data, and this leads to massive inefficiency in processing the data, to the point that processing packets of any size is impractical using this method. I've already put in a request with Vera (recently) for a raw block protocol, recognizing it's probably a low priority for them at this moment. Unfortunately, this is the only way of handling received data asynchronously, because...

3) If the foregoing <incoming> mechanism doesn't work for you for whatever reason, you are left with direct luup.io calls or LuaSocket. This is fine for send-expect communication (send command to device, it soon returns a response of success/failure/status), but any protocol that returns data asynchronously (e.g. alarm panel notifies you that zone 7 is now breached and system is in alarm) is a problem because luup.io provides no mechanism for notifying on data available, and the usual mechanisms for waiting on a socket in LuaSocket don't work in the Luup environment--they lead to deadlocks and reloads (which makes sense, actually, given the architecture of the system). That means the plugin needs to poll the socket with a frequency that makes sense for the response time required, which is inherently inefficient (doing work when there's no data waiting/no work to be done) and can lead to high CPU utilization and the side-effects that come with it (impact on other services, etc.). Fixing Luup to make LuaSocket work is probably not in the cards, but I think extending luup.io with a few more useful functions (like being able to set handler functions for "data available" and "connection closed") would go miles toward resolving this and other problems with async comms.

All of these point to software to me. Which is good. It means they are fixable in a portable way that works for even the oldest hardware and keep those hardware platforms viable longer (I've already asked on 2 and 3).
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 30, 2019, 02:37:36 pm
Thanks Rigpapa,

It's very insightful. The reason why I am pointing to hardware is because... I managed to make the whole unit reboot (not just the luup engine) by SCPing a large amount of small files from the vera to server. I was cloning the entire file system and passing it through the socket.
The Extrooting process which does the same but through USB never caused this so I concluded that the socket was the problem.

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rigpapa on January 30, 2019, 02:55:21 pm
Thanks Rigpapa,

It's very insightful. The reason why I am pointing to hardware is because... I managed to make the whole unit reboot (not just the luup engine) by SCPing a large amount of small files from the vera to server. I was cloning the entire file system and passing it through the socket.
The Extrooting process which does the same but through USB never caused this so I concluded that the socket was the problem.

That sounds like a dropbear bug, more a core firmware bundle issue than anything LuaUPnP. I was going to suggest using cpio or tar. Unfortunately, it appears that cpio isn't available, which is a shame, since it does a better job with links on restore. But tar is there and usable, but like scp, would come at the expense of restoring links as files rather than links (so the restore consumes more space than that which was backed up).

Code: [Select]
tar -c -z -f - /overlay | ssh patrick@mylocalserverip 'cat >vera-overlay.tgz'
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 30, 2019, 03:01:05 pm
I did finally manage to clone the file system. Thank you. It just took me to clone folders one at a time and took a little more time doing it. You might be right that it could be a dropbear issue but again I copied back this same files through SCP to another machine (freebsd) running dropbear without any problem. Granted it was going the other direction.

Also, what do you use to monitor the CPU utilization? I did some research on what linux reports and what system monitor, ie top I believe is not the best indicator of utilization spikes.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rigpapa on January 30, 2019, 03:10:17 pm
... (freebsd) ...

Ah, so rare to meet another who has the religion... :)
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 30, 2019, 03:53:23 pm
hahaha  ;D ;D. For testing, I am running the "luup engine" through QEMU... I worry that because the LuaUPnP doesn't queue commands much, it may either drop them or just freeze up so it isn't so much the CPU load over a period of time that matters, it is the peak. It maybe the reason why you are observing inconsistent behaviors.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on January 30, 2019, 05:46:04 pm
The MediaTek MT7621 SoC's dual-CPU cores are pretty powerful, (1.6DMIPS/Mhz) as is the Gigabit Ethernet interface with hardware acceleration. I'm with @rigpapa---this is a software problem. Unfortunately, that leaves a lot of places to look... :(
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on January 30, 2019, 06:22:07 pm
I had the same opinion and bias as well and indeed the luup engine has quite a bit to look at... my test will validate. I don't think it needs a lot of memory. With only two plugins (altui and system monitor) it ranges from 50-80mb used. But before openLuup, I had it run up to 160-180mb used with all my plugins. The look at the storage situation made me wonder if other things are amiss. My busybox upgrade for example made a big difference...though I had to patch some of the original mios scripts to make system backup or leds work again. Unfortunately without the source code for LuaUPnP, we can?t fix things and I know many of them should be quite easy fixes and should not take a whole lot of work and time. So I am looking at the next thing I can.

Also note that only the vera secure has a dual core MT7621A. The Vera Plus has a single core MT7621S.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 01, 2019, 07:44:19 pm
February 1st and got the midnight luup reload. Now I can start my test...
I will see if the hardware is indeed a factor. Hoping to get one month before it reloads. Zwave and Zigbee are all setup.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: mblindsey on February 02, 2019, 12:51:55 am
First, thanks to all the contributors on this thread!  There is an amazing amount of good info here. 

I decided to take the plunge and run the script posted by rafale77 to mod my vera (posts #175/176).  Quick notes:

- Set up extroot using an 64gb SSD drive w/usb->sata controller

- Vera running 1.7.4001, and at the time of this post, the only noted tested versions of the mods in this thread I see are: 1.7.26 and 1.7.27 (post #169)

- I did get two package install errors, and installed both manually, without error. specifically:

* opkg_install_pkg: Package libpam md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'.
* opkg_install_pkg: Package libsqlite3 md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'.


- My full install log is attached.

- I installed the backup script in post #19.  I haven't tested it yet out of cron, but I did need to install bash.

- I'm using Home Assistant to talk to Vera and running automations with Node-Red

I'll report back with successes and failures.

Cheers!

--Michael




Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 02, 2019, 04:09:54 pm

- Vera running 1.7.4001, and at the time of this post, the only noted tested versions of the mods in this thread I see are: 1.7.26 and 1.7.27 (post #169)

- I did get two package install errors, and installed both manually, without error. specifically:

* opkg_install_pkg: Package libpam md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'.
* opkg_install_pkg: Package libsqlite3 md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'.



On the vera firmware version numbering: sorry for the confusion. mios uses version and build in their numbers. I meant to say 7.0.26 and 7.0.27 which are UI versions. 1.7.4001 is the released build for the vera plus corresponding to version 7.0.26.

On the opkg errors. these two packages are secondary and probably will not affect you. They were accompanying packages which came with the updated version of lighttpd and the upgrade is optional. The problem appears though as if the download was somehow corrupted so it is a good thing they did not get installed. Can ignore them for now and see how things go.
I have applied these same mod patches to my emulator test unit currently running on a newer linux kernel (3.18.23 vs 3.14.10) and newer version of operating system (openWRT Chaos Calmer 15.05.1 Vs Barrier Breaker 14.07). I have never seen a luup engine crash since so I am optimistic I will get a month without crash out of my test.

Digging further into the zigbee dongle... the vera uses EZSP (Ember Zwave stack) so any USB stick supporting this standard stack will work on the vera...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 11, 2019, 11:50:12 am
Well so much for my test. It failed after 11 days after 2am which I suspect is after a nightly heal which oddly is not reported on ALTUI.
So it doesn't seem like the vera hardware is much of a limitation to the stability. It seems like the zwave network can be a source of luup reloads as well mostly due to the autoconfiguration of the vera. Any sort of changes to the network, example: Aeon HEM sending a signal saying it can support 3 poles while it only has 2. Can cause the vera to automatically add a device, try and fail to configure it and then either force a reload or crash.
The automation around the device configuration is a big problem and in particular the child device creation handling as we all discovered with ghost child devices. Disable auto configuration in the zwave menu is not sufficient. We need to disable it for each device as well to prevent some of it from happening.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager on February 12, 2019, 08:07:28 am
Wow... You have put far more work into trying to make something stable than I ever would have...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 12, 2019, 11:09:51 am
Yes, it's been an agony... Made a lot of progress and the instability I am facing might be benign but I am trying hard to make the vera work... even without vera hardware. I am at a point of being reasonably happy with it.
I have a couple of suspicions about why luup reloaded after the nightly heal yesterday: I moved a couple of my motion sensors and they might have updated neighbor nodes lists or it is what I described below with the handling in particular of aeon devices automatically creating child devices even after they have been configured. Generally though, when this happens, the reload occurs during the zwave backup, not during the heal so it is more likely the former.

Some people go as far as rebooting the vera every day. it isn't acceptable to me because of the unpredictable times I am up in the house and how long the reload takes ( 35 - 45s and, almost 1m for a reboot) which are times all data is lost. Luup reloads should be acceptable only during setup and configurations (user induced).

Summary of Vera instabilities and solutions:

1. Memory leak and shortage:
       Move plugins out of the vera and to openLuup to reduce the amount used
       Upgraded lighttpd (actually available on the mios opkg repo) to address performance and potential memory leak
       Extreme in my case, ran the vera luup engine on non vera hardware
2. NAND flash corruption and flash partition  full
      ExtRoot to an external flash drive, short term alternative is my script to use the storage partition for non-operating system folders.
      Extreme in my case, ran the vera luup engine on non vera hardware
3. CPU and network socket crash/lockups
      Move plugins to openLuup
      which was recently updated to allow some delay in its communications to prevent overloading the vera socket
      Killed the networkmonitor program running in the background.
4. mios server (outages and errors from the server can cause the vera to crash and reboot)
      Killed all tunnels and services connecting the vera to mios servers except the event server which I have not yet been able to disable.
5. zwave network updates and errors
     Disable auto configuration on every device after the device configuration has been completed.
     I wish I could disable nightly heals but I still see some occasional auto heal I believe triggered by the zwave chip itself
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on February 12, 2019, 11:22:56 am
Rafale, just a random thought (probably answered elsewhere) but do you have any remote access into your Vera? If so, might I ask how you secure it? From an app, for example?

Cheers

C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 12, 2019, 11:54:37 am
Yes I use Homewave as my phone app and have remote access through a VPN through a dyn DNS. I had explored multiple VPN solutions and settled on using openVPN. It isn't just an access to my vera/openLuup. It gives full access to my network including my security NVR, my NAS etc... It adds the extra step of having to log into the VPN but... I am not relying on anyone else's server and I am not sending them any of my data.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on February 12, 2019, 05:25:44 pm
Cheers!

Probably not a high WAF (at least for my W)

C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 12, 2019, 05:40:26 pm
Well, once it is setup right, on my iphone it is about unlocking the phone, launch the openvpn app. turn on VPN and you are in business... One extra app to launch... but the responsiveness, security and reliability is so much greater! :)
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: HSD99 on February 12, 2019, 07:05:02 pm
Well, once it is setup right, on my iphone it is about unlocking the phone, launch the openvpn app. turn on VPN and you are in business... One extra app to launch... but the responsiveness, security and reliability is so much greater! :)

I use OpenVPN and have a VPN server in-house for all the reasons mentioned by @rafele77. The latest version of the OpenVPN app (iOS) will automatically start and connect if you set "Connect" in the App on ON. For me it's seamless; when I leave the house and the phone switches to LTE, the VPN automatically comes up.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on February 13, 2019, 01:45:11 am
Thanks, both.  May well give this some thought.

C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Mike Yeager on February 14, 2019, 06:56:06 am
I simply chose to move to another platform to avoid all of this. I'm still using my Vera for Alexa integration at the moment, as it works great, but that's pretty much it. A few virtual switches to keep things in sync and it's all good. Even if the Vera reboots, things will sync up as soon as it comes back up. I do admire the work that you've put in to this though...
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 15, 2019, 02:53:38 am
I got to the bottom of my last luup reload... It was due to my aeon HEM Gen2 somehow sending crap data. After the luup reload, the vera ignored all the data from the HEM. I power cycled the HEM and it is back up and running. I don't think I have rebooted the HEM in at least a year. I can't really blame the vera alone on this one.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on February 15, 2019, 03:54:46 am
I got to the bottom of my last luup reload... It was due to my aeon HEM Gen2 somehow sending crap data. After the luup reload, the vera ignored all the data from the HEM. I power cycled the HEM and it is back up and running. I don't think I have rebooted the HEM in at least a year. I can't really blame the vera alone on this one.

How do you work out why a reload happened?  Just curious

C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 15, 2019, 10:18:00 am
first I get notifications on my phone whenever I get a luup reload. It is something I did with my startup lua.
2 things to track: I usually look at the logs but they sometimes get wiped out and I see every thing which happened after the reload but nothing just before. In this case, I have setup grafana with historian and noticed that my HEM stopped reporting any update at the very same time the reload occured. I have been noticing it go a little quirky lately creating a 3rd "ghost" phase occasionaly by sending some strange data to the vera.
The problem is also for vera to handle this a little better... poping a message instead of reloading luup which helps nothing would have been much better.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on February 15, 2019, 10:39:17 am
Thanks. I did wonder if it was possible with the inbuilt functionality.  Seems not really. Agreed. Failing catastrophically without any reporting is pretty poor.

C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 19, 2019, 08:51:20 am
Hey @rafale77

Are the VeraMods files in posts 165 / 166 up to date?  I'm just waiting on a USB SSD drive to arrive and am going to try this on a Vera Secure in the next day or so - should it work OK on a Secure?

Similarly, is the extroot.sh in your other thread up to date and should that work OK on a Secure too?

Also, how does this mod and the extroot mod impact on future firmware updates?  Should they just apply over the top and not mess up any of these changes?

And finally for backup / restore, should that work OK too?

My intention is to "prepare" some Secure using your mods and extroot scripts and then restore backups from my live Vera (a mixture of Edge, Plus & Secure) - do you foresee any issues with that?


Your best guess is fine, I have access to several units for testing so I'm not too worried about bricking them ..... I can also provide any info you may need beforehand for the Secure (partition layouts, versions, etc).
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 19, 2019, 11:22:46 am
Hi Martyn:

The latest version of the script is in post 175-176. It is the 3 file version.

The order by which you should apply the script is:

1. extroot (I believe I have only left one version on the forum and deleted all the older ones so it should be up to date)
2. VeraMods.

I have tested them quite extensively on my spare unit having run and bricked the vera quite a few times and recovered as many times. I believe it should work on the secure as well given it is basically the same unit. with a dual core CPU and more memory. Just to be sure though, I would appreciate if you could post the banner you see as you login (I want to check what version of openWRT it is running) and the output of "dmesg" and "df -h" right after a boot so I can map the flash drive.
Not critical but just in case.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 19, 2019, 11:54:27 am
Ah yeah post 175-176 that's what I mean, I was just too lazy to go back and check when I wrote the post :-)

Here's the output:

Code: [Select]
BusyBox v1.19.4 (2017-01-30 10:11:42 UTC) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M

 ---------------------------------------------------
      BARRIER BREAKER (Bleeding Edge, r39638)
 ---------------------------------------------------
  ***      MiOS LTD. ( www.mios.com )        ***
  ***                                        ***
  ***               WARNING :                ***
  *** Any changes made to the system without ***
  *** guidance from MiOS support will VOID   ***
  *** your future Support requests           ***
 ---------------------------------------------------

Code: [Select]
[    5.136000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[    5.136000] [DBG] BOFFSET: 0, BREPEAT: 0
[    5.136000] cdc_xr_usb_serial 1-2.2:1.0: This device cannot do calls on its own. It is not a modem.
[    5.152000] cdc_xr_usb_serial 1-2.2:1.0: ttyXR_USB_SERIAL0: USB XR_USB_SERIAL device
[    5.180000] VFS: Mounted root (squashfs filesystem) readonly on device 31:5.
[    5.196000] Freeing unused kernel memory: 228K (82447000 - 82480000)
[    5.252000] usb 1-2.3: new full-speed USB device number 5 using xhci-hcd
[    5.304000] usb 1-2.3: New USB device found, idVendor=04e2, idProduct=1420
[    5.320000] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    5.336000] usb 1-2.3: Product: Exar USB UART
[    5.344000] usb 1-2.3: Manufacturer: Exar Corp.
[    5.352000] usb 1-2.3: SerialNumber: D162257002
[    5.376000] add_ep parameters, dev_speed 2, is_in 1, isTT 1, ep_type 3, maxp 64, interval 64, burst 0, mult 0, ep 0x9beea300, ep_ctx 0xa1c24240, sch_ep 0x9bf01a80
[    5.408000] check tt_intr_bw interval 8, frame_idx 0
[    5.420000] check tt_intr_bw interval 8, frame_idx 1
[    5.428000] check OK............
[    5.436000] [DBG] BPKTS: 1, BCSCOUNT: 3, BBM: 1
[    5.436000] [DBG] BOFFSET: 8, BREPEAT: 0
[    5.436000] add_ep parameters, dev_speed 2, is_in 0, isTT 1, ep_type 2, maxp 64, interval 1, burst 0, mult 0, ep 0x9beea280, ep_ctx 0xa1c24120, sch_ep 0x9bf01800
[    5.464000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[    5.464000] [DBG] BOFFSET: 0, BREPEAT: 0
[    5.464000] add_ep parameters, dev_speed 2, is_in 1, isTT 1, ep_type 2, maxp 64, interval 1, burst 0, mult 0, ep 0x9beea2ac, ep_ctx 0xa1c24140, sch_ep 0x9bf01580
[    5.496000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[    5.496000] [DBG] BOFFSET: 0, BREPEAT: 0
[    5.496000] cdc_xr_usb_serial 1-2.3:1.0: This device cannot do calls on its own. It is not a modem.
[    5.516000] cdc_xr_usb_serial 1-2.3:1.0: ttyXR_USB_SERIAL1: USB XR_USB_SERIAL device
[    6.808000] Button Hotplug driver version 0.4.1
[    6.844000] JFS: nTxBlock = 4019, nTxLock = 32158
[    6.868000] SCSI subsystem initialized
[    6.880000] usbcore: registered new interface driver usb-storage
[    7.468000] 78:FFFFFF94:FFFFFFB4:FFFFFFF7:FFFFFF85:53
[    7.476000] Raeth v3.1 (Tasklet)
[    7.488000] phy_free_head is 0x1c3a000!!!
[    7.496000] phy_free_tail_phy is 0x1c3bff0!!!
[    7.504000] txd_pool=a1c40000 phy_txd_pool=01C40000
[    7.516000] ei_local->skb_free start address is 0x9be526dc.
[    7.528000] free_txd: 01c40010, ei_local->cpu_ptr: 01C40000
[    7.540000]  POOL  HEAD_PTR | DMA_PTR | CPU_PTR
[    7.548000] ----------------+---------+--------
[    7.560000]      0xa1c40000 0x01C40000 0x01C40000
[    7.568000]
[    7.568000] phy_qrx_ring = 0x01c39000, qrx_ring = 0xa1c39000
[    7.584000]
[    7.584000] phy_rx_ring0 = 0x01c3c000, rx_ring0 = 0xa1c3c000
[    7.624000] MT7530 Reset Completed!!
[    7.632000] change HW-TRAP to 0x17ccf
[    7.640000] set LAN/WAN LLLLW
[    7.652000] GMAC1_MAC_ADRH -- : 0x00007894
[    7.660000] GMAC1_MAC_ADRL -- : 0xb4f78553
[    7.676000] CDMA_CSG_CFG = 81000000
[    7.680000] GDMA1_FWD_CFG = 20710000
[   10.196000] ESW: Link Status Changed - Port4 Link UP
[   11.144000] jffs2: notice: (380) jffs2_build_xattr_subsystem: complete building xattr subsystem, 1 of xdatum (1 unchecked, 0 orphan) and 48 of xref (0 dead, 37 orphan) found.
[   11.644000] ra2880stop()...Done
[   11.656000] Free TX/RX Ring Memory!
[   12.600000]
[   12.600000] set gpio 30 input
[   12.616000]
[   12.616000] set gpio 33 input
[   12.628000]
[   12.628000] set gpio 23 output
[   12.636000]
[   12.636000] set gpio 22 output
[   12.644000]
[   12.644000] set gpio 23 to 0
[   12.652000]
[   12.652000] set gpio 22 to 0
[   20.628000] NTFS driver 2.1.30 [Flags: R/O MODULE].
[   20.664000] loop: module loaded
[   20.676000] gre: GRE over IPv4 demultiplexor driver
[   20.688000] ip_gre: GRE over IPv4 tunneling driver
[   20.716000] u32 classifier
[   20.720000]     input device check on
[   20.728000]     Actions configured
[   20.736000] Mirror/redirect action on
[   20.748000] usbcore: registered new interface driver btusb
[   20.764000] usbcore: registered new interface driver ark3116
[   20.776000] usbserial: USB Serial support registered for ark3116
[   20.796000] usbcore: registered new interface driver cdc_acm
[   20.804000] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[   20.824000] usbcore: registered new interface driver cdc_wdm
[   20.836000] usbcore: registered new interface driver ch341
[   20.852000] usbserial: USB Serial support registered for ch341-uart
[   20.868000] usbcore: registered new interface driver cp210x
[   20.880000] usbserial: USB Serial support registered for cp210x
[   20.896000] usbcore: registered new interface driver ftdi_sio
[   20.912000] usbserial: USB Serial support registered for FTDI USB Serial Device
[   20.932000] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[   20.948000] usbcore: registered new interface driver pegasus
[   20.964000] Error: Driver 'pl2303' is already registered, aborting...
[   21.108000] Ralink APSoC Hardware Watchdog Timer
[   21.124000] usbcore: registered new interface driver sierra
[   21.136000] usbserial: USB Serial support registered for Sierra USB modem
[   21.180000] xt_time: kernel timezone is -0000
[   21.188000] usbcore: registered new interface driver asix
[   21.204000] usbcore: registered new interface driver ax88179_178a
[   21.220000] usbcore: registered new interface driver cdc_eem
[   21.232000] usbcore: registered new interface driver cdc_ether
[   21.244000] usbcore: registered new interface driver cdc_ncm
[   21.260000] usbcore: registered new interface driver cdc_subset
[   21.272000] ip_tables: (C) 2000-2006 Netfilter Core Team
[   21.284000] Type=Restricted Cone
[   21.304000] nf_conntrack version 0.5.0 (8039 buckets, 32156 max)
[   21.328000] usbcore: registered new interface driver option
[   21.340000] usbserial: USB Serial support registered for GSM modem (1-port)
[   21.360000] Error: Driver 'pl2303' is already registered, aborting...
[   21.388000] PPP generic driver version 2.4.2
[   21.400000] PPP MPPE Compression module registered
[   21.412000] NET: Registered protocol family 24
[   21.420000] usbcore: registered new interface driver qmi_wwan
[   21.436000] usbcore: registered new interface driver sierra_net
[   21.448000] usbcore: registered new interface driver smsc95xx
[   21.468000] usbcore: registered new interface driver cdc_mbim
[   21.484000] Error: Driver 'pl2303' is already registered, aborting...
[   21.524000] Error: Driver 'pl2303' is already registered, aborting...
[   24.208000] jffs2: notice: (1882) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[   37.320000] 78:FFFFFF94:FFFFFFB4:FFFFFFF7:FFFFFF85:53
[   37.332000] Raeth v3.1 (Tasklet)
[   37.344000] phy_free_head is 0x1c3a000!!!
[   37.352000] phy_free_tail_phy is 0x1c3bff0!!!
[   37.360000] txd_pool=a1c40000 phy_txd_pool=01C40000
[   37.372000] ei_local->skb_free start address is 0x9be526dc.
[   37.380000] free_txd: 01c40010, ei_local->cpu_ptr: 01C40000
[   37.392000]  POOL  HEAD_PTR | DMA_PTR | CPU_PTR
[   37.404000] ----------------+---------+--------
[   37.412000]      0xa1c40000 0x01C40000 0x01C40000
[   37.420000]
[   37.420000] phy_qrx_ring = 0x01c39000, qrx_ring = 0xa1c39000
[   37.436000]
[   37.436000] phy_rx_ring0 = 0x01c3c000, rx_ring0 = 0xa1c3c000
[   37.480000] MT7530 Reset Completed!!
[   37.488000] change HW-TRAP to 0x17ccf
[   37.496000] set LAN/WAN LLLLW
[   37.508000] GMAC1_MAC_ADRH -- : 0x00007894
[   37.516000] GMAC1_MAC_ADRL -- : 0xb4f78553
[   37.524000] CDMA_CSG_CFG = 81000000
[   37.528000] GDMA1_FWD_CFG = 20710000
[   37.548000] device eth0.2 entered promiscuous mode
[   37.556000] device eth0 entered promiscuous mode
[   37.588000] br-wan: port 1(eth0.2) entered forwarding state
[   37.600000] br-wan: port 1(eth0.2) entered forwarding state
[   39.604000] br-wan: port 1(eth0.2) entered forwarding state
[   40.064000] ESW: Link Status Changed - Port4 Link UP
[   44.056000]
[   44.056000] set gpio 23 to 0
[   44.068000]
[   44.068000] set gpio 23 to 1
[   44.820000] usb 1-2.4: new high-speed USB device number 6 using xhci-hcd
[   44.848000] usb 1-2.4: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[   44.868000] usb 1-2.4: New USB device found, idVendor=058b, idProduct=0041
[   44.884000] usb 1-2.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   44.900000] add_ep parameters, dev_speed 3, is_in 1, isTT 0, ep_type 3, maxp 512, interval 1024, burst 0, mult 0, ep 0x9afdf400, ep_ctx 0xa1c49080, sch_ep 0x9b6d1c80
[   44.932000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   44.932000] [DBG] BOFFSET: 0, BREPEAT: 0
[   44.932000] add_ep parameters, dev_speed 3, is_in 1, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9afdf380, ep_ctx 0xa1c49100, sch_ep 0x9b6d1a00
[   44.964000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   44.964000] [DBG] BOFFSET: 0, BREPEAT: 0
[   44.964000] add_ep parameters, dev_speed 3, is_in 0, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9afdf3ac, ep_ctx 0xa1c490a0, sch_ep 0x9b6d1800
[   44.996000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   44.996000] [DBG] BOFFSET: 0, BREPEAT: 0
[   44.996000] cdc_acm 1-2.4:1.0: This device cannot do calls on its own. It is not a modem.
[   45.012000] cdc_acm 1-2.4:1.0: ttyACM0: USB ACM device
[   46.412000] usb 1-2.4: USB disconnect, device number 6
[   47.412000] usb 1-2.4: new high-speed USB device number 7 using xhci-hcd
[   47.444000] usb 1-2.4: config 1 has too many interfaces: 6, using maximum allowed: 4
[   47.464000] usb 1-2.4: New USB device found, idVendor=1bc7, idProduct=0026
[   47.476000] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   47.496000] usb 1-2.4: Product: 6 CDC-ACM Data Only
[   47.504000] usb 1-2.4: Manufacturer: Telit
[   47.512000] usb 1-2.4: SerialNumber: 354678055800986
[   47.524000] add_ep parameters, dev_speed 3, is_in 1, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9b7b0580, ep_ctx 0xa1c48080, sch_ep 0x9b6d1c00
[   47.556000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   47.556000] [DBG] BOFFSET: 0, BREPEAT: 0
[   47.556000] add_ep parameters, dev_speed 3, is_in 0, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9b7b05ac, ep_ctx 0xa1c48060, sch_ep 0x9b6d1900
[   47.584000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   47.584000] [DBG] BOFFSET: 0, BREPEAT: 0
[   47.584000] add_ep parameters, dev_speed 3, is_in 1, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9bd20500, ep_ctx 0xa1c480c0, sch_ep 0x9b6d1d00
[   47.616000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   47.616000] [DBG] BOFFSET: 0, BREPEAT: 0
[   47.616000] add_ep parameters, dev_speed 3, is_in 0, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9bd2052c, ep_ctx 0xa1c480a0, sch_ep 0x9afdf100
[   47.644000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   47.644000] [DBG] BOFFSET: 0, BREPEAT: 0
[   47.644000] add_ep parameters, dev_speed 3, is_in 1, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9ac7cf00, ep_ctx 0xa1c48100, sch_ep 0x9b5dc700
[   47.676000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   47.676000] [DBG] BOFFSET: 0, BREPEAT: 0
[   47.676000] add_ep parameters, dev_speed 3, is_in 0, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9ac7cf2c, ep_ctx 0xa1c480e0, sch_ep 0x9b6d1700
[   47.708000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   47.708000] [DBG] BOFFSET: 0, BREPEAT: 0
[   47.708000] add_ep parameters, dev_speed 3, is_in 1, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9b581600, ep_ctx 0xa1c48140, sch_ep 0x9b5dce80
[   47.740000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   47.740000] [DBG] BOFFSET: 0, BREPEAT: 0
[   47.740000] add_ep parameters, dev_speed 3, is_in 0, isTT 0, ep_type 2, maxp 512, interval 1, burst 0, mult 0, ep 0x9b58162c, ep_ctx 0xa1c48120, sch_ep 0x9b5dcc00
[   47.768000] [DBG] BPKTS: 1, BCSCOUNT: 0, BBM: 1
[   47.768000] [DBG] BOFFSET: 0, BREPEAT: 0
[   47.804000] option 1-2.4:1.0: GSM modem (1-port) converter detected
[   47.816000] usb 1-2.4: GSM modem (1-port) converter now attached to ttyUSB0
[   47.840000] option 1-2.4:1.1: GSM modem (1-port) converter detected
[   47.856000] usb 1-2.4: GSM modem (1-port) converter now attached to ttyUSB1
[   47.876000] option 1-2.4:1.2: GSM modem (1-port) converter detected
[   47.896000] usb 1-2.4: GSM modem (1-port) converter now attached to ttyUSB2
[   47.912000] option 1-2.4:1.3: GSM modem (1-port) converter detected
[   47.924000] usb 1-2.4: GSM modem (1-port) converter now attached to ttyUSB3
[   49.672000] jffs2: notice: (3331) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[   51.012000] Bluetooth: hci0 urb 9b4cf500 failed to resubmit (2)
[   51.024000] Bluetooth: hci0 urb 9accbf00 failed to resubmit (2)
[   57.824000]
[   57.824000] led off GPIO_LED_ZIGBEE         
[   60.380000]
[   60.380000] led off GPIO_LED_SERVICE         
[   60.660000]
[   60.660000] led off GPIO_LED_LPRF           
[   61.428000]
[   61.428000] led on GPIO_LED_ZIGBEE         
[   61.924000]
[   61.924000] led on GPIO_LED_ZWAVE           
[   62.252000]
[   62.252000] led on GPIO_LED_LPRF           
[   62.468000]
[   62.468000] led on GPIO_LED_LPRF           
[   62.732000]
[   62.732000] led on GPIO_LED_POWER           
[   62.792000]
[   62.792000] led on GPIO_LED_ZWAVE           
[   63.120000]
[   63.120000] led on GPIO_LED_ZIGBEE         
[   63.416000]
[   63.416000] led on GPIO_LED_SERVICE         
[   63.680000]
[   63.680000] led on GPIO_LED_3G             
[   64.120000]
[   64.120000] led off GPIO_LED_ZIGBEE         
[   64.268000]
[   64.268000] led off GPIO_LED_LPRF           
[   64.436000]
[   64.436000] led off GPIO_LED_SERVICE         
[   64.564000]
[   64.564000] led off GPIO_LED_3G             
[   65.620000]
[   65.620000] led on GPIO_LED_BLUETOOTH       
[   67.744000]
[   67.744000] led on GPIO_LED_WIFI           
[   67.864000]
[   67.864000] led on GPIO_LED_BLUETOOTH       
[   71.992000]
[   71.992000] led off GPIO_LED_ZIGBEE         
[   74.184000]
[   74.184000] led off GPIO_LED_LPRF           
[   74.240000]
[   74.240000] led off GPIO_LED_SERVICE         
[   74.628000]
[   74.628000] led on GPIO_LED_ZIGBEE         
[   74.736000]
[   74.736000] led on GPIO_LED_ZWAVE           
[   74.844000]
[   74.844000] led on GPIO_LED_LPRF           
[   74.956000]
[   74.956000] led on GPIO_LED_LPRF           
[   75.064000]
[   75.064000] led on GPIO_LED_ZWAVE           
[   75.164000]
[   75.164000] led on GPIO_LED_ZIGBEE         
[   75.276000]
[   75.276000] led on GPIO_LED_SERVICE         
[   75.388000]
[   75.388000] led on GPIO_LED_3G               

Code: [Select]
Filesystem                Size      Used Available Use% Mounted on
rootfs                    8.0M      4.5M      3.5M  56% /
/dev/root                10.5M     10.5M         0 100% /rom
tmpfs                   251.2M      7.5M    243.7M   3% /tmp
/dev/mtdblock6            8.0M      4.5M      3.5M  56% /overlay
overlayfs:/overlay        8.0M      4.5M      3.5M  56% /
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock10          50.0M     11.5M     38.5M  23% /storage
/dev/mtdblock10          50.0M     11.5M     38.5M  23% /etc/cmh-firmware
/dev/mtdblock10          50.0M     11.5M     38.5M  23% /etc/cmh-backup
/dev/mtdblock9           10.0M     10.0M         0 100% /mios

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 19, 2019, 11:56:08 am
Also added a ps output:

Code: [Select]
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  1.6  0.1   1436   672 ?        S    16:46   0:04 /sbin/procd
root         2  0.0  0.0      0     0 ?        S    16:46   0:00 [kthreadd]
root         3  0.2  0.0      0     0 ?        S    16:46   0:00 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S    16:46   0:00 [kworker/0:0]
root         5  0.0  0.0      0     0 ?        S<   16:46   0:00 [kworker/0:0H]
root         6  0.0  0.0      0     0 ?        S    16:46   0:00 [kworker/u4:0]
root         7  0.1  0.0      0     0 ?        S    16:46   0:00 [migration/0]
root         8  0.0  0.0      0     0 ?        S    16:46   0:00 [rcu_bh]
root         9  0.6  0.0      0     0 ?        S    16:46   0:01 [rcu_sched]
root        10  1.3  0.0      0     0 ?        S    16:46   0:03 [migration/1]
root        11  0.1  0.0      0     0 ?        S    16:46   0:00 [ksoftirqd/1]
root        12  0.0  0.0      0     0 ?        S    16:46   0:00 [kworker/1:0]
root        13  0.0  0.0      0     0 ?        S<   16:46   0:00 [kworker/1:0H]
root        14  0.0  0.0      0     0 ?        S<   16:46   0:00 [khelper]
root        15  0.0  0.0      0     0 ?        S    16:46   0:00 [kworker/u4:1]
root       103  0.0  0.0      0     0 ?        S<   16:46   0:00 [writeback]
root       105  0.0  0.0      0     0 ?        S<   16:46   0:00 [bioset]
root       107  0.0  0.0      0     0 ?        S<   16:46   0:00 [kblockd]
root       115  0.2  0.0      0     0 ?        S    16:46   0:00 [khubd]
root       127  1.2  0.0      0     0 ?        S    16:46   0:03 [kworker/1:1]
root       150  0.0  0.0      0     0 ?        S    16:46   0:00 [kswapd0]
root       151  0.0  0.0      0     0 ?        SN   16:46   0:00 [ksmd]
root       152  0.0  0.0      0     0 ?        S    16:46   0:00 [fsnotify_mark]
root       153  0.0  0.0      0     0 ?        S<   16:46   0:00 [crypto]
root       259  0.6  0.0      0     0 ?        S    16:46   0:01 [kworker/0:1]
root       289  0.0  0.0      0     0 ?        S<   16:46   0:00 [krfcommd]
root       293  0.0  0.0      0     0 ?        S<   16:46   0:00 [deferwq]
root       305  0.0  0.0      0     0 ?        S    16:46   0:00 [kworker/u4:2]
root       321  0.0  0.0      0     0 ?        S    16:46   0:00 [jfsIO]
root       322  0.0  0.0      0     0 ?        S    16:46   0:00 [jfsCommit]
root       323  0.0  0.0      0     0 ?        S    16:46   0:00 [jfsCommit]
root       324  0.0  0.0      0     0 ?        S    16:46   0:00 [jfsSync]
root       339  0.0  0.0      0     0 ?        S<   16:46   0:00 [kworker/1:1H]
root       340  0.0  0.0      0     0 ?        S<   16:46   0:00 [kworker/0:1H]
root       381  0.6  0.0      0     0 ?        SN   16:47   0:01 [jffs2_gcd_mtd6]
root       501  0.1  0.0    892    92 ?        S    16:47   0:00 /sbin/ubusd
root       502  0.0  0.0    768    80 ttyS1    Ss+  16:47   0:00 /sbin/askfirst ttyS1 /bin/ash --login
root      1883  5.5  0.0      0     0 ?        SN   16:47   0:13 [jffs2_gcd_mtd10]
root      2075  0.2  0.0   1048   356 ?        S    16:47   0:00 /sbin/logd -S 16
root      2080  0.1  0.1   3672   624 ?        S    16:47   0:00 /usr/bin/btn_g550 -c /etc/config/button_g550.ini -d
root      2083  0.0  0.0      0     0 ?        S    16:47   0:00 [kworker/1:2]
root      2156  0.2  0.1   1584   756 ?        S    16:47   0:00 /sbin/netifd
root      2360  0.0  0.0   1768   364 ?        S    16:47   0:00 udhcpc -p /var/run/udhcpc-br-wan.pid -s /lib/netifd/dhcp.script -f -t 0 -i br-wan -C
root      2747  0.0  0.0   1772   376 ?        S    16:47   0:00 /usr/sbin/crond -f -c /etc/crontabs -l 5
root      2781  0.0  0.2   4068  1160 ?        S    16:47   0:00 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
root      2786  0.0  0.1   1736   588 ?        Ss   16:47   0:00 /usr/sbin/dbus-daemon --system
root      2962  0.0  0.0   1104   300 ?        Ss   16:47   0:00 /usr/sbin/ntpclient -c 6 -i 600 -s -l -D -p 123 -h 3.openwrt.pool.ntp.org
root      3395  0.0  0.0      0     0 ?        S<   16:47   0:00 [kworker/u5:0]
root      3396  0.0  0.0      0     0 ?        S<   16:47   0:00 [hci0]
root      3397  0.0  0.0      0     0 ?        S<   16:47   0:00 [hci0]
root      3400  0.0  0.0      0     0 ?        S<   16:47   0:00 [kworker/u5:1]
root      3401  0.0  0.0      0     0 ?        S<   16:47   0:00 [kworker/u5:2]
root      3458  0.0  0.0   1768   364 ?        S    16:47   0:00 /usr/sbin/ntpd -n -p 0.openwrt.pool.ntp.org 1.openwrt.pool.ntp.org 2.openwrt.pool.ntp.org 3.openwrt.pool.ntp.org
root      3490  0.0  0.1   1780   524 ?        S    16:47   0:00 /bin/sh /usr/bin/Start_LuaUPnP.sh
root      3611  0.0  0.0   1768   432 ?        S    16:47   0:00 /bin/sh /usr/bin/Start_serproxy.sh
root      3629  0.2  0.2   3364  1452 ?        S    16:47   0:00 /usr/bin/bluetoothd -n -E
root      3653  0.0  0.0      0     0 ?        S    16:47   0:00 [kworker/0:2]
root      3686  0.0  0.0      0     0 ?        S    16:47   0:00 [kworker/1:3]
root      3886  0.0  0.1   1944   600 ?        S    16:47   0:00 /bin/sh /usr/bin/cmh-ra-daemon.sh 127.0.0.1 80 vera-us-oem-relay41.mios.com 30656 SOME REDACTED STUFF
root      3927  0.2  0.0   1232   352 ?        S    16:47   0:00 ssh -p 232 -T -y -i /etc/cmh-ra/keys/cmh-ra-key.priv -R 30656:127.0.0.1:80 cmh-ra@vera-us-oem-relay41.mios.com
root      3965  0.0  0.0   1772   464 ?        S    16:47   0:00 /bin/sh /usr/bin/Start_NetworkMonitor.sh
root      3985  0.0  0.1   1780   520 ?        S    16:47   0:00 /bin/sh /usr/bin/StreamingTunnelsManager.sh
root      4074  0.0  0.0   1792   500 ?        S    16:47   0:00 /bin/sh /usr/bin/Start_WanFailover.sh
root      4102  0.3  0.7   8404  3796 ?        Sl   16:47   0:00 /usr/bin/NetworkMonitor
nobody    4368  0.0  0.0    960   336 ?        S    16:47   0:00 /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k
root      5213  5.0  2.0  75636 10640 ?        Sl   16:47   0:10 /usr/bin/LuaUPnP
root      5456  0.0  0.0   1148   352 ?        S    16:48   0:00 /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300
root      5750  0.0  0.0   1024   340 ?        S    16:48   0:00 /usr/bin/serproxy 127.0.0.1 127.0.0.1 SOME REDACTED STUFF
root      7463  0.8  0.1   1212   536 ?        Rs   16:49   0:01 /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300
root      7556  0.0  0.0   1772   508 pts/0    Ss   16:49   0:00 -ash
root      9337  0.0  0.0   1760   116 ?        S    16:50   0:00 sleep 60
root      9368  0.0  0.0   1760   116 ?        S    16:50   0:00 sleep 58
root      9822  0.1  0.1   1600   596 ?        S    16:51   0:00 /usr/sbin/pppd nodetach ipparam 3g ifname 3g-3g lcp-echo-interval 5 lcp-echo-failure 3 +ipv6 nodefaultroute usepeerdns persist maxfail 1 connect USE_APN=m2m005229.attz DIALNUMBER=*99# /usr/sbin/chat -t5 -v -E -f /etc/chatscripts/3g.cha
root      9906  1.0  0.1   1952   676 ?        S    16:51   0:00 /bin/sh /usr/bin/WanFailover_Watch.sh --3g-iface 3g-3g
root      9930  0.0  0.1   1952   564 ?        S    16:51   0:00 /bin/sh /usr/bin/WanFailover_Watch.sh --3g-iface 3g-3g
root      9934  0.0  0.0   1764   368 ?        S    16:51   0:00 ping -I br-wan -q -w 3 -c 1 98.139.183.24
root      9941  0.0  0.0   1296   336 pts/0    R+   16:51   0:00 ps aux

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 19, 2019, 12:06:49 pm
Thank you! Very helpful.

I cracked up at the rootfs partition... 8MB!! come on mios... what were you thinking?
Vera Lite 11MB, Vera Edge 10MB, Vera Plus 8.6MB, Vera Secure 8MB... The more we upgrade the less storage we have.

Unfortunately the output of your dmesg is a bit tardy in the process (it starts after 5s) so I cannot map the drive but I think I have enough information.
It runs the exact same kernel as the Vera Plus so you can run all the scripts the exact same way. It is even more critical for you to start with extroot.

The ps output is also helpful. The secure seems to have a couple of extra scripts for 3G failover which obviously the VeraMod scripts will not disable.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 19, 2019, 01:35:45 pm
Sounds good, SSD's should be here tomorrow so will take a crack at it.

The ps output is also helpful. The secure seems to have a couple of extra scripts for 3G failover which obviously the VeraMod scripts will not disable.

I've actually been running all my Vera "mostly" disconnected from Vera Cloud for the last three or four years using some simple scripts to kill off most Cloud connectivity aside from logs and alerts and a few other bits .... I forget now, it was ages ago that I figured it all out, but I run all my Vera behind hardware firewalls so it's easy to see what they are trying to connect to.  The one benefit of my simple scripts is that you can run stop / start at will which is handy if you find you need to connect back up to the Cloud for something.


Your mods obviously go much further though!
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 20, 2019, 09:07:13 am
So far so good with the extroot on the Secure :-)

Unfortunately I think running VeraMods has killed it tho :-(

After the reboot there's only a few things running (no LuaUPnP process for example).

Here's the log output from running VeraMods, seems quite a few errors there?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 20, 2019, 10:59:33 am
So, I think this was a permissions problem ...... if you follow the instructions and unzip the VeraMod* .zip files on a Windows PC then all the permissions obviously get removed.

If you then move those folders across to Vera and execute the modvera.sh file it copies various files from those folders into the Vera file system and those files are now no longer executable.


I fixed that by looking at each modvera.sh file and working out which files had been copied into the Vera file system and then changed the permissions to be correct (e.g. chmod 755 x.sh) to match the permissions on files from a standard Vera.

Unfortunately after a reboot it seems that it's now a brick .... not even SSH access ....

I removed the SSD, rebooted from internal, added the SSD back and re-did the extroot to get back to default for now.


Let me know there's anything I can provide to help to troubleshoot?  Would a tar of the original root filesystem help?

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 20, 2019, 12:07:55 pm
Wow, Yes you are right, you need to change the permissions again if the files go through windows. Mac OS seems to be able to maintain the original permission information. Good thing you had it extrooted. It is the ultimate anti-brick failsafe.
If you could run the scripts and paste the output of the script while you are still in SSH mode, I will look into it. There might be some differences on the vera secure which may not allow all of the updates I made so I may have to take them down a notch.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 20, 2019, 02:08:51 pm
Actually I managed to get a bit further along ..... the Secure seems to be pretty different to the Plus, for example the package source in the MiOS repo is mios_g550 and not mios_g450 - that was the big thing that seemed to cause the bricking before (understandably).

After I changed the opkg.conf and opkg2.conf in the VeraMods folders (along with rectifying the permissions issues) it seems happier now (in as much as LuaUPnP is up) although still some problems, for example the Secure has a default installed Plugin that handles the battery & siren aspects and this is cr*pping out at the moment and causing LUA startup errors.

Doing a diff between some of your Plus based modified .sh files and the originals on the Secure shows quite a few differences - I unfortunately don't have a Plus on a current firmware versions to compare your mods against to see what you've changed or what is a genuine difference between the Plus & Secure models.  I've guessed at a few (e.g. the set_led.sh is different on Secure because it has a lot more LEDs) and will fiddle about a bit more.

Oh, also "serialapi_controller_static_ZM5304_US.hex" - do you have the versions for EU / ANZ too? 

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 20, 2019, 03:16:01 pm
Ohh Do not use the ZM5304 to upgrade your zwave firmware. The plus uses a slightly different version: The ZM5202 if I remember correctly you definitely want to keep the original. If your firmware had a ZM5304 file then it is very likely not being used by the luup engine. In case you really want it. I attached it.

It sounds like there is some extra work to be done as indeed some sh scripts are different on the vera secure. I have downloaded and mounted the verasecure firmware to take a peek. Most of the mods should be minor but since I do not have a vera secure I will have a hard time testing it.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 20, 2019, 06:17:37 pm
Ah yes, the Secure is all ZM5202 files (EU, US, ANZ) - is there an updated version of that available?  Also, I assume that upgrading it would have been a manual step and not carried out automagically? I guess not if the file names are different anyway?

I think I roughly figured out most of the changes now and it seems to be running OK.  There was a stupid bug in the Plugin I mentioned before where it tries to get the value of any credit on the internal SIM card from the MiOS servers and fails (probably due to the tunnels being down).  This results in a nil value concatenation error .... schoolboy coding mistake really and easy to fix.

Happy to test a Secure version of your script if you get the chance to make one  .... no problem if not as I think I am OK as-is but a packaged version may work better for anybody else.

One other thing I spotted, I've not looked too closely but the BusyBox upgrade seemed to lose some commands, for example unzip, diff, whoami (you can see what was removed in the log I posted earlier).



Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 20, 2019, 06:55:25 pm
Ah yes, the Secure is all ZM5202 files (EU, US, ANZ) - is there an updated version of that available?  Also, I assume that upgrading it would have been a manual step and not carried out automagically? I guess not if the file names are different anyway?

I have come to believe that these are actually not even used by the vera so I don't know why they are there. I have booted my vera without it. It should. Unfortunately the SDK from Silicon Image only has full firmware for the SD3502 (which is the USB stick) and the API file for the ZM5304 so I am not able to find the ZM5202 version of it.

Happy to test a Secure version of your script if you get the chance to make one  .... no problem if not as I think I am OK as-is but a packaged version may work better for anybody else.

One other thing I spotted, I've not looked too closely but the BusyBox upgrade seemed to lose some commands, for example unzip, diff, whoami (you can see what was removed in the log I posted earlier).


Yes I know that the latest busybox version removes a few commands which I have for some of them had to get back through opkg as standalone binaries. The standalone binaries actually better and more complete than the busybox one which is really useful only if you are very limited in storage space. With extroot, no reason to sweat it. The new busybox however has increased the vera's responsiveness which is why I prefer it.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 25, 2019, 01:39:12 pm
I've had this running for several days now on a Secure and in the most part it appears OK.

This was based on me merging your Plus-based scripts / changes into the Secure which seems have been largely successful.

One thing that I am struggling with though is log-rotation, not sure why but the LuaUPnP log never rotates successfully - that is, it gets rotated to LuaUPnP.1 but a new LuaUPnP file isn't created.

Also, the ntpclient logs rotation looks like:

Code: [Select]
294409 Feb 25 14:05 log.ntpclient.gz.gz
-rw-r--r--    1 root     root        292446 Feb 25 14:05 log.ntpclient.gz.gz.gz.gz
-rw-r--r--    1 root     root        293818 Feb 25 14:05 log.ntpclient.gz.gz.gz.gz.gz.gz
-rw-r--r--    1 root     root        292673 Feb 25 14:05 log.ntpclient.gz.gz.gz.gz.gz.gz.gz.gz

I think I'm using the Rotate_Logs.sh from your mods as-is, so I wondered if you have noticed the same issue?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 25, 2019, 01:46:52 pm
It looks like the rotate logs need to be modified for the Vera Secure. It is likely that the name of the log is different. I will look into it when I have a few minutes today.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 25, 2019, 02:27:02 pm
Actually I think I worked out what was happening.

If I ran Rotate_Logs.sh manually with force flag then it gets:

Code: [Select]
root@:/etc/init.d# /usr/bin/Rotate_Logs.sh 1
ps: invalid option -- a
BusyBox v1.29.3 () multi-call binary.

Usage: ps

Show list of processes

        w       Wide output
Starting Ntpclient
ps: invalid option -- a
BusyBox v1.29.3 () multi-call binary.

Usage: ps

Show list of processes

        w       Wide output
ps: invalid option -- f
BusyBox v1.29.3 () multi-call binary.

Usage: ps

Show list of processes

        w       Wide output
ps: invalid option -- a
BusyBox v1.29.3 () multi-call binary.

Usage: ps

Show list of processes

        w       Wide output
Start rotating logs PID=31563, force rotate=1, free space=254464 KB, min=5120 KB, cmh logs size=8 KB, max=20480 KB, now=1551120901, last rotation=1551103502, diff=289 min 59 sec, max=12 hours
/usr/bin/Rotate_Logs.sh: line 129: stat: not found
sh: 358400: unknown operand
ps: invalid option -- f
BusyBox v1.29.3 () multi-call binary.

Usage: ps

Show list of processes

        w       Wide output
ps: invalid option -- a
BusyBox v1.29.3 () multi-call binary.

Usage: ps

Show list of processes

        w       Wide output
ps: invalid option -- a
BusyBox v1.29.3 () multi-call binary.

Usage: ps

Show list of processes

        w       Wide output
Finished log rotation for serial=, version=1.7.4002, date=2019-02-25_18-55-03
ArchiveLogsOnServer is disabled, no logs uploaded

It seems that ps version from new busybox in /bin doesn't support the a flag - or perhaps it doesn't "pass through" to the full ps binary in /usr/bin/ - on an original Secure I can do /bin/ps aux OR /usr/bin/ps aux and get the same valid output.

In any case I can workaround the issue by hardcoding the path in the Rotate_Logs.sh script and if I do that I now get:

Code: [Select]
root@:/usr/bin# ./Rotate_Logs.sh 1
Start rotating logs PID=1569, force rotate=1, free space=255696 KB, min=5120 KB, cmh logs size=8 KB, max=20480 KB, now=1551121690, last rotation=1551120901, diff=13 min 9 sec, max=12 hours
./Rotate_Logs.sh: line 129: stat: not found
sh: 358400: unknown operand
Finished log rotation for serial=, version=1.7.4002, date=2019-02-25_19-08-12
ArchiveLogsOnServer is disabled, no logs uploaded

So it now barfs on the "stat" command - which is missing from the busybox install (compared to an original Secure).


I assume this all works OK on the Plus?
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 25, 2019, 02:32:44 pm
touche....

From memory I had to run
Code: [Select]
opkg install coreutils-stat
and
Code: [Select]
opkg install procps-ps
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: martynwendon on February 25, 2019, 02:58:15 pm
Yeah stat I installed OK.

What's odd though is that procps-ps *is* installed (in /usr/bin)

But there's also a ps in /bin as part of busybox.

This is the same as on an original Secure though, but I'm surmising that the original busybox version handled "ps a" OK:

Code: [Select]
root@:~# ls -alt
drwxr-xr-x    4 root     root          4096 Feb 25 19:52 .
lrwxrwxrwx    1 root     root            26 Feb 25 19:52 ps -> /mnt/mtdblock6/bin/busybox
drwxr-xr-x    4 root     root          4096 Feb 21 18:00 changes
drwxr-xr-x   20 root     root          4096 Feb 21 17:52 ..
-rwxr-xr-x    1 root     root           604 Feb 20 16:37 redoextroot.sh
-rwxr-xr-x    1 root     root          1972 Feb 19 13:32 extroot.sh
drwx------    2 root     root          4096 Jun 25  2018 .ssh
root@:~# ./ps aux
  PID USER       VSZ STAT COMMAND
    1 root      1444 S    /sbin/procd
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    5 root         0 SW<  [kworker/0:0H]
    6 root         0 SW   [kworker/u4:0]
    7 root         0 SW   [migration/0]
    8 root         0 SW   [rcu_bh]
    9 root         0 SW   [rcu_sched]

Code: [Select]
root@:~# /bin/ps aux
/bin/ps: invalid option -- a
BusyBox v1.29.3 () multi-call binary.

Usage: ps

Show list of processes

        w       Wide output


In any case I chose to remove the symlink for ps from /bin to busybox to sort it, so in theory /usr/bin version will always be used (as long as /usr/bin is in PATH of course)
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 25, 2019, 09:35:21 pm
Ohh yeah I have had to do this on my vera simulator as well. I don't remember doing it on the plus though.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on February 26, 2019, 01:21:20 pm
Rafale looking at your mods, I'm struggling to see how you have modified Log rotation?  I'm wanting to store rather more logs for troubleshooting. Can you explain?

Many thanks
C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: rafale77 on February 26, 2019, 11:29:05 pm
Cayman, I am out of town this week and will have a hard time looking into it. I just remember that the log rotate runs as a function of how much space the logs occupy and you can set a limit. It is all in the RotateLog.sh in the /usr/bin folder I believe. You can check that script and change the limit. It is actually fairly well commented.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on February 27, 2019, 12:59:36 am
No panic at all :) . I can see the comments but little concerned about some of the other comments that the changes get overwritten.

Will have a prod :)

Cheers!

C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: niharmehta on February 27, 2019, 01:17:56 am
Rafale looking at your mods, I'm struggling to see how you have modified Log rotation?  I'm wanting to store rather more logs for troubleshooting. Can you explain?

Many thanks
C

Another option if you want to store more logs is to just have the log rotation script FTP it to your own server vs the MIOS servers. It is a trivial change to make it work .  I have years of log files stored on my NAS.
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on February 27, 2019, 02:08:31 am
Ahh! Edit defaultLogsServer="logs1.mios.com"

Cheers!

C
Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: niharmehta on February 27, 2019, 01:54:30 pm
yes that is in the servers.conf file I think. You can also edit the /etc/hosts file to point to your own FTP server.  create a user/pass matching the config file. I posted this a couple of years ago :
http://forum.micasaverde.com/index.php/topic,37156.msg277291.html#msg277291

Each FW update may reset the configuration to default however.

Title: Re: Securing and stabilizing the Vera by taking it off the grid
Post by: Catman on February 27, 2019, 05:02:47 pm
yes that is in the servers.conf file I think. You can also edit the /etc/hosts file to point to your own FTP server.  create a user/pass matching the config file. I posted this a couple of years ago :
http://forum.micasaverde.com/index.php/topic,37156.msg277291.html#msg277291

Each FW update may reset the configuration to default however.

Thanks I think your way is simpler :)

C