WIFI Master Extension 2.0 green status light

[Superp]

Hello,

I have a WIFI Master Extension 2.0 mounted on top of a Master Brick 3.1

As per the documentation I can control the green status LED of the WIFI Extension 2.0 with two methods:

• #enable_wifi2_status_led
• #disable_wifi2_status_led

When I call the disable method, the led turns off, and #is_wifi2_status_led_enabled returns false, as expected.

When I call the enable method, the led does not turn back on, but #is_wifi2_status_led_enabled returns true.

Only when I reset the Master Brick does the green LED turn on again.

Am I doing something wrong or is this a bug?

(Edited to clarify #is_wifi2_status_led_enabled returns expected result)

bearbeitet December 14, 2021 at 08:22 von Superp
clarify

[rtrbt]

Hi,

How is your extension configured?

The methods work for me. Does the attached script print the same messages with your extension? (Remember to change the UID ;) )

$ ruby test.rb
LED true
Press key to disable LED

LED false
Press key to enable LED

LED true
Press key to exit

 

test.rb

[Superp]

rtrbt,

Thanks for your quick help.

When I run your script, I get the exact same output.

But after the green LED is switched off, it does not come back on again. Software reports the LED is ON, in reality it is OFF, until I reset or powercycle.

To be sure:

• I reconfigured the extension in Brickv (extension 0 / WIFI 2.0) and configured it again as client only.
• I reset the Master Brick, and powercycled the stack.

No change. Once off, it is not possible to turn the LED back on.

I have two brand new stacks (MB3.1/Wifi2) that both become unresponsive after some time when connected via WLAN. I hooked up one stack via USB to be able to continue development, and then this problem with the Wifi status LED turned up. My thinking was, this LED problem is unrelated, but maybe it is not.

Maybe whatever is making my stacks unresponsive via Wifi is also causing the problem with the Wifi status LED.

The other Master Brick, while trying to address the above problem, entered zombie mode, as I reported here.

 

[rtrbt]

20 hours ago, Superp said:

and configured it again as client only.

This seems to be the problem here. If the extension is configured only as client, the status LED stops blinking if the extension is connected.

The code is event driven, so when you disable and enable the status LED, what really happens is that the connection between the WiFi events and the LED state is severed or (re)connected. The issue is now, that no event from the WiFi code is generated if the extension is already connected and when you re-enable the LED the state is never changed.

Interestingly, when disabling the LED, it is then shut off manually. We've added the same work-around for the enable function (first toggle the LED on, then reconnect it to the WiFi events). This is not perfect, because if the WiFi state would cause the LED to stay off and you disable and re-enable the LED it will stay on, but I think this behaviour better fits the user expectations better, as the LED should light up when you call enable... in any case.

20 hours ago, Superp said:

I have two brand new stacks (MB3.1/Wifi2) that both become unresponsive after some time when connected via WLAN.

This is another issue. Do you have any more information about this? But the LED problem should indeed be unrelated.

[Superp]

Thanks for explaining in detail. This is certainly an interesting bug.

To conclude, what happens next?

• There will be new firmware, or
• Now that we know what happens, we leave it as it is

If you could clarify that?

I propose we then close this threat and I start a new threat about the unresponsive stacks.

[photron]

1 hour ago, Superp said:

There will be new firmware

Exactly this. Version 2.1.5 just got released.

[Superp]

I can confirm FW 2.1.6 fixes this issue for Wifi Extension 2.0 in client mode (with the limitation described above).