veralite 1.7.513 lua restart every 6 minutes (on the second)

ranneman · February 21, 2015, 1:50pm

Okay, using veralite for 3 years, almost always happy. Now facing an issue on a frequent restart (lua I think) every 6 minutes exact. Have been searching the forum for hours and found lots of users facing the same issue. However no solution. The restart isn’t a very big problem but I want to have it solved. What I tried: remove Fibaro’s 3 in 1, remove all plugins, disable all scenes, remove all old plugin files but nothing changes the strange behavior. With everything removed Memory cannot be the problem (also checked top, free etc). Disabled/enabled USB logging no result.
Something runs every 6 minutes (its like a Swiss clock on the second) and causes the issue:

6 02/21/15 14:09:52.432 Device_Variable::m_szValue_set device: 16 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: ActualUsage was: 1 now: 1 #hooks: 0 upnp: 0 skip: 0 v:0xd032c0/NONE duplicate:1 <0x2b2cc680>
4 02/21/15 14:09:57.242 <0x2b2cc680>
1 02/21/15 14:10:16.234 UserData::WriteUserData saved–before move File Size: 29753 save size 29753 <0x2b4cc680>
2 02/21/15 14:10:16.235 UserData::TempLogFileSystemFailure start <0x2b4cc680>
2 02/21/15 14:10:16.259 UserData::TempLogFileSystemFailure 5053
-rw-r–r-- 1 root root 33 Feb 6 18:21 /etc/cmh/HW_Key
-rw-r–r-- 1 root root 32 Feb 6 18:21 /etc/cmh/HW_Key2

Any ideas (except a ticket to support, still waiting for their response for a different question couple of weeks ago :'() ?

wilme2 · February 21, 2015, 5:20pm

Just to eliminate it as the issue, have you tried disabling polling? Might have device that isn’t playing well with a polling request.

guessed · February 21, 2015, 5:49pm

Check how much free space you have left in the filesystem, and run the logread command and check it for errors.

Vreo · February 21, 2015, 7:09pm

[quote=“RichardTSchaefer, post:617, topic:172785”]There are two typical sources of restarts:

Memory limitations
Deadlocks (Something running too often, or taking to long)

I find a better way metric for determining if Vera is short of memory is to look the MEM size % from the top command (for the LuaUPnP program)
This includes memory that it MIGHT use that it currently has not locked down into memory (i.e. has not been paged into the address space).
This includes the stacks for device that have not been active yet. But it also includes “CODE” segments that are paged out of the executable files.
So the number can legally be over 100% without exceeding memory limits. But I find that Vera get very unstable as this approaches and exceeds 100%

My Vera 3 with 150+ devices runs at 86% normally … and occasionally works up and restarts.
My Vera Lite with a handful of devices (20, more than half are plugins) running UI7 is running at 102% and is very unstable.
When I get it down to less than 100% it becomes much more stable …
But this is my test system and I use these other plugins to test my plugins with.

But this is NOT the correct thread for this … so further discussions should start a new THREAD.[/quote]
Maybe that is your problem… Indeed it is mine, I have 198% mem usage of LuaUPnP, and I have a lot of restarts with VeraLite. I am planning to upgrade to a Vera Edge but asking Tech Support to remove the force update flag so I can downgrade it because I don’t like UI7. In the meanwhile, does someone know a way to get this number down?

Regards.

ranneman · February 21, 2015, 7:18pm

@wilme2, Thanks good idea. I tried it but unfortunately the issue remains.

@Guessed, I’ am not good in this. I did the logread and noticed two things (see att.):

It looks like there are several bad blocks (6 times ra_nand_block_checkbad: offs:760000 tag: BAD)
Timing wise the restart is at the moment this command runs: crond: USER root pid 23968 cmd /usr/bin/Rotate_Logs.sh. this runs 20 times

Not sure on how to check filesystem but as mentioned I already removed everything consuming memory (free and top looks ok)

any ideas?

ranneman · February 21, 2015, 7:25pm

@Vreo, I removed anything consuming memory and my TOP overview never looked that clean, for LuaUPnP around 80%. Strange thing is that there is no difference in this restart behaviour,having all scenes and plugins in or everything removed. Looks like every time the command crond: USER root pid 3082 cmd /usr/bin/Rotate_Logs.sh runs the reset happens. And this command seems to run every 6 minutes.

guessed · February 21, 2015, 7:45pm

For the filesystems themselves, you can use “df -k” to tell you what’s what. Some will be read-only and/or 100% full (intentionally) and others might be 100% full (unintentionally)

Here’s mine, for reference, using USB Logging (with Log uploads to MiOS completely disabled):

Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 4608 4608 0 100% /rom tmpfs 63728 896 62832 1% /tmp tmpfs 512 0 512 0% /dev /dev/mtdblock7 11264 2412 8852 21% /overlay overlayfs:/overlay 11264 2412 8852 21% / /dev/sda1 518320 65224 426768 13% /tmp/log/cmh /dev/mtdblock8 4480 4480 0 100% /mios

Log rotation/compression puts a whole bunch of extra load on Vera, esp if you’re not running USB Logging… where you’ve already got a large log in Memory (as a memory filesystem) and then you compress it into that same filesystem before eventually removing it.

If you have BAD Blocks, that can also be a serious issue, and Support is best to get engaged. Think of them as landmines on the disk (Flash) surface, and when you step on one, by trying to write to it, bad/unpredictable things occur.

If you’re lucky, and already running USB Logging, and the bad blocks happen to be there, then you can swap it out for another.

Anyhow, there were indications in your original logs that something wasn’t able to write the user_data.xml files, or to compress them, hence the reason to ask how much free-space you had (in addition to BAD Blocks on the Flash)… either of which can readily trip up Vera.

ranneman · February 21, 2015, 8:41pm

Thanks Guessed. Filesystem seems to be ok. I use USB logging but I also switched it off to check if that made a difference, it didn’t. I will replace the device just to make sure.

[tt]/etc/cmh$ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 4352 4352 0 100% /rom
tmpfs 31240 464 30776 1% /tmp
tmpfs 512 0 512 0% /dev
/dev/mtdblock7 11264 1780 9484 16% /overlay
overlayfs:/overlay 11264 1780 9484 16% /
/dev/sda1 516024 17772 472000 4% /tmp/log/cmh
/dev/mtdblock8 6272 6272 0 100% /mios
[/tt]

ranneman · February 21, 2015, 9:10pm

Replacing the USB stick didn’t solve the issue. Bad blocks remained and every 6 minutes a restart

Vreo · February 21, 2015, 11:15pm

Just an idea, you can change the crontab to make less often the logs rotation, especially if you have USB enables with sufficient storage space (512 MB). I am going to try that my self.

ranneman · February 22, 2015, 5:51pm

I checked crontab and I expect the second line to cause the issue

/$ crontab -l */1 * * * * /usr/bin/Rotate_Logs.sh #Rotate_Logs 06 12 * * * //usr/bin/mios-service-sync_ergy.sh #Sync_Ergy

However when deleting the second line using crontab -e and dd to delete the line the file looks like

/$ crontab -l */1 * * * * /usr/bin/Rotate_Logs.sh #Rotate_Logs

But still the restart occurs every 6 minutes. What am I missing ???

RichardTSchaefer · February 22, 2015, 7:07pm

I do not think this has anything to do with the crontab …

You did however remove the Sync Energy script that runs at 12:06 everyday … probably OK

However the log rotation script which runs EVERY minute is still enabled.

The 6 minute interval I believe is the interval VERA uses to save any changes to state variables in the persistent file user_data.json (in a compressed format).
You appear to have enough room on the USB … so that looks good for logs.
Your root file system seems to have room … that’s where this file is written (overlayfs:/overlay 11264 1780 9484 16% /)

So a few more possibilities:

You do not have enough free memory to compress and write the file.
The device state is corrupted … so when it tries to write it out … the output file is way to large (i.e it’s trying to write a lot of garbage to the disk).
The flash memory (that acts like a disk) has too many errors (bad sectors).

If it’s #1 you can fix this … Whats the output from the command:

free

or the top few lines from the command (control-c to quit):
top

Otherwise you need to contact support.

ranneman · February 22, 2015, 7:33pm

Thanks for your ideas.

I re-installed a backup so now my free is less free

/usr/bin$ free total used free shared buffers Mem: 62480 52132 10348 0 876 Swap: 0 0 0 Total: 62480 52132 10348

It looks like I have 8 bad blocks

Feb 22 19:37:35 MiOS_xxxxxx kern.warn kernel: ra_nand_block_checkbad: offs:760000 tag: BAD Feb 22 19:37:35 MiOS_xxxxx kern.warn kernel: ra_nand_block_checkbad: offs:764000 tag: BAD Feb 22 19:37:35 MiOS_xxxxx kern.warn kernel: ra_nand_block_checkbad: offs:768000 tag: BAD Feb 22 19:37:35 MiOS_xxxxx kern.warn kernel: ra_nand_block_checkbad: offs:76c000 tag: BAD Feb 22 19:37:35 MiOS_xxxxx kern.warn kernel: ra_nand_block_checkbad: offs:770000 tag: BAD Feb 22 19:37:35 MiOS_xxxxx kern.warn kernel: ra_nand_block_checkbad: offs:774000 tag: BAD Feb 22 19:37:35 MiOS_xxxxx kern.warn kernel: ra_nand_block_checkbad: offs:778000 tag: BAD Feb 22 19:37:35 MiOS_xxxxx kern.warn kernel: ra_nand_block_checkbad: offs:77c000 tag: BAD

RichardTSchaefer · February 22, 2015, 8:40pm

I see you have a Vera Lite (I can tell from the size of available memory).

You probably do not have enough memory … you may need to reduce the number of plugins/devices (NON Z-Wave devices).

cybrmage · February 22, 2015, 9:03pm

This is the new behavior of UI7… It updates the user_data and rotates the logs on a schedule… The LuaUPnP engine did NOT crash

The problem is that the output looks very similar to the output of a LuaUPnP crash in UI5…

The key here is that a LuaUPnP crash/recovery will log…

01      02/22/15 13:54:40.143   Mongoose XXX-mg_stop1 0xdc0a70 1 3 <0x77ae7000>
01      02/22/15 13:54:42.143   Mongoose XXX-mg_stop2 0xdc0a70 2 3 <0x77ae7000>
01      02/22/15 13:54:42.143   Mongoose XXX-mg_stop3 0xdc0a70 2 3 <0x77ae7000>
01      02/22/15 13:54:42.144   Mongoose XXX-mg_stop4 0xdc0a70 14367856 3 <0x77ae7000>
03      02/22/15 13:54:42.224   LuaUPNP: ending __LEAK__ this:-593920 start:2134016 to 0x1439000 <0x77ae7000>


2015-02-22 13:54:42 - LuaUPnP Terminated with Exit Code: 0

and

03      02/22/15 13:54:43.805   LuaUPNP: starting bLogUPnP 0 <0x779f1000>
02      02/22/15 13:54:43.888   UserData::LoadUserData previous: 0 from *1.7.961* <0x779f1000>
03      02/22/15 13:54:43.895   UserData::LoadUserData BuildVersion: *1.7.961* SvnVersion: *13646* Model: 35 Sercomm NA301 flush: 0 changed: 0 resync: 1382 syncdevice:0 <0x779f1000>

The lines in the your log

2   02/21/15 14:10:16.235   UserData::TempLogFileSystemFailure start <0x2b4cc680>
2   02/21/15 14:10:16.259   UserData::TempLogFileSystemFailure 5053

are caused by the “Rotate_Logs.sh” script… It forcibly closes the log files so that it can rename/move/archive them… This is also normal behaviour, and happens regardless of where the logs are.

Your posted logs do not have these teltale signs of a LuaUPnP crash… just of the new normal operating procedures.

ranneman · February 22, 2015, 9:35pm

Thanks for clarifying, that explains the behaviour. It was a learning experience which kept me busy this weekend ;D

Vreo · February 23, 2015, 2:15am

How can I check if I have bad sectors in my VeraLite? Can I use fsck and how?

ranneman · February 23, 2015, 6:00pm

You can ssh to your vera and the command logread. SSH see this [url=http://wiki.micasaverde.com/index.php/Logon_Vera_SSH]http://wiki.micasaverde.com/index.php/Logon_Vera_SSH[/url]

ranneman · February 23, 2015, 6:07pm

What kind of restart is it I see in this code? As it seems to be normal to happen every 6 minutes and lasts for 11 seconds it can disturb normal processes I supose.

[code]
01 02/23/15 02 02/23/15 02 02/23/15 -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root -rw-r–r-- 1 root 19:03:32.279 UserData::WriteUserData saved–before move File Size: 41733 save size 41733 LEAK this:253952 start:2052096 to 0x15bc000 <0x2b68a680>
19:03:32.279 UserData::TempLogFileSystemFailure start <0x2b68a680>
19:03:32.305 UserData::TempLogFileSystemFailure 4898
root 33 Feb 6 18:21 /etc/cmh/HW_Key
root 32 Feb 6 18:21 /etc/cmh/HW_Key2
root 9 Feb 6 18:21 /etc/cmh/PK_AccessPoint
root 7 Feb 22 18:24 /etc/cmh/PK_Account
root 4707 Feb 23 18:56 /etc/cmh/alerts.json
root 412 Feb 23 06:31 /etc/cmh/cmh.conf
root 0 Jan 27 2012 /etc/cmh/devices
root 16383 Feb 22 12:08 /etc/cmh/dongle.3.20.dump.0
root 16383 Feb 22 11:17 /etc/cmh/dongle.3.20.dump.1
root 16383 Feb 10 22:12 /etc/cmh/dongle.3.20.dump.2
root 16383 Feb 8 16:44 /etc/cmh/dongle.3.20.dump.3
root 16383 Feb 8 15:16 /etc/cmh/dongle.dump
root 227 Feb 22 18:19 /etc/cmh/ergy.conf
root 41 Mar 20 2012 /etc/cmh/ergy_key
root 0 Jan 27 2012 /etc/cmh/first_boot
root 0 Dec 17 2012 /etc/cmh/fresh_install
root 48 Mar 20 2012 /etc/cmh/keys
root 3 Feb 4 09:10 /etc/cmh/language
root 2 Feb 4 09:10 /etc/cmh/language_id
root 10 Feb 23 18:20 /etc/cmh/last_backup
root 11 Feb 22 12:06 /etc/cmh/last_report
root 14085 Jan 23 15:12 /etc/cmh/network_pnp.lua
root 15971 Jan 23 15:12 /etc/cmh/network_pnp_sys.xml
root 12 Feb 4 09:10 /etc/cmh/platform
root 458 Jan 23 15:12 /etc/cmh/ra_key
root 10 Jul 26 2014 /etc/cmh/reupgraded.firmware
root 539 Feb 23 02:16 /etc/cmh/route.data
root 0 Feb 4 09:10 /etc/cmh/scenarios
root 1976 Feb 22 16:26 /etc/cmh/servers.conf
root 1464 Feb 4 09:10 /etc/cmh/servers.conf.default
root 20 Feb 22 18:20 /etc/cmh/servers.conf.timestamp
root 1431 Feb 22 18:25 /etc/cmh/services.conf
root 20 Feb 8 15:50 /etc/cmh/sync_kit
root 20 Feb 8 15:50 /etc/cmh/sync_rediscover
root 2 Feb 4 09:10 /etc/cmh/ui
root 2 Feb 4 09:10 /etc/cmh/ui_man
root 5 Feb 4 09:10 /etc/cmh/ui_skin
root 504 Jul 14 2011 /etc/cmh/user_data.json.luup.lzo
root 41798 Feb 23 18:57 /etc/cmh/user_data.json.lzo
root 41685 Feb 23 18:51 /etc/cmh/user_data.json.lzo.1
root 41779 Feb 23 18:45 /etc/cmh/user_data.json.lzo.2
root 41667 Feb 23 18:39 /etc/cmh/user_data.json.lzo.3
root 41712 Feb 23 18:33 /etc/cmh/user_data.json.lzo.4
root 41649 Feb 23 18:27 /etc/cmh/user_data.json.lzo.5
root 41733 Feb 23 19:03 /etc/cmh/user_data.json.lzo.new
root 19 Feb 22 18:25 /etc/cmh/users.conf
root 20 Feb 22 18:25 /etc/cmh/users.conf.timestamp
root 1 Feb 4 09:10 /etc/cmh/vera_model
root 8 Feb 4 09:10 /etc/cmh/version
root 8 Feb 22 18:19 /etc/cmh/version_latest
root 8 Feb 23 06:33 /etc/cmh/zwave_house_id
root 27 Feb 22 10:11 /etc/cmh/zwave_house_id.history
root 3 Feb 6 18:21 /etc/cmh/zwave_locale
root 74874 Jan 23 15:12 /etc/cmh/zwave_products_sys.xml
root 48 Feb 23 06:33 /etc/cmh/zwave_version

/etc/cmh/orig:
-rw-r–r-- 1 root root 0 Feb 4 09:10 devices
-rw-r–r-- 1 root root 0 Feb 4 09:10 first_boot
-rw-r–r-- 1 root root 0 Feb 4 09:10 fresh_install
-rw-r–r-- 1 root root 0 Feb 4 09:10 scenarios
-rw-r–r-- 1 root root 526 Feb 4 09:10 user_data.json.lzo

/etc/cmh/persist:

/etc/cmh/wan_failover:
-rw-r–r-- 1 root root 44 Jan 23 15:12 check_internet.hosts
LEAK this:20480 start:2072576 to 0x15c1000 <0x2b68a680>
02 02/23/15 19:03:32.398 UserData::TempLogFileSystemFailure start <0x2b68a680>
02 02/23/15 19:03:32.425 UserData::TempLogFileSystemFailure 4809
-rw-r–r-- 1 root root 33 Feb 6 18:21 /etc/cmh/HW_Key
-rw-r–r-- 1 root root 32 Feb 6 18:21 /etc/cmh/HW_Key2
-rw-r–r-- 1 root root 9 Feb 6 18:21 /etc/cmh/PK_AccessPoint
-rw-r–r-- 1 root root 7 Feb 22 18:24 /etc/cmh/PK_Account
-rw-r–r-- 1 root root 4707 Feb 23 18:56 /etc/cmh/alerts.json
-rw-r–r-- 1 root root 412 Feb 23 06:31 /etc/cmh/cmh.conf
-rw-r–r-- 1 root root 0 Jan 27 2012 /etc/cmh/devices
-rw-r–r-- 1 root root 16383 Feb 22 12:08 /etc/cmh/dongle.3.20.dump.0
-rw-r–r-- 1 root root 16383 Feb 22 11:17 /etc/cmh/dongle.3.20.dump.1
-rw-r–r-- 1 root root 16383 Feb 10 22:12 /etc/cmh/dongle.3.20.dump.2
-rw-r–r-- 1 root root 16383 Feb 8 16:44 /etc/cmh/dongle.3.20.dump.3
-rw-r–r-- 1 root root 16383 Feb 8 15:16 /etc/cmh/dongle.dump
-rw-r–r-- 1 root root 227 Feb 22 18:19 /etc/cmh/ergy.conf
-rw-r–r-- 1 root root 41 Mar 20 2012 /etc/cmh/ergy_key
-rw-r–r-- 1 root root 0 Jan 27 2012 /etc/cmh/first_boot
-rw-r–r-- 1 root root 0 Dec 17 2012 /etc/cmh/fresh_install
-rw-r–r-- 1 root root 48 Mar 20 2012 /etc/cmh/keys
-rw-r–r-- 1 root root 3 Feb 4 09:10 /etc/cmh/language
-rw-r–r-- 1 root root 2 Feb 4 09:10 /etc/cmh/language_id
-rw-r–r-- 1 root root 10 Feb 23 18:20 /etc/cmh/last_backup
-rw-r–r-- 1 root root 11 Feb 22 12:06 /etc/cmh/last_report
-rw-r–r-- 1 root root 14085 Jan 23 15:12 /etc/cmh/network_pnp.lua
-rw-r–r-- 1 root root 15971 Jan 23 15:12 /etc/cmh/network_pnp_sys.xml
-rw-r–r-- 1 root root 12 Feb 4 09:10 /etc/cmh/platform
-rw-r–r-- 1 root root 458 Jan 23 15:12 /etc/cmh/ra_key
-rw-r–r-- 1 root root 10 Jul 26 2014 /etc/cmh/reupgraded.firmware
-rw-r–r-- 1 root root 539 Feb 23 02:16 /etc/cmh/route.data
-rw-r–r-- 1 root root 0 Feb 4 09:10 /etc/cmh/scenarios
-rw-r–r-- 1 root root 1976 Feb 22 16:26 /etc/cmh/servers.conf
-rw-r–r-- 1 root root 1464 Feb 4 09:10 /etc/cmh/servers.conf.default
-rw-r–r-- 1 root root 20 Feb 22 18:20 /etc/cmh/servers.conf.timestamp
-rw-r–r-- 1 root root 1431 Feb 22 18:25 /etc/cmh/services.conf
-rw-r–r-- 1 root root 20 Feb 8 15:50 /etc/cmh/sync_kit
-rw-r–r-- 1 root root 20 Feb 8 15:50 /etc/cmh/sync_rediscover
-rw-r–r-- 1 root root 2 Feb 4 09:10 /etc/cmh/ui
-rw-r–r-- 1 root root 2 Feb 4 09:10 /etc/cmh/ui_man
-rw-r–r-- 1 root root 5 Feb 4 09:10 /etc/cmh/ui_skin
-rw-r–r-- 1 root root 504 Jul 14 2011 /etc/cmh/user_data.json.luup.lzo
-rw-r–r-- 1 root root 41733 Feb 23 19:03 /etc/cmh/user_data.json.lzo
-rw-r–r-- 1 root root 41798 Feb 23 18:57 /etc/cmh/user_data.json.lzo.1
-rw-r–r-- 1 root root 41685 Feb 23 18:51 /etc/cmh/user_data.json.lzo.2
-rw-r–r-- 1 root root 41779 Feb 23 18:45 /etc/cmh/user_data.json.lzo.3
-rw-r–r-- 1 root root 41667 Feb 23 18:39 /etc/cmh/user_data.json.lzo.4
-rw-r–r-- 1 root root 41712 Feb 23 18:33 /etc/cmh/user_data.json.lzo.5
-rw-r–r-- 1 root root 19 Feb 22 18:25 /etc/cmh/users.conf
-rw-r–r-- 1 root root 20 Feb 22 18:25 /etc/cmh/users.conf.timestamp
-rw-r–r-- 1 root root 1 Feb 4 09:10 /etc/cmh/vera_model
-rw-r–r-- 1 root root 8 Feb 4 09:10 /etc/cmh/version
-rw-r–r-- 1 root root 8 Feb 22 18:19 /etc/cmh/version_latest
-rw-r–r-- 1 root root 8 Feb 23 06:33 /etc/cmh/zwave_house_id
-rw-r–r-- 1 root root 27 Feb 22 10:11 /etc/cmh/zwave_house_id.history
-rw-r–r-- 1 root root 3 Feb 6 18:21 /etc/cmh/zwave_locale
-rw-r–r-- 1 root root 74874 Jan 23 15:12 /etc/cmh/zwave_products_sys.xml
-rw-r–r-- 1 root root 48 Feb 23 06:33 /etc/cmh/zwave_version

/etc/cmh/orig:
-rw-r–r-- 1 root root 0 Feb 4 09:10 devices
-rw-r–r-- 1 root root 0 Feb 4 09:10 first_boot
-rw-r–r-- 1 root root 0 Feb 4 09:10 fresh_install
-rw-r–r-- 1 root root 0 Feb 4 09:10 scenarios
-rw-r–r-- 1 root root 526 Feb 4 09:10 user_data.json.lzo

/etc/cmh/persist:

/etc/cmh/wan_failover:
-rw-r–r-- 1 root root 44 Jan 23 15:12 check_internet.hosts
<0x2b68a680>
06 02/23/15 19:03:43.131 Device_Variable::m_szValue_set device: 16 service: urn:micasaverde-com:serviceId:EnergyMetering1 variable: Watts was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0xf7f468/NONE duplicate:1 LEAK this:-274432 start:1798144 to 0x157e000 <0x2b88a680>
06 02/23/15 19:03:43.132 Device_Variable::m_szValue_set device: 16 service: [/code]

Vreo · February 23, 2015, 11:11pm

[quote=“ranneman, post:18, topic:186081”]You can ssh to your vera and the command logread. SSH see this [url=http://wiki.micasaverde.com/index.php/Logon_Vera_SSH]http://wiki.micasaverde.com/index.php/Logon_Vera_SSH[/url][/quote]Thanx! And is there a way to fix bad sectors? I have three…