-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ikea Tradfri bulbs support #5
Comments
Thanks for your investigation. I unfortunately don't have any experience with Ikea Tradfri bulbs and wasn't aware of any limitations regarding API calls directed at those bulbs. As far as I understood there are multiple issues at the moment, please correct me if I forgot something:
For the second point, there could be a potential workaround that could restore compatibility with v0.8.0, when running multiple instances. In v0.8.0 the Regarding the third point: While Hue Scheduler has an internal rate limiter that should prevent too many requests in parallel, it can't coordinate those limits across multiple instances running in parallel. You could however lower the rate limit for each instance via the Regarding the fourth point: Thank you for bringing up the manual change tracking. Looking into it I found a bug for tracking changes of states where only the brightness is set. Internally, the scheduler always compared the current color mode of the light with the color mode of the last applied state. If they differed, a manual override would be detected. To fully solve the issue with Ikea Tradfri bulbs, it would be interesting to know if this limit of "one property per request" applies to all properties i.e. |
Thank you for this quick hotfix, I can confirm it solved that brightness-only bug, even for Tradfri bulbs. That also means that basic support for Tradfri bulbs with only 1 property being scheduled is possible now again. And I've got very good news. Trafdri support is almost there =). I made a couple more observations and probably found a little bug. If that's fixed, Tradfris work well enough. Actually, It sounds like it should already work with hue scheduler. But after testing this approach with it and enabling the TRACE log I've noticed that the So if that'd be fixed sufficient Tradfri support would be available. One could add a note like this into the readme: For me that'd be sufficient enough and would save the time for implementing workarounds directly into hue scheduler that might even become obsolete at some point (If Ikea would fix the firmware). But it's up to you, just let me know. |
This is great to hear, thank you for the quick test and your further investigations into the issue. Interesting to see how this has been solved by other projects by setting the transition time to 0 -- thanks for the link! I'm also wondering why the transition time is set to a value of 3, instead of 0, if it has been explicitly set. Can you maybe share the relevant state configurations? One though that comes to mind is that And thank you for the suggested warning note, I agree that it makes sense to place this in the Readme so others are aware of this issue. I will still think if there is maybe a clean way to support this natively, but you are right, it might become at some point obsolete. |
Jippie, not setting
Adding
off-topic: fyi: The most impact for my day to day usage would be those things we already talked about but are limited by the Hue API: ideally an instant reaction time after a dumb wall switch turn on as well as the fast turn on/off recognition to clear manual changes immediately. I'll let you know when I spot further issues. Thank you very much for that great peace of software. |
I just built a little excel helper to create the schedule interpolation entries. Now I have about 800 schedule entries. The app requires >15 minutes to apply the schedules now. I am curious if it'll work stable. |
Hi @cswrd, thank you for bringing the issue of long startup times to my attention. I investigated the potential causes and managed to make some significant improvements, which are now available in the newly released v0.10.0. Feel free to check it out and let me know if it fixes the issue! To summarize: I added a cache for parsing the solar and local times, as these computations are performed frequently when Hue Scheduler tries to sort the states and calculate their respective end times during startup. |
This is a feature request to have a better support for Ikea Tradfri bulbs.
In comparison to v0.7.1 the compatibility of v0.8.0 with these bulbs got reduced. Here is why: as far as I know and based on some API tests I made to confirm that with these bulbs (LED2101G4) and the latest Firmware (1.0.003) at least these properties are different to hue bulbs:
ct
andbri
sent within 1 API request will apply onlyct
. Unfortunately, fetching the data (see below) will respond with the intended values for some seconds, even thoughbri
won't be applied.ct
andbri
have to be sent with 2 individual requests and with a little delay in-between. Otherwise the ongoing change, e.g. brightness at 254 set to 1 (which is not instantaneous) is aborted in between. A delay of 100ms seems reasonable. Or send with atransitiontime
of0
(source).As mentioned in #2 with v0.7.1 a workaround is possible: just run at least 2 hue schedulers, one responsible for brightness and another responsible for color temperature and make sure to schedule both properties at different times. Only the retry behaviour might violate number 2 but this is very unlikely.
With v0.8.0 this workaround yields to hue schedulers sending requests concurrently when a light is turned on due to the fast event mechanism. And the change from one scheduler would be interpreted by the other scheduler as a manual change, probably.
For sure another workaround would be to schedule either of these properties and never schedule the other property.
This is the response from such a Tradfri bulb:
https://ip/api-key/lights/7
edit: Actually, hue scheduler recognizes a manual change for them with each schedule. I am not sure why, yet. When I check the lights with the above API request the intended brightness is set correctly.
The text was updated successfully, but these errors were encountered: