search

zigpy / bellows

A Python 3 project to implement EZSP for EmberZNet devices
GNU General Public License v3.0
177 stars 87 forks source link

[REQUEST] Support for Silicon Labs EFR32 (Mighty Gecko family) based Zigbee radio adapters using newer EZSP serial protocol? #243

Closed Hedda closed 3 years ago

Hedda commented 4 years ago

Can the bellows library be made to support newer EZSP serial protocol such as EZSP v6, v7, and v8 when used with ZNet 6.x on Silicon Labs EFR32 (Mighty Gecko family) based Zigbee radio adapters?

See ex. #242 as that hardware is based on this same family and series of chips from Silicon Labs.

Zigbee EmberZNet version 6.7.0.0 has breaking change (with EZSP Protocol Version 8 and Secure EZSP Protocol Version 2) as both EZSP and Secure EZSP have adopted a new frame format with the following changes: (1) the fields of "Frame Control" and "Frame ID" are now two bytes; (2) no longer use "Legacy Frame ID"; (3) consume two bits of "Frame Control" to indicate the frame format version which is version 1 now.

Perhaps newer modules will dethrone Nortek HUSBZB-1 for ZHA as the must-have Zigbee adapter?

Hedda commented 4 years ago

Maybe someone can test EFR32MG12 based E180-ZG120B module from Ebyte works with bellows?

Ebyte makes an inexpensive development board called "E180-ZG120B-TB" for testing E180-ZG120B

This Zigbee 3.0 capable module has some very powerful MCU and radio specifications for its price:

This development is sold by cdebyte for less than $9 US-dollar on Aliexpress or about twice on eBay:

You can also buy them on bulk from Alibaba for less:

Looks like you can remove some jumpers to disable the USB converter if want to use serial directly.

E180-ZG120B by Chengdu Ebyte (CDEYTE) has 20 dBM powerful Zigbee 3.0 radio for 2.4GHz capable based on an EFR32MG1 Series 1 MCU SoC / chip, specifically EFR32MG1B (IC = EFR32MG1B232F256GM48), from Silicon Labs EFR32 ("Mighty Gecko") family.

EFR32MG1B232F256GM48 includes a 40 MHz ARM Cortex-M4 microcontroller with 256 Flash, 32 RAM and a rich peripheral set in a QFN48 package. With 19.5 dBm maximum output power and receive sensitivity of -101 dBm (250 kbps O-QPSK DSSS). Key Specs: 19.5 Output Power Max (dBm) / 120.5 Total Link Budget (dB).

I understand this also is classified as an Ember based radios using the EZSP (EmberZNet Serial Protocol) serial protocol (UART bus) interface so could therefore be made compatible with the bellows library for zigpy if the E180-ZG120B module is flashed with the right firmware?

I guess that my follow-up question will be which exact firmware to use on the E180-ZG120B module?

Ebyte is now making two EFR32MG1B based modules called E180-ZG120A and E180-ZG120B

E180-ZG120B (and old E180-ZG120A) module is sold by cdebyte on eBay and Aliexpress at low prices.

Example:

Hedda commented 4 years ago

Silicon Labs also has an official devkit called "EFR32 Mighty Gecko Wireless Starter Kit", but it cost almost $500 US-dollars ($499 to be precise), however, that kit contains three (3) complete dev boards.

Hedda commented 4 years ago

Z-Smart Systems now has driver code supporting latest Silicon Labs Ember dongles at @zsmartsystems

Adminiuga commented 4 years ago

Does ebyte provide any firmware? I've ordered one we'll see what firmware it comes with. But in later version of EZSP they changed commands id to 16 bit.

Hedda commented 4 years ago

You could try contacting Ebyte / cdebyte (Chengdu Ebyte), however, I believe that the Ebyte module most likely only comes with standalone bootloader firmware preloaded for boot. Such standalone bootloader firmware usually is just enough to allow you to flash and upgrade the main application firmware via USB (without having to use a GPIO port / JTAG connector / debug adapter and Simplicity Studio or J-Link Downloader).

I would think you have to build/compile Zigbee stack (Zigbee EmberZNet) project with coordinator device type config in their SDK or tools ("Simplicity Studio" and "Simplicity Commander") and then flash application bootloader firmware with Zigbee stack yourself, ...but where to get that Zigbee stack and application bootloader firmware I don't know, maybe from a Silicon Labs SDK? As I understand they call protocol such as their Zigbee stack (Zigbee EmberZNet) for "apps".

Think these might be a couple of easier how-to guide for building EmberZNet for EFR32 and EM35x:

I don't own one myself yet but would be nice if could just install and start their latest SDK or tools ("Simplicity Studio" and "Simplicity Commander") and it would detect the hardware once it is plugged in to then start a new project.

Guessing that you first might need to register a serial number to your account for full SDK access, or at least register a dev kit part-number to your account, like for the official "EFR32 Mighty Gecko Wireless Starter Kit" (that kit part number is "SLWSTK6000B") as the dev board in that dev kit is kind similar to the Ebyte dev board as they both use the same type of chip from Silicon Labs .

Simplicity Studio

Simplicity Commander

Silicon Labs has its community knowledge-base here:

https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base

Silicon Labs also have different user forums here:

Silicon Labs IoT also has a community on Slack:

https://silabsiot.slack.com/

Silicon Labs IoT also has a community on Gitter:

https://gitter.im/Silabs-IoT

@cdjackson from @zsmartsystems also mention two main NCP images in their README.md

Perhaps he would be willing to hint where to get the correct Zigbee coordinator firmware for EFR32?

@cdjackson also keep adding new EZSP support from UG100 to com.zsmartsystems.zigbee

Hedda commented 4 years ago

@sprut666666 as mentioned in https://github.com/zigpy/bellows/issues/242 is also working on similar EFR32MG1 based adapter for @sprut

Adminiuga commented 4 years ago

So it boils down to getting Silicon Labs SDK which you only get with their dev-kit. But once you get SDK you can also get new image for the same chip as on HUSBZB-1 stick.

Adminiuga commented 4 years ago

There're three dev boards in the mighty Gecko Silicon labs devkit. Just need to find two more volunteers willing to shell out $166 + taxes for a dev board and access to SDK which would allow to upgrade HUSBZB-1 to the latest emberznet.

Hedda commented 4 years ago

Yes same SDK, but I don't think that you can use the latest EmberZNet Zigbee Stack on older hardware.

That is, you can't upgrade EM35x based dongle with a Zigbee 3.0 stack, only latest Zigbee PRO stack. To run the latest EmberZNet Zigbee Stack with Zigbee 3.0 support you need EFR32 hardware.

Anyway, some posts on their forum hint that you don't need a dev kit serial number for the SDK:

You might only need to enter the kit part number for the official "EFR32 Mighty Gecko Wireless Starter Kit", and that kit part number is "SLWSTK6000B" (as it is kind of a similar development board with the same type of chip) and then just click a checkbox to accept the license agreement.

Then once someone has created hex/bin files with EmberZNet firmware then anyone can flash them themselves (I understand that is already done to get Telegesis ETRX3 adapters to work with bellows).

Adminiuga commented 4 years ago

not sure if we're reading the same posts, but those do tell you have to have access to dev-kit serial number https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2017/11/22/access_to_siliconla-jk1S

Hedda commented 4 years ago

not sure if we're reading the same posts, but those do tell you have to have access to dev-kit serial number https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2017/11/22/access_to_siliconla-jk1S

Note that the original post there was posted more than two years ago so might have changed.

sslin (Employee) teplied Feb 21 2019, 2:40 AM in that thread with this:

Simplicity Studio is free to download and use even if you don't buy any kits.

JTAG driver will be installed automatically when you install the Simplicity Studio.

Some sdks/stack are free to download within the Simplicity Studio like Bluetooth, Flex, MCU, etc ...

With the serial number you got from the Mesh starter kit, you will be granted the access right to Zigbee and Thread for life long.

cdjackson commented 4 years ago

The HUSBZB does not contain a bootloader so cannot be updated.

Adminiuga commented 4 years ago

Some sdks/stack are free to download within the Simplicity Studio like Bluetooth, Flex, MCU, etc .

Well, that might be true (for those stacks), but last time I've looked Emberznet stack was not accessible without a kit.

The HUSBZB does not contain a bootloader so cannot be updated

You send it a bootloader frame and it enters into bootload mode and you can upload .ebl image using xmodem.

Adminiuga commented 4 years ago

from HUSBZB in bootloader

EM3581 Serial Bootloader v5.4.1.0 b962                                       
1. upload ebl                                                                
2. run                                                                       
3. ebl info                                                                  
BL >
cdjackson commented 4 years ago

You send it a bootloader frame and it enters into bootload mode and you can upload .ebl image using xmodem.

Really? Have you tried this? For the HUSBs that I've looked they have not shown a bootloader being installed.

Adminiuga commented 4 years ago

send it launchStandaloneBootloader() EZSP command and afterwards connect to it with a serial terminal (might need different baudrate, i don't remember the details) It did enter the boot loader mode

image

cdjackson commented 4 years ago

Sure - I’m very familiar with the protocols and have supported many companies with implementing Silabs systems. I don’t personally have one of these devices as I’m in Europe so there’s little point here, but I’ve had someone else test this and it didn’t work - maybe there was a problem with that device or maybe not all support the boot loader (or maybe the previous person to test this didn’t test it well).

Adminiuga commented 4 years ago

I think it is might be up to the vendor to include boot loader into image, but both of Nortek GoControl HUSBZB-1 sticks in my possession respond to launchStandaloneBootloader command and were ready to accept .ebl image.

cdjackson commented 4 years ago

Does it respond to getStandaloneBootloaderVersionPlatMicroPhy?

Adminiuga commented 4 years ago 
debug: Send command getStandaloneBootloaderVersionPlatMicroPhy: ()
debug: Sending: b'2240215754bbef5f7e'
debug: Data frame: b'2340a15754bb05e65d9e49e6697e'
debug: Sending: b'83401b7e'
debug: Application frame 145 (getStandaloneBootloaderVersionPlatMicroPhy) received: b'1054040a03'
[21520, 4, 10, 3]
debug: Closed serial connection

it does.

cdjackson commented 4 years ago

Thanks. I might need to try and get hold of one to create a new firmware and try this.

Adminiuga commented 4 years ago

Just to make it a bit easier https://github.com/zigpy/bellows/pull/249

Hedda commented 4 years ago

There are otherwise plenty of instructions out there on how to flash Telegesis ETRX357 USB dongles, as you can't use them with bellows until you have first flashed them with other EmberZNet firmware, see:

https://github.com/zigpy/bellows/blob/dev/README.md

https://community.home-assistant.io/t/eu-usb-sticks-for-the-new-zigbee-component/16718/10

Quote bellow originally posted by Frank Aug '17 in linked thread:

I can confirm that the ETRX357USB-LRS+8M can be flashed with an appropriate EZSP firmware without the use of any programming hardware.

So, without any guarantees (you might -but probably won’t- brick your device), here’s how:

Download the firmware. I used some random blob someone put on github that at least seemed to have the right name. What could possibly go wrong, right? :smile: https://github.com/yqyunjie/Zigbee-Project/blob/master/firmware/EmberZNet/EM35x-EZSP/build/em35x-ezsp-images/EM357/em357-ncp-uart-xon-xoff-use-with-serial-uart-bl-500.ebl?raw=true 282

(Install USB-to-serial drivers for the device. Linux will load the driver automatically when you plug in; not sure about other OSes.)

Install a serial port communication app that supports X-MODEM. (debian/ubuntu: sudo apt-get install minicom) Run it and configure it (sudo minicom -s) to use the fake serial port (/dev/ttyUSB0) at 19200 baud 8N1. Disable both hardware (RTS/CTS) and software (XON/XOFF) flow control.

Type ‘AT’ , you should get OK in response. Now type ‘AT+BLOAD’ . The device will reboot into the bootloader.

Change the baud rate in the serial port communication app setting to 115200 baud. (exit minicom using CTRL-A Q, run ‘sudo minicom -s’ again)

Pressing enter in the terminal should now show you a three-option boot loader menu. Choose option 1.

‘C’ characters will start showing. Don’t wait for this to finish, but start an X-MODEM upload of the firmware you downloaded earlier (use CTRL-A S in minicom). You have 60 seconds to start the upload.

After the upload finished, you should return to the menu. Now select option 2, to reboot into the new firmware. You’re done.

Enjoy!

Hedda commented 4 years ago

Think these might finally a couple of easier how-to guide for building EmberZNet for EFR32 and EM35x:

It does however do sound as if you need to register EFR32MG development kit with a serial number to get a logon, but once you have you are allowed to reuse it within the same organization or company.

Could be worth it for you to try to contact Silicon Labs Salesforce and explain that you would like a logon for an open-source organization/project without owning a dev kit, as an "organization" is a loose term, zigpy is technically an organization.

After all, projects like zigpy does help Silicon Labs sell chips. Guess that the answer might differ depending on how Silabs feelings are towards helping open-source projects which are not-for-profit.

@Adminiuga Another suggestion could be for you & @dmulcahey to ask if maybe Home Assistant core team would be willing to sponsor you ZHA devs with an official EFR32MG development kit.

Again it sounds as if you would only need one login for "team zigpy" and then several people on "team zigpy" would be allowed to use that same login with Simplicity Studio and other Silicon Labs software.

Hedda commented 4 years ago

I think it is might be up to the vendor to include boot loader into image

Guess they might sometimes recommend disabling bootloader to prevent any firmware upgrades.

Here are otherwise some Silicon Labs recommendations for building firmware images for production:

kpszupin (Employee) originally posted 12/29/2017 but it has probably updated since then:

Some recommendations when building firmware images for production:

  1. Build a single manufacturing hex file for each device with bootloader, application image, flash protection patches, and any tokens.
  2. Enable write protection on the bootloader flash area (0-0x4000) by clearing the lower eight bits of the first byte in the lock bits page (0x0fe04000). Each bit represents 2KB of flash, so 8 bits represents 16KB total for the standard bootloader: --patch 0x0fe04000:0x00
  3. Disable the debug port on the EFR32 by clearing the four LSBs of the DLW register in the lock bits page. This prevents debugger access from reading/writing to the device. Debug access can only be gained again by erasing the device. --patch 0x0fe041FC:0xF0
  4. Program the AES/encryption key (if applicable) and the ECDSA public key tokens. These can be in the same token file as any other tokens you are programming. --tokenfile keyfile.txt
  5. Lock the lock bits page on EFR32 by clearing bit 1 of the ULW register in the lock bits page. This is a requirement to secure the AES and ECDSA tokens which reside in the lock bits page. --patch 0x0fe041F8:0xFD

It is possible to combine these patches into a single hex file for manufacturing with a Simplicity Commander command, which can be put into a batch file or post-build script. For example:

commander.exe convert gecko-bootloader.s37 app_image.s37 --patch 0x0fe04000:0x00 --patch 0x0fe041FC:0xF0 --patch 0x0fe041F8:0xFD —tokengroup znet —tokenfile mfg_tokens.txt -o manufacturing_image.hex -d EFR32MG1P233F256GM48

Hedda commented 4 years ago

Another tip is this "Zigbee Boot Camp Course" wiki for Silicon Labs @MarkDing has put on GitHub :

He has also put together this PDF with Silicon Labs ZigBee Onboarding Roadmap for beginners:

Also see

Hedda commented 4 years ago

Slightly off-topic question; but once have EFR32 based adapter with latest EmberZNet Zigbee stack:

Would it be possible for zigpy to form a Zigbee 3.0 network using latest EmberZNet ZigBee Stack?

Currently, as I understand, zigpy & bellows form a Zigbee HA (Zigbee Home Automation) network?

Hedda commented 4 years ago

FYI @SillyDay don't own a E180-ZG120B but has tried to build a firmware for it as per discussion here:

https://github.com/Koenkk/zigbee-herdsman/issues/168

SillyDay GitHub repo for EFR32 firmware:

https://github.com/SillyDay/EFR32

tofurky commented 4 years ago

not quite the latest, but i've obtained the following:

   148224  2018-11-02 13:39   developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/em3581/ncp-uart-rts-cts-use-with-serial-uart-btl-6.4.1.ebl
   146560  2018-11-02 13:39   developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/em3581/ncp-uart-xon-xoff-use-with-serial-uart-btl-6.4.1.ebl
   147904  2018-11-02 13:39   developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/em3581/ncp-uart-sw.ebl
   149632  2018-11-02 13:39   developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/em3581/ncp-uart-hw.ebl

any idea which of these, if sent with xmodem after 'bellows bootloader', would be least likely to brick a perfectly working HUSBZB-1? :-) (EZSP Stack Type: 2, Stack Version: 21520 - "EM3581 Serial Bootloader v5.4.1.0 b962")

btw, i'm fully willing to provide these to anyone who needs them, but am not certain on the best way to go about doing so. i could throw them in a repo? 😬

AFAICT 6.4.1.0 is the last release to include prebuilt NCP firmwares (per https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.4.pdf).

btw, bringing things back to the original topic, also seeing these:

   198592  2018-11-02 13:39   developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/efr32mg12p433f1024gm68-brd4170a-gb868-native/ncp-spi-use-with-ezsp-spi-btl-6.4.1.ebl
   189504  2018-11-02 13:39   developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/efr32mg12p433f1024gm68-brd4170a/ncp-spi-use-with-ezsp-spi-btl-6.4.1.ebl
   182336  2018-11-02 13:39   developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/efr32mg12p433f1024gm68-brd4170a/ncp-uart-rts-cts-use-with-serial-uart-btl-6.4.1.ebl
   191360  2018-11-02 13:39   developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/efr32mg12p433f1024gm68-brd4170a-gb868-native/ncp-uart-rts-cts-use-with-serial-uart-btl-6.4.1.ebl
Adminiuga commented 4 years ago

I'd think either developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/em3581/ncp-uart-sw.ebl or developer/sdks/gecko_sdk_suite/v2.4/protocol/zigbee/ncp-images/em3581/ncp-uart-xon-xoff-use-with-serial-uart-btl-6.4.1.ebl

the HW ones AFAIK use baudrate 115200.

Hedda commented 4 years ago

@tofurky Cool but maybe start a new issue for "HUSBZB-1 firmware upgrade" as that is off-topic here?

Both use EZSP APIs but HUSBZB-1 is based on the older EM358x family, not the newer EFR32 family.

Hedda commented 4 years ago

FYI, @s-hadinger has now got a Sonoff ZBBridge and started reviewing the board in it (for Tasmota)

First signs it is the EFR32 Zigbee module it has inside it has EmberZNet / Ember based firmware.

Hedda commented 4 years ago

There is now also a deep dive follow-up discussion here in parallel about hacking or flashing its EFR32:

s-hadinger commented 4 years ago

Hi, I have the EFR32 on the Sonoff Zigbee bridge flashed with EmberZNet v6.7.6.0 and supporting protocol EZSP v8. I'm struggling to send EZSP frames beyond the first v4 version frame.

I see that bellows send a 0xFF extended frame control when switching to protocol v5, but I can't find any mention of this 0xFF in the v8 documentation (UG100).

Can someone give me a link or a piece of documentation about this value?

Adminiuga commented 4 years ago

v8 changed frame format and expanded command_id to 2 bytes and bellows currently does not support that. In EZSP Reference guide check the protocol format, around page 10

s-hadinger commented 4 years ago

Thanks. I solved my problem as soon, but it needed to specify frame version to 1 in the high control byte.

s-hadinger commented 4 years ago

Btw adding support in bellows may not be a big change. You need to set control bytes to 0001 and extend command to 2 bytes. Still there is no command number greater than 0xFF so adding 00 after the command should do the work.

Adminiuga commented 4 years ago

Haven't looked yet, still waiting for my ebyte modules to show up. Just need to figure a way to switch between the versions, since most will be running on V7, V6 or even V5. And need a way to implement different command sets between the versions, as there were some changes. e.g. I don't see RCE4 frames in the later protocols. Probably would be easier with SDK access to track changes between protocol versions.

Hedda commented 4 years ago

@Adminiuga have you read about @s-hadinger hacking/development progress with Sonoff ZBBridge (Sonoff Zigbee Bridge)?

Interesting for bellows he has now added a TCP serial bridge to Tasmota firmware for remote access:

Description:

Add a new feature: Serial to TCP bridge (similar to esp-link). This allows to remotely communicate to a MCU through ESP8266. Needs #define USE_TCP_BRIDGE

It adds 2 GPIO types: TCP Tx (208) and TCP Rx (209) and can work with hardware or software serial.

Commands:

  • TCPBaudRate <x>: sets the baudrate for serial (only 8N1 mode), min 1200, max 115200 by 1200 increments.
  • TCPStart <port>: listens to port <port>. This features supports 2 parallel TCP connexions, which can be useful if you need a terminal + a specific protocol (like XMODEM). The 3rd connection will disconnect an previous connection. The number of parallel connections is a compile-time option.
  • TCPStart 0 or TCPStart: shuts down the TCP server and disconnects any existing connection.

For security reasons, the TCP bridge is not started at boot, and requires an explicit TCPStart command (can be automated with Rules).

FYI; @mtx512 also builds custom EZSP NCP firmware for Sonoff ZBBridge and other EFR32 devices:

Hedda commented 4 years ago

FYI, apparently all newer IKEA Tradfri light bulbs also all contain an EFR32 MG1 based module which can be desoldered and used as an NCP Zigbee coordinator as well if flashed with a new firmware.

@mtx512 also hosts new EZSP NCP firmware for "icc-a-1" EFR32 MG1 based module which can be disassembled from an IKEA Tradfri bulb and hacked for the same reason, as @basilfx documented.

@MattWestb is documenting how-to flash @mtx512 EZSP firmware on an IKEA Trådfri ICC-A-1 module

Might not be as user-friendly as an Ebyte board but at least IKEA Trådfri light bulbs are easy to find.

MattWestb commented 4 years ago

@s-hadinger @Adminiuga In EmberZNet Changed release 6.7.0.0 to V8 and not longer supporting older versions(" no longer use "Legacy Frame ID""). 6.6.4.0 its the latest that having possibility to going down to older protocols. https://github.com/MattWestb/IKEA-TRADFRI-ICC-A-1-Modul#firmware. Both its in the latest SDK so perhaps @mtx512 can doing one 6.6.4.0 for you s-hadinger.

Hedda commented 4 years ago

Not sure how missed it but apparently Elelabs Zigbee USB adapter and Pi shield is based on EFR32MG1

Elelabs Zigbee Raspberry Pi Shield => https://elelabs.com/products/elelabs-zigbee-shield.html

Elelabs Zigbee USB Adapter => https://elelabs.com/products/elelabs-usb-adapter.html

Credits to @MattWestb who stumbled on this info and posted it in https://github.com/Koenkk/zigbee-herdsman/issues/168

I thought that Elelabs had not published exactly which chip type they were using other than they were from Silicon Labs, so I had no idea that they are based on EFR32 MG1 (EFR32 Mighty Gecko Series 1).

I was sure that Elelabs only marketed those as alternatives Nortek GoControl QuickStick Combo Model HUSBZB-1 if you only want a Zigbee adapter compatible the bellows library as used in the ZHA integration component for Home Assistant. I know that the fact that HUSBZB-1 is not sold outside the United States was the main reason that Elelabs started making those, at least they at first have been targeting Home Assistant's ZHA users, and later also openHAB users.

Regardless Elelabs must only ship with old firmware version(s) with their products since it is compatible with the bellows library out-of-the-box and the fact is that the bellows library is currently only compatible with the older versions of EZSP protocols.

Hedda commented 4 years ago

Probably would be easier with SDK access to track changes between protocol versions.

@Adminiuga Do you think, if you ask, that Home Assistant founders (or Nabu Casa) would sponsor you with $99, $479 or $978 to buy Wireless Gecko Starter Kit(s) from Silabs to get official SDK access?

"EFR32xG21 Wireless Gecko Starter Kit" (article: SLWSTK6006A) with EFR32MG21 radios cost $479 and "EFR32™ Mighty Gecko Wireless Starter Kit" (SLWSTK6000B) with EFR32MG12 cost $499 respectively contains three starter kits and been confirmed to include full access Silicon Labs Zigbee Stack/SDK after register on Silabs. EFR32MG21 is Mightly Gecko Series 2 and EFR32MG12 is Mightly Gecko Series 1.

Silicon Labs recently also released a less expensive $99 "EFR32xG22 Wireless Gecko Starter Kit" (SLWSTK6021A) which only contain one mainboard and low-power Zigbee Green Power compatible Mightly Gecko Series 2 radios but it has not yet been confirmed if that as well includes Zigbee Stack/SDK access or not.

https://www.silabs.com/products/development-tools/wireless/efr32xg22-wireless-starter-kit

The SLWSTK6021A ($99) comes with EFR32MG22 modules so it only EmberZNet 6.7.4.0 or greater.

Anyway, once you bought the kit you just need to register an account with its serial to get access:

Google search shows that relatively inexpensive $99 kit can already be bought from resellers globally.

Hedda commented 4 years ago

It has been confirmed by @jnicolson that buying just that $99 kit does give you full access to Silabs Zigbee stack (he contacted SiLabs support specifically asking this question and got confirmation it does, and he has since already purchased one and now have full access to the Silabs Zigbee stack).

Hedda commented 4 years ago

I'm currently running 6.7.6.0 of EFR32MG21, using protocol v8. The stack is correctly initialized, based on the work from bellows, the network is up and EFR32 is acting as coordinator. But I'm struggling to have devices pairing to the coordinator.

My first attempts showed a tentative of devices (Xiaomi and OSRAM) to pair, and unpairing because of a TC key issue. Now I'm not receiving any message when trying to pair. I'm stuck...

@s-hadinger sorry for cross-posting confusion but did you mean to write quoted to @Adminiuga ?

You posted quoted text in https://github.com/Koenkk/zigbee-herdsman/issues/168 but think you meant to post it here in https://github.com/zigpy/bellows/issues/243

Adminiuga commented 4 years ago

@s-hadinger yeah, I suspect something has changed between the versions. Don't they use EZSP Values now, instead of EZSP Policy IDs ? Need to make sure the commands ID are still correct, as there were changes (commands added/deleted/replaced) between the versions, but bellows most likely still has the V5 command set.

One thing to try: change https://github.com/zigpy/bellows/blob/1dfe9c79ef6daea8aa06c4ddde4cf33f6c863033/bellows/zigbee/application.py#L237 to t.EzspDecisionId.ALLOW_TC_KEY_REQUESTS

s-hadinger commented 4 years ago

Yes, thanks. I'm taking help from where I can.

I'm currently running 6.7.6.0 of EFR32MG21, using protocol v8. The stack is correctly initialized, based on the work from bellows, the network is up and EFR32 is acting as coordinator. But I'm struggling to have devices pairing to the coordinator.

My first attempts showed a tentative of devices (Xiaomi and OSRAM) to pair, and unpairing because of a TC key issue. Now I'm not receiving any message when trying to pair. I'm stuck...

The example I found from bellows called networkInit, I'm calling formNetwork instead after each boot, and I don't believe it makes any difference.

I have tried many different security settings, and tried to mimick the one from bellows:

s-hadinger commented 4 years ago

@Adminiuga The value for EZSP_TC_KEY_REQUEST_POLICY is now EZSP_ALLOW_TC_KEY_REQUEST_AND_GENERATE_NEW_KEY which matches the value for 0x52 GENERATE_NEW_TC_LINK_KEY

The alternative is 0x51 EZSP_ALLOW_TC_KEY_REQUESTS_AND_SEND_CURRENT_KEY

Adminiuga commented 4 years ago

Hrm, without logs hard to say. But if you are not seeing anything, I'd use a zigbee sniffer to see what is going on, at least to see if the device is requesting beacons and beacons are being sent out.

For TC_KEY policy, yes, change it to EZSP_ALLOW_TC_KEY_REQUESTS_AND_SEND_CURRENT_KEY

s-hadinger commented 4 years ago

Argh. I found the problem. I put the same key for preConfiguredKey and networkKey, it does not complain but it makes pairing fail. Now I can try again.

Thanks for your help, I may need it to go further.