This beta release is the successor of v2.14.1 version.
Changes
- DDF for Niko connected socket outlet 170-33505/170-33605 #5813
- DDF for Xiaomi Aqara temperature/humidity/pressure sensor WSDCGQ11LM #5812
- DDF for Develco MOSZB-140 motion sensor #5794
- DDF for Develco/frient SMSZB-120 smoke detector #5810
- DDF for Develco/frient heat detector HESZB-120 #5811
- DDF for Bosch BWA-1 water sensor #5858 #5188
- DDF for LK Fuga Wiser socket outlet LK/OUTLET/1 #5766
- DDF for OWON THS317-ET Multisensor (temp probe support) #5777
- DDF for Frient Keypad KEPZB-110 #5850
- DDF file for Shneider Electric Wiser Plug 16A #5845
- DDF for Danfoss Ally temperature and humidity sensor #5855
- DDF for Develco/frient temp/hum sensor HMSZB-110 #5856
- DDF support Tuya manufacturer specific cluster #5868
- DDF for Merten MEG5113-0300 cover controller #5873
- DDF for MoesGo/Tuya Smart Dimmer Module (_TZE200_e3oitdyu) #5869
- DDF for Aqara E1 roller shade (lumi.curtain.acn002) #5851
- Add config/enrolled resource item for MCCGQ14LM to allow sensor usage #5822
- Trigger manufacturer name read and consider it while selecting DDF #5789
- Correct consumption values for innr SP120 smart plug #5814
- Extend functionality of LK FUGA Wiser Wireless Battery 4 Button Switch #5772
- Improvements for window covering devices #5619
- Support Essentials radiator thermostat (_TZE200_jeaxp72v) #5405
- Support Sunricher ZG2833K4_EU06 #5619
- Securely generate network key when resetting adapters #5833
- Add missing manufacturer code for reading Develco/frient firmware version #5795
- Fix warnings about uneeded copies in Qt containers #5834
- Fix REST response when setting a schedule’s localtime attribute #5806
- Fix sunriseoffset/sunsetoffset for Daylight sensor #5619
- Fix detection of GIRA/JUNG switches #5880
- Fix missing description.xml on Linux.
- Fix showing clusters with id 0xFFFF in Cluster Info Panel.
- Fix slow group casts, the delay will only be applied when firmware reports full broadcast table.
- Show all neighbor lines if minimuk LQI value is set to 0 (like in older deCONZ versions).
A special thanks to all contributors of the deCONZ GitHub community.
Development overview
You may have noticed that the word DDF occurs quite often in recent changelogs, as we get more and more devices into the new system of supporting devices. We’re also starting to remove device specific C++ code which is now handled by DDF, less code, less bugs and chances for regressions.
It’s still a long way to go to transform the whole code base to the new system. The focus currently is to make solid steps and improve the DDF capabilities with devices which are physically available to verify and test new features as well fixing bugs a long the way. One example is the Tuya PR in this release.
Over time the legacy C++ codebase needs to shrink and will get a lot faster than what we have today.
Next larger steps here are:
- Build up comprehensive documentation around DDF
- Improve the DDF editor, e.g. with writing ZCL attributes
- Support handling switches via DDF alone with editor support
- Support huge number (thousands) of DDFs and only load the ones needed.
So far the abstractions introduced by DDF work out pretty well for devices which can already be supported by DDF.
Matter
As the official Matter launch comes closer the question arises if ConBee II or deCONZ will support it. Here are some thoughts on that.
Matter Bridge API
To bring your existing Zigbee devices into the Matter world deCONZ needs to provide a Matter Bridge API, this is what the Philips Hue bridge is planning and allows Apple Siri and Amazon Alexa to communicate with the devices. This is pretty brilliant as for the first time there would be only one gateway API needed.
The DDF system playes a big part here as it allows us to go in that direction once the API side is abstracted as well. If all unknown can be ruled out this is definitely the way to be future proof.
Important: Technically this is all possible, but the big unknown is wherever Apple Siri would talk to an Zigbee device of our bridge if the device is not Matter certified. The Matter specification isn’t clear about this, hopefully only the bridge needs to be certified.
Thread Border Router
As for the ConBee II (spoiler and it’s successor) it can’t run Zigbee and Thread at the same time, but the OpenThread support as Thread border router is planned to be able to bridge Thread and IP networks, note this is completely seperated from deCONZ itself and a smaller self contained project.
So ideally it turns out that we can support the Matter Bridge API, in the expectation that the Matter big players also allow non certified end-devices and at most the bridge needs to be certified (and this is a big if).
Matter client
Beside exposing Zigbee devices to the Matter world, the other way around is also very interesting, deCONZ as a Matter client could talk to Matter end-devices. For example this allows the deCONZ rule system to let a Zigbee switch control a Matter light. The hurdles here seem lower than the Matter Bridge API.
The following diagram shows one possible way how things could be put together:
deCONZ GUI
The work on a new UI has started a while ago, and while it’s a long way to go before an release I’d like to share a few insights. The new UI is a separate application talking to the deCONZ REST-API and leverages DDF.
Specs:
- For Android, iOS, Windows, Linux and macOS
- Native fast code, no Qt, Electron or other frame works
- Handle 500 devices or more easily
- Uses at most 50 MB RAM
- Uses a gateway abstraction, not limited to deCONZ (e.g. Matter client)
- Shows device states like sensor values and light on/off/color
Visually it’s a FUI (Future User Interface) which can often be seen in Sci-Fi films.
With all our weird devices and countless values theres a lot that can be shown and controlled 
To get an idea what a FUI is, watch this little video:
(the UI won’t be that busy or convoluted but the style is a nice fit for Home Automation compared to usual boxy dashboards)