In my opinion this is not Xiaomi into Home Assistant (HA). To me, an integration would mean that I need nothing from Xiaomi, all activities are within HA.
from the Github page[0]:
> Xiaomi Home Integration and the affiliated cloud interface is provided by Xiaomi officially. You need to use your Xiaomi account to login to get your device list. Xiaomi Home Integration implements OAuth 2.0 login process, which does not keep your account password in the Home Assistant application. However, due to the limitation of the Home Assistant platform, the user information (including device information, certificates, tokens, etc.) of your Xiaomi account will be saved in the Home Assistant configuration file in clear text after successful login. You need to ensure that your Home Assistant configuration file is properly stored. The exposure of your configuration file may result in others logging in with your identity.
I think (some correct me) you can group most devices into the following categories:
1. Device requires internet for setup, and for usage
2. Device requires internet for setup, but after that don't need it anymore
3. Device can be fully setup without internet, and used without internet
Personally I aim to be fully within 3 as much as I can, but some devices are really hard to find at a good price point that falls into 3. All my HA devices are within 3, except some real-time cameras which I couldn't find below ~300 EUR if I wanted them in 3, so those are within group 2 and now isolated after the setup.
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 like the taxonomy you've outlined. It would be great if the Home Assistant org were to formalize something like it into levels with logos manufacturers could use in ads and packaging. It would help clarify products for users and, most importantly, provide an incentive for manufacturers toward more local-first interop.
It might be good to invert the order above and name the levels with something like Platinum, Gold, Silver to clearly signal better and best. Manufacturer's marketing people love having external compliance logos, especially manufacturers of commodity hardware.
Home Assistant itself falls into category 2, with some integrations/utilities in category 1. The amount of stuff it pulls from the mothership and GitHub is crazy. I wish it were local-only by default.
Is the certificate for that domain pinned? If not, just host it locally. In fact, I'm going to try doing that. Have you already checked the Docs? Somebody probably already published a gist somewhere with the needed path
A fresh HAOS VM can not successfully boot without internet access, maybe due to how they are managing everything with Docker within HAOS? I noticed this because the VM was accidentally put into a network that does not have stable internet, and I kept wondering why it didn't boot.
Really hope that there is a fully offline solution.
> The amount of stuff it pulls from the mothership and GitHub is crazy.
It seems the problem of HAOS, not Home Assistant itself. I have install my HA in NixOS from its package manager, it seems not try to download somethings.
I'm curious about what you're issue was finding cameras as, to me, that's the easiest thing to find cloud free since they have a long history of being used in closed networks as POE, onvif cameras long before smart homes were really a thing.
I can’t speak for OP but usually the issue with #3 for me is that the other criteria it needs to meet is that it works with whatever other integration I want. I remember when I looked the TP-Links were a good option but you just needed internet to set it up. Afterwards it just went on a vlan without internet. The camera needs to support Scrypted/Frigate for my use case but depending on needs for PTZ, Wi-Fi, resolution, night vision, etc, I may or may not be able to find one at a reasonable price that doesn’t require internet access for setup. TP Link makes good cameras at a good price but they require internet access to setup, so any camera that falls into #3 will get compared to a TP Link in #2
Agree, I buy some Dahua POE cameras, It can be configured via browser locally with powerful AI feature, and work without internet access, although some drawbacks:
# Some of them are limited to 25 fps
# The model name are really a mess
# Some models are without hardware reset button, the only way to reset is register device to Dahua's cloud service with China phone number (although it is not enforced)
At AirGradient, all our air quality monitors can completely run local. Our official firmware is on GitHub and people could even flash their own (adjusted) version.
We believe this is how IoT devices should be and are very vocal about it. So I think there are a few manufacturers that think different.
And this is exactly why I like to buy AirGradient hardware. Your CO2 sensors are some of the best I've found for the price point, and I love your outdoor monitor as well.
That said; I have started moving towards using SEN5x for a lot of my air monitoring. I've noticed the SHT3x temp sensors pretty consistently flake out after 2-3 years, and the footprint of your current DIY kit is rather larger.
Would you consider an updated version with the SEN6x once it comes out, with perhaps an ESP32c3, rather than the 8266?
To steel man a bit, they're also trying to make things as easy as possible for the generic public that they want to buy their device, who doesn't know what a hub is, and definitely doesn't want to learn, to turn on a lightbulb.
The fact that the engineering effort would be diverted to something that targets a small fraction of a percent of their customer base is a perfectly valid reason to not do it, especially when that engineering effort could be put towards making the product better for the other 99.x% of their customers.
This is how a lot of home assistant integrations work. Sure, many HA users (self included) try to avoid dependence on cloud services and opt for local only solutions, such as zwave or ZigBee or products that work with local-only wifi. But the nature of the beast is that some devices out there are built to talk only to a cloud service.
Having a company start an upstream project is probably a better sign than not having that, however sure, they could pull the plug on their access to cloud service, people may have privacy and security concerns, etc.
they could pull the plug on their access to cloud service
It's happened to me twice.
The first time was about seven years ago, when Fiet Electric sent out a software update that deliberately bricked all of its home hubs, and consequentially turned all of the connected smart light bulbs into dumb light bulbs. Speculation on IoT forums at the time was that Fiet failed to properly license some piece of code that was critical to its system; but that was all speculation. I seem to recall that Fiet put out an e-mail long after the fact letting people know they could no longer use their "smart" devices.
The second time was earlier this year, when Sylvania ended its cloud service, and turned its smart bulbs into merely clever bulbs. They'll still work with the stand-alone Sylvania app, but new bulbs can no longer be added to Apple HomeKit setups. So you need to use two apps (Home and Sylvania) to control the devices in your home. That is, until the Sylvania app is no longer available in the App Store, or compatible with modern devices.
Avoiding Fiet Electric products was easy. But I thought I'd be safe with a big name like Sylvania.
I completely agree with the grandparent. This is all avoided by using Zigbee or Z-Wave devices. All our smart lights are Hue. If they decide to stop supporting it, they can be controlled with the Samsung/Aeotec SmartThings Hub, Home Assistant, Zigbee2MQTT, or whatever you please. Similarly, our smart plugs are also Zigbee and we use a couple of Aeotec Z-Wave temperature/humidity sensors.
Best of all, less worries about yet another IoT device with probably vulnerable software that we have to put on a VLAN/IoT WiFi network. Zigbee and Z-Wave are also much simpler than WiFi/Bluetooth, so less likely that they are a swiss cheese of vulnerabilities.
With hue there is still potential risk of a lockin with their hue app. They allow it still, because their sales are not really good. But otherwise they might have restricted it.
Hue bulbs currently are stock standard Zigbee compatible light bulbs. You can pay them into ZHA/Z2M without any issues and control them without any Hue hub or app.
If Hue were to suddenly switch to something proprietary their existing bulbs will all continue to function without their app or hub.
The bulbs are ok but I tried moving my Hue motion sensors over to my main Zigbee network and they were terrible, constantly dropping offline and needing reset.
Luckily Hue is made by Philips who I'm pretty sure aren't going anywhere.
I moved my Hue sensors to my primary Zigbee network and left the bulbs on the hub, especially since I have some of the gradient strips that don't work unless they are on the Hue hub, and my motion sensors have been rock solid.
Hue Bulbs use Zigbee. If hue stops supporting the hub or older devices, you can reset and pair them to anything.
The Hue bridge is IP based but can be controlled entirely over your local network. It’s a slim possibility of something breaking (the mobile app mostly) and then the bulbs are still fine.
what's the state of bulbs that don't use apps? I have some from IKEA that get paired to a Bluetooth remote, and it seems pretty good for now but I'm kinda nervous about relying on a device like that.
IKEA bulbs use mostly Zigbee, can be paired directly with their remote so don't require any hub, and connect directly with any Home Assistant with a Zigbee dongle like Sonoff.
Philips Hue uses Zigbee and the quality of Hue lights is really excellent (both the lights themselves and longevity, our oldest lights are over 10 years). A lot of Ikea devices also use Zigbee, though it sometimes takes a while before they are supported properly by SmartThings, Home Assistant, etc.
> And it how the _current_ integration works. So what are we gaining here
An official integration, supported (for whatever that's worth) by Xiaomi instead of random people reverse engineering their API until the next breaking change, or even worse, them deciding "this is DDoS so we'll ban anyone from using our API".
Although I bought my Dreame D10 because its on the Valetudo compat list, I actually never put it on, because it turns out OOB you actually don't need to setup anything for the regular mop function to work. It's entirely unconnected, which I prefer anyway. I miss out on remote access and mopping only parts of the room, but I can live with this trade off.
Once they turn them into true IoT shits, then I'll be worried.
"Integration" is just the term the HA project uses for code supporting a specific device/brand/platform. Home Assistant shows a label on each integration clarifying whether it's entirely local or cloud-based.
I agree that it totally sucks. If you use home assistant, it is mostly to not give control of everything in your home to the cloud of a company. Especially to a Chinese one...
And there is no legitimate reason why control can't be local only, especially when home assistant is there to provide the gateway feature and remote access is needed!
So this action of Xiaomi is just a marketing way to be able to print "compatible with home assistant" on their box despite still forcing to use their cloud!
That is nice because the xiaomi stuff is all over the place in HA. Some devices (the air cleaner for example) have built in support but many of them need custom not really supported addons from HACS. Like the WiFi fans, weighing scales, rice cooker etc
What is Land Rover the Land Rover of again? Highest cost per repair? Least likely off-road brand to be taken off-road? No.1 brand owned by rich land-owners? I legit don't get what that reference was going for.
Home Assistant is a free and open source way of cross-connecting smart devices. It is incredibly powerful. It can easily save you money (e.g. garage door/motion sensor + thermostat temp adjustments), or allow you to craft bespoke convenience/security features.
It is the central hub of a smart-home. Very reliable in my experience.
Closest to the first. He's joking that you can't own a Land Rover without being a mechanic and you can't use Home Assistant without being a programmer.
I love Home Assistant, and except for the occasional update breaking config files it's been very reliable, but there is no way 95% of people could get it installed, let alone get it set up to do anything useful.
I have an Apple HomePod Mini (with Matter support), and HA with Homebridge, and every now and then I see evidence in HA of tighter integration. Not sure where it might all end up tho. I'm keeping my fingers crossed that some day it will magically become self-aware and make everything "just work".
>What is Land Rover the Land Rover of again? Highest cost per repair? Least likely off-road brand to be taken off-road? No.1 brand owned by rich land-owners? I legit don't get what that reference was going for.
excepting the recent dross from them with the death of the real defender...they can usually be fixed roadside with a hammer and some grease, they're easily the most ubiquitous off-road vehicle globally (well either landrover or toyota) and with 80% of all made still running.
Not sure why your reaction was so emotional, but I think you're thinking of Range Rovers, again though, the old ones were superb, the new ones are for rappers, footballer, and the other assorted nouveau riche.
I think they were referring more to Land Rovers making mechanics out of car owners (Due to their famously bad reliability), but I may have misunderstood the joke.
Definitely, I heard som many bad jokes like you need to buy 2 evoque models to be able to drive at least 1 etc. Really bad reliability despite good design.
Home Assistant is one of the best open source projects I've come across. I've been using it for 5+ years on an older RPi and it's been pretty rock solid. Countless updates and everything just keeps on chugging.
I've landed on a mixture of MQTT and Zigbee communicating devices, the latter being much easier to set up and maintain. There's an integration for just about everything I've wanted, some better than others, but all in all just a great project.
I experimented a bit with ZHA (native Zigbee integration) but soon realised I needed something better, and Z2M was that something.
It had all been working wonderfully, until I had a problem recently that meant I had to redo the entire Zigbee setup.
I run HAOS on a VM, with the Zigbee radio being passed through from the host. Recently I wanted to play with Thread so I added a radio and passed it through to the VM as well. All was fine, though I wasn't having a lot of time to experiment and the Thread dongle was connected in an awkward position so I decided to yank it out. At this point all hell broke lose. Z2M wouldn't start, throwing cryptic error messages. After a lot of trial and error, I removed both USB passthroughs, rebooted the VM, shut it down again, re-plugged the Zigbee dongle and re-added the passthrough. At this point the hardware side of things was fine but my Zigbee network was gone. To make it worse, a new one couldn't be initialised because it was trying to use the same ID as the previous one. I had to manually change the ID in the config YAML, restart everything, then re-pair all devices.
I really feel like this stuff should be more resilient to failures. Otherwise, it's pretty good!
> At this point the hardware side of things was fine but my Zigbee network was gone.
How come the hardware was ok but the network was gone? Did some Z2M config files go wrong because of two dongles? Did you try to restore VM from snapshots?
Losing the network and having to re-pair everything would be a nightmare for me given the number of Zigbee devices I run (~35) and that some of them are mounted in switch boxes in the walls.
Honestly, I don't think I can answer your question. I didn't change the config but I had to delete and re-pair all devices (or they had been gone from Z2M already at this point, I can't remember - it's mostly an academic distinction though).
I've actually done my migration the other way around. I started with zigbee2mqtt, saw that HA now offers ZHA and switched to that. It just works with all devices I own, so the end result is one less moving part I need to update so the choice was easy.
For me, a lot more entities from each device was correctly detected out-of-the-box. I think the wide compatibility is the biggest reason why you'd go with it.
But if you only have Phillips and Ikea devices for example, probably won't be much difference with Z2M.
The nice part about mqtt is other things can subscribe to the same stream. I've also seen people do some really interesting things with hosting a copy of HA in the cloud -- this is what they connect to while outside their network -- and using mqtt to push updates to a local HA.
Okay but if you have Home Assistant in the center of all things, why would other things need to subscribe to that same stream?
I use MQTT but for me it's only a tool for getting a certain device integrated in HA. I don't see why I would want more devices to communicate that way.
Plus, from my development background, I have grown to really dislike event buses. And mqtt sure feels like a weird big non-strict event bus with some persistence.
Because HA is a single point of failure. It's big, complex, and frequently updated (there were 3 minor version updates this month already.) Any one of those updates could bring some issues that require fixes/rollback, and even when it's smooth, it takes a minute or two on my 8th-gen, i5-based, NVMe-having home server, not some underpowered Pi or SBC.
Meanwhile, a standalone MQTT broker like Mosquitto is rock solid, had 2 minor updates this year, and could run on the most minimal of hardware/LXC.
I second Zigbee2mqtt. Koen's work is legedenary, I also been fascinated by Zigbee and been using ever since. No need to 3rd part oem vendor lock-in. 99% of the devices I purchased currently nearly 52 on my zigbee network, were paird hassle free.
I've been rolling my own stuff, mostly devices posting to custom python servers, storing data into influxdb and mongodb, triggering other servers on events, and lately also integrating Tasmota devices via MQTT, like the microwave, washing machine, computer monitors, small heating fans and the like. I migrated all Hue devices to zigbee2mqtt and am happy with the flexibility.
Initially (7 years ago?) I refused to use HA because I've all too often had the issue that then projects become stale and I need to migrate to something else.
But lately I've gotten the feeling that HA is really here to stay, with a community big enough for this project not to die and maintaining very good hardware support.
What I'm missing out on is an (Android) app, and I think that this would be a good reason to think about moving over to HA.
> What I'm missing out on is an (Android) app, and I think that this would be a good reason to think about moving over to HA.
There is! The Home assistant companion - it brings you a lot of functionality in terms of location, notifications, sensors and what not into the HA world.
Same story here. Everything goes through MQTT, and a single python script has my automation logic. All redeployable via Docker Compose. I never need to worry about updates breaking things, and there’s much less context for me to try to remember.
Home Assistant never “clicked” with me. It makes some hard things easy, but some easy things hard. I just don’t love YAML enough to write logic in config files…
I also hate that HA pushes you to run their whole OS. The docs usually assume you’re running HAOS.
There is an app that is basically a wrapper arround the mobile version of HA. But it works quite well. The dashboards of HA are responsive and there is no need for a native version.
HA is awesome but I have found that over time entropy kicks in if you don't maintain it properly (which I haven't done for a year) connections fail, switches stop doing what they are supposed to...it's on my Xmas list to spend some time sorting it out!
I'm a noob when it comes to DBs, but stumbled upon using InfluxDB with Home Assistant - would you say that's a solid choice, or are there better alternatives out there?
InfluxDB is pretty much the most popular and widely used time series database.
The difference between just storing every value ever and a time series DB is that the latter one can reduce the data frequency when it gets older.
Like if you're measuring your fridge temperature, you might store it every minute. But do you care about 1 minute accuracy when the data is two years old? Would 5 or 15 minutes be enough?
This is what time series DBs do automatically.
They're also optimised for data that's formatted as <time stamp> - <values>, making inserts and queries fast for data like that.
I include this when considering buying something integrated.
For example Philips Hue is overpriced, but their Home Assistant integration is top tier and ultra-reliable. Contrast that with myQ garage door openers (LiftMaster, Chamberlain and Craftsman) recently breaking Home Assistant support on purpose, to essentially replace it with nothing, and they're dead to me.
So Xiaomi adding support, assuming it is reliable, definitely moves them into a better category.
I installed a pair of these, and haven't looked back. Yes, there is a little bit of a curve with rewiring your opener, but there is great documentation available, and safety in the fact that if you mess up, your door just won't open. If you snap a picture ahead of time, it's easy to undo. And from there, you can hook it in to Home Assistant or HomeKit and do whatever you want, which is amazing. My Home Assistant notifies me when the door has been open for 5, 10, 30, 60 minutes, as well as if the sensor is obstructed for the same intervals.
Second this product. I wanted an Ethernet version so I made my own (it's integrated into esphome and the circuit is documented here https://github.com/Kaldek/rat-ratgdo). Apart from general usage, I use mine to tilt the garage door a small amount if it detects bad air quality in my shop (using an IKEA air quality sensor via home assistant).
I'm aware but I'm one of the like 5 people that bought the overpriced MyQ-HomeKit adapter and it's still working to provide HA control. If it ever dies I'll be going ratgdo or opengarage for sure
It's inexpensive if you discount the cost of your education learning how to wire in something like that.
There's an order of magnitude difference in project size between setting up the old MyQ integration with home assistant and learning how to use.. whatever that thing is.
Sometimes I think clever and educated people forget what it's like to be less intelligent or educated.
That's a fair point, but it's still likely less expensive than replacing your existing opener if you include the cost of an electrician doing the wiring for you.
It's really not hard at all. It probably took 5 minutes to install, with most of the time futzing with the power cable routing so that it looked decent and didn't rub on sharp corners of the opener bracket.
I agree that it's not challenging. I'm just saying that even if someone is intimidated by doing this, it's still probably a relatively inexpensive option even when you include hiring an electrician.
1. They want to charge for some integrations. I could see this if they didn't make local only impossible if you want anything beyond the clicker. Why aren't these just bluetooth and or wifi so my car and open when I pull up and close when I leave? Hell, if they just added an 'open if closed' and 'close if open' it would make it way better for the car to controll. IMO they are purposely making the non myQ options suck and stuck in the 80s just so they can upsell to a monthly subscription.
2. Their security is a joke. After moving to new phone their app would refuse to login yet would still show me notifications for door events. The only way to stop the notifications was to uninstall the app.
My newer garage door is lacking wifi just so I can add my own automation without even bothering with theirs.
I wouldn't call them overpriced (at least not all products), their quality is typically great, you get what you pay for. We have had Hue lights for over 10 years (pretty much every light in our house is Hue) and never had any issues. I think over that period one light broke. And like you said, the integration is great. In our house we have it configured to use both through the Hue hub and SmartThings.
> their quality is typically great, you get what you pay for.
You're lucky. I also have almost all lights from Hue, and in almost 6 years I've had 6 or 7 completely dead bulbs (out of ~40). One more lightbulb failed in a weird way - it sort of worked, but in 90% of cases refused to completely turn off and still kept some of the LEDs lit. I haven't bothered to disassemble it to see how that happened. And one more light works normally, but somehow fails to report its status to HomeKit. It can be controlled but always shows up as "updating..." - guess it's a software bug of some sort, since it works in the Hue app.
No Home Assistant here at the moment, just regular Hue+HomeKit setup. I have tried HA a few times, but found no significant additional value over what I already have. It's just as dumb as all other "smart" home solutions, still has very limited diagnostics if something is not working (maybe if one really groks its internals it can be debugged better, but I don't) and requires maintenance. I was thinking about building something with plain simple Zigbee2MQTT and a bunch of DIY scripts to make it a little smart, but haven't yet had time for this.
Yup. I paid like $40CAD for a single Hue lightbulb in 2017 and it's still going. In that time, I've had countless cheap Canadian Tire brand (NOMA) & Walmart brand LED bulbs burn out and need replacing totaling WAY more than $40.
I just looked and they have gotten like 20% more expensive though... that said, their non-smart bulbs are still pretty affordable comparatively.
We have almost two dozen Ikea Tradfri bulbs and they've been great. We had a few older Hue ones too, those never seemed to keep their state across power loss and their light quality was pretty bad given the price, really not impressed.
Look for Zigbee devices and most stuff just works out of the box. And when you’re not upgrading firmware, there’s no way for the manufacturer to break anything.
Zigbee is wonderful, especially alongside things like zigbee2mqtt device support [0]. The downside is that its not uncommon to see non-compliant devices, or buggy implementations which is almost more annoying.
I recently installed a zigbee thermostat in my bathroom, which turned out to be flooding the network and causing the rest of my network to become unstable
If you’ve got a spare garage remote control, a raspberry pi or Arduino board, a soldering iron, an optocoupler, and a sense of adventure, you can easily integrate your existing garage door opener into Home Assistant or what have you.
In fact, the Arduino starter kit comes with a few optocouplers and instructions for basically exactly this project!
Or you can get a tube of a dozen 4N25 optocouplers for like $8 on amazon.
I am looking to install a garage opener and due to meatspace constraints I will probably have to use jackshaft. Jackshafts are predominantly LiftMaster and Chamberlain => the smarts are myQ, which I don't want anywhere near my network. Genie jackshafts seem fine, but Genie's reputation is bad to the point where garage door companies may refuse to work on them.
These motors also usually come with the ability to hook up a hardwired button. There are a couple of pre-made (konnected, ratgo) solutions or one could jury rig a z-wave relay.
Alternative is Overhead Garage door company that have separate SKUs for the unit, the battery and the smarts so one can pick two and use the same relay (my current plan).
There may be _some_ proprietary shenanigans with LM and Chamberlain hardwired buttons but Overhead's one really seems to just work through bridging two contacts
Just use a LiftMaster/Chamberlain jackshaft opener, never connect it to any network install the ESP32-based ratgdo device into the wiring harness, be done with this issue.
Nothing else compares due to the digital integration. ratgdo uses the simple serial protocol that the opener button uses, so it has access to a lot of information.
Thanks, that's the plan. To be precise - - I thought about getting the opener+battery from Overhead and ratgo/konnected.
Since you mention those two manufacturers specifically -- do you know if there's something that disqualifies the Overhead company's one? One downside that I could think of is that I'd be vendor-locked in for parts when it croaks.
Not sure how it works with a jackshaft vs. the more traditional residential opener, but ratgdo can speak the myQ protocol and control it from mqtt or home assistant. I have it working with my Chamberlain opener as do many others.
Besides the questionable rent-seeking behavior from myQ:
* I don't want to use an integration that needs a round-trip through the cloud to work. Long-term changes are inevitable (company goes out of business, randomly changes API, etc.)
* I fundamentally do not like Amazon Key integration. It gives someone else control over my security hardware which makes me very uncomfortable. I am not sure if it's opt-in or out, but the point is that a myQ device that is installed _can_ be configured to let arbitrary third party to open the door.
If I have a choice, I'd rather set up a system that I control from the get-go rather than try to lobotomize a system that I can't fully control.
Ratgdo doesn't go through the cloud. It's a separate board. You wire it into the opener the same way would a button, and it speaks the serial protocol that a myQ enabled button or console would use. Then it can speak MQTT over wifi.
I never paired my opener with any app nor do I have it on WiFi.
Yes, of course. As a matter of fact -- I will be using one of those solutions myself and pair it with HA.
>I never paired my opener with any app nor do I have it on WiFi.
The opener may be advertising "configure me" network (WiFi or BT) -- which (in theory, depending on how bad did they screw the security up) could allow anyone to pair their app with your opener.
I think it might be better to add it to the network but firewall it off No ingress or egress. This is just so that it no longer advertises the configuration network.
Putting it into a faraday cage should also work but I suppose the firewall way is faster
> Why don’t you want myQ anywhere near your network?
Precisely because they're rent-seeking. I have a wifi-enabled garage door opener that I paid a lot of money for. Why should I have to pay MyQ every month to effectively just let something other than their app or their proprietary switch open the door?
“Near my network” suggested it was a security issue. Are there other companies running a cloud-based api for garage doors that don’t charge? It does cost money to keep the servers going.
I personally just took a cheap remote, attached its button to an esp32 with a relay, put on mqtt, and interfaced it with homebridge. Now it shows up in the home app. Works well! iCloud via Apple TV connects it to the internet securely.
Ah, sorry. I may have misinterpreted your question.
I've only had a garage worth having motorization for a short time. It isn't something I've thought a ton about: While I do have this garage, and it would be nice to be able to park a car in there on a daily basis, and having it be motorized (and automated!) would be great, it's still full of the detritus from moving. Having the door go up and down by itself is pretty low on the list right now and will probably remain that way until the weather gets warmer and drier. :)
When I have thought about it, I've thought that building something myself would be adequate; that I'd just pick any dumb opener that has open/closed IO exposed, and graft on the connectivity functions I need with an ESP32 and some relays, using ESPHome.
Or maybe Shelly modules: One variation or another might have enough IO built in to do it, and they're packaged neatly, priced right, and the default software integrates well with Home Assistant. (They've also got ESP32s inside and can run ESPHome if one is so-inclined.)
Seems easy enough to me, and I've certainly done much more daunting and elaborate integration stuff at $dayjob.
But I don't know of a competitive "just-works" LAN-controllable garage door opener.
If it weren't for the SNAFU a year or so ago[0], I'd probably pick Chamberlain and a Ratdgo[1] board for local network control. But as it stands, I do not want to reward Chamberlain with any of my dollars, and I'm willing to go to any expense in order to avoid doing so.
Hue is amazing, the reliability of their products is truly impressive. I've had ~40 lights for years and not a single one has died or ever had connectivity issues.
At the moment you can pair them with any ZigBee controller, which I found to be much simpler. This is one firmware update away from not working (which is why I mostly relied on Z-Wave) so YMMV.
MyQ are such scum. I love how on my smartphone I can just press a button in the MyQ app to open my garage door, but if I want to push the button on my Tesla, they want to charge me a subscription fee of $100 a year or something like that
It's worth clicking through and reading details on each one before you commit. Most of them are quite complete, but some only support a handful of devices or features. You can also get a sense if the control is local (i.e. no internet connection) or cloud based.
Meanwhile MyQ “closed” their API and broke all HA integration because it “cost” the company too much. Where in reality, they just wanted people to use their app since they started serving ads. Say what you want about China and the security implications but a lot of their IoT companies are way more opened than our US counterparts.
low-end Chinese phones, including Xiaomi and Huawei, show ads on system apps like Settings and Contacts. soon, smart home appliances might also display or speak ads. there's nothing stopping these Chinese companies from doing so - both technologically and ethically.
Xiaomi definitely should not lead the way in smart home automation.
do you mean putting Bing on the start menu? Microsoft just made them opt-in by default and hoped that folks won't notice or care. you can disable them.
for Chinese devices, there's no way to disable them.
the difference is, for Windows, having Bing on start was a feature (although a bad one). for Chinese devices, you just get ads - you're stuck with ads while changing your brightness.
No, not just Microsoft services or features (or subscription based software), ads for games and apps on their store get jammed in the start menu as well.
And as other commenters have pointed out, lots of budget phones and hardware jam ads all over the place.
> for Chinese devices, there's no way to disable them.
Uh can you stop spreading misinformation? Try google "disable xiaomi ads" it takes you like 5 minutes to make all ads gone on MIUI or HyperOS. Sure the opt-out buttons were hidden deep behind menus for maximizing profit.
But be warned, in certain countries you are getting a modified ROM from your local re-seller, in that case some ads can't be disabled and they are not from Xiaomi. The only solution is to flash your ROM to the official releases.
Is there a way to unlock the bootloader? (The official ways give cryptic error messages on purpose to keep you distracted until your warranty runs out)
IIRC you'll need to register an account, use their official unlocker, then wait 2 weeks before your device is allowed to be unlocked. It's supposed to be done to hinder 3rd party sellers that flash custom rom with ads on phones they sell.
Yes, that's something like the official process excuse. It doesn't actually work, because their server has been configured to reject all unlocking requests.
While they do include MS services in their advertising it's way more than that. They include a bunch of other crap, including hardware offerings like trying to sell you XBox controllers in popups near the taskbar. They advertise Candy Crush, Instagram, Adobe Express, etc, as listed apps "preinstalled" in Windows. They push clickbait MSN articles (ads) for games, travel, and buying guides in the search button of the taskbar that is enabled by default. They then push those in a widget popover panel too. They make Edge the default browser out of the box (and are relentless about getting you to switch if you change it) and Edge itself then shoves ads in your face with default bookmarks like Ebay and Netflix and Walmart and featured content. IIRC even things like their Maps, Weather, and Photos apps also had web advertising placements.
There's probably more but I can't bear to use Windows more than minimally necessary so I've probably missed a bunch.
You get ads for agreeing to buy a cheap subsidized device, like amazon devices. There's lots of guides out there to disable ads/msa.
>soon, smart home
How? With what screen or speaker? The half inch oled on my smart ricer cooker? Xiaomi has been in the smart home market for ~10 years, with 100s of products, except pushing for storage subscription in the mi home app, they haven't done anything aggregious. My robovacuum, air purifier, air conditioner didn't screamed ads in the middle of the night. There's nothing stopping any tech company that inputs to a screen or speaker from monetizing ads, except for past behaviour, and so far Xiaomi home has been very good.
Samsung, and some other major players put a lot of ads and bloatware in their phones, TVs, laptops and other appliances. Xiaomi doesn't have ads on global versions of TVs and Phones. I know the Chinese version does have ads.
As a homeowner, I don't know what is worse. Using stuff where the local government can watch and spy on every step or some Chinese guy watching your boring life if you are low-level person.
…unlike appliances from non-Chinese companies like, say, Amazon? :-)
There is nothing "Chinese" about enshittification of the world around us. My LG TV insists that my "home screen" is not my property, even though I bought the TV, and invents new ways of showing ads and tracking me invasively. Amazon devices show ads and speak ads. Even Apple devices, even though apple pretends they are above this, show ads in app store search results, and send you ad notifications.
I won't even honorably mention Windows, where my computer and the main UI is basically considered a free-for-all for the Microsoft marketing department.
I love Home Assistant but I now have a pretty strict minimum effort rule after years of configuring integrations and building dashboards that I would forget about after 2 months:
I only do automations (no dashboards at all), and try to keep them as simple as possible. Once I feel I’m reaching diminishing returns territory, I stop.
Only use HA if I need to mix different vendors (e.g. turn on the hue lights if the tuya sensor switches to on) or if the vendor app/service has a limitation that doesn’t allow me to do what I want. For instance, I have some automations for my Mitsubishi airco units cause their app sucks. Otherwise I’ll just use the default app or service.
Only configure an integration if I’m going to use it in an automation; I have a bunch of integrations detected that I don’t configure.
I decided to follow these rules a couple of years back, and since then I could address all my needs with almost 0 maintenance.
How many apps do you have installed to control everything? And how is the stuff integrating if you have equipment from different vendor that need to talk to each other, like AC units with PV inverter to start and shutdown based on electricity net production and real temperature in the rooms (using external thermometers, not the one in the AC)? And how do you consolidate and monitor power consumption in a single place, are you using a different solution for that?
It sounds like I use HA in a similar manner. For me, I make HA available to Google Home and HomeKit. HA is just glue to hold everything together.
I tried do make a dashboard some time ago but it felt rather complicated. Google Home and HomeKit integrate the best into my life and the lives of my family that there is no way HA can compete. Maybe that will change if I find myself in a house that I own… Maybe spending time to make a dashboard will have a better value prop.
I assume then, you don’t use HAOS? What benefit do you see by managing your config this way? Do you also have an operator to reload HA when when you update configs?
Better late than never, I have 3 of their bulbs in the house, and not being able to integrate with HA prevented me from buying more (at least before Matter was announced).
I've been using them with Google Home, so the lights weren't automated with HA. I'll try the integration out.
I have bulbs from wiz, which already have HA support.
Being new to all this home automation stuff I was quite intrigued how they worked though. They're exposed on the WiFi network over a really simple UDP based protocol which led me down a rabbit hole of writing a little go client to mess about with them, took a few evenings.
Not saying Xiaomi bulbs would be quite as simple to write an integration for, but they might have been. It's kind of fun seeing how people have reverse engineered all these custom protocols.
I got some of those Yeelight ones (gen 1/gray plastic and gen 2/white plastic!) but my experience has been really bad. Even if their app allows you to enable local mode it's laggy and just... stops working after a while, it also seems to break if it can't reach xiaomi servers (pihole). Wondering how you got yours to work, mine are just trash at this point and i've since switched to proper local devices.
Zero lag. If they lose power they revert to cool white. All local. Checked home assistant and its direct integration (yeelight)...no mqtt.
And looked up my old notes - copied in below though don't recall details of what I did. Suspect maybe I used the python stuff just to check that lan is enabled rather than editing
Just to confirm, you are using the Yeelight app for this setup? On android there's Yeelight Classic (red icon), Yeelight (purple icon), Yeelight Pro (black icon) and the Xiaomi Home one. I think some of my issue might have been that region lock thing that kept changing a few years back (someone mentioned in another parent here). I remember setting it up on the Yeelight (red) but it eventually had me switch to Xiaomi Home (green app) which then required re-setting it up on another cloud region, which then broke again after a while.
I'll give this python script a try for sure, glad to know you got yours to properly work!
Both the red yeelight classic and green Xiaomi Home is showing as previously downloaded on my iphone. Afraid I don't know which (was years ago) but I'd try red first
...and that too feels on brand for Xiaomi...utter chaos on branding.
Personal anecdote but at least for me WiFi devices are significantly more reliable and there exists good brands that don't have any vendor lockdown, such as Shelly or Sonoff. Others can do Tasmota. So you shouldn't go around discarding it just because it's wifi. I live in a concrete and metal house. My WiFi coverage is spotless with several APs around the house.
Can't really do that with ZigBee. Almost all of my zigbee devices just fail to connect every other day. Z-wave offers that mesh network promise but man is it out of reach in the price range.
WiFi is everywhere/in every house, I seriously think more vendors should offer devices that just integrate into it instead of trying to build this bespoke network on the same band. Specially since 2.4GHz is going into disuse more and more as people switch to 5GHz for phones/pcs/etc..
Some of the best home automation stuff is cloud-less wifi. For example Shelly switches with Tasmota are awesome and I much prefer those over zigbee bulbs.
Low effort, low maintenance, works good. mqtt & wifi, tasmota has everything you could want in a timer interface while still exposing switching etc to override it HA.
All I know about Xiaomi is that I bought a phone from them because the hardware specs were pretty good and the bootloader was unlockable. Upon trying to unlock the bootloader, I was told my account must be 30 days old (effectively, that I must have owned the phone for 30 days). Annoying, but not that unreasonable if it's some kind of anti-theft protection or something. After 30 days, every time I press the button for the first step of unlocking, I am told that I should try again on tomorrow's date. Apparently every 6 months they change the roadblocks to bootloader unlocking, and as of this moment there is no simple way to do it (their server no longer processes the requests), with rumours they plan to permanently disable it. This is pretty bad for my trust in their brand.
I have some xiaomi bulbs that used to work until I needed to re-pair them to a new wifi and (unofficial) integration kept asking me for pairing code - which is nowhere to be found. I probably got rid of the boxes where it's supposed to be located. Wonder if there's a workaround for that.
I think WiFi IoT stuff has a reputation for being janky pretty much across the board, the recommendation is usually to use Zigbee stuff instead wherever possible. That also has the security advantage of keeping the devices on their own little network that can't access your LAN or the internet directly.
I've gone with Zwave instead - older house and hoping to keep wifi bands uncongested. It's about $30 per device, with Zooz as a big brand. It's been quite solid and the spousal-acceptance-factor is high.
Not familiar with xiaomi bulbs, do they have QR codes on the base?
A few years ago Xiaomi started enforcing region locks to reduce gray market sales, so a bunch of products stopped pairing when app set to wrong region, without indication why. I had to repair my vacuum, air purifier, security cameras on profile with PRC region, and other stuff on profile with Singapore region. Very annoying.
Is anyone else trying to run HA with deCONZ & Conbee II ? AFAICT the documentation is scattershot and the software is ugly and fickle. OTOH maybe I'm just stupid.
I am running HA with Conbee II using zigbee2mqtt in docker, and it is very stable and easy to use. However the Conbee II stick needs to left at an older version of firmware. The most recent updates of Conbee II firmware are unstable.
I tried it for a year or so, then I moved everything to zigbee2mqtt and a slae.sh CC2652 stick (https://slae.sh/projects/cc2652/). I had a lot of problems with deCONZ / Conbee II dropping messages and losing devices, forcing me to reset, re-pair and re-configure every few weeks (specifically my Hue lights). The new stick and zigbee2mqtt has been flawless so far (18 months)
I tried. It was unreliable as f. Conbee lost connection whenever he wanted. HA was way to heavy for modern raspi. Documentation was horrible for all tools and plugins I needed. Many python connectors I found to work with HA in my research before turned out to be outdated and/or only work in specific setups.
As the far majority of my devices is bound to random online APIs anyway, I hacked my own solution back then and today sometimes 'i port' HA plugins using chatgpt :)
I have a Conbee II stick but it's running through Zigbee Home Automation.
HomeAssistant is running inside a VM with the stick passed through from the host.
It works mostly well, hasn't lost any of the Sonoff and Lixee sensors. The only issue is that I need to reboot the VM after an update, or it will lose access to the stick for some reason.
I mean....I guess this is better than not having it, but I'm not personally interested in cloud-only smart integrations. Cloud option? Fantastic! Cloud-only? No thank you.
> Xiaomi central hub gateway is only available in mainland China. In other regions, it is not available.
Nonstarter for many, myself included.
ETA: Yes it does say "partial" local control can be done without the gateway software, but is not recommended and does not work unless you are on the same local network. Better than nothing, but still a nonstarter.
> If you do not have a Xiaomi central hub gateway or other devices having central hub gateway function, all control commands are sent through Xiaomi Cloud.
Now I don't actually know what central hub gateway function entails :) but it does sound like some non-Xiaomi devices could also fulfill this role.
In case of HASS I think local network is a pretty decent assumption. I have my HASS on both my local VLAN as well as the IOT VLAN.
If you are thinking of deploying Home Assistant (HA), let me give you a few tips that I should have known when started. HA environment is vast. There are myriads of options, features, and functions. There are some gotchas that can be costly down the road.
All of the following are "for now, as you start out":
Do not gyrate over which version of HA to run. Run the HAOS loaded on RasPi, or a dedicated machine. You can migrate to other solution if that does not end up to be the best choice.
Make sure you get the latest Zigbee radio dongle the HA Forum recommends. I use in all my HA installs a combination dongle for Zigbee & Z-Wave and it works flawlessly (NORTEK Quickstick Combo).
Start with a few cheap Zigbee devices. Stay away from WiFi, LoRaWAN and other solutions. Z-Wave devices are great, but more expensive. You know you do not know if you even want to do this.
Initially, just use the built-in Zigbee (ZHA) integrations. Once you are comfortable deploying other ways, like MQTT can be established easily.
Do not spend too much on the devices now. I suggest you pick up a PIR motion sensors, door & window opening sensors, temperature & humidity sensors, smart plugs, and light bulbs. Anything else is overkill to try out. Sub-tip: all of these are battery operated, so try to consolidate on a standard battery. The ones I listed can all run off of 2032 cell batteries. Ikea sells most of these, Aqara is well known, and so on. If it is Zigbee (not Matter) you will have 96% chance it will work with HA.
What I wish I had known: HA is just a python program, it's pretty easy to run it manually.
After my Pi's sdcard died, I wanted to use an old laptop (more reliable with a built-in backup battery) so I followed the deployment recommendations and used the VM image. After that, for the first time I started having problems with HA not running - because VirtualBox would run only about a month before crashing. And I didn't like how much memory a VM locked up on the host.
The documentation makes it sound super complicated, but if you can make a venv and `pip install`, the setup is that easy. I tend to just run `hass` manually but there instructions for setting up supervised. I wish the documentation made this clearer, it really tries to scare people away from that method but running a whole VM is a lot of overhead for my pretty simple zwave-js setup.
Can't do with docker or can't do as easily with docker as you can with HAOS? My understanding has been that everything can be done by just adding new containers or files, and it's worked for me thus far.
HAOS uses docker to containerize everything, so it can’t be that difficult, and it really is not. Docker has a —-device flag for this purpose, udev makes it easy enough to assign stable names.
What do you mean by “HAOS on docker”. HAOS is a standalone complete Linux system with its own fully managed kernel, not meant to be containerized. It uses docker internally itself though and “pass through” works transparently.
If you’re talking about running home assistant in a docker container, sure you’re more on your own, but since official home assistant in HAOS must run in docker, none of this is terribly difficult to configure.
The dongles are usually exposed as tty devices and I’ve been running zigbee2mqtt and Zwavejs addons in docker containers for years with no issue.
HAOS takes care of stable naming (based on default udev rules) out of the box.
Unlike system virtualization, there isn’t really anything that needs passing through, it’s a naming and permissions issue - the container just needs an appropriately permissioned dev node ideally with a stable name. If you are using official addons it is effectively zero-config, and if you’re not, sorry but I don’t find the configuration to ensure a dev node to be anything but straightforward container config.
As someone else mentioned it may be as simple as:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0
But you can just as easily use the /dev/serial tree to have stable names. Those names come out of the box with udev. You can always make your own too, I’ve done it, it’s not hard.
The benefit of docker for home assistant is the packaging of it, rather than isolation. You can always run a container with host network mode and privileged mode so that it can access everything it needs to the same as if it were running directly on the host.
Overlooked option for running these things in containers is macvlan networking. Just give it its own MAC address on the network. Works great and you don't have to compromise on isolation.
I've ditched all ARP, mDNS in my setup. Everything is static IP addresses: it vastly improved robustness against network glitches, which absolutely will happen to you.
If my router is unplugged or offline, everything with power can still communicate for example.
Nearly everything is static on mine too. I keep track of all the various devices' MAC addresses and assign them one IP. I also make sure that, even should I reinstall an OS on a device and "forget" to assign it a static IP, my router always assigns that MAC address the static IP I picked for that MAC address. I then keep a little range of IP addresses for unknown devices that the router is allowed to use when a new device shows up. Once in a while I log into my router and look which new device(s) I forgot to assign a static IP too.
When you say you ditched all ARP, did you do anything special? For example do you configure, on all your machines, static ARP entries for each MAC address of all your devices?
I think it can, if you run your Docker containers in host network mode. I run my HA in docker using host mode, and it auto-detects all new devices that pop up on my network.
Good advice, except that I’d try whenever possible to get AA/AAA devices rather than button cells. Not only do the button cell devices burn through batteries, causing a maintenance headache if you have a non-trivial number of devices, but the rechargeable battery ecosystem is much better developed for AA/AAA. We’re currently working on swapping out all our button cell remotes, especially.
Also, the replacement process on the button cells tends to be so fiddly - tiny screws, tiny little doors, etc.
Low battery detection relies on reliable battery level reporting.
Most of my devices hover around 90% for months, then drop to 60% and die within a day. I've stopped bothering with preemptive maintenance, and just replace batteries when devices drop offline.
Also: The IKEA rechargeable LADDA batteries are rebranded Eneloops, confirmed by multiple tests to be virtually identical in capacity and charge retention.
Sadly there's no AAA equivalent to the simple old square Tradri 0/1 on/off dimmer switches that use the cr2032 batteries. Those old switches are small enough that I could 3D print brackets to mount them in my standard wall covers. The newer AAA devices are all much bigger or try to do too many things.
I'd recommend a Raspberry Pi instead. Easier to source (you may even already have it!) and I can guarantee it will be supporter longer and better than whatever low-volume Chinese board they're using here. There is zero advantage to this box, it doesn't even include built-in interfaces for some of the more "exotic" protocols like Zigbee or Z-Wave so you still need dongles either way.
I’ve had the opposite experience. The literally home assistant branded zigbee stick refuses to work with HA („unsupported forward“) even after updates so all the zigbee stuff is in a box
Have had much better luck with WiFi. Both commercial and self soldered circuits. 2.4ghz WiFi is as battle tested as it gets and between esphome and tasmota it’s pretty open and customizable. Just need to steer clear of the usual cheap trash that comes with an app etc
Wi-Fi is battle tested but the network stacks on a lot of these devices are not.
Not a lot of these devices seem to understand the complexities of IP addressing (ARP, IP, etc.) very well so I’ve noticed they can lose connection easily. I’m sure you can limit yourself to products that have good network stacks but it’s hard to tell until you’ve wasted money. My Zigbee/Z-Wave devices have fared a lot better because the protocol is simpler and there is less for developers to screw up.
WiFi is not good for a network with lots of devices. It's star topology which limits multi-device performance. And the WiFi AP which can carry many devices is expensive.
Many WiFi smart home devices only support old WiFi standard, it will pull down both performance (If there is a old standard device, the AP have to fallback to old behavior to match it. OpenWRT's setting also inform that.) and security (You can't use WPA3 only, even WPA2/3). And because these devices use the same network technology with your home network, you need something like VLAN to isolate them.
I personally see that as a feature. When I was researching what route to go (wifi/zigbee/zwave) I encountered enough horror story posts about mesh networks to know that it's not for me. Small network absolutely, especially for battery powered devices, but meshes seem to hit critical mass where it becomes unstable & then people end up doing stupid shit like having to physically uninstall wall light switches to temporarily move them closer to hub to re-pair them
Adding more 2.4ghz AP capacity is comparatively trivial. Hell even raspberry pis can act as APs.
>it will pull down both performance
Anything where I care about performance is on the 5 and 6 ghz band. 2.4ghz is too noisy in cities for general use, but is entirely adequate for IoT sending a couple bytes every now and then.
>[WPA] security
That one is indeed a problem. At some point I'll stick them on a separate AP device with a firewall between that and rest of network, but can't say its a priority
I think this advice is pretty context dependent. Plenty of folks have tons of trouble with their wifi network. For example, someone in an apartment with a very crowded wifi spectrum might have better luck with zwave (900 MHz).
I started with HA in a VM and some WiFi devices, added BLU later, never had the need for Zigbee. More than a year later and over 40 devices in 2 locations (with VPN between, using the same HA server), I am more than happy with the results.
Conclusion: people have different needs and go different paths.
- Use an MicroSD card that can handle multiple read/write like the purple MicroSD cards. Can also be a benefit with too big card to save some writes, to make the card last longer. Talking about <1year vs +50 in how long they last.
-It’s just Python, Jinja and Sqlite3 at the core. For custom programs I find it easier to write the Python program and then just convert to Jinja syntax.
Good microsd cards have write cycle or bytes written estimates in their specs. I usually buy those meant for dashcams since they have a bigger reserve capacity and are decently fast.
Or just get a mini PC. I have an Intel N100 based one that wasn't much more expensive than a higher-end Pi, housing, wallwart, SSD and adapter, is substantially more powerful, energy consumption is pretty close, and it's potentially more useful if it needs to be repurposed later.
Also a tip that will save you few days and save you few things from destroying in anger. If you have existing zwave integration in let say alarm.com hub you first need to remove the devices from the network. Resetting DOES NOT WORK. Enjoy!
If your devices are bound to an old or broken controller, you can rescue your devices by putting a zwave controller into exclusion mode near the device and triggering exclusion on the device (how to do this is device specific, but it usually means "pressing whatever switch the device has"). Note that this is different than what many devices call a reset, which usually doesn't fully reset the device.
Exclusion mode should work on all zwave devices, because they have been certified as zwave compliant with the zwave alliance. The problem is that exclusion mode is extremely counter intuitive. Here is what you need to know:
1. Any zwave controller can exclude a device from any network. It does NOT have to be the controller for that network.
2. The controller needs to be near the device, as other devices won't forward the exclusion messages... at least I think this part is true.
So to rescue your device, you can plug a zwave controller into your laptop and walk around your house excluding devices. I wrote a blog post on how to do this: https://notes.bayesup.date/How+I+Made+a+Mobile+Z-Wave+Exclus.... There are some USB zwave controllers that have a built-in battery specifically so you can do this without involving your laptop.
Anyway, this is so poorly designed I suspect many devices have been thrown away in frustration even though they could have been saved. I almost did this to over $1,000 in zwave switches until I figured out how to write the freaking exclusion program myself and walk around with my laptop.
This is the way to go if you want get things running without wasting days. HA needs to be on on wired LAN for the best experience so one more reason to have it run on RPi and maybe have it sit next to your router.
I have the weirdest issues with HA. Like I can either make or find everything I need, except audio inputs and outputs which seem like some kind of horrifying netherworld of barely supported through config hacks.
Which wouldnt be an issue if their voice assistant stuff wasnt otherwise fantastic.
They seem to really rely on some kind of all in one third party device, but I havent found any that work for me.
Yeah, I never got the audio (stt and tts) / assistant pipeline quite working, always the weirdest issues. I tried running with Docker and other configurations I don't even remember. Discord folks weren't very helpful. It's too bloated to run on old Pi's, requires new ones which are just computers by now and not cheap anymore. Gave up on it long ago.
Happy to, but caveat emptor, your mileage may vary, and so on. The following is for a North American site I was just in.
The things that are battery operated, no big deal. The things that are full power, make sure they are UL, CSA, CE, AS/NCS, JIS, IS, and such listed. The cheaper the device the more likely to have quality shortcuts. Last thing we need is things to catch on fire unnecessarily.
Aqara Smart Plug
Linkind PIR Motion Sensor
Linkind Door Window Sensor
Seedan Zigbee Smart Light Bulbs
Seedan Zigbee Smart Plug
Sonoff SNZB-01 Zigbee Wireless Switch
eWeLink SNZB-03 ZigBee Motion Sensor
IKEA STYRBAR remote control
TRADFRI motion sensor
Some Zigbee devices go to sleep (e.g., STYRBAR) and disappear from the list or show unavailable. Once acted on, they would come to life and perform as expected.
I'll be the one to plug Valetudo in this thread I guess. Primitively, it replaces the cloud functionality on-device for robot vacuums (see supported models) and replaces it with local services that run offline and can connect to Home Assistant easily.
I will never buy another robot vacuum without Valetudo support as long as that project lives. It's great.
I've been eyeing Valetudo for a while. I think it's a shame that it doesn't and (according to the author) never will support multiple maps. I don't want to have to buy a separate robot for each floor when I can easily carry it to the next floor when it's done.
Yeah the author is very set on his ways. I was thinking about contributing but he doesn't want any help. I read CONTRIBUTING.md and I kind of get it. Respect.
Mad respect indeed. I am not in the target audience for this project, but I just read through the contributing.md page. It is very well written, everything he says makes sense
If there's an issue that affects 3% of users doing something arcane which can be fixed by either a large chunk of code or just by not doing that arcane thing, the latter will be the preferred solution.
I use a fork [1] of Valetudo and it lets me do just this. I save one map per floor, then restore when carrying it between floors. One floor gets cleaned much more often, but so far I have preferred this over buying two robots.
Currently I can just get the robot from one floor to the next and press start. It takes a few seconds to find its bearings and switch maps, then goes on his merry way.
Having to restore a snapshot each time I move floors is a lot more friction.
This morning I ran out of coffee at home. While walking to the coffee shop I was thinking about building something like this for my Roborock. Now that I know it already exists, it is a less appealing idea. Video games and books in the holidays it is then!
You mean exploiting FOSS for personal profit would be a business model?
Yes, yes most definitely it would be.
We see that all the time in the world.
Extract money with the easy tasks and leave the hard stuff (actually building things, long-term support, you name it) to "someone else".
And it's perfectly legal too; Just a shameful thing to do.
I want to use something Valetudo to keep my local system supportable and maintainable, but I don't want to spend hundreds of dollars trying to figure out which robot vacuum might have just the right firmware revision that I can dismantle and flash it so it'll work.
Given the cost of getting it wrong, buying a preflashed "definitely works" unit is of considerable value to me.
If the author of Valetudo wanted to license a run of vacuums from a manufacturer that definitely worked, I would buy that. If someone else goes into business managing the buying and flashing part with some sort of support, that's also valuable to me.
If this market segment is currently unserved (seems to be) then I'll become a customer of whoever starts serving it, because that has value to me. Ideally, that would also include kicking back funding to ensure good support from the Valetudo platform (which tends to be how these things work).
Though also frankly the idea that managing the logistics and supply of a product pipeline is "easy" is...well, why hardware is hard has been covered extensively before.
It's perfectly fine to make a business implementing, installing, or supporting FOSS software. I would even consider that a positive thing. Even if you don't (or can't!) help the upstream development.
Yeah I almost installed it, ripped apart my vacuum, just to realize there are many different roborock S7 versions with different SoCs, and my variant wasn't supported. Also roborock doesn't even support scheduled cleaning without cloud :(
Yeah, I have a Roborock S7 MaxV I bought about two years ago and was hoping I could put open source firmware on it but after some searching I learned that Roborock makes a lot of similar but different flavors within a generation like S7 and they can be quite different. Unfortunately, it appears my MaxV flavor of the S7 isn't rootable.
from the Github page[0]:
> Xiaomi Home Integration and the affiliated cloud interface is provided by Xiaomi officially. You need to use your Xiaomi account to login to get your device list. Xiaomi Home Integration implements OAuth 2.0 login process, which does not keep your account password in the Home Assistant application. However, due to the limitation of the Home Assistant platform, the user information (including device information, certificates, tokens, etc.) of your Xiaomi account will be saved in the Home Assistant configuration file in clear text after successful login. You need to ensure that your Home Assistant configuration file is properly stored. The exposure of your configuration file may result in others logging in with your identity.
[0] https://github.com/XiaoMi/ha_xiaomi_home?tab=readme-ov-file#...
reply