Add support for Zigbee Home Automation #6263
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
homeassistant
added
cla-needed
new-platform
platform: binary_sensor.zha
integration: zha
cla-signed
and removed
cla-needed
labels
|
I'm a bit confused here. We already have a Zigbee component + platforms: https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/zigbee.py |
|
The zigbee component is a "DIY" component. As far as I know, you can't do anything but control or read digital and analog pins on a remote zigbee device. The configuration reflects this. This PR is for "consumer" zigbee devices. I should expand the docs PR to list some example devices, but here's why I'm controlling through ZigBee at the moment:
|
|
I meant to say "control or read digital and analog pins on a remote xbee device" previously. |
|
What zigbee hardware is this supporting? |
|
In terms of the local radio, it should support any EmberZNet device that supports the EZSP protocol. I've been using the GoControl QuickStick Combo (sometimes also called HubZ, model number is HUSBZB-1). ZigBee devices I have tested on the network are:
|
|
Thanks for the clarification. If this implements the EZSP protocol, I suggest we rename this component to |
|
I'm not totally against renaming it. That said, I want to make sure that the understanding about the various protocols etc is clear. EZSP is the protocol between the host (Home Assistant, in this case) and the "Network Co-Processor" (a USB device which contains a ZigBee radio). It implements methods like formNetwork (with parameters like the channel, security keys, etc), permitJoins, sendUnicast (with a destination address, and packet contents) and sendMulticast (similar). You could use an EZSP device to talk to XBee devices using their flavour of ZigBee. bellows is a library which implements the EZSP protocol, and then a ZigBee stack on top of that. In that sense, it really conflates two things. Some of the ZigBee support in it also assumes ZHA (mostly just for expedience). It should be possible to use the ZigBee parts of the bellows stack and just replace how it communicates with a radio, in order to provide ZHA support for other radios - XBee S2C and TI CC2530/CC2531 seem like possible candidates. The logic that exists inside this platform is all about implementing the ZigBee Home Automation logic - eg, when we read manufacturer and model information in I guess the question is ... if someone wanted to implement support for ZHA devices with an XBee S2C radio as the controller, would you prefer that they re-implement the logic in this platform? |
|
This looks excellent. Ive been keen to try zigbee direct rather than needing to use a proprietary gateway or hub. It looks like this usb device might also be compatible too as it seems to use an EmberZNet chipset? |
|
@dale3h , I've just re-added my iris contact sensor, and it works OK (it reports as a CentraLite 3320). If you could get me some debug logs, that'd be useful. I usually run with this logger config: logger:
default: debug
logs:
homeassistant.components.websocket_api: info
bellows.uart: info |
|
Yes, naming is fine. |
|
This is ready to merge @rcloran when you give the 👍 |
|
@rcloran Here is the (filtered) debug output from me trying to permit 3 different, in this order:
Both IKEA Tradfri devices throw the |
|
I'm somewhat ignoring the tradfri stuff for now - my initial experiments with the devices I could get to join showed that they weren't standards compliant. While it may be true that these particular ones are actually, I'm not quite up for this fight with gadgets right now :) The exception is caused because we're getting an undocumented value over EZSP. Even if I add a value to that enum, I don't have anything that'll handle those macFilterMatchMessageHandler messages. I have a feeling these are generated when some zll devices try to join a zha network, but I'm not yet sure why, or really exactly what they mean. It's not clear from your logs when you attempted to make the iris contact sensor join. 14:12:13? Here's the logs from my iris contact sensor joining: https://gist.github.com/rcloran/7a91bbeb1e708fc54c98b5cca02a1c4e It seems that yours is not finishing the join to the trust center, which is something entirely handled by the USB stick (ie, no communication with bellows). Did you do anything special when forming the network, or did you let the code in hass do that? |
|
@dale3h got his device paired - it needed to be closer to his zigbee radio. So, I'm confident this is reasonably close to OK to merge. There are a few things I'd still like to do, but I can always submit more PRs to fix future things. I guess there's one quick fix I want to make, which is to add a value 128 to the EmberMacPassthroughType in |
|
Sorry if I led you astray this weekend, @dale3h! My Iris Contact sensor paired just fine from across the house. 😬 |
|
👏 👏 👏 👏 👏 |
|
just joining the discussion about compatible usb sticks available in Europe(/Germany). Are there any? what about an em357 or em3588 based stick? (like this one: https://www.digikey.de/de/product-highlight/c/cel/cortet-radio-em3588-usb-sticks) |
|
@h3ndrik , I think that em3588 stick should work. |
|
Is this a stick that would work? https://www.dresden-elektronik.de/conbee/ |
|
@turbokongen I believe @dale3h confirmed that the Conbee does NOT work since the firmware isn't compatible. |
|
@rcloran have you tested pairing with "Xiaomi Smart Home" sensors which also use ZigBee? https://xiaomi-mi.com/mi-smart-home/xiaomi-mi-smart-home-kit/ SmartThings community report that the Xiaomi ZigBee sensors pairs with Samsung SmartThings Hub: https://community.smartthings.com/t/release-xiaomi-sensors-and-button-beta/77576 https://community.smartthings.com/t/9-zigbee-xiaomi-door-window-sensors-works-for-some-people/28607 These "Xiaomi Smart Home" devices are the cheapest quality ZigBee sensors I can find. |
|
Please don't turn merged PRs into a FAQ or forum. That's what our forum and docs are for. If there's a problem, open an issue. Thanks! |
ghost
removed
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description: Add support for locally managed ZigBee Home Automation devices with a compatible ZigBee radio.
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.io#2155
Example entry for
configuration.yaml(if applicable):Checklist:
If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
toxrun successfully. Your PR cannot be merged unless tests passREQUIREMENTSvariable (example).requirements_all.txtby runningscript/gen_requirements_all.py..coveragerc.If the code does not interact with devices:
toxrun successfully. Your PR cannot be merged unless tests pass