Petit sujet pour les développeurs de plugins utilisant les types génériques.
A ma connaissance :
- Mobile
- Homebridge
- Jeemate
- Alexa
Dernièrement en Core 4.2 nous avons :
-
Ajouté une page Outils / Types d’équipements qui permet de typer très facilement les équipements et leurs commandes.
Typer les équipements n’a pas de réel utilité, toutefois tout était déjà dans le core (class, DB etc) et çà permet de ranger ses équipements, éviter la confusion, et permet la fonction de typage automatique. Bien sûr on peux mettre un generic dePrisesur un équipement typéLumièreetc. Alors quand on a déjà tous de paramétré çà ne sert pas à grand chose, mais pour la compréhension par des utilisateurs ne maitrisant pas les types génériques c’est beaucoup plus clair. Et çà évite d’avoir un tiroir avec tous les équipements dedans. A voir plus tard si on s’en sert ailleurs.
Bien sûr, certains capteur comme des détecteurs de mouvements ont aussi des température etc. Rien n’empêche de typer l’équipement dans environnement, ou autre, çà n’a pas d’influence dans les plugins mais çà reste plus clair. Et forcément le auto types ne proposera pas grand chose puisqu’il ne peux que se baser sur le type d’equipement puis les type/subtype de commandes et enfin leur nom pour deduire quelque chose… Il y a toujours des cas particuliers …
Doc avec la liste des génériques du Core -
Une fonction à intégrer dans les plugins qui ont besoin d’ajouter leurs propres types génériques. Actuellement Jeemate l’a intégré et le Core affiche bien les types propre à Jeemate sur la page Types et la modale de config de commande.
→ doc -
La gestion des
genericType()en déclencheur de scénario, expression, action. Mais ce n’est pas le sujet ici.
Hier, j’ai ajouté deux choses :
- Un bouton ‹ Liste › sur la page type pour lister tout les types génériques du Core+Plugins installés. Plus complet que la doc, accessible facilement, et toujours actualisée …
- Un champ commentaire sur les types generiques, permettant d’avoir une description de ceux ci. Ce n’est qu’une proposition, à voir si çà reste.
ex:
'LIGHT_TOGGLE' => array(
'name' => __('Lumière Toggle',__FILE__),
'familyid' => 'Light',
'family' => __('Lumière',__FILE__),
'type' => 'Action',
'subtype' => array('other'),
'comment'=>__('Inverse l\'état on/off d\'une lumière.',__FILE__)),
Ce qui nous donne:
_____So …
Dans la liste des génériques du Core, 9 types ont plusieurs (2) subtype de commande possible. Exemple, LIGHT_STATE qui peut être 'subtype' => array('binary','numeric')
Donc si je comprend bien, un user peux mettre ce type sur une commande binaire ou numerique, du coup dans un plugin, comment traitez vous çà ?
Ne faudrai-t-il pas autoriser seulement un subtype de commande par generic ?
Ici on a LIGHT_STATE_BOOL possible que sur du binaire, donc LIGHT_STATE devrait être que numeric non ? Comme çà tous les plugins savent qu’elle type de données ils vont recevoir ?
De plus certains generics n’ont aucun subtype renseigné, est-ce logique / acceptable ??
Pour info les paramètres type et subtype d’un generic permettent dans Jeedom d’attribuer ce generic sur telle ou telle commande. Un generic de subtype binaire ne sera pas proposé sur une commande de subtype numeric, etc.
Ne serait-il pas opportun aussi de nettoyer un peu cette liste, ajouter certains type communément utilisés mais pas dans le Core, etc ?
Comment améliorer sans tout casser en 4.2 ? Quitte à intégrer certains choses en 4.3 et l’anticiper sur les plugins ?
) on sent bien qu’ici l’usage s’accélère.