Jump to content

WIFI Master Extension 2.0 green status light


Recommended Posts


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)

Edited by Superp
Link to comment
Share on other sites


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.


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...