If you like reading my journe, I have a kind of "smart" home since it's a modern one with a small p.v. plant, VMC, big hot water reservoir with heat pump + classic resistance kind-of integrated with the p.v:
- very first thing I want is knowing the state of my p.v. NOT needing a third party server on the other side of the planet just to see what my inverters do a meter away from my desktop and even more seen delayed and pruned data because the remote server can't handle the number of connected clients. I finally choose Victron and Fronius inverters since the first is nearly open platform (a rebranded Debian) with MQTT and ModBus services by default, the latter have an almost public API, ModBus only but at least a well known open protocol and the hw characteristics I was looking for. Even if both are not exactly cheap devices they look like crappy prototypes in software terms, at least they work.
- secondly since I have invested in a hot water system to consume less electricity from the grid I want to integrate it. It was 2017 so before the supply chain/China/covid/war/semi/* crisis, it was (still is) a Daikin gear not an unknown brand by some obscure seller. "yes, the system can talk ModBus RTU but you need a card, not in stock in 3-4 months you can have it for 350€" (oh, cheap since it's just an adapter between a serial proprietary protocol and ModBus but anyway)... Docs are incomplete of course, but in the end it work. However the p.v. integration is limited I can only command "go full power heat pump + resistance" (~3.6kW) or "go only heat pump" (~0.9kW) not for instance "go only resistance since it's -10℃ outside and I can barely spare 3kW now", at least I can programmatically see water temp so decide if it's better heat it a bit or not.
- third thing the VMC with built-in heat-pump, it talk ModBus natively, only I need a third party ModBus/TCP adapter to reach my homeserver, I found one, who curiously need to be configured on the same network card it will work with or it refuse to work (MAC address check, for unknown reasons apparently), again docs are not only bad but also false, some registers does not exists, some others discovered myself are not documented, some range and bitfields are wrong etc, again I manage to get them work but was not that immediate.
- forth, by electrical norms I need to measure and show consumed energy by at least heating, hot-water, etc so I need a smart meters. There are many on sale, nearly no one connectable via MQTT/ModBus or anything else standard beside passing through some third party server except, one is the new Shelly 4PM witch unfortunately it's 16A only, too little for local norms, so I go for another Carlo Giavazzi ET112 (I cite names just because nothing else exists AFAIK on sale) witch works well, but to have more than one one the same serial you need to change device ID by a 40+Mb windows only 32bit GUI crapware and a usb serial adapter that their software like, even if formally is a thing I can do with kermit/minicom/gtkterm IF someone just document the damns interface.
- fifth, since I have done that on a home server (Home Assistant, not something I really like but at least I can deploy via Pip NOT with pre-made out-of-date docker images or entire distro for raspi and co just for a damn small thing I would like thermometers, hygrometers, anemometers etc I can only found very few and very crappy. I would like to integrate portal/entryphone, the only usable option found is a hyper-expensive VoIP entryphone system since all the rest works only with some third party "clouds" or can't talk to anything else than their own display, proprietary/undocumented protocols. Not better for switches etc that are almost all wireless only, unreliable as hell.
Long story short: for too many there is no real purpose for a smart home because they do not have real automation use cases, so the really interested market is damn small so far. Those who are really interested can only find crap so most of them avoid going smart as much as possible. OEMs must agree on one/few open, common standards (we have some already like the decades old ModBus, slow but simple and the modern, simple and less cheap in electronics terms fast and rich MQTT) and learn to implement good interfaces with good docs and reliable devices instead of pushing Android on hyper-expensive SoC in a fridge. Then smart homes will take off.
Unfortunately we do not have vertical knowledge we have OEMs who buy something pre-made by someone else, bolt it in their product hope it will help sales but without even the knowledge needed to understand what they are doing.