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.
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?
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.
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 ā¦
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.
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.
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.
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.
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.
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.
