Les génériques

Salon des Développeurs Core V4 (dev)
1

Avec la nouvelle version de l’appliaction Jeedom, il semble que les types génériques soient mis en retrait.

Certain type actuel ne sont pas correctement typé (fil pilote etat qui n’est que binaire).
ici en 4.1.19

image
image1205×223 30.5 KB

depuis la 4.2 : ici il faudrait ajouter en subtype ‹ numeric ›
image
image1083×130 7.47 KB

Et les nouveaux équipements connectés n’en ont tout simplement pas ( Voiture electrique, Lave linge, lave vaisselle, etc…)

Sur quel source, Jeedom se base pour les Génériques ? Y’a t’il une possibilité d’en ajouter au Core, car oui depuis la 4.2 on peut en faire pour chaque plugin mais ce n’est pas l’ideal car alors ils ne fonctionnent pas pour les autres plugins (sauf entente entre dev ex: Homebridge/JeeMate).

Pourquoi ne pas obliger les devs de plugin tiers a correctement les configurer ?

Je me doute que cela est un sujet sensible vu qu’un espace de travail avait un temps été envisagé mais a force d’attendre et de ne rien faire, c’est un bordel sans nom et je comprend que certain user soit découragé.

3 « J'aime »
2

Bonjour,
Pas mal de question je peux pas répondre a tout :

  • Sur quel source, Jeedom se base pour les Génériques ? Aucune on fait ca comme on le sent tout le monde peut faire des PR pour les ajouter, attention quand meme si yen a trop les plugins risque de pas les prendre en compte
  • Y’a t’il une possibilité d’en ajouter au Core ? Oui par PR sur le github
  • Pourquoi ne pas obliger les devs de plugin tiers a correctement les configurer ? On ne peut absolument pas forcer les dev a faire ce genre de chose. Les types générique sont du confort, configurable par l’utilisateur et non nécessaire au fonctionnement du core. De plus des fois une prise sera une prise puis une lampe ou autre chose c’est pas toujours simple et seul l’utilisateur final sait ce que c’est. Et pour être honnête rien que pour les plugins officiel je le fais quand je passe dessus mais c’est un boulot trop gros pour le temps que j’ai donc ca avance mais lentement.
3

OK, je vais proposer des PR dans ce cas.

A force ne ne pas les obliger, ben rien n’est fait. Vu que tous les plugins ont des commandes sur lesquels ont peut ajouter des génériques mais que seul 4 ou 5 plugins les utilisent alors les devs ne se prennent pas la tête et ne les mettent pas.

En effet cela prend du temps, surtout quand cela est fait après coup, mais un dev qui créé sont plugin dans lequel il y a 10 commandes, cela est relativement rapide de les ajouter en même temps ( comme l’unité, le min, le max, en fait ce qu’ils ne font pas non plus).

Une prise, c’est une prise, ensuite si l’user l’utilisent pour autre chose alors la c’est a lui de modifier le générique existant mais de base le générique prise devrait être renseigné.

Et, ce n’est pas à toi de faire cela, on sait tous que tu n’en a pas le temps.

4

Si tu as une idée pour forcer les devs vas y je t’écoute mais je vois vraiment pas comment faire désolé…

Et si c’est a moi de le faire c’est moi qui gere les plugins qui utilisent le moins bien les generiques type…

5

Hello,

Moi j’ai jamais utilisé. Pas encore eu envie de me pencher sur le sujet pour être franc.

Sagitaz, peut-être qu’avec un bon tuto Community, ça permettra aux devs de s’y intéresser et de faire les modifications nécéssaires :

  • Utilité / intérêt pour les utilisateurs dans Jeedom
  • Exemples permettant d’adapter le code des plugins pour mâcher le travail

Moi je veux bien le faire sur mes quelques plugins, j’imagine que l’affaire de 30mn maximum mais comme j’ai pas encore vu l’intérêt en tant qu’utilisateur, j’ai pas du tout regardé coté code :face_with_peeking_eye:

6

Pour finir on en revient au même problème…

un type générique doit avoir un comportement générique et ce comportement n’est défini nulle part… donc quand bien même les plugins les appliqueraient, ça sera probablement mal fait… et après c’est aux devs des plugins protocoles externes (apps jeedom, alexa, homebridge, gsh) de se ramasser les demandes « j’ai le type générique prise info qui renvoi une valeur string « allumé » ou « éteint » et ton plugin prend pas en compte… »

1 « J'aime »
7

c’est déjà le cas, ce matin 2 demandes de configuration de types générique, c’est ce qui ma pousser à faire ce post.

8

Hello,

Vaste sujet :slight_smile:
Cependant quelques notes en vrac si je peux.

Actuellement, sans types génériques, peu importe le plugin, un équipement dans jeedom est générique… c’est à dire qu’en effet jeedom ne sait pas à quoi correspond tel equipement. (alors que d’autres solutions domotiques le savent par contre, car pour elles, il s’agit d’un information importante qui leur permet d’ajouter du contexte dans leur solution).

Sans type, générique, par exemple si on appaire un équipement Lumière dans un plugin (tuya ou que sais je), jeedom ne sait pas qu’il s’agit d’une lumière.
Pour cela, il faut que l’utilisateur aillent configurer les types génériques dans ce nouvel équipement, et seulement à partir de ce moment, les plugins compatibles « types génériques » ainsi que Jeedom peuvent alors savoir, « ah cet équipement est une lumière, je peux adapter son comportement, ajouter du contexte… ».
Sans ça, c’est quoi? un eqlogic. et cet autre équipement? un autre eqlogic ^^
Si admettons un plugin voulait lister toutes les lumières dans jeedom, il fait comment s’il n’y a pas de types génériques qui ont été affectés à l’équipement?

Quand ce n’est pas fait par défaut dans un plugin (et correctement), alors l’utilisateur doit s’en charger.
Est-ce friendly pour un nouvel utilisateur, non informaticien, d’appairer un équipement, et d’ensuite aller définir ces types génériques? Est-ce une pratique courant dans les autres solutions domotiques opensource ou commerciales?
Presque sur que de nombreux utilsiateurs quand ils appairent une ampoule par exemple, n’imaginent meme pas que jeedom ne sait mm pas ce qu’est cet equipement.

Idem, je vais mm pousser un peu le bouchon, sur la définition des commandes ^^
Est-ce utile pour un utilisateur non expérimenté de travailler directement avec un max=255 sur une ampoule, ou que son volet a une plage de 1-99 ? Faudra qu’il a aille fouiner dans son equipement, afin de savoir qu’il ne s’agit pas d’un pourcent, pour écrire son scenario, ou meme pire, que dans son scenario il ne faut pas écrire etat==1 mais etat==allumé. Ce pourrait etre transparent pour l’utilisateur avec un valeur « user » qui a du sens, et une valeur brute/raw pourquoi pas si besoin. Mais cela en effet demanderait au dev du plugin de bien connaitre les equipements.

Avec l’existant, c’est pas évident à présent de brider les types génériques sur du bool ou du num :grimacing:

9

OK merci c’est plus clair. J’ai retrouvé aussi ce sujet qui présente déjà pas mal l’idée : Core et Types Génériques

Donc concrètement et pour vulgariser : ça permet à l’utilisateur d’allumer toutes les lumières de son château en même temps (en mode conte de fée) ou de faire un scénario avec un déclencheur générique sur une lumière pour que le scénario se déclenche dès qu’une lumière s’allume quelque part dans son château histoire d’aller questionner l’idiot qui a allumé une pièce un jour rouge ! :nerd_face:

10

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

11

Cela doit être la 100eme fois que ce sujet est évoqué :slight_smile:

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 :slight_smile:

4 « J'aime »
12

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…).

2 « J'aime »
13

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 :grin:

toujours op pour en discuter, quand un groupe actif se sera formé :slight_smile:

3 « J'aime »
14

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 :joy:

A dispo pour la constitution d’une équipe de réflexion sur cette partie en tout cas.

12 « J'aime »
15

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 :

  • supprimer l’inversion sur les binaires (ca complexifie inutilement jeedom si on suit la règle des valeurs)
  • rendre les scénarios plus user friendly avec des #…# == ouvert par exemple ou #…# == mouvement (idem les possibilité seront a definir dans cette meme documentation pour avoir un referentiel).
3 « J'aime »
16

ah bien :slight_smile:

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)

17

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

18

oui, ex le widget shutter core :
image

19

Ok c’est inversé

20

j’en ai ajouté quelques uns vite fait