n8n with Home Assistant and ioBroker: Automating Building Technology in Operation

n8n can be connected to Home Assistant and ioBroker, though not via a single built-in trigger for state changes. The native Home Assistant node in n8n currently offers no trigger that reacts to a state change, which is why the push direction has become the standard approach in practice: Home Assistant triggers an n8n workflow via an automation and a webhook call, and n8n writes back when needed via the REST Command integration or a direct API call. For ioBroker, the connection works through the official REST API adapter with Basic or Bearer token authentication in both directions. For access control, heating control, or alarm forwarding in a company building, this push/pull pattern is generally sufficient. As of: August 2026.

How does Home Assistant trigger an n8n workflow via webhook?

Home Assistant sets up the webhook endpoint automatically as soon as you create an automation with the trigger type „Webhook" and assign it a webhook ID. The call is made at the address /api/webhook/<webhook_id>, with the documentation explicitly recommending PUT requests; GET and HEAD requests are only allowed if you explicitly enable them via the allowed_methods option. By default, the local_only option restricts access to the local network or the Nabu Casa cloud, which you should generally leave unchanged for a purely in-house automation. Depending on the content type, the data sent in the automation is available either as trigger.data (form data) or trigger.json (JSON, when the content type application/json is set). On the n8n side, a regular webhook node with the appropriate HTTP method captures this request, including the usual separation between test and production URLs. Details on trigger configuration can be found in the Home Assistant documentation on automation triggers.

Why isn't the native Home Assistant node in n8n enough on its own?

The native node does not cover a trigger for state changes, which is repeatedly described in the n8n community as a central gap when switching from Node-RED. Users report a lack of entity selection via dropdown there, meaning entity IDs have to be transferred manually between the two systems, and cite interval-based polling of the REST API as the only workaround, which is impractical for time-critical building events. A generic WebSocket node was discussed but not implemented as a built-in solution. For operation, this means: rely on the push direction via webhooks instead of polling, and call the appropriate Home Assistant services to switch devices instead of setting states directly, as the latter reportedly does not reliably reach all devices according to community reports.

How does n8n receive the events and how does it write back?

The webhook node in n8n supports the HTTP methods DELETE, GET, HEAD, PATCH, POST, and PUT with a maximum payload of 16 MB, which is sufficient for sensor and event data from building technology. For the way back, n8n calls Home Assistant's rest_command integration via an HTTP Request node, which provides regular REST calls as callable actions and makes URL, HTTP method, header, and payload configurable; the response delivers status code, return text, and headers for further processing. For authentication against external systems, the n8n documentation recommends using predefined credential types where available and otherwise falling back on generic methods such as header or OAuth2 authentication. Details on methods and payload limits can be found in the n8n documentation on the webhook node.

How do you connect ioBroker via the REST API?

The official ioBroker.rest-api adapter provides a Swagger interface and supports three authentication methods: credentials as query parameters, Basic authentication via the Authorization header, or an OAuth2 bearer token from its own endpoint. States can be set the classic way via GET with a value parameter, which the adapter supports for compatibility reasons with the older Simple API, but which is marked as a legacy method in the current documentation. POST and PUT are available for structured write access, where POST creates a resource regardless of duplicates and PUT checks for its existence beforehand. In n8n, you map this via an HTTP Request node that reads states or writes them via setState with the val and ack fields. Details can be found in the README of the ioBroker.rest-api adapter.

For which scenarios in operation is the combination worthwhile?

For access control, a pattern is suitable in which a door sensor or card reader triggers a webhook automation via Home Assistant, and n8n logs the event and notifies the administration if needed. For heating control, the reverse path is suitable: a time-triggered n8n workflow calls the rest_command integration or the ioBroker adapter to set target values for individual zones. For alarm forwarding, a combination of both is recommended, where Home Assistant reports security-relevant events to n8n via webhook and n8n handles the escalation via email, Microsoft Teams, or a ticketing system. It is important in all three cases that security-relevant actions such as unlocking doors are not triggered directly via webhook, as the Home Assistant documentation also explicitly points out. If you want to firmly anchor and maintain such automation in operation, NordFlux supports you in building n8n workflows.

Frequently asked questions about n8n with Home Assistant and ioBroker

Can n8n react directly to a state change in Home Assistant?

No, the native Home Assistant node in n8n currently offers no built-in trigger for this. In practice, the connection therefore runs in the reverse direction: Home Assistant actively reports events to n8n via webhook, instead of n8n continuously polling the state.

Which HTTP method should the Home Assistant webhook use?

The Home Assistant documentation explicitly recommends PUT requests for webhook triggers. GET and HEAD requests only work if you additionally enable them via the allowed_methods option.

Is ioBroker's REST API secure enough for production use?

It is, provided you enable Basic authentication or an OAuth2 bearer token instead of passing credentials unencrypted as query parameters. For operation on the company network, you should also run the adapter behind a reverse proxy with HTTPS.

Do I need a separate n8n workflow for every device?

No, it is common to use a central webhook workflow that routes incoming events to the appropriate processing logic via a switch or IF node based on the payload content. This keeps maintenance manageable, even when several dozen sensors and actuators are connected in the building.