Code Monkey home page Code Monkey logo

zigpy's Introduction

zigpy

Build Coverage Status

zigpy is a hardware independent Zigbee protocol stack integration project to implement Zigbee standard specifications as a Python 3 library.

Zigbee integration via zigpy allows you to connect one of many off-the-shelf Zigbee Coordinator adapters using one of the available Zigbee radio library modules compatible with zigpy to control Zigbee based devices. There is currently support for controlling Zigbee device types such as binary sensors (e.g., motion and door sensors), sensors (e.g., temperature sensors), lights, switches, buttons, covers, fans, climate control equipment, locks, and intruder alarm system devices. Note that Zigbee Green Power devices currently are unsupported.

Zigbee stacks and hardware from many different hardware chip manufacturers are supported via radio libraries which translate their proprietary communication protocol into a common API which is shared among all radio libraries for zigpy. If some Zigbee stack or Zigbee Coordinator hardware for other manufacturers is not supported by yet zigpy it is possible for any independent developer to step-up and develop a new radio library for zigpy which translates its proprietary communication protocol into the common API that zigpy can understand.

zigpy contains common code implementing ZCL (Zigbee Cluster Library) and ZDO (Zigbee Device Object) application state management which is being used by various radio libraries implementing the actual interface with the radio modules from different manufacturers. The separate radio libraries interface with radio hardware adapters/modules over USB and GPIO using different native UART serial protocols.

The ZHA integration component for Home Assistant, the Zigbee Plugin for Domoticz, and the Zigbee Plugin for Jeedom (competing open-source home automation software) are all using zigpy libraries as dependencies, as such they could be used as references of different implementations if looking to integrate a Zigbee solution into your application.

Zigbee device OTA updates

zigpy have ability to download and perform Zigbee OTAU (Over-The-Air Updates) of Zigbee devices firmware. The Zigbee OTA update firmware image files should conform to standard Zigbee OTA format and OTA provider source URLs need to be published for public availability. Updates from a local OTA update directory also is also supported and can be used as an option for offline firmware updates if user provide correct Zigbee OTA formatted firmware files themselves.

Support for automatic download from existing online OTA providers in zigpy OTA provider code is currently only available for IKEA, Inovelli, LEDVANCE/OSRAM, SALUS/Computime, and SONOFF/ITEAD devices. Support for additional OTA providers for other manufacturers devices could be added to zigpy in the future, if device manufacturers publish their firmware images publicly and developers contribute the needed download code for them.

How to install and test, report bugs, or contribute to this project

For specific instructions on how-to install and test zigpy or contribute bug-reports and code to this project please see the guidelines in the CONTRIBUTING.md file:

This CONTRIBUTING.md file will contain information about using zigpy, testing new releases, troubleshooting and bug-reporting as, as well as library + code instructions for developers and more. This file also contain short summaries and links to other related projects that directly or indirectly depends in zigpy libraries.

You can contribute to this project either as an end-user, a tester (advanced user contributing constructive issue/bug-reports) or as a developer contributing code.

Compatible Zigbee coordinator hardware

Radio libraries for zigpy are separate projects with their own repositories and include bellows (for communicating with Silicon Labs EmberZNet based radios), zigpy-deconz (for communicating with deCONZ based radios from Dresden Elektronik), and zigpy-xbee (for communicating with XBee based Zigbee radios), zigpy-zigate for communicating with ZiGate based radios, zigpy-znp or zigpy-cc for communicating with Texas Instruments based radios that have Z-Stack ZNP coordinator firmware.

Note! Zigbee 3.0 support or not in zigpy depends primarily on your Zigbee coordinator hardware and its firmware. Some Zigbee coordinator hardware support Zigbee 3.0 but might be shipped with an older firmware which does not, in which case may want to upgrade the firmware manually yourself. Some other Zigbee coordinator hardware may not support a firmware that is capable of Zigbee 3.0 at all but can still be fully functional and feature complete for your needs, (this is very common as many if not most Zigbee devices do not yet Zigbee 3.0 or are backwards-compable with a Zigbee profile that is support by your Zigbee coordinator hardware and its firmware). As a general rule, newer Zigbee coordinator hardware released can normally support Zigbee 3.0 firmware and it is up to its manufacturer to make such firmware available for them.

Compatible zigpy radio libraries

  • Digi XBee based Zigbee radios via the zigpy-xbee library for zigpy.
  • dresden elektronik deCONZ based Zigbee radios via the zigpy-deconz library for zigpy.
  • Silicon Labs (EmberZNet) based Zigbee radios using the EZSP protocol via the bellows library for zigpy.
  • Texas Instruments based Zigbee radios with all compatible Z-Stack firmware via the zigpy-znp library for zigpy.
  • ZiGate based ZigBee radios via the zigpy-zigate library for zigpy.

Legacy or obsolete zigpy radio libraries

  • Texas Instruments with Z-Stack legacy firmware via the zigpy-cc library for zigpy.

Release packages available via PyPI

New packages of tagged versions are also released via the "zigpy" project on PyPI

Older packages of tagged versions are still available on the "zigpy-homeassistant" project on PyPI

Packages of tagged versions of the radio libraries are released via separate projects on PyPI

zigpy's People

Contributors

abmantis avatar adminiuga avatar andreasbomholtz avatar cdce8p avatar chmielowiec avatar codyhackw avatar damarco avatar davet2001 avatar dmulcahey avatar felixstorm avatar gamester17 avatar hedda avatar igorbernstein2 avatar inovelliusa avatar jeremielegrand avatar majkrzak avatar mdeweerd avatar nepeat avatar pipiche38 avatar prairiesnpr avatar presslab-us avatar puddly avatar pvizeli avatar rcloran avatar shulyaka avatar skgsergio avatar tacov avatar thejulianjes avatar yoda-x avatar zalke avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

zigpy's Issues

Orivibo T10D1 Smart Dimmer causing UTF related errors

I've picked up one of these dimmer switches for an excellent price and tried it out with ZHA on Hass.io. It pairs correctly but after that Zigpy throws an error like this:

Error during setup of component zha
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/homeassistant/setup.py", line 145, in _async_setup_component
    hass, processed_config)
  File "/usr/local/lib/python3.6/site-packages/homeassistant/components/zha/__init__.py", line 106, in async_setup
    APPLICATION_CONTROLLER = ControllerApplication(radio, database)
  File "/usr/local/lib/python3.6/site-packages/bellows/zigbee/application.py", line 21, in __init__
    super().__init__(database_file=database_file)
  File "/usr/local/lib/python3.6/site-packages/zigpy/application.py", line 25, in __init__
    self._dblistener.load()
  File "/usr/local/lib/python3.6/site-packages/zigpy/appdb.py", line 223, in load
    ep.manufacturer = value.decode('ascii').strip()
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 0: ordinal not in range(128)

I took a look in zigbee.db and saw that it the manufacturer name was in Chinese. I corrected this to just Orvibo manually and it seems to have solved the problem.

A secondary problem is that the switch only shows up as a switch object with no dimming function. Not sure how to solve that one.

Support AlertMe/Iris proprietary clusters

With the release of some (most?) of the source code of the Iris system there is now public documentation of the behavior of these devices and how to interface with them.

The meat and potatoes appears to be here: https://github.com/arcus-smart-home/arcusplatform/tree/master/common/arcus-protocol/src/main/irp (the ame-* files)

They may no longer be sold by Lowe's but there's still a lot of them out there second-hand and people selling off old stock. It'd be nice to have more options.

Add support for Xiaomi sensors

(previously zigpy/bellows#43)

The protocol used by Xiaomi to connect to their sensors seems to deviate slightly from the ZigBee standard, preventing zigpy from communicating properly with them. It would be great if we could use a generic ZigBee radio to connect Xiaomi sensors to Home Assistant.

New PyPi Release

@rcloran Any chance you could publish a new Zigpy & Bellows release ?
We have a few important changes we would like to get into Hass 0.85 before the cutover date for beta. I understand it is a holiday season and don't want to steal too much of anyone's time, just need to know if it would be possible, otherwise I need to revert a few merged changes to hass prior the hass beta.

Standalone application

For testing purposes, it is nice to have zigpy running in a standalone mode, which can handle joins, database updates etc without dying (as some devices require some time to complete setup). Always running zigpy through home assistant is no alternative as 1) The home assistant startup time is prohibitive 2) Some people (including me) uses zigpy/bellows for other things than HA, so there should be a strict separation between the two (i.e. HA must not be a requirement for zigpy)

Error when adding GE Smart Dimmer

i'm getting an error when adding a GE smart dimmer switch on zigbee-deconz:

Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/config_entries.py", line 258, in async_setup
result = await component.async_setup_entry(hass, self)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/zha/init.py", line 140, in async_setup_entry
application_controller = ControllerApplication(radio, database)
File "/srv/homeassistant/lib/python3.5/site-packages/zigpy_deconz/zigbee/application.py", line 21, in init
super().init(database_file=database_file)
File "/srv/homeassistant/lib/python3.5/site-packages/zigpy/application.py", line 25, in init
self._dblistener.load()
File "/srv/homeassistant/lib/python3.5/site-packages/zigpy/appdb.py", line 214, in load
dev = self._application.get_device(ieee)
File "/srv/homeassistant/lib/python3.5/site-packages/zigpy/application.py", line 116, in get_device
return self.devices[ieee]
KeyError: 00:22:a3:00:00:25:83:74

Any help would be appreciated! Happy to provide additional information

King of Fans zigbee receiver dimmable lights

The King of Fans/Hampton Bay Zigbee fan receiver is able to dim lights. However, the light device shows up in Home Assistant as a switch (non-dimmable) instead of a dimmable light entity. Not completely sure if this is a Home Assistant issue or Zigpy issue. Figured I'd start here first.

I'm willing to help test or install dev versions of packages.

Quirks for smartthings sensors to add battery_percentage_remaining attribute

Working HA, I was looking to add a generic battery layer that uses the battery_percentage_remaining attribute. Unfortunately, many sensors, like the last generation smarthings, don't report this attribute.

I tried to add a quirk to create this attribute based on the existing battery_voltage, but this failed dismally. Was wondering if anyone had the expertise to do this.

This was my attempt based on an example I saw elsewhere, but it is never triggered.

class SmartthingsPowerCluster(CustomCluster, PowerConfiguration):
    """Provides battery % remaining based on voltage"""
    minVolts = 15
    maxVolts = 28
    values = {
        28: 100,
        27: 100,
        26: 100,
        25: 90,
        24: 90,
        23: 70,
        22: 70,
        21: 50,
        20: 50,
        19: 30,
        18: 30,
        17: 15,
        16: 1,
        15: 0
    }

    def _update_attribute(self, attrid, value):
        super()._update_attribute(attrid, value)

        attr_name = self.attributes.get(attrid, [attrid])[0]
        _LOGGER.debug("smartthings update attribute %s", attr_name)
        if attr_name == 'battery_voltage':
            _LOGGER.debug("Found battery voltage %s %s", value)

            value = min(value, self.maxVolts)
            value = max(value, self.minVolts)

            bpr = self.values.get(value, 'unknown')
            bpr_id = self._attridx.get('battery_percentage_remaining')

            super()._update_attribute(bpr_id, bpr)

Invite more developers to join "Team Zigpy" (zigpy organization on GitHub) to permit GitHub repo admin, commit, or release permissions and more?

@rcloran can I suggest that you extend some invitations to a few more developers who already submitted patches or are actively working on patches for and forks of zigpy as well radio libraries for zigpy to join some kind of 'Team Zigpy' (i.e. the zigpy organization here on GitHub) which could work together to achieve common goals for this upstream zigpy project and all of its repositories as an organizational unit with shared goals?

https://github.com/orgs/zigpy/people

As mentioned in #104 and #318 please then give more permissions to either all or a trusted few to not only make commits of pull requests to merge into the mainline tree but also tag and make releases on GitHub (and PiPy releases as well).

Long-term, do you not believe that it would be a good idea to have more people with commit merges and release access to this upstream repo for zigpy?

As a team, you could collaborate using a common chat and public or private community forums as communication channels for sharing ideas and discussing short-term and long-term goals for zigpy and other related libraries or tools for zigpy?

Maintainers are also needed for releasing and maintaining all PyPI releases as a team when tag versions

Having a team collaborating would off-load some of the work from you. Like if you and a few of them are willing to work together as a team then you could, for example, all help review and give feedback on each other’s pull request for patches and once trust is proved you could giving more people write access to the upstream bellows repository to assist in committing push request and fixing issues that other people posts?

To start with some example team-member candidates of the people who look to be actively been working on improvements and enhancements for zigpy and its radio libraries or the ZHA component for Home Assistant are; @AndreasBomholtz @Adminiuga @dmulcahey @roblandry @Yoda-x @jonatanolofsson @damarco @doudz @Seluxit @h3ndrik @SteveEasley @titilambert @puddly @igorbernstein2 @hobbypunk90 @dbajric @kylehendricks @glentakahashi @ryanwinter @Koenkk @Equidamoid ...and perhaps also @balloob from the Home Assistant project too?

Switch turns off but doesn't turn on from the HA portal

I've been able to add the Jasco switch to my home assistant using zigpy-deconz package, but now I'm able to turn off the light but I'm not able to turn it back on.

I've added and remove the light several times and here are the scenarios and how HA responds.

  1. I can always turn the light off in the HA portal.
  2. I can see the current status of the switch in the HA portal whenever I turn the switch on or off at the switch.
  3. If the first command I give to the switch through the HA portal is to turn it on, then it works. Every subsequent attempt to turn the switch on remotely doesn't work.

Here's a copy of my logs (I removed anything that doesn't include Zigbee in the log entry to reduce the size of the file).
https://pastebin.com/wep19P0S

[REQUEST] ZHA Device Handler to handle the unique quirks exception handling implementation in Zigpy

@dmulcahey (with the help of a few other developers like @damarco @Adminiuga & @Yoda-x ) have written this ZHA Device Handler as an implementation to handle "quirks" for Zigbee devices when using Zigpy (in Home Assistant) which allow you to write modular device handlers for handling unique exceptions (a.k.a. "quirks") in Zigbee devices.

https://github.com/dmulcahey/zha-device-handlers

@rcloran @AndreasBomholtz I was wondering it would be a good idea for the Zigpy itself to integrate such a ZHA Device Handler function of its own or similar modular implementation for exception handling of the unique quirks in some Zigbee devices?

This point of this is both to workaround bugs in devices and to deal with exceptions when device manufacturers deviate from the Zigbee standards or even if a device use functions not yet available in the Zigpy library itself, as separate handlers can then be implemented by third.parties without having to change or update the Zigpy library. SmartThings, for example, has custom handlers which perform this function of dealing with exceptions and device functions not yet implemented by Samsung.

I mean, would it not be better if a modular ZHA Device Handler implementation existing as part of the Zigpy project (so other third-party projects can use it as well) instead of it being only part of Home Assistant?

PS: Something similar was also requested by @jonatanolofsson in #8 ("Low-level hardware specialization")

"Specialization cannot be exclusively handled above the zigpy abstraction level as some devices require low-level adjustments. One distinguished example is the IKEA Trådfri devices which need to use the ZHA profile ID in the APS frame in ZCL communication."

Traceback when adding Xiaomi device

I have a few Xiaomi devices, which works great with the new support. But, on join they fail with a traceback:

2018-06-08 15:33:00 ERROR (MainThread) [bellows.ezsp] Exception running handler
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/bellows/ezsp.py", line 194, in handle_callback
handler(*args)
File "/usr/lib/python3.5/site-packages/bellows/zigbee/application.py", line 139, in ezsp_callback_handler
self._handle_frame(*args)
File "/usr/lib/python3.5/site-packages/bellows/zigbee/application.py", line 160, in _handle_frame
tsn, command_id, is_reply, args = self.deserialize(device, aps_frame.sourceEndpoint, aps_frame.clusterId, message)
File "/usr/lib/python3.5/site-packages/zigpy/application.py", line 73, in deserialize
return sender.deserialize(endpoint_id, cluster_id, data)
File "/usr/lib/python3.5/site-packages/zigpy/device.py", line 97, in deserialize
return self.endpoints[endpoint_id].deserialize(cluster_id, data)
KeyError: 1

I feel that's due to the fact that quirks only operate after device_initialized, not add_device (though I'm have only a shallow understanding of the problem).

I'd be happy to help testing.

Thanks!

GE Link A19 fails to pair, Failed ZDO Request

When attempting to pair, the process times out. I've tried with allow pair on and off and get the same result. This is after resetting the bulb, bulb will dim and then blink three times, but isn't added.

Home assistant version:
0.85.0.dev0

Zigpy version: 0.2.0

Logs:

> 2018-12-29 02:15:32 INFO (MainThread) [zigpy.application] Device 0x88b7 (00:13:a2:00:40:b4:15:17) joined th
> e network                                                                                                  
> 2018-12-29 02:15:32 INFO (MainThread) [zigpy.device] [0x88b7] Discovering endpoints                        
> Tries remaining: 3                                                                                         
> 2018-12-29 02:15:32 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 5                
> 2018-12-29 02:15:32 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:13:a2:00:40:b4:1
> 5:17, 34999, 0, 0, 5, 0, 0, 32, b'\x05\xb7\x88')                                                           
> 2018-12-29 02:15:32 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (14, 00:13:a2:00:40:b4:15:17, 3
> 4999, 0, 0, 5, 0, 0, 32, b'\x05\xb7\x88')                                                                  
> 2018-12-29 02:15:32 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x0e\x88\xb7\x00\x00\x00'   
> 2018-12-29 02:15:32 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status                          
> 2018-12-29 02:15:32 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [14, 34999, 0, 0, 0]                    
> 2018-12-29 02:15:32 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x13\xa2\x00@\xb4\x15\x1
> 7\x88\xb7\xe8\xe8\x00\x92\xc1\x05\x01\x01\x10.\x00\x00 '                                                   
> 2018-12-29 02:15:32 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator              
> 2018-12-29 02:15:32 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=1                        
> Tries remaining: 2                                                                                         
> 2018-12-29 02:15:44 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 6                
> 2018-12-29 02:15:44 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:13:a2:00:40:b4:1
> 5:17, 34999, 0, 0, 5, 0, 0, 32, b'\x06\xb7\x88')                                                           
> 2018-12-29 02:15:44 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (15, 00:13:a2:00:40:b4:15:17, 3
> 4999, 0, 0, 5, 0, 0, 32, b'\x06\xb7\x88')                                                                  
> 2018-12-29 02:15:44 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x0f\x88\xb7\x00\x00\x00'   
> 2018-12-29 02:15:44 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status                          
> 2018-12-29 02:15:44 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [15, 34999, 0, 0, 0]                    
> Tries remaining: 1                                                                                         
> 2018-12-29 02:15:56 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 7                
> 2018-12-29 02:15:56 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:13:a2:00:40:b4:1
> 5:17, 34999, 0, 0, 5, 0, 0, 32, b'\x07\xb7\x88')                                                           
> 2018-12-29 02:15:56 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (16, 00:13:a2:00:40:b4:15:17, 3
> 4999, 0, 0, 5, 0, 0, 32, b'\x07\xb7\x88')                                                                  
> 2018-12-29 02:15:56 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x10\x88\xb7\x00\x00\x00'   
> 2018-12-29 02:15:56 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status                          
> 2018-12-29 02:15:56 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [16, 34999, 0, 0, 0]                    
> 2018-12-29 02:16:06 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization:     
> Traceback (most recent call last):                                                                         
>   File "/srv/homeassistant/lib/python3.7/site-packages/zigpy/device.py", line 51, in _initialize           
>     epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)                                       
>   File "/srv/homeassistant/lib/python3.7/site-packages/zigpy/util.py", line 52, in retry                   
>     r = await func()                                                                                       
>   File "/srv/homeassistant/lib/python3.7/site-packages/zigpy/device.py", line 89, in request               
>     expect_reply=expect_reply,                                                                             
>   File "/srv/homeassistant/lib/python3.7/site-packages/zigpy_xbee/zigbee/application.py", line 81, in reque
> st                                                                                                         
>     v = await asyncio.wait_for(reply_fut, timeout)                                                         
>   File "/usr/local/lib/python3.7/asyncio/tasks.py", line 423, in wait_for                                  
>     raise futures.TimeoutError()                                                                           
> concurrent.futures._base.TimeoutError 

UnicodeDecodeError: 'ascii' codec can't decode byte 0x91 in position 3: ordinal not in range(128)

Hello, I am using zigpy_xbee inside homeassistant. It looks like sometimes parts of the API frame header are trying to be interpreted as ASCII. This happens randomly but 10-15 times a day. Is this a problem in how I have setup my radio or a real bug?

2019-05-17 05:42:25 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <bound method SerialTransport._read_ready of SerialTransport(<uvloop.Loop running=True closed=False debug=False>, <zigpy_xbee.uart.Gateway object at 0x722ef550>, Serial<id=0x722ef570, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False))>
Traceback (most recent call last):
File "uvloop/cbhandles.pyx", line 66, in uvloop.loop.Handle._run
File "/usr/local/lib/python3.7/site-packages/serial_asyncio/init.py", line 106, in _read_ready
self._protocol.data_received(data)
File "/usr/local/lib/python3.7/site-packages/zigpy_xbee/uart.py", line 78, in data_received
self.command_mode_rsp(rsp)
File "/usr/local/lib/python3.7/site-packages/zigpy_xbee/uart.py", line 55, in command_mode_rsp
data = data.decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0x91 in position 3: ordinal not in range(128)

Lutron Connected Bulb Remote support

Please advise if this is the incorrect place to place this issue and I'll resubmit elsewhere.

I previously posted this here: HASS ~ ZHA ZigBee Tested Devices

Wanted to share some info I found on the deCONZ REST GitHub regarding the use of Lutron Connected Bulb Remotes: deCONZ REST Commit

+static const Sensor::ButtonMap lutronLZL4BWHLSwitchMap[] = {
+//    mode                          ep    cluster cmd   param button                                       name
+//  vendor specific
+    // top button
+    { Sensor::ModeDimmer,           0x01, 0x0008, 0x04, 0xfe,  S_BUTTON_1 + S_BUTTON_ACTION_SHORT_RELEASED, "on" },
+    // second button
+    { Sensor::ModeDimmer,           0x01, 0x0008, 0x06, 0x00,  S_BUTTON_2 + S_BUTTON_ACTION_HOLD,           "dimm up" },
+    { Sensor::ModeDimmer,           0x01, 0x0008, 0x03, 0x00,  S_BUTTON_2 + S_BUTTON_ACTION_LONG_RELEASED,  "dimm up release" },
+    // third button
+    { Sensor::ModeDimmer,           0x01, 0x0008, 0x02, 0x01,  S_BUTTON_3 + S_BUTTON_ACTION_HOLD,           "dimm down" },
+    { Sensor::ModeDimmer,           0x01, 0x0008, 0x03, 0x01,  S_BUTTON_3 + S_BUTTON_ACTION_LONG_RELEASED,  "dimm down release" },
+    // bottom button
+    { Sensor::ModeDimmer,           0x01, 0x0008, 0x04, 0x00,  S_BUTTON_4 + S_BUTTON_ACTION_SHORT_RELEASED,  "off" },
+
+    // end
+    { Sensor::ModeNone,             0x00, 0x0000, 0x00, 0,    0,                                           0 }
+};

It was referenced here: deCONZ REST Plugin Issue #232

@manup there mentioned "For the events we'll create a binding from 0x0008 level control cluster to a newly created device group, so the remote will also work when the gateway is offline."

Not sure if this would help, as I've seen ya'll are making a ton of progress in Home Assistant Pull Request #12528

convert install code gets byte order wrong

def convert_install_code(code):
    if len(code) < 8:
        return None

    real_crc = bytes([code[-1], code[-2]])
    crc = CrcX25()
    crc.process(code[:len(code) - 2])
    if real_crc != crc.finalbytes():
        return None

    return aes_mmo_hash(code)

This code converts incorrectly. With a code of 313233343536E672 the value of real_crc is b'r\xe6' whereas the CrcX25 is b'xe6r'. To fix, the line needs to be changed to real_crc = bytes([code[-2], code[-1]])

Restarting hass on xbee throws exception and loses control of already paired devices

Hi,
I'm trying to setup a hass system with xbee s2c and some xiaomi devices. I'm using a venv home assistant installation on a ubuntu 18.04, both 0.75.x and 0.76 has the same issue.

configuration.yaml

logger:
  default: debug
  logs:
    homeassistant.components.zha: debug
    zigpy.zdo: debug
    zigpy.application: debug

zha:
  radio_type: xbee
  usb_path: /dev/ttyUSB0
  database_path: /home/homeassistant/.homeassistant/zigbee.db
  baudrate: 9600

Starting up home assistant brings the zha component up:

2018-08-19 12:06:26 INFO (MainThread) [homeassistant.setup] Setting up zha
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.uart] Connection made
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy.appdb] Loading application state from /home/homeassistant/.homeassistant/zigbee.db
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] AT command: AP (2,)
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Command at (1, b'AP', b'\x02')
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x01AP\x00'
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] AT command: AO (3,)
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Command at (2, b'AO', b'\x03')
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x02AO\x00'
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] AT command: SH ()
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Command at (3, b'SH', b'')
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x03SH\x00\x00\x13\xa2\x00'
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] AT command: SL ()
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Command at (4, b'SL', b'')
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x04SL\x00A%\x83\xd5'
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Read local IEEE address as 00:13:a2:00:41:25:83:d5
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] AT command: AI ()
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Command at (5, b'AI', b'')
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x05AI\x00\x00'
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] AT command: MY ()
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Command at (6, b'MY', b'')
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x06MY\x00\x00\x00'
2018-08-19 12:06:26 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:06:26 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=zha, service=permit>
2018-08-19 12:06:26 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=zha, service=remove>
2018-08-19 12:06:26 INFO (MainThread) [homeassistant.setup] Setup of domain zha took 0.4 seconds.
2018-08-19 12:06:26 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=zha>

Pairing a xiaomi smart plug works fine:

2018-08-19 12:08:10 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 140484382849456: Received {'type': 'call_service', 'domain': 'zha', 'service': 'permit', 'service_data': {'duration': 120}, 'id': 14}
2018-08-19 12:08:10 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=zha, service=permit, service_data=duration=120>
2018-08-19 12:08:10 INFO (MainThread) [homeassistant.components.zha] Permitting joins for 120s
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.api] AT command: NJ (120,)
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.api] Command at (7, b'NJ', b'x')
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x07NJ\x00'
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.api] AT command: AC ()
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.api] Command at (8, b'AC', b'')
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x08AC\x00'
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.api] AT command: CB (2,)
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.api] Command at (9, b'CB', b'\x02')
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\tCB\x00'
2018-08-19 12:08:10 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:08:10 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_executed[L]>
2018-08-19 12:08:10 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 140484382849456: Sending {'id': 14, 'type': 'result', 'success': True, 'result': None}
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x00\x00\x00\x13\x00\x00\x02\xb0m9\x08\x1c\x16\x02\x00\x8d\x15\x00\x8e'
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=2
2018-08-19 12:08:30 INFO (MainThread) [zigpy.application] Device 0x396d (00:15:8d:00:02:16:1c:08) joined the network
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy.zdo] [0x396d:zdo] ZDO request 0x0013: [14701, 00:15:8d:00:02:16:1c:08, 142]
2018-08-19 12:08:30 INFO (MainThread) [zigpy.device] [0x396d] Discovering endpoints
Tries remaining: 3
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 1
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:15:8d:00:02:16:1c:08, 14701, 0, 0, 5, 0, 0, 32, b'\x01m9')
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (10, 00:15:8d:00:02:16:1c:08, 14701, 0, 0, 5, 0, 0, 32, b'\x01m9')
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\n9m\x00\x00\x00'
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [10, 14701, 0, 0, 0]
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x00\x00\x80\x05\x00\x00\x01\x01\x00m9\x04\x01\x02\x03d'
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=1
2018-08-19 12:08:30 INFO (MainThread) [zigpy.device] [0x396d] Discovered endpoints: [1, 2, 3, 100]
2018-08-19 12:08:30 INFO (MainThread) [zigpy.endpoint] [0x396d:1] Discovering endpoint information
Tries remaining: 3
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 2
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:15:8d:00:02:16:1c:08, 14701, 0, 0, 4, 0, 0, 32, b'\x02m9\x01')
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (11, 00:15:8d:00:02:16:1c:08, 14701, 0, 0, 4, 0, 0, 32, b'\x02m9\x01')
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x00\x01\x04\x00\x18\xcd\n\x05\x00B\tlumi.plug\x01\x00 \x01'
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=0
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy.endpoint] Ignoring unknown cluster ID 0x0000
2018-08-19 12:08:30 WARNING (MainThread) [zigpy_xbee.zigbee.application] Unexpected response TSN=205 command=266 args=b'\x05\x00B\tlumi.plug\x01\x00 \x01'
2018-08-19 12:08:30 WARNING (MainThread) [zigpy.endpoint] [0x396d:1] Message on unknown cluster 0x0000
2018-08-19 12:08:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sun.sun, old_state=<state sun.sun=above_horizon; next_dawn=2018-08-20T02:49:01+00:00, next_dusk=2018-08-19T17:27:12+00:00, next_midnight=2018-08-19T22:07:15+00:00, next_noon=2018-08-19T10:07:34+00:00, next_rising=2018-08-20T03:18:09+00:00, next_setting=2018-08-19T16:57:59+00:00, elevation=58.73, azimuth=150.95, friendly_name=Sun @ 2018-08-19T12:06:25.971401+03:00>, new_state=<state sun.sun=above_horizon; next_dawn=2018-08-20T02:49:01+00:00, next_dusk=2018-08-19T17:27:12+00:00, next_midnight=2018-08-19T22:07:15+00:00, next_noon=2018-08-19T10:07:34+00:00, next_rising=2018-08-20T03:18:09+00:00, next_setting=2018-08-19T16:57:59+00:00, elevation=58.82, azimuth=151.38, friendly_name=Sun @ 2018-08-19T12:06:25.971401+03:00>>
2018-08-19 12:08:30 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 140484382849456: Sending {'id': 2, 'type': 'event', 'event': {'event_type': 'state_changed', 'data': {'entity_id': 'sun.sun', 'old_state': <state sun.sun=above_horizon; next_dawn=2018-08-20T02:49:01+00:00, next_dusk=2018-08-19T17:27:12+00:00, next_midnight=2018-08-19T22:07:15+00:00, next_noon=2018-08-19T10:07:34+00:00, next_rising=2018-08-20T03:18:09+00:00, next_setting=2018-08-19T16:57:59+00:00, elevation=58.73, azimuth=150.95, friendly_name=Sun @ 2018-08-19T12:06:25.971401+03:00>, 'new_state': <state sun.sun=above_horizon; next_dawn=2018-08-20T02:49:01+00:00, next_dusk=2018-08-19T17:27:12+00:00, next_midnight=2018-08-19T22:07:15+00:00, next_noon=2018-08-19T10:07:34+00:00, next_rising=2018-08-20T03:18:09+00:00, next_setting=2018-08-19T16:57:59+00:00, elevation=58.82, azimuth=151.38, friendly_name=Sun @ 2018-08-19T12:06:25.971401+03:00>}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 8, 19, 9, 8, 30, 726845, tzinfo=<UTC>), 'context': {'id': 'ab5eaabdca3547f2bb92054971d4ded3', 'user_id': None}}}
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\n\x01\x04\x00\x10\xce\x00\x00\x00'
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=0
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy.endpoint] Ignoring unknown cluster ID 0x000a
2018-08-19 12:08:30 WARNING (MainThread) [zigpy.endpoint] [0x396d:1] Message on unknown cluster 0x000a
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x0b9m\x00\x00\x00'
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [11, 14701, 0, 0, 0]
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x00\x00\x80\x04\x00\x00\x01\x02\x00m9\x1e\x01\x04\x01Q\x00\x01\t\x00\x00\x04\x00\x03\x00\x06\x00\x10\x00\x05\x00\n\x00\x01\x00\x02\x00\x02\x19\x00\n\x00'
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=1
2018-08-19 12:08:30 INFO (MainThread) [zigpy.endpoint] [0x396d:1] Discovered endpoint information: <SimpleDescriptor endpoint=1 profile=260 device_type=81 device_version=1 input_clusters=[0, 4, 3, 6, 16, 5, 10, 1, 2] output_clusters=[25, 10]>
2018-08-19 12:08:30 INFO (MainThread) [zigpy.endpoint] [0x396d:2] Discovering endpoint information
Tries remaining: 3
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 3
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:15:8d:00:02:16:1c:08, 14701, 0, 0, 4, 0, 0, 32, b'\x03m9\x02')
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (12, 00:15:8d:00:02:16:1c:08, 14701, 0, 0, 4, 0, 0, 32, b'\x03m9\x02')
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x0c9m\x00\x00\x00'
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [12, 14701, 0, 0, 0]
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x00\x00\x80\x04\x00\x00\x01\x03\x00m9\x0e\x02\x04\x01\t\x00\x01\x01\x0c\x00\x02\x0c\x00\x04\x00'
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=1
2018-08-19 12:08:30 INFO (MainThread) [zigpy.endpoint] [0x396d:2] Discovered endpoint information: <SimpleDescriptor endpoint=2 profile=260 device_type=9 device_version=1 input_clusters=[12] output_clusters=[12, 4]>
2018-08-19 12:08:30 INFO (MainThread) [zigpy.endpoint] [0x396d:3] Discovering endpoint information
Tries remaining: 3
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 4
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:15:8d:00:02:16:1c:08, 14701, 0, 0, 4, 0, 0, 32, b'\x04m9\x03')
2018-08-19 12:08:30 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (13, 00:15:8d:00:02:16:1c:08, 14701, 0, 0, 4, 0, 0, 32, b'\x04m9\x03')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\r9m\x00\x00\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [13, 14701, 0, 0, 0]
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x00\x00\x80\x04\x00\x00\x01\x04\x00m9\x0c\x03\x04\x01S\x00\x01\x01\x0c\x00\x01\x0c\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=1
2018-08-19 12:08:31 INFO (MainThread) [zigpy.endpoint] [0x396d:3] Discovered endpoint information: <SimpleDescriptor endpoint=3 profile=260 device_type=83 device_version=1 input_clusters=[12] output_clusters=[12]>
2018-08-19 12:08:31 INFO (MainThread) [zigpy.endpoint] [0x396d:100] Discovering endpoint information
Tries remaining: 3
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 5
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:15:8d:00:02:16:1c:08, 14701, 0, 0, 4, 0, 0, 32, b'\x05m9d')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (14, 00:15:8d:00:02:16:1c:08, 14701, 0, 0, 4, 0, 0, 32, b'\x05m9d')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x0e9m\x00\x00\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [14, 14701, 0, 0, 0]
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x00\x00\x80\x04\x00\x00\x01\x05\x00m9\x0ed\x04\x01\x07\x01\x02\x01\x0f\x00\x02\x0f\x00\x04\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=1
2018-08-19 12:08:31 INFO (MainThread) [zigpy.endpoint] [0x396d:100] Discovered endpoint information: <SimpleDescriptor endpoint=100 profile=260 device_type=263 device_version=2 input_clusters=[15] output_clusters=[15, 4]>
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.quirks] Considering <class 'zigpy.quirks.xiaomi.TemperatureHumiditySensor'>
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.quirks] Fail because endpoint list mismatch: dict_keys([1, 2, 3]) {1, 2, 3, 100}
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.quirks] Considering <class 'zigpy.quirks.xiaomi.AqaraTemperatureHumiditySensor'>
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.quirks] Fail because endpoint list mismatch: dict_keys([1]) {1, 2, 3, 100}
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.quirks] Considering <class 'zigpy.quirks.xiaomi.AqaraOpenCloseSensor'>
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.quirks] Fail because endpoint list mismatch: dict_keys([1]) {1, 2, 3, 100}
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.quirks] Considering <class 'zigpy.quirks.xiaomi.AqaraWaterSensor'>
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.quirks] Fail because endpoint list mismatch: dict_keys([1]) {1, 2, 3, 100}
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 6
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:15:8d:00:02:16:1c:08, 14701, 1, 1, 0, 260, 0, 32, b'\x00\x06\x00\x04\x00\x05\x00')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (15, 00:15:8d:00:02:16:1c:08, 14701, 1, 1, 0, 260, 0, 32, b'\x00\x06\x00\x04\x00\x05\x00')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x0f9m\x00\x00\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [15, 14701, 0, 0, 0]
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x00\x01\x04 \x18\x06\x01\x04\x00\x00B\x04LUMI\x05\x00\x00B\tlumi.plug'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=32
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.loader] Loaded switch from homeassistant.components.switch
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.setup] Setting up switch
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=switch, service=turn_off>
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=switch, service=turn_on>
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=switch, service=toggle>
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.setup] Setup of domain switch took 0.0 seconds.
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=switch>
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.core] Bus:Handling <Event platform_discovered[L]: service=load_platform.switch, platform=zha, discovered=discovery_key=00:15:8d:00:02:16:1c:08-1>
2018-08-19 12:08:31 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 140484382849456: Sending {'id': 5, 'type': 'event', 'event': {'event_type': 'service_registered', 'data': {'domain': 'switch', 'service': 'turn_off'}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 8, 19, 9, 8, 31, 504128, tzinfo=<UTC>), 'context': {'id': '63eb09e1c0a948dd94ff50b46a0d1fac', 'user_id': None}}}
2018-08-19 12:08:31 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 140484382849456: Sending {'id': 5, 'type': 'event', 'event': {'event_type': 'service_registered', 'data': {'domain': 'switch', 'service': 'turn_on'}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 8, 19, 9, 8, 31, 504380, tzinfo=<UTC>), 'context': {'id': '95b7c0c964914a1da0a29fc02716745f', 'user_id': None}}}
2018-08-19 12:08:31 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 140484382849456: Sending {'id': 5, 'type': 'event', 'event': {'event_type': 'service_registered', 'data': {'domain': 'switch', 'service': 'toggle'}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 8, 19, 9, 8, 31, 504618, tzinfo=<UTC>), 'context': {'id': 'b3d592fea9b44d72bc38c19ecc9be53b', 'user_id': None}}}
2018-08-19 12:08:31 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 140484382849456: Sending {'id': 4, 'type': 'event', 'event': {'event_type': 'component_loaded', 'data': {'component': 'switch'}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 8, 19, 9, 8, 31, 504932, tzinfo=<UTC>), 'context': {'id': '9f77370741d74966b42263a2c403003f', 'user_id': None}}}
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.loader] Loaded switch.zha from homeassistant.components.switch.zha
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.components.switch] Setting up switch.zha
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 7
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:15:8d:00:02:16:1c:08, 14701, 0, 0, 33, 0, 0, 32, b'\x07\x08\x1c\x16\x02\x00\x8d\x15\x00\x01\x06\x00\x03\xd5\x83%A\x00\xa2\x13\x00\x01')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (16, 00:15:8d:00:02:16:1c:08, 14701, 0, 0, 33, 0, 0, 32, b'\x07\x08\x1c\x16\x02\x00\x8d\x15\x00\x01\x06\x00\x03\xd5\x83%A\x00\xa2\x13\x00\x01')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x109m\x00\x00\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [16, 14701, 0, 0, 0]
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x00\x00\x80!\x00\x00\x01\x07\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=1
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 8
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:15:8d:00:02:16:1c:08, 14701, 1, 1, 6, 260, 0, 32, b'\x00\x08\x06\x00\x00\x00\x10\x00\x00X\x02')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (17, 00:15:8d:00:02:16:1c:08, 14701, 1, 1, 6, 260, 0, 32, b'\x00\x08\x06\x00\x00\x00\x10\x00\x00X\x02')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x119m\x00\x00\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [17, 14701, 0, 0, 0]
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x06\x01\x04 \x18\x08\x07\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=32
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 9
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Sequenced command: tx_explicit (00:15:8d:00:02:16:1c:08, 14701, 1, 1, 6, 260, 0, 32, b'\x00\t\x00\x00\x00')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Command tx_explicit (18, 00:15:8d:00:02:16:1c:08, 14701, 1, 1, 6, 260, 0, 32, b'\x00\t\x00\x00\x00')
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b"\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x00\x01\x04\x00\x1c_\x11\xd0\n\x01\xffB1d\x10\x00\x03(,\x989\x00\x00\x00\x00\x959\x00\x00\x00\x00\x96#\xc4\x08\x00\x00\x05!\x07\x00\x9a \x10\x08!\x16\x13\x07'\x00\x00\x00\x00\x00\x00\x00\x00\t!\x00\x01"
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=0
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0000] ZCL request 0x000a: [[<Attribute attrid=65281 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc51017ac50>>]]
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0000] Attribute report received: 65281=b"d\x10\x00\x03(,\x989\x00\x00\x00\x00\x959\x00\x00\x00\x00\x96#\xc4\x08\x00\x00\x05!\x07\x00\x9a \x10\x08!\x16\x13\x07'\x00\x00\x00\x00\x00\x00\x00\x00\t!\x00\x01"
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x8b\x129m\x00\x00\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: tx_status
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] tx_status: [18, 14701, 0, 0, 0]
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x06\x01\x04 \x18\t\x01\x00\x00\x00\x10\x00'
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:31 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=32
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new switch.zha entity: switch.lumi_lumiplug_02161c08_1
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=switch.lumi_lumiplug_02161c08_1, old_state=None, new_state=<state switch.lumi_lumiplug_02161c08_1=off; friendly_name=LUMI lumi.plug @ 2018-08-19T12:08:31.888504+03:00>>
2018-08-19 12:08:31 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 140484382849456: Sending {'id': 2, 'type': 'event', 'event': {'event_type': 'state_changed', 'data': {'entity_id': 'switch.lumi_lumiplug_02161c08_1', 'old_state': None, 'new_state': <state switch.lumi_lumiplug_02161c08_1=off; friendly_name=LUMI lumi.plug @ 2018-08-19T12:08:31.888504+03:00>}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 8, 19, 9, 8, 31, 888532, tzinfo=<UTC>), 'context': {'id': '113434c835c64f0e8048f0bb83cb23bc', 'user_id': None}}}
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=group, service=set, service_data=object_id=all_switches, name=all switches, entities=['switch.lumi_lumiplug_02161c08_1'], visible=False>
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=group.all_switches, old_state=None, new_state=<state group.all_switches=off; entity_id=('switch.lumi_lumiplug_02161c08_1',), order=0, auto=True, friendly_name=all switches, hidden=True @ 2018-08-19T12:08:31.891619+03:00>>
2018-08-19 12:08:31 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 140484382849456: Sending {'id': 2, 'type': 'event', 'event': {'event_type': 'state_changed', 'data': {'entity_id': 'group.all_switches', 'old_state': None, 'new_state': <state group.all_switches=off; entity_id=('switch.lumi_lumiplug_02161c08_1',), order=0, auto=True, friendly_name=all switches, hidden=True @ 2018-08-19T12:08:31.891619+03:00>}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2018, 8, 19, 9, 8, 31, 891645, tzinfo=<UTC>), 'context': {'id': '78d5deb20da44265a953a2be5cb65df9', 'user_id': None}}}
2018-08-19 12:08:31 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_executed[L]>
2018-08-19 12:08:32 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x06\x01\x04\x00\x18M\n\x00\x00\x10\x00'
2018-08-19 12:08:32 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:32 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=0
2018-08-19 12:08:32 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] ZCL request 0x000a: [[<Attribute attrid=0 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc5185e53c8>>]]
2018-08-19 12:08:32 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] Attribute report received: 0=Bool.false
2018-08-19 12:08:32 DEBUG (MainThread) [homeassistant.components.switch.zha] Attribute updated: <Entity None: off> 0 Bool.false

At this point, I can see and control the state of the switch on GUI, and the gui gets updated when I press the physical on/off button on the plug itself:

2018-08-19 12:08:36 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x06\x01\x04\x00\x18I\n\x00\x00\x10\x01'
2018-08-19 12:08:36 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:36 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=0
2018-08-19 12:08:36 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] ZCL request 0x000a: [[<Attribute attrid=0 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc51123a6a0>>]]
2018-08-19 12:08:36 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] Attribute report received: 0=Bool.true
2018-08-19 12:08:36 DEBUG (MainThread) [homeassistant.components.switch.zha] Attribute updated: <Entity None: on> 0 Bool.true
2018-08-19 12:08:46 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x06\x01\x04\x00\x18\xe0\n\x00\x00\x10\x01\x00\xf0#\x00m9\x03'
2018-08-19 12:08:46 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:46 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=0
2018-08-19 12:08:46 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] ZCL request 0x000a: [[<Attribute attrid=0 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc5316aef28>>, <Attribute attrid=61440 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc51017ac18>>]]
2018-08-19 12:08:46 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] Attribute report received: 0=Bool.true, 61440=54095104
2018-08-19 12:08:46 DEBUG (MainThread) [homeassistant.components.switch.zha] Attribute updated: <Entity None: on> 0 Bool.true
2018-08-19 12:08:46 DEBUG (MainThread) [homeassistant.components.switch.zha] Attribute updated: <Entity None: on> 61440 54095104
2018-08-19 12:08:47 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x06\x01\x04\x00\x18\xe1\n\x00\x00\x10\x01'
2018-08-19 12:08:47 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:47 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=0
2018-08-19 12:08:47 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] ZCL request 0x000a: [[<Attribute attrid=0 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc5185e5ef0>>]]
2018-08-19 12:08:47 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] Attribute report received: 0=Bool.true
2018-08-19 12:08:47 DEBUG (MainThread) [homeassistant.components.switch.zha] Attribute updated: <Entity None: on> 0 Bool.true
2018-08-19 12:08:53 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x06\x01\x04\x00\x18\xe7\n\x00\x00\x10\x00\x00\xf0#\x00m9\x03'
2018-08-19 12:08:53 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:08:53 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=0
2018-08-19 12:08:53 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] ZCL request 0x000a: [[<Attribute attrid=0 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc51123a160>>, <Attribute attrid=61440 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc51017ac18>>]]
2018-08-19 12:08:53 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] Attribute report received: 0=Bool.false, 61440=54095104
2018-08-19 12:08:53 DEBUG (MainThread) [homeassistant.components.switch.zha] Attribute updated: <Entity None: on> 0 Bool.false
2018-08-19 12:08:53 DEBUG (MainThread) [homeassistant.components.switch.zha] Attribute updated: <Entity None: off> 61440 54095104
2018-08-19 12:08:53 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=switch.lumi_lumiplug_02161c08_1, old_state=<state switch.lumi_lumiplug_02161c08_1=on; friendly_name=LUMI lumi.plug @ 2018-08-19T12:08:35.190770+03:00>, new_state=<state switch.lumi_lumiplug_02161c08_1=off; friendly_name=LUMI lumi.plug @ 2018-08-19T12:08:53.155516+03:00>>

zigbee.db

sqlite> select * from devices;  
ieee                     nwk         status    
-----------------------  ----------  ----------
00:15:8d:00:02:16:1c:08  14701       2         
sqlite> select * from endpoints;
ieee                     endpoint_id  profile_id  device_type  status    
-----------------------  -----------  ----------  -----------  ----------
00:15:8d:00:02:16:1c:08  1            260         81           1         
00:15:8d:00:02:16:1c:08  2            260         9            1         
00:15:8d:00:02:16:1c:08  3            260         83           1         
00:15:8d:00:02:16:1c:08  100          260         263          1         
sqlite> select * from clusters;
ieee                     endpoint_id  cluster   
-----------------------  -----------  ----------
00:15:8d:00:02:16:1c:08  1            0         
00:15:8d:00:02:16:1c:08  1            4         
00:15:8d:00:02:16:1c:08  1            3         
00:15:8d:00:02:16:1c:08  1            6         
00:15:8d:00:02:16:1c:08  1            16        
00:15:8d:00:02:16:1c:08  1            5         
00:15:8d:00:02:16:1c:08  1            10        
00:15:8d:00:02:16:1c:08  1            1         
00:15:8d:00:02:16:1c:08  1            2         
00:15:8d:00:02:16:1c:08  2            12        
00:15:8d:00:02:16:1c:08  3            12        
00:15:8d:00:02:16:1c:08  100          15        
sqlite> select * from output_clusters;
ieee                     endpoint_id  cluster   
-----------------------  -----------  ----------
00:15:8d:00:02:16:1c:08  1            25        
00:15:8d:00:02:16:1c:08  1            10        
00:15:8d:00:02:16:1c:08  2            12        
00:15:8d:00:02:16:1c:08  2            4         
00:15:8d:00:02:16:1c:08  3            12        
00:15:8d:00:02:16:1c:08  100          15        
00:15:8d:00:02:16:1c:08  100          4          
sqlite> select * from attributes;     
ieee                     endpoint_id  cluster     attrid      value     
-----------------------  -----------  ----------  ----------  ----------
00:15:8d:00:02:16:1c:08  1            0           4           LUMI      
00:15:8d:00:02:16:1c:08  1            0           5           lumi.plug 
00:15:8d:00:02:16:1c:08  1            0           65281       d        
00:15:8d:00:02:16:1c:08  1            6           61440       117440524 
00:15:8d:00:02:16:1c:08  1            6           0           0

After this I restart home assistant, and zha / zigpy throws the exception - please note that the KeyError referenced is the network address (nwk, 14701) of the end device:

2018-08-19 12:13:30 INFO (MainThread) [homeassistant.setup] Setting up zha
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.uart] Connection made
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy.appdb] Loading application state from /home/homeassistant/.homeassistant/zigbee.db
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy.quirks] Considering <class 'zigpy.quirks.xiaomi.TemperatureHumiditySensor'>
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy.quirks] Fail because endpoint list mismatch: dict_keys([1, 2, 3]) {1, 2, 3, 100}
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy.quirks] Considering <class 'zigpy.quirks.xiaomi.AqaraTemperatureHumiditySensor'>
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy.quirks] Fail because endpoint list mismatch: dict_keys([1]) {1, 2, 3, 100}
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy.quirks] Considering <class 'zigpy.quirks.xiaomi.AqaraOpenCloseSensor'>
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy.quirks] Fail because endpoint list mismatch: dict_keys([1]) {1, 2, 3, 100}
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy.quirks] Considering <class 'zigpy.quirks.xiaomi.AqaraWaterSensor'>
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy.quirks] Fail because endpoint list mismatch: dict_keys([1]) {1, 2, 3, 100}
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] AT command: AP (2,)
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Command at (1, b'AP', b'\x02')
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.yr
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x01AP\x00'
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] AT command: AO (3,)
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Command at (2, b'AO', b'\x03')
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x02AO\x00'
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] AT command: SH ()
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Command at (3, b'SH', b'')
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x03SH\x00\x00\x13\xa2\x00'
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] AT command: SL ()
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Command at (4, b'SL', b'')
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x04SL\x00A%\x83\xd5'
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Read local IEEE address as 00:13:a2:00:41:25:83:d5
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] AT command: AI ()
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Command at (5, b'AI', b'')
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x05AI\x00\x00'
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] AT command: MY ()
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Command at (6, b'MY', b'')
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x88\x06MY\x00\x00\x00'
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.api] Frame received: at_response
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=zha, service=permit>
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=zha, service=remove>
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.setup] Setup of domain zha took 0.4 seconds.
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=zha>
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.loader] Loaded switch from homeassistant.components.switch
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.setup] Setting up switch
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=switch, service=turn_off>
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=switch, service=turn_on>
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=switch, service=toggle>
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.setup] Setup of domain switch took 0.0 seconds.
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=switch>
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.core] Bus:Handling <Event platform_discovered[L]: service=load_platform.switch, platform=zha, discovered=discovery_key=00:15:8d:00:02:16:1c:08-1>
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.loader] Loaded switch.zha from homeassistant.components.switch.zha
2018-08-19 12:13:30 INFO (MainThread) [homeassistant.components.switch] Setting up switch.zha
2018-08-19 12:13:30 DEBUG (MainThread) [zigpy_xbee.zigbee.application] Zigbee request seq 1
2018-08-19 12:13:30 ERROR (MainThread) [homeassistant.components.switch] Error while setting up platform zha
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py", line 129, in _async_setup_platform
    SLOW_SETUP_MAX_WAIT, loop=hass.loop)
  File "/usr/lib/python3.6/asyncio/tasks.py", line 358, in wait_for
    return fut.result()
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/switch/zha.py", line 27, in async_setup_platform
    await cluster.bind()
  File "/srv/homeassistant/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
    expect_reply=expect_reply,
  File "/srv/homeassistant/lib/python3.6/site-packages/zigpy_xbee/zigbee/application.py", line 71, in request
    self._devices_by_nwk[nwk],
KeyError: 14701

After this, home assistant starts, but there is no switch on the gui. I've tried to press the physical button on the plug, it is still paired:

2018-08-19 12:11:18 DEBUG (MainThread) [zigpy_xbee.uart] Frame received: b'\x91\x00\x15\x8d\x00\x02\x16\x1c\x089m\x01\x01\x00\x06\x01\x04\x00\x18\x84\n\x00\x00\x10\x00\x00\xf0#\x12\x00\x00\x07'
2018-08-19 12:11:18 DEBUG (MainThread) [zigpy_xbee.api] Frame received: explicit_rx_indicator
2018-08-19 12:11:18 DEBUG (MainThread) [zigpy_xbee.api] _handle_explicit_rx: opts=0
2018-08-19 12:11:18 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] ZCL request 0x000a: [[<Attribute attrid=0 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc51017a0b8>>, <Attribute attrid=61440 value=<zigpy.zcl.foundation.TypeValue object at 0x7fc5101cef60>>]]
2018-08-19 12:11:18 DEBUG (MainThread) [zigpy.zcl] [0x396d:1:0x0006] Attribute report received: 0=Bool.false, 61440=117440530
2018-08-19 12:11:18 DEBUG (MainThread) [homeassistant.components.switch.zha] Attribute updated: <Entity None: off> 0 Bool.false
2018-08-19 12:11:18 DEBUG (MainThread) [homeassistant.components.switch.zha] Attribute updated: <Entity None: off> 61440 117440530

I've also tried with a xiaomi aqara switch, the issue is the same. I have this setup ready, I can test code & provide other info.

Thanks,

Port ZSmartSystems ZigBee Java library supporting multiple dongles

As I understand ZSmartSystems ZigBee Java library aims to do what Zigpy and bellows does but in Java:

https://github.com/zsmartsystems/com.zsmartsystems.zigbee

Just suggestion to read and learn from their mistakes and success, and port over tweaks, etc.

FYI; this library was developed by @cdjackson who also developed the OpenHAB binding for ZigBee:

https://github.com/openhab/org.openhab.binding.zigbee/

https://github.com/cdjackson

http://www.cd-jackson.com

Change Zigbee name stylization referenses from "ZigBee" to "Zigbee" in all docs and code

Nitpicking but all code and documentation sooner or later needs to be updated to say "Zigbee" instead of "ZigBee" to reflect that the official Zigbee Alliance trademark branding changed the Zigbee name stylization from “ZigBee” to “Zigbee”, as in they are no longer writing Zigbee with a capital “B” in the middle of the name.

https://zigbeealliance.org/developer_resources/zigbee-specification/

"Please note that this uses old branding, Zigbee is always a lowercase B, not a capital. This change occurred shortly after the official release of this document."

Also see other Zigbee Alliance docs such as https://zigbeealliance.org/about/ and https://zigbeealliance.org/solution_type/zigbee/

Manually toggling samsung smartthings outlets does not update HA

When I toggle the outlet through HA, everything works as expected:

2018-02-18 16:20:29 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.uart] Sending: b'775d219c547364b658924a24ab1593499c5d34a8ecdd66201d7e'
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.uart] Data frame: b'705da19c543cdbfa7e'
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.uart] Sending: b'8070787e'
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.uart] Data frame: b'005db1ed542e14b459954b65ab55922363867eda12316283eecd6289b8647e'
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.uart] Sending: b'8160597e'
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.uart] Data frame: b'105db197547364b658924a24ab1593499c5834abed6f537e'
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.uart] Sending: b'82503a7e'
2018-02-18 16:20:29 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received

When I manually toggle with the device, HA does not update with the new state. I also see nothing in home_assistant.log.

Make zigpy forgiving when faced with unknown clusters/endpoints.

Some devices - notably Xiaomi - will not report the available cluster in accordance with the zigbee specifications (in fact, they rarely answer to requests at all). They do however send data on those clusters anyway, which causes bellows/zigpy to fail. Instead of throwing an error, a new cluster could be initialized upon discovery (it is more likely that it's not properly initialized than a properly invalid cluster id makes it through transport and hash checks). The same is true for uninitialized endpoints.

Xiaomi WXKG03LM and quirks

What Xiaomi device/model the class TemperatureHumiditySensor(CustomDevice): quirks is for?
I've got WXKG03LM the single button, which gets detected with 3 endpoints

<SimpleDescriptor endpoint=1 profile=260 device_type=24321 device_version=1 input_clusters=[0, 3, 25, 65535, 18] output_clusters=[0, 4, 3, 5, 25, 65535, 18]>
<SimpleDescriptor endpoint=2 profile=260 device_type=24322 device_version=1 input_clusters=[3, 18] output_clusters=[4, 3, 5, 18]>
<SimpleDescriptor endpoint=3 profile=260 device_type=24323 device_version=1 input_clusters=[3, 12] output_clusters=[4, 3, 5, 12]>

and therefore the above quirks takes over it, but it is definitely not a Temperature/humidity device or at least I think it is not. If it has the same clusters as the quirks Temperature/humidity sensor, then maybe we should take model into consideration when matching for a quirk?

New PyPi Release

Could we get a new release pushed to PyPi so Home Assistant's requirement can be updated?

Port cc-znp to communicate with TI CC253X / CC26X2R1 Zigbee Network Processor (ZNP) with Z-Stack firmware over UART serial port

Would it be possible to port the cc-znp library (or the newer forks of it) from JavaScript to Python to use as a base in a radio module for Zigpy to communicate with cheap TI CC253X based USB dongles when they are flashed with the custom Z-Stack firmware that the Zigbee2mqtt project has developed?

Texas Instruments CC253X based dongles like the inexpensive CC2531 USB sniffer sticks you can buy from China for less than $9 including shipping are readily available hardware and recently been made very popular by the Zigbee2mqtt (Zigbee to MQTT bridge) project which made a custom Z-Stack firmware for have them which has full Zigbee 3.0 stack with coordinator functionality (the project provide both Z-Stack 1.2 and Z-Stack 3.0 coordinator firmware, and also repeater firmware as well).

cc-znp library which was written in JavaScript is an integration interface for a host to communicate with the Z-Stack firmware running on TI CC253X Zigbee Network Processor (ZNP) using a serial protocol over a serial port via TI Z-Stack Monitor and Test (MT) APIs upon a UART interface. This cc-znp libary was utilized by the original zigbee-shepherd project and now also in the newer zigbee-herdsman project as well as some other projects which makes use of the use of custom Z-Stack firmware on CC253X chips. Most of which are based on Texas Instruments Z-Stack SDK (like the custom Z-Stack firmware available from the Zigbee2mqtt project).

https://github.com/zigbeer/cc-znp
https://github.com/zigbeer/cc-znp/wiki

Note! Best would probably be to port the code from newer forks of the cc-znp library which contains updated code and are better maintained:

https://github.com/Koenkk/cc-znp
https://github.com/open-zigbee/zigbee-bridge-znp
https://github.com/Koenkk/zigbee-herdsman

Update!: FYI @sanyatuning started development on a cc-znp python port as a module for Zigpy here:

https://github.com/sanyatuning/zigpy-cc

Another update! FYI, Adminiuga & puddly started development zigpy-znp as a alternative module here:

https://github.com/zha-ng/zigpy-znp
and here:
https://github.com/puddly/zigpy-znp

FYI; ioBroker is another JavaScript based project which Zigbee via same custom Z-Stack by Koenkk (ioBroker Zigbee module is based on zigbee-herdsman library and their new converters database)

https://github.com/ioBroker/ioBroker.zigbee

ioBroker claim to not only support CC2531/CC2530 but also CC26x2R and CC2538 (+ CC2592 PA)

https://github.com/ioBroker/ioBroker.zigbee/blob/master/README.md

Update! Z-Stack firmware from @Koenkk now also has experimental support CC2652R / CC26X2R1 based USB sticks and he has added Zigbee 3.0 support in Z-Stack 3.0 firmware as well. CC2652R by Texas Instruments is a new high-performance Zigbee chip which is much faster and contains much more memory than the CC2530 and CC2531 chips, (bonus is that Texas Instruments LAUNCHXL-CC26X2R1 LaunchPad development kit board requires no additional flashing hardware is needed, as the board has an on-board programmer).

https://github.com/Koenkk/Z-Stack-firmware
https://github.com/Koenkk/zigbee2mqtt
https://www.zigbee2mqtt.io

Do you think that Zigpy support CC253x (like CC2531) chips with custom Z-Stack firmware could be achieved by porting cc-znp from the latest zigbee-shepherd and zigbee-herdsman by Zigbee2mqtt project?

As I understand it, that custom Z-Stack firmware could possibly also be made compatible with additional Zigbee USB sticks/boards, like those based on CC2530, CC2530EM, CC2538, CC2540, CC2630, CC2650, CC2590, CC2591, and CC2592 chips from Texas Instruments as well?

https://github.com/zigbeer/zigbee-shepherd/wiki
https://github.com/zigbeer/documents/tree/master/zigbee-shepherd

Anyway, cc-znp, zigbee-shepherd, and zigbee-herdsman are all open-source software written in JavaScript. They support TI's CC253X wireless SoC as a zigbee network processor (ZNP) with custom Z-Stack firmware, and takes the ZNP approach with cc-znp to run the CC253X as a coordinator and to run zigbee-shepherd or zigbee-herdsman as the host.

@Koenkk who is the developer of zigbee2mqtt has most recently been developing zigbee-herdsman as a fork of zigbee-shepherd and is an improved replacement for zigbee-shepherd

https://github.com/Koenkk/zigbee-herdsman
https://github.com/Koenkk/zigbee-herdsman-converters

PS: Zigbee2mqtt also have source code as well as pre-built firmware for a custom Z-Stack firmware :

https://github.com/Koenkk/Z-Stack-firmware
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator
https://github.com/Koenkk/zigbee2mqtt/wiki/Getting-started
https://github.com/Koenkk/zigbee2mqtt

Native serial UART protocol support for ConBee and RaspBee from Dresden-Elektronik (radios using deCONZ serial protocol)

Please consider adding support for ConBee and RaspBee Zigbee radio transceiver hardware to Zigpy.

That is, make Zigpy support using ConBee and RaspBee adapters directly via serial potocol over UART and/or CLI similar to how it supports "bellows" Python library, without need to use deCONZ gateway software.

Dresden-Elektronik sell two types Zigbee transceivers in the form of their ConBee USB dongle and RaspBee GPIO module, both of these are very popular in Europe and both support the same native serial protocol (UART), a.k.a. "deCONZ Serial Protocol". Dresden-Elektronik have said that they themselves is currently not priotitizing applications using their native serial UART protocol, but they do at least provide documentation for it.

deCONZ Serial Protocol - The following document descibes the low level binary serial protocol used between deCONZ and the RaspBee/ConBee firmware.

http://www.dresden-elektronik.de/rpi/deconz/deCONZ-Serial-Protocol-en.pdf

As I understand it the protocol requires advanced understanding of the ZigBee standard, further it is fairly complicated for historical reasons to be compatible with legacy devices.

Please use Dresden-Elektronik public GitHub issues to discuss, report and request anything related to the serial protocol.

https://github.com/dresden-elektronik/deconz-rest-plugin/issues

zha lights stop responding over time

I'm going to cross-reference my issue at zigpy/bellows#124 because it doesn't seem to be getting any traction over there, and a similar issue at home-assistant/core#15259 looks even more dead.

You can read more issue details over in the bellows issue, but the bottom line is that zha lights work fine immediately following a Home Assistant restart. Then, over the course of a few hours, they disappear. They still show up in the UI, but they are entirely inoperative. After a homeassistant.restart call, the lights will all work again.

For some reason my Visonic MCT-340E door sensors never drop off, but all the lights eventually do, one at a time.

And here's the log message when I try to operate one of those missing lights (actually three at once):

2018-07-10 07:11:09 ERROR (MainThread) [homeassistant.core] Error executing service ServiceCall <light.turn_off: entity_id=['light.osram_lightify_a19_tunable_white_0001d4ac_3', 'light.osram_lightify_a19_tunable_white_0001e6c8_3', 'light.osram_lightify_a19_rgbw_000a381d_3']>
Traceback (most recent call last):
File "/usr/src/app/homeassistant/core.py", line 1021, in _event_to_service_call
await service_handler.func(service_call)
File "/usr/src/app/homeassistant/components/light/__init__.py", line 362, in async_handle_light_service
await light.async_turn_off(**params)
File "/usr/src/app/homeassistant/components/light/zha.py", line 127, in async_turn_off
await self._endpoint.on_off.off()
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.6/site-packages/bellows/zigbee/application.py", line 213, in request
assert sequence not in self._pending
AssertionError

And for the record, this is with the usual HUSBZB-1 stick, and I'm running 0.76.1 now, in Docker. This issue has persisted for a number of months now, and the wife acceptance factor is flirting with zero at this point.

Iris MOT800 won't join

A couple weeks ago I picked up some Iris 1st gen PIR sensors for $6 at Lowes. Today I tried getting them to join and I'm just having one heck of a time getting it to join the network. I can see the sensor attempt to join but it never completes the process. I am running homeassistant 0.82.0 on hassio on a NUC.

I'm guessing a quirk needs to be written for this device, but I'm not sure exactly what i'm looking at to even get started. Can someone point me to whats going on?

Here's the log (I ran HA logging with bellows and zigpy in debug, but removed the bellows lines):

2018-11-11 10:19:24 INFO (MainThread) [homeassistant.components.zha] Permitting joins for 60s
2018-11-11 10:19:25 INFO (MainThread) [zigpy.application] Device 0xa372 (00:0d:6f:00:03:b3:1f:d7) joined the network
2018-11-11 10:19:25 INFO (MainThread) [zigpy.device] [0xa372] Discovering endpoints
Config directory: /config
Tries remaining: 3
2018-11-11 10:19:37 INFO (MainThread) [zigpy.application] Device 0x85a7 (00:0d:6f:00:03:b3:1f:d7) joined the network
2018-11-11 10:19:37 DEBUG (MainThread) [zigpy.application] Device 00:0d:6f:00:03:b3:1f:d7 changed id (0xa372 => 0x85a7)
2018-11-11 10:19:37 DEBUG (MainThread) [zigpy.device] Canceling old initialize call
2018-11-11 10:19:37 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
r = await func()
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.6/site-packages/bellows/zigbee/application.py", line 241, in request
v = await send_fut
concurrent.futures._base.CancelledError
2018-11-11 10:19:37 INFO (MainThread) [zigpy.device] [0x85a7] Discovering endpoints
Tries remaining: 3
2018-11-11 10:19:49 INFO (MainThread) [zigpy.application] Device 0x4b8d (00:0d:6f:00:03:b3:1f:d7) joined the network
2018-11-11 10:19:49 DEBUG (MainThread) [zigpy.application] Device 00:0d:6f:00:03:b3:1f:d7 changed id (0x85a7 => 0x4b8d)
2018-11-11 10:19:49 INFO (MainThread) [zigpy.device] [0x4b8d] Discovering endpoints
Tries remaining: 3
Tries remaining: 2
2018-11-11 10:20:02 INFO (MainThread) [zigpy.application] Device 0x2deb (00:0d:6f:00:03:b3:1f:d7) joined the network
2018-11-11 10:20:02 DEBUG (MainThread) [zigpy.application] Device 00:0d:6f:00:03:b3:1f:d7 changed id (0x4b8d => 0x2deb)
2018-11-11 10:20:02 DEBUG (MainThread) [zigpy.device] Canceling old initialize call
2018-11-11 10:20:02 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
r = await func()
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.6/site-packages/bellows/zigbee/application.py", line 241, in request
v = await send_fut
concurrent.futures._base.CancelledError
2018-11-11 10:20:02 INFO (MainThread) [zigpy.device] [0x2deb] Discovering endpoints
Tries remaining: 3
Tries remaining: 1
2018-11-11 10:20:14 INFO (MainThread) [zigpy.application] Device 0x774a (00:0d:6f:00:03:b3:1f:d7) joined the network
2018-11-11 10:20:14 DEBUG (MainThread) [zigpy.application] Device 00:0d:6f:00:03:b3:1f:d7 changed id (0x2deb => 0x774a)
2018-11-11 10:20:14 INFO (MainThread) [zigpy.device] [0x774a] Discovering endpoints
Tries remaining: 3
2018-11-11 10:20:16 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization: Message send failure: EmberStatus.DELIVERY_FAILED
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
r = await func()
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.6/site-packages/bellows/zigbee/application.py", line 241, in request
v = await send_fut
zigpy.exceptions.DeliveryError: Message send failure: EmberStatus.DELIVERY_FAILED
Tries remaining: 2
Tries remaining: 2
Tries remaining: 1
2018-11-11 10:20:39 DEBUG (MainThread) [zigpy.zcl] [0x2feb:1:0x0202] ZCL request 0x000a: [[<Attribute attrid=0 value=<zigpy.zcl.foundation.TypeValue object at 0x7f2100189780>>]]
2018-11-11 10:20:39 DEBUG (MainThread) [zigpy.zcl] [0x2feb:1:0x0202] Attribute report received: 0=0
Tries remaining: 1
2018-11-11 10:20:46 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization: Message send failure: EmberStatus.DELIVERY_FAILED
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
r = await func()
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.6/site-packages/bellows/zigbee/application.py", line 241, in request
v = await send_fut
zigpy.exceptions.DeliveryError: Message send failure: EmberStatus.DELIVERY_FAILED
2018-11-11 10:20:56 DEBUG (MainThread) [zigpy.zdo] [0x6c34:zdo] ZDO request 0x0000: [00:0d:6f:00:04:26:39:3c, 0, 0]
2018-11-11 10:20:56 DEBUG (MainThread) [zigpy.zcl] [0x6c34:1:0x0006] ZCL request 0x000a: [[<Attribute attrid=0 value=<zigpy.zcl.foundation.TypeValue object at 0x7f20fdb7f4e0>>]]
2018-11-11 10:20:56 DEBUG (MainThread) [zigpy.zcl] [0x6c34:1:0x0006] Attribute report received: 0=Bool.false
2018-11-11 10:20:58 DEBUG (MainThread) [zigpy.zdo] [0x6c34:zdo] ZDO request 0x0000: [00:0d:6f:00:04:26:39:3c, 0, 0]
2018-11-11 10:20:58 ERROR (MainThread) [zigpy.device] Failed ZDO request during device initialization: Message send failure: EmberStatus.DELIVERY_FAILED
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 51, in _initialize
epr = await self.zdo.request(0x0005, self.nwk, tries=3, delay=2)
File "/usr/local/lib/python3.6/site-packages/zigpy/util.py", line 52, in retry
r = await func()
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.6/site-packages/bellows/zigbee/application.py", line 241, in request
v = await send_fut
zigpy.exceptions.DeliveryError: Message send failure: EmberStatus.DELIVERY_FAILED

[REQUEST] Zigpy support for ZiGate ( http://zigate.fr ) open source ZigBee USB adapter hardware

Please consider supporting the ZiGate open source ZigBee USB adapter hardware and its firmware in zigpy.

ZiGate is a open source ZigBee USB adapter that was initially launched on Kickstarter by @fairecasoimeme

Update!: Apparently @doudz have already started development here:

@doudz has published zigpy-zigate v0.1.0 which has experimental support for ZiGate to Zigpy

zigpy-zigate 0.1.0 release on PyPI

Requires ZiGate firmware 3.1a or later firmware version which has added a raw mode

The Zigate USB adapter communicates via a PL2303HX Serial interface module. Here is the documents that layout the communication protocol used by the Zigate:

Developer @elric91 has a "pyzigate" Python library for ZiGate that is being developed here:

He @elric91 has also made a ZiGate component for Home Assistant which might help the HA side(?):

Additional inputs for SmartThings multipurpose sensors

I've been digging into the code a bit to see if there might be a mechanism to map the inputs on the SmartThings multipurpose sensors. I saw that 0x402 (1026) maps the temperature sensor and that works in HA.

Other inputs include:

  • 0xFC02 (64514) tilt and acceleration. attr 0x0010->acceleration, 0x0012->x-axis 0x0013->y-axis 0x0014->z-axis
  • 0x500 (1280) zone status, attr 2, 32=closed and 33=open

If anyone has any suggestions I'm willing to help do some leg work. I do see that 0x402 (1026) is mapped in zha.py and that's the temperature sensor. Thanks!

Support Custom ZDO Response

I have several Iris SmartPlugs (V1) that require a custom response to the Match Descriptor request. Not sure what the best path forward on this is, but it would be beneficial if we could support manufacturers that don't follow the standards at the ZDO level. Below is my replacement handle_match_desc that allows for the join, these devices respond on profile 0xc216 and require a slightly different payload.

def handle_match_desc(self, addr, profile, in_clusters, out_clusters):                                                           
       local_addr = self._device.application.nwk                                                                                    
       self.debug('Match Desc %s' % profile)                                                                                        
       if profile == 260:                                                                                                           
           response = (0x8006, 0, local_addr, [t.uint8_t(1)])                                                                       
       elif profile == 0xc216:                                                                                                      
           response = (0x8006, 0, local_addr, [t.uint16_t(258)])                                                                    
       else:                                                                                                                        
           response = (0x8006, 0, local_addr, [])                                                                                   
       self.reply(*response) 

Thanks

Python 3.4 support

I know support of python 3.4 has been dropped #5 when HA did it too but since zigpy is supposed to be "universal" I think it could be useful to still support python 3.4 for other system.
For example Jeedom still use python 3.4 on some hardware

Additionnally Python 3.4 is not dead yet, the next release 3.4.10 is planned for March 2019
https://www.python.org/dev/peps/pep-0429/

Low-level hardware specialization

Specialization cannot be exclusively handled above the zigpy abstraction level as some devices require low-level adjustments. One distinguished example is the IKEA Trådfri devices which need to use the ZHA profile ID in the APS frame in ZCL communication.

attribute cache expiration

We should have some sort of cache expiration for attributes. Currently (if I understand the code correctly) the attribute cache is updated only when:

  • an attribute report is received
  • an "uncached" Read_Attribute command is issued

so if a zigbee device never sends "attribute reports" and application is only using "cached" attribute_reads, then the attribute cache goes stale.
For example, zha.light component in Home Assistant:

  1. I started hass (0.70.dev.0)
  2. changed the color and brightness of the bulb
  3. stopped hass
  4. started and stopped hass two times, nothing was changed/controled. Here what async_update() was getting when light was initialized and "updated_before_add":
    image
    image
  5. after that I stopped has and read the same attributes with bellows which makes an "uncached" read
(venv-dev) kex@deb:~/kex/src/ac-hass$ bellows zcl 7c:b0:3e:aa:00:a4:55:95 3 6 read_attribute 0
0=Bool.false
(venv-dev) kex@deb:~/kex/src/ac-hass$ bellows zcl 7c:b0:3e:aa:00:a4:55:95 3 8 read_attribute 0
0=119
(venv-dev) kex@deb:~/kex/src/ac-hass$ bellows zcl 7c:b0:3e:aa:00:a4:55:95 3 768 read_attribute 3
3=9895
(venv-dev) kex@deb:~/kex/src/ac-hass$ bellows zcl 7c:b0:3e:aa:00:a4:55:95 3 768 read_attribute 4
4=22478
  1. after reading the same attribute with bellows I started hass again and this time it read "correct" cached attributes:
    image

for zha.light I can alleviate the issue if I don't load "attribute cache" from the database. But it still not addresses the issue of the cache going stale, since zha.light does not configure attribute reporting.

So 1st question: do we really need to fill the cache from DB upon cold start?
2nd question: is attribute cache updated on getting a successful attribute write? I don't think so, but would like to confirm

Sylvania Lightify Smart+ Dimmer Switch not Passing Button Presses

I apologise in advance if this is the wrong place but I was directed to come here to raise an issue with the component. My Lightify Smart+ Dimmer Switch is only showing an on/off state and brightness attribute. The component does not seem to be passing event clicks to Home Assistant.

For example if the switch state is 'on' and I press the 'on' button, nothing gets sent to Home Assistant. This causes problems with my switch getting out of sync with the device that it is controlling. Is there a way to resolve this?

Thanks!

Request for a new release

Hello,

in order to get my bulbs working in hass.io i have to do some dirty build hacks to get this fix(#36 ) included in the default home assistant docker setup procedure. Have you planned a new release, if not, it would be pretty nice, if you can publish a new release (0.0.4) based on the commit state of #36 .

Thanks

Receiving "read_attribute" request from the network on Time cluster throws error

For whatever reason I started receiving read_attribute requests from Zigbee devices directed to coordinator, which causes the following error message in the logs:

2018-12-22 18:32:01 DEBUG (MainThread) [bellows.uart] Data frame: b'6368b157546f15b6589e4a24ab1593499cbfd86485539874f8c67789fb7e3bc1247e'
2018-12-22 18:32:01 DEBUG (MainThread) [bellows.uart] Sending: b'87009f7e'
2018-12-22 18:32:01 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received
2018-12-22 18:32:01 DEBUG (MainThread) [zigpy.zcl] [0x9d68:1:0x000a] ZCL request 0x0000: [[7]]
/home/lex/lex/src/zigpy/zigpy/zcl/clusters/general.py:351: RuntimeWarning: coroutine 'request' was never awaited
  self.write_attributes(data, True)

write_attributes() is a coroutine, isn't it? Enclosing self.write_attributes() into asyncio.ensure_future() fixes it for me, but I'm not sure whether this is correct or not?

Quirks handling can overwrite persisted device signature

The quirks implementation can cause the real signature for a device to get overwritten in the database. If this happens the quirk will not match again after a restart because the "replacement" signature is stored in the database now and not the original signature.

I have seen 2 different things cause this:

  1. forcing a device to rejoin that hasn't actually been removed from the network
  2. a device rejoining on its own with a different nwk value
    def handle_join(self, nwk, ieee, parent_nwk):
        LOGGER.info("Device 0x%04x (%s) joined the network", nwk, ieee)
        if ieee in self.devices:
            dev = self.get_device(ieee)
            if dev.nwk != nwk:
                LOGGER.debug("Device %s changed id (0x%04x => 0x%04x)", ieee, dev.nwk, nwk)
                dev.nwk = nwk
            elif dev.initializing or dev.status == zigpy.device.Status.ENDPOINTS_INIT:
                LOGGER.debug("Skip initialization for existing device %s", ieee)
                return
        else:
            dev = self.add_device(ieee, nwk)
    
        self.listener_event('device_joined', dev)
        dev.schedule_initialize()
    

both paths cause dev.schedule_initialize() to get called. This results in raw_device_initialized being fired again after the "initial join". This is after quirks have been matched (which happened either at zigpy startup for an existing device or when the device joined the first time for a new device) and because of that the modified device is what exists in memory. This causes the replacement signature to overwrite the original signature in the database. If the signature deviates from the real signature in any way, all future quirks matching for the device will fail.

Remove magic numbers from source code

Currently, there are a lot of magic numbers in the source which could be removed. Use names/constants instead of numbers when e.g. referring to a command.

[RFC] add `message_type` to `ControllerApplication.handle_message()`

Add message_type to handle_message() method to provide some context to upper layer app handlers, particularly whether the received message was a

  • Unicast
  • Broadcast
  • Multicast

Primarily the driver for this is handling of ZDO NWK_addr_req and IEEE_addr_req requests, as reply to those request could be different depending whether the request was a Unicast or Broadcast

[RFC] OTA Support

Implementing support for OTA upgrades would practically eliminate the need for unnecessary hubs. Below is the event listener I used to successfully upgrade six IKEA Trådfri 1000lm bulbs (copied from an unrelated issue):

import asyncio
import logging
import contextlib

from collections import defaultdict

import aiohttp
from zigpy.zcl.foundation import Status
from zigpy.zcl.clusters.general import Ota

logging.basicConfig(level=logging.DEBUG)
logger = logging.getLogger(__name__)



class HerdLock:
    '''
    A lock that indicates to the caller if they are the first to acquire it.
    If not, the context manager waits until the lock is released. Used like this:

        lock = HerdLock()
        expensive = None

        async def worker():
            async with lock('LOCK_NAME') as is_first:
                if is_first:
                    print('Actually performing task')
                    await asyncio.sleep(5)
                    expensive = 'got it'

            # Here we can assume `expensive` is set and that only one worker actually fetched it
            print(expensive)

        await asyncio.gather(worker(), worker(), worker(), worker())
    '''

    def __init__(self):
        self.semaphores = defaultdict(asyncio.Semaphore)

    @contextlib.asynccontextmanager
    async def __call__(self, key):
        semaphore = self.semaphores[key]

        try:
            is_first = not semaphore.locked()

            async with semaphore:
                yield is_first
        finally:
            # Delete the lock if we're the last one to release it
            if not semaphore.locked():
                self.semaphores.pop(key, None)


class TrådfriOTAMainListener:
    UPDATE_URL = 'https://fw.ota.homesmart.ikea.net/feed/version_info.json'
    OTA_HEADER = 0x0BEEF11E.to_bytes(4, 'little')
    MAXIMUM_DATA_SIZE = 40

    def __init__(self):
        self._firmware_cache = {}
        self._lock = HerdLock()

    def cluster_command(self, tsn, command_id, args, ota_cluster):
        asyncio.create_task(self._cluster_command(tsn, command_id, args, ota_cluster))

    async def _cluster_command(self, tsn, command_id, args, ota_cluster):
        if not self._firmware_cache:
            logger.info('Downloading firmware update list from IKEA')

            async with self._lock('DOWNLOAD_VERSION_INFO') as was_first:
                if was_first:
                    async with aiohttp.ClientSession() as client:
                        async with client.get(self.UPDATE_URL) as response:
                            firmwares = await response.json(content_type='application/octet-stream')

                        self._firmware_cache.clear()

                        for fw in firmwares:
                            if 'fw_file_version_MSB' not in fw:
                                continue

                            fw['fw_file_version'] = (fw['fw_file_version_MSB'] << 16) | fw['fw_file_version_LSB']
                            self._firmware_cache[(fw['fw_manufacturer_id'], fw['fw_image_type'])] = fw

        if command_id == 0x0001:  # query_next_image
            field_control, manufacturer_code, image_type, current_file_version, hardware_version = args
            key = (manufacturer_code, image_type)

            logger.info('Received an OTA image query from %s', ota_cluster.endpoint.device)

            # We don't know what this device is
            if key not in self._firmware_cache:
                await ota_cluster.query_next_image_response(Status.NO_IMAGE_AVAILABLE, 0x0000, 0x0000, 0x00000000, 0x00000000)
                return

            fw = self._firmware_cache[key]

            # Tell the device we're ready to continue
            await ota_cluster.query_next_image_response(Status.SUCCESS, manufacturer_code, image_type, fw['fw_file_version'], fw['fw_filesize'])
        elif command_id == 0x0003:  # image_block
            field_control, manufacturer_code, image_type, \
            file_version, file_offset, maximum_data_size, \
            request_node_address, block_request_delay = args

            # We assume at this point we won't be getting unsolicited requests for blocks
            key = (manufacturer_code, image_type)
            fw = self._firmware_cache[key]

            # Download the firmware on demand
            if 'fw_data' not in fw:
                async with self._lock(f'DOWNLOAD_FW:{fw["fw_binary_url"]}') as was_first:
                    if was_first:
                        async with aiohttp.ClientSession() as client:
                            async with client.get(fw['fw_binary_url']) as response:
                                data = await response.read()

                        # The IKEA images wrap the Zigbee OTA file in a container
                        offset = data.index(self.OTA_HEADER)
                        fw['fw_data'] = data[offset:offset + fw['fw_filesize']]
                        assert len(fw['fw_data']) == fw['fw_filesize']

            logger.debug('Firmware upgrade progress: %0.2d', 100.0 * file_offset / fw['fw_filesize'])
            data = fw['fw_data'][file_offset:file_offset + min(self.MAXIMUM_DATA_SIZE, maximum_data_size)]

            await ota_cluster.image_block_response(Status.SUCCESS, manufacturer_code, image_type, file_version, file_offset, data)
        elif command_id == 0x0006:  # upgrade_end
            status, manufacturer_code, image_type, file_version = args

            # Upgrade right now
            await ota_cluster.upgrade_end_response(manufacturer_code, image_type, file_version, 0x00000000, 0x00000000)


class TrådfriOTAListener:
    def __init__(self, ota_cluster, main_listener):
        self.ota_cluster = ota_cluster
        self.main_listener = main_listener

    def cluster_command(self, tsn, command_id, args):
        logger.info('Received an OTA cluster command from %s', self.ota_cluster.endpoint.device)

        self.main_listener.cluster_command(tsn, command_id, args, self.ota_cluster)

The Trådfri remotes seem to work too. Unfortunately, I was not able to get my RGB bulbs to upgrade despite a newer firmware version being available so I believe further device quirks will need to be handled by https://github.com/dmulcahey/zha-device-handlers. The core OTA functionality, however, should belong in zigpy since it doesn't depend on any specific adapter interface and can basically be a transcription of the process described in the Zigbee specification (see pages 27+).

What do you think?

Ikea tradfri discovery throws exception

I'm trying to join an ikea tradfri bulb to home-assistant (v0.63.0), and I traced back the error to this exception:

bellows -d/dev/ttyUSB0 permit -D /config/zigbee.db
Joins are permitted for the next 30s...
Device 0x8bb4 (address) joined the network
[0x8bb4] Discovering endpoints
Device 0x796f (address) joined the network
[0x796f] Discovering endpoints
[0x796f] Discovered endpoints: [1]
[0x796f:1] Discovering endpoint information
[0x796f:1] Discovered endpoint information: <SimpleDescriptor endpoint=1 profile=49246 device_type=544 device_version=2 input_clusters=[0, 3, 4, 5, 6, 8, 768, 2821, 4096] output_clusters=[5, 25, 32, 4096]>
Failed ZDO request during device initialization: ('Endpoint request failed: %s', [129, 35764, []])
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 54, in _initialize
    raise Exception("Endpoint request failed: %s", epr)
Exception: ('Endpoint request failed: %s', [129, 35764, []])
Done

The device itself:

bellows -d/dev/ttyUSB0 devices -D /config/zigbee.db
Device:
  NWK: 0x796f
  IEEE: (address removed)
  Endpoints:
    1: profile=0xc05e, device_type=DeviceType.COLOR_TEMPERATURE_LIGHT
      Input Clusters:
        Basic (0)
        Identify (3)
        Groups (4)
        Scenes (5)
        On/Off (6)
        Level control (8)
        Color Control (768)
        Diagnostic (2821)
        LightLink (4096)
      Output Clusters:
        Scenes (5)
        Ota (25)
        Poll Control (32)
        LightLink (4096)

The coordinator is a Telegesis EZSP dongle, and I don't yet have a tradfri hub, so the bulb might have old firmware.

Samsung Arrival sensor

Hi folks,
can anyone help with supporting Samsung Arrival sensors (they are so handy for tracking the presence of a car when left in the cup holder ;) )

Many thanks

Attribute Report prior to Init causes exception

If a device reports an attribute value prior to completing initialization. The attribute will be written to the database, but the corresponding device entry isn't created. This will cause an exception during the Home Assistant startup and prevent any ZHA devices from working until the database is manually edited to remove the offending entry.

homeassistant==0.88.0.dev0
zigpy==0.2.0
zigpy-xbee==0.1.1

2019-02-03 11:20:15 ERROR (MainThread) [homeassistant.config_entries] Error setti
ng up entry /dev/ttyUSB0 for zha                                                 
Traceback (most recent call last):                                               
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/config_entri
es.py", line 258, in async_setup                                                 
    result = await component.async_setup_entry(hass, self)                       
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/z
ha/__init__.py", line 140, in async_setup_entry                                  
    application_controller = ControllerApplication(radio, database)              
  File "/srv/homeassistant/lib/python3.5/site-packages/zigpy_xbee/zigbee/applicat
ion.py", line 15, in __init__                                                    
    super().__init__(database_file=database_file)                                
  File "/srv/homeassistant/lib/python3.5/site-packages/zigpy/application.py", lin
e 25, in __init__                                                                
    self._dblistener.load()                                                      
  File "/srv/homeassistant/lib/python3.5/site-packages/zigpy/appdb.py", line 214,
 in load                                                                         
    dev = self._application.get_device(ieee)                                     
  File "/srv/homeassistant/lib/python3.5/site-packages/zigpy/application.py", lin
e 116, in get_device                                                             
    return self.devices[ieee]                                                    
KeyError: 00:13:a2:00:40:c0:4e:54 

Use python3.5+ await syntax

Home assistant is dropping python3.4 support, so it's time to update the zigpy syntax to use the await syntax. This also improves the support to e.g. spot unawaited futures.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.