Reactor backup.
OK. Send me your Reactor backup file to the address listed in step 5 of the troubleshooting instructions on the Tools page of any ReactorSensor.
Also, please check the available disk space on your unit.
Backup sent.
I’ve never checked available disk space, and at a loss on how to do that. Sorry to say, couldn’t find anything helpful online either other than install ALTUI and run a command, which if avoidable id prefer not do do.
Tried using WinSCP > Session > Server and protocol information > space available, but that one tab was greyed out.
Install putty and make an ssh connection. Then execute
df -h
HTH
C
Log in via SSH, and do the following (copy-paste):
cd /etc/cmh
df -kh .
cd /etc/cmh-ludl
df -kh .
cat /etc/cmh/version
Copy-paste that output and post it here.
ok thanks.
What’s the -k switch, chap?
Also surely df will return the same no matter what folder you are in?
As ever, just curious
C
df -kh . will report disk utilization in human-readable form (h) with kilobyte units (k) for the current directory’s (.) mount point. That helps focus on the specific volume that matters when you are looking at the capacity for a specific purpose. In this case, there are really only two volumes that are relevant: the volume on which user_data.json lives (where /etc/cmh is) and that on which the plugin is installed.
1 Like
Yeah, man(ed) the -k.
When executed on my box the -k or folder location made no difference to the output but (natch) YMMV 
C
On some systems, -k is the default. I just always include it, because of habit from working across so many systems. Here’s the difference between with and without the “.” though, which is the important bit:
root@MiOS_5002XXXX:/etc/cmh# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 10880 3684 7196 34% /
/dev/root 8192 8192 0 100% /rom
tmpfs 127328 4228 123100 3% /tmp
/dev/mtdblock6 10880 3684 7196 34% /overlay
overlayfs:/overlay 10880 3684 7196 34% /
tmpfs 512 0 512 0% /dev
/dev/mtdblock10 51200 41624 9576 81% /storage
/dev/mtdblock10 51200 41624 9576 81% /etc/cmh-firmware
/dev/mtdblock10 51200 41624 9576 81% /etc/cmh-backup
/dev/mtdblock9 9984 9984 0 100% /mios
/dev/mtdblock10 51200 41624 9576 81% /etc/cmh-ludl
/dev/mtdblock11 19712 1272 18440 6% /ezmi
/dev/mtdblock11 19712 1272 18440 6% /etc/cmh
root@MiOS_5002XXXX:/etc/cmh# pwd
/etc/cmh
root@MiOS_5002XXXX:/etc/cmh# df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mtdblock11 19712 1272 18440 6% /ezmi
root@MiOS_5002XXXX:/etc/cmh#
1 Like
root@MiOS_4504xxxx:~# cd /etc/cmh
root@MiOS_4504xxxx:/etc/cmh# df -kh .
Filesystem Size Used Available Use% Mounted on
rootfs 9.4M 7.0M 2.4M 75% /
root@MiOS_4504xxxx:/etc/cmh# cd /etc/cmh-ludl
root@MiOS_4504xxxx:/etc/cmh-ludl# df -kh .
Filesystem Size Used Available Use% Mounted on
rootfs 9.4M 7.0M 2.4M 75% /
root@MiOS_4504xxxx:/etc/cmh-ludl# cat /etc/cmh/version
1.7.4969
root@MiOS_4504xxxx:/etc/cmh-ludl#
OK, one more…
ls -l /etc/cmh/user_data.json.lzo
root@MiOS_4504xxxx:~# ls -l /etc/cmh/user_data.json.lzo
-rw-r--r-- 1 root root 123109 May 24 17:41 /etc/cmh/user_data.json.lzo
OK, so here’s what I suspect…
Reactor is very defensive about the saved configuration. It will not “fall back” the default “comment only” configuration except in exactly one circumstance: when the configuration state variable is completely and totally empty. Anything else, valid or not, it tries to parse, and if it’s not parseable, it will throw a runtime error and stop the ReactorSensor, but it will will not ever overwrite that configuration. The UI is even more defensive: if the configuration isn’t valid (including blank), it just throws an error.
So the only way you could be getting the result you are getting, that “comment only” configuration typical of a new ReactorSensor, is if Luup is returning blank or nil when Reactor asks for the configuration variable’s contents.
Since they didn’t do the useful repartitioning on the Edge that they did for Plus and Secure on 7.30/31, I suspect you are running out of disk space when Luup is trying to save the very large config you have–keep in mind it has to rewrite the entire contents of user_data to save that one variable (any variable); it does not/can not write only a portion. On Edge, you still have your system configuration and plugin files on the same volume, and it’s not a very large volume as well.
I would first try cleaning out some space from /etc/cmh-ludl/. I would go in there and make sure there are no left-over plugin files for plugins you’ve uninstalled. If there are plugins installed that you no longer need, remove them, and then go remove their files (Luup does not remove plugin files when you uninstall a plugin). If you accidentally delete a file for an installed plugin, it likely will not be a problem, as Luup catches missing files and makes an attempt to redownload them, but be careful nonetheless, as some plugins make files on-the-fly and that could lead to issues. You can likely start by getting rid of any files of the pattern reactor-devNNN-config-vYYYYY-backup.json, as these are just backup files of old configs made when upgrading from one Reactor version to another when the config format changes. Just make sure you do not delete the Reactor backup file reactor-config-backup.json.lzo. Look for log files that various plugins (including Reactor) may be writing there and bin 'em. Try to get as much more space as you can. After that, reload Luup, and see if you can restore that ReactorSensor backup.
1 Like
Ok thanks, I’ll give this a shot this evening.
Did as you suggested and got back some memory. I have restored the sensor and will monitor.
A few questions:
- Would it be more stable to split up the large reactor sensor in question?
- I must have 20+ backups of the vera configuration, can I delete those or anything else as well? If yes, which folder do they reside?
- Are there any preventative measures that can be taken to address the whopping 10mb?
- I have noticed that sometimes lights do not react to motion sensors quickly (10-20 seconds), which also use reactor sensors. Is this related to the issue which caused this problem (low memory)?
root@MiOS_450xxxxx:/etc/cmh# df -kh .
Filesystem Size Used Available Use% Mounted on
rootfs 9.4M 6.1M 3.3M 65% /
root@MiOS_450xxxxx:/etc/cmh# cd /etc/cmh-ludl
root@MiOS_450xxxxx:/etc/cmh-ludl# df -kh .
Filesystem Size Used Available Use% Mounted on
rootfs 9.4M 6.1M 3.3M 65% /
Not likely. If the space constraint is really the issue, you’re going to have a tough time working around that on the Edge, as it continues to use the old partitioning scheme. And if this is the issue, you’ll hit it again with something else; Reactor just happened to be what you were playing with and noticed, but in all likelihood, other states were being modified and not saved as well, you just didn’t notice. The RS itself isn’t very large; it’s fine.
If they are sitting on the Vera (which would be odd), then yes. If you just have them sitting in the Downloads folder on your PC, that has no bearing to available space on the Vera.
Just monitor it. Unfortunately it’s about all you can do. Make sure you keep the volume as clean as possible by policing uninstalled plugins, etc. There other posts about recovering space from excess alerts, ergy, etc., which is something you should look into.
Possibly, or just the system being busy polling, especially if you have any secure devices–the interaction with those takes a lot longer, and in my experience also tends to be fragile and a good source of “got CAN” messages. But so are many non-secure battery-powered devices. That specific delay time you mention is in the range of Vera’s “got CAN” response blindness, so it’s a bit suspicious. Perusing your logs around the time of the expected motion event is often telling. Also, some “pet immume” motion sensors are pet immune by dampening their response in various tricky ways, among these being a larger number of beam zones needing to be crossed within a wider period of time, or delays looking for repeated hits within the same small number of beams.
Ok thanks.
I haven’t stored them there. I thought Vera may do it by default.
Just an update on this, 2 days and so far so good!
Thanks again!
1 Like
Scary, though, isn’t it? I wish they would have repartitioned for Edge like they did for Plus/Secure. I would say maybe in 7.32, but at this point, I have to say I doubt there will be a 7.32 (my guess/opinion only).
1 Like