Is “local” always local? For example, what if your “local polling” or “local push” device requires that you use the manufacturer’s smartphone app to join it to your wireless network or for other aspects of initial setup or ongoing tuning/configuration? Worse yet, what if that app requires you to log in to the manufacturer’s web service or simply doesn’t doesn’t work without a connection to their servers? What do you do when they shut off the web service upon which that app depends? Many Matter and Homekit devices seem to fall into this category.
I think it would be helpful if the “local” classifications were slightly more specific.
Why a new thread? Why generate more when the context of the above makes clear the question and provides good doc. Naively, I think this is the right thread to have the discussion on. The details in the OP haven’t changed to my knowledge so none of the context is outdated.
So, all of the integration information pages have a link like the one circled here:
Which takes you to the following documentation, which you might not immediately realize is in the form of a blog post, due to use of an anchor link…
Further down that page, you’ll see an invitation to discuss the documentation…
… which brought me here, and it was only then that I noticed the text about this being a “companion discussion topic” for a blog post, but since it seemed like the blog was being used as a CMS, with the post in question serving as the official documentation on the topic, I figured it was appropriate to comment here.
If the documentation ever gets updated, perhaps it will be done with a new blog post, in which case any further discussion will be tied to a new thread.
I appreciate the importance of politely educating newcomers about posting etiquette, and I understand the reasons why it is often undesirable to have people re-opening old threads, and, but I’m not sure those reasons apply in this case.
In any event, what’s done is done, and I’d love to get some feedback on what I posted and not have this turn into a discussion of proper forum use. (I might suggest that anyone interested in that topic create a new thread!)
This is a very good point, and deserves more clarity on the integration pages.
One device I have that fits this description is a Yeelight desk lamp. The Yeelight integration describes itself as “Local Push”, which is true, once you manage to complete their initial setup, which was an absolute bear. It took at least 20 attempts of resetting everything with the light, the app, and my account, before I could successfully connect and enable “LAN Control”, which is required for the HA integration to work. The integration docs do mention that setup is required through the app, at least.
After blissfully working for a couple months, the light factory reset itself, and I have been dreading having to go through that setup again. It’s almost not worth the trouble of having a smart light.
Another risk is the manufacturer pushing a firmware update through the app at some point in the future which disables LAN control before I can enable it. The required app setup is a big downside to using devices like this. Flashing the internal microcontroller with ESPHome or Tasmota is a permanent solution, but not always possible, and certainly not as straightforward.
Good point is that this information do not belong only in blog post from 7-years ago but instead should really be part of the official Home Assistant documentation (which it is not) → Documentation - Home Assistant or at the very least in the Home Assistant Developer Docs (which now only refer to this blog post) → https://developers.home-assistant.io/
I by the way asked a related question about the IoT classification of the ZHA integration 2-years ago and got no reply as of yet, see:
I’m not sure how you even have that question. It’s both local polling and local push. If you read the blurbs at face value, you can’t state that it’s local push when some things on it may require polling. Logically you’d have to list local polling and the website only supports 1 at a time.
After blissfully working for a couple months, the light factory reset itself, and I have been dreading having to go through that setup again. It’s almost not worth the trouble of having a smart light.
It’s sad to say, but these days the only sure fire way to avoid wasting your time with bait-and-switch promises of fully local operation is to flat out ignore all products with WiFi interfaces. It seems like you’re only safe with Zigbee, Z-Wave, perhaps Matter over Thread, and maybe Bluetooth (but probably not Bluetooth, because Bluetooth-enabled devices are often intended to be used with a mobile app, which generally invites trouble.)
The “Local Poling” and “Local Push” integration pages should have a mandatory section that describes in detail the steps to commission the device out of the box prior to integrating it with Home Assistant. If the steps involve installing a mobile app or require an Internet connection, that should be disclosed and the integration should be reclassified as something else like “Local Push - Some/All Devices Need Commissioning with Proprietary App/Cloud”. (but preferably more succinct) Pages for such integrations should also warn prospective buyers/users that devices may be rendered unmanageable in the future if the manufacturer discontinues the app/service or pushes an update that breaks local connections.
Another risk is the manufacturer pushing a firmware update through the app at some point in the future which disables LAN control before I can enable it.
All too common. Just look at the recent news about Bambu Lab 3D printers. Avoid!
The required app setup is a big downside to using devices like this. Flashing the internal microcontroller with ESPHome or Tasmota is a permanent solution, but not always possible, and certainly not as straightforward.
I’ve been known to do this, but I honestly find the popularity of the ESP32/ESP82xx platforms a little worrisome from a supply chain standpoint and I also try to limit my use of them for ethical reasons. (that’s a topic for a different thread, though) I look forward to similar options for devices based on the RP2350.
There seems to be a state / approach missing that HA could help with. Rather than assuming state, it could be derived from other sensors. For example, time of day and Lux level could be used to derive the state of a lamp. Sound level could be used to derive if the TV is on or off.
It’s not fair statement. Opt in for Shelly and you will be happy.
BTW upcoming 4th generation of Shellies is going to have wifi, bt and zigbee all together on board.
IIRC Paulus posted a comment a year ago or so that he would also like to create a device database (similar to the one Zigbee2MQTT) but for all devices compatible with all locally controlled devices that are natively compatible with Home Assistant.
If that ever comes to frutition then I imagine that such a device database could contain detailed information for each product (at least for Zigbee, Z-Wave, Thread, and Bluetooth devices).
I agree. Though I would also add recommendation to stay away from all Matter devices for now as well, and that includes Matter devices that uses Thread, because Matter still have loopholes that allow manufactures to add propriatory features that are only available in their own app and/or hub.
I would also recommend to try avoid all products that state that they require the manufacurer’s own app or hub/gateway/bridge because even if they claim it works locally there is still a chance it requires a clould connection/service at some point or that the manufacturer push a firmware update that changes it (like what is happening to Bambu Lab’s 3D pinters right now).
Sorry. The point I was trying to make is that not all but most WiFi-based products are that way, and if you find yourself looking at mass market “smart” devices on a typical retailer’s shelf, ignoring the ones with a WiFi logo is a way to avoid wasting your time. Obviously, there are many WiFi-based products that don’t have this issue, but they are in the minority.
Thanks for the suggestion of Shelly, but I am avoiding their products for now. I’d be more favorable toward their brand if they didn’t use Chinese micro controllers (ESP32), which concern me on grounds of security, human rights, and democracy. That’s a tangent for a different thread or DMs, though.
I support your sentiment in the big picture sense, so long as you don’t single out ESP32 but likewise dismiss any other products whose chips and or motherboards are made and or assembled in China - iPhone and so forth. Otherwise it seems arbitrary. The right way to deal with ESP32 being from China, is by Western manufacturers giving companies like Shelly an option that’s at least half as good for double the money.
That is, why not make the website support more than one at a time?
