Description
ZHA integration relies on python modules providing interface to Zigbee radios/network and all those modules are using zigpy library for basic ZCL/ZDO interfaces and a basic ControllerApplication.
With diversification of supported modules/protocols, it become problematic to have an uniform interface between ZHA and respective radio module/library, because technically ZHA is not integrating with Zigpy, but with the radio module itself. In other words zigpy has just a subset of configuration options a given radio module could implement.
With that in mind in 0.20.0 we introduced schemas/configuration dict as a mean to pass parameters from ZHA integration to radio lib implementing interface with the radio.
Most (All?) Zigpy based libraries are currently following this layout:
zigbee.application.ControllerApplication() <->API() <--> Uart()
The idea was to have a "configuration" dict which we could pass to ControllerApplication() instance and let it parse, handle and pass the required bits to the underlying layers like API() and Uart/Gateway() instances.
My idea was to allow Zigpy to define schema which affects configuration options independent of the radio being used (e.g. OTA) or options which can be implemented by all the radios (e.g. permit()) using zigpy.
Radios are allowed to extend this schema and include radio specific options.
ATM, current Zigpy schema could be represented by the following .yaml
database_path: /config/zigbee.db
ota:
ikea_provider: False
ledvance_provider: False
otau_directory: /config/zigpy_ota
device:
path: /dev/ttyUSB0And for example bellows extends the above schema with the following options:
device:
baudrate: 57600
source_routing: False
ezsp_config:
CONFIG_APS_UNICAST_MESSAGE_COUNT: 10
CONFIG_ROUTE_TABLE_SIZE: 16
....Making it all work with ZHA integration config entry options is going to be an interesting challenge (for @dmulcahey :) but that's another story.
I'm open for feedback/suggestions whether it meets the current needs and/or what could be improved?