YoLink integration

The documentation link you provided for Hub 3 makes it clear that the device (at the time of that documentation) is NOT the local only hub we are looking for. The following is an expect quote from the manual:

A continuous internet connection is essential for the Hub 3, achievable through WiFi, Ethernet, or a Cellular SIM card (4G LTE, 3G, or 2G)

While this dosent meant they won’t offer a future firmware release that adds Matter support or even locally hosted MQTT services (that MAY or may not ) require an outbound connection to their servers…. It just means that any SHORT term expectations of the 3 year dangled solution are not likely.

The bottom line as a long time product manager for a for a TECHNOLOGY most of you certainly use is this; there is no TECHNICAL reason a purely local device can’t be produced, and additional services added on top of that. The reality is it’s NOT their BUSINESS model.

And as much as I wish it were not the case, if I were in their place I WOULD’T do it either (though I wouldn’t string folks along). Frankly from a biz perspective the market opportunity is relatively small and RELATIVELY fixed. They are NOT going to SUBSTANTIALLY grow the number of customers (and thus revenue) by delivering a local only product. The market of folks who want this is small (let’s say all 1100 of us). What happens after we buy them? Sure we will “keep buying” new Lo cost sensors for those rare cases where our environment changes. And perhaps the same percentage of all NEW Home Assistant install users choose to buy Yolink products but that ALONE becomes you revenue source to sustain continuing engineering as well as FUTURE R&D. I just don’t see it….Not given that they ALREADY have a viable biz model (with their lock in) unfortunately, so why would the risk it. They clearly have everything to lose with little real upside. Perhaps they might be able to consolidate some market share from other competitors but this will never be a mass market product that can be supported by an expectation of almost endless new users coming to the platform or replacing defective/obsolete products.

After spending some time thinking about how one could compromise the encryption keys during enrollment (using a potentially competmized hub or proxy) at best you end up with a device that would be permanently sandboxed from the public Internet and thus unable to interact using any Yolink apps or functionality. Not a horrible solution as if it ever sees the real net it could be bricked or less changed, firmware rewritten etc). Of course that also mean no Yolink app functionality. Just sensors on MQTT, and a lot of work to get there. I would do it if I could because I just don’t see anyone producing a the long range battery powered sensors I want using open standards. Given these are being used for security, the temptation to exploit the REQUIRED security/encryption for their own business purposes is far to great. In the end I don’t see anyone closing to do the work and then leave what they see as money or market control on the table.

Apologies for the rant…. Net net I just don’t se is getting what we want short of building our own sensors…. Like was done with the everything sensor and others)

An example of my suggestion that we croudDev. I’m now starting to look at building my own OPEN solutions (for personal use). While they may cost a bit more to build than off the shelf solutions from yolonk, we can have TRANSPARENT source code (from chip up), PUBLISHED interfaces, and the opportunity to create open source APIs using STANDARD message passing interface.

https://store.rakwireless.com/products/sensor-hub?m=3&h=sensor-hub-all&variant=42418231279814

Their entire LoRaWAN product line

and of course not just limited RAK with cost effective solutions like:

https://www.amazon.com/DIYmalls-915MHz-Protective-Arduino-LoraWan/dp/B09N8HZLTB

And finally an example of the type of sensor that started me looking at Yolink, No I wouldn’t likely trust this company’s product on my LAN but on the LoRaWAN where I choose/or craft the LAN hub/gateway I just might pick up a device like this.

Outdoor contact sensor

Think reference design kit with PoE, (optional solar input) charging of a rechargeable Li battery that should easily provide up to years of off standalone functionality (dependent on cells selected). Hardware side shouldn’t be to hard. The challenge and fun will be in the software side.

This and similar companies are the only real hope we have of moving Yolonk and others to breakdown their walled garden and let us have access to our devices. Even if we only come up with a base reference design, and a basic GitHub repo, folks can build on there own solutions to fit their own needs (think ESP32). This will if successful also pressure the current consumer focused companies to release the products we want or others will leverage our efforts and make kits that will progressively eat away at there legacy market…. Evolve or die is the law of the market, we just need to provide the impetus to move them, and create that missing business case for why they need to deliver.

Anyone else interested, and able to devote a bit of time to seeing what we can build on these platforms? Seems a better bet than playing wack-a-mole with Yolink’s current cloud lock or watering and HOPING they will ship a hub that one day then gets an update that then provides a solution that allows for COMPLETE unfettered local ONLY access after enrollment…

If there is interest we can discuss further and more appropriate form as I don’t want to keep flooding this forum so this is my last post on the matter and my apology for my verbosity, it’s just I have seen this all many times over the years. I sincerely want to help and move this space forward while also filling out my knowledge in several key areas along the way.

Regards.
T

Id gladly help.

I also agree it would be nice if someone came out with something easy to use for LORA. I know there are some other projects in the work but Im not aware of any released to date that integrate totally locally with HA

It is my understanding that the hub 3 will talk directly to HA for it’s devices (once Yolink updates their integration for the hub 3). The internet connection is required for the hub 3 to stil be able to offer services like virtualarm (24/7 monitoring where they will call the police if you do not answer when they first call you - all triggered by whatever yolink device you have that you desire). So in that case it would work locally but also needs the internet to provide you with the 24/7 monitoring services should you wish to use them. There is no other integration provider I know of that works with HA that offers a 24/7 monitorn service.

Thanks for the insight.

For my OWN PERSONAL perspective I am less concerned with an EXTERNAL monitoring solution.

For me having battery backed local speaker/siren access is sufficient. Thses can be activated LOCALLY (as YooLink seems to offer under the branding of Control-D2D).

In terms of Fire/Police notification for dispatch, I expect this will be serviceable locally hosted \ Text/SMS service from HA. Given HA runs on my NAS IF I fee the need to harder the service to withstand loss of power, I have long considered tieing ancient Rack mounted UPS to the NAS, and though I have no intention to do it, I COULD potentially augmenting my Fiber network connection with a trivial text only plan and connect a USB cellular device to the NAS and effectively replicate 95% of what it seems Virtualalam does without a subscription service (cellar link not withstanding).

All that said, there is CLEARLY a place for a turnkey solution that provide value to some who will happily contract for a monitoring solution. As I have said many a time the goal is OFFER choices not to FORCE the user’s choice… :wink: And hopefully offer a greater degree of transparency then what have thus far seen from YoLink (to date). Again that’s not a dig just a recognition that as a corporate entity their constituent responsibilities are very different then what an open source solution would be and there is clearly a place for both to thrive.

I agree 100%. I have lived through a nightmare with them begging them to create a home assistant integration while using IFTTT to have Yolink talk to HA which was painful and slow. I stopped buying anything Yolink but I am glad I gave them for devices I am using for leak, smoke, fire and alarm purposes. Many towns will not accept an automated call but insist on a live person calling them which is where such a24/7 service comes into play.

OMG!!! Sign me up! When can I place my order? I have quite a few YoLink devices
that I am ready to throw in the trash, as I can not get their revised API to work with my HA and support from DMatrix is not helpful.

Fortunately for me @KruseLuds has been trying to assist me. But I messed up my settings in CloudFlare and destroyed the fiber communications within the family. Why? Because I tried following the directions in the documentation.

Looks like you have the cloud: integration disabled, which prevents Nabu Casa from authenticating for you. The note about authentication is the YoLink integration docs in confusing, but what is means is that Nabu Casa will authenticate with OAuth without you having to do anything. However, if you want to authenticate by yourself, then you have to request (doesn’t say from whom) a set of credentials. Specifying application credentials generated on the YoLink app causes the error that you see.

Interesting.
Please entertain my clarifications :smile:, Are you saying I have to use and pay the Nabu Casa subscription service? It is extremely possible I missed a step in creating Home Assistant from scratch, since I have never used Nabu Casa before, I wouldn’t know what steps I was missing. Since January I have killed HA and started over about twice daily trying quite the variety of methods, steps, and anything suggested by my cries for help in the community. YoLink is extremely necessary for me, as it provides me my much needed medical communication as well as the other benefits of being the only “so called compatible” devices I know that use Lora (?) for distance.
Thank You so much for your help. Meanwhile, I continue my mission of deleting and reinstalling HA from scratch hoping I stumble on that magical step making it operational again.

No subscription or linking of your HA instance to Nabu Casa is needed. You simply have to have the Home Assistant Cloud integration active. It is on by default if you are using the Default Config.

Also, remember to delete the application credentials that you entered manually for YoLink. In summary:

  1. Ensure that Home Assistant Cloud is active.
  2. Delete the existing application credentials for the YoLink integration.
  3. Restart HA (optional).
  4. Readd the YoLink integration.

FYI- The hub is available again. I posted with links to teardowns done by Austinc3030… I’ll repeat 2 comment I made there… See link for further details

  1. Unfortunately it does not appear that device includes a speaker
  2. Just because they reference local only after enrollment does not NECESSARILY mean OPEN ACCESS when local only…

Purchased one myself for experimentation.

The Product page has also been updated to include a description and calls out Matter compatibility but DOSEN’T say IF its is a “future” software update. So since it’s ADVERTISED and offered for sale as including matter compatibility it legal SHOULD have it out of the box/at customer intro…

Matter Compatibility: Effortlessly integrates with third-party platforms using Matter, enabling seamless interaction with a wide range of smart home devices from various manufacturers, fostering a truly integrated smart home ecosystem.

1 Like

I see that just they were posted again today. LoRa, fully local control open to third parties, Matter, 4G and battery backup sounds a lot like too good to be true. Otherwise I’d get one at this very moment.

FYI- No assumption you are in the US but here are details on FCC regulations and 911

It is too good to believe as that’s not what they technically said in their product page.

I’ll try it another way… Since they need a Hub online for enrollment they can still POTENTIALLY break/brick/change what functionality you get from the products you PREVIOUSLY purchased in the future since encryption keys will be exchanged between end nodes and the cloud (perhaps these are cached locally on Hub 3).

They COULD (and would likely require) that you have hub online for updates or upload new firmware from your phone if you connect it to the hub (got to update right?)… Also one might reasonably expect that encryption keys DO expire right? So the minute you have to renew keys on end devices (sensors) you open the potential for obsolescence or functional compromise IF the company exits the market/gets purchased/or changes management/biz models (turns to subscription plan)/decides it wants to "encourage users to move to other “plans” offered (ie monitoring, etc)… So you can’t put your hub & sensors in a “deep freeze” air gaped from the public internet and expect will continue too work without YoLinks continued support…

As long as we don’t have native API access to the hub, and the ability to update/any security keys/encryption keys we would STILL be operating at the graces/good will of the company…

NOT that this isn’t positive step I the right direction! Just not a silver bullit/Holy Grail you might have been lead to believe it might be… You are rightly cautious :slight_smile:

Regarding Matter support:
After reading the CURRENTLY posted support Product Support/Install documents (dated Dec 2023) there is NO reference to Matter (the only reference is in the product summary)…

SO if Matter IS supported, it will likely come via a future update as I suggested earlier…

Correspondingly, I would assume that any kind of offline functionality that we care about (ie off-cloud mode WITH direct integration to HomeAssistance) is yet ANOTHER FUTURE firmware update beyond the above update (that I would postulate is to be releases AFTER getting Matter released). This makes sense as they very well could build-on/rely-on/claim-that providing Matter support/compliment fulfills the functional requirement of being local only as Matter does also for Link-Local addressing…

1 Like

Maybe they just updated the product page a few hours ago because I haven’t seen anyone mention this. There is a FAQ at the bottom and one of the questions addresses local control.

Q: Does the YoLink Hub 3 Support Local Integration?

A: As of April 2024, the YoLink Hub 3 does not support local integration. It is planned to be completed by end of year along with matter compatibility and once completed, will be through a software update by the Hub 3.

I guess that means local control by way of updating the Hub 3 to be a Matter Bridge. Well it’s not a forum or reddit post, they put it on their product page this time. I hope that actually means this will happen this time. But the plan is to release it by the end of the year and it’s April right now :unamused:

1 Like

Yep. I saw that as well. I was about to purchase, but I’m not going down the vaporware line.

1 Like

Thank you for this, good to know!

1 Like

In reference to @Rice_Eater and just to again be clear…

Unfortunately Local Control ≠ Open Source / Open Protocols or even rootable… witness Tyua’s games they play.

So long as payloads are encrypted, and we DO NOT have access to those keys, which MUST be renewed-- you are STILL at the mercy/good graces of whatever local access YoLink chooses to offer and that can be withdrawn ANY time those keys needed to be changed, or new devices enrolled (their literature for “local control” does mention needing to be online for enrollment so I think I am not far off here on what local control will actually look like)…

We MAY be able to keep our traffic off their servers (also helping to save them some money on AWS services), but these are NOT the local only devices WE are looking for. At a minimum THIS is what we want (in case anyone from YoLink is still scanning this forum) from the software update to Hub 3. This particular example is the RAK7268v2. It supports connecting to a remote network like the TTN network as well as offering a full ChirpStack with an embedded MQTT Broker functionality so it can function COMPLETELY off network if you choose. All keys then are managed locally (though you can of course bind to a cloud based IoT provider (TTN, AWS etc) IF you chose. It is FULLY independent of RAK (should the go out of biz). There are others companies as well. This is baseline for what we mean by “offline” functionality. I can enroll sensors (and of course monitor sensors) WITHOUT network ANY cloud connection…

But again until delivered, actually know what will be delivered, my comments are simply based upon the industry track record as a whole, and what business models make sense over my past 30 years in it…

I will try my new Hub 3 (which arrives later today), and set up a small Yolink testbed with a couple sensors (door/vibration/alarm horn), and test if oner can indeed have control-d2d active & Alarmo integration via HA with HA enabling/disabling censored in the D2D alarm group(condition or whatever its called). To those experts here, have others tried this before? Any success? Is this reasonable/possible?

In addition I will start work a month or two from now, sourcing components to build an open source based system design using LoRa/LoRaWAN and potentially even Semtech chipsets, as I discussed in this thread. As I stated, I expect this will be more costly, as it doesn’t have the economy of scale in the production side that YoLink and other commercial vendors have. It COULD however leverage an economy of scale on the SOFTWARE side by using and making the sofware (as well as reference design), free, open source so at least the software platform and IP will/can move much faster and more transparently Yosmart/Tuya etc while eliminating the vendor lock-in/control that we currently have to contend with. Again there is a place for off the shelf integration that REQUIRES no HA server, no Engineering background, where assembly is NOT required and batteries ARE included, and things are bulletproof because they are vertically integrated. I am VERY familiar with that market having worked on and playing a significant part in one of those markets yeas ago. It’s a place YoLink can thrive. My goal is to offer help drive that ecosystem forward by offering an alternative showcase of what IS possible when you let the ingenuity of a community propel the platform forward, something I have been fortunate enough to have participated in several times in my career.

You buy/build a device, YOU choose what you want to do with it, YOU choose who it communicates with, and YOU choose how long it functions. This SHOULD be the baseline for ALL IoT devices, and I dare say that what we need is one of these new “Nutrition Labels” " to be added to NIST’s current IoT Labeling Program… However this is a thread for discussion elsewhere and is of course US-centric, though conceptually applicable elsewhere. I apologize for this last paragraph as it is somewhat off topic. Any further discussion/details/designs and links for the open platform I discussed, will take place on GitHub (unless someone can suggest a more appropriate location). Link to be posted in a couple months

I’d like to return discussion here BACK to the topic of Yolink-HA integration, and perhaps any thoughts people have on the viability of using the currently available YoLink products to build a hybrid Control-D2D / HomeAssistant deployment? It seems like a more appropriate and constructive topic here that I assume others have thought about it if not attempted?

2 Likes

I am the one who ordered and released the teardown of hub3 as linked in a previous post. I have not added that teardown to my other documentation but this is the repo with most of my research into yolink hubs, sensors, and cloud. GitHub - dynacylabs/yolink_re

Including links to ghidra tools for esp32, firmware dumps from hubs and sensors, documentation of debug pins and communication protocols.

The hub (smaller non-speaker hub, larger non-speaker hub, and speaker hub, not sure on hub3) already communicates with an MQTT server and I have successfully compromised the hubs to point to a local MQTT server AFTER activation with yolink’s services. Also, I would recommend using one of the first 3 hubs (again, not hub3) as a basis for your gateway. It is based on esp32 and an LLCC68/Semtech SX12XX chip, both of which have extensive libraries available on github.

This project has been on hold as of late for me as I’ve pretty much narrowed it down to only one path forward, which involves compromising the encryption keys.

It appears that YoLink’s cloud is running an MQTT server which the hub talks to, i.e. Sensor <—lora—> Hub <—internet—> cloud. MQTT appears to just be the message service as I found evidence to suggest YoLink is already using chirpstack to handle the lora stuff (encryption keys namely). The data between the sensor and the cloud is encrypted, meaning the hub does not encrypt/decrypt anything. However, there must be an initial key (likely the same across sensors) that is used for initial configuration/exchange of keys during enrollment. This key must live inside the YoLink YL09 silicon. I have dumped the flash of a few sensors and was unable to find any keys in the dump. I do not have RE experience with ARM. so have stopped my research to pursue other projects at this time. The sensors (YL09 chip) appears to be an STM32L73-Z (or something similar, I don’t recall the exact part number) tied to a semtech SX1272 (again, may not be exactly the correct PN, check the repo in this post for exact numbers).

None of their stuff appears to be bootloader/flash locked. I was able to successfully flash the hubs with basic firmware just to determine if they would run a custom image. It wouldn’t be difficult to write your own firmware for the hub, write your own firmware for the YL09 chip, and build your own open ecosystem using their stuff off the shelf with custom stuff.

Flashing the YL09 chip might be difficult on most sensors. While I have not personally bought and torn down every sensor they offer, I have reviewed every set of images of all their sensors on FCCID and only found 3 with exposed pins that are connected to the correct pins to allow flashing the YL09 chip. If I recall correctly, this would be the temp/humidity sensor (non X3, non outdoor), the the inwall switch, and i forget the third one.

Many (almost all) of their sensors have exposed debug pins BUT not all of them map to the correct pins on the YL09. My guess is the YL09 is flashed prior to being put on the PCB.

The HUB 3 appears to be running something like an openwrt system based on it’s serial output. Support for the chip PN also appears to be supported by openwrt, further supporting this theory. The chip on the hub3 is much more powerful than the esp32 in the other hubs. I fully expect this chip to be capable of handling local control (Device to device coms via hub (not D2D), local mqtt supprt, scenes (or whatever yolink calls it), etc.).

4 Likes

In the last week or so anyone else’s motion and door sensors quit reporting to HA? Temp sensors still report. 2024.4.3 and 2024.4.4