[REQUEST] EmberZNet 6.8.0 (6.8 / 6.8.x / 6.8.x.x) NCP application firmware for EFR32 in Sonoff ZBBridge

[Hedda]

Have you looked for this feature in other issues and in the docs?

Yes

Is your feature request related to a problem? Please describe.

No related problem. This is only a feature request for a new EFR32 Zigbee firmware release that tasmota-zbbridge depends on.

Describe the solution you'd like

EmberZNet 6.8 (6.8.x) NCP application compiled firmware image as optional download for Sonoff ZBBridge (tasmota-zbbridge).

That is, release and support newer pre-compiled SiLabs EmberZNet 6.8.x.x (and later) firmware images for tasmota-zbbridge.

I believe that 6.8.0.1 is currently the latest firmware.

Silicon Labs EmberZNet SDK version 6.8.0 (6.8.0.2) was released this summer so it is new but not quite cutting-edge any more.

Might be nice for developers and users to have the option to also try the latest and greatest firmware available from SiLabs ;)

Describe alternatives you've considered

The alternative is for users to use "older" EmberZNet 6.6.x, 6.6.x, or 6.7.x firmware on the EFR32 MG21 chip in Sonoff ZBBridge.

Additional context

@s-hadinger @Jason2866 @mtx512 @grobasoz supplied EmberZNet 6.7.x (6.7) or 6.5.x (6.5) EFR32 firmware for ZigbeeBridge:

https://github.com/arendst/Tasmota/tree/development/tools/fw_zbbridge

https://github.com/mtx512/efr32

https://github.com/grobasoz/zigbee-firmware

Please note that release notes say that EmberZNet PRO stack version 6.8.x requires latest Simplicity Studio 5 (SSv5) which is new:

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.8.0.2.pdf

https://www.silabs.com/documents/public/quick-start-guides/qsg106-efr32-zigbee-pro.pdf

Major new Zigbee feature in EmberZNet 6.8 and later is support for concurrent multiple PANs (multi-PAN) on one coordinator:

https://www.silabs.com/documents/public/application-notes/an724-multi-network.pdf

There is also support for "Dynamic Multiprotocol Development with Bluetooth and Zigbee" which might not be as interesting.

https://www.silabs.com/documents/public/application-notes/an1133-dynamic-multiprotocol-bluetooth-zigbee.pdf

Keywords: Sonoff ZBBridge ZB Bridge Ember ZNet 6.8 Zigbee Stack EFR32 EFR32MG EFR32MG2 EFR32MG21 EZSP FW images.

[Hedda]

@MattWestb this might also be of interest for your DIY "IKEA Billy EZSP" Zigbee bridge based on IKEA TRÅDFRI ICC-A-1 module?

https://github.com/MattWestb/IKEA-TRADFRI-ICC-A-1-Module

(Tasmota zbbridge firmware on an ESP8266 connected to a IKEA TRADFRI ICC-A-1 module using same pins as Sonoff ZBBridge).

[s-hadinger]

From a Z2T point of view there will be no benefit. There is no plan for multi-PAN support. Also we need a signed firmware by Sonoff key, which is beyond our control.

So happy to upgrade to 6.8 if you find a signed firmware but I doubt users will see any difference when using Tasmota.

[Hedda]

Also we need a signed firmware by Sonoff key, which is beyond our control.

So happy to upgrade to 6.8 if you find a signed firmware but I doubt users will see any difference when using Tasmota.

Do you or anyone else know who signed the firmware images that you provide today with Sonoff key?

https://github.com/arendst/Tasmota/tree/development/tools/fw_zbbridge

[MattWestb]

@Hedda read the original Z2T thread and you is finding how we was getting the signed firmware.
I agree with Stephan its no impotent things that giving the user functions in Z2T but if you like you can doing one request as we was doing but if Tasmota is supporting the firmware is one other thing.

[ascillato2]

From a Z2T point of view there will be no benefit. There is no plan for multi-PAN support.

Ok. Closing issue.

[Hedda]

@s-hadinger As I understand it, there would also be no downside with Z2T using the newer 6.8 versions as it works with EZSP v8.

Should be noted that the new EmberZNet 6.8.x.x firmware also contains bug-fixes and will have a longer life-cycle than 6.6 or 6.7

Meaning that EmberZNet 6.8.x.x firmware should be more future-proof as it will officially be supported longer by Silicon Labs.

[xsp1989]

https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/SM-011/ncp-uart-sw-6.8.0.1_115200.ota
6.8.0.1 NCP application firmware for EFR32 in Sonoff ZBBridge

[Hedda]

https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/SM-011/ncp-uart-sw-6.8.0.1_115200.ota
6.8.0.1 NCP application firmware for EFR32 in Sonoff ZBBridge

Nice! Has that already been signed with ITead key to that it should work with Sonoff ZBBridge and Tasmota zbbridge Z2T now?

If so then maybe you could then submit that file as a pull request to /arendst/Tasmota/tree/development/tools/fw_zbbridge ?

https://github.com/arendst/Tasmota/tree/development/tools/fw_zbbridge

[Jason2866]

Dont use the 6.8.0.1 firmware at the moment. Tasmota Zbbridge needs a little adaption to work with.
s-hadinger already knows and we tested already a quick fix (not good for release since it is not backward compatible).
So soon there will a zbbridge version with support for.

[bogorad]

So soon there will a zbbridge version with support for.

Sorry to bother, but is there any news on that front? The bug with lost sensors after 24-48 hour blackouts is killing me :(

There's a new version BTW

https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/SM-011/ncp-uart-sw-6.8.2.0_115200.ota

[s-hadinger]

After initial tests 6.8.0.1 had lots of issues. There is no definite plan to support 6.8.2 in the short term unless it solves known issues or has interesting new features.

If ain't broke don't fix it.

6.7.6 is very reliable for now. I get some restarts that I need to investigate.

[bogorad]

6.7.6 is very reliable for now. I get some restarts that I need to investigate.

I'm still losing about half the paired sensors after extended (24hr+) power-downs :( Was hoping the new version would fix that.

[s-hadinger]

@bogorad This is unfortunate. What are you powering down? Coordinator? Devices?

There are mechanisms in ZB3 to forget old devices, but 24h seems too short. And even though, the device would do an automatic rejoin.

Another explanation would be that a device was attached to the router and the router is down. Normally the device would pick another router after some amount of time, but some device like Aqara are known to never change router. In that case they need a re-pair.

I'm afraid that the only way to know what is happening is to use a Zigbee sniffer.

[bogorad]

What are you powering down? Coordinator? Devices?

I'm powering down coordinators (e.g. for sending to a friend). No routers involved in this configuration. If I also remove batteries from the devices, the chances are better (I think).

I'll get a sniffer then :)

[MattWestb]

Then power down the coordinator for longer time and not having any router in the mesh then all the end device cannot communicating with network because its not present (silent don't getting any answers then trying communicating). The edn device is thinking they have being removed and backing out the network. If you is having one or more routers then the end devices can still living in the network then the coordinator is offline without backing out of it (best having the end devices connected thru routes but not easy getting to do that).

Add one bulbs or something that is acting as router in the network that is not having large routing problems (so not old OSRAM plugs and so on) and your sensors is not permanently leaving the network the your coordinator is off line.

[bogorad]

Thanks, but bulbs won't help when transporting stuff (e.g. sending to a friend). So effectively the end-user has to do re-pairing :(

[MattWestb]

OK You is sending the complete system.
My experience with Xiaomi sensors is that they don't like being off line to long and also then changing batteries they need being prepared (the same have starting happening with IKEA controller devices).

I think more modern transport like teleporting its the best way solving the problem ;-))))

Serius: Buying one IKEA signal repeater paring it and then transporting the system letting the end device with the battery in and power the repeater with one power bank so the end device ain't losing the contact to the network may working as the end devices always can finding the network then the repeater is still living.

[bogorad]

Serius: Buying one IKEA signal repeater paring it and then transporting the system letting the end device with the battery in and power the repeater with one power bank so the end device ain't losing the contact to the network may working as the end devices always can finding the network then the repeater is still living.

That's very clever, thank you!

[MattWestb]

Cand being worth trying if being on the move with hole or parts of one "living" network.

Interesting to see how / if its working !!

[Hedda]

FYI, EmberZNet SDK 6.8.2.0 GA (General Availability) was released on October 14th of 2020 as a bug-fix release to 6.8.0.1 / 6.8.0.2

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.8.2.0.pdf

zigpy's bellows developers are testing that version in Home Assistant's ZHA integration with Elelabs ELU013 and ELR023 adapters:

https://github.com/zha-ng/EZSP-Firmware/tree/master/Elelabs-ELU013

New APIs

Added in release 6.8.2.0

Added slx_zigbee_routing_set_route_record_policy() to select the conditions under which a node will send a route record to the
concentrator. Note that only the default policy of ROUTE_RECORD_POLICY_ACK_BY_SOURCE_ROUTED_MESSAGE is Zigbee-compliant.

Fixed Issues

Fixed in release 6.8.2.0

ID # + Description

• 345167 Sleepy end devices occasionally do not send APS ACK for received APS unicasts polled from parent: This issue was unrelated to the SDK, rather was rooted in the reporter’s application.
• 519911 In alignment with Zigbee Alliance’s "RF Performance Test Plan & Specification Version 1.0" (19-01701-00), the StandardizedRfTesting sample application's CLI parsing of the "custom lsetpower" and "custom rsetpower" commands is changed to account for mode arguments that precede the power argument, and to treat the power argument as a signed 8-bit value.
• 520432 ZCL Diagnostics cluster implementation (diagnostic-server plugin) no longer attempts to update the value of an optional cluster attribute that is not implemented, and thus no longer prints a debug error message when such an attempt fails.
• 620185 emberResetRejoiningNeighborsFC(bool reset) functionality has been extended to gate resetting the joiner's incoming frame counter when the transport key is passed to the joiner (i.e. the joiner has been accepted by the Trust Center). Default setting remains "FALSE" to ensure interoperability with legacy devices.
• 622524 Apps built for BRD4166A will now default to software flow control mode.
• 623079 The "emberChildCount" API is now multi-network-aware. Users can call "emberChildCount" as before, whether or not it is multi-network-enabled.
• 627883 Stopped sending unsolicited network update responses to the network manager when multiple TX failures are detected.
• 623646 Multi-PAN SPI NCP builds correctly and can communicate with the host app.
• 634372 NCP Framework now provides alpha support for selection of the following targets:
  • MGM210L022JIF (and BRD4309A)
  • MGM210L022JNF
  • MGM210LA22JIF (and BRD4309B)
  • MGM210LA22JNF
• 635430 Fixed a corrupted message being detected as an address conflict in rare circumstances.