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.
1 « J'aime »
J’ai ajouté les lumières, c’est quasi le plus compliqué…
car il peut y avoir plusieurs types :
- les lumières simples : on + off + Etat binaire
- les lumières avec variateur et deux états : un état binaire donnant l’état d’allumage + un état de luminosité (0-100 (zigbee et wifi) ou 0-99 (zwave) ou 0-255 (hue))
- les lumières avec variateur et un etat : un etat numérique, 0= eteint, autre = allumé et luminosité
- toutes ces variations avec des températures couleurs soit en Mired soit en Kelvin, la différence est assez facile a déceler, si la valeur <=500 alors c’est des Mired, sinon Kelvin.
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
- Interrupteur simple : on + off + Etat binaire
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
oui oui, juste pas eu le temps et ce type n’existe pas dans le core encore
Merci, pas dispo jusqu’à lundi soir mais je regarderais ce que je peux ajouter dans cette liste.
Bien entendu que tout ceci sera sans doute un peu compliqué à mettre en place dans tous les plugins officiel et non-officiel mais le but est de simplifier au maximum le travail ensuite de l’utilisateur.
Quand je vois encore des état lumière en string cela me pique les yeux. Et on en voit souvent.
j’ai complèté. certains ne sont pas dans le core et il y en a d’autres : météo, multimedia etc mais de mon coté j’ai quasi rien là dessus…
C’est top l’initiative.
Les tableaux ne devraient ils pas être plus complet pour permettre ce référentiel comme l’évoque Loic.
Je donne un exemple car en regardant uniquement un type simple « ventilateur » il y a déjà plusieurs valeurs possibles pour le type info (Binaire + numérique) dans la même ligne du tableau si que en soit est hors de toute normalisation.
Un exemple a mon avis très incomplet car il y a des génériques beaucoup plus complexe (tableau du haut l’existant du fichier md et celui du bas une umble proposition a amender :
Pas simple de trouver un nom sur les entêtes de colonnes 
Cette approche permet ensuite de définir le nom de gen type :
« cat_generique »& _ &« nom_generique »&_&« sous_cat_generique » => info_ventilateur_etat
A voir si il faut ajouter le sous-type => _binary
Avec ce découpage, cela permettrait probablement aussi de clarifier les valeurs possibles de « sous_cat », sous_type" mais aussi les valeurs possibles pour les numériques…
Votre avis ?
1 « J'aime »
Hello,
oui, je pense qu’il faut garder des possibilités multiples, car il y a plusieurs types d’équipements, mais comme tu dis en référencer plusieurs est une bonne idée ! par contre il faudrait un système (j’ai eu le cas pour le type générique lumière ou je n’ai pas trop vu comment je pouvais afficher ça clairement…) pour afficher ces différents types (ex plus haut avec les types d’ampoules et leurs comportement). c’est plus le comportement alors qu’il faudrait décrire (si vous avez une ampoule qui indique son état d’allumage + une luminosité et que cette luminosité si elle est changée alors que l’ampoule est éteinte allumera l’ampoule alors vous devez faire comme ceci, etc) mais ça devient complexe… je n’ai pas vu comment les autres (HA, ioBroker, etc s’en sortent…)
j’aime bien le fait d’ajouter aussi des colonnes au tableau, mais pour moi la notion de obligatoire n’a (malheureusement) rien à faire là… car l’obligation dépend plutot de celui qui va utiliser ce type générique (gsh, jeemate, jeeconnect, homebridge, alexa, widget, etc) et pas du générique en lui-même. et j’aime pas les noms des premières colonnes 
soit maj soit _ soit camel case mais là c’est mélangé
concernant les ranges de valeurs elles sont souvent dépendantes des min max des actions (puisque les min max sur les états ne sont pas obligatoires pour afficher correctement et beaucoup de dev ne les mettent pas)
Sur le dernier point, effectivement si le min max est définit cela permet d’avoir la valeur de du curseur.
Mais l’idée n’est pas là , mais pour cadrer les ranges parfois divers 0-100, 1-99, 0-254 …
Un scénario avec tous les volets à 50% => pour le volet 1 128, le 2 50 le 3 49 … si pas la même technologie / marque equipement
En gros la plage est fixe et le plugin s’adapte et plus le contraire comme aujourd’hui.
Pour les noms de colonne j’avais prévenu
Pour HA, il définisse en amont les classes d’équipement et les dev doivent s’y contraindre :
Customizing entities - Home Assistant (home-assistant.io)
Sensor - Home Assistant (home-assistant.io)
Zigbee Home Automation - Home Assistant (home-assistant.io)
Binary sensor - Home Assistant (home-assistant.io)
Capteur - Assistant à domicile (home-assistant.io)
On parle bien aussi ce clarifier les types de commande info/action mais aussi le type d’équipement (lumière, robot-tondeuse, volet)…
peu importe en fait le range… tant qu’il est défini qqpart (min max) on peut s’adapter, ca pourrait meme etre 127-418 c’est la même chose
J’ai pas souvenir qu’un utilisateur puisse dans un scénario dire 50% de la commande toto.
Et si toto c’est 127-418, le core calcul (418-127)/2 sans passer par un bloc code ou un syntaxe de 12 pieds de long
trouvé les lumires aussi : Light - Home Assistant beaucoup est en pourcentage sauf hue (pas Philips mais hue/sat) : Hue is scaled 0-360, and saturation is scaled 0-100. et des luminosités de -100 à 100 par ex. pour les couleurs ils supportent nativement HS RGB XY RGBW RGBWW
pour les volets ils parlent d’une position mais qui ne dit pas si c’est ouverture ou fermeture : Cover - Home Assistant
Une autre approche :
Et peut être que certains critère comme le min/max pourrait remonter dans la classe et les obligatoire/falcutatif
Pour les lumières il y a mieux, la page dev :
Light Entity | Home Assistant Developer Docs (home-assistant.io)
Pour les ouvrant(volets, fenêtre, rideaux…) :
Cover Entity | Home Assistant Developer Docs (home-assistant.io)
autre exemple Climat/thermostat
Climate Entity | Home Assistant Developer Docs (home-assistant.io)