oui en bref ^^
et ça permet aussi aux autres plugins, de savoir qu’ils ont à faire avec une lumière (et donc d’afficher un widget lumière, et non un widget avec une icone bidon générique). De savoir que cette commande info est un capteur de température et non un capteur de pression…
ça permettrait aussi pleins d’autres choses, d’ajouter du contexte notamment, dans des assistants pour créer des scenarios etc
Cela doit être la 100eme fois que ce sujet est évoqué 
Pour les utilisateurs historique c’est dans les mœurs (ou presque) mais pour un nouvel utilisateur cela le dépasse.
Je principe du générique type est excellent, c’est un principe que HA à aussi. Mais la différence c’est que sur HA c’est obligatoire il parse un json et c’est plié. Tu utilises du zwave, du zigbee … ou autre l’utilisateur n’a pas a se poser de question.
Je ne suis pas dev de plugin, mais comme l’évoque @sagitaz ou @nebz et probablement l’ensemble des dev qui se reposent sur ce principe doivent passer une bonne partie de leurs temps à réexpliquer le principe des génériques.
Comme l’évoque @Loic il est compliqué de forcer la main au dev de faire les choses proprement.
Mais il faut avouer que de remettre les min/max (oui je sais ce n’est pas du générique, mais c’est aussi une info quasiment toujours absente) pour pas avoir une gauge qu’il n’est pas adapté ou l’unité est vide (cela doit être des kg patates), ou autre.
Si les utilisateurs , voir des dev comme @Bison ne connaissent pas le concept des génériques, cela démontre que l’objectif de Jeedom de typer pour faciliter certaines intégrations n’est pas atteint.
Nous devons être nombreux à le regretter pour différentes raisons.
Mais à la question de Loic de comment forcer, cela semble compliqué d’imposer cela après des années de liberté. La sensibilisation de l’intérêt des génériques auprès des utilisateurs est peut êtes une piste. Cela permettrait potentiellement de motiver ensuite les dev à répondre aux attentes des usagers de leurs plugins.
L’autre idée serait de pomper les données Home Assistant Intégration que beaucoup de solutions tierces ont mis en place pour faciliter leurs intégration dans cette solution. Mais je ne sais pas si c’est possible et adaptable à Jeedom.
Mais vous risquez de vous reposer cette question dans12 mois
Plusieurs le font ! le nouveau plugin zigbee officiel (basé sur z2m), @Mips dans ses nouveaux plugins qui justement ont vocation d’utiliser cette intégration !, @MrGreen je pense aussi dans plugin-zigbeelinker. mais oui il faudrait généraliser !!
je trouve aussi le fait que @Bison (rien contre toi hein ;)) ne connaisse pas l’utilité de ceux-ci est inquiétant…
ça devrait même être dans la doc pour créer un plugin.
Et comme toujours on en revient à une définition des types génériques faisant autorité. Je sais que jeemate s’est basé sur ma doc qui se veut le plus exhaustive possible avec mes observations des plugins officiels (ancien ancien zigbee, zwave etc) et sur les comportements des plugins existants et également des tips d’@Alexandre sur comment il gérait certains types dans la feu app mobile v1. Je dis pas que ça fait autorité mais à réflexion c’est peut-etre une bonne base pour commencer (je sais que c’est ce qu’on s’était dit à l’époque dans le groupe de travail et que je n’avais pas pu prendre le lead dessus pour raison personnelle, mais on pourrait tenter de retenter ;))
Je sais pertinement que dans homekit je ne pourrai pas suivre certains types (voiture élèctrique par exemple donné par @sagitaz ), mais je pourrai au moins adapter au mieux en fonction de homekit… (même si au final une voiture est un consommateur électrique + des ouvrants + des thermostats et des lumières…)
bref, soit on va une fois de plus en parler et laisser faire, soit il faut qu’on prenne les devants en tant que communauté (car il faut pas se bercer d’illusion, ni @Loic (il n’a pas le temps) ni Jeedom SAS (aucun intéret financier) ne feront rien là dessus…).
en effet, et ce serait d’ailleurs dommage de profiter et importer des équipements provenant de jsons HA (typé) vers jeedom en ne typant pas les équipements créés car là, l’import perd grandement de son intérêt 
toujours op pour en discuter, quand un groupe actif se sera formé
Hello,
L’équipe jeedom serait je pense ravi d’y participer aussi, pour une fois @nebz je vais te contre dire sur un de tes points, l’intérêt financier est là car si ui de Jeedom peux s’améliorer via les génériques types et la facilité d’intégration de nouveau composant on va pas dire non !
Et puis les générique type c’est un peux mon bébé sur le quel je me suis battu,mais J’ai perdu 
A dispo pour la constitution d’une équipe de réflexion sur cette partie en tout cas.
Bonjour,
Pour info je viens d’initier ce document https://github.com/jeedom/documentations/blob/master/fr_FR/dev/cmd_value.md . A completer bien sur mais ca donnera une base. L’idée c’est que tous les plugins officiel suivent cela d’ici la 4.5 et si assez de plugin tierce suivent alors ca sera une obligation en 4.5.
Dans la suite ca pourrait (conditionnel attention) permettre de :
ah bien
par contre les volets, quasi tous les système (zwave, zigbee, shelly, widget core shutter) c’est des pourcentages d’ouverture (à part ipx c’est ça ?)
Je peux pré-remplir avec les valeurs du plugin homebridge ? (quitte à modifier après si besoin)
C’est l’inverse les volets ? Je sais jamais mais j’ai changé ipx pour faire comme tout le monde donc si c’est l’inverse je vais corriger la doc.
Et oui tu peux remplir avec homebridge ca donnera une base
oui, ex le widget shutter core :
Ok c’est inversé
j’en ai ajouté quelques uns vite fait
Ok merci par contre je pense il ne faut pas indiqué les inversé, le but c’est de dire 1 c’est ca 0 c’est ca et de pas laisser d’autre choix.
sauf que compliqué pour les contacts (ouverture)… dans tous les plugins c’est inversé pour obtenir :
0 fermé
1 ouvert
(car les plugins se basent toujours sur contact = 1 = fermé)
Dans ce cas on fera les modifications pour tous les plugins. L’idée est de definir une norme sans prendre en compte l’existant (sinon on s’en sortira pas). Ensuite on fera ce qu’il faut pour mettre a jour les plugins.
J’ai ajouté les lumières, c’est quasi le plus compliqué…
car il peut y avoir plusieurs types :
Oui les lumieres… et encore le pire c’est hue qui te renvoi une luminosité meme si la lampe est etiente…
oui c’est le type 2
pas très grave je trouve, c’est même le mieux… il y a aussi les ampoules qui s’allument si tu modifies la luminosité et d’autres pas … idem avec la couleur et temp couleur…
Oui ya aussi ca, les ampoules c’est pas simple quand meme ca va etre du boulot pour tout normaliser mais bon je pense faut y passer.
Il serait bien d’ajouter
il me semble qu’il est utilisé dans Homebridge
Hello,
Je vais peut-être con dans mon message.
Mais pourquoi on ne s’inspirerait pas des autres solutions domotiques.
Car unifier également entre les solutions permettrait de simplifier les adaptations d’add-ons ou les interconnections entre elles.
Mais je pense qu’également certains fabricants travaillent avec les solutions internationales, et donc les API de ces dits fabricants s’adaptent au type de leurs solutions partenaires, et donc de faciliter les intégration simple (Sans traitement complexe pour adapter les valeur a jeedom)
Mais cela permettrait également, dans le futur d’intégrer facilement des solutions qui ont un system de découverte a la HA directement dans le core ou dans un plugin dédier comme celui de mips. Ça simplifierait souvent les choses si l’intégration jeedom n’existe pas encore
Exemple Home Bridge : Homebridge Plugin Documentation
Cdt
Thibaut