I Updated the installation documentation. It appears that you need to use a Tag instead of a Keyword if you haven't previously scanned the repositories.
1 Like
Support for the following device has been added:
LeakSensor (YS7903-UC)
Use the HPM Update feature and you should see the update for YoLink Device Service version 1.0.2. This will download the new driver. Then run the "YoLink™ Device Service" app again to create the devices.
2 Likes
Support for Leak Sensor (YS7903-UC) has been added.
2 Likes
Me neither. I have a couple applications for their devices, and I can't get over the lack of local integration. They are losing a few sales from me, and probably others, by not having an open API.
No, it just made me laugh, thinking we might be thought of similar to Darth Vader saying "come to the dark side" or something like that. A proprietary product is not inherently evil or deceptive. Would it be reasonable to get mad at GM because you can't take your Chevy to a Ford dealer for parts and warranty service? I don't think we're much different than a typical car brand - unique and with some proprietary aspects.
But my main point is we are not tricking anyone or pushing them into our walled garden. Our products sell themselves on their own merits. For one thing, we do have a fairly unique product, and our wireless technology is in some ways even superior to the nearest equivalent, LoRaWAN. It would be one thing if we went out of our way to make a WiFi-based sensor proprietary, but it's a very different animal, already. And, had we chosen to be just a sensor manufacturer, I think we'd be a very different company, disconnected from the end-user, chasing the next order for 100,000 units, products commoditized and end-user customers marginalized. But instead, we are about providing a service and an ecosystem of products, where end-user customer feedback and purchasing trends determine our next products, and those products lead to new customers, and so on. Like GM or Ford, I guess.
We are going to make an offline hub with local control, but it's for a relatively niche market segment (most people don’t want to roll-their-own smart home). The current business model is for the most part the norm and I think it is a mutually-beneficial one for us and our customers. Oh, it’s worth pointing out we will be producing dual-network devices that work on Helium as well as our network. That’s not “walled garden” at all.
I was not laughing at anyone, I almost posted a GIF of Vader, actually; I was just amused by YoLink being characterized as tricking anyone into getting into a negative company/customer relationship. It's not like that.
6 Likes
To be fair to everyone, I don’t think that anyone is “mad” at YoLink (which I agree would be unreasonable) , just disappointed that Yoink’s great sensors cannot be used with Hubitat without relying on the YoLink Cloud. The obvious reason for this disappointment is that the YoLink Hub is much, much, much less capable than Hubitat and (of course) is not compatible with local control with Hubitat.
Now, to be fair to Eric, I think he explained very well (and fairly) his company’s approach and as I have stated, has always been quite responsive and helpful whenever I have interacted with him. YoLink can obviously use any business model they wish and that is (of course) completely their choice and right.
It is admittedly easy to misinterpret intentions with text, so just like some innocent jokes or quotes in these times of hyper-wokeness, it is easy to ascribe evil intent when not there. I suppose everyone just needs to just take a deep breath and IMHO, should give everyone the benefit of the doubt until proven otherwise, 
myself included.
BTW, what would make a lot of people “happy” if not ecstatic, would be if the YoLink local hub in development could be interfaced with Hubitat via telnet like the Lutron hubs, Hint Hint!
2 Likes
It's the modem fight over who owns the product. By forcing an always on connection to the cloud it is signaling that you are paying for the use of the product, not the product itself. While I love what YoLink is doing in there hardware I am not a fan of this model. Those is becoming far to common and honestly it needs to stop. It limits the consumer while encouraging an ever ending cycle of re buying devices.
3 Likes
@SteveBarcus My Power strips are not showing up in the device list? I have updated to version 1.02 and then I when back and updated the app and the strips show up in the list and I check the box and process and nothing? Is there something else that I can try? Thanks for all you do. All my other devices has been included.
Did you check your Hubitat log for any errors from the "YoLink Device Service"?
Everyone, please refrain from discussing the pros and cons of YoLink devices and their business model in this thread. I wrote the app and drivers for those who want to use YoLink devices for whatever reason - period. If you want to get into a pissing contest over their business model and their devices, please start your own thread. Thanks.
8 Likes
Hey @SteveBarcus, sorry, I agree with you and I apologize as I was just responding to YoLink’s comments in YOUR thread. It does seem that every YoLink thread I have come across tends to end up in this way one way or another. All that aside, great job on your app. It is greatly appreciated! Thanks for all your work.
2 Likes
Okay, so I have to admit I'm a newbie writing for this platform and using the Hubitat Package Manager (HPM). I was a mainframe programmer for 40 years, so this is all new to me - and the available development documentation for Hubitat and YoLink is mostly incomplete, error ridden, or just plain out of date. That's my story, and I'm sticking to it.
Having said that, it appears I screwed things up deploying the application via HPM. The folllowing directions only apply to anyone that has installed the app and drivers on or before today (7/17/2022):
- Go into HPM and click on "View Apps and Drivers".
- These are the current app and drivers that should be shown:
- YoLink™ Device Service v1.0.1 (app)
- YoLink COSmokeSensor Device v1.0.1 (driver)
- YoLink DoorSensor Device v1.0.1 (driver)
- YoLink Hub Device v1.0.1 (driver)
- YoLink LeakSensor Device v1.0.0 (driver)
- YoLink Manipulator Device v1.0.1 (driver)
- YoLink MotionSensor Device v1.0.1 (driver)
- YoLink MultiOutlet Device v1.0.0 (driver)
- YoLink Outlet Device v1.0.3 (driver)
- YoLink Siren Device v1.0.0 (driver)
- YoLink SmartRemoter Device v1.0.1 (driver)
- YoLink SpeakerHub Device v1.0.1 (driver)
- YoLink Switch Device v1.0.1 (driver)
- YoLink THSensor Device v1.0.3 (driver)
- YoLink Temperature Sensor Device v1.0.3 (driver)
- If any are incorrect, you need to use the HPM "Repair" function to repair "YoLink Device Service"
- If the app and driver versions are correct and your temperature/humidity sensors are not working, you'll have to go back into the "YoLink Device Service" app, unselect the device to uninstall it, and go back in again and select it to reinstall it. There was a bug where those devices were not being initialized correctly.
Thanks - and sorry.
1 Like
@SteveBarcus I when back in and look at the log and seen an error message that the driver for the MultiOutlet was not install and that I needed to add it. It is now working.
I really want to thank you for all you do. I do like the Yolink devices. Thanks again.
2 Likes
You're welcome.
1 Like
Rather than clutter up @SteveBarcus’s thread about his Yolink drivers, I created a new thread here, please consider posting your question in that thread and deleting your post in this one.
3 Likes
@SteveBarcus just to make you aware. I'm using some Yolink sensors in node red and get the following error message but the contact and motion sensors that I'm using are unaffected by the way I use them and I'm not using the temperature for anything. Just wanted you to be aware. Thanks for the Yolink integration.
1 Like
OK! Yesterday I installed the API driver and the drivers for the THSensor and Door Switch that I have (plus all the other device drivers just for good measure) and was able do to successfully replace my kludged-up YoLink IFTTT bridge code and some proxy virtual devices with direct Hubitat connections through the API to the actual YoLink devices themselves, yay! My previously obtained UAID and secret key worked just fine without my having to renew them with YoLink.
Currently I have the polling interval set by the YoLink API app to 1 minute so that I could easily test changing inputs to the sensors without waiting around too long. (Is it safe to re-run the YoLink API app anytime I need to change the polling interval? I was concerned that running it again might create duplicate devices.)
The Door Sensor (which I use in our mailbox to indicate mail arrival) worked great right off the bat. In fact the mailman arrived just as I had finished installing it and I got the notification exactly as I expected.
The THSensor I have had a few issues with. To begin with, after the initial installation I was not getting automatic polling to track changes in temperature. If I manually clicked the Poll button on the THSensor driver's page then it would update immediately; if not there were no live updates.
When I looked at the THSensor device log with (with Debug logging disabled in the YoLink API Device settings) I could see that the THSensor driver was throwing Groovy errors anywhere there was the assignment of devstate = object.data.state.state, ie on lines 276 and 342:
(There is also a similar assignment at line 199 but that assignment either does not fail or is never executed.)
When I replaced those lines at 276 and 342 with the assignments devstate = "normal" and devstate = "alarm", respectively, the runtime system stopped throwing errors. And when the errors stopped, the timed THSensor polling then began working correctly.
Very curiously, the devstate assignments did not fail when Debug logging was enabled in the YoLink API Device settings. But of course then my log was filling up with a huge amount of benign debug status data. I could not see anywhere in the driver code that Debug logging could possibly be affecting actual driver execution semantics.
So anyway, that's my bug report, and for the time being I will operate with my 2 one-line patches in place to get normal operation in non-Debug mode. Let us know when you are ready to entertain suggestions for feature upgrades, etc.
Thanks for the feedback. I'll return the temperature values as a string in the next release of the Service App.
You can run the service app as often as you wish. It checks to see if devices already exist and will not create duplicates. I will look into the errors. Thanks for the feedback.
1 Like
If you look at the State Variables for one of the failing temp sensors, what version of the driver is it using? Thanks.
