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
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
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
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
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 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
Organizing/ structuring rule sets and rules
R
Hi guys, Just wondering how you guys organize your rule sets and rules. I wish I had an extra layer to have some more granularity, but my feature request was not popular. Maybe there are better ways to organize my rule sets. I use the rule sets now primarily for rooms. So a rule set per room. But maybe grouping by functionality works better. Any examples/ suggestions would be appreciated.
Multi-System Reactor
Moving MSR from a QNAP container to RP 5 - some issues
Tom_DT
Topic thumbnail image
Multi-System Reactor
Widget deletion does not work and landing page (status) is empy
M
Topic thumbnail image
Multi-System Reactor
Need help reducing false positive notifications
T
Topic thumbnail image
Multi-System Reactor
Deleting widgets
tunnusT
Hopefully a trivial question, but how do you delete widgets in a status page? Using build 22266
Multi-System Reactor
MQTT configuration question
tunnusT
I have the following yaml configuration in local_mqtt_devices file x_mqtt_device: set_speed: arguments: speed: type: str topic: "command/%friendly_name%" payload: type: json expr: '{ "fan": parameters.speed }' While this works fine, I'm wondering how this could be changed to "fixed" parameters, as in this case "fan" only accepts "A", "Q" or a numeric value of 1-5?
Multi-System Reactor

Post-DST and MSR not reflecting local time

Scheduled Pinned Locked Moved Multi-System Reactor
18 Posts 4 Posters 3.2k 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

    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.1.177
    *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

    *HASS 2025.6.0
    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.1.177
      *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

      *HASS 2025.6.0
      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.1.177
          *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

          *HASS 2025.6.0
          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.1.177
                *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                *HASS 2025.6.0
                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.1.177
                    *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                    *HASS 2025.6.0
                    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.1.177
                        *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                        *HASS 2025.6.0
                        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.1.177
                            *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                            *HASS 2025.6.0
                            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

                            • Gradually turn on lights.
                              G
                              gwp1
                              0
                              4
                              134

                            • Stop the MSR by an external switch on Hubitat.
                              wmarcolinW
                              wmarcolin
                              0
                              1
                              33

                            • Error After Upgrade
                              G
                              gwp1
                              0
                              4
                              104

                            • Reset attribute value of entity in event handler
                              R
                              RHCPNG
                              0
                              5
                              203

                            • Need help figuring out how to delay a reset on reaction
                              G
                              gwp1
                              0
                              22
                              927

                            • Way to search for rules (rule state) in other rules
                              T
                              tamorgen
                              0
                              3
                              100

                            • Links to MSR from HA
                              Tom_DT
                              Tom_D
                              0
                              1
                              91

                            • Set Reaction > Script Action
                              wmarcolinW
                              wmarcolin
                              0
                              11
                              436

                            • Wiring Samotech SM308-S into light fitting
                              akbooerA
                              akbooer
                              0
                              2
                              149

                            • Errors after updating to MQTTController build 25139
                              toggledbitsT
                              toggledbits
                              0
                              6
                              238

                            • 🎉 My very first MSR controller: OpenSprinkler
                              therealdbT
                              therealdb
                              5
                              13
                              918

                            • Advice reqeusted to migrate MSR from Bare Metal to Container
                              T
                              tamorgen
                              0
                              5
                              261
                            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