Verified supported devices

aidbish · July 6, 2021, 10:00am

Would be a good idea to have a locked post that only admins can add to that lists verified devices that work with deConz after being device support is added. If possible include the automation system it also works with (Home assistant, OpenHab, ioBroker etc), Manufacturers name and model descriptor being mandatory items to be listed
This would then be searchable and users directed to search there initially before requesting device additions

SoulAssassin · July 6, 2021, 10:05am

This information is already provided by blakadder, check it:

aidbish · July 6, 2021, 10:07am

Has been know to be wrong, i have checked before for a couple of devices that deconz is supposed to support but ended up requesting device support.

Preferable to list supported by the developers themselves rather than 3rd party which could be incorrect

SoulAssassin · July 6, 2021, 10:10am

Well, we need to start updating the information on the github page:

aidbish · July 6, 2021, 10:12am

yes, but github will become less used, and so the forum should now hold that information and updated as devices are added.

manup · July 6, 2021, 11:22am

In this regard future development will focus on having a clear picture about every supported device.
Every device gets described in a Device Description JSON file (DDF) from which the documentation, supported devices and other lists are automatically generated. The idea is also to embed how well a device works, if it tested and known gotchas. Even things like which 3rd party integration supports it could be part of it.

Early preview off auto generated documentation based on DDF can be found at Supported Devices - deCONZ REST-API

aidbish · July 6, 2021, 11:28am

Nice.
Could the model descriptor be listed for easy searching, especially those tuya devices as they seem to be same device just different codes sometimes.

aidbish · July 6, 2021, 11:30am

Also, could those DDF files be user generated, so that end users could try adding device support themselves early on and then submit them for inclusion
A bit like they can do with zigbee2mqtt herdsman or zha quirks files?

Edit: just read the v2 plugin link and it looks like these could be user generated?

manup · July 6, 2021, 11:57am

For cryptic things like the Tuya model identifiers and manufacturer names we’ll use mapping to some sane human readable identifiers. In the C++ part we already started to use this internally to not go crazy

github.com

dresden-elektronik/deconz-rest-plugin/blob/master/product_match.cpp

/*
 * Copyright (c) 2021 dresden elektronik ingenieurtechnik gmbh.
 * All rights reserved.
 *
 * The software in this package is published under the terms of the BSD
 * style license a copy of which has been included with this distribution in
 * the LICENSE.txt file.
 *
 */

#include <regex>
#include <deconz/dbg_trace.h>

#include "product_match.h"
#include "resource.h"

/*! The product map is a helper to map Basic Cluster manufacturer name and modelid
   to human readable product identifiers like marketing string or the model no. as printed on the product package.

   In case of Tuya multiple entries may refer to the same device, so in matching code

This file has been truncated. show original

For a supported devices webpage which is based on DDF it shall be possible to search for any criteria.

Edit: just read the v2 plugin link and it looks like these could be user generated?

Yes that is one goal to be able to quickly support new devices without writing a line of C++ code. There will quite some magic behind the scenes like editing and reloading these files in a live system without restarting deCONZ.

A few DDF examples can be found at:

These are pretty low level, later on they can become simpler in common cases.

aidbish · July 6, 2021, 12:14pm

Is there a timeframe for the transition to v2 of api or is it in use now?

Robban · July 6, 2021, 12:19pm

The answer is indeed yes

manup · July 6, 2021, 12:43pm

The v2 API won’t be a hard cut and v1 API is meant running in parallel to not break clients.
Parts of the new approach are getting added incrementally like the introspection API in the last beta to provide supported buttons information of a switch via API.

Providing ETA’s has shown to be extremely difficult. What I can tell is that the new Device/DDF code is already running pretty well in my tests and supports the DDF files visible on GitHub. The next steps are to to stabilize the coexistence of old and new code and get it merged. After that we can piece by piece reduce device specific C++ code and move it into DDF files. Can’t be soon enough as this should improve issues on so many fronts.

Michael · July 13, 2021, 10:51am

but e.g. this website lists the IKEA blinds as supported by deconz (IKEA Fyrtur Block-out Roller Blind (E1757) Zigbee compatibility), but they don’t work properly through the phoscon web interface at all (pairing as lights, not pairing in the blinds section if the beta, …).

Where can / could I (as a end-user) find out if a device is properly supported through deconz and phoscon in a way I don’t have to fiddle around in the phoscon gui setting arguments and wiring things together?

I dont want to “just” criticise, it’s just really hard to find all relevant information about supported devices at the moment, being spread around github, this forum, readmes, …)

Sjonnie · July 13, 2021, 5:02pm

I second this request and I am having the same problems as @Michael to find the correct info. It is “really hard to find all relevant information” and it would be a big bonus for this forum if such a device list exists. It would also support and strengthen the move for most users to this forum instead of staying at the github. I realize it is a fair bit of work to create and maintain a compatibility list but I for one would be very greatful if there is one

Viking · July 13, 2021, 6:49pm

Why do we need a list of “compatible” devices at all? Why can’t Zigbee be just like Bluetooth or Wi-Fi? Everything just works!

Sjonnie · July 14, 2021, 4:53pm

Try posting your question here: https://csa-iot.org/

Deconz/Phoscon adheres to the ZigBee standard but not all manufacturers do. You see the same situation in the USB arena (especially USB-C).

Viking · July 14, 2021, 7:39pm

Well, this (Matter) is still only a vision on the horizon. Even if it does happen one day, it remains to be seen how many choose to play along. “Paper”-standards often tend to loose against de facto standards.

manup · July 15, 2021, 7:15pm

These are valid points. Right now there isn’t a complete overview of which device is supported in: the REST API, the Phoscon App, and various 3rd party integrations. “Supported” could mean anything, only the REST API is granted.

The above mentioned DDF files enable us to build a comprehensive overview. In them we can specify which integration supports a device and automatically generate a Supported Devices webpage.

w.vuyk · July 15, 2021, 7:56pm

Trying to use the sample shown at Add introspection REST API for state and config attributes by manup · Pull Request #4933 · dresden-elektronik/deconz-rest-plugin (github.com)
I replaced the uniqueid with the uniqueid of my IKEA remote (round one with 5 buttons).
But nothing is found (false is returned)
Could this be because there is no DDF for the IKEA remote at deconz-rest-plugin/devices/ikea at device_descriptions · manup/deconz-rest-plugin (github.com)?

Just trying to get this working for my plugin here, so I can start trying on the basics and want to be sure I am not missing somethng obvious?

Wim

manup · July 15, 2021, 8:56pm

The current state.buttonevent introspection API is still not yet using the DDF files. But the round 5 button remote already works since version v2.12.1-beta.

Little test on my machine; GET /api/123456/devices/90:fd:9f:ff:fe:f8:1c:d6-01-1000/state/buttonevent/introspect returns the correct values.