YoLink Integration

[Michael McSharry]

I have added integration of YoLink devices to HS with mcsMQTT plugin. I have made attempts to get engineering information about the YoLink hub in hopes of providing local integration, but it is clear now that YoLink is not interested in supporting this. What I have done is used their published API for integration via the cloud. Responsiveness is excellent, but does depend upon the internet.

There are two sets of information available from a YoLink device. One is the "response" that describes the device characteristics. The other is the "report" which occurs with a change of status. The only information that anybody would like to use is the status to map into a HS device. The other pieces of information may be of interest, but not needed for HS events etc.





mcsMQTT will report on the Topic starting with YoLink/deviceId where deviceId is the identification being reported by the YoLink device.

At this time I have not attempted control of the YoLink devices. I believe it can be done, but this is a good first step for the things one would actually use YoLink in favor of other technologies. I do not have any YoLink output devices so this would require that I obtain one that could have potential use. Things like thermostats would not fit this category as I would never want to depend upon my internet for this purpose.

The user is responsible to identify a YoLink device with its 32 character QR code. A smartphone QR scanner can provide this. It is entered on the first tab of the TCP page. YoLink and IPRelay share the same tab as a matter of space conservation.



The plugin is now at version 5.17.0.0 with changed files at:
HS3: http://mcsSprinklers.com/MCSMQTT_51700.zip
HS4: http://mcsSprinklers.com/MCSMQTTHS4_51700.zip

If there is interest I can explore adding the ability to control YoLink plugs and other devices in the family.

I have requested information about the LoRa characteristics beyond the 923.3 MHz frequency. With or without it I will attempt to see if I can receive and decode the communication between the sensor and the hub using a ESP32/LoRa. If they did a good engineering job this should be difficult and I will abandon. If they were not concerned with hacks the I may be able to replace the hub with a ESP32/LoRa and eliminate the cloud.

[upstatemike]

I could see value in controlling Yolink plug-in modules... especially outdoor ones where the LoRa signal might be very useful to reach a remote corner of your property. I also use the Garage door controller because it works very well with Alexa but that is a lower priority since it is easy enough to control a garage door via dry contact using any number of connections back to Homeseer.

[jhopple]

Just ordered a hub and door sensor to experiment with. I like the range, supposed battery life and low cost of these devices. I will check out the plugin when they arrive.

Thanks for your efforts, they are appreciated!

[Michael McSharry]

As matter of comparative interest I have a WiFi connection at 600 ft through heavy woods using Ubiquiti Nanostation, a 433 MHz LoRa serial terminal, and a YoLink Door/Window senosr at the same location. In all cases if I place the receivers on the second story of the house so that a line-of-sight can be achieved the communications are successful. If I have the receiving locations on the first floor I loose communications. It appears that line of sight is needed for successful communication for both WiFi/5 GHz and LoRa 433 MHz and 933 MHz. Theory states that lower frequencies will do better at navigating the forest. I don't see much difference in this use case for frequency, but lack of blocking terrain was important.

[jim@beersman.com]

I'm currently running mcsMQTT 5.16.2.1. Do I just need to replace just the .dll and .pdb or do I need a full upgrade for the plugin? Do I need to apply to Yolink to get access to the API or is only the Yolink QR code required?

[Michael McSharry]

You only need the files in the zip. For HS4 it also has TCP.html that goes in the \html\mcsMQTT folder. The others go in \bin\mcsMQTT. HS will still show 5.16.2.1, but it will be obvious that you have the update when viewing the TCP Page.

All that is needed is the QR code. You first need to bind the sensor you want to integrate to your YoLink hub using their App. This then makes the sensor status available on their cloud server from which mcsMQTT will receive notifications as the state changes.

[jim@beersman.com]

Michael, you are the BEST!!!

Hardest part was keying in the 32 character QR code correctly.

[jim@beersman.com]

Michael, I found what I think is a bug but it could be a feature. If you change the Device Name in Homeseer it breaks the link to the Device.

Not sure if you are not allowed to change the Device Name that is displayed in Homseer or not. I much prefer seeing Mailbox as apposed to report:data:state

[Michael McSharry]

This should not be the case as the plugin only uses the Ref to identify the association. In the Association tab do you see the status updated for item, but the HS device is not being updated?

[jim@beersman.com]

My HS3 devices are updating after the name change, the HS4 devices are not. I'm going to delete them and start fresh only changing one name to see if this is really an issue.

[jim@beersman.com]

It appears that something, possible YoLink, does not like me having your PI running on both HS3 and HS4 at the same time. It will update one but not the other. So which ever one I start last gets the messages from YoLink

[Michael McSharry]

I can give it a try with a couple HS instances running. I can also contact YoLink to see if there are any limits to subscriptions to a device.

... update I tried with two instances and got the same result where only the last subscription to their server was sent updates. I will contact them, but don't expect response over the weekend.

[jim@beersman.com]

Glad to know I'm not crazy

[Michael McSharry]

I integrated the YoLink Outlet. This should apply to the three versions of the outlet that YoLink sells. Update is at
HS3: http://mcsSprinklers.com/MCSMQTT_51720.zip
HS4: http://mcsSprinklers.com/MCSMQTTHS4_51720.zip

No need to update from prior version unless you have an outlet.

During integration I observed that the event message was delivered if the YoLink App changed the state of the Outlet or if it was changed by the local button. If command to change via HS then no event was observed. I will report this to YoLink, but first want to deal with the more important issue about multiple clients and don't want to distract them. To overcome this deficiency both the response and report topics need to be mapped into the same HS device as shown below. "A" associate one of the two and then enter the Ref number in the Ref text box for the second. The lasts one reporting will be reflected in the HS device.

The nomenclature that YoLink uses if Open/Close where Open is the On state and Close is the Off state. An interesting decision for a power plug. Could be China translation for the developer.

I do not expect to integrate other output devices unless a specific user need exists. It is easy to do, but no point unless somebody needs it.

I also observed with regularity a response of "Can't connect to device as shown in the "desc" JSON key shown below. I have a poor internet connection. This reflects one of the problems with depending upon a cloud server for control of local devices. Currently mcsMQTT has no monitor/retry logic for YoLink. First step is to get YoLink to report events when controlled from HS and a unified monitoring strategy can then be developed to deal with cloud operations.

[Michael McSharry]

I did get a response from YoLink about multiple clients and I can make it work even though there are some issues with the API implementation on the YoSmart side. I followed up pointing these issues out and presented the other problem with a lack of event reporting when the Outlet is changed via the API. I will wait for additional response before posting an update. The API is relatively new. I suspect there has been very few that have tried to use it so there are some growing pains that are not realized until real-world use cases have been applied to vet things out.