Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP]: EFR32 EmberZNet EZSP adapter #317

Merged
merged 63 commits into from
Mar 2, 2021
Merged

Conversation

kirovilya
Copy link
Contributor

@kirovilya kirovilya commented Feb 28, 2021

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:

  • specify port parameter or gateway address
  • set adapter to "ezsp"

Worked:

  • Pairing/Leaving
  • Bind/Unbind
  • ZCL messages/commands
  • Network map

TODO:

  • Improving the stability work of the network
  • Groups
  • Touchlink
  • Backup/Restore
  • OTA update
  • Tests
  • ZGP (Zigbee Green Power)

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
Copy link

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
Copy link
Contributor

Hedda commented Mar 2, 2021

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
Copy link
Contributor

Hedda commented Mar 2, 2021

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
Copy link

digiblur commented Mar 2, 2021

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

@digiblur
Copy link

digiblur commented Mar 2, 2021

@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
Copy link
Contributor

Hedda commented Mar 2, 2021

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 #242

@kirovilya
Copy link
Contributor Author

@digiblur :) ok, thanks
@Hedda added

@kirovilya
Copy link
Contributor Author

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

kirovilya added a commit to ioBroker/ioBroker.zigbee that referenced this pull request Mar 2, 2021
@digiblur
Copy link

digiblur commented Mar 2, 2021

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

@digiblur
Copy link

digiblur commented Mar 2, 2021

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
Copy link

digiblur commented Mar 2, 2021

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
Copy link

digiblur commented Mar 3, 2021

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
Copy link
Contributor Author

made a separate issue for further improvements, cause this PR is already merged #319

@Arkdor
Copy link

Arkdor commented Mar 14, 2021

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
Copy link
Contributor Author

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

@Arkdor
Copy link

Arkdor commented Mar 14, 2021

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
Copy link

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
Copy link
Contributor

Hedda commented Mar 15, 2021

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
Copy link
Contributor

Hedda commented Mar 15, 2021

@Arkdor This pull request has been closed so please instead post in the still open issue for improvement discussions -> #319

Copy link

@Zidane115 Zidane115 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WWE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants