YoLink integration

Q2? So are we still in Q4 of the business year and their Q2 won’t begin until late June then?

April of last year they said they’d release something by the end of 2024. Now maybe it’s Q2 of this year which will probably be July at the earliest? Why must they test our patience so much lol?

So I looked up the user guide for the Hub 3 and changed the 5 to a 6 just to see if anything would happen. Turns out the new Hub’s user guide is online. After all these years it’s finally real and we can take an early look at it

https://www.yosmart.com/support/YS1606-UC/docs/instruction

2 Likes

@Rice_Eater this is very exciting news, ESPECIALLY if the new hub will work with the same old yolink sensors…

Nice find! Maybe it actually is finally getting close!

Nice, though I also assume the yolink integration may need to be updated too to work locally as currently it makes requests to the yolink website which would have to change with a local device

It looks like the local hub will act as a matter gateway, eliminating the need for a YoLink integration altogether.

@starsoccer Looks like we have two methods for local control, Matter and a local API.

As most of us should know, Matter can be rather limiting. Especially with exposing more entities. So I would opt to keep using their integration assuming the local version is on par with the current cloud one.

I don’t know what that means though. Will the current integration support cloud and local devices or will there be a separate cloud and local integration?

1 Like

I mean I think matter will likely work out of the box, but I think the local api integration likely wont work out of the box and may need changes done to the integration. We wont know till it comes out and someone tries or yolink clarifies

I did some extensive RE (GitHub - dynacylabs/yolink_re) on yolink devices and thought I’d offer my 2 cents.

Based on what I am seeing, there is a decent chance the manual found applies to the “Hub 3” that “mistakenly” went on sale a few months ago. Quick background on that:

A few months ago, yolink’s site showed a “Hub3” in stock. I was quick enough that I ordered one. I got an email from yolink saying “we ordered 2 ‘dev’ units for our engineers and they were mistakenly inventoried. Would you like a refund and a discount on future products, or would you prefer to receive the device?”

I opted to receive the device. While I waited, I browsed YoSmart’s FCC applications and found FCC ID 2ATM71605. When I received the device, I confirmed the FCC application matched the device I received. I did a quick teardown (https://photos.app.goo.gl/ZikUWUshFzpnYiZK7) and hooked up some debug probes.

With the debug probes, I confirmed the device is running UBOOT 1.1.3. The SOC appears to be supported by OpenWrt so they may be using OpenWrt as a base for the hub’s firmware. EDIT: This SOC, if running OpenWrt or a variant, should have enough CPU to support a local API/Matter. I hope they are going to bring all features down to the device level as well (button press on keyfob trigger’s garage door opener without going to the cloud). The previous hubs running an ESP32 definitely wouldn’t have been able to support cloud, local api, and local automations.

What I am surmising is that the “Hub3” I received will be the same as the Hub from the manual posted. The case looks the same, the ports (ethernet, power) and power switch all are in the same location.

Just to clarify your saying the Hub3 you ordered is different then the Hub3 currently on the site and you think you actually got what Ill just call a Hub4?

I am proposing that the hub 3 currently for sale on the site is the same device that I received. But what I am suggesting is that the “hub 4” will be the same hardware as the hub 3 and the only difference will be in the firmware.

Ignoring the theorized “hub4”, I found there to be 4 hubs yolink has sold. The first 2 hubs were identical hardware and firmware, with the only difference being form factor (the “earlier” board was physically larger). These both utilized an ESP32 as the main processor. The third hub was the speaker hub. This utilized a different ESP processor from the first 2 hubs, but was otherwise identical to the other hubs hardware wise. The fourth hub is the hub3 that runs a completely different, and more capable processor. All hubs use a yolink specific daughterboard for Lora communication.

I am theorizing that the hub 4, the only change is going to be firmware, similar to the first two hubs being identical hardware wise.

If/when a new hub is released, I will happily be buying one to conduct further RE on it, but it likely will end with the same result: we need the keys to be able to decrypt messages. Optimistically, the new hub or new firmware will have the keys locally which would make extraction easier. If the keys can be derived, then al previous hubs would support custom firmware that could take the Lora messages and broadcast them via MQTT, completely negating the need for yolink cloud, which is what we all want in the first place.

Some people that are using the Virtualarm service want the cloud connection for just that. Of course I THINK the HA integration needs to be updated/changed for this as well but you are saying the Hub4 would have local access such that HA would be able to interact ‘directly’ with sensors through the Hub? If so, why bother hacking it - or just exploring?

I’m keeping an eye on it. Looking thru the document it looks promising. Here is a list of features/caveats and they seem reasonable. Local api sounds great and might have similar entities to the official app and hopefully matter will also expose important entities (always a concern).

Features:

  1. Local Automation: Supports local automation rules that work without needing cloud connectivity.
  2. Sunset/Sunrise and Scheduling: Allows you to set advanced scheduling options, like triggering actions based on sunrise and sunset times.
  3. Local Integrations: Supports Local API and Matter for managing local events and commands within the local network.
  4. Automatic Network Synchronization: Automatically syncs subnet information to ensure smooth and uninterrupted operation.
  5. Multiple Connectivity Options: Offers flexibility with Ethernet, dual-band WiFi, and cellular connectivity.

Limitations:

  1. Local Network Restriction: Devices within the Local Area Network (LAN) will only communicate with the Local Hub in that network.
  2. Offline Limitations: Apps, alarm strategies, scenes, and automation rules (created through the YoLink app’s Smart Automation page) cannot work without an internet connection.

I’m expecting Matter to be pretty barebones(like a contact sensor only gives us open/close). So I’m hoping whatever we get out of the local API is at least on par with the current integration.

As for the limitations, they don’t seem like a problem for HA users. We were going to create our own automations in HA anyways and ignore the app after setting up the local hub and connecting devices to it.

Regarding limitation #1, is that true even with mDNS reflection? My current hub is on an IOT vlan and my HA instance is not, they speak with no issue - ?

I’ve a question on the Yolink integration, but also some news on my conversation with them yesterday:

The new local hub (non cloud) is currently under testing with some US customers, prior to public release. It only operates currently on US frequencies.

And now my question, in case anyone can help:

Can anyone confirm whether the EU hubs (and associated EU frequency sensors) are supported in the HA integration?

The integration page only lists the ‘UC’ (US) based devices, but I thought I’d seen a thread somewhere saying that the EU/UK versions were working also.

I’m in the UK and trying to source the EU frequency hub (MODEL: YS1603-EU) and external contact sensors (MODEL: YS7707-EU), in order to integrate them with HA. At the moment I cannot find the products (only the US, ‘-UC’ part numbers), so be grateful for anyone who’s located any.

Can’t help you with your question, but I appreciate the update!

As a cyber security professional, I am of the belief there is always something to be gained from researching and analyzing a new device. Whether it be to document an emerging technology, improve one’s skill set, or simply because we can, there is virtually no reason not to investigate a device.

YoLink is the first (that I know of) to introduce Lora into an end product for the everyday consumer. This makes it very appealing for a number of reasons. For the majority of the market, YoLink’s offering will suffice. But there is a share of the market who may be under-served by their offering.

HA exists for this reason. Countless IOT devices, built by many manufacturers, each with their own half-baked ecosystem. Sure, the Phillips Hue devices work together, but without HA, good luck getting a Lutron Switch to play nicely.

Only in the last few years have we seen standards like Matter and HomeKit be implemented that allow inter-ecosystem integration. But even these standards are not a turn-key solution. Some manufacturers support Matter but not HomeKit, and some support HomeKit but not Matter. But HA supports both, thus bridging the gap even further.

Plenty of integrations started as cloud integrations and later became local integrations through the manufacturer opening up their product. And how many of those integrations were further improved by someone’s work?

A great anecdote on this point is the Emporia Vue 2 (and now 3). There is a perfectly capable cloud integration for the Emporia ecosystem (GitHub - magico13/ha-emporia-vue: Home Assistant Integration for Emporia Vue Energy Monitor). And yet, @flaviut, a security researcher, saw the value in a local integration using ESPHome (GitHub - emporia-vue-local/esphome: Custom component for ESPHome to add support for the Emporia Vue 2 energy monitor). Now we have two offerings, each with their own strengths.

Just because an integration already exists doesn’t mean it can’t be improved upon.

And lastly, to quote your message from Jul 2024: “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.”

How will the new hub having a cellular model fit into your security model? Sure, they say the cellular service is only for backup communication with their server. And there may even be a switch in the app to toggle between cloud and local. But do you trust the word of a company who has fumbled on their promises and promotes a closed ecosystem?

I, personally, do not. I would rather someone research the device to ensure my data isn’t being exfilled over a channel I have no control over.

3 Likes

This needs to be the default thinking. Even if it shows no signs of snooping today, any device with a connection to the outside world is a simple firmware update or command away from being able to do so.

Without getting into the international politics and business strategy mess, it does beg the question of how they will implement matter along side their existing security model. The devices are end-to-end encrypted. This means the existing hubs have no ability to read the contents of the packets or issue firmware updates/commands. My understanding is that they only store & forward.

Matter is also end-to-end encrypted. So will they:
a) Add another provisioning model where sensors can communicate & pair with the hub locally, and the hub “translates” between YoLink and matter ecosystems
b) Implement matter on the sensors themselves either as a replacement or sidecar to the existing model
c) Orphan the devices from the cloud such that the user is responsible for the certificate management, and then the method employed doesn’t really matter

My assumption is their hands are tied with regard to the cloud based certificates. If those are ever found in the open, then anyone within a quarter mile of a YoLink device can issue a rogue firmware update, as there is nothing on the sensor itself that requires physical access to do so.

So why does it “matter” which approach they use? The reason is security certificates have an expiration date and renewal process. If the devices are still paired to the cloud then the expiration can be set conservatively (6 months or a year) and it becomes a situation where you have to reconnect to the cloud periodically for it to refresh the certificates. Hence they could also deploy a mandatory firmware update before allowing fresh certificates, and we are back to square one with the blurry line between “leasing” the devices or owning them.

Incidentally, option c (the orphan route) is the easiest and quickest to implement, so I am assuming it was already ruled out, and the certificates or some other “gotcha” is going to come into play.

Just a heads up after contacting support a while back I just got an email out of the blue telling me they just got some of the new hubs(YS1606) in their warehouse and it supports local api and matter.

They told me I could purchase it as I showed interest previously, so I just ordered it and am eagerly awaiting delivery.

2 Likes