I would also love to see this feature. I recently bought the 9w rgbw wifi yeelights and would like to simulate a sunrise before the alarm goes off.
Here are two links that could help make this happen: http://www.yeelight.com/en_US/developer
unfortunately I don't have the sunflower or the blue version where there are APIs available, but maybe the above mentioned links could help.
Thank you so much for considering integrating this
Much time has passed, but support from inside the application is not implemented. Please tell me, is there any hope that a connection will be established between the yeelight and sleep as Android lamps?
Hello everyone. Sadly, I have to close this feature request and state that we won’t implement the integration.
We have bought a yeelight and spent quite some time trying to integrate it, but it turned out that the protocol it uses is so badly chosen that it just isn’t possible for Sleep as Android to use Yeelight.
For the technically inclined:
Yeelight uses UDP and TCP protocols. They use UDP for discovery of the bulbs and TCP for command messages.
UDP has non-guaranteed delivery, and that’s the pain point. Sometimes the discovery of your bulb can take minutes, sometimes (less often) it fails altogether and the bulb needs to be restarted physically.
Our application is time-critical (at least in terms of minutes), so we cannot use this product. Practically it would mean lots of maintenance and a raise in incoming support requests as most of the time the lights will be delayed if they work at all.
If someone differs in their opinion and wants to try it on their own, we have an open API and offer any help he might need.
You should also be able to trigger your Yeelight from Sleep as Android using IFTTT.
Long story short, it works! But not always: When I select the sleep_tracking_started, and sleep_tracking_stopped events, my Yeelight turns on as expected after I start or stop sleep tracking.
However, when using the alarm_alert_start or the alarm_alert_dismiss events, the light doesn’t turn on. Which is a bummer cause that’s the setup I would like, to have the light turn on the moment the alarm rings or, if that’s not possible, when I dismiss the alarm.
@jiri-urbandroid has there been any change in webhooks recently? Or is there something else I am missing?
I have yet to try the smart_period event, will do so tomorrow.
There hasn’t been any change in the IFTTT integration itself. But, depending on which Android version you are, there may be an issue with connectivity.
From Android P, we are unable to enable Wifi for you if you are in Airplane mode. So if you sleep with airplane mode on, we will not have connectivity to internet at the time of the alarm.
From Android Q, we are unable to control wifi completely. So if you slept with wifi off, we would again not have connectivity.
Thanks for the info! Connectivity issues are definitely not the problem, my tests are done with both phone and lamp connected to wifi, router in the same room. I just tested again, and where sleep_tracking_stopped does turn the light on, alarm_alert_start does not.
I even tried the com.urbandroid.sleep.alarmclock.ALARM_ALERT_START_AUTO event, no luck.
I’m about to test the smart_period event. This starts 45 minutes before the smart wakeup period, which means if the smart wakeup period is, say, 30 minutes before the alarm, the event would start 75 minutes before the alarm is set, correct?
Okay could you please send me a debug log (menu > report a bug)? We log all the events that we send to IFTTT so I should be able to see what’s going on.
Please let me know here after you send it and I’ll find it in our inbox.
Just to make sure I do it right, I’ll set up IFTTT for alarm_alert_start, set an alarm for 5 minutes, wait for it to ring, then send a debug log, correct?
Does that mean that the correct event for IFTTT (in my case) would be com.urbandroid.sleep.alarmclock.ALARM_ALERT_START_AUTO? In any case, this event doesn’t work either. Which could mean it’s solely an IFTTT issue.
A-ha! There’s really an issue with some of the commands.
We’ve found it thanks to you!
The issue lies in the alarm label.
We are sending the trigger to IFTTT along with a body that includes the alarm label. And we are setting the body content-length in bytes to the length of the body in characters, however there is a discrepancy between bytes and character count if you write in non-Latin script.
I’m fixing it for the next beta.
Please if you want to have it fixed right away, either don’t use labels on your alarms or use Latin alphabet on them.