Logon screen timeout

[cw-kid]

@rafale77

Hi, well I bought the HP T520 Thin Client because of what you said to me previously. It was cheap enough from eBay.

I had some issues with the power supply however as it didn't come with one.
I did have a spare suitably spec'd laptop power supply, but it had the wrong DC connector plug on the end of it.

So I ordered the correct "DC Tip 7.4x5.0mm Power Plug Socket Connector" off eBay and cut the other one off and soldered the new one on.

However the HP Thin Client was not turning on, no power nothing at all and totally dead.

I then read that you have to use a genuine HP power supply, as they have some kind of checking so that the thin clients won't power on if you are using a 3rd party power supply.

Corporate Greed !

I then found an article about hacking the unit and soldering in a 240K resister on the back of the power input jack and I did this today and amazingly it worked and the thin client powered on.

One thing I can't figure out how to do yet is to update the BIOS without having one of their supported OS installed.

[rafale77]

@cw-kid

I don't have this exact model but... my HP desktops all have the ability to update the BIOS from within the UEFI BIOS. Have you tried that? Sorry for the song and dance on the power supply. I never encountered this since I always got power bricks with the ones I bought and I actually have spare power supplies... Great soldering job though!

[cw-kid]

@rafale77

There is an option in the BIOS menu to update / flash the BIOS but when I click OK on it, it says:

"Can not find bios update interface"

I've not really looked in to it properly yet as I was keen to get MSR up and running first.

From the quick Google searches I did, most suggested you need to have one of the HP supported operating systems installed to be able to update the BIOS.

But there must be some work around some how. I need to read in to it more.

[cw-kid]

@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:

[cw-kid]

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.

[cw-kid]

A scheduled rule set just ran actually and turned on the RGBW light strip in the kitchen, so think it's working now.

[toggledbits]

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

[cw-kid]

@toggledbits said in Issues installing MSR on Debian 10 Linux:

http://your-msr-host-ip:8111/diag/sun

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.

@rafale77

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.

[rafale77]

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.

[toggledbits]

I use scp just to copy the config and storage 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 and apt-get update my way back to current, that's fast enough on recovery.