List of devices compatible with Gladys 4

[pierre-gilles]

Hello!

I’m creating this topic in response to this message:

Organisation des développement Gladys 4

Je pensais à une chose dont on avait déjà parlé, le listing des devices compatibles. La liste commence à s’allonger.

The current debate is:

• Where to store this list of compatible devices: In the Gladys repository? Or in the documentation repository? Knowing that there is an issue: internationalization. Products are not the same depending on the country, titles/descriptions/links must be internationalized.

• Where to display this list of devices: in Gladys + in the documentation? Only in Gladys? Or only in the documentation? Knowing that the answer to this question conditions choice 1. Because we are not going to put this list in two places, so there will necessarily be one that draws on the other if we display it in both places.

We debated this extensively on the forum, I don’t remember where, but since we didn’t follow up, I’m restarting the debate here

[Tlse-vins]

Here’s a summary of the debate I found:

@pierre-gilles

So to recap, there are 3 different requests in this thread:

1. A list of devices compatible with each service, directly within a service in Gladys
2. A list of devices compatible with Gladys, in Gladys but at the « global » Gladys level.
3. A list of devices compatible with Gladys in the Gladys documentation

All three are not mutually exclusive; we can certainly do several, but the source of the information must be the same. Otherwise, we all know how it will end up: after one update, one list will not be up to date compared to the others.

I think it makes sense to have these information entered in the Gladys repo in a config file since it is directly coupled with Gladys code. This allows the developer to modify the config file in the same PR that will add a compatibility, and thus remain consistent in every way.

This information must be internationalized, so there will be one file per language.

We need to put tests to ensure that if a device is added in one language, it is also added in another language, otherwise we will quickly find ourselves with developers filling out one language and not the other and the list will be desynchronized!

What do you think?

Personally, I am rather in favor of proposal 2) and 3), I think that 1) requires too complex work and will make the UI heavy everywhere in the services.

If you have ideas and wish to propose a PR for this, it will be with pleasure

@Tlse-vins

a doc in the form of a table with multiple columns:

• brand
• product name
• an image (optional)
• the product protocol
• type: buttons, lamp, sensor, camera, actuator
• the service that makes it work in Gladys
• development (color scheme: green ok, orange in progress, red not yet)
• a link for purchase (not convinced because the link can be dead which happens at jeedom)

@pierre-gilles

We must also think that some devices can be managed by different services, such as Xiaomi objects that can be used with xiaomi or zigbee2mqtt services.

Absolutely, we can indicate the list of compatible services in the table.

[AlexTrovato]

Good evening,

I suggest adding an attribute to indicate whether a device has been tested or not, as I have just made changes to the Tasmota module, and there is a database of compatible devices listing over 850 devices. However, I won’t be able to test them all, but I believe they will (almost) all be supported by Gladys.

https://templates.blakadder.com

Even offer users the possibility to submit a new device (requested or tested and validated).

[Tlse-vins]

850 devices!!
You haven’t integrated all of them, have you?

• brand
• product name
• an image (optional)
• product protocol
• type: buttons, lamp, sensor, camera, actuator
• the service that makes it work in Gladys
• development (color scheme: green ok, orange in progress, red not yet)
• a purchase link (not convinced because the link may be dead, which happens in Jeedom)

I add:

• tested in Gladys (color scheme: green ok, orange in progress, red not yet)

[AlexTrovato]

In fact, I did not integrate device by device, but feature by feature.
I query the device, ask for its « capabilities », and generate a Gladys device with the features translated from the information received.
The integration becomes more generic and will be less constrained by changes.

[pierre-gilles]

@AlexTrovato

there is a database of compatible devices listing more than 850 devices,

Ok, so that means we potentially have thousands of devices in this database, so it will need to be classified (by what?), paginated, sortable, and with a search bar.

This is more than a small project now ^^ In my opinion, unless someone dives into it headfirst, we don’t have the resources to get this done before the RC, at least not on my end, I’m fully focused on the scenes!

I still struggle to see where this could fit in Gladys in terms of UI (if we put it in Gladys). In the documentation, I can see it very well, but in Gladys, I’m not sure.

[Tlse-vins]

@pierre-gilles

I still have trouble seeing where this could be in Gladys in terms of UI (if we put it in Gladys). In the documentation, I see it very well, but in Gladys, I don’t have much of an idea

• Could this be specified in each service?
  There are several pages in the services, why not add a page with compatible devices?

[AlexTrovato]

I think it should be in the documentation, or even separate, but not in Glayds. A link in Gladys to this repo will be sufficient.

[Reno]

Hi,

In my opinion, we should create a directory in gladys with files by brand (as @AlexTrovato did for the Zigbee2mqtt service) so as not to have files that are too large.
In these files, there should be the information useful to the services, in particular the associated features, the model, … But also the names of the services that manage it and the integration status (integrated, in progress or not managed).
Then, we would have a script that generates a file for display in the documentation and we would add a checkbox to indicate that the model has been tested. This way, users who test hardware could directly provide this information without impacting the development process.
Zigbee2mqtt.io uses such a script for its documentation. I was going to do a small test on github to show you what it looks like but I really don’t have the time at the moment…