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#...
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 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!
75! Can't you just employ a butler? ;-)
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.
I'm using Kasa switches and not sure they can be flashed?
Can you provide couple links with the switch and the firmware you used. Thanks
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.
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.
https://github.com/softScheck/tplink-smartplug/blob/master/t...
https://python-kasa.readthedocs.io/en/latest/cli.html
As an aside - Tasmota is great, but I'd be very wary of random Chineseum off Amazon for switching mains power.
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.)
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.
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.
Don't recall if Shelly's default to 2 or 3 but I like that you can flash em to tasmota for a gaurenteed 3.
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.
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.
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.
https://www.home-assistant.io/blog/2016/02/12/classifying-th...
Updating an ESPHome device config requires network to build/compile the image. [0]
Viewing your Integrations page leaks a list of integrations you are using to "brands.home-assistant.io". [1]
[0] https://community.home-assistant.io/t/esphome-completely-off...
[1] https://community.home-assistant.io/t/wth-why-are-brand-icon...
I have SQUID doing TLS MITM in front of it right now, but that doesn't get me really to "offline builds".
Really hope that there is a fully offline solution.
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.
# 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.
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?
Netatmo has a nice app and widgets, but poor integration.
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.
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.
The "L" in IoT stands for "Longevity."
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.
If Hue were to suddenly switch to something proprietary their existing bulbs will all continue to function without their app or hub.
Luckily Hue is made by Philips who I'm pretty sure aren't going anywhere.
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.
And it how the _current_ integration works. So what are we gaining here? I certainly don't yet have any option for a vacuum that isn't Valetudo.
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".
Once they turn them into true IoT shits, then I'll be worried.
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!
(Very capable, but also making programmers out of home owners since 2012)
edit: I was referring to a sticker that I’ve seen often on enthusiasts' forum posts 'Land Rover - Proudly turning owners into mechanics since 1948'.
The old school Defender is a very capable off road vehicle, but its need for regular unscheduled maintenance is legendary.
Greetings from a Toyota HZJ80 driver :)
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.
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.
HA is only good for normies if there's a techie setting it up and keeping it running.
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.
There's also HACS for plugins which they don't want to merge.
https://www.home-assistant.io/blog/2024/11/18/event-wrapup-g...
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.
Almost everything I use is ZigBee, but at first, I used the built-in Zigbee support for it, not realizing what I was missing out on.
After a move, I setup everything again, but this time via ZigBee2MQTT instead and the compatibility is miles ahead of the built-in integration.
Just a word of advice to others who are using the built-in integration atm, not realizing the big difference between the two :)
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!
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.
But if you only have Phillips and Ikea devices for example, probably won't be much difference with Z2M.
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.
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.
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.
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.
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.
15GB on an actual server? Peanuts.
15GB MariaDB/Mysql database on a Raspberry Pi SD card? Recipe for disaster.
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.
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.
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.
I want a solution I can download :(
If you're using Home Assistant at all, you are more than capable of installing this device.
The old MyQ HA integration was absolutely more difficult to configure and install.
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.
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.
I just looked and they have gotten like 20% more expensive though... that said, their non-smart bulbs are still pretty affordable comparatively.
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
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.
https://store.arduino.cc/products/arduino-starter-kit-multi-...
You just excluded 99.9% of smart home product customers.
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
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.
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.
* 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.
I never paired my opener with any app nor do I have it on WiFi.
>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
That said they’re rent seeking to use their products, eg $100/yr or thereabouts for Tesla integration.
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?
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.
And when the time does come that I need to buy garage door opener, it won't say Chamberlain on it.
Chamberlain's system is cloud-based. Strictly speaking, it doesn't work on LANs -- that's not one of its functions.
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.
[0]: https://www.home-assistant.io/blog/2023/11/06/removal-of-myq...
Have 2 of them and work great.
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.
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.
Xiaomi definitely should not lead the way in smart home automation.
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.
And as other commenters have pointed out, lots of budget phones and hardware jam ads all over the place.
Premium hardware too (hello Smart TVs)
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.
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.
>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.
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.
Did you mean Oppo and Vivo?
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 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.
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.
https://github.com/shepherdjerred/homelab/tree/main/cdk8s/co...
I've been using them with Google Home, so the lights weren't automated with HA. I'll try the integration out.
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.
Tried to rebuy got a different brand and they don’t work offline properly. Bit of a crapshoot
These days I try to buy preflashed tasmota gear. Things like athom.tech
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
------
https://github.com/Squachen/micloud
pip install micloud
miiocli device --ip 192.168.1.88 --token FOOBAR info
miiocli device --ip 192.168.1.88 --token FOOBAR info
On iphone go to yeelight app, select the apps overall setting menu and enable lan control
I'll give this python script a try for sure, glad to know you got yours to properly work!
...and that too feels on brand for Xiaomi...utter chaos on branding.
Anything else is just WiFi and vendor lockdown
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..
Plus, unless you fence off your wifi device from the router, it might be phoning home on you. At least a module without a WiFi stack can't do that
https://www.aliexpress.com/store/5790427
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.
Defaulting to zigbee for anything new
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.
"Warning: Conbee 2 firmware versions newer than 0x26580700 will result in an unstable network with devices dropping randomly, see Issue 9554" https://www.zigbee2mqtt.io/guide/adapters/deconz.html
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 :)
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.
There's also another, a built-in one.
Could still be behind cloud authentication, though.
> 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.
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.
Have fun!
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.
devices:
- /dev/ttyUSB0:/dev/ttyUSB0If 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
I’m impressed with your knowledge of the Linux ecosystem. Regardless, passing usb devices to the containerised version is still more effort than it’s worth for the average user.
Maybe Zigbee is different for some reason?
If my router is unplugged or offline, everything with power can still communicate for example.
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?
Also, the replacement process on the button cells tends to be so fiddly - tiny screws, tiny little doors, etc.
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.
Here’s hoping our device battery level detection is better than that of the sibling commenter.
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
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.
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.
It's whole terrible story.
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
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.
OR create frequent backups that are pushed to a better medium.
And then set up backups.
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.
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.
Highly recommended zooz devices, they’ve been robust and get consistent firmware updates.
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 will never buy another robot vacuum without Valetudo support as long as that project lives. It's great.
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.
Having to restore a snapshot each time I move floors is a lot more friction.
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.
privatize profits, socialize costs
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.
For those interested: This Reddit post had more info https://www.reddit.com/r/Roborock/comments/vlvep2/roborock_s... and a sub-post there linked to this Defcon presentation on rooting Roborock vacs https://dontvacuum.me/talks/DEFCON29/DEFCON29-vacuum-robots.....