Home Assistant, Tasmota, ESPHome, and Zigbee2MQTT all converge on MQTT. Teams migrating from YAML automations to Nodlyn often ask: “How do we keep our topics and still get visual workflows, approvals, and audit trails?”
This post is about integration strategy — not duplicate connector documentation. For node properties and outputs, see the Knowledge Base: MQTT Event and MQTT Publish.
Why ecosystems standardise on MQTT
Each stack uses slightly different topic trees, but the transport is the same:
- Home Assistant —
homeassistant/…discovery plus device topics - Tasmota —
cmnd//stat//tele/prefixes - ESPHome —
<device>/sensor/…and…/switch/…/command - Zigbee2MQTT — friendly names under
zigbee2mqtt/<name>/
Nodlyn does not replace your broker — it sits beside it as an orchestration layer: complex branching, ERP hooks, PDF generation, approval gates, and runtime export that YAML alone struggles with.
Migration playbook
1. Inventory existing topics
Export your HA automations or grep Zigbee2MQTT logs. List triggers (incoming topics) and actions (outgoing topics). Map each to a Nodlyn trigger or publish step.
2. Start with read-only parity
Clone one sensor → notification flow using MQTT Event. Run Dry Run and compare payloads with your legacy automation for a week before switching writes.
3. Add cross-system steps
Once parity is proven, add steps MQTT-only stacks cannot easily do: Salesforce case creation, signed HTTP callbacks, Modbus writes, or multi-workflow bundles on a gateway.
4. Deploy headless
Studio stays on an engineer laptop; production runs on Runtime at the edge next to the broker. External systems can still trigger flows via Event Ingress.
Example: motion → light → ticket
Warehouse bay motion (Zigbee2MQTT) should turn on a Tasmota relay and open a Facilities ticket if the bay stays occupied after hours.
- MQTT Event on
zigbee2mqtt/motion_bay3 - Condition on payload
occupancy - MQTT Publish to Tasmota
cmnd/bay3_light/POWER ON - Schedule check + HTTP to ticketing API if still occupied at 22:00
Topic strings and broker host live in global variables so facilities can retarget bays without redeploying graphs.
Operational lessons
- Broker auth — use per-client credentials; runtime agents store secrets in the exported manifest (treat ZIPs as confidential).
- Retained messages — great for last-known state, dangerous for stale commands; use retain only where the device spec requires it.
- Wildcards —
+/temperaturesimplifies multi-sensor graphs; narrow subscriptions in production to reduce noise.
Further reading
- Three MQTT patterns for factory & edge
- Device Discovery — find MQTT brokers on the LAN
- Device Discovery deep dive (blog)