-
Notifications
You must be signed in to change notification settings - Fork 13
Fade timings are sporadically off #8
Comments
Well, it does not happend always but quite regularly. I have written a small script to reproduce the issue: It will set different hues with ramps and then check the final hue value after waiting the ramp time. It will run in an endless loop. You will sometimes see stuff like this
Which means it sets a hue of 50 (ramp 1.0) and then hue of 200 with a ramp of 60 seconds. So it will fade from 50 to 200 in 60 seconds. But after 61 seconds the hue value still was only 179 (200 not reached yet). |
Thanks for reporting this. I've used your script to test the behavior and can confirm your findings. However - how important are 100% time dependant fades? Which use case requires this? Currently the controller use the Sming Timer Delegates to call the rgbwwlibrary which then handles fading/animations See: Animations/Fades are internally handled on a 'step basis'
It might be, that the esp is busy handling other tasks and thus the relation between steps/time will be out of sync. |
I noticed this behavior when I tried to synchronize two LED devices in FHEM (I tried a LedController with a WifiLight). To get a long-running disco effect I issued a 15 minute hue-fade to both devices (repeatedly). And it was quite obvious that the visible color often differed alot. The same happened when tried to synchronize 2 LedControllers device in the same way. You are right and I don't expect it to be 100% accurate. But honestly, I am considering a fade taking ~75 seconds instead of the requested 60 seconds to be quite significantly off. A fix for this would be great. Maybe there is anything I can do or anything I can help out with? |
I added some more debug outputs to better analyze what is going on when it happens. I wanted to see if there is one particular single lag that occurs which pauses the processing for some time or if the fade in general is too slow. So I made hue fade from 100 to 160 within 60 seconds and did an output every 3 seconds. So the current fade time and last two digits of the hue value should always match (e.g. after 35 seconds the hue should be at 135).
So, what we see is:
Correct me if I am wrong but it does not look to me as there are certain moments where the controller is busy and some particular lags occur. To me it looks like for some reasons certain fades are executed wrongly. Maybe some miscalculation regarding start or end HSV values or something like that? Please find the updated script here: |
Usually fade timings are really accurate for me and do match well with the passed fade time in the command. But sometimes when issueing a fade command then the fade takes significantly longer to execute than desired.
I am not sure if this is an issue with the firmware or maybe with the RGBWWLed library. Also I tested only with FHEM so it might also be an issue with the FHEM module. But my best guess is that it is related to the firmare.
The issue is 100% reproducible for me using these commands:
I always issue one command then wait until it completes. Then I send the next command (manually). All fades work fine but the last one takes about 74 seconds to complete instead of the targeted 60 seconds.
I am using latest firmware 0.3.1.
The text was updated successfully, but these errors were encountered: