Comments (6)
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:
- Ikea Tradfri bulbs can't handle multiple property changes in a single API call
- If split into multiple calls, there needs to be a short delay between them
- Multiple instances of the scheduler cause too many request rejections by the Hue bridge
- The manual change tracking of the Hue Scheduler prevents some updates if multiple instances are running in parallel
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 --power-on-reschedule-delay
global configuration flag was added (initially forgot to mention it in the release notes), which controls the delay in ms after a light-on event was detected and when the scheduler should reapply the desired light states. The default value is 150ms, but you can adjust this value for the multiple instances, which should prevent the scheduler to fire pending updates all at the same time, when the lights are turned on.
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 --max-requests-per-second
global configuration flag. The default is set to 10 requests per second. If you come across this error again, I would be interested in the exact error message the bridge is throwing, as I could probably improve such error handling in the future.
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.
For states that only define the brightness, no expected color mode can be derived, but the scheduler failed to ignore the color mode in such cases and therefore incorrectly detected a change. I published a fix for this with version v0.8.0.1. Let me know, if this solves this issue.
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. ct
, bri
, hue
, sat
, xy
or just ct
and bri
. If we know what the bulbs expect, I could adapt the API calls for those specific models explicitly, so that you wouldn't need to run multiple instances to begin with.
from hue-scheduler.
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, transitiontime
is supported by those bulbs (I spelled it wrong in my first post and my tests, initially). It works fine as long as only 1 state is being changed. And it's even possible to apply at least 2 states with 1 API request. But... one needs to send it explicitly with a transitiontime
of 0
. That's where tr
and tr-before
come very handy. I found that information in this post and can confirm it works with my powershell tests.
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 tranisitontime
is sent with the value 3
instead of 0
. Resulting in those unfinished state changes and hue scheduler detecting manual changes, hence aborting further schedules. Interestingly, the state change on application start is sent with a transitionTime
of 0
and that very first state change works as intended.
So if that'd be fixed sufficient Tradfri support would be available. One could add a note like this into the readme:
"Most Tradfri bulbs suffer a firmware bug when sending 2 or more property changes (e.g. bri
and ct
) concurrently to the bulb with a transitiontime
above 0
. It won't apply both values. This also causes an unintentinal manual change detection in hue-scheduler that stops further schedules. So if you want to schedule more than 1 state at the same time make sure to set tr
and tr-before
to 0
for these bulbs, explicitly. If you still want to have some kind of smooth transition with multiple properties, you could schedule a bunch of minor state changes on your own to imitate the transition behaviour.
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.
from hue-scheduler.
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 tr-before
should probably not be set at all, if the goal is to have an exact transition time of 0 in the API call, as tr-before
is right now only intended for dynamically calculating transition times. Maybe the scheduler still detects some time difference of a few ms even if tr-before
is set to 0, which could then in turn be used for the transition time instead of the explicit tr:0
. So better just set tr:0
and don't set tr-before
at all, as it's not needed and intended for this use case.
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.
from hue-scheduler.
Jippie, not setting tr-before
does the trick to send the transitiontime
as 0
. I confirmed the behvaiour with this setting:
Wohnzimmer Vorn 19:04 bri:1 ct:2200 tr:0
Wohnzimmer Vorn 19:05 bri:254 ct:4000 tr:0
Wohnzimmer Vorn 19:06 bri:1 ct:2200 tr:0
Wohnzimmer Vorn 19:07 bri:254 ct:4000 tr:0
Adding tr-before:0
or tr-before:0s
will send a 5
today instead of a 3
like yesterday. I didn't expect that to be the solution, as I wanted to be as specific as possible. Thought it's a fall back to some default value or so:
Wohnzimmer Vorn 19:08 bri:1 ct:2200 tr:0 tr-before:0
Wohnzimmer Vorn 19:09 bri:254 ct:4000 tr:0 tr-before:0
Wohnzimmer Vorn 19:10 bri:1 ct:2200 tr:0 tr-before:0
Wohnzimmer Vorn 19:11 bri:254 ct:4000 tr:0 tr-before:0
off-topic:
So at that point thanks to you I can achieve everything I ever wanted with my smart lights at home. I can also run just 1 hue-scheduler now. Both a further increased support for Tradfri bulbs and the "Continuous transition management" would probably "only" reduce the huge size of configuration for me but not change the behaviour from a user perspectve. Sure, the ability to achieve the same with way less configuration workarounds would still be very welcome.
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.
from hue-scheduler.
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.
from hue-scheduler.
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.
from hue-scheduler.
Related Issues (6)
- No transition HOT 2
- Thank you ❤ HOT 5
- Continuous transition management HOT 9
- Docker image HOT 3
- Schedule configuration validation HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hue-scheduler.