YoLink Integration

[jim@beersman.com]

Thanks for the update

[Michael McSharry]

The updates are at:
HS3: http://mcsSprinklers.com/MCSMQTT_51730.zip
HS4: http://mcsSprinklers.com/MCSMQTTHS4_51730.zip

My communications with YoLink get a response when my request has an easy answer, but when presenting problems or issues with the API then I get no response. I have no idea of the issue tracking mechanism that is employed or if changes to the API will being made.

What I have done is used what exists today in the YoLink server based upon empirical evidence. This may change in the future if the issues I raised are addressed.

I applied as a partner to YoLink at service@yosmart.com from which they sent an Excel spreadsheet where I filled in my information and they returned credentials with which I could access the YoLink server for purpose of integrating my product with theirs. This was done in Dec 2020.

With the prior versions of the YoLink integration via mcsMQTT I provided the UI to the user to identify their YoLink devices and the plugin would use the partner access information to the YoLink server to perform the integration. This capability continues to be available.

With version 5.17.3.0 of the plugin I gave the user the option to apply for their personal YoLink account and then the plugin would use this access information rather than using the access provided by my partner credentials.

Also in this version an option was provided to have a single instance or multiple instance of mcsMQTT accessing the YoLink cloud server. The reason for this is similar to the reason for the change made in the prior paragraph.

For any given account the YoLink server associates a QR code to the account. This means that anybody using the account will potentially have access to the all devices that have been associated with that account. I had expected YoLink to restrict access of a YoLink device to only the client that had made the association of the device to the account. Since this was not done I performed the management within the plugin. This means that the plugin will provide visibility to only those YoLink devices for which the user has entered the QR code. It does mean that the information is transmitted by YoLink server to mcsMQTT so if somebody wanted to use Wireshark or other network snooping tools they would be able to see the state of the YoLink device of everybody who has used the same account for YoLink server access.

This become a potential security issue for the case where there are multiple instances of mcsMQTT reporting on the same YoLink device. The server will send a status change to all client using the account. This will not be visible to the mcsMQTT user, but for a hacker they could gain access to the state of all users devices. This still does not give the hacker information that allows a device to be controlled such as an outlet, nor information about login credentials to the YoLink server to do the next level of mischief.

If a user does not have a need for multiple mcsMQTT instances with access to the same YoLink device then the setting provided for single instance will allow mcsMQTT to restrict the communications so that hacking would only have access to the one user's devices rather than all users devices.

The next level of protection provided is to use a personal set of credentials for access to the YoLink server. This requires another step with application with YoLink and their approval to gain access to their server. I believe their intent is to provide this to partners and not end users, but the API architecture they have setup is somewhat lacking is security for partner accounts as described above.

[jim@beersman.com]

Over on the Home Assistant forum back on July 8 someone posted a response they received from Yolink
"Our official Home Assistant plug-in is under development, which does not require users to apply for additional API keys.

We also had suspended the API key application channel for individual end-users. Later, end-users can directly manage their sec key and authorizations in the YoLink app.

Any questions, please feel free to contact me!

Best Regards

Chi Yao"

So I'm not sure if I can get an API key, but I did fill out the spreadsheet that I had received a couple weeks ago and sent it in. Will see if I get a response

[Michael McSharry]

I got a response about my report of issues and privacy concerns and did get a response this morning:

You should use the unified agent to exchange data with the yolink server, and then provide data services for your end client, rather than allowing your end client to directly access the yolink server. That's not our design goal.

Thanks and best regards
Chi Yao

In essence they are expecting each partner with access to the YoLink server to setup their own server in the cloud. This second cloud server then has responsibly to protect information that is made available on the end user's network. I am not going to do this with mcsMQTT. I am just going to be forthcoming about the privacy consideration for those who run multiple instances of HS that want access to YoLink devices managed through mcsMQTT.

[jim@beersman.com]

Thanks for the update. I would say I can't believe their security model is so lacking but I'm not surprised. Just another reason to stay away from Cloud Vendors products.

[Michael McSharry]

My last communication with YoLink is

The permission issue is not a problem for the application. While the YoLink broker/server is not responding as you indicated I can see what it is doing so I can accommodate.

In your other response I see you divorced YoLink from user security and expect the partner to take whatever measures they see appropriate to protect user devices. Not the best of privacy decisions for a product that is based on confidence of privacy in the cloud, but that is a business decision.

I receive many "Can't connect to device” shown in the "desc" JSON /response. While this is interesting information, it implies to me that YoLink broker/server is not honoring the MQTT QOS level 1 where an acknowledge is required before stopping attempts at delivering the message. One of the primary benefit of MQTT is the QOS that is provided and it looks as if YoLink broker/server is not honoring the QOS for message delivery.

[logbuilder]

Michael, I have had mcsMQTT as an installed plugin for over a year but have not actually used it. Yolink devices were recently installed mainly for the freezer temp sensor. They work well. However, integration into HS3 would be nice in terms of more robust alerting and actions when they trigger.

I have added the 32 character ID of the devices and in the association table I can see some messages being received from the yolink server. So far so good! Now, how do I get a HS device to show the temp? I can see the payload on the associations tab and can see the "temperature":-16.7 within the payload. The -16.7 is the celsius value which is 2.4 fahrenheit. Is there a way to convert to F?

Thanks.
Robert

P.S. Lots of smoke up here in Darrington. Hopefully not so much in NB. The red sun is interesting though.

[jim@beersman.com]

In mcsMQTT in the Plugin select MQTT, find the device and click on the Ref Number which should open what I call the Edit/Setup box. Go to expression and enter the formula ROUND(($$PAYLOAD: * 1.8) + 32,1). I believe that is the correct conversion formula

[logbuilder]

This is the payload of the only reference # that seems to contain the temp.

{"event":"THSensor.Report","time":1628964551237,"msgid":"162 8964551236","data":{"state":"normal","alarm":{"lowBattery":f alse,"lowTemp":false,"highTemp":false,"lowHumidity":false,"h ighHumidity":false,"period":false,"code":0},"battery":4,"mod e":"f","interval":0,"temperature":-17.8,"humidity":51,"tempLimit":{"max":-4.2,"min":-22.2},"humidityLimit":{"max":100,"min":0},"tempCorrection":0 ,"humidityCorrection":0,"version":"0362","loraInfo":{"signal ":-87,"gatewayId":"xxxxxxxxxxxxxxxx","gateways":1}},"deviceId": "xxxxxxxxxxxxxxxx"}

How do I get that into a HS3 device that I can use as a trigger in an event? Jim's conversion formula looks like it will work on a payload that contains one value to be converted.

I also see a field called "battery" which I hope has the battery level. Anybody know what the scale is for yolink devices?

These are probably basic questions so I appreciate your patience.

P.S. The yolink temp sensors work really well while inside my upright freezer as well as my refrigerator.

[jim@beersman.com]

On the General tab of the mcsMQTT PI do you have "Decode JSON into separate HS Devices" checked?

[jim@beersman.com]

Also a Battery Level of 4 = 100%. Or at least they do on my devices (Contact Closure)

[logbuilder]

On the General tab of the mcsMQTT PI do you have "Decode JSON into separate HS Devices" checked?

Yes, it is checked. Do I need to be in express mode for that to work?

[jim@beersman.com]

Here are my settings

[logbuilder]

OK, I just discovered that there are many associations if you page forward (duh).

[Michael McSharry]

I setup a LoRa receiver to see what the local widget to YoLink Hub was receiving. My hardware has antennae filters and length optimized for 868 MHz, so the 928 MHz YoLink frequency is not optimal, but with the devices sufficiently close I was able to see the traffic. YoLink advertised this is an encrypted communicaiton. In my test case of an outlet changing state it was a 41 byte packet, but with the encryption it would take much work to reverse engineer. It is not worth my effort so I will not continue to attempt direct YoLink Widget connection and continue to use the Cloud API for integration with HS. If YoLink ever changes to allow direct access this can be revisited, but considering their current position and their statement about the security of the communications I doubt if there will be any change in ability to have direct access to the YoLink widget.