Zigbee with Python

With my custom made devices I’m using custom data structures and ZigBee is used only as a data transport protocol. However, having more and more standard ZigBee devices available, I started to look for some standard ZigBee features implementation in Python. Unfortunately wasn’t really able to find anything which would fit the purpose – ZigBee feature implementation decoupled from manufacturer specific elements and covering ZDO/ZCL processing/parsing as per ZigBee standard.

There are usually three groups of references coming up in search results:

  • XBEE python package, which provides a tool which handles XBEE api, however has nothing to do with ZigBee as such. I’m already using this library with slight modifications today to handle XBEE api in my application.
  • bellows python package, which gets really close to what I’m looking for, but is very much linked with specific manufacturer device api.
  • custom implementations of specific ZigBee ZCL/ZDO requests for specific devices as part of some project.

So I decided to look a bit more into bellows package. Quite quickly I was able to simulate parsing of ZCL/ZDO messages, but few of the general concepts were not exactly matching my expectations. So to make it work for me either I had to implement EZSP uart protocol in my coordinator device, or rewrite several parts of library which would anyway require quite good understanding of ZDO/ZCL stuff. Unfortunately neither was looking as a quick and simple option.

The only option left was to dig into ZigBee ZDO/ZCL details and create some kind of prototype library by myself to get better understanding what I can get out of standard features, the complexity of implementation, and then decide to have another look on bellows package or continue with own library creation.

Xiaomi Zigbee sensors

Recently I noticed Xiaomi Zigbee sensors being available for quite reasonable price, could not resist and bought few from each of the available types – temperature/humidity sensor, motion sensor, door/window open sensor and button/switch.

All my current devices are custom built and are not using proper ZHA profiles and clusters, as first devices built which are still in use were using XBEE devices, I continued to use the same profile/cluster/endpoint scheme to keep compatiblity between all devices. And it was quite nice surprise that when I tried to link new devices with some Zigbee network, they found my development coordinator and connected to it, and started to send signals, which even reached software but were not processed due to the missing support for standard HA devices.

Sensors are quite nicely made, and to my surprise were using the same NXP JN5168 chips I have chosen for my devices – this should eliminate majority of Zigbee stack incompatibility issues, like disconnects I have been reading about in some forums where these sensors were used with non-Xiaomi gateways.

The only complain I could think about at the moment is missing temperature sensor endpoint on motion sensor – having just one sensor which reports both temperature readings and presence/motion would be really nice feature, as instead on two sensors it would be just one.

New version of Zigbee coordinator/gateway.

Having better understanding of features provided by NXP JN5168, I understood that I need to create next generation of coordinator/gateway device at least for development purposes.

The main issue I wanted to solve was messy setup with connections to coordinator board – coordinator board had uart in/out and I used usb->uart dongles to connect board to pc. As I absolutely love dual uart functionality (one for communication with application, one for debug/info output), it was even more messy with two dongles and two connections to board.

So the new board of course has my current favorite Zigbee chip from NXP – JN5168, and I went with FD2232D which provides dual uart functionality with single usb connection. Added few pushbuttons for reset/programming mode and command button (not used yet, but who knows), and also I2C header in case I’ll decide to add some extra features later.

Regarding firmware of JN5168 – I’m still sticking with XBEE compatible API for communication with application, as it’s simple enough and at the same time provides all the necessary information, as well as provides certain level of compatibility with XBEE devices.