Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved
Collapse
Discussion Forum to share and further the development of home control and automation, independent of platforms.
  1. Home
  2. Software
  3. Multi-System Reactor
  4. Post-DST and MSR not reflecting local time
[Reactor] Help with screne controller cycling logic
therealdbT
I’ve added a couple of Shelly Wave i4 as scene controllers and I’m planning to add more, since I can just use standard buttons instead of battery-powered scene controllers, which also looks better aesthetically. That said, I’m struggling to figure out how to write a simple rule that cycles between states every time I press a button. Example: Light 1 ON → OFF, then Light 2 ON → OFF. The part I can’t get right is handling the case where Light 1 or Light 2 might already be ON independently of the rule. Maybe it’s just too much sun and relaxation clouding my brain, but any hint would be appreciated.
Multi-System Reactor
Stop the MSR by an external switch on Hubitat.
wmarcolinW
Use case: When performing home maintenance, such as air conditioning, I want all rules involving air conditioning to be disabled. To do this, to day, I have a virtual switch that I placed within all rules involving air conditioning, meaning that if I turn it off, none of them work. Then another situation: the water pump system and garden irrigation, another switch. In short, I had to create several virtual switches in Hubitat to disable rules in MSR. Unfortunately, however, I was unable to cover all scenarios, so I wondered if it would be possible for MSR to support a virtual MSR switch, which, when configured in the reactor settings, would function as a general on/off switch for MSR. If it is configured and turned off, the entire rules and actions in MSR stops working, except for the status change reading process, specifically for this switch, which, when turned on, would restart the MSR. Would it be possible to do something like this? Any recommendations from the experts?
Multi-System Reactor
[Reactor] Variables not updating correctly in latest-25201-2aa18550
therealdbT
Topic thumbnail image
Multi-System Reactor
Expose MSR entities
CatmanV2C
Probably a really dumb question. Currently I am using the owntracks_sensor for tracking phones being in region in MSR and it works great. Digging around with Home Assistant and toying with some dashboards, is there any way of exposing that sensor to HA trivially? I could set MSR to trip a virtual switch in OpenLuup which can then be exposed to HA (with all my other Vera devices) but that feels a bit in-elegant if I can do it directly. Any thoughts? Apologies if the ask is not clear/ TIA C
Multi-System Reactor
Comment in Globa Expressions
Tom_DT
I have several Global Expressions that are set by a rule so the definition area is blank. I'd like to add a comment in this area that explains what is setting the value. Commenting in this area breaks the remote setting. Any way to document what is setting the GE?
Multi-System Reactor
Unofficial thread for compatibility
tunnusT
As there are statements about compatibility for home assistant versions in MSR new version announcements (e.g. "HassController: Bless Hass to 2025.7.3"), I thought it would be good idea to track other controllers as well. As an example, I can confirm that build "latest-25208-c53e8513" works with Hubitat Elevation C-8 platform version 2.4.2.134 using Maker API.
Multi-System Reactor
Gradually turn on lights.
Tom_DT
I have several lights that I would like to turn on very gradually over 15 or 20 seconds. from 0 to .25 in .01 increments. I have tried a few things that came nowhere near working, so here I am.
Multi-System Reactor
Reactor (Multi-System/Multi-Hub) Announcements
toggledbitsT
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here. Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed.
Multi-System Reactor
Can't customize home page
G
I foolishly let my system wipe all cookies this morning and with it my settings for my MSR home page. Once logged back in I can no longer remove errant panes nor is the + available to add new ones. Brave Browser v1.80.122 (Jul 16, 2025) What have I done?! Will check other browsers on my M1. UPDATE: Safari exhibits same behaviour. I've tried both sans last-four public key entry and with - no change.
Multi-System Reactor
Error After Upgrade
T
Topic thumbnail image
Multi-System Reactor
Reset attribute value of entity in event handler
R
Topic thumbnail image
Multi-System Reactor
Need help figuring out how to delay a reset on reaction
T
Topic thumbnail image
Multi-System Reactor
Way to search for rules (rule state) in other rules
T
@toggledbits, not sure if this is a feature request or I'm using the search tool wrong. You have a "Search for rule" in the Rules Set tab in MSR. It works nicely to find a rule and bring up said rule, but can it/could it be used for as a "where used?" global search? For instance, I have a fairly large set of rules, divided up into 10 different rulesets. There's easily a hundred individual rules, and many of the rules have Rule State triggers, which of course refer to other rules. Amongst my troubleshooting today, I came across what may have been a duplicate or troubleshooting attempt, but I can't tell if it's actually used as a Rule State in another rule without opening each rule that I suspect it may be a part of. Thanks.
Multi-System Reactor
Links to MSR from HA
Tom_DT
I am using Home Assistant a lot recently. On a dashboard showing the devices, I would like to show a link to the MSR rule that controls the devices. Is there a way to link directly into MSR?
Multi-System Reactor
Set Reaction > Script Action
wmarcolinW
Topic thumbnail image
Multi-System Reactor
Errors after updating to MQTTController build 25139
tunnusT
I'm running MSR build 25139 on Docker, using MQTT controller 24293, and everything working as expected. But if I try to upgrade to MQTTController build 25139, I'm getting the following errors on MSR UI: An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.god Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.green Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa filter pump auto off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.red Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa filter pump auto run" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.pump Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa watchdog" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.status Last 11:20:37 My MQTT configuration (local_mqtt_devices.yaml) for the related entity is: layzspa_message: type: ValueSensor capabilities: ["temperature_sensor", "value_sensor", "power_sensor"] primary_attribute: power_sensor.value events: "layzspa/message": "power_sensor.value": json_payload: true if_expr: '! isnull( payload?.PWR )' expr: "float(payload.PWR)" "value_sensor.air": json_payload: true if_expr: '! isnull( payload?.AIR )' expr: "float(payload.AIR)" "value_sensor.pump": json_payload: true if_expr: '! isnull( payload?.FLT )' expr: "float(payload.FLT)" "value_sensor.god": json_payload: true if_expr: '! isnull( payload?.GOD )' expr: "float(payload.GOD)" "value_sensor.lock": json_payload: true if_expr: '! isnull( payload?.LCK )' expr: "float(payload.LCK)" "value_sensor.unit": json_payload: true if_expr: '! isnull( payload?.UNT )' expr: "float(payload.UNT)" "value_sensor.error": json_payload: true if_expr: '! isnull( payload?.ERR )' expr: "float(payload.ERR)" "temperature_sensor.green": json_payload: true if_expr: '! isnull( payload?.GRN )' expr: "float(payload.GRN)" "temperature_sensor.red": json_payload: true if_expr: '! isnull( payload?.RED )' expr: "float(payload.RED)" "temperature_sensor.target": json_payload: true if_expr: '! isnull( payload?.TGT )' expr: "float(payload.TGT)" "temperature_sensor.value": json_payload: true if_expr: '! isnull( payload?.TMP )' expr: "float(payload.TMP)" "temperature_sensor.virtual": json_payload: true if_expr: '! isnull( payload?.VTM )' expr: "round(float(payload.VTM), 1)" "temperature_sensor.ambient": json_payload: true if_expr: '! isnull( payload?.AMB )' expr: "float(payload.AMB)" "layzspa/Status": "value_sensor.status": if_expr: '! isnull( payload )' expr: "payload" "layzspa/button": "value_sensor.button": if_expr: '! isnull( payload )' expr: "payload" and in reactor.yaml I have: "layzspa_states": name: "Lay-Z-Spa States" friendly_name: 'Lay-Z-Spa States' include: layzspa_message I realize my MQTT configuration might be a bit unorthodox, but could there still be something unintentional in the latest MQTTController build? If needed, I can provide detailed logs.
Multi-System Reactor
🎉 My very first MSR controller: OpenSprinkler
therealdbT
Since today is my birthday - and I still pretend to be unconventional - I'm giving away a present to this wonderful community and I'm releasing my first OpenSprinkler controller for MSR. It was real fun to code it - and while it's still WIP, it seems to work OK for me. It's polling-based at the moment, but I'll add support for updates via MQTT very soon (it's already partially coded). Get it at (install is similar to MQTTController and such): https://github.com/dbochicchio/reactor-opensprinkler Feel free to try it. It's beta software, but it's stable. I'll update it weekly until all the tasks from my todo list are empty. Since I've learnt a lot from this controller, I'll explore new controllers soon.
Multi-System Reactor
Advice reqeusted to migrate MSR from Bare Metal to Container
T
Good day all, I'm in the process of trying to shut down my 10 year old Linux home server that served many purposes, but primarily it's what I used for my NAS/Plex Media server. I migrated the NAS aspect of the server in November of last year to a true NAS solution (Ubiquti UNAS Pro), which is rack mount and much more efficient than my old tower, which it's only side benefit was heating my home office during the winter. Unfortunately it also means heating my home office during the summer, which were about to be in full swing. I have two things running on this 10 year old server at this point. MSR and pi-hole. I'm running Plex Media Server on Fedora Workstation in Podman on mini PC, which is much more energy efficient than my old tower. My next step is to migrate MSR. I know there are images of MSR out there, and creating it is well documented. I'm going to be using Podman instead of Docker for various reasons, but they work very similar. What I don't know, is what I need to do to migrate my existing Bare Metal installation over to a container. Has anyone done this? Any advice?
Multi-System Reactor
Can´t restart or upgrade/deploy MSR
F
Topic thumbnail image
Multi-System Reactor
[Solved] Limit HA Entity in MSR
wmarcolinW
Topic thumbnail image
Multi-System Reactor

Post-DST and MSR not reflecting local time

Scheduled Pinned Locked Moved Multi-System Reactor
18 Posts 4 Posters 3.3k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G 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:

    00cc5775-2f66-4dff-ae84-b6262bd3c454-image.png

    ... which is correct.

    I also noticed suninfo.dst is still showing as false

    G Offline
    G Offline
    gwp1
    wrote on last edited by
    #3

    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.

    *Hubitat C-7 2.4.2.129
    *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

    *HASS 2025.7.2
    w/ ZST10-700 fw 7.18.3

    *Prod MSR in docker/portainer
    MSR: latest-25139-fbd67abc
    MQTTController: 25139
    ZWave Controller: 25139

    G 1 Reply Last reply
    0
    • dzeD Offline
      dzeD Offline
      dze
      wrote on last edited by
      #4

      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

      Hubitat C-7 2.3.4.127
      Home Assistant 2022.12.1.0
      MSR on RPi4 bare metal Model B 8GBs
      MSR latest-22349-ec1d482b
      MQTTController-22361
      ZWave Controller-22323

      1 Reply Last reply
      0
      • Tom_DT Offline
        Tom_DT Offline
        Tom_D
        wrote on last edited by
        #5

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

        screenshot-192.168.1.193_8080-2024.03.10-12_20_55.jpg

        screenshot-192.168.1.193_8111-2024.03.10-12_25_27.jpg

        latest-25082-3c348de6

        Tom_DT 1 Reply Last reply
        0
        • G 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.
          G Offline
          G Offline
          gwp1
          wrote on last edited by
          #6

          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
          da23f19c-ef79-4153-b82c-ec6b7a01bea6-image.png

          Restarted Reactor
          fc426fbe-33ae-4b71-8299-c90544bdbb07-image.png

          And viola... it'll get me thru for now.
          6219dd70-377b-404e-9cb0-354a3c031bb3-image.png

          *Hubitat C-7 2.4.2.129
          *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

          *HASS 2025.7.2
          w/ ZST10-700 fw 7.18.3

          *Prod MSR in docker/portainer
          MSR: latest-25139-fbd67abc
          MQTTController: 25139
          ZWave Controller: 25139

          G 1 Reply Last reply
          0
          • G 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
            da23f19c-ef79-4153-b82c-ec6b7a01bea6-image.png

            Restarted Reactor
            fc426fbe-33ae-4b71-8299-c90544bdbb07-image.png

            And viola... it'll get me thru for now.
            6219dd70-377b-404e-9cb0-354a3c031bb3-image.png

            G Offline
            G Offline
            gwp1
            wrote on last edited by gwp1
            #7

            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 ea274e36-aaf1-4c08-a569-1327febaf149-image.png

            Then I turned OFF test_time and refreshed the same rule.
            2718ac68-7317-4499-a39f-d6cc78c11ac5-image.png

            That reflects the real time... but the clock display now shows me an hour off again, MSR being back on EST.
            46aab6b4-379b-4c04-a434-def84cf995db-image.png

            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).
            be9c223c-421e-4b3a-9c7d-df1b141d5a79-image.png

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

            *Hubitat C-7 2.4.2.129
            *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

            *HASS 2025.7.2
            w/ ZST10-700 fw 7.18.3

            *Prod MSR in docker/portainer
            MSR: latest-25139-fbd67abc
            MQTTController: 25139
            ZWave Controller: 25139

            1 Reply Last reply
            0
            • G 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:

              00cc5775-2f66-4dff-ae84-b6262bd3c454-image.png

              ... which is correct.

              I also noticed suninfo.dst is still showing as false

              toggledbitsT Offline
              toggledbitsT Offline
              toggledbits
              wrote on last edited by
              #8

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

              Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

              G 1 Reply Last reply
              0
              • toggledbitsT 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.

                G Offline
                G Offline
                gwp1
                wrote on last edited by
                #9

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

                *Hubitat C-7 2.4.2.129
                *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                *HASS 2025.7.2
                w/ ZST10-700 fw 7.18.3

                *Prod MSR in docker/portainer
                MSR: latest-25139-fbd67abc
                MQTTController: 25139
                ZWave Controller: 25139

                toggledbitsT 1 Reply Last reply
                0
                • G 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.

                  toggledbitsT Offline
                  toggledbitsT Offline
                  toggledbits
                  wrote on last edited by
                  #10

                  @gwp1 set tz in your environment for nodejs

                  Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

                  G 1 Reply Last reply
                  0
                  • Tom_DT Tom_D

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

                    screenshot-192.168.1.193_8080-2024.03.10-12_20_55.jpg

                    screenshot-192.168.1.193_8111-2024.03.10-12_25_27.jpg

                    Tom_DT Offline
                    Tom_DT Offline
                    Tom_D
                    wrote on last edited by
                    #11

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

                    latest-25082-3c348de6

                    1 Reply Last reply
                    0
                    • toggledbitsT toggledbits

                      @gwp1 set tz in your environment for nodejs

                      G Offline
                      G Offline
                      gwp1
                      wrote on last edited by
                      #12

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

                      *Hubitat C-7 2.4.2.129
                      *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                      *HASS 2025.7.2
                      w/ ZST10-700 fw 7.18.3

                      *Prod MSR in docker/portainer
                      MSR: latest-25139-fbd67abc
                      MQTTController: 25139
                      ZWave Controller: 25139

                      toggledbitsT 1 Reply Last reply
                      0
                      • G 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;
                        
                        
                        toggledbitsT Offline
                        toggledbitsT Offline
                        toggledbits
                        wrote on last edited by toggledbits
                        #13

                        @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

                        Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

                        G 1 Reply Last reply
                        0
                        • toggledbitsT 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

                          G Offline
                          G Offline
                          gwp1
                          wrote on last edited by gwp1
                          #14

                          @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
                          

                          763084ea-af8c-4812-9d72-e3acbef11109-image.png

                          So something is clearly amiss.

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

                          7176d3e6-fad5-44ca-a423-ef5a99d073d3-image.png

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

                          sudo raspi-config
                          

                          55272d24-289b-44a4-84e3-6000bfc53677-image.png 51216d5c-0d05-47f0-951a-2094243d1a3b-image.png

                          Rebooted.

                          Alas, same result for

                          ls -l /etc/local/time
                          

                          293a4b03-fad6-4600-8bc9-3748de861d61-image.png

                          Moving on...

                          In usr/share/zoneinfo I see:
                          92089872-8855-43b4-bf47-40be2590a4ca-image.png 73beaa87-cf36-416b-930b-7f152b160d85-image.png 50e7ef4e-cdac-40e9-a434-82aafe9ceb8d-image.png 52143380-2467-483c-9226-303b745886a2-image.png

                          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
                          f662743c-5520-441d-8c41-4804a58d6fa4-image.png ...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.
                          5354bebd-2080-404e-a8b9-f2e30494b040-image.png

                          Moving on to the reactor.service edit. This resulted in:
                          0fbe989a-86f2-41d3-aa61-58e45a3960d7-image.png

                          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.
                          7f00f213-47be-4e6a-a571-514ddb352c70-image.png

                          *Hubitat C-7 2.4.2.129
                          *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                          *HASS 2025.7.2
                          w/ ZST10-700 fw 7.18.3

                          *Prod MSR in docker/portainer
                          MSR: latest-25139-fbd67abc
                          MQTTController: 25139
                          ZWave Controller: 25139

                          toggledbitsT 1 Reply Last reply
                          0
                          • G 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
                            

                            763084ea-af8c-4812-9d72-e3acbef11109-image.png

                            So something is clearly amiss.

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

                            7176d3e6-fad5-44ca-a423-ef5a99d073d3-image.png

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

                            sudo raspi-config
                            

                            55272d24-289b-44a4-84e3-6000bfc53677-image.png 51216d5c-0d05-47f0-951a-2094243d1a3b-image.png

                            Rebooted.

                            Alas, same result for

                            ls -l /etc/local/time
                            

                            293a4b03-fad6-4600-8bc9-3748de861d61-image.png

                            Moving on...

                            In usr/share/zoneinfo I see:
                            92089872-8855-43b4-bf47-40be2590a4ca-image.png 73beaa87-cf36-416b-930b-7f152b160d85-image.png 50e7ef4e-cdac-40e9-a434-82aafe9ceb8d-image.png 52143380-2467-483c-9226-303b745886a2-image.png

                            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
                            f662743c-5520-441d-8c41-4804a58d6fa4-image.png ...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.
                            5354bebd-2080-404e-a8b9-f2e30494b040-image.png

                            Moving on to the reactor.service edit. This resulted in:
                            0fbe989a-86f2-41d3-aa61-58e45a3960d7-image.png

                            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.
                            7f00f213-47be-4e6a-a571-514ddb352c70-image.png

                            toggledbitsT Offline
                            toggledbitsT Offline
                            toggledbits
                            wrote on last edited by
                            #15

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

                            Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

                            G 1 Reply Last reply
                            0
                            • toggledbitsT 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?

                              G Offline
                              G Offline
                              gwp1
                              wrote on last edited by gwp1
                              #16

                              @toggledbits sorry, let your request slip by me.

                              etc/issue
                              3eb94abc-d3f8-4479-bc4c-06dad65f07c1-image.png

                              OS is
                              d930ce00-0f43-4741-a8d9-7d21b5256c34-image.png

                              *Hubitat C-7 2.4.2.129
                              *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                              *HASS 2025.7.2
                              w/ ZST10-700 fw 7.18.3

                              *Prod MSR in docker/portainer
                              MSR: latest-25139-fbd67abc
                              MQTTController: 25139
                              ZWave Controller: 25139

                              1 Reply Last reply
                              1
                              • toggledbitsT Offline
                                toggledbitsT Offline
                                toggledbits
                                wrote on last edited by
                                #17

                                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.

                                Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

                                G 1 Reply Last reply
                                0
                                • toggledbitsT 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.

                                  G Offline
                                  G Offline
                                  gwp1
                                  wrote on last edited by
                                  #18

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

                                  *Hubitat C-7 2.4.2.129
                                  *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                                  *HASS 2025.7.2
                                  w/ ZST10-700 fw 7.18.3

                                  *Prod MSR in docker/portainer
                                  MSR: latest-25139-fbd67abc
                                  MQTTController: 25139
                                  ZWave Controller: 25139

                                  1 Reply Last reply
                                  0
                                  • toggledbitsT toggledbits locked this topic on
                                  Reply
                                  • Reply as topic
                                  Log in to reply
                                  • Oldest to Newest
                                  • Newest to Oldest
                                  • Most Votes


                                  Recent Topics

                                  • [Reactor] Help with screne controller cycling logic
                                    therealdbT
                                    therealdb
                                    0
                                    3
                                    44

                                  • Stop the MSR by an external switch on Hubitat.
                                    wmarcolinW
                                    wmarcolin
                                    0
                                    4
                                    170

                                  • [Reactor] Variables not updating correctly in latest-25201-2aa18550
                                    tunnusT
                                    tunnus
                                    0
                                    22
                                    562

                                  • Expose MSR entities
                                    CatmanV2C
                                    CatmanV2
                                    0
                                    11
                                    107

                                  • Comment in Globa Expressions
                                    CrilleC
                                    Crille
                                    1
                                    2
                                    93

                                  • Little Bobby tables...
                                    CatmanV2C
                                    CatmanV2
                                    0
                                    3
                                    101

                                  • Home Assistant Voice TTS is Easy
                                    CatmanV2C
                                    CatmanV2
                                    0
                                    3
                                    151

                                  • Play Audio through Home Assistant Voice Unit
                                    toggledbitsT
                                    toggledbits
                                    1
                                    1
                                    94

                                  • Home Assistant Voice
                                    CatmanV2C
                                    CatmanV2
                                    0
                                    21
                                    727

                                  • Unofficial thread for compatibility
                                    tunnusT
                                    tunnus
                                    2
                                    1
                                    102

                                  • Gradually turn on lights.
                                    toggledbitsT
                                    toggledbits
                                    0
                                    21
                                    966

                                  • Reactor (Multi-System/Multi-Hub) Announcements
                                    toggledbitsT
                                    toggledbits
                                    5
                                    123
                                    56.0k
                                  Powered by NodeBB | Contributors
                                  Hosted freely by 10RUPTiV - Solutions Technologiques | Contact us
                                  • Login

                                  • Don't have an account? Register

                                  • Login or register to search.
                                  • First post
                                    Last post
                                  0
                                  • Categories
                                  • Recent
                                  • Tags
                                  • Popular
                                  • Unsolved