I have this Global Reaction doing some work around lights, based on the season:

When I run it, both the lights in Summer and Winter groups are turned on. Very, very strange. I tried removing and adding the groups again, with no joy.

I see these on the logs:

[latest-25328]2026-01-11T18:23:11.847Z <Engine:CRIT> TypeError: this[_0x3c7c88(...)][_0x3c7c88(...)] is not a function [-]
TypeError: this[_0x3c7c88(...)][_0x3c7c88(...)] is not a function
    at GlobalReactionPredicateContext.toString (/opt/reactor/server/lib/PredicateContext.js:87:126)
    at Logger.getLogger (/opt/reactor/server/lib/Logger.js:417:31)
    at new GlobalReactionPredicateContext (/opt/reactor/server/lib/GlobalReactionPredicateContext.js:62:93)
    at Engine._resume_reaction (/opt/reactor/server/lib/Engine.js:2136:55)
    at Engine._process_reaction_queue (/opt/reactor/server/lib/Engine.js:2031:133)
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
[latest-25328]2026-01-11T18:23:12.155Z <Engine:CRIT> Engine#1 alarm() context is rule Rule#rule-mf29005p condition condmf29005q Script; timer ID will be alarm:rule:rule-mf29005p:cond:condmf29005q
[latest-25328]2026-01-11T18:23:13.159Z <Engine:CRIT> Engine#1 alarm() context is rule Rule#rule-mf29005p condition condmf29005q Script; timer ID will be alarm:rule:rule-mf29005p:cond:condmf29005q
[latest-25328]2026-01-11T18:23:14.376Z <Engine:CRIT> TypeError: this[_0x3c7c88(...)][_0x3c7c88(...)] is not a function [-]
TypeError: this[_0x3c7c88(...)][_0x3c7c88(...)] is not a function
    at GlobalReactionPredicateContext.toString (/opt/reactor/server/lib/PredicateContext.js:87:126)
    at Logger.getLogger (/opt/reactor/server/lib/Logger.js:417:31)
    at new GlobalReactionPredicateContext (/opt/reactor/server/lib/GlobalReactionPredicateContext.js:62:93)
    at Engine._resume_reaction (/opt/reactor/server/lib/Engine.js:2136:55)
    at Engine._process_reaction_queue (/opt/reactor/server/lib/Engine.js:2031:133)

Maybe some old format that was corrupted in the rule? @toggledbits

@CatmanV2 said in [HowTo] Using HABridge with Reactor:

Which I don't think needs URL encoding. (Well the URL encoder I checked didn't make any changes)

Nope, canonical IDs in HASS always require encoding. Ask me why I know this...
The request is failing otherwise. Trust me

Yes, thanks. I usually send json and numbers, so I assumed it would automatically convert to string anyway. Not a big deal, but it made me check my sanity for a couple of hours, until I realized it was not me.

@CatmanV2 here we go: https://smarthome.community/topic/1593/howto-using-habridge-with-reactor

Yes, same here. Once discovered, you have to stick with it.

I’m calling reactor endpoints to control hass devices. I posted the urls in a previous post, but I could post it again if needed.

Can’t you just use “after Dec 15th” and then add an OR for just “before Jan 15th”?

I have a global variable named ChristmasTime that’s set daily, so it’s easier to use in multiple reactions. Just a suggestion to simplify things.

I will change my logic to just check for your state to be disarmed (so, no changes) for at least 5 secs, or as already suggested, just use OR with all the possible variations you’d get.

Hey @toggledbits.

I found a strange bug while sending boolean MQTT payloads in actions. Latest MQTT/Reactor builds.

Basically, if I send a true/false, it gets logged but it's not sent:

[latest-25328]2025-12-31T11:36:23.958Z <MQTTController:INFO> MQTTController#mqtt x_mqtt.publish publishing foo/cmd/foo payload false

If I change to ${{ str(1 == 1) }}, it goes thru. No apparent errors in logs.

I did a "replace script" that's parsing JSON files and replacing references. Every time I change a device (i.e.: I pair a new Zwave device or replace some Wi-Fi thing with ZigBee/Zwave), I run it with old device and new device as params. Back in the days I mostly did it manually.
Here's the todo list:

• Stop reactor
• Copy storage folder (and make a backup)
• Search for the old device ID and change accordingly
• Save files, copy to storage folder
• Start Reactor again

I agree a much needed feature will be the ability to filter rules by device. At least you'll easily spot the ones not used in code blocks and that will be useful when you don't remember the exact rule that is doing something with a particular device.

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.

Back in the days I used an illuminance binary sensor to do this (linked to a fibaro relay), but now I’m using civil dawn/dusk and called it a day.

All that said, I’m still using an illuminance sensor indoor in my office to drive my blinds.

My logic is like the one you mentioned: once triggered, the low light state stays true for at least two hours. When driving lights/blinds, hysteresis is fundamental.

I was toying with the idea of using a time series, so I could get let’s say a trend and/or the avg in the latest 15 minutes or so, but it seemed overkill for this simple situation.

As you may already know, I'm heavily invested in Zwave (70+ devices at the main house, 40 in the beach one), curious towards Shelly Wifi (4-5 devices added when using Vera, that I'll eventually ditch for Zwave) and slowly starting interest in ZigBee.

I find Zwave life after Vera to be definitely better and the mesh still more stable than Zigbee or WiFi.

I've started a new journey to learn more about Matter and I've recently started working on a matterbridge plugin to call HTTP endpoints as in the old ha-bridge days. Problem is, while Matter may seems a standard, vendors have their own preferences over implementation, with the result that support is not complete and you'll see ridiculous constraints, such as no more than 20 matter devices supported on your Alexa network.

We'll see, I avoided tuya because of cloud links and the only cloud-only things I have are my Nest thermostats, bought when I was thinking that it will eventually become less important, because they were the only thermostats that were good to show. Today, I'll not buy them.

All that said, my older Zwave devices are 10 years old and apart 2-3 I had to replace because of relay that stops working, all is good and mesh is stable as it has never been, thanks to ZWA-2.

if you connect to HAOS VM, there's no need to install Zigbee2MQTT.

This should be recognized by HAOS as well. Otherwise, map the USB to your Zigbee2MQTT VM/Docker image and you're good to go. Remember to get an USB cable, so the radio is not near the internal USB port - that's better in terms of radio.

@CatmanV2 yes. you could use it directly or via Zigbee2MQTT, as I did (because I wanted to fiddle around).

Home Assistant

Home Assistant Connect ZBT-2

The easiest way to start with Zigbee or Thread is now even better.

I have this Home Assistant ZBT-2 in one house, and SONOFF ZBDongle-E in another and both are working OK with Zigbee2MQTT. Mostly plug&play (just the setup is not very straightforward - but manageable), definitely good after setup.

yes, fine on my Mac and on iOS 26 as well.

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.

@toggledbits are external Zwave controllers supported via USB? that could be another route, as in the old Vera days.

@tunnus I see there's a beta for C8. The point is to just take a NVM backup in the format supported by ZwaveJS. after that, it's a breeze to restore it on a new controller, if you have a minimum SDK/fw version, as mentioned in the ZWA release notes.
It's wort a try, if you have lots of Zwave devices and unpair/repair them is out of question for you.
I'm still on my original ZWave network I built in a previous house 10+ years ago - and that's a testament to the enormous flexibility that Zwave offered me in the last decade.

@tunnus if you could install ZwaveJS on your c8, just backup the nvm, take the file and restore it on your final controller. Easier than you’d think. Secondary controllers promoted to primary are always a mess in my experience.