search

Koenkk / zigbee-herdsman

A Node.js Zigbee library
MIT License
456 stars 277 forks source link

[WIP]: EFR32 EmberZNet EZSP adapter #317

Closed kirovilya closed 3 years ago

kirovilya commented 3 years ago

The adapter is designed to work with EFR32 chips using the EmberZNet v8 protocol. Recommended firmware NCP 6.7.8.

The work with devices with such chips was tested:

Settings:

Worked:

TODO:

I urge the developers to participate in the finalization of the adapter. I'm not an expert in TypeScript and EmberZNet, so I ask for help.

p.s. Special thanks to @G1K for help with development

MattWestb commented 3 years ago

For compatible radio adapter with EZSP version 6.7.8.0 i have doing one matrix showing wot we have getting working and pending and no respond on request for updating coordinator firmware (= No interest from devs). https://github.com/zigpy/zigpy/discussions/636#discussion-1925478

EZSP version 6.7.0.0 is the lowest working with protocol version 8 so if you is having 6.5.1.0 its not working with this implantation !!

Our (ZHA) firmware cooker is for the moment NOT recommending higher then versions of EZSP 6.7.8.0 then some critical bugs ("The Sonoff bug") is not fixed and new is implanted in the 6.8 and 6.9 branch.

Great work done devs and hop more great thing is coming soon !!!

kirovilya commented 3 years ago

@MattWestb Great, thanks for the info! I've looked a lot at your Zigpy / Bellows work on EZSP implementation

MattWestb commented 3 years ago

Tasmota is new made and is supporting only protocol version 8 so its easier seeing wot the devs have being doing but bellows is having more functionality implanted and better security implanted.

Keep coding well so we soon can running our EFR32 and EM35X on Z2M !!

Hedda commented 3 years ago

@kirovilya If this adapter specifically use "EmberZNet Serial Protocol" interface (similarly to bellows for zigpy) then suggest that you call the zigbee-herdsman adapter for "EZSP" instead of calling the adapter for "EmberZNet" to prevent possible future confusion?

The reason for that is that "EmberZNet" is also the generic name for the Zigbee stack from Silicon Labs and a developer could technically create an EmberZNet application firmware for Silabs hardware that has another API or CLI interface that is not EZSP.

In fact, Telegesis ETRX3 series modules are based on Silabs hardware with EmberZNet application firmware but have an AT-command interface instead as standard, (though they can be flash with alternative firmware that features the EZSP interface).

https://www.silabs.com/wireless/zigbee/telegesis-legacy-modules

https://www.silabs.com/documents/public/reference-manuals/TG-ETRXn-Commands.pdf

https://www.silabs.com/documents/public/data-sheets/TG-PM-0516-ETRX35x.pdf

PS: @grobasoz also mentioned that he has been thinking about creating an EmberZNet application firmware for Silabs hardware that would be compatible with standard ZNP API interface so even could use the (unmodified) z-stack adapter for zigbee-herdsman

kirovilya commented 3 years ago

@Hedda I named the adapter is "EZSP", just in the title of this PR I indicated EmberZNet. I can rename the title of PR if necessary :) I think this is not critical

MattWestb commented 3 years ago

Then in implantation is only supporting EZSP v8 and not older version of EmberZNet i thik its one god working name and also as "end name" and the devs dont have any intention to supporting old "AT firmware" and the firmware requirements is already being sett = the same as "ZHA EZSP PRO".

Hedda commented 3 years ago

For compatible radio adapter with EZSP version 6.7.8.0 i have doing one matrix showing wot we have getting working and pending and no respond on request for updating coordinator firmware (= No interest from devs). zigpy/zigpy#636 (comment)

Direct link to the wiki page where @MattWestb documented recommended application firmware version for EZSP Coordinators:

https://github.com/zigpy/zigpy/wiki/Coordinator-Firmware-Updates#recommended-firmware-version-for-ezsp-coordinators

Perhaps also good to mention that @walthowd created a docker image that can help upgrade firmware on most EFR32 hardware:

https://github.com/walthowd/husbzb-firmware

That include but isn't exclusive to the popular but no longer manufactured Nortek GoControl QuickStick Combo Model HUSBZB-1

Hedda commented 3 years ago

Then in implantation is only supporting EZSP v8 and not older version of EmberZNet i thik its one god working name and also as "end name" and the devs dont have any intention to supporting old "AT firmware" and the firmware requirements is already being sett = the same as "ZHA EZSP PRO".

Bellows also started out only supporting a single specific version of EZSP but it was later extended to support more versions.

So while this new adapter will start out only supporting EZSP v8 it could maybe be extended by someone else in the future, though that effort might not be worth it in the end. Perhaps most important to know today is that EZSP v5, v6 and v7 (EmberZNet 6.6.x.x) use the same framing format, but EmberZNet 6.7.x.x/EZSP v8 introduced new framing format and expanded command id field from 8 bits to 16 bits.

digiblur commented 3 years ago

Awesome work! Looking forward to checking this out. I do have this one to also try out for testing from iTead - image

digiblur commented 3 years ago

@kirovilya I'll definitely be keeping an eye on this and see where I can help out, the previous bounty offer still stands in my book.

Hedda commented 3 years ago

Another item for TODO could be "ZGP (Zigbee Green Power)" support for EmberZNet/EZSP adapter:

https://www.silabs.com/documents/public/user-guides/ug392-using-sl-green-power-with-ezp.pdf

https://www.silabs.com/documents/public/user-guides/ug103-15-green-power-fundamentals.pdf

By the way, @G1K also has "GreenPower support and 242 endpoint" on his ZiGate roadmap in https://github.com/Koenkk/zigbee-herdsman/issues/242

kirovilya commented 3 years ago

@digiblur :) ok, thanks @Hedda added

kirovilya commented 3 years ago

Now, you can try to test it in dev-version of z2m

digiblur commented 3 years ago

Paired up a Sonoff Zigbee Mini switch with the Sonoff Zigbee Bridge and was able to turn it on and off.

digiblur commented 3 years ago

Weird... I tried to remove it from the bridge, then changed my dev container to the USB dongle and it starts up but failed on pairing 2 devices. I switched back to the bridge and it fails as well. I'll have to investigate later when I have more time to fool with it.

digiblur commented 3 years ago

Fiddling and messing with it, got the bridge working again after dumped all the settings. I'll see if I can get the stick working again, I want to see if one mains and one battery powered will stay alive for a bit.

digiblur commented 3 years ago

Works on the MG21 based Zigbee Dongle 3.0. Nice job! Definitely some issues with the devices hanging on between networks, changing the network keys fixes that when I switch adapters and pair stuff again. It's showing 6.7.8.0 build 373

kirovilya commented 3 years ago

made a separate issue for further improvements, cause this PR is already merged https://github.com/Koenkk/zigbee-herdsman/issues/319

Arkdor commented 3 years ago

Hi, i have Sonoff ZbBridge flashed with Tasmota how can I add it to Zigbee2MQTT? I setup port to 192.168.1.7:8888 and it cannot connect.

kirovilya commented 3 years ago

@Arkdor did you setup dev-branch of z2m? In configuration set adapter to ezsp?

Arkdor commented 3 years ago

Im using edge version in homeassistant, adapter set to ezsp. In zha port connection looks like this: socket://192.168.1.7:8888, how should it look in z2m?

digiblur commented 3 years ago

Im using edge version in homeassistant, adapter set to ezsp. In zha port connection looks like this: socket://192.168.1.7:8888, how should it look in z2m?

https://www.digiblur.com/2021/03/zigbee2mqtt-with-sonoff-zigbee-bridge.html

Hedda commented 3 years ago

Im using edge version in homeassistant, adapter set to ezsp. In zha port connection looks like this: socket://192.168.1.7:8888, how should it look in z2m?

https://www.digiblur.com/2021/03/zigbee2mqtt-with-sonoff-zigbee-bridge.html

Note! EmberZNet USB Zigbee adapters/dongles/sticks are highly recommended instead of using a remotely connected Ember module over a serial-to-ip bridge / serial forwarding server like ser2net, but if you still insist on using a remotely connected Ember module over a serial-to-ip bridge then the recommendation is to use a bridge model that features wired Ethernet instead of WiFi.

Regardless, please only use USB Zigbee adapters/dongles/sticks for EZSP if you are developing/testing this EZSP adapter in Zigbee2MQTT or IoBroker, because the ESZP protocol is known to be unstable over WiFi when using Serial-over-IP connection it so is not a good idea to use WiFi based solution such as the Sonoff ZBBridge from ITead when developing/testing this EZSP adapter in Zigbee2MQTT or IoBroker now. Such a serial-over-IP connection over WiFi is infamous for not giving a stable connection for production or troubleshooting. Compound this with the fact that the EZSP adapter implementation in zigbee-herdsman being brand new so very unmatured and it will guarantee to give the developers bug-reports with a lot of false positives of errors that will be due to the user's WiFi setup and/or unstable Serial-over-IP connections.

FYI, Home Assistant ZHA and zigpy developers are now strongly recommending not to use any WiFi based EZSP bridges/gateways.

https://github.com/zigpy/bellows#warning-about-zigbee-to-wifi-bridges

https://www.home-assistant.io/integrations/zha/

The reason Ember remote bridges over serial-to-IP proxy server is not recommended is that clients using the EZSP serial protocol requires a robust connection between the EmberZNet Zigbee stack running on EFR32 MCU and the serial port of the Zigbee radio. With solutions such as ITEAD Sonoff ZBBridge or a Ser2Net serial proxy connection over a WiFi network it is expected to see NCP entered failed state. Requesting APP controller restart in the logs. This is a normal part of the operation and indicates there was a drop in communication which caused packet loss to occurred between the zigpy radio library and the Zigbee radio. The use of serial network proxies/bridges/servers over WiFi is therefore not recommended when wanting a stable Zigbee environment with Silicon Labs Ember based Zigbee radios. The developers of the bellows radio library for the zigpy project has more information about this if needed.

Hedda commented 3 years ago

@Arkdor This pull request has been closed so please instead post in the still open issue for improvement discussions -> https://github.com/Koenkk/zigbee-herdsman/issues/319