Run devices independently from HA

Essentially, before buying devices, what considerations should I make to ensure they can continue operating independently from the main HA / RPi unit, in case it is down / broken / rebooting / etc?

This applies across all categories, though I expect lighting to be the primary use-case.

Similarly, the state of devices will need to be known by HA at all times, to allow full independent use even if HA is operational. Most common example would be someone manually flipping a light switch.

Is it protocol-specific, i.e. always use Z-wave or zigbee or wifi devices?

I have MQTT broker and Maria DB database running on a seperate machine to HA, that way I can tinker with HA and reboot it, but I’m still able to use MQTT to operate devices. :slight_smile:

Thanks @Codec303

I was referring more to the type of devices themselves and how they wired up / connected to both the physical world as well HA (and associated software, like MQTT, etc).

Where is MQTT used within the HASS world? Only for Zigbee devices?

MQTT is every where.

I have light switches that use MQTT for HA but the switches work independently of HA. MQTT will notify HA of the state change if I click the switch manually.

I have a separate Raspberry Pi connected to my garage door that runs MQTT that I can open/close and see the state of with or without HA.

Will soon have a sensor the check my water softeners salt level. It will run MQTT to notify HA or any other device that I connect to it’s MQTT topic.

I don’t have any Zigbee devices

It’s protocol specific, generally

For example, with Z-Wave you can use Association (where supported) to have one device directly control another. Other protocols may have similar functionality, but not all.

Most IOT manufacturers offer a cloud interface and phone apps for controlling their devices. The problem is that their clouds go down, malfunction, or become inaccessible from time to time.

Some IOT manufacturers offer a local API, an MQTT interface, or some other way to communicate directly to their devices. This allows the use of a local dashboard like HA, but that too can go down, malfunction, or become inaccessible.

In the ideal world IOT manufacturers would offer both a cloud and a way to directly interface to their devices. There are some manufacturers who do this, but I could not find any manufacturers who I trusted with devices that I liked. My answer was to develop my own devices to monitor and control things around my home using MPUs from Particle.io.

Particle devices are VERY similar to Arduino, but Particle offers a cloud interface so each device that can be access by WiFi, wired ethernet, or cellular connections. This cloud supports connections to other web services like Google, PushBullet, and IFTTT. You can also use Particle librarys to enable MQTT and/or other communication protocols for local use. Particle’s third generation devices can also communicate with each other via a self-healing mesh network.

If you would like to see an example of Particle code, I have a project on GitHub that:

  • Monitors a temperature sensor.
  • Monitors and toggles a relay.
  • Monitors the Particle device itself (along with its attached LiPo battery).

The project includes:

  • HTML to control the relay via the Particle Cloud
  • YAML sensor and switch settings for monitoring and controlling via HA and MQTT.

If you toggle the relay via the HTML, you’ll see the relay toggle on HA and vice versa. This is what the HTML interface looks like …
browserImage

I use MQTT mainly on Sonoff devices flash with the Tasmota firmware, but I also use NodeRED to send MQTT messages also. I use the Mosquitto MQTT broker, and it works great. :slight_smile:

I don’t use any Zigbee devices, Sonoff devices use Wifi

I’ve made sure that (almost) every device I use in HA can also be controlled independently of HA. And the ones that are in the “almost” category are some type of parallel add-on capability and still have the original functionality intact from outside HA.

I use Sonoff and Shelly MQTT switches for the majority of my controls and I have them set up to take a wall switch input that will switch the relay independently of the status of HA/MQTT. And that also goes for the balance if my controls that use Aeotec Z wave switches. IF HA or the Z Wave controller is down then the switches are still controllable though the wall toggle switch input to the device.

The only items that don’t have a “convenient” way of being controlled outside of HA are my 4 Sengled Zigbee bulbs and 2 GoControl Z Wave Bulbs. But those bulbs can still be turned into a dumb bulb by flipping the switch off & back on to manually turn on the bulb.

Don’t get me wrong I would lose all of the smart functionality I’ve incorporated if I switched off HA but even if I did my house would still function just like it did before I started with HA aside from a couple of extra switch cycles until I replaced the smart bulbs with dumb ones.

EDIT: I inadvertently lied to you…

I just recently switched from Tasmota/MQTT on my Sonoff/Shelly devices to ESPHome/API on those devices.

The basic end result is the same. Just the implementation is different.

@finity @Codec303 @rwpalmer @Tinkerer and any others I have missed. Thanks, all are really helpful and its the insights into common, reliable components that people are actually using that I am looking for.

I have actually ordered a single Shelly 1 for testing, as it is only cheap and I’m sure it would remain somewhere on the network, even if it doesn’t become the standard.

@finity is this the newer / better / easier method for deploying the Shelly 1’s now?

I’ve gone to using ESPHome for all of my ESPxx devices (Sonoff/Shelly/Nodemcu/etc).

the ability to completely bypass the MQTT broker and have a direct interaction to HA thru the API is neat.

However, you still have the ability using ESPHome to interact via MQTT as well if you want to use them that way. And having options is good.

And I know that Tasmota has been kind of considered the “gold standard” in the ESP device community, and i’m sure it’s still there to a degree but there have been a few rumblings recently abut it’s stability in some platforms so I figured I’d make the jump for all of those reasons.

I don’t know that I would call it “easier”, tho. Definitely the easiest integration for a Shelly in HA is using the built-in MQTT firmware and bypassing the Shelly Cloud service.

So if you decide to put your own alternative firmware onto the Shelly you’re going to have to make some connections to the GPIO pins. The Shelly1’s make it easy since the pins are already exposed with a header. I don’t have any experience with any of the others. The other thing that is nice about the Shelly1’s is that they have the wall switch input already pre-configured on the terminals.

If you go the Sonoff route you are going to have to do some soldering or some “fancy finger work” in order to make the connections from the programmer to the device. and then you need to get a little creative in order to use them with a standard wall switch since they don’t come configured that way out of the box like the Shelly. Not a huge deal if you already have the GPIO header soldered on for programming.

‘Independently from HA’

If you use MQTT or an IP path then do consider what happens if the MQTT broker or network transport fails. Secondary switches etc… Hardwired control is fundamentally dependable, MQTT offers decentralised control which can alleviate HA failure.

I love ESPhome also because you can bypass HASS itself!!

My HASS installation once in a while is offline, and that’s a big problem if I am not home when it happens (WAF problems) there are annoyances.

With ESPhome I use HTTP shortcut for sending POST URLs and works perfectly also without HASS

Could you tell me how you managed to integrate the Sengled bulbs into HA?
Did you flash tasmota/esphome?

I can’t find any info on them

When I paired mine a long time back I had to go to the services page and run the zha permit service. Then I powered on the bulb and it paired with the controller immediately.

There is no flashing required. And you can’t use tasmota/esphome anyway since the bulbs are zigbee. tasmota/esphome requires wifi devices.

Right, thanks.

I’m looking at Snegled as an option so don’t know much about them

I’ve got xiaomi products and the gateway. I’m assuming I’d have to have zigbee2mqtt or a zigbee stick to get them working then?

What are you using?

I use the HUSBZB-1 stick.

Even if you use zigbee2mqtt you will still need a zigbee controller to pair them with. zigbee2mqtt won’t work with the regular zigbee sticks like the HUSBZB-1. It takes a special programmable zigbee radio.

1 Like

Ok cool, so all I’ll need is a HUSBZB-1 stick…

Thank you very much

That’s what I’ve used for around 2 years now and it has worked fine.

1 Like

What about the range of the HUSBZB-1 would it be fair to say it’s the same as Xiaomi gateway at least?
Or will I need a repeater of some sort?

I don’t have a Xiaomi gateway so I have no way to compare the two but my furthest bulb is 30ft away and it works fine.

the other thing to remember is that zigbee is a mesh network and most (all?..) mains powered devices should act as a repeater anyway so you should be OK as long as one device isn’t unreasonably far away from the other devices in the mesh.

1 Like