I would like to run some Zigbee sensors (temp, motion, etc) at a second location and pick up the values on my home HA currently running Zigbee2MQTT with a local adapter. For simple sensor data I’d prefer not to get a second HA setup.
I was thinking about a Sonoff Zigbee Bridge with Tasmota in the hope it could send the MQTT messages to an external broker (Hive, Flespi), but it looks like the regular Tasmota MQTT broker setup is not included in favour of listening on local port 8888 since the bridge is expected to usually be on the same network as HA.
Does anyone know if this might work:
set up Dynamic DNS on the remote router and port forward to the bridge at 8888 so I now have a fixed IP address;
set up a second Zigbee2MQTT addon (using the trick of slightly altering the repository URL);
then point the Zigbee2MQTT to the REMOTE_IP_ADDRESS:8888 ?
You sure need to try. It does not seem impossible. Maintaining the connection between Zigbee2MQTT and the bridge will be the problem. Or you could try the Zigbee2Tasmota.
Thanks, you’ve sparked a thought. All the Tasmota flash guides are directed towards further reconfiguring to convert the bridge to a TCP listener for use with ZHA/Zigbee2MQTT on a local Home Assistant. I’ve dug around a bit further and found one guide this one that seems to suggest the Tasmota MQTT configuration is still there. If it’s the same as other individual Tasmota devices I’ve used then I might be able make it work with the public MQTT broker (flespi) and Zigbee2Tasmota options. I may buy a ZBB bridge just to see if I can make that work.
For others who might have my original problem - reading a set of sensors at another location in the simplest way possible - I’ve had some success so far. I set up Tasmota on a Sonoff Bridge, pointed it at a public MQTT broker to publish topics, then subscribed to those topics using the the MQTT nodes in Node Red on my Home Assistant. This was mainly to avoid having to buy more hardware and set up another Home Assistant and deal with VPNs,etc. The only hardware required was the Sonoff Bridge, Zigbee sensors and an internet connection.
I bought a Sonoff Zigbee Bridge Pro, quite a neat box, and flashed it with Tasmota using Tasmotizer:
The online guides I found were clear, but pinouts for flashing with the FTDI all seemed to be for the old version. They are labelled clearly enough.
Don’t forget to short GPI00 to Ground momentarily at power up to set Flash Mode.
Make sure to use tasmota32-zbbrdgpro.bin, not tasmota-zbbridge.bin if you have the Pro version.
Once Tasmota is set up the Zigbee Join and Map buttons will be greyed out until you flash the Zigbee coordinator firmware. I followed NotEnoughTech’s guide but found the required files and partition sizing were already included with the latest Tasmota package so only the Berry Script commands had to be followed.
SInce it is just sensor data, I used Flespi.io as the public broker. As part of the setup it creates a unique token to use as a user name, no password. Use that token for the username in the MQTT setup in Tasmota pointing to mqtt.flespi.io Port 1883 to publish MQTT topics. I also used “setOption89 1” in the Tasmota Console to publish unique topics with the sensor ID, rather than as one stream, to help parse the data.
I mainly use Node Red for automations and it has the handy feature of being able to subscribe to more than one MQTT broker. Setting up an MQTT IN node I was able to connect to Flespi, subscribe to my topics, parse them,then publish to the Home Assistant Broker after setting up matching MQTT sensors and an MQTT OUT node.
It’s been stable for 2 days. I’m sure there is latency but that isn’t a critical factor. I’ll leave it to test for a few more and report back if there are issues.
For anyone who might read this, I ran into a bit of an odd problem with the public MQTT broker Flespi.io changing the device IDs in the messages from the ones coming out of the ZBBridge, throwing off my filtering. IE if it left the bridge as TELE/DeviceABC/SENSOR/Data it might come in as TELE/Devicea12/SENSOR/Data. There is probably a persistence setting in Flespi.io that I could not figure out. Instead, I used the console commands in Tasmota to setOption 89 0 and setOption 83 1 to stop creating a unique message for each device and to use the device friendly name in the message. It took me a while to figure out how to parse the incoming messages in Node Red but below is a screenshot of the settings. The key was to compare msg.payload to msg.payload.ZbReceived[“Device_Name”] ie msg to msg rather than the common msg to string.
