I'm not buying any device that's not 3, everything else turns into a brick as soon as there's some larger change.
I have some older Google Speakers, and while they seemed to be 2, after being powered off for long enough they can't be set up again, not even with internet access since their firmware was also outdated and the app isn't able to set them up again.
Same here. My gold standard for this is hardware that comes with the open source Tasmota firmware (or which can be flashed to Tasmota). All 75 light switches in our new house run Tasmota firmware and to me it's the perfect combination of simple, flexible and yet deeply powerful. Devices can be controlled via MQTT, web requests, webUI console or serial and not only does it avoid any cloud dependency, Tasmota devices aren't even dependent on having a router to coordinate locally with each other! They can be set so that if they don't see a wifi router, they'll form an ad hoc mesh network.
To me, this is the ultimate in reliability because even if the internet connection is offline, even if the Home Assistant Raspberry Pi crashes, even if the wifi router crashes - as long as there's power, the lights will still always communicate and work together in their device groups. When we built the house I just ordered cheap ($15) wifi light switches from Amazon, flashed them with Tasmota, configured their device groups, labeled where they went, and gave them to the general contractor's electrician, who knew nothing about home automation. So we didn't pay anything extra for special installation, design or programming - in fact we got a $5 per switch discount because they didn't need to supply the dumb switches.
The only slightly tricky part was convincing the very old-school electrician he didn't need to run traveler wires for all the three, four and five way switches. Even after I explained it to him, he didn't quite believe me that they would work so he could test them with just his temporary construction power in an unfinished house with no internet, wifi or controller hardware. I just told him to start by installing the fixtures and switches for a hallway and he was amazed when switches along the hallway controlled fixtures they weren't connected to - including sharing dimming memory and the behavior of the micro-LED strip on each light indicating brightness and status!
Yeah, it's actually amazing I was able to buy 75 little computers with their own buttons, LEDs, wifi and internally hosted HTML pages for $15 each delivered overnight.
But yeah, building a custom house. It's definitely not for the faint of heart. Having done it now, I like to advise "If you're someone with the resources to build your own custom home, you'll find the experience transforms you... into someone who no longer has the resources to even build a garden shed." :-)
To be fair, we knew this going in and only did it because we happened to have access to a deeply experienced general contractor who'd built high-end custom homes for several friends of ours over the past 15 years. And he has his own dedicated crew, most of who have worked only with him for much of that time. Although he wasn't the cheapest (nor the most expensive), he had an extremely impressive, personally verifiable track record. That's very rare to find, and without it, we probably wouldn't have even considered doing a custom home. And he did complete the project nearly on time and nearly on budget - and COVID happened during the build. Everyone else we know who was building a home during COVID ended up at least a year late and >40% over budget - so, even though technically a little late/over budget, the guy delivered at a near-miraculous level given the circumstances.
Tasmota runs on hundreds of different devices including switches, plugs, buttons, power strips, sensors, IR & RF gateways, etc. Tasmota homepage: https://tasmota.github.io/docs/. There are over 2800 devices listed in this user maintained repository: https://templates.blakadder.com/.
Three years ago when I was choosing devices I initially ordered a Kasa switch to try but after a little research quickly realized I didn't want any cloud-locked proprietary devices installed in my home's walls. So, I sent the Kasa switch back unopened and chose this dimmer switch on Amazon because it could be flashed with Tasmota firmware: https://www.amazon.com/TASMOTA-Martin-Jerry-ESP8266-Assistan... (now $20 each in a three pack). https://templates.blakadder.com/martin_jerry_MJ-SD01.html. Ultimately, almost all these devices are commodity components based on standard reference designs. Various off-shore manufacturers will put these in their own different plastic designs with slightly differing button, light and other features. Kasa just happens to only offer their flavor locked to their proprietary app, cloud and services. Even if they are benign today, that can always change without notice and they won't be in business forever.
As you'll see on the user repository, Tasmota supports all this different hardware by grouping them into type classifications and then within each type using a configuration string. The MJ-SD01 switches I bought are Type 73 which is a PWM Dimmer. The configuration string is listed on the page I linked and specifies which pins are used for input, output and what they're connected to (buttons, LEDs, dimmer, etc) because this is something various manufacturers often do differently. Everything needed to make generic Tasmota work on any device listed in the repository is in the config string on its repository page. Just copy and paste that string into the device's Tasmota Config web page and the buttons, lights and loads will be mapped to the correct pins.
These Martin Jerry switches now come with Tasmota firmware pre-installed but they did not three years ago, so we had to open them and temporarily solder three wires to the board to upload the firmware using a USB-Serial adapter. I used it as an opportunity to give my middle-schooler some practical soldering experience. This was a one-time requirement because once installed, Tasmota firmware then can update itself via wifi. Fortunately, lots of devices come with Tasmota pre-installed now. Here's a partial list: https://templates.blakadder.com/preflashed.html but you can just search Amazon, eBay and AliExpress for "Tasmota" to find others.
I chose this particular switch because it fit the modern style of the house we were building, has three primary buttons (plus a tiny reset button just under the rocker) and unobtrusive LED indicators. Today there are many other similar switches available with different looks and features and I might choose differently now. Under Tasmota the three buttons and LEDs have sensible defaults but can optionally be assigned to any functions you'd like on the device, on other devices or to anything else under Home Assistant control via press, long press and double press. One thing to keep in mind about these (and similar) switch devices is that the "front-end" of the button controls and LED display are entirely separate from the "back-end" of controlling the attached AC power load such as a light fixture. By default the buttons are mapped to control the device's own load just like a normal 'dumb' switch, but this can easily be customized. I have some switches whose front buttons control loads connected to other switches but not the load connected to that switch. And I have some switches that don't have any AC fixture connected to the output. I use those to do things like control low voltage landscape lights connected through a Tasmota wall power plug in a panel outside the house. I suggest keeping it simple when you start by sticking to the defaults, just be aware that you can later do all kinds of creative and unexpected things because Tasmota is so flexible.
Sir, take it from a random person on the internet, you're more than kind. Thank you so much for the details and bits of your own experience to make it relatable.
Even though I have many Kasa switches I do want the option 3 that was raised earlier. Again, many thanks.
If they're the older Kasa bulbs/switches (before they got all Matter), they have a dead simple local, MAC-addressed TCP packet protocol. I've implemented basic ON/OFF commands in ESPHome C++ code, but there's also a command line tool: https://github.com/python-kasa/python-kasa?tab=readme-ov-fil... There's a list at the bottom of supported devices.
Last used the command-line utility with a PowerShell script to make the lights in the playroom do a rainbow-random color dance party for the kiddos. Was nice to crank out a working automation in 2 minutes.
I have a bunch of Kasa devices. I got them before Tasmota was really on the scene, because they are configurable and controllable without Internet access. The protocol could be better, but it does work. I've heard that TP-Link may have changed the protocol since then (at least on some devices), so YMMV.
Total stab in the dark here, but it could be the local time on the device. Your local clock needs to be relatively close to the actual clock. I've run into this more than a few times with an old Surface Tablet I seldom use. Powered off/battery dead, clock gets out of sync. Power on, cannot get online because everything is TLS/SSL now, even clock sync. Cannot even sync the clock, because of certificate issues. Manually set the time to approximately correct time has resolved my issues with long powered off devices. That is, assuming of course, the _ability_ to set the time on the device.
> but it could be the local time on the device. Your local clock needs to be relatively close to the actual clock.
Yes, this is one of those nasty hidden costs that the "just use TLS/SSL for everything, it's easy!" people don't seem to recognize - introducing certificates to the mix suddenly makes your application coupled to wall clock time being in sync with the rest of the world. That is a big step in complexity right there - as everyone who ever had a clock drift couple minutes off the rest of the world, and saw half of the Internet stop working for them.
(And don't get me started on getaddrinfo(), another step function in complexity, hard-coupling even most trivial software to a heap of things that isn't relevant to it at all; or how it all interacts with SSL.)
I have Hue lights, they're nice, always just work. But now (some time back) they suddenly require an account and I get ads in the app. I have always easily moved Hue lamps from the Hue bridge to the Home Assistant SkyConnect (now called Connect ZBT-1, much better ahum). I sleep better because I know I can do this.
Yeah I also use Hue lights, but since I don't use a Hue bridge and simply use Zigbee directly the lights have no internet access and I have no restrictions on usage.
That’s why I’m sticking to Zigbee as much as possible. The only place where there’s an internet connection is at the Home Assistant computer which has a Zigbee USB stick.
I settled on Zigbee for door, window and some motion sensors, stand-alone buttons and other devices that need to be battery powered but for everything that's built into a wall or perma-attached to an outlet (like light switches, dimmers and wall plugs) I use generic commodity hardware running open source Tasmota firmware. These devices are based on standard reference designs, made by multiple Shenzen manufacturers and dirt cheap via Amazon, eBay and AliExpress. They're mostly based on ESP-8266 or ESP-32 chips and communicate via wifi.
The reason I use wall-powered wifi devices alongside Zigbee is the Zigbee architecture was designed to enable tiny battery powered devices that can run for a year or more on a small battery. Zigbee does this really well but I didn't want to be changing batteries on nearly a hundred wall switches, plugs and sensors that are connected to 110V anyway or perma-installed in places where wall power was easy to supply. There are also many devices like ultra wide band motion sensors, RF bridge repeaters, etc that can't be battery powered for long periods.
This Wifi+Zigbee split architecture has worked flawlessly in both our primary residence and a vacation home but they are both large detached homes, well-covered by wifi mesh routers with wired backhaul and other 2.4Ghz wireless neighbors a hundred or more feet away from our outer walls. So it's important to test wireless range and environmental compatibility inside your specific wall construction and unique RF domain before settling on wireless standards and architecture and installing a bunch of devices. Also, I'll mention that it's always tempting to just use wireless backhaul because it's easy but I think a big reason my large, complex home automation installs have avoided issues with randomly varying latency and intermittent signal loss is that I put in extra effort to get gigabit wired backhaul to each wifi mesh node and wired a Zigbee node alongside each wifi node. This entailed getting creative, like using an old pre-existing coax cable run with a Docsis modem to one mesh node and powerline ethernet to another. I'm pretty sure that extra pain up front prevented a lot of niggling gremlin pain later.
Zigbee has hardwired switch options so you aren’t replacing batteries, but I haven’t done a lot of them because they’re far from dirt cheap. Only in places where I find automations or smartphone control to be particularly useful, or where existing dimmers died and I figured I might as well upgrade.
Inovelli Blue are the ones I’m using, but at $50 each they’re competing against products like Lutron Caseta.
In some other places where it’s not just wanting the zigbee control, but also that the hardwired switch is in a stupid location, I’m using IKEA’s RODRET remote combined with their relatively cheap Zigbee bulbs, instead of Zigbee wall switches. They run on AAA batteries and seem to last quite a while, but I can’t say how long yet.
For plug-in lights where you just want on/off (garage strip lights for instance) their TRETAKT Zigbee outlet is a steal at $7. There’s a fancier version with energy monitoring too.
I sleep a little better knowing all my line voltage devices are from real brands with UL or equivalent testing, and the only cheap parts from mystery vendors with unknown certifications are 3V coin cell door sensors.
Actually, the non-battery-powered devices are the important part of Zigbee network. In Zigbee network, only coordinator and router can * route* the tracfic, others device can only send or receive. So if there is no other router or only few router, the Zigbed network will degrade from mesh topology to star topology. Because of power limit, the battery-powered devices are not suitable for router role so they almost is an end device. The AC-powered devices normally do router role.
This is why I haven't fully bought into Zigbee for any device that could possibly be wired and Wifi. I've already invested considerable money building a 2.4G (5G, really) wireless network: why not throw a few more relatively quiet devices on there. Zigbee is on the overcrowded 2.4GHz spectrum anyway.
Slightly off topic but I just bought an inexpensive water leak monitor set and it uses LoRa — I’ve had range problems with other bands “Extremely Long Range: Powered by LoRa technology, the long-range low-power system offers the industry’s longest receiving range (1/4 mile). Areas such as basements and sheds connect up to 100 sensors to deliver product information smoothly.”
LoRa sounds like a good idea for water sensing in particular. Water catches all radio signals at 2.4 GHz and turns the waves into heat (that's why microwave ovens work, after all), so spread-spectrum transmission seems like a good way around that issue. I would test the transmission range in a bathtub.
Most devices are in the category 3, except for BLU that are currently in 2. I have almost 1 of everything they make and I did set up the BLU ones using 2 with their app, I did not test to see if their app works without Internet, but I doubt the BLU can be configured without their app.
I learned my lesson with LIFX light bulbs. Luckily for me I was able to find an old version of the Android app. Manually installed it, and was able to rescue the few I have.
These days I’ve found that when in doubt get the device that is home kit approved. That usually ensures local only control. You have to fake it with home assistant, but it can be done with little fuss.
When it's cheaper to replace device 2 than get device 3 I guess walling it off in a subnet makes sense. These devices need to get replaced eventually anyway so unless the manufacturer goes under in a year or two of purchase IDK really.
Depends on the kind of device though - I'm not so keen on changing switches for example and would not compromise there. But cameras or robot mops or voice assistant, throwaway stuff after warranty expires no matter who the source is.
I have some older Google Speakers, and while they seemed to be 2, after being powered off for long enough they can't be set up again, not even with internet access since their firmware was also outdated and the app isn't able to set them up again.