I’m focused here only on the option to add devices for Wi-Fi devices; Zigbee already has a solution and isn’t the focus here.
Currently, Wi-Fi devices, when in synchronization mode, offer an access point (AP) that the device connects to. You provide the Wi-Fi address, and it configures the device. But what happens after that? Is there documentation or a known endpoint that allows pooling the device’s data to its IP address?
I know that LocalTuya handles this communication after connection, but since several platforms function similarly from a UX perspective, wouldn’t it be possible to create an initial solution for Android to perform the initial step and send this data to Home Assistant?
There is no single standard for wifi type devices (except matter over wifi) and therefore you’re talking about reverse engineering every single manufacturer’s integration and providing them on a manufacturer by manufacturer basis. Most manufacturers don’t want to do that so they lean on something like Tuya…
Which is provided already as an integration. Exactly how it’s done right now.
They’re not wifi devices. They’re (insert manufacturer name here) devices that happen to run on wifi and Tuyas walled garden.
You mean like normal DHCP functionality on your router (a basic network function), completely unrelated to Android (an operating system promoted by Google)?
Allocating a fixed/static IP address?
Bypassing the new device autodiscovery process in HomeAssistant?
Using Tuya functionality on non-Tuya devices?
What do you do for non-Android users, such as those that use Windoze, or Apple ecosystems?
Where does Matter onboarding come into this? Apple, Samsung, Google, Amazon, etc ecosystems.
WiFi, Bluetooth, Thread, LoRa, whatever.
I’m not understanding your question, or suggestion.
I had to smile on that one - so true! As long as they understand each other. HomeAssistant is just the puppeteer pulling the strings to glue it all together.
Today, TinyTuya can retrieve the data after the integration has been completed, which enables collecting the local connection in the same way Tuya Local works.
My question/interest is: why isn’t there, in the Home Assistant Android app, a process to add a device? Is the handshake process obscure, or is it not open?
Today we have this problem solved for Zigbee because you can use zigbee2mqtt. But for Wi‑Fi devices, setup using Tuya/Smart Life/eWeLink’s “add device” is mandatory—even if after the process you can run locally. So why not add the Wi‑Fi device and register Home Assistant as the “cloud” for the Wi‑Fi device?
My Home Assistant runs in Docker and has no access to Wi‑Fi. If a Wi‑Fi device—like a smart Wi‑Fi plug—connects to the same network, will Home Assistant be able to add it directly through the web interface without me needing to add it in the Tuya app for it to show up in the Tuya integration? As far as I know (and given the limitation of my Home Assistant setup), it can only be added using the Tuya app, and then it appears in the device list of the Tuya integration.
Step by step, for me to add a new Wi‑Fi device compatible with Tuya (but this also applies to Aqara, Sonoff, etc.):
For Tuya to find the device, besides providing an AP name, it must expose other discovery information. After that, the Tuya app accesses some endpoint that identifies/registers the device on the chosen network and connects it to the cloud. Why can’t this initial step for Wi‑Fi devices be available in the Home Assistant app and, for example, have a Wi‑Fi integration that supports some common protocols (does that exist?) for the Wi‑Fi device?
What you describe has to be provided by the manufacturer or someone who reverse engineers the protocol. That’s what the integration DOES. There’s already a process called Zeroconf discovery which listens to the 'wire and finds ad much as it can and guess what on some Wi-Fi type devices Zeroconf pops a discovery item that tells the user hey install this integration to set this thing up.
Its already doing as much of the process as you want as is possible with the available technology.
The process for. Zigbee is exactly identical. They ship ZHA in box for it. And the Tuya integration ships for Tuya. And the Esphome integration ships for Esphome devices and the ZWaveJS integration ships for ZWave… (see the point)
WiFi is not a universal medium. Yes I can see something is there yes I can try to fingerprint it but the minute you’re inside the protocol you are reliant on the manufacturer unless it’s a standard. Tuya is NOT a standard.
By deliberate design, each manufacturer tends to make it difficult so it can lock users into their own ecosystem. Get used to it - it is called corporate profits and capitalism. Others call it corporate greed and bastardry, dog-eat-dog and the users be damned!
Delve into the code used for autodiscovery by HomeAssistant and you will see why. Despite severe obstacles, heavy duty reverse engineering by dedicated individuals has made the process quote simple for most people, and exposed how computers can not only make life easy, but also horribly difficult if you want to step out of the well trodden path so temptingly laid out in front of you by corporate marketing.
Actually it probably is, by sheer volume of devices out there. Maybe call it pervasive, rather than standard. Constantly changing and evolving, but oh so tempting for people that want an easy cheap solution without needing to get too technically involved. For people looking to release a new product, want a thousand devices or a million? Just sign up to Tuya, login, follow the wizard to choose the templates provided, add a few pictures for corporate branding and you have a finished product ready in a few weeks. Ignore the corporate cloud lock-in behind the scenes, and potential security and privacy issues - not my problem - yours, and as a purchaser, you will capitulate, always, as you saved ten cents when you bought it online on a well known Asian website against a cheap clone of a well known corporate brand that you also suspect shafts you too.
Matter was touted as the universal cure for this. A year of real devices out there has shown what has actually happened, the consortium members developing a superficiall standard, adding their own unique extensions to make them all incompatible, and using heavy marketing to convince the sheeple to replace their still working existing equipment with new stuff that still needs detailed technical skills to troubleshoot. Standards steered by corporate need to make profits, rather than the common good.
Webysther, you are either deliberately baiting us, for AI/LLM bot learning or a homework paper, or your naive ignorance is showing. You show ignorance of technical standards, commercial reality, and technical processes that have been cobbled together at many levels to make the moden world so connected. Please do some more research. Commercial reality can often interrupt tilting at windmills.
I think you are being harsh here. The question seemed sincere to me. Naive ignorance is nothing to be ashamed of. Ignorance can only be cured by asking questions.
I’m not trying to shame, just highlight the issue is far more complex than evidenced by his posts, guiding him to some areas he might wish to research to expand his understanding. We all learn - it is a never ending journey in life. To ask ‘why it is so’ is one place to start, and knowledge can be empowering and where there is an open mind, enabling too.
IT can be complex at times and if you do not have the knowledge of the terms used in the field, then a technical explaination can be gibberish.
In IT networks you often have a transport protocol and a communication protocol.
A transport protocol could be called the roads with traffic rules, just like the real world.
If you want to have something transported in these roads then you need a courier, which can be found by looking at advertisements for such, like on the internet, TV, billboards. These medias would be equal to discovery services in the Iat network, like ZeroConfig, SSDP and uPNP.
Once you decided for a courier service then you need to order a courier for your goods to be transported.
The actual courier is the communication protocol in an IT network.
Now the roads and the traffic rules are pretty standard, so it is everyone with a drivers license can use them. It is a common standard.
The advertisements are multiple and there are many more than the ones I mentioned, but there are some big ones that can be called defacto standard, so those can easily be taught to a person.
The courier ordering is harder, because each courier have their own ordering process. Some do it on a website with different information needed, some require a phone call, others need an app installed and so on.
There is no real standard for this part and that is the part that is requested a standard way for.
I only use AI for translation (and god help your souls because I will not filter my english in this one) as my mother language is portuguese
Totally naive, I’m a software engineer and IoT is not my main area, far from this.
IOT7712 I got your point, but my question is because my personal journey which looks to be similar to some people:
Buy some devices to use around, started with wifi one
Get wifi limitation, find tuya, buy some
Find Home Assistant after some months
Start you homelab to use more offline stuff
Last which lead me to the question: migrate to z2m and get stuck with the old wifi devices I buy years ago (step 1)
The problem is more about the UX to be honest and I think because I don’t have ideia that HA have autodiscovery if have wifi, bt and zigbee available to him. I only use the home assistant in docker w/o any hardware.
Thanks for the point about autodiscovery, my installation don’t have this because I only use as a docker service. Another point is that, my network use VLAN and I don’t allow traffic between them, this is easy using openwrt but I prefer to keep the zeroconf out of my network, moving UDP over around and sometimes deal with broadcast it’s not what I want.
There some way to ditch the wifi devices from tuya using only home assistant? For my knowledge is trash them and buy zigbee alternatives or using local tuya/tuya local
For wifi devices the guide of orange-assistant is correct, you need to flash a new firmware for every wifi device you have to allow using mqtt or the socket like ESPHome.
I have a tuya thermostat for my gas boiler which is wifi, to remove from tuya (and not only use local with tuya local), I need to install a ESPHome (https://devices.esphome.io/devices/beca-thermostat/) and after that the autodiscovery/manual will works inside HA. Another solution is install tasmota which is similar ideia of ESPHome but works using MQTT, if you have a mqtt broker already working, maybe makes sense install tasmota to keep the broker.
PS: Tasmota vs ESPHome is a hot topic, I only discover this yesterday…
I found the ESPHome have some advantages, like keep some automation inside the device. Still I don’t know because I already have mqtt, maybe I test using both for the wifi devices…
