Sonoff Dongle E

[Blackspell01]

Is this supposed to work with the Sonoff Dongle E with the Silicon Labs EFR32MG21 chip?

[altazure]

I can also confirm I'm getting the same error with the same dongle.

[3dluvr]

You need to specify the baudrate...for me it starts working and the bulb flashes a few times but then I get an error

$ python hue-thief.py -b 115200 /dev/ttyACM0
Scanning on channel 11
NCP entered failed state. Requesting APP controller restart
Traceback (most recent call last):
  File "/home/user/Envs/playground/lib/python3.9/site-packages/bellows/ezsp/protocol.py", line 152, in command
    return await future
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/user/Envs/playground/src/hue-thief/hue-thief.py", line 135, in <module>
    asyncio.get_event_loop().run_until_complete(steal(args.device, args.baudrate, args.channel))
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/home/user/Envs/playground/src/hue-thief/hue-thief.py", line 105, in steal
    await dev.mfglibSendPacket(frame)
  File "/home/user/Envs/playground/lib/python3.9/site-packages/bellows/ezsp/protocol.py", line 152, in command
    return await future
  File "/home/user/Envs/playground/lib/python3.9/site-packages/async_timeout/__init__.py", line 141, in __aexit__
    self._do_exit(exc_type)
  File "/home/user/Envs/playground/lib/python3.9/site-packages/async_timeout/__init__.py", line 228, in _do_exit
    raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError

[altazure]

I can again confirm having the same issue: Specifying the baudrate allows me to get to the scanning stage, but once the bulb is found, it flashes a few times, and then I get the same error as @3dluvr.

Just to make sure, I tested it on three different devices (but the same dongle), two different Raspberry Pis (one older 3 model B+, one brand new 5 model B), as well as an older laptop now running Linux Mint, and got the same error message every time.

[3dluvr]

@altazure

After fiddling yesterday with various versions of the dongle firmware and bellows, I settled on 6.10.7 and bellows==0.35.5.

This combination still returns NCP entered failed state. Requesting APP controller restart and the bulb flashes a few times, but it actually does reset the bulb. I was able to pair it via ZHA and control it.

I have 2 more brand new untouched bulbs, so I will need to run this process on them to confirm.

Also, the NCP failed state message is apparently normal behaviour, according to https://github.com/zigpy/bellows/issues/377

[altazure]

@3dluvr

Good to hear that you found a solution! Inspired by you changing the bellows version, I dug into the code to see where the error happens. Long story short: Because the bulb flashes, I realized that the identification flash command gets sent, but the await on that times out(?) for some reason, giving the error.

Figuring that it might be possible to send the reset command in a similar manner, I just removed the await on the flash message (and the user interactive confirmation check too, though in hindsight that was probably not necessary), and in that way just forced the program to basically ignore the reason for the error and get to the part where the reset command is sent. And it works, the reset command actually does get sent and the bulb was reset -- I paired it with ZHA and it's working properly.

It's more of a hacky brute force workaround than a proper fix, though.

And yeah, I still got the NCP failed state message but it worked nonetheless.

[3dluvr]

@altazure

That's great to hear, at least the hue-thief is doing its part and we can reset the bulbs.

As an aside, when I tried a bunch of other versions, beyond bellows==0.35.5 all kinds of errors occur, as well as bumping the dongle firmware to 7.x series. But I did not want to invest any time into debugging the code, just wanted to get going with something (turning the light on and off was enough to make me happy that late at night LOL).

I wonder though if we are missing anything using 6.10 vs 7.x firmware...