It works!

[bobo-cher]

Flashed the firmware and it worked straight away!

Posting a few photos as a proof 😉

The immediate response on toggling of switch is remarkable.

Tested with another zbminir2 as a receiver. That's what I needed for my project (one mini in wall box behind switch should control another mini connected to lights).

Thank you for sharing this firmware.

I'll do more tests on weekend.

P.S. consider enabling discussions on this repository for posts like this, which are strictly speaking not issues.

[ius]

That's great to hear!

I do have a small fix incoming for the reliability issues I've been seeing myself. With that, I'm fairly confident the most obvious use case (toggling a remote bulb/device) should work each and every time.

Going forward, I might look into achieving feature parity with the original firmware. It would also be neat to make the Zigbee command sent configurable - the Toggle I'm currently sending doesn't switch on/off my Hue bulb instantly but applies a (very short) fade. With Move to Level it can be toggled instantly.

[bobo-cher]

Observations

• Binding to itself makes it to a simple switch 😆
• After resetting via on-device button or via 5x click the binding remains active. Z2M doesn't show any bindings though. To release the binding I needed to configure the same binding in Z2M again and then to delete it. I would expect all bindings to be cleared on reset.

Feedback on documentation

• Generally the getting started guide is awesome. I could compile the firmware on first try.
• I wish there were a hint that openocd requires extra permissions to access USB. That would have saved me four hours of research and trying of multiple Linux VM just to realise that my J-Link was OK and I just need to put sudo before openocd 🤣

[ius]

Observations

• Binding to itself makes it to a simple switch 😆

🤣

• After resetting via on-device button or via 5x click the binding remains active. Z2M doesn't show any bindings though. To release the binding I needed to configure the same binding in Z2M again and then to delete it. I would expect all bindings to be cleared on reset.

Good catch. Not sure whether Zigbee allows bindings to be enumerated, but I agree it makes sense to clear them on reset. Fixed in f4e4831

• I wish there were a hint that openocd requires extra permissions to access USB. That would have saved me four hours of research and trying of multiple Linux VM just to realise that my J-Link was OK and I just need to put sudo before openocd 🤣

Ouch. I've added a note about USB permissions to the guide - didn't realize due to having configured a udev rule for the adapter myself..

Aside from the binding table change, I've also fixed switch debounce and added the eWeLink manfacturer specific cluster (changing the attributes doesn't have any effect currently, but I guess at least it'll make Z2M spew fewer errors).

[bobo-cher]

Thank you. I'll test the new version tomorrow.
I could test OTA too but need some guidance. I have a second ZBDongle-E, which I can use for that.

---

Noticed a typo in getting started guide:

You can also trigger a (re)join by toggling the external switch ~10 times in rapid succession.

It should say 5 times.

---

You've mentioned a possible configuration option for command to send. To make this option appear in Z2M a custom converter would be needed. I wonder if you can change model id in the firmware for Z2M to distinguish between official zbminir2 and your mod. Do you plan to do this at some point later?

Right now it's even good that no changes to Z2M are needed actually, makes it easier to start using the firmware.

[ius]

It should say 5 times.

Fixed.

I wonder if you can change model id in the firmware for Z2M to distinguish between official zbminir2 and your mod. Do you plan to do this at some point later?

I think Z2M is fairly flexible - I'll look into it once I get around to making the Zigbee command emitted configurable.

---

In other news, I've documented how to update over the air, check out OTA Updates.

It might be a little rough around the edges - just wanted to get it published, let me know if you encounter any issues.

Note that the firmware version is currently configured as 1 (SL_ZIGBEE_AF_PLUGIN_OTA_CLIENT_POLICY_FIRMWARE_VERSION 1) but the OTA image header claims it's version 0x02 - it's a bit of trickery to make sure it always accepts updates (for now),

[bobo-cher]

Thank you. Got OTA working.

• Sonoff ZBDongle-E currently doesn't work with 8.1.0 firmware. That's a known issue: Feedback on EmberZNet 8.1.0 SiliconLabs/simplicity_sdk#29.
• z3gateway app compiled with 8.1.0 SDK cannot connect to dongle running other firmware versions.
• I had to rebuild z3gateway (actually the whole project/firmware) using 8.0.2 SDK (the latest supported on this dongle); that required changes to nix-files which reference SDK.
• BTW, simplicity_commander.nix needed to be updated too to reflect version bump on their server.
• z3gateway app has a different name and is located in other path in 8.0.2 SDK, had to change the build script accordingly.
• z3gateway must be started with other parameters on ZBDongle-E because the dongle doesn't support hardware flow control. In my case the command was:

  sudo ./build/z3gateway.elf -b 115200 -f x -d build -p /dev/ttyUSB0

• for whatever reason with command plugin network-steering start 0 the dongle could not connect to network. Moreover during connect attempts z2m reported some strange errors and then didn't work properly and had to be restarted after each attempt.
• instead I joined the dongle to network using router mode in ember-zli.
• after that z3gateway was connecting to network directly after starting the app.
• on the OTA wiki page the command plugin ota-server notify 0x1234 1 3 100 0x1286 0 5 has a typo, the last parameter should be 2 (firmware version).
• it helped a lot to have zbminir2 connected to PC via serial. Mini prints many useful messages especially during OTA attempts.
• after receiving OTA-command mini searched for OTA-server, found my main coordinator and reported "no updates available".
• after stopping z2m the OTA-command worked better: mini was connecting to the second dongle and OTA process started successfully.
• further OTA-updates worked even with running z2m though.
• update via z3gateway app takes 10 minutes which is about two times faster than doing OTA updates on (regular) zbminir2 in z2m.

[ius]

Thanks again for the extensive feedback!

BTW, simplicity_commander.nix needed to be updated too to reflect version bump on their server.

Shrug I was hoping they'd only update it along with the SDK - guess not. It's a bit problematic that they don't publish versioned releases - others seem to be annoyed by it as well. Either I'll need to update it every time that happens, or decide to rehost their binaries myself..

after receiving OTA-command mini searched for OTA-server, found my main coordinator and reported "no updates available".

Hmm, yeah, the spec says:

Since Match descriptor request MAY be sent as unicast or broadcast, the client MAY get multiple responses if there are more than one server in the network. The client SHALL use the first response received.

So far I didn't run into any issues, but I guess it explains your trouble. Will document how to form a network

on the OTA wiki page the command plugin ota-server notify 0x1234 1 3 100 0x1286 0 5 has a typo, the last parameter should be 2 (firmware version).

In practice it seems the Silabs stack doesn't care about the version in the update notify - it always responds with a QueryNextImageRequest.

update via z3gateway app takes 10 minutes which is about two times faster than doing OTA updates on (regular) zbminir2 in z2m.

Interesting difference...

As for the ZBDongle-E related points, I guess there are so many (current) incompatibilities that it makes sense to just recommend getting a €10 ZB-GW04 until the SDK incompatibility is resolved.

[bobo-cher]

I've discovered a strange behaviour of my unit and wonder if you can reproduce this with yours.
With the external switch on (S1 connected to S2) disconnect mini from power source. Mini sends toggle command (and light switches on or off). I can reproduce this 100% with any power source: main 240v, powered from J-link or from USB-Serial.

I've tried to reproduce this with a regular mini. I was monitoring z2m log looking for toggle message. There are no message on power loss. What I'd like to know: is the problem specific to my unit and it would also happen with regular firmware on this unit or is Sonoff doing something in their firmware to prevent sending of commands during power shutdown?

I cannot of course flash the original firmware to make a test but I can flash the second unit which I tested with regular firmware and check if I can reproduce the issue there.

[ius]

It's not specific to your unit, I can reproduce it.

Maybe enabling the brownout detectors helps - I recall that enabling flash protection (as SONOFF has done) also hard-enables some brownout detectors. I tried fiddling around, but it doesn't seem to do much - perhaps I'm missing something (ie. what about EMU_IEN?)

void __attribute__((optimize("O0"))) app_init(void)
 {
  EMU->DECBOD |= EMU_DECBOD_DECBODEN;
  EMU->BOD3SENSE |= (EMU_BOD3SENSE_AVDDBODEN | EMU_BOD3SENSE_IOVDD0BODEN | EMU_BOD3SENSE_IOVDD1BODEN);
  EMU->RSTCTRL |= (EMU_RSTCTRL_IOVDD0BODRMODE | EMU_RSTCTRL_AVDDBODRMODE);
 }

Otherwise I don't really know how to solve it.

[ius]

A hack/workaround: introduce a delay in switch_event_handler:

sl_sleeptimer_delay_millisecond(50);

[bobo-cher]

sl_sleeptimer_delay_millisecond(50);

That fixed the issue. Great!

We want the latency as small as possible. Therefore I've tried different delays. 20ms works for me (10ms doesn't). I wonder if the minimum working delay is different for different units. Have you tried 20ms with yours?

Tested on main power (240v) and powered by J-Link. Works consistently correct now.