Set Reaction > Script Action

[gwp1]

This system has been running flawlessly year after year for the time changes twice a year literally since MSR came out so I was caught off-guard when this happened this morning.

Time in MSR browser is EST, time on RPi is local time (DST).

• I've rebooted the RPi
• I've restarted MSR after double-checking the time on the RPi.
• Used a completely different browser to eliminate any caching concerns.
• Double-checked MSR reactor.yaml

What am I missing here @toggledbits ?

[gwp1]

Poking at things just because, doing a .../diag/sun and it shows me:

The host time is 3/10/2024, 8:04:48 AM offset -300 minutes from UTC (TZ=undefined; location (lat,lon) 32.94707,-80.01374 elev 0m; sunrise 3/10/2024, 6:37:23 AM, sunset 3/10/2024, 6:25:28 PM.

This is not what the RPi is showing as host time, it's an hour off - but if I go to CLI and do a simple date I get:

... which is correct.

I also noticed suninfo.dst is still showing as false

[gwp1]

Reviewing troubleshooting:

• Host time is verified correct
• Browser time is verified correct (hard reset done anyway)
• Local config is correct in reactor.yaml
• Test time is not active (has been commented out since 2022's last use
• MSR does not match RPi's host time, it is an hour behind as though it's literally not "seeing"/able to access the host time.

[dze]

Seeing the same issue here.

Verified host time against other systems.
Checked Local time,
MSR is 1 hour behind,
Verified TZ settings .

Hubitat C-7 2.3.8.125
Home Assistant 2024.3.0 running ZST10-700 fw 7.18.3
MSR on RPi4 bare metal Model B 2GBs, SSD
MSR latest-24057-e9add9f5
MQTTController-24050
ZWave Controller-23326

[Tom_D]

MSR is running in a QNAP container. The server time is correct.

[gwp1]

Interestingly, since the docs (yes, I read them) said to double-check to ensure test_time wasn't enabled - which it wasn't.

Then I had the brainstorm of "what if I use the test_time functionality to at least get me on the right time until a solution is found"?

So I set the test_time in reactor.yaml

Restarted Reactor

And viola... it'll get me thru for now.

[gwp1]

Ok, this just got weirder. I edited a rule at 15:50 EDT still under test_time as shown above.

The rule shows the SET time as

Then I turned OFF test_time and refreshed the same rule.

That reflects the real time... but the clock display now shows me an hour off again, MSR being back on EST.

Yes, the browser is being refreshed after each change is implemented.

UPDATE: looking back at some rules from the day, I see this rule was scheduled for 07:30 EDT but fired at 08:30 EDT. The display shows the REAL time but the action happened an hour late (ie, the time displayed for host time).

It would appear rules are firing from the displayed host time (the incorrect EST time) but being logged as the correct time, EDT.

[toggledbits]

@gwp1 said in Post-DST and MSR not reflecting local time:

doing a .../diag/sun and it shows me:

The host time is 3/10/2024, 8:04:48 AM offset -300 minutes from UTC (TZ=undefined;

Try setting TZ. If using systemctl, do it in the systemctl configuration for Reactor.

No startup logs? No nodejs version info?

Traveling, have limited access.

[gwp1]

@toggledbits according to a screenshot in the first post, the RPi does have a default timezone. It's America/New York.

NodeJS v18.18.2

Pleading ignorance here for "If using systemctl do it in the systemctl configuration for Reactor. Not sure what you mean by that.

I've restarted Reactor and pulled two log files. I'll put them in the Dropbox.

[toggledbits]

@gwp1 set tz in your environment for nodejs

[Tom_D]

@Tom_D Spelling Los_Angeles properly solved my time issue. Thanks.

[gwp1]

@toggledbits So this is new territory for me. What appears to have resolved this is the addition to app.js of this line at the top:

process.env.TZ = "America/New_York";

I placed it here:

/** Copyright (C) 2020-2023 Kedron Holdings LLC, All Rights Reserved. This file is part of Reactor.
 *  For info and license terms please see https://reactor.toggledbits.com/
 *  ------------------------------------------------------------------------------
*/
process.env.TZ = "America/New_York";
const a0_0x2a8642 = a0_0x2074;

[toggledbits]

@gwp1 said in Post-DST and MSR not reflecting local time:

So this is new territory for me.

OK. I'm back home now and can engage this a little more.

First, what you've done may have worked, but it's not the "right" way and nobody should ever do this in future. I say that only to avoid people going down this path if they happen upon this thread later. This may have worked, but you're going to have to redo it every time you upgrade Reactor, and it's just generally not the OS-approved way to handle it.

To start on the "right" path, we need to begin with a look at your system time setting, which you can see by doing the following (post the output here in reply):

ls -l /etc/localtime

The named path is (or should be) a symbolic link to a timezone data file (typically in /usr/share/zoneinfo). The preferred timezone names these days are continental/regional forms, like America/New_York, not the old EST5EDT form. Using the timedatectl command with no options should show the correct current time, time zone, offset, and NTP status.

If Reactor is still misbehaving, make sure your OS is fully up to date, and all timezone data files have been updated to latest versions. If updates were applied, reboot and repeat the checks in the previous paragraph.

If all that doesn't fix or change it...

THIS APPLIES TO BARE-BONES INSTALLS ONLY. If you're a docker user having time zone or DST issues, see here.

The best way to change it on an RPi is to the raspi-config application. You can also manually symbolically relink the file yourself (i.e. in -sf /usr/share/zoneinfo/whatever/whatever /etc/localtime and then use the ls command again to confirm the result). Reboot the system after changing the time zone. Here's some helpful into for Ubuntu and Debian users on other hardware.

I have never run into a system bare-bones install that requires TZ to be set if the system time zone is set by linking /etc/localtime correctly. Common problems are misspelled time zone names (like apparently @Tom_D ran into). Docker users must set TZ in the container configuration, but should use the same continental/regional forms.

From there, if your nodejs is still not providing proper time to Reactor, you have some other misconfiguration or possibly nodejs bug (although I see no issues on 18 or 20) that I'm not going to spend time digging for -- you can set TZ for the Reactor process to work around it, but we need to know how you are starting up Reactor. If you used my RPi install script (from the reactor/tools directory), then you are using systemctl, because that's what the script sets up. To set TZ in the configuration for systemctl, do the following as root:

1. Open /etc/systemd/system/reactor.service in your favorite editor (nano, vi, etc.)

2. Find the line beginning Environment

3. Insert the following additional line after that (change the timezone specifier as needed for your locale):

    Environment=TZ=America/New_York
   

   You should now have two lines that begin with Environment -- one for NODE_PATH and one for TZ.

4. Save the modified file.

5. Run systemctl daemon-reload to reload the modified config file.

6. Run systemctl restart reactor to restart the Reactor service.

That should address the timezone configuration when running Reactor with systemctl. If you start Reactor some other way (and again, this applies to bare-bones installs only, not docker), the easiest thing to do is to make the TZ environment variable setting part of the system startup process. Do this (as root) only if not using systemctl to start/run Reactor:

1. Open /etc/profile in your favorite editor;

2. At the bottom, add this line (change the timezone spec to whatever yours is):

    TZ=America/New_York ; export TZ
   

3. Save the file.

4. Reboot the system.

5. Log in and confirm the environment setting by doing echo $TZ

[gwp1]

@toggledbits I left this as unsolved because I was questioning my workaround for the exact reason you state: what about future updates overwriting what I'd done?

Results of

ls -l /etc/local/time

So something is clearly amiss.

Moving on, timedatectl shows what I would expect. This information is correct:

Moving on... I've done this before but stepped thru it again just to be sure.

sudo raspi-config

Rebooted.

Alas, same result for

ls -l /etc/local/time

Moving on...

In usr/share/zoneinfo I see:

Moving on...

Did in -sf /usr/share/zoneinfo/whatever/whatever /etc/localtime which I think should be ln -sf /usr/share/zoneinfo/whatever/whatever /etc/localtime and rebooted.

Oddly, no change. Went digging into the RPi and realized

ls -l /etc/local/time

should be

ls -l /etc/localtime

The result of that is
...which is what I'd expect and want.

Moving on...

Removed

process.env.TZ = "America/New_York";

from app.js and restarted Reactor. Right back where we started.

Moving on to the reactor.service edit. This resulted in:

A few seconds off which netted me the MSR warning but I'll make sure both sides are properly synced NTP-wise.

Actually, they took care of each other themselves - btt I saved the edits here everything was back to normal.

[toggledbits]

@gwp1 said in Post-DST and MSR not reflecting local time:

Results of

ls -l /etc/local/time

Ugh! That's a typo (one of two) on my part (localtime should be one word without a slash in it). I'll correct the original post, but as you discovered later, it should be:

    ls -l /etc/localtime

Thanks for picking those errors up.

It's pretty unusual to have to set TZ for a systemd process. Again, I think there's some lurking broken config somewhere in the OS. But if setting TZ in the systemd config fixes it, that works.

What OS are you using? Can you post the contents of /etc/issue?

[gwp1]

@toggledbits sorry, let your request slip by me.

etc/issue

OS is

[toggledbits]

OK. I don't have that running in my environment any more. It's EOL in June as well. You may want to plan for an upgrade. Not saying it's related; I've been through plenty of DSTs on Buster when I was using it, without issue. But like everything else, it's in your interest long-term to follow along with the LTS cycles, at least.

[gwp1]

@toggledbits yeah, I just got new hardware and am considering moving to the containerized version. But that's going to take some time as it's tech I've not played with before and my day job + new puppy haven't left much dev hours these months.

MSR is now very integral to the operation of this house so I need to tread carefully when poking the proverbial bear.