Q1/Q2 Development in 2025
It has been a bit quite the last months. So while we catch up with posts and issues and new releases, I’d like to give a first small overview of what’s next.
New product FLS-M
This is a new LED controller which enhances our 2013 FLS-PP lp RGBW controller greatly. It’s a configurable device that supports RGB/W, color temperature, monochromatic and addressable LED strips. Beside Zigbee the FLS-M also speaks Matter over WiFi all on one device. Learn more about it at FLS-M Overview
Phoscon App
The main user interface of the Phoscon App has been redesigned to present lights, scenes, group as well as sensors and rooms in form of a drag and drop dashboard – gone are the list based interface which only covered lights and groups. The goal here is to support all kinds of devices which exist nowadays in the less technical Phoscon App. Our plan is to release this in February in the app store as a beta version and would like to hear your feedback.
deCONZ
Following GCFFlasher firmware update tool, in 2024 deCONZ was released as Open Source https://github.com/dresden-elektronik/deconz. The direction for deCONZ is to continue making the core application simpler and creating foundation libraries (deconz-lib) which are used by deCONZ as well as plugins like the REST-API plugin in order to phase out Qt over time, and be able to split deCONZ GUI from core.
One important milestone is that the serial connection between deCONZ and the RaspBee/ConBee will be handled by GCFFlasher. That lets us get rid of QtSerialPort library since GCFFlasher is dependency free. As a side effect this allows us to run GCFFlasher with ConBee/RaspBee connection on one machine, like a Raspberry Pi and deCONZ on another one like a PC.
Device support
Over time the community made hundreds of new DDFs (Device Description Files) in order to support over 380 devices. In most cases the code base doesn’t need to be changed. Last year we got DDF bundles for easier sharing of new supported devices without the need to update deCONZ. It is also now possible to run different versions of a DDF for specific devices. The automated machinery on Github checks that DDFs are valid before merging and creates a DDF bundle which can be tested without waiting for a new deCONZ release (except for devices which require changes in of a new release).
While the groundwork is done, a focus in Q1 2025 is to fix the rough edges asap. For example currently reloading DDFs isn’t as smooth as it should be and can require a deCONZ restart. There are still issues in the DDF and bundle loading code that are under investigation. Significant parts of the C++ code base are too fixed for devices and types and need to be made more generic so we can give more power to DDFs, the related GitHub Pull Requests are usually more complex, e.g. PR #7979 so these are merged in wider release cycles.
When adding support for new devices currently a dummy DDF is created automatically which guesses how the device works, but the DDF is not active, the “unknown” device is basically running on legacy code, which mostly only works for lights. A better way for doing this is to improve the automatically generated DDF and activate it. This way we rely less on whatever the old code base was doing, and get a DDF that can be adjusted. For lights, power plugs and certain sensors like the IAS ones (open/close, occupancy, alarm, etc.) a generic approach for basic functionality is often possible. While specific functionality like attribute reporting, special effects in some lights and similar features needs to be adjusted manually in the DDF, the base functionality can be identified for many of these devices and be activated by default.
Tuya clone army
Random new Tuya branded devices pop up almost every week. We can’t really automate supporting all these. However it must become simpler to provide the necessary information what new Tuya devices are sending in order to create an appropriate DDF if they are in fact new.
One thing which has become clear is also that Tuya devices are a clone army. For example looking at the Tuya presence sensor DDF https://dresden-elektronik.github.io/deconz-rest-doc/devices/tuya/ts0202_presence_sensor that is one device which (currently) goes by 25 manufacturer name/modelid combinations. Every time a new clone pops up: 1) a user has to create a Github issue, 2) a developer has to look at it, 3) identify what’s going on, 4) extend the DDF, 5) create a PR and 6) wait for merge and release.
The thing is, we now have DDFs which deCONZ can query, and we can look on a yet unknown Tuya device and check if this is with likely just a clone which needs to be added to an existing DDF. For this we can look at the model, clusters and endpoints used by the DDF and if they match with what the device reports and there is only one DDF describing this, let’s call it bingo and automatically activate it.
In summary this can reduce a process of weeks to support Tuya clones to a second or two and free developer resources. The actual DDF should still be updated to pop up in supported devices list but for users the wait time is removed.
Continue reducing legacy code
The elephant in the room is and will be for quite a while the old legacy code, which runs side by side to DDFs. These are two sub-systems trying to fight over who can do the job. In 2024 this brought more trouble to surface as we got more devices running on DDFs. Therefore we will continue to remove old code in favor of DDFs and add general code instead. This is rather painful work as it can only be done in small steps to not cause constant havoc with unexpected bugs. The old code contains hundreds of if/else branches for various device types and worse specific devices by model or manufacturer.
In short as we continue to cut old ties, the more the deterministic machinery behind DDFs can do its work without getting undermined by old code.
A recent example is PR #8074 removes ability from old code to issue commands in parallel to DDFs (aka device poll scheduling).
REST-API
For REST-API plans there will be separate detailed post. One goal is to continue to cleanup the internals and split out device and vendor specific handlers. The devices/ endpoint reading side needs to be completed and hooked into Websocket events. Last year we got the capabilities for devices in DDFs for lights. The API should also dynamically make use of this information so we can phase out more modelid specific code.
RaspBee II and ConBee II / III firmware
RaspBee II and ConBee II will soon get a new firmware release to fix rare but nasty bug which causes total chaos for a network. As a side note behind the scenes the development setup for firmware has moved and it’s now much easier to create and debug new firmware releases.
For ConBee III there will also be firmware improvements, we have collected a list of bugs to be fixed fix. This was unfortunately on hold during the FLS-M development.
Summary
In this post I haven’t touched all topics but hopefully a coarse overview of the next important steps.
- Getting rid of bugs, focus of the long standing ones
- Automate basic device support and Tuya clones where possible
- Continue to moving the code base away from legacy code
- Continue to move towards smaller, generic and Qt free code base