Custom firmware for Sonoff SNZB 01P button

[bobo-cher]

Can we use the same approach to bring direct binding to Sonoff SNZB 01P Button?

Test points TMS and TCK are connected to SWDIO and SWDCLK pins of the MCU. I tested with J-Link:

[nix-shell:~/zbminir2]$ sudo openocd -f interface/jlink.cfg -c 'transport select swd' -f openocd/efm32s2.cfg 
Open On-Chip Debugger 0.12.0+dev-snapshot (2025-01-28-19:38)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
swd
efm32s2_dci_read_se_status
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04
Info : Hardware version: 7.00
Info : VTarget = 3.300 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x6ba02477
Info : SWD DPIDR 0x6ba02477
Error: Failed to read memory at 0xe000ed00
Successfully connected to DCI
DCI WPENDING bit set, retrying
DCI SESTATUS response:
Debug lock (config): Enabled
Device erase: Enabled
Secure debug: Disabled
Debug lock (hw status): Enabled


 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
  You will not be able to communicate with this device
  unless you perform a device erase (if available, indicated above)!
  Try efm32s2_dci_device_erase to attempt erase.
 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Warn : target efm32s2.cpu examination failed
Info : starting gdb server for efm32s2.cpu on 3333
Info : Listening on port 3333 for gdb connections

Looks promising, right?

This is a different chip, EFR32MG22, and it probably requires a different configuration of the project and J-Link config.

I haven't tried to erase the flash yet as I wanted to get your opinion first, before doing things, which may destroy the device ;)

It would be great to be able to use these buttons to control zbminir2. I have four different kinds of buttons and all of them have significant delay/latency when controlling lights via HA automations. One button supports binding to groups but it doesn't improve latency (and the button itself feels cheep and isn't that nice).

I hope with a custom firmware on Sonoff button we can get a fast working remote for lights, which is also independent from coordinator and HA.

[ius]

Looks promising, right?

Definitely!

This is a different chip, EFR32MG22, and it probably requires a different configuration of the project and J-Link config.
I haven't tried to erase the flash yet as I wanted to get your opinion first, before doing things, which may destroy the device ;)

Yeah, it's a different chip, but shouldn't really be all that different compared to zbminir2 - project configuration wise. The only thing tying it to EFR32MG21 is the pin configuration and one reference to the EFR32MG21A020F768IM32 component to pull in chip specifics.

Hardware wise it's fairly similar: it has a led and two button inputs - it just needs slightly different handlers for the buttons.

I can see only two gotchas:

• The SoC only has 512kB of flash (compared to the 768k MG21 in zbminir2) - the board also has SPI flash onboard. There's a silabs bootloader variant which supports storing OTA images on SPI flash so I guess that's what Sonoff is doing.
• It's a battery powered device. It will require additional optimization (likely have it enter EM4) to avoid draining the battery.

In any case, you've nerd sniped me into buying a SNZB-01P to see whether we can get that supported ;) Disclaimer: might take some time, I'm a bit busy and I'd like to get zbminir2 finished up too..

I hope with a custom firmware on Sonoff button we can get a fast working remote for lights, which is also independent from coordinator and HA.

So it doesn't support bindings out of the box? What do the short/long/double press actions look like over the air?

(Thanks for adding detailed photos, that's really helpful)

[bobo-cher]

you've nerd sniped me into buying a SNZB-01P

Mission accomplished 😎

I can see only two gotchas:

OTA is much less important on this device. In a case with zbminir2 firmware updates (without OTA) require extraction of mini from the wall box, which can be a lot of work. The remote button is a totally different case. For those lucky who have PCBite reflashing even doesn't require disassembly. And for others it should be possible to leave short thin wires in battery compartment for later use. Therefore my suggestion: OTA is a low priority.

So it doesn't support bindings out of the box?

Yes, what a pity. Some reviewers mentioned that the previous version ("01" without "P") did support binding but not the new one.

What do the short/long/double press actions look like over the air?

Let me do some sniffing and I'll write back.

it's a different chip, but shouldn't really be all that different compared to zbminir2 - project configuration wise.

I'm willing to experiment with the device. How high are chances to totally brick the device if using wrong configuration (for example flashing into wrong memory address etc.)? I've noted that the zbminir2 firmware consists of two parts: bootloader and the main program. Can the device be flashed again even if previously flashed with bad bootloader?

[ius]

I'm willing to experiment with the device. How high are chances to totally brick the device if using wrong configuration (for example flashing into wrong memory address etc.)?

Zero I'd say.

I've noted that the zbminir2 firmware consists of two parts: bootloader and the main program. Can the device be flashed again even if previously flashed with bad bootloader?

Sure, the debug interface should always work - after all we use it to flash the bootloader too.

Perhaps it's possible to configure the bootloader to disable the debug interface in software, but since you managed to get a DPIDR that doesn't seem to be the case. And certainly won't be an issue after erasing ;)

But nothing is sent to that device - the same behaviour as with default zbminir2 firmware.

Classic.

[bobo-cher]

What do the short/long/double press actions look like over the air?

It sends commands from cluster OnOff to coordinator:

• Toggle on single click;
• On on double click;
• Off after pushing the button for 3 seconds. Nothing is sent when the button is released.

Example for single click:

ZigBee Network Layer Data, Dst: 0x0000, Src: 0x3c47
    Frame Control Field: 0x2248, Frame Type: Data, Discover Route: Enable, Security, End Device Initiator Data
    Destination: 0x0000
    Source: 0x3c47
    Radius: 30
    Sequence Number: 80
    [Extended Source: SiliconLabor_ff:fe:19:a5:4a (44:e2:f8:ff:fe:19:a5:4a)]
    [Origin: 56]
    ZigBee Security Header
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x00)
    Destination Endpoint: 1
    Cluster: On/Off (0x0006)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 147
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x01)
    Sequence Number: 50
    Command: Toggle (0x02)

I can bind the button to other device in Z2M and a message confirming successful binding is shown. But nothing is sent to that device - the same behaviour as with default zbminir2 firmware.

[bobo-cher]

Got it working! 🥳

Pins

Function	Pin
TX	PA06
RX	PA05
Main button	PA04
Side button	PB01
Led	PD00
SPI Flash	PC00-PC03 (probably, not tested)

Progress

• Pin assignment
• Bootloader
• Erase flash
• Flash firmware
• Firmware boots
• Serial interface
• Joining to network via side button
• Assigning bindings in z2m
• Main button single click
• Proper device id and clusters - currently identifies as zbminir2
• Proper device type - currently router
• Better led function - we don't want the led to be on all the time
• Replace end-device type with sleepy-end-device
• Power management - support sleep states to save battery life
• Power management - support deep sleep when not joined. Currently sleeps only when joined to network
• Provide power source information (probably via powerCfg cluster) and battery status
• OTA

I'll upload my fork later and can make a PR if you like.

[bobo-cher]

Uploaded my fork: https://github.com/bobo-cher/zbminir2/tree/snzb01p

[ius]

Nice progress! Will update once I have some time to try it out myself..

For power management, be careful entering EM4 as I saw a report (n=1) of someone being unable to enter debug due to the debug subsystem being disabled in EM4.

On other devices where I run into similar problems, I make sure to enter deep sleep only after a short timeout to avoid that..

[bobo-cher]

Update

• Implemented sleepy-end-device device type.
• Improved led function: blinks during joining, turns off when joined.
• Power management is almost working. The only problem remaining is that the sleep states work only after joining to network. There is an option to sleep even if not joined couldn't get it work yet.
• Power consumption once joined to network: 13 μA, exactly like with original firmware.
• Power consumption when not joined: 1 mA (yeah, needs to be fixed).
• Latency between clicking on button and reaction from light is practically non-existent, even from deep sleep state.

User Guide

• In Z2M permit join.
• Press and release the small side button on the device to initiate joining.
• Led blinks during joining and turns off after joining.
• For whatever reason Z2M doesn't configure the device: the binding and reporting isn't properly setup. To fix this click on "Configure" button in Z2M. Press and release the small side button to initiate binding negotiation.
• Setup binding in Z2M to control a light device and click on "Bind" button. Press and release the small side button to wake up device and initiate binding negotiation.

The small side button has therefore two modes:

• When not joined it initiates joining.
• When joined it initiates binding.

Reset (disconnect from network):

• Press and keep holding the large top button.
• Press and release the small side button - network will be left.
• Release the large top button.

After reset the device is in not joined state and can be joined again via small side button.

TODO

• Power management: support deep sleep when not joined. Currently sleeps only when joined to network.
• Provide power source information (probably via powerCfg cluster) and battery status.
• Fix Z2M not configuring automatically.
• OTA.

[bobo-cher]

Update

• The big one: got power management under control. There is a bug in current SiSDK preventing sleep when not joined. A recommend workaround is to patch library files (hardcoding it for sleeping). That would however prevent normal work of other device types (e. g. zbminir2). I was able to develop a workaround in snzb01p code which doesn't require patching of the library files. This makes the project also easier to build.
• Reworked button and led functions.
• Long press on small button leaves current network (if previously connected) and initiates joining.
• Short press on small button initiates binding (if already joined).
• Led blinks quickly during joining and during binding.
• Successful joining is confirmed with a 5 second led light.

User Guide (updated)

• In Z2M permit join.
• To initiate joining press the small button on the device for several seconds until the led starts blinking. Release the button.
• Led blinks quickly during joining. A successful joining is confirmed with a 5 second led light. If the led just stopped blinking the joining has failed.
• For whatever reason Z2M doesn't configure the device: the binding and reporting isn't properly setup. To fix this click on "Configure" button in Z2M under device details. Quickly press and release the small button to initiate binding negotiation.
• In Z2M under device details configure binding to control a light device and click on "Bind" button. Press and release the small button to wake up device and initiate binding negotiation. Z2M should confirm that the binding was successful.
• Click large button to toggle the lights.

TODO

• Provide battery status.
• Fix Z2M not configuring automatically.
• OTA.

[bobo-cher]

Update

• Battery status (voltage an percentage) is reported to coordinator.
• Issue with Z2M not automatically configuring the button after joining has been resolved. It was caused by Z2M marking the device as non-configurable after three failed attempts. Removing device from Z2M database helped.

User Guide (updated)

• In Z2M permit join.
• To initiate joining press the small button on the device for several seconds until the led starts blinking. Release the button.
• Led blinks quickly during joining. A successful joining is confirmed with a 5 second led light. If the led just stopped blinking the joining has failed.
• In Z2M under device details configure binding to control a light device and click on "Bind" button. Press and release large or small button to wake up the device and initiate binding negotiation. Z2M should confirm that the binding was successful.
• Use large button to toggle the lights.

TODO

• OTA.

[bobo-cher]

Update

• Added support for double and triple clicks.
• Each action (single click, double click, etc.) can send any of the commands (on, off, toggle) to one or more devices.
• Low-latency mode for single clicks.
• See user guide for details.

User Guide (updated)

The user guide has become too large to post it here in the discussion. It now has its own wiki-page: SNZB-01P+ User Guide.

TODO

• OTA is still missing. Don't know how to configure SPI flash properly 😕

[bobo-cher]

Update

• Got communication with SPI flash working. However OTA wasn't the main reason to work on this.
• By sending a special command to SPI flash we now put it into deep sleep (power down) mode. That saves 9μA of current consumption.

Power consumption measurements (somewhat confusing)

I've flashed two units and got somewhat confusing results regarding power consumptions:

• Before SPI power down thing the consumption on first unit was 13μA and on the second unit 23μA.
• After implementing SPI power down mode the consumption dropped to 4μA on first unit and 14μA on second unit.
• The drop of 9μA corresponds to the data sheet of the SPI flash.

I cannot explain the difference in 10μA on both units. That's quite a lot of difference comparing absolute numbers. Of course I cannot trust the absolute numbers on my (20 years) old cheap multimeter. But the measurements are totally reproducible and consistent.

Both units work correctly. They were erased and flashed multiple times.

The 14μA of second unit is equal to what I measured with original firmware on that unit before flashing. Unfortunately I haven't measured the first unit running original firmware to compare with.

Could this difference in energy consumption be caused by some faulty component (like capacitor etc.)? According to documentation on MG22 the 3μA is what you could expect in EM2 power mode (normal deep sleep). Where the additional 10μA comes from?

I'll receive a third unit soon and will do measurements before and after flashing.

[bobo-cher]

Update

• bootloader now supports our SPI flash.
• power down of SPI flash is now made through bootloader instead of directly talking to SPI.
• OTA is work in progress.
• third unit is measured with 3μA of current consumption running original firmware. I assume the second unit (with 14μA) is a bad/faulty unit, although it works OK in other regards.

[bobo-cher]

Update

• OTA works!

There are two issues though:

• Because we currently shutdown spi flash, the OTA hangs immediately after start. Temporary solution (for development/debugging) is to disable function power_down_spi_flash in "app.c".
• Update is very slow due to polling in sleepy end device. Temporary solution (for development/debugging) is to change device type from SLI_ZIGBEE_NETWORK_DEVICE_TYPE_SLEEPY_END_DEVICE to SLI_ZIGBEE_NETWORK_DEVICE_TYPE_END_DEVICE in "snzb01p.slcp".

[bobo-cher]

Update

• All issues have been fixed. OTA is fully working.

[bobo-cher]

Please let me know how would you prefer to handle the firmware for SNZB-01P. I could create a pull request to merge it into your repository or we could keep it separate. In the latter case I would create a new repository (under my account) with an appropriate name and only with button stuff (no zbminir2 parts). Thanks.

[ius]

Thanks for the extensive updates! I followed along, even though I didn't get around to responding - great to see you basically got everything working. Unfortunately I haven't gotten around to testing your work - nor finishing up the missing zbminir2 features, for that matter.

As for merging, functionality wise that totally makes sense. I'm not sure how to handle (if at all) the branding/marketing problem caused by naming this repository 'zbminir2' - thoughts?

Looks like you've only touched the build script - so whereas I do feel bad about not having finished up missing zbminir2 features yet (soon™) - I don't think that has to be a blocker as long as we're not merging the C implementation.

[bobo-cher]

Thanks for the feedback.

I'll be glad to merge my work into your repository. Let me know when you have more free time for this. Although I've finished the first version, I'm still finding small things to fix now and then. Doing a real life test with two buttons for the last couple of days helped.

I have some thoughts for the second version like better control of dimmable lights. I might want to wait for the feedback from users first (if there will be any, ha-ha).

GitHub repositories can be renamed and everything should continue to work - see Renaming a repository. The only difficult part here is to come up with a good new name 😉.

To make the adoption easier I would offer releases with compiled firmwares. There is a precompiled version of patched OpenOCD for Windows, which we could point users to. The flashing of firmware for Windows users should be pretty easy then (with an extra guide of course).