YoLink - Products

[Eric-YoLink]

Eric,

Just looked at the keyfobs on Amazon. They look great! Are they documented in the existing API so that Michael can integrate them and make them available to HS users?

Thanks,
Robert

yes!

[Michael McSharry]

What type is it? Is it a finger? A switch? Other?

[Eric-YoLink]

What type is it? Is it a finger? A switch? Other?

A switch, I think. To Alexa it's four motion sensors.

[rmasonjr]

These devices look absolutely great! So, are these going to require a local hub? When controlling a device, will the command be 'local
or will it go out through the cloud and back?

[Eric-YoLink]

Cloud, using AWS servers, very reliable and fast. We do have the ability to pair devices so they work independently (without the cloud), it's patented and we call it Control D2D. Naturally, I should not be too salesy in here. I was originally a customer and was also impressed right away, particularly with the customer service. Message me for more info. We have a Facebook page, Discord API/Developer and Power User groups and YouTube channel, all pretty active and a great way to stay connected to all things YoLink and to get the most out of your system.

[Michael McSharry]

Cloud, using AWS servers, very reliable and fast.

The speed and reliability are not a function of AWS, but the ISP that is getting the client to AWS. In my case I cannot typically upload a file to a AWS server that is over 1 MB without multiple tries. When the connection is hit and miss the chances that a YoLink event will actually get through a bidirectional path to and from the cloud is also hit and miss. There are also cases where outages occur. One does not want to have anything important depend upon things that are outside one's control. It is fine for the fluffy stuff, but not for anything one depends upon.

it's patented and we call it Control D2D

Device to Device technology has been around a long time. That is the basis of a distributed architecture. Going the direction of patenting some niche application of a distributed architecture is an indication that YoLink is moving away from the industry trends of more open and interoperable devices and toward something that tries to lock the customer into the YoLink ecosystem. What the general HA community is looking for is DeviceX to DeviceY communications where X and Y do not need to be proprietary YoLink products.

[jim@beersman.com]

I agree with everything Michael said.

Control D2D is a proprietary Yolink communication method that only works with other Yolink products. Yolink can't communicate with other vendors products locally because that does not appear to be important to them. However to many HomeSeer users (and other HA systems) this is a VERY important feature.

I need my Brand X prod to talk with Brand Y without going to the Internet. This is why many people across all the Social Media sites that Yolink likes to say they are a part of, keeps asking for local MQTT. Unfortunately the users request has been ignored to this point.

Without local communication, if my Internet connection is lost or Yolink were to go out of business all my Yolink products simply become doorstops.

[upstatemike]

The speed and reliability are not a function of AWS, but the ISP that is getting the client to AWS. In my case I cannot typically upload a file to a AWS server that is over 1 MB without multiple tries. When the connection is hit and miss the chances that a YoLink event will actually get through a bidirectional path to and from the cloud is also hit and miss. There are also cases where outages occur. One does not want to have anything important depend upon things that are outside one's control. It is fine for the fluffy stuff, but not for anything one depends upon.

I agree local is better and I am glad there is a commitment by Yolink to provide a piece of hardware to enable all local control sometime in 2022. That said I am using Yolink to update Homeseer virtual devices via Alexa routines and I can't distinguish the response time from that of local Z-Wave stuff. I am comfortable using Yolink this way for now knowing the local solution is coming.

Device to Device technology has been around a long time. That is the basis of a distributed architecture. Going the direction of patenting some niche application of a distributed architecture is an indication that YoLink is moving away from the industry trends of more open and interoperable devices and toward something that tries to lock the customer into the YoLink ecosystem. What the general HA community is looking for is DeviceX to DeviceY communications where X and Y do not need to be proprietary YoLink products.

The patented D2D technology is what provides local associations within the LoRa protocol. As far as I know no other LoRa manufacturer is providing a local association option. It is used to provide functionality that does not exist in a standardized way that can be interoperable across different LoRa manufacturers. I don't think there is any authority managing LoRa to create and enforce standards that would ensure the kind of interoperability you are looking for is there? Some kind of LoRa Alliance or something?

[Michael McSharry]

Eric will need to provide the details, but I see nothing in this thread that indicates any local control in 2022. I just see that Home Assistant will have a similar capability that HS now has with mcsMQTT. It will just be using the HA account into YoSmart server rather than the mcsMQTT account. To get local control one needs to either have another LoRa hub at 928 MHz that brokers the undisclosed communications with YoLink devices or YoLink needs to update their hub so that a local server is used rather than the YoSmart server.

The point being made with D2D is that YoLink is providing a means for interoperability for YoLink devices and getting a patent so other manufacturers will not be able to connect their LoRa device to a YoLink LoRa device as well as allow other manufactures to use the technique covered by the patent. LoRa, like Z-Ware, is a proprietary technology. It uses spread spectrum and provides a means to tradeoff speed vs. distance. What is being communicated is not part of LoRa. Just like what is communicated over the internet is not part of the internet, albeit communication standards do exist at high levels of the ISO model. If one wants to look at communication standards for LoRa then look into The Things Network.

[rmasonjr]

So, reading back through this some more, here are some thoughts:

HST recently started supporting Tuya devices "locally" by communicating directly and so far, it has been great. I have 5 of the devices and they all work fast and "locally".
Ideally, if HST could do the same thing with the Yolink devices, via the Yolink hub, it would be very close to how they support Tuya.

Eric-YoLink you should reconsider opening up the hub with some simple JSON or other API for "local" interaction instead of through the cloud.

Again, those products look great - I hope they can make them more widely available to us!

[alexbk66]

For anybody interested I created AKYoLink plugin https://forums.homeseer.com/forum/de...orawan-devices