You’re right. It did not work the way I expected, but it did work. Thanks.
“two weeks”
Except Tesla EVENTUALLY makes good on their promises, just a LITTLE later than 2 actual weeks.I’ve been waiting years. I went with YoLink because they had a solution to shut-off the water main [father in water came home to severe flooding once]. I thought cloud control was a bad idea, but local integration was promised to be coming.
I may be probing the valve control with a multimeter to control the over priced thing with Tasmota & a NodeMCU (or a Zigbee dev board), then I can add much cheaper leak sensors to the other places that I want them and link them all via Home Assistant. I have many door and window sensors on YoLink, but only a handful of leak sensors.
Maybe I will but more ZoLink leak detectors, but not without them working locally. What good are they if I am reliant on my internet provider, their server, their management, and then my smart home?
They could pull a wink hub on me.
I better not need a special hub for local support. I can’t believe no one has figured out a way to run a server on a docker instance that pretends to be their server and talks to Home Assistant and the hub (then you would just need to tell your router to redirect request to whatever their router is to that address.
Or just jail broken the hub.
I guess we’re all hoping YoSmart will follow through on their promises. I really home they release an update for local support, this doesn’t need to be a new hub.
Up this thread there’s a guy that made good progress reverse engineering YoLink and with deep hacks got it working locally. But could not get to the point of a setup reproduceable in general. If I got him right, it was due to not being able to find the master encryption keys within dumps of the processor.
I did this research. I was able to get a hub to report locally over MQTT, but the problem is the hub does nothing more than take MQTT messages and play them over LoRa. The hub doesn’t even know what the message says/means. The end sensor receives the message over LoRa and then does what it does. In Theory, if we could get the encryption key, we could then very easily implement a local control. I never released a way to get MQTT reporting locally since it was a moot point without the keys.
When I stopped researching these devices, the direction I was headed was to pull encryption keys from the sensor MCU’s themselves. I managed to pull flash dumps from a few sensors and began trying to find the keys, but I have limited experience with ARM reverse engineering. If someone wanted to pick it up, I relatively recently open sourced my research. Feel free to take a look.
In the end, I accepted the fact that we would need to wait on yolink to hold to their promise of releasing local control. However, I have not purchased any more yolink devices as I think the company will not release local control. If they do, I will happily drop +$1,000 USD on sensors the day local control works.
3 Likes
I was surprised that the comms are encrypted all the way from the end sensors. Were you able to infer whether there’s some kind of cryptographic handshake during initial pairing? Perhaps the key can be sniffed at that point. Although if a secure key exchange mechanism is in use that would be unfeasible. Luckily, in power-constrained devices this is not the norm.
The other possibility is the presence of a hardcoded key, but if it’s inside of a secure element then extracting would take deep hardware hacking.
There is an initial pairing between the sensor and the cloud, where I suspect some sort of key exchange takes place. There are 3 messages exchanged during pairing. 2 from cloud to sensor, one from sensor to cloud. Since all of these messages are encrypted, simply sniffing them does not work.
My belief of this exchange is as follows:
- (Message 1) When the sensor starts up (or when manual pairing is initiated), it begins broadcasting, which the hub picks up as the hub relays all LoRa messages it gets to the cloud. I surmise this initial message is encrypted using a static key that is the same across sensors.
- (Message 2) The cloud receives the QR code (which appears to be the SN or MAC address of the sensor, and some other unidentified information). The cloud then sends down a message to hub for it to relay. This message, I surmise, is a key exchange where the cloud sends down a unique key for the sensor to use.
- (Message 3) The sensor accepts the new key, and sends an ACK message, encrypted with the new key. If the cloud receives a properly formatted/encrypted ACK, then pairing is complete.
In researching these devices, the cloud side appears to be running a very standard LoRa stack (I believe it’s called ChirpStack but I forget at the moment). This stack seems to follow the above messaging I outlined. If the initial key could be extracted, then a ChirpStack instance could be instantiated with this key. Then, all messaging is handled by ChirpStack, including the unique key exchange.
Mind you, there is the MQTT transport that is relaying messages from the hub to the cloud. I recall seeing some repos on github that integrated MQTT and ChirpStack.
Again, I’m not sure if ChirpStack is the correct name.
Edit:
Mind you, this is only to get initial communication working. Once the messages arrive at ChirpStack, there is still work that would be needed to actually interpret the messages from the sensor to know what it’s reporting, what commands it accepts, etc.
2 Likes
It is completely possible.
- The hub is a server, it just needs a firmware update
- A server could be run in docker if YoLink doesn’t want to do the work of making it truly local as promised. The docker server would forward to Home Assistant (or Hubitat, etc). The hub could just point to the virtual server. This would be messier than promised, but it would work, even if your internet fails or YoSmart servers were not available, or they started charging fees (see Wink hub)
@Badabinski
If they already use MQTT, could you buy a LoRA dev board and have it listen for MQTT messages?
Then, relay messages to WiFi MQTT so that it could be used in Home Assistant? [And vice versa so that it is 2-way,
HA would see that YoLink leak detectors or other sensors go off. Zigbee leak sensors could turn off my YoLink Water Valve.
Specific IP devices can be blocked from Internet access, at least in the pfSense firewall I use. That would prevent any automatic firmware upgrade to the hub, assuming the local control feature is ever delivered.
Note that a Man-in-the-Middle strategy putting an MQTT server or whatever in between won’t work because, as austinc3030 has explained, all comms are end-to-end encrypted from the node itself.
Thanks for clarifying that. I was beginning to think I forgot to mention the end-to-end encryption. 
Yep, the encryption stumped me. I was considering trying to nab the static key from an end device, but I’ve given up on that. I’m very comfortable with networking and higher level software development, but I’ve never done anything as low-level as doing RE on an already-flashed ESP. Instead, I’ve just gone all-in on z-wave Long Range which is good enough for my needs. I hope that Yolink eventually implements Matter support. More importantly, I hope that their Matter support is completely divorced from the cloud. I can just imagine a scenario where the hub is just translating Matter to HTTP API calls against some Yolink server (like what I imagine the app does), and then the device being configured by the same encrypted MQTT nonsense coming back from the cloud. I really hope I’m wrong, but the fact that they include a cellular modem as a backup makes me fear that I’m not.
1 Like
After visiting and reading this thread several times over the past, I have to agree with others: fully local support will never happen, at least not in the sense or spirit that we would expect.
The only explanation with Chinese companies like YoLink/YoSmart, Tuya, Temu, DJI, Bambu Labs, TikTok, Huawei et al. is that they are strongly incentivized to maintain a presence on the network, for reasons we can only speculate. Likely paid for or coerced by the Chinese government if I had to guess. So this means local API support might “work” someday, so long as we are forced to leave the door open for snooping and meddling on the network, in some manner.
I very much doubt that the value comes from knowing how often you open the refrigerator or how much water you use. Phones, social media, email, web browsing, etc. has already long since perfected the art of violating privacy for advertising and marketing purposes. It has to be deeper than that.
Being on a LAN in proximity to privileged accounts (which are often accessed without SSL, sadly typical of cameras, routers and NAS devices), and easily inferring physical location from IP or MAC address, means by all probability any target will eventually turn up. For the majority of users, this isn’t a concern, but if a device wakes up on a network known to be a high value target, then maybe you receive “the special firmware” instead of just a key exchange.
Sorry if this is too tin-foil hat for some people. However, to me, this explanation makes a lot more sense than a subscriptionless business model! And the reality is that it’s becoming increasingly easy to accomplish things which used to take many man hours (like combing through files and logs) by just running data through LLM’s. So it reduces it to compute time instead of inconsistent manual review for “them” to find whatever it is “they” are looking for. I suspect it’s by design…
2 Likes
I agree. I became permanently paranoid about security when my boss called me at work one day and asked why I had submitted a claim with my state unemployment department’s office for unemployment compensation. Think about that and let it sink in for a minute… Y.I.K.E.S.!
As the old dogma goes, if you get a product for free, you are the product that’s being sold. Locking you into the ecosystem is the best way to suck up and monetize your data (and provide it to whatever respective government demands it), and to ensure that you have to keep buying their newest model just because they stop supporting the old ones that still work perfectly.
Anyone able to get their account login to work to add the integration?
I just get an error: “Account info not match,Login failed.”
And I get a weird API response:
@Eric-YoLink @matrixd2
Earlier posts in the thread indicated that you needed to load the api.yosmart.com page with HTTPS, but that’s currently occurring because it was fixed (When linking account on yolink integration https should be used · Issue #72863 · home-assistant/core · GitHub)
Eric is no longer associated with Yolink.
Yes, I just rejoined my account with no issues. Try adding the integration to Home Assistant using the same device that has the Yolink app installed. This basically did the work for me and opened links that I just had to approve. Done. Simple.
1 Like
Good tip! That worked great – I couldn’t get any other method to work, but the app loaded and authorized me after a few seconds. Thank you!
1 Like
Is it just me or is it a general issue with the yolink hub going offline? For me it’s getting worse. Only way to solve it for me is a power cycle of the hub. It has a wired connection so it’s definitely not a wifi issue. As the HA standard integration doesn’t have any sensor for indicating if the hub is online it’s also hard to mitigate with a smart plug and a script 
1,000% agreed. I have developed a relationship with their programmer that did the yolink integration and learned alot from him on how they do things.
I only stuck with them because they offer the 24/7 online monitoring through Virtualarm (with terrific granularity on what ou want them to monitor for each individual Yolink device) that will call the authorities if you do not reply. Particularly good for their smoke alarms. My wife nuked a poptato twice by mistake and the fire departmewnt was there in 5 minutes after we did not respond to phone calls - only because we could not hear them while we were runng around opening windows to air the place out!
Above is the ONLY reason to go with Yolink - mainly because of the below traffic patterns which are a poor design as per below:
IOT Device / Sensor ↔ Your Yolink hub ↔ Yolink cloud servers ↔ Your router ↔ Home Assistant
IOT Device / Sensor ↔ Your Yolink hub ↔ Yolink cloud servers ↔ Your router ↔ your yolink phone app
or if you are using our phjone and not on Wifi -
IOT Device / Sensor ↔ Your Yolink hub ↔ Yolink cloud servers ↔ your cell phone provider’s internet connection ↔ your yolink phone app
HA does NOT communicate with the Yolink hub directly AT ALL. In the case of the Yolink hub going offline it is only because:
Yolink cloud servers lose MQTT connection to your yolink hub (which they try to keep open) so they send a message to ↔ Your router ↔ Your Home Assistant
They will never come out with a local solution for the old hub even though they say they will, as we have been asking for it for years. They did come out with a new hub which requires a cell phone connection to only connect to the yolinkk servers to not require an internet connection for the hub itself. Supposedly there is the abiility (an API) to connect to that hub directly from wthin the local network but I do not believe the yolink integration supports that local connection for the new hub.
I have tight security and my router only gives internet access to devices through one connection which is a pool of 10 vpn tunnels (two VPN service providers, 5 tunnels each), each tunnel connecting to a different server on the internet which is located in a non nine-eyes country. The VPN’s are both headquartered in non nine-eyes countries as well.
Anyway, I am getting off subject but for good reason. The yolink hub connects to the internet through your router by establishing an MQTT connection to the yolink cloud servers, kept open to maximize speed of the traffic. If the MQTT connection is lost the yolink hub tries to reconect to it I believe it is every 10 seconds. That is how the yolink cloud servers know when the connection is lost. You will see a message in the log about the mqtt connection lost (but never when it is re-estanblished (?)… Also, the yolink HA integration connects to the yolink cloud servers using the same paradigm (an open tunnel for MQTT to use).
Also due to the way we are connected to yolink, a VPN cannot therefore be used, two places (both through your router of course) - for any kind of 80% (?) reliability for the below connections 1. The yolink hub to the internet, and 2. Your HA instance to the internet.
Remember: HA does NOT communicate with the Yolink hub directly AT ALL.
Yolink hub ↔ your router ↔ yolink cloud servers ↔ your router ↔ HA Instance
I endlesly tweaked everything to death and was ready to throw in the towel with yolink until I set it up in that manner…
Hope that helps!
(PS: In other words, anything and everything that includes the old yolink hub or the yolink ha integration anywhere in your infrastructure in the equation - you need wide open, I mean completely wide open - connection to the internet, no VPNs or filtering out advertisements etc. just wide open)