WS281x led device fails to start with "Device '' was not ready! Trying to re-open."

[mharring]

The changes from #654 have unfortunately broken the WS281x Led Device (and presumably other led devices, although I haven't tested any others). On attempting to start hyperion, I see the following messages in the log:

[hyperiond LEDDEVICE] (DEBUG) (LedDevice.cpp:68:setEnable()) Device '' was not ready! Trying to re-open. [hyperiond LEDDEVICE] (DEBUG) (LedDevice.cpp:68:setEnable()) Previous line repeats 200 times

The _deviceReady flag is set in the LedDevice::start function, which calls LedDevice::open and sets the flag depending on the result. However, in the LedDevice::open function, LedDevice::setEnable is called, which checks _deviceReady and throws an error if it isn't. This will always fail because _deviceReady hasn't be set to true until LedDevice::open returns.

In a related note, if _deviceReady is false when LedDevice::setEnable is called, LedDevice::open is called again (which in turn calls LedDevice::setEnable and so on and so forth).

I agree with the type of check that was intended here, but the logic needs some tweaks.

[Lord-Grey]

@mharring Thanks for the feedback. I will have a look and come back to you.

[Lord-Grey]

@mharring Seems I found the problem. The open() method for the WS281x device was not invoked. I think, I fixed the problem. The device is now recognised and goes now correctly in error in my environment.

Would you do me the favour testing the changes before I will publish them widely? I included some additional Debug statements just to trace the initialization part. It would be good, if you could run hyperiond in Debug mode and share the output with me afterwards.

Many thanks in advance for your support!

The updated files you find here 20200213_ws281x-fix.tar. Just put the tar file in the hyperion home directory and extract the files via

tar -xvf 20200213_ws281x-fix.tar

Now compile as before and start hyperiond.

[mharring]

Thanks for taking a look. I'm not sure when I'll have time to rebuild but I'll give it a shot when I can.

Open was being called on the master branch by the start function when the led device thread was created (see start function in LedDevice.h):

///
/// Is called on thread start, all construction tasks and init should run here
///
virtual void start() { _deviceReady = (open() == 0 ? true : false);}

[Lord-Grey]

@TheAndi You are welcome to test the fix, too.

[TheAndi]

It's compiling, I'll let you know soon

[TheAndi]

Ok, I gave it a test. The ws281x device does work now and the smoothing can be disabled.

One note to that: The activation state of the smoothing is still not properly synced between the control panel and the activate checkbox of the smoothing settings.

Furthermore, I noticed that the LED output stops when global smoothing is turned on and a Effekt is selected. Unfortunately there is no error in the logs. A quick disable/reanable of smoothing or led device however makes the effect show as intended.

Let me know how if I can provide more info.

[TheAndi]

And one more thing, when smoothing is disabled I get random flicker in my led strips. Especially noticeable with the breath effect. Even a little smoothing of 25ms solves it.

I'm not sure if it's the same flickr I mentioned in https://github.com/hyperion-project/hyperion.ng/issues/641 (here I thought it's the SPI driving method)

[Lord-Grey]

One note to that: The activation state of the smoothing is still not properly synced between the control panel and the activate checkbox of the smoothing settings.

I captured a separate issue #680.

[Lord-Grey]

Furthermore, I noticed that the LED output stops when global smoothing is turned on and a Effekt is selected. Unfortunately there is no error in the logs. A quick disable/re-enable of smoothing or led device however makes the effect show as intended.

Would you mind outlining the steps you executed for the test? What is your expectation? Currently the effect starts immediately after the last standard write. There is no smooth transition between output and effect .

And one more thing, when smoothing is disabled I get random flicker in my led strips. Especially noticeable with the breath effect. Even a little smoothing of 25ms solves it.

I tested with the "file" LedDevice which outputs the LED RGB values written. I ran a Colour Effect with pure red and there were not any differences in the output records over the whole time. I would assume it is a hardware setup/configuration problem, not a software one.

[TheAndi]

Would you mind outlining the steps you executed for the test? What is your expectation? Currently the effect starts immediately after the last standard write. There is no smooth transition between output and effect .

Sure here's my commented log

[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> Smoothing: enabled
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:250:clearInput()> Removed source priority 1
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 254
[hyperiond EFFECTENGINE] <INFO> effect finished
[hyperiond EFFECTENGINE] <INFO> Run effect "Atomic swirl" on channel 1
[hyperiond EFFECTENGINE] <DEBUG> <EffectEngine.cpp:183:runEffectScript()> Start the effect: name [Atomic swirl], smoothCfg [2]
--effect not showing--
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:153:registerInput()> Register new input 'Web Configuration@::ffff:192.168.178.40/EFFECT' with priority 1 as inactive
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:233:setInputImage()> Priority 1 is now active
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 1
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> LED device: disabled
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> LED device: enabled
--"Atomic swirl"  shows up--
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:250:clearInput()> Removed source priority 1
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 254
[hyperiond EFFECTENGINE] <INFO> effect finished
[hyperiond EFFECTENGINE] <INFO> Run effect "Breath" on channel 1
[hyperiond EFFECTENGINE] <DEBUG> <EffectEngine.cpp:183:runEffectScript()> Start the effect: name [Breath], smoothCfg [2]
--effect not showing--
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:153:registerInput()> Register new input 'Web Configuration@::ffff:192.168.178.40/EFFECT' with priority 1 as inactive
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:193:setInput()> Priority 1 is now active
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 1
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> Smoothing: disabled
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> Smoothing: enabled
--"Breath" shwoing up--
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:250:clearInput()> Removed source priority 1
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 254
[hyperiond EFFECTENGINE] <INFO> effect finished

When I remember correctly every time the effect was "not showing" hyperion wen't back to my background color and wasn't showing any more inputs (also no single colors) until either smooth or led device was toggled.

[TheAndi]

I tested with the "file" LedDevice which outputs the LED RGB values written. I ran a Colour Effect with pure red and there were not any differences in the output records over the whole time. I would assume it is a hardware setup/configuration problem, not a software one.

I am running my strip setup for many years now (with old Hyperion and Pi3) without any flicker, so I would say my hardware is fine. Furthermore, with smoothing enabled, there is no more flicker.

Flicker was first seen when I switched to Hyperion.ng and a Pi1 B+.

Could it be that some effects are updating the LEDs even faster than the 60Hz of the enabled smoothing and are therefore overloading my Pi1 when the frame rate is not limited by the smoothing algorithm?