After spending some time I think I got it figured out. Thanks to @Crille for the Inspo expression. I created a similar one that would basically deduct the extra light that is added when the lights are on. Basically when the lights are off, the expression gives the true value of the light sensor, and when they're on it deducts the 30lx from the true value. 30lx is probably too much but It seems to work now. The sunrise/sunset trigger is just temporarily there to ensure the lights still turn on and off as back up. [image: 1766635051215-screenshot-2025-12-24-at-7.57.25-pm-resized.png] [image: 1766635065885-screenshot-2025-12-24-at-7.57.41-pm-resized.png]

I tried different things and after all I’ve just switched to my own emulated hue bridge, calling reactor HTTP endpoints. I was toying with the idea of sending MQTT commands, but HTTP just works. I did my own bridge because I have 100 switches/scenes/virtual switches mapped to Alexa and ha-bridge has not the ability to define multiple bridges on the same host, so I wrote mine But ha-bridge should just work. Never tried HASS native hue emulation. I tried matter bridge and unfortunately Alexa will only see 20 devices.

In the version you are using, it is still required; that's the docs leading the released code by a step (sorry). The version you are using also doesn't enforce limits well, so it allows values that could produce no result, or store more data than needed. For example, given your retention of 60 and interval of 5, there would be r/i+1 = 13 samples in the series. But if you specify depth of 2, then only the most recent 2d-1 = 3 samples are considered... the other 10 samples don't contribute to the result value. A depth of 7 would be the best match for the given interval and retention (just mathematically, ignoring your semantic goals).

That is very helpful, thanks. I'll enable some logging tomorrow and have a dig! C

Thanks both! Busy day today but shall look tomorrow. Love this place <edit> Just looks. That makes perfect sense! C

FFS! User=pi Looks like it's fixed C

Further testing, I need a router decvice as by the time I move the sensor two floors down it stops responding, but I was pretty much expecting that. I can probably do something with the positioning of the dongle on its extension as well. C

@Pabla said in Single protocol?: When you make the switch give the new ZWA-2 Z wave antenna a try, it will fix a lot of any lingering problems. That is exactly where I am headed. Most of the "complicated" devices in my mesh that were on Vera (scene controllers, notably, but also multi-sensors and some devices that were causing issues there) have been moved to a 500-series Z-stick controlled by Z-WaveJS, and I will migrate everything to the ZWA-2 when I get it (on my Christmas wish list, so if it's not under the tree, I'll just gift it to myself after). I have to confess, despite its issues and the horrible ending that Ezlo has given the product (and the tremendous face-in the-dirt failure that their supposed replacement products have been), I remain sentimental. So much wasted potential. Alas, we move on. Edit: just now, to illustrate: [image: 1765821934989-6b950965-5658-45f5-aa89-50ef098cf2ea-image.png]

TBF I was suprised as well! C

@toggledbits I tried the Clear Local Storage and a hard-refresh and still have the same result. I am attaching a new screenshot of the web inspector where I saw some errors just in case it means something to you. [image: 1765418734262-screenshot-2025-12-10-at-5.47.00-pm.png] I don't know why it works for some on Safari but seems work for all with other browsers. Is there anything else you can think of for me to check? Thank you for responding with your experiences @CatmanV2 @therealdb and @gwp1 !

I guess I never noticed before as I thought they used to update. The rules function so just visual. Thank You for the information.

Well, taking a backup inside ZWaveJS is a breeze - and yes, it's very easy to backup (or restore) the NVM on the ZWA-2. In fact, I just restored a backup from UZB to ZWA-2 and I was good to go. I think you'll never need to move it around the house, because the antenna is huge. No problems in pairing devices either, but that was the case with UZB before and I think it's a ZWave JS prerogative in general. It was just plug&play for me, but I understand that if you have to change your logic to match new device IDs it may make sense to start from scratch - time permitting.

yep, parameters for reactions will definitely improve my job here, specially when speaking of thermostats/HVAC in general. Thanks as always for your support, Patrick!

OK. I DM'd you something else to try.

sorry for all the replies here but.. I deleted the device trackers and they all just reappear. They are coming from HA even though I have removed Opnsense integration. So I added this to my reactor.yaml filter_entity: - "/^device_tracker_/" Deleted the tracker jsons, restarted docker and the problem is 100% resolved. I am now trying to figure out how to get rid of these in HA. very annoying....

Ok, I'm aware of "after" operator, and in this case didn't want to use "between 13:00 and 13:05"

You list Hubitat and HASS as hubs, and the default logging for both of these hubs should tell you what you need to know. I've tried to keep these messages fairly consistent across the controllers, generally in this form: [...]2025-11-25T12:45:08.121Z <xxx:INFO> xxx#house perform power_switch.set on Switch#house>device_396 with { "state": false } Search using the canonical entity ID. There are several capabilities that can turn a light on, so searching by capability is harder. The idea is to find a perform ??? on ??? with ??? at the right time with the right entity ID. From there, start looking backwards for a message like either one of these: [...]2025-11-25T12:45:00.100Z <Engine:NOTICE> Starting reaction Parking Area Light Off (re-lk5lrx5a) or [...]2025-11-25T12:45:08.121Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 3 If this line is within just a couple of lines, maybe even directly before, the perform log entry you found above, then that's the name of the Reaction that manipulated the device. If that has :S or :R at the end of its ID and the tag <SET> or <RESET> appended to the Reaction name, the Reaction is part of a Rule with that ID and name, and that is the rule that is manipulating the entity — you're done! If the Reaction ID doesn't have the :S or :R suffix, then the Reaction is not rule-based (e.g. it's a global reaction), and you need to find what launched it. If the line you've found is of the form Resuming "<reaction name>" (reaction id)" from step n, then keep looking backwards. You may find more Resuming lines for other steps of the same reaction, but your goal now is to find the line that looks like Starting "<reaction name>" (reaction id). Once you are on the Starting "<reaction name>" (reaction id) line, you should not have to look very far to find an Enqueuing "<reaction name>" (reaction id) line. Once you are on the Enqueueing line, you should not have to look very far to find another Resuming or Starting reaction line. This line may have the :S and :R on the reaction ID that you are looking for to indicate the rule that launched the reaction. If it doesn't, then the reaction was launched by another reaction, and you just repeat the above process looking for what started this reaction. This path will eventually lead to the responsible rule. Live example from my host this morning. The perform action we found above is for an outdoor flood light that lights a parking pad at my house. It got turned off. By what, though? Well, we already established that is was by a reaction called Parking Area Light Off because we found a Resuming line for that reaction right before the perform line for the entity. Let's keep digging to find the responsible rule. Here's are some more relevant lines from my log: [...]2025-11-25T12:45:00.067Z <Engine:INFO> Enqueueing "Morning Lighting Off<SET>" (rule-knjifbn1:S) [...]2025-11-25T12:45:00.078Z <Engine:NOTICE> Starting reaction Morning Lighting Off<SET> (rule-knjifbn1:S) [...]2025-11-25T12:45:00.078Z <Engine:INFO> Enqueueing "Outdoor All Off" (re-kl73syb6) . . [...]2025-11-25T12:45:00.088Z <Engine:NOTICE> Starting reaction Outdoor All Off (re-kl73syb6) [...]2025-11-25T12:45:00.089Z <Engine:INFO> Enqueueing "Parking Area Light Off" (re-lk5lrx5a) . . [...]2025-11-25T12:45:00.100Z <Engine:NOTICE> Starting reaction Parking Area Light Off (re-lk5lrx5a) . . [...]2025-11-25T12:45:00.118Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 2 [...]2025-11-25T12:45:00.119Z <Engine:NOTICE> Parking Area Light Off delaying until 1764074708119<11/25/2025, 7:45:08 AM> . . [...]2025-11-25T12:45:08.121Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 3 Working backwards from the last line, which is the Resuming line that we found earlier (reaction step 3), we find a Resuming line for the previous step (2) of that same reaction at 12:45:00.118. Notice also that reaction had a delay at that step that was logged immediately after, which accounts for the time gap between reaction steps 2 and 3. Keep working backwards to 12:45:00.100 and we find the Starting line for that Parking Area Light Off reaction. And continuing to look backwards for that same reaction ID, we eventually find the Enqueueing line for it (12:45:00.089). Usually these two lines are pretty close together, but it's not usual to have other things logged between. Now just looking backward line by line (not searching for any ID here), we soon find a Starting reaction Outdoor All Off line (12:45:00.088) very close to our Enqueueing line, indicating that Outdoor All Off launched the Parking Area Light Off reaction. Now we just repeat this process with Outdoor All Off — find it enqueued at 12:45:00.078 by Morning Light Off<SET> also at 12:45:00.078. The <SET> on the name and :S on the ID means it's a rule reaction, so Morning Light Off is the rule that triggered and started the sequence of two other reactions that eventually turned off the light. So to recap: Find the perform line (search using entity ID) that occurs at about the right time. Look backwards a short distance and you will find either a Starting <reaction> or Resuming <reaction> line. If that's a rule's SET or RESET reaction, you've found the responsible rule. Otherwise, a global reaction manipulated the entity/device, so proceed to the next step. Find what launched the current reaction. Keep looking backward until you find the Enqueueing line for it. Then very shortly preceding it, you should find a Starting <reaction> or Resuming <reaction> line for a different reaction. That's what started the current reaction. If this new reaction is a rule's SET or RESET reaction, you've found the responsible rule. Otherwise, find what launched this new (global) reaction by repeating this step. NOTE: Almost all actions in Reactor are asynchronous, meaning the Engine launches them in a separate process and the Engine can move on to working on a different reaction if multiple are running concurrently. Some in particular can take a lot of time (like HTTP Request). Depending on how busy your system is in that moment, all of these lines can be separated by other lines for other things going on, and you have to be careful and patient sifting through them.