Issues installing MSR on Debian 10 Linux
-
@toggledbits I copied over the storage and config folder contents from the Rpi to the HP Thin Client and then restarted MSR on the thin client.
I did edit the base URL in the Reactor.yaml file.
I've stopped the MSR service on the Rpi so now the thin client is the only one running..
None of my scheduled rulesets based around sunset have run their actions this evening for some reason.
The time shown in the top of the MSR Web GUI is the correct time.
So seems I need to look into this further.
There is another schedule up coming, the garden lights should turn on 20 minutes after sunset, that is in about 20 minutes time from now, so will see if that happens?
EDIT:
These are the before sunset rules that the other rules reference in their triggers.
20 and 40 minutes before sunset, not sure why both say true as of the same time at 20:48pm.
The after sunset 20 minutes rule says:
waiting for 21:21:00
Its now 21:25pm and my garden lights have NOT turned on, so something not right here.
This is the summary card for the rule that turns on the garden lights:
-
Not sure which rule this is, but I am seeing several errors in the log like these:
2021-05-15T19:48:14.906Z <Rule:5:Rule.js:957> Rule#rule-km50yfxo._evaluate() mutex acquired, evaluating 2021-05-15T19:48:14.907Z <Rule:5:Rule.js:961> Rule#rule-km50yfxo update rate is 1/min limit 60/min 2021-05-15T19:48:14.908Z <Rule:5:Rule.js:883> Rule#rule-km50yfxo evaluateExpressions() with 0 expressions 2021-05-15T19:48:14.910Z <Rule:5:Rule.js:973> Rule#rule-km50yfxo._evaluate() trigger state now true (was true) 2021-05-15T19:48:14.911Z <Rule:5:Rule.js:1351> Rule#rule-km50yfxo cond cond5hu03sp timer schedule 1621119600000<16/05/2021, 00:00:00> 2021-05-15T19:48:14.913Z <Rule:5:Rule.js:975> Rule#rule-km50yfxo._evaluate() constraints state false 2021-05-15T19:48:14.913Z <Rule:null> Rule#rule-km50yfxo rule state now false, changed no 2021-05-15T19:48:14.915Z <Rule:CRIT> Error: EACCES: permission denied, open '/home/stuart/reactor/storage/states/cs-rule-km50yfxo.json' Error: EACCES: permission denied, open '/home/stuart/reactor/storage/states/cs-rule-km50yfxo.json' at Object.openSync (fs.js:498:3) at Object.writeFileSync (fs.js:1524:35) at IndividualFileStrategy.saveDataObject (/home/stuart/reactor/server/lib/IndividualFileStrategy.js:137:29) at Container.saveDataObject (/home/stuart/reactor/server/lib/Container.js:94:54) at Data.save (/home/stuart/reactor/server/lib/Data.js:152:49) at Rule._evaluate (/home/stuart/reactor/server/lib/Rule.js:985:365) at runMicrotasks (<anonymous>) at processTicksAndRejections (internal/process/task_queues.js:95:5) at async /home/stuart/reactor/server/lib/Rule.js:940:17
Think something may have gone wrong with copying over the stuff from the Pi.
This is that folder in WinSCP on the HP Thin Client.
I installed MSR as a none root user aka as my own username name. But these rule set files most are saying root as the owner.
I was logged in to WinSCP as root user when I did the copy so maybe that is why.
If I try logging in to WinSCP as my username instead of root and then doing the copy again from the Pi to the Thin Client it doesn't work and I don't seem to have the permissions to do it.
If instead I try to change the group and owner of a file from root to my username I can't do that either:
So I am stuck now and don't know what to do.....
OK I logged back in to WinSCP as root and now I can change all the files their group and owner from root to my own user name. I have done that now for all of them.
So hopefully that fixes the problem? Will have to wait for later schedules to happen later this evening to see.
-
Make sure your system time zone is set to local time. If the default is UTC or something else, all time-based rules will be a mess. The displayed time in the GUI is browser time, not system (host) time.
Fix permissions in your Reactor config and storage with this:
sudo chown -R stuart:stuart config/ storage/
Edit: To see current host time configuration:
http://your-msr-host-ip:8111/diag/sun
-
Make sure your system time zone is set to local time. If the default is UTC or something else, all time-based rules will be a mess. The displayed time in the GUI is browser time, not system (host) time.
Fix permissions in your Reactor config and storage with this:
sudo chown -R stuart:stuart config/ storage/
Edit: To see current host time configuration:
http://your-msr-host-ip:8111/diag/sun
@toggledbits said in Issues installing MSR on Debian 10 Linux:
The host time is currently 16/05/2021, 14:20:58 offset 60 minutes from UTC (TZ=undefined); location (lat,lon) 53.99078,-1.5373 elev 127; sunrise 16/05/2021, 05:01:40, sunset 16/05/2021, 21:03:33. {"sunrise":1621137700000,"sunset":1621195413000,"civdawn":1621134941000,"civdusk":1621198173000,"nautdawn":1621130939000,"nautdusk":1621202174000,"astrodawn":null,"astrodusk":null,"solarnoon":1621166557000,"daylength":16.031,"angle":14.6}
Time looks to be correct, however it says "TZ=undefined".
None of my schedule rules were running last night because of the permissions issue when I copied them from the Pi to the Thin Client.
I fixed that and then they started working again OK.
I've got everything moved over from the Pi now to the new Thin Client, also setup today Node-Red and Java HA-Bridge.
What's the best way to be backing up Debian ?
The SSD is only 16GB so guess I could take a full system snapshot rather than just backing up certain files and folders.
-
Indeed a full system snapshot would be best and easier to recover but short of that, you can always backup the entire folder by running a cron job to copy the reactor folder either to a network drive or to a USB SSD you would have to plug into the T520.
-
I use
scp
just to copy theconfig
andstorage
directories. That's really all you need to from Reactor to get it going on a reinstall, as you've seen.I find file-based backups of entire Linux systems to be perilous, because permissions, links and special files almost always get screwed up somehow, so I never recommend that route. An image backup is better (I use
partclone
to back up used space only, and it's good about the later target system being a different size/geometry than the original/source), but I'll only do that maybe 1-2 times per year. I figure if I can restore an image quickly andapt-get update
my way back to current, that's fast enough on recovery. -
T toggledbits locked this topic on