[HowTo] Using HABridge with Reactor
-
If you’re like me and still running HABridge to control your devices locally via Alexa, you might need to tweak your endpoints to call Reactor via HTTP. Here’s the best way to do it, IMO:
Insert the Reactor Canonical ID (e.g.,
zwavejs>71-1) into the MapID field, but make sure it’s URL-encoded like this:zwavejs%3E71-1.Then, configure these endpoints as needed:
- On:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/power_switch.on - Off:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/power_switch.off - Dim:
- For lights:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/dimming.set?level=${intensity.decimal_percent} - For roller shutters:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/position.set?value=${intensity.decimal_percent}
- For lights:
- Color:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/rgb_color.set_rgb?red=${color.r}&green=${color.g}&blue=${color.b}
Just replace
[ReactorIP]with your actual IP address. By using these placeholders, you can standardize your endpoints across all devices, making maintenance easier.This setup works with any device mapped under MSR, regardless of the controller (ZWaveJS, Vera, HASS, OpenSprinkler, virtual, MQTT, DynamicEntities, etc.). If you need different calls, just go to the entities, get the action and parameters, and adjust accordingly. Enjoy super fast access to your devices via Alexa!
If you're migrating from Vera, the endpoints are (URL-encoded) in a file called device.db, in JSON format, under your config. You'd write a script to align the new endpoints to the new one, if you prefer to do it automatically. YMMV.
- On:
-
T therealdb referenced this topic
-
If you’re like me and still running HABridge to control your devices locally via Alexa, you might need to tweak your endpoints to call Reactor via HTTP. Here’s the best way to do it, IMO:
Insert the Reactor Canonical ID (e.g.,
zwavejs>71-1) into the MapID field, but make sure it’s URL-encoded like this:zwavejs%3E71-1.Then, configure these endpoints as needed:
- On:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/power_switch.on - Off:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/power_switch.off - Dim:
- For lights:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/dimming.set?level=${intensity.decimal_percent} - For roller shutters:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/position.set?value=${intensity.decimal_percent}
- For lights:
- Color:
http://[ReactorIP]:8111/api/v1/entity/${device.mapId}/perform/rgb_color.set_rgb?red=${color.r}&green=${color.g}&blue=${color.b}
Just replace
[ReactorIP]with your actual IP address. By using these placeholders, you can standardize your endpoints across all devices, making maintenance easier.This setup works with any device mapped under MSR, regardless of the controller (ZWaveJS, Vera, HASS, OpenSprinkler, virtual, MQTT, DynamicEntities, etc.). If you need different calls, just go to the entities, get the action and parameters, and adjust accordingly. Enjoy super fast access to your devices via Alexa!
If you're migrating from Vera, the endpoints are (URL-encoded) in a file called device.db, in JSON format, under your config. You'd write a script to align the new endpoints to the new one, if you prefer to do it automatically. YMMV.
@therealdb OK so I'm doing something wrong

Testing on my Garage lights which I believe has canonical ID
switch.garage_lights

Which I don't think needs URL encoding. (Well the URL encoder I checked didn't make any changes)
So I have this in my HA Bridge:
http://192.168.70.249:8111/api/v1/entity/switch.garage_lights/perform/power_switch.onOn testing HA bridge suggests all is well, but nada happens to the the switch
Reactor logs the request
[latest-25325]2026-01-05T10:48:19.404Z <httpapi:INFO> HTTPAPI(#1) API request from ::ffff:192.168.70.249: GET /api/v1/entity/switch.garage_lights/perform/power_switch.onI've set the type as HTTP in HA Bridge (and tried as Vera)
Please forgive my idiocy...
C
- On:
-
Sigh. People, let's make 2026 the year we stop posting one line from the logs. Almost everything we have in the logs requires context. Posting it up-front increases the chances that, if you haven't already figured it out yourself from what's there, someone else can without further back-and-forth in the thread.
Odds are, there's a bunch of interesting stuff following the line you posted, @CatmanV2 that tells how the system is responding to the HTTP request. Let's have a look at it!
-
Well, OK but I'm pretty sure there isn't (or I would have, or at least tried to diagnose it myself)
[latest-25325]2026-01-05T14:15:08.186Z <httpapi:INFO> HTTPAPI(#1) API request from ::ffff:192.168.70.249: GET /api/v1/netstatus [latest-25325]2026-01-05T14:15:08.193Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:15:41.714Z <Rule:INFO> Cinema Is Occupied (rule-m4ocf1di in Cinema Environment) starting rule state evaluation; because entity-changed BinarySensor#hass>binary_sensor_cinema_presence_presence [latest-25325]2026-01-05T14:15:53.631Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:15:53.635Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:15:53.638Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:15:53.643Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:16:03.261Z <httpapi:INFO> HTTPAPI(#1) API request from ::ffff:192.168.70.249: GET /api/v1/netstatus [latest-25325]2026-01-05T14:16:03.264Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:16:40.341Z <httpapi:INFO> HTTPAPI(#1) API request from ::ffff:192.168.70.249: GET /api/v1/entity/switch.garage_lights/perform/power_switch.on [latest-25325]2026-01-05T14:16:41.721Z <Rule:INFO> Cinema Is Occupied (rule-m4ocf1di in Cinema Environment) starting rule state evaluation; because timer-trigger Timer#rule-m4ocf1di [latest-25325]2026-01-05T14:16:41.722Z <Rule:INFO> Cinema Is Occupied (rule-m4ocf1di in Cinema Environment) evaluated; rule state transition from SET to 'RESET' [latest-25325]2026-01-05T14:16:41.729Z <Engine:INFO> Enqueueing "Cinema Is Occupied<RESET>" (rule-m4ocf1di:R) [latest-25325]2026-01-05T14:16:41.742Z <Engine:NOTICE> Starting reaction Cinema Is Occupied<RESET> (rule-m4ocf1di:R) [latest-25325]2026-01-05T14:16:41.743Z <HassController:INFO> HassController#hass perform power_switch.off on Switch#hass>switch_cinema_heater with { } [latest-25325]2026-01-05T14:16:41.744Z <HassController:INFO> HassController#hass service homeassistant.turn_off target data is { } (empty), assuming default entity target [latest-25325]2026-01-05T14:16:41.745Z <HassController:INFO> HassController#hass: sending payload for power_switch.off on Switch#hass>switch_cinema_heater action: { "type": "call_service", "service_data": { }, "domain": "homeassistant", "service": "turn_off", "target": { "entity_id": "switch.cinema_heater" } } [latest-25325]2026-01-05T14:16:41.754Z <HassController:INFO> HassController#hass action power_switch.off({ }) on Switch#hass>switch_cinema_heater succeeded [latest-25325]2026-01-05T14:16:41.756Z <Engine:INFO> Resuming reaction Cinema Is Occupied<RESET> (rule-m4ocf1di:R) from step 1 [latest-25325]2026-01-05T14:16:41.757Z <Engine:INFO> Cinema Is Occupied<RESET> all actions completed. [latest-25325]2026-01-05T14:16:53.631Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:16:53.637Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:16:53.640Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:16:53.644Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:17:08.399Z <httpapi:INFO> HTTPAPI(#1) API request from ::ffff:192.168.70.249: GET /api/v1/netstatus [latest-25325]2026-01-05T14:17:08.403Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:17:53.632Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>system [latest-25325]2026-01-05T14:18:03.470Z <httpapi:INFO> HTTPAPI(#1) API request from ::ffff:192.168.70.249: GET /api/v1/netstatus [latest-25325]2026-01-05T14:18:03.476Z <Rule:INFO> Internet Check (rule-m6z41xhd in Office Environment) starting rule state evaluation; because entity-changed System#reactor_system>systemApologies anyway
C
-
@CatmanV2 said in [HowTo] Using HABridge with Reactor:
(PS Cinema was occupied as the cat had just walked in there... )

Actually, what's not there is equally telling. The HTTP request itself probably returned a (failed) result code, so however you made that request, that's the tool that will log that result. The possible HTTP results for that endpoint are:
- 200: The request succeeded, which it did not, because the action itself would have caused more log info that we don't see here;
- 400: The request failed because the action failed. This is not it either, because that is also logged on the Reactor side, and we don't see it here;
- 404: The entity was not found. This isn't logged in Reactor, it's just a fast return.
It's a 404, because you did not give it a canonical ID for the entity in the request URL. A canonical ID includes both the entity ID and it's parent controller's iD — different controllers can have an entity with the same ID, so you have to specify which controller's entity you are targeting. Canoncal IDs take the form
controller-id>entity-id(note>between the two parts). The absence of this also explains why the URL encoder didn't make any changes, because that>must be escaped.So for troubleshooting API calls, remember, if it doesn't work, look at the Reactor log for messages; if nothing is logged on the Reactor side, look at the logs/messages for the tool that made the request to Reactor.
Ref: API docs
-
@therealdb OK so I'm doing something wrong

Testing on my Garage lights which I believe has canonical ID
switch.garage_lights

Which I don't think needs URL encoding. (Well the URL encoder I checked didn't make any changes)
So I have this in my HA Bridge:
http://192.168.70.249:8111/api/v1/entity/switch.garage_lights/perform/power_switch.onOn testing HA bridge suggests all is well, but nada happens to the the switch
Reactor logs the request
[latest-25325]2026-01-05T10:48:19.404Z <httpapi:INFO> HTTPAPI(#1) API request from ::ffff:192.168.70.249: GET /api/v1/entity/switch.garage_lights/perform/power_switch.onI've set the type as HTTP in HA Bridge (and tried as Vera)
Please forgive my idiocy...
C
@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

)