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. Gradually turn on lights.
Date/time condition
tunnusT
Topic thumbnail image
Multi-System Reactor
Device log?
G
@toggledbits is there a log that will show me what rule is turning on a specific device? I've got a switch that has been kicking on at 2200 ET for several nights now and the reactor.log doesn't have a thing in it that I can see on a device level (it being more rules-based).
Multi-System Reactor
Midnight crossing not working in date/time condition (build 25325)
tunnusT
Topic thumbnail image
Multi-System Reactor
Error: Command timeout
G
at _ClientAPI._commandTimeout (http://192.168.1.100:8111/client/ClientAPI.js:807:179 Seeing this randomly when returning to open browser tab after being away awhile. Once, maybe twice a day. "What did you do to trigger it?" Literally nothing, just walked away and returned and there it was. Actions taken in reasonably close proximity to this particular instance of it popping up: I'd restarted the MSR container in Portainer. I'll try to grab some logs here shortly.
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
[Solved] Local expression in Rule does not evaluate as they used to do
CrilleC
Topic thumbnail image
Multi-System Reactor
Home Assistant 2025.11.2 and latest-25315
CrilleC
Topic thumbnail image
Multi-System Reactor
Notice to Docker + ARM Users (RPi 3/4/5 and others)
toggledbitsT
This post does not apply to users of Intel/AMD-based systems. If you are using a Reactor image tagged latest-amd64 or stable-amd64, then this post does not apply to you. It also does not apply to bare-metal installs; it's for users of docker images on ARM-based systems only (principally Raspberry Pi hosts, but could be others). After January 15, 2026, I will no longer produce the aarch64-tagged docker image for Reactor. The ARM images will be arm64 for 64-bit operating systems, and armv7l for 32-bit operating systems. For those of you running a container from the aarch64 image today, this will be a relatively simple change: you just need to switch the image used for your docker container to a differently-tagged image. If you are using docker-compose, then this is a relatively simple matter of changing the image line in your docker-compose.yaml file and then stopping (docker-compose down) and restarting (docker-compose up -d) your Reactor daemon. But there's a catch... not all of you can safely just switch from the aarch64 image to the arm64 image. And, you can't just trust the output of uname -m, for example, because this exposes the CPU architecture, but not the word size of the OS running on that CPU. For Raspberry Pi systems, the transition to 64-bit operating systems was long (starting in 2016) and not always obvious — although there was a first "official" 64-bit OS for RPis in 2020, it did not become a default recommendation in the Raspberry Pi Imager until 2021, and then that was only the default for Pi 3/4 systems with >4GB RAM; it was 2022 before it was universally recommended for all 64-bit CPUs regardless of RAM size. Depending on when you first imaged your RPi system and what default you may have been offered/chosen, you could today easily have a 64-bit CPU Raspberry Pi running a 32-bit version of the operating system. Upgrades along the way would not change this; changing it to fully 64-bit requires a full reimage of the system. To establish if your OS is 64- or 32-bit, log in to your Pi and run: sudo dpkg-architecture -q DEB_HOST_ARCH. If the response is arm64 or aarch64, then you are running a 64-bit OS and you should use the arm64-tagged image. If it's anything else, you are running a 32-bit OS, and you should use the armv7l-tagged image. pi@rpi4-1:~ $ sudo dpkg-architecture -q DEB_HOST_ARCH armhf pi@rpi4-1:~ $ uname -m aarch64 pi@rpi4-1:~ $ In the example above, the uname command reports that the CPU is 64-bit architecture (aarch64), which is true for the host on which I ran these commands, but the DEB_HOST_ARCH value is armhf, indicating a 32-bit operating system. This system has to use the armv7l-tagged image. Other systems will have their own ways of determining the word size of the running OS. Since the majority of Reactor users running ARM systems are on Raspberry Pis, I am able to supply the above instructions, but if you happen to have a different ARM system, you'll need to do some web searching to figure out how to expose that information. Or, you can just try the arm64 image, and if it doesn't start up, try the armv7l image. Remember to always back up your system before making any changes. For everyone, please make this change as soon as possible, and if you have any trouble finding a working image, please (1) go back to the current aarch64 image; and (2) let me know in this thread along with as much detail about your host system as you can offer (including the output of the dpkg-architecture command mentioned above).
Multi-System Reactor
Requesting a proper ARM64/aarch64 Docker image (Pi 5 support)
M
Hi, I'm in the process of migrating from a Raspberry Pi 4 (ARMv7) to a Raspberry Pi 5 (ARMv8/aarch64), but I’ve run into an issue: there is no proper ARMv8/aarch64 image available. None of the existing images run on the Pi 5 - they all exit immediately with code 139 (segmentation fault), which typically indicates that the binaries inside the image are not compatible with the ARM64/aarch64 architecture used by the Pi 5. Would it be possible to publish a correct ARMv8/aarch64 (linux/arm64) image? Building one should be relatively straightforward using docker buildx with multi-arch support. For example, my own Node.js images are built this way: docker buildx build --push \ -t <localrepo>/<project>:<tag> \ --platform=linux/arm64,linux/amd64 \ --file ./apps/<project>/Dockerfile . This produces both the AMD64 and ARM64/v8 variants automatically. Also, as a side note, it may be best to avoid using Alpine as the base image for the ARM64 build, since musl-based builds often cause compatibility issues and unnecessary headaches. A glibc-based base image (e.g., Debian or Ubuntu) tends to work far more reliably on ARM64, especially for Node.js applications. @toggledbits - tagging you in case you missed this. Thanks, mgvra
Multi-System Reactor
Script action and custom timers
therealdbT
Sorry to write here without trying, but I’m flying today. Am I correct if i say that script action with alarm() makes it possible to execute a reaction in a given interval, lets say 15 seconds or 3.5 minutes? That sounds amazing, since I’ve used weird tricks, including a custom controller, just to do this.
Multi-System Reactor
Help resolve change in behaviour post update
CatmanV2C
Topic thumbnail image
Multi-System Reactor
Reactor w/HA 2025.11 error on set_datetime service call setting only time
CrilleC
@toggledbits Do you know if this is related to that PR or is it a change they made in 2025.11.1? [latest-25310]2025-11-11T13:16:24.319Z <HassController:INFO> HassController#hass perform x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_dag with { "time": "10:45" } [latest-25310]2025-11-11T13:16:24.320Z <HassController:INFO> HassController#hass: sending payload for x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_dag action: { "type": "call_service", "service_data": { "date": (null), "time": "10:45", "datetime": (null), "timestamp": (null) }, "domain": "input_datetime", "service": "set_datetime", "target": { "entity_id": "input_datetime.vvb_dag" } } [latest-25310]2025-11-11T13:16:24.321Z <HassController:ERR> HassController#hass request 1762866984320<2025-11-11 14:16:24> (call_service) failed: [Error] Not a parseable type for dictionary value @ data['date'] [-] [latest-25310]2025-11-11T13:16:24.321Z <HassController:WARN> HassController#hass action x_hass_input_datetime.set_datetime({ "time": "10:45" }) on Entity#hass>input_datetime_vvb_dag failed! [latest-25310]2025-11-11T13:16:24.321Z <HassController:INFO> Service call payload: {"type":"call_service","service_data":{"date":null,"time":"10:45","datetime":null,"timestamp":null},"domain":"input_datetime","service":"set_datetime","target":{"entity_id":"input_datetime.vvb_dag"},"id":1762866984320} [latest-25310]2025-11-11T13:16:24.322Z <HassController:INFO> Service data: {"fields":{"date":{"example":"\"2019-04-20\"","selector":{"text":{"multiline":false,"multiple":false}}},"time":{"example":"\"05:04:20\"","selector":{"time":{}}},"datetime":{"example":"\"2019-04-20 05:04:20\"","selector":{"text":{"multiline":false,"multiple":false}}},"timestamp":{"selector":{"number":{"min":0,"max":9223372036854776000,"mode":"box","step":1}}}},"target":{"entity":[{"domain":["input_datetime"]}]}} [latest-25310]2025-11-11T13:16:24.322Z <Engine:ERR> Engine#1 reaction rule-mgb8pfhs:S step 0 perform x_hass_input_datetime.set_datetime failed: [Error] Not a parseable type for dictionary value @ data['date'] [-] [latest-25310]2025-11-11T13:16:24.322Z <Engine:INFO> Engine#1 action args: { "time": "10:45" } [latest-25310]2025-11-11T13:16:24.322Z <Engine:INFO> Resuming reaction Sätt Schema VVB i Home Assistant<AKTIV> (rule-mgb8pfhs:S) from step 1 [latest-25310]2025-11-11T13:16:24.323Z <HassController:INFO> HassController#hass perform x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_natt with { "time": "03:00", "timestamp": 0 } [latest-25310]2025-11-11T13:16:24.323Z <HassController:INFO> HassController#hass: sending payload for x_hass_input_datetime.set_datetime on Entity#hass>input_datetime_vvb_natt action: { "type": "call_service", "service_data": { "date": (null), "time": "03:00", "datetime": (null), "timestamp": 0 }, "domain": "input_datetime", "service": "set_datetime", "target": { "entity_id": "input_datetime.vvb_natt" } } [latest-25310]2025-11-11T13:16:24.324Z <HassController:ERR> HassController#hass request 1762866984323<2025-11-11 14:16:24> (call_service) failed: [Error] Not a parseable type for dictionary value @ data['date'] [-] [latest-25310]2025-11-11T13:16:24.324Z <HassController:WARN> HassController#hass action x_hass_input_datetime.set_datetime({ "time": "03:00", "timestamp": 0 }) on Entity#hass>input_datetime_vvb_natt failed! [latest-25310]2025-11-11T13:16:24.324Z <HassController:INFO> Service call payload: {"type":"call_service","service_data":{"date":null,"time":"03:00","datetime":null,"timestamp":0},"domain":"input_datetime","service":"set_datetime","target":{"entity_id":"input_datetime.vvb_natt"},"id":1762866984323} [latest-25310]2025-11-11T13:16:24.324Z <HassController:INFO> Service data: {"fields":{"date":{"example":"\"2019-04-20\"","selector":{"text":{"multiline":false,"multiple":false}}},"time":{"example":"\"05:04:20\"","selector":{"time":{}}},"datetime":{"example":"\"2019-04-20 05:04:20\"","selector":{"text":{"multiline":false,"multiple":false}}},"timestamp":{"selector":{"number":{"min":0,"max":9223372036854776000,"mode":"box","step":1}}}},"target":{"entity":[{"domain":["input_datetime"]}]}} [latest-25310]2025-11-11T13:16:24.324Z <Engine:ERR> Engine#1 reaction rule-mgb8pfhs:S step 1 perform x_hass_input_datetime.set_datetime failed: [Error] Not a parseable type for dictionary value @ data['date'] [-] [latest-25310]2025-11-11T13:16:24.324Z <Engine:INFO> Engine#1 action args: { "time": "03:00", "timestamp": 0 } [latest-25310]2025-11-11T13:16:24.325Z <Engine:INFO> Resuming reaction Sätt Schema VVB i Home Assistant<AKTIV> (rule-mgb8pfhs:S) from step 2 [latest-25310]2025-11-11T13:16:24.325Z <Engine:INFO> Sätt Schema VVB i Home Assistant<AKTIV> all actions completed.
Multi-System Reactor
Reactor Version 25310 : Office Light control via rule in reactor no longer working since last update.
P
Hello, I currently have an office light (connected via a Leviton Zwave Dimmer switch) controlled from a Gen5 Aeotech Zwave switch installed on my Synology 720+ NAS. I run HA(2025.11.10) in a virtual machine from my NAS and Reactor on the container manager of the same NAS. Prior to updating to 25304 the rule I had set to turn the light on to a specific dimming value worked correctly. Now the rule appears to follow the decision tree, however the reaction does not trigger setting the dimming or turning on the office light? Strangely I can still turn the light on and off as well as dim it directly from HASS..? I have tried using the ''try this action'' button in the rules reaction setting and it will not control the light and does not throw an error flagÉ Please help, P.S Reactor has been rock steady for me over the last few years and I'm a big fan of this solution.
Multi-System Reactor
[Solved] alarm() in global expression throws error in log.
CrilleC
Topic thumbnail image
Multi-System Reactor
[Solved] Define function issue in latest-25304
CrilleC
Topic thumbnail image
Multi-System Reactor
No Upgrade Notification for Build 25308?
CatmanV2C
FWIW I'm no longer getting a notification from MSR that there's an update. Just thought I'd mention it C
Multi-System Reactor
Strange behavior in MSR latest-25304 with disabled groups in Reaction
therealdbT
Topic thumbnail image
Multi-System Reactor
[Reactor] Variables not updating correctly in latest-25201-2aa18550
therealdbT
Topic thumbnail image
Multi-System Reactor
The reaction stopped working (Google Nest max playing a video)
F
Topic thumbnail image
Multi-System Reactor
Handling Dead Entities and Renamed Entities
PablaP
Hello all.. been a minute! I recently rebuilt my Z wave network and migrated to a new z wave stick. In order to prevent any downtime I kept my original z wave network up and ran a docker version of Z Wave JS UI with my new controller. This way I could add device by device without having any devices down. I finally moved all the devices over to my new stick today. The final step was to migrate everything from my Docker instance of Z Wave JS UI to the HA add-on of Z Wave JS UI. However during this migration some of the names didn't populate correctly which I later managed to import back into Z Wave JS UI. The issue was in Reactor it is stuck on the default names and the entities are not updating. I removed the controller from Reactor, restarted, hard refreshed, and added the controller back however the new entity names have not updated. Also it seems like the old entities from my previous instance of Z Wave JS UI are lingering and not being marked as dead (I believe a certain amount of time needs to lapse before they're marked as dead in Reactor). My goal is to basically purge all the entities for the 'ZWaveJS' controller in Reactor so it can pull all the updated entity names and only the entities that exist in Z Wave JS UI. I cannot find a quick way to do this, I know entities can be deleted one by one, but with over 100 entities this would take long I am guessing that if I added the controller with a new name in in the Reactor config it would pull the updated entities and names but I think that would break my rules since the entity IDs would change (I made sure to name all the entities the exact same as they were previously to prevent this issue).
Multi-System Reactor

Gradually turn on lights.

Scheduled Pinned Locked Moved Solved Multi-System Reactor
21 Posts 6 Posters 2.8k Views 6 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.
  • CatmanV2C Offline
    CatmanV2C Offline
    CatmanV2
    wrote on last edited by
    #6

    This was actually the use case that started my journey into HA eeeek years ago with a couple of X10 units since they were cheaper than sunrise lamps!

    C

    The Ex-Vera abuser know as CatmanV2.....

    1 Reply Last reply
    0
    • V vezinpi

      @toggledbits I am having some difficulty implementing the suggested approach. In my case, what you suggested above worked but with some limitations. Maybe due to the fact that I am not using the Z-Wave controller but Z-Wave JS UI.

      I have created the same rule as you suggested but to better understand what is happening I perform some test from the "Entities" menu.

      1- The "dimming.step" when changed does not stick after a dimming.up/down

      In the "Entities" menu I set the attribute "dimming.step" to 0.05. Still in the etities menu, I then perform a "dimming.up" and can confirm that indeed the "dimming.level" went up by 0.05 however at the same time the dimming.step goes back to 0.1 (default). From that point, any subsequent "dimming.up" uses the default.

      2- The dimming.up does not exceed the previous level (This might be normal but a bit difficult to manage?)

      If the dimming level was set to 60% and then turn off, performing a "dimming up" will not go beyond 60%. So implementing the rule as suggested, make an infinite while since .99 is never reached.

      I tried this on 2 type of z-wave devices with the same result.

      Thanks in advance

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

      @vezinpi can you share screenshots of the rules?

      I implemented this and it appears to be working fine (though I want to do some fine tuning).

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

      *HASS 2025.11.1
      w/ HA Connect ZWA-2
      FW: v1.1
      SDK: v7.23.1

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

      1 Reply Last reply
      0
      • V Offline
        V Offline
        vezinpi
        wrote on last edited by
        #8

        @gwp1 Here is the screen capture. It is basically a copy of what toggledbits provided. Keep in mind that it is working fine with the default dimming.step and if your dimmer is normally set to 100% before being turned off.

        From the screen capture you can see that, in my case, the "Current value" is 0.59...This is as high as it will go if the previous state of the dimmer was 60%. This situation causes the while to repeat every 2 second indefinitely. I have to kill it in the "running reaction" status screen or to disable the rule.

        image.png

        G 1 Reply Last reply
        0
        • V vezinpi

          @gwp1 Here is the screen capture. It is basically a copy of what toggledbits provided. Keep in mind that it is working fine with the default dimming.step and if your dimmer is normally set to 100% before being turned off.

          From the screen capture you can see that, in my case, the "Current value" is 0.59...This is as high as it will go if the previous state of the dimmer was 60%. This situation causes the while to repeat every 2 second indefinitely. I have to kill it in the "running reaction" status screen or to disable the rule.

          image.png

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

          @vezinpi mine is as such:

          c49d3fa7-b5b0-429b-8546-46936b06bf7c-image.png

          Here's the rule's Set Reaction that pulls this in.

          07704c8c-6a37-4c7b-b67f-d8285f955bad-image.png

          I also have another group under this same rule's Set Reaction for Evenings.

          0cd4a81b-ea76-43b7-a6a5-a7c6e719ab28-image.png

          Everything I've seen shows this as working as intended. Only rises to 30% in the mornings, 80% at night. Only the mornings get the slow roll ramp up.

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

          *HASS 2025.11.1
          w/ HA Connect ZWA-2
          FW: v1.1
          SDK: v7.23.1

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

          1 Reply Last reply
          0
          • V Offline
            V Offline
            vezinpi
            wrote on last edited by
            #10
            This post is deleted!
            1 Reply Last reply
            0
            • V Offline
              V Offline
              vezinpi
              wrote on last edited by vezinpi
              #11

              Hi again, more accurate info for the "Perform dimming.up/down"

              I have just made a test from the entity menu. Using the default dimming.step (0.1) I did the following starting with the dimmer off:

              1- Perform dimming.up 10 times

              This should have brought the dimmer to 100% but it did stop at 60% (0.59...)

              2- Perform dimming.down 10 times

              This should have brought the dimmer to 0% but it did stop at 50%

              From 100%, I can only dimmed.down to 50%
              from 0%, I can only dimmed.up to 60% (0.59)

              The dimming.set "value" works all the time

              Here is the log from Z-Wave JS for the 10x dimming.up followed by the 10x dimming.down test.

              2025-07-07 23:32:00.315 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 0 => 10
              2025-07-07 23:32:00.328 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 10 => 10
              2025-07-07 23:32:03.828 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 10 => 20
              2025-07-07 23:32:03.834 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 10 => 20
              2025-07-07 23:32:03.854 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 20 => 20
              2025-07-07 23:32:06.007 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 20 => 30
              2025-07-07 23:32:06.014 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 20 => 30
              2025-07-07 23:32:06.045 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 30 => 30
              2025-07-07 23:32:08.149 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 30 => 40
              2025-07-07 23:32:08.152 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 30 => 40
              2025-07-07 23:32:08.165 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 40 => 40
              2025-07-07 23:32:10.289 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 40 => 50
              2025-07-07 23:32:10.295 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 40 => 50
              2025-07-07 23:32:10.308 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:12.397 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 59
              2025-07-07 23:32:12.401 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 59
              2025-07-07 23:32:12.416 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 59
              2025-07-07 23:32:14.848 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 59 => 59
              2025-07-07 23:32:14.853 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 59
              2025-07-07 23:32:14.866 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 59
              2025-07-07 23:32:16.744 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 59 => 59
              2025-07-07 23:32:16.749 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 59
              2025-07-07 23:32:16.762 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 59
              2025-07-07 23:32:18.651 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 59 => 59
              2025-07-07 23:32:18.654 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 59
              2025-07-07 23:32:18.665 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 59
              2025-07-07 23:32:20.649 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 59 => 59
              2025-07-07 23:32:20.652 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 59
              2025-07-07 23:32:20.661 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 59
              2025-07-07 23:32:22.864 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 59 => 50
              2025-07-07 23:32:22.870 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 59 => 50
              2025-07-07 23:32:22.881 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:26.963 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 50
              2025-07-07 23:32:26.966 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:26.975 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:29.030 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 50
              2025-07-07 23:32:29.035 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:29.052 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:31.234 DEBUG Z-WAVE: Polling value 49-0-Air temperature
              2025-07-07 23:32:31.289 INFO Z-WAVE: [Node 036] Metadata updated: 49-0-Air temperature
              2025-07-07 23:32:31.292 INFO Z-WAVE: [Node 036] Value updated: 49-0-Air temperature 24 => 24
              2025-07-07 23:32:31.297 DEBUG Z-WAVE: 36-49-0-Air temperature will be polled in 60 seconds
              2025-07-07 23:32:31.715 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 50
              2025-07-07 23:32:31.718 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:31.727 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:34.557 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 50
              2025-07-07 23:32:34.562 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:34.578 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:36.379 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 50
              2025-07-07 23:32:36.384 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:36.398 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:38.130 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 50
              2025-07-07 23:32:38.133 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:38.141 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:39.756 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 50
              2025-07-07 23:32:39.759 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:39.767 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:41.731 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 50
              2025-07-07 23:32:41.737 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:41.756 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:43.814 INFO Z-WAVE: [Node 005] Value updated: 38-0-targetValue 50 => 50
              2025-07-07 23:32:43.819 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50
              2025-07-07 23:32:43.828 INFO Z-WAVE: [Node 005] Value updated: 38-0-currentValue 50 => 50 ~~~
              1 Reply Last reply
              0
              • toggledbitsT Offline
                toggledbitsT Offline
                toggledbits
                wrote on last edited by toggledbits
                #12

                Sounds like you might have dimming.minimum on the entity set to 0.1? And what of dimming.maximum? Failing that, does the device itself have min/max set in its Z-Wave configuration?

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

                1 Reply Last reply
                0
                • V Offline
                  V Offline
                  vezinpi
                  wrote on last edited by
                  #13

                  Hi,

                  The dimming.maximum/minimum are set to 1 and 0

                  image.png

                  @toggledbits said in Gradually turn on lights.:

                  Failing that, does the device itself have min/max set in its Z-Wave configuration?

                  Not sure exactely how to check this. The device is a Zooz ZEN 72. I look in the Z-Wave JS UI and could not find any parameter that would limit the dimming min/max.

                  I might be wrong here but it is my understanding that the Z-Wave JS UI sits between HA and the devices. Since the Z-Wave JS UI log shows that any level change request above 60 from MSR, stays at 60, it can only be coming from MSR or HA. In addition the dimming.set works without any issues.

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

                    OK. There are some rounding issues with JavaScript, and I think I can tune things up to work around them a little better. Stay tuned.

                    Also, tip: use the Copy Attributes button instead of screen-grabbing the attributes. Gives more data.

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

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

                      Yup, a lot going on here. ZWave and ZWave-JS produce values for brightness in the range 0-99. HA maps that into its 0-255 scale, so precision oddities are introduced there. HassController then attempts to scale HA's 0-255 into Reactor's 0-1, which introduces more precision oddities.

                      I've made an interim build with a handful of adjustments. It is published only for docker aarch64/arm64 (RPi 64-bit and similar) right now, because I don't have time to repackage the whole thing for all platforms right now (I'll be unavailable from 11th through 20th), and it's too risky. For others reading, I don't recommend going to this build unless you need this specific fix immediately.

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

                      1 Reply Last reply
                      0
                      • V Offline
                        V Offline
                        vezinpi
                        wrote on last edited by
                        #16

                        @toggledbits Thank you for looking into this.

                        There is absolutely no rush on any of this on my side. When I read the post I really liked the approach you suggested and made a test rule to see how I could use it and got into some issues.

                        Since you took the time to make an interim built, I will take the time to test it and report back here with the result. This way, you will know the status when you return.

                        Thanks again

                        1 Reply Last reply
                        0
                        • V Offline
                          V Offline
                          vezinpi
                          wrote on last edited by vezinpi
                          #17

                          Loaded the new built and as expected, the dimming.up/down are working for all levels. I also noticed that the dimming.level reported are nicely round up to one digit after the "." except for 50% where it displays "0.51" (not really an isssue just reporting what I see)

                          However, the other issue mentionned my opening post (that got kind of forgotten) is still present. Here is the refference:

                          said in Gradually turn on lights.:

                          1- The "dimming.step" when changed does not stick after a dimming.up/down

                          In the "Entities" menu I set the attribute "dimming.step" to 0.05. Still in the etities menu, I then perform a "dimming.up" and can confirm that indeed the "dimming.level" went up by 0.05 however at the same time the dimming.step goes back to 0.1 (default). From that point, any subsequent "dimming.up" uses the default.

                          Again, this can wait until your next release if a fix is indeed needed.

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

                            Have you done a hard refresh on the browser? If that's not it, check file permissions on your storage directory, and also check the logs to see if any errors are emitted when you change the attribute value and within the window of about two minutes after (allowing for the delayed-write strategy caching). The other likely issue is that your storage directory has issues and isn't properly saving the state data for the entity.

                            Edit: Well, I said:

                            There is no code that changes dimming.step other than the button you use on the UI.

                            And that's technically true, there's no code, but... seems there is a stray directive in the entity mapping data table hass_devices.yaml, which is specific to HassController, left over from wayyyyy long ago that should not be there today, and will do what you are observing. Simple fix. I'll roll a new docker image shortly.

                            Edit 2: Updated container is up and ready.

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

                            1 Reply Last reply
                            0
                            • V Offline
                              V Offline
                              vezinpi
                              wrote on last edited by
                              #19

                              As usual, you nailed it!

                              With a dimming.step of 0.03, it does a very nice gradation.

                              Many thanks

                              1 Reply Last reply
                              0
                              • T Offline
                                T Offline
                                tbully
                                wrote on last edited by
                                #20

                                I'm having this same issue with a bare metal install. I assume this fix will be included in a future release? (No hurry. This is just a nice-to-have thing...)

                                toggledbitsT 1 Reply Last reply
                                0
                                • T tbully

                                  I'm having this same issue with a bare metal install. I assume this fix will be included in a future release? (No hurry. This is just a nice-to-have thing...)

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

                                  @tbully said in Gradually turn on lights.:

                                  I'm having this same issue with a bare metal install. I assume this fix will be included in a future release? (No hurry. This is just a nice-to-have thing...)

                                  The 25208 build released yesterday includes the fixes in the temporary containers built for @vezinpi and others on this thread.

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

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


                                  Recent Topics

                                  • Date/time condition
                                    tunnusT
                                    tunnus
                                    0
                                    3
                                    44

                                  • Is there a way to turn this section (image in post) off?
                                    toggledbitsT
                                    toggledbits
                                    0
                                    1
                                    49

                                  • Device log?
                                    toggledbitsT
                                    toggledbits
                                    0
                                    2
                                    84

                                  • Midnight crossing not working in date/time condition (build 25325)
                                    tunnusT
                                    tunnus
                                    0
                                    3
                                    88

                                  • Error: Command timeout
                                    G
                                    gwp1
                                    0
                                    6
                                    200

                                  • Reactor (Multi-System/Multi-Hub) Announcements
                                    toggledbitsT
                                    toggledbits
                                    5
                                    131
                                    75.4k

                                  • [Solved] Local expression in Rule does not evaluate as they used to do
                                    CrilleC
                                    Crille
                                    0
                                    5
                                    289

                                  • Home Assistant 2025.11.2 and latest-25315
                                    G
                                    gwp1
                                    0
                                    6
                                    299

                                  • Notice to Docker + ARM Users (RPi 3/4/5 and others)
                                    toggledbitsT
                                    toggledbits
                                    1
                                    1
                                    105

                                  • Requesting a proper ARM64/aarch64 Docker image (Pi 5 support)
                                    M
                                    mgvra
                                    1
                                    3
                                    213

                                  • Script action and custom timers
                                    toggledbitsT
                                    toggledbits
                                    0
                                    4
                                    229
                                  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