FYI, development started on deCONZ RFC REST-API v2

[Hedda]

FYI, dresden-elektronik developers have started parallel development on deCONZ RFC REST-API v2 (for ConBee and RaspBee Zigbee adapters) and now are looking for feedback or input for ideas and all wishes on how a new API interface may look like:

dresden-elektronik/deconz-rest-plugin-v2#1

https://github.com/dresden-elektronik/deconz-rest-plugin-v2/wiki

https://github.com/dresden-elektronik/deconz-rest-plugin-v2/wiki/Device-Descriptions-Draft

https://github.com/dresden-elektronik/deconz-rest-plugin-v2/wiki/Fault-Tolerance

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/RFC-REST-API-v2

https://github.com/dresden-elektronik/deconz-rest-plugin-v2

Why

I think it's time that we need to figure out a proper v2 REST-API to support a wider range of devices which are available today or might arrive in the future. I'm increasingly unhappy about the /lights hack which is currently used in some places to add devices which don't fit in the provided categories.

A first humble attempt to address more complex devices was the /devices endpoint which allows querying all sub-devices behind one physical device referenced by its MAC address. dresden-elektronik/deconz-rest-plugin@96daf83

Request For Comments

To proceed I invite everyone to share ideas and wishes how a new interface may look like.
Beside this GH issue the RFC REST-API v2 wiki page should be used to develop the new API.

Initial thoughts

• The current API v1 is used by several home automation projects, therefore v2 should be implemented as a parallel interface in order to not break any v1 client.
• The v2 API should be considered completely independent from v1, it should be the best possible API and not a workaround or compatibility compromise.
• A proper security scheme should be integrated. HTTPS can't be used due certificate complexity. However using widely available libsodium we can have end-to-end encryption, authentication and identity management without much hassle.
• The internal Resource and ResourceItem C++ classes are a good common ground to build a generic API on top. These are already used in many places and simplify the implementation of the rules engine. For v2 they are likely to be extended to be more versatile.
• deCONZ and the REST-API is now nearly 10 years old with some historically grown code. As a by-product of v2 new code must be designed and implemented with a proper architecture to escape spaghetti land. The code and many processes like joining new devices could be such much better than it is right now. By now we have so much knowledge about various devices, what can go wrong and how-to workaround issues manually, that's punishment of the user and should be handled by code. The related architecture and design decision should be thoughtful developed with RFC documents.
• The implementation of various switches have shown that a general notion of capabilities might be desirable.
• The v2 interface should be as high level as possible, clients shall not be required to understand any Zigbee specific knowledge. However an optional low-level v2 interface can be offered in parallel to provide full access to Zigbee world.
• Currently Websockets are used to provide real time events, MQTT can be offered as well. Qt has native support for it so the implementation is simple (in fact there exists already a very basic prototype for it).

[MattWestb]

deCONZ is trying doing something better after first being one of the best light steering system on the market, and then more or less destroying it completely by half integrating HA devices. One example the Opple light switch that is one great device that can sending ZLL commands or ZHA and changing its working mode with zigbee command or by one config switch, they was making it only ZHA and its unusable for lights = no go for my.
Most of the last "wave" of tuya devices is only half integrated and not integrated in the Phoscon app (professional ?).

The hardware have great potential if mantrating the firmware well then its one unique architecture but little unusual approach of implanting things. Bad thing is that the second gen dont have implantation the touchlink commands so its not working with their old web app (Wireless light control that is one great app for configuring and working with lights) touch link resetting of ZLL devices.
If i have understanding it is all zigbee light groups configured in the NCP automatically reporting the messages from the network to the host and dont have limits like most other NCPs is having.

Working with cluster in deCONZ GUI is pretty good but limited in many ways. Like querying groups from one light you is getting the number of groupes its belonging but only the ID of the highest numbered one instead of the compleet list. Manipulating scenes is also pretty good implanted but not all the way.

Implanting new devices that is not Zigbee standard is one PIA and must being added in many places in the code (also in the closed cod part) for working instead of one dictated device handler like Z2M and ZHA is doing.

Some of the company devs and community ones is very good but i dont knowing if its enough for keeping Z2M and ZHA taking more of the higher end of the market.

To getting some statistics how many 100 ++ devic system deCONZ, Z2M and ZHA is having today that working stabile wold being very interesting :-))

The biggest problem is making good hardware and getting payed or doing hard and software that is state of art and getting payed or only the half work done and getting problems in the end.

By the way the supports have going under the ice and also is blocking there customer if they is saying somthing the company dont like hearing (My includes for some weeks now).