If you’re using node-red-contrib-home-assistant within Node-Red, to create the master/slave connections, it uses REST. In other words, Node-Red communicates the same was as a RESTful sensor (but with the added infrastructure of Node-Red itself).
FWIW, there’s an alternative version called node-red-contrib-home-assistant-websocket, created by @Kermit that addresses some of the shortcomings of using REST (by employing websockets). You can learn more about it here
There are many articles explaining the pros and cons of REST vs MQTT. Here’s one. Basically, if the need is to simply serve as a robust communications channel, MQTT is the better choice.
For the purposes of this discussion:
-
If you want a basic master/slave system with the least amount of additional infrastructure, then go with @jimpower suggestion and use a RESTful sensor.
-
If you want to use a better communications technology, install an MQTT Broker and use MQTT Statestream (see my device_tracker example above). Use the
includedirective to specify only what is needed to be shared with the slave system. -
If you also want to transform or manipulate the data sent between master and slave, then install Node-Red and node-red-contrib-home-assistant-websocket. Proceed to create a flow that connects the master to the slave and manipulates the payload. If you do not intend to alter the payload, then Node-Red only serves to provide a visual representation of the master-slave connection.
I use an MQTT Broker and Node-Red to interconnect three Home Automation systems (Premise Home Control, Home Assistant, and openHAB). Home Assistant and openHAB talk directly to the MQTT Broker whereas Premise Home Control relies on a Node-Red flow to convert its data from a TCP channel to MQTT (and vice-versa).
