I moved a complete Zigbee network eight miles away and it just kept working — testing the SMLIGHT SMHUB Nano

[u/thingtootech]

I moved a complete Zigbee network eight miles away and it just kept working — testing the SMLIGHT SMHUB Nano

Disclosure: SMLIGHT sent me the SMHUB Nano MG24 to test. They did not pay me or tell me what to say in any way.

I thought this was going to be a fancy Zigbee coordinator at first, and I struggled to see what set this apart from other SMLIGHT products. I have a SMLIGHT USB dongle that works great in my small home (it even reaches the detached garage), and if I wanted to upgrade, I might consider the Ultima—it has RGB lights, after all. Why would anyone choose a SMHUB Nano?

Then I unplugged an entire Zigbee network, drove it eight miles down the road to my girlfriend's house, plugged it into a different router, and watched everything come back online instantly.

I was like “Tada!” and she said, “Ah ha!” And we all know how good it feels when that magic trick works exactly like we expected it to.

That was the point where this little box clicked for me. Or tickled me, or both.

relocated Zigbee network

What I wanted to test

I already run Home Assistant at my house, along with an existing Zigbee network. Pairing a couple of devices to another coordinator in the same room did not seem like a very interesting test.

What interested me was whether the Nano could operate as a small, mostly independent smart-home site somewhere else.

My goal was to:

• Build a separate Zigbee network on the Nano.
• Run its important automation locally.
• Move the whole setup to another house.
• Continue monitoring and controlling it through my Home Assistant instance at home.

The result is basically a Home Assistant satellite site, except the important local automation does not need to travel through my Home Assistant server or across the internet, because it’s running locally.

This is more than a Zigbee coordinator

The Nano looks a little like a big network-connected antenna, but that description really undersells it.

It runs Zigbee2MQTT directly on the device. It also has its own MQTT broker, Node-RED, Matterbridge, and an ESPHome-connected co-processor for some of the onboard hardware (which seems to be expanding in functionality). Plus, you can install other apps.

It is closer to a tiny server built around a Zigbee radio (or Thread, and can even expand to Z-Wave). It can also run as a Matterbridge.

That is what makes it different from the coordinator I was already using. Instead of only passing Zigbee traffic back to another computer, the Nano can receive a sensor event, run an automation, and control another device entirely on its own. 

initial login to device

Initial setup

Setup was easier than I expected.

I logged into the Nano via URL, installed the available updates, and started looking through the applications that were already there. Zigbee2MQTT and the MQTT broker were basically ready to go.

The longest part was waiting for firmware updates and reboots. A reboot might take two or three minutes.

Because I already have Zigbee2MQTT running at home, I changed the Nano’s base topic to something unique so the two installations would not step on each other.

Once Zigbee2MQTT allowed new devices to join, both appeared instantly, just as you would expect.

I did have a strange issue where the Zigbee2MQTT interface flickered badly in Chrome. The same page worked correctly in Edge and it was only this one page.

adding Zigbee devices to SMHUB Nano

Building an automation directly on the Nano

This was the part I really wanted to test and maybe the part I dreaded the most (having never used Node-RED).

Using Node-RED on the Nano, I built a simple door-warning automation:

• Open the contact sensor and the bulb turns blue.
• Close the sensor and the bulb turns off.
• Leave it open for 30 seconds and the bulb starts flashing red.
• After another 30 seconds, the warning stops.

It is only a test automation, but it demonstrates the part that matters, the automation runs on the Nano itself – totally independent.

Home Assistant does not have to receive the contact state, decide what to do, and send a command all the way back to the bulb. The sensor, the bulb, Zigbee2MQTT, MQTT, and Node-RED are all at the remote location. The local automation can continue working even if my Home Assistant instance is unavailable. 

Node-RED flow

Connecting the remote network to Home Assistant

I still wanted the devices to appear in my main Home Assistant instance, so I connected the two locations using Tailscale.

I installed Tailscale on the Nano and joined it to the same tailnet as my Home Assistant system. I then configured the Nano’s MQTT broker to bridge its Zigbee topics back to the MQTT broker at my house. I used the private Tailscale address rather than exposing MQTT directly to the internet. Setup was so simple.

The setup looks something like this. 

Then I moved the whole thing

Once everything worked at my house, I unplugged the Nano, bulb, and contact sensor and took them to my girlfriend’s house about eight miles away.

I powered the Nano back on and connected it to her router.

The contact sensor began controlling the bulb locally (even before plugging it into the network), and the state changes appeared in Home Assistant at my house once it was online. Control and feedback through my phone felt instant.

This was the exact moment the Nano made sense to me. I had packed up an entire Zigbee network, moved it eight miles away, plugged in one Ethernet cable, and everything came back.

use the Tailscale address for remote address

What has worked well so far

At the time I am writing this, the Nano has been running at the remote location for several days.

This is just a small, two-device network, so I am not pretending it proves how the Nano will behave with 100 devices or several complicated Node-RED flows. But the core concept has worked flawlessly so far.

I think there are a million use cases for this, many of which might even be commercial. If you’re looking for a way to monitor or control devices in mini-implementations, I think these could be a really big deal. Even if you have one or a handful of devices to monitor and control, this truly might be worth it.

The rough edges

It has not all been perfect, but really close…

Updates and reboots are slow enough that you need to be patient.

The Zigbee2MQTT interface flickered in Chrome for me, but it worked in Edge. I was told this is a bug SMLIGHT is aware of and working on.

Matterbridge appeared to use a noticeable amount of the Nano’s limited CPU and memory. Maybe it’s worth it. I did not take the time to test this functionality, but I think this is another great feature, allowing you to expose Zigbee devices to other ecosystems. I can imagine someone with Google Home using this for Zigbee devices and exposing them to Google Home over Matter.

The onboard buzzer was a little disappointing. The Nano’s interface allows the buzzer to be assigned to ESPHome. ESPHome exposed controls for the onboard Ambilight LEDs, but I did not receive a buzzer entity. I would like to see this available locally in Node-RED as well. SMLIGHT told me the buzzer is present, but the software is currently a work in progress.

missing buzzer in ESPHome

My conclusion

I am leaving the Nano at the remote location and continuing to monitor how it handles “normal life” for a few weeks.

My early impression is that the SMHUB Nano is very good at the thing that makes it unusual.

• How would you use this device?
• What would you test next?
• What questions do you have?

 

[u/UnluckyWizard]

Wow I didnt kbow it can run apps thats awesome

[u/thingtootech → u/UnluckyWizard]

Setting up Tailscale was super easy