Catégories de deviceType: J'ai besoin de vous!


#1

Hello!

Ca fait longtemps que je je dis qu’on va le faire, et là j’ai vraiment envie d’intégrer ça en même temps que le Gladys Gateway: des catégories de deviceType claires.

Les catégories, c’est ce que vous sélectionnez sur cette vue:

L’objectif de ce topic: définir toutes les catégories de deviceTypes possible, sans être trop exhaustif mais sans être trop généraliste quand même.

L’objectif d’une catégorie, c’est de décrire fonctionnellement ce que fait un deviceType.

Exemple: Actuellement j’utilise la catégorie “light” pour sélectionner toutes les lumières d’une pièce quand on demande vocalement à Gladys “allume la lumière du salon”.

Exemples de bonnes catégories:

“light” => Lumières
“humidity-sensor”: "Capteur d’humidité
“temperature-sensor”: Capteur de température
“television” => “une TV”

Exemples de mauvaise catégories:

“roof-light” => Plafonnier => Trop spécifique, ne décrit pas juste fonctionnellement, ne peut pas être utilisé derrière.

Avez vous en tête des idées de catégories de deviceType ? :slight_smile:

@MathieuA @Hamtaro @VonOx @Boimb @Piznel @spenceur @isokar @Pti_Nico @Retlaw Vous qui êtes expert Gladys, je compte sur vous :slight_smile:


#2

Je pense que l’on pourrai s’inspirer de ce que fait ImperiHome:
http://dev.evertygo.com/api/iss

il y a certains types par contre qui ne nous apportent pas grand chose(Dimmer par exemple). mais à contrario j’aime bien “camera”, “lock”(ouvrant)…


#3

Pas mal, la liste est bonne!


#4

je suis justement dessus pour le module imperihome


#5

Dimmer peut être utile, si tu veux allumer la lumière de façon tamisée, genre :

“Gladys, allume le salon à 30%”

Qui serait, de plus, une sentence sympa à implémenter :wink:


#6

Oué… j’avais dis que j’m’y collerais … mybad.
Pour me faire pardonner, j’ai fait un repo histoire de centraliser toutes les idées.
Je ne sais pas si c’est une bonne idée de l’organiser comme j’ai fait mais au moins, ça fait une base commune de travail, non ?

C’est peut-être un peu overkill, mais l’idée était de séparer par sous-catégories avec un système “key”:“value”, histoire que la traduction soit faisable.

Qu’en pensez-vous ?


#7

Pas mal la liste, vous voyez des catégories manquantes ?


#8

Moi j’aimerais juste pouvoir différencier door et window, c’est pas le cas sous imperiHome.

Chez Xiaomi, ils ont sorti un capteur de vibration (le doute subsiste sur sa capacité, si ce n’est pas simplement un capteur de mouvement avec une sensibilité sur un accéléromètre). Du coup, un truc du genre vibration me plairait aussi.


#9

Hello

Moi j’avais déjà crée une issue à l’époque avec quelques idées ^^


#10

Pour moi, les catégories les plus importantes seraient :

  • Alarme
  • Caméra
  • Chauffage
  • Interrupteur
  • Porte
  • Fenêtre
  • Volet
  • Détecteur de fumée
  • Virtuel
  • Température
  • Capteur météo

Attention, dans Imperihome, Lock semble être pour les serrures et non les ouvrants (j’ai essayé avec ton module pour voir justement et ça donne un bouton ouvrir/fermer, donc plus destiné, à piloter les serrure connectée je pense)


#11

J’ai rapproché la liste d’imperihome et les différentes propositions des uns et des autres.
Ca commence à faire :smiley:
J’ai regroupé dans 5 catégories :

  • security,
  • sensor,
  • actuator,
  • media,
  • light

Normalement en combinant les types, on devrait pouvoir arriver à gérer beaucoup voire tous les cas de figure.


#12

@Boimb : La liste est vraiment sympa, mais j’ai pas compris ton système ou tu imbriques les catégories dans des catégories :stuck_out_tongue: C’est juste visuel pour regrouper là ?

Le but des catégories, c’est de décrire fonctionnellement ce qu’est l’objet, donc tout deviceType d’une lumière à mon sens sera de catégorie “light”. Pas de sous catégorie!

J’ai peut être mal expliqué comment fonctionne la phrase “allume la lumière du salon”!

Gladys va chercher tous les deviceTypes ayant comme caractéristiques:

  • category = light
  • type = binary
  • room = ID salon

=> value 1

C’est le duo category + type qui permet d’identifier une fonctionnalité, pas la catégorie seule qui n’est qu’une description de ce qu’est l’objet !

Donc le cas de “Gladys, allume le salon à 30%”, on sélectionnerait les périphériques de types :

  • type = “dimmer/multilevel” ? (a voir ce qu’on choisit)
  • category = “light”
  • room = ID salon

=> Value = 30

  • type = “binary”
  • category = “light”
  • room = “salon”

=> value = 1

La liste que j’ai en tête:

  • light: Lumières
  • television: TV
  • switch: interrupteur
  • outlet: prise
  • humidity-sensor: Capteur d’humidité
  • temperature-sensor: Capteur de température
  • door-opening-sensor: Capteur d’ouverture de porte
  • window-opening-sensor: Capteur d’ouverture de fenêtre
  • […] : Toute la floppée de capteurs que tu as cité @Boimb dans ton fichier :slight_smile:
  • camera: une caméra
  • lock: serrure connectée
  • thermostat: Thermostat
  • Plus plein d’autres que vous avez cité, mais vous voyez l’idée!

#13

Bonjour à tous !

Pour moi, le problème principal que j’ai pour faire une liste exhaustive est de bien comprendre à quoi pourront servir les catégories dans l’avenir.
Je trouve qu’avoir un champ uniquement util pour le brain est dommage, d’autant qu’une évolution des tags le ferait tout aussi bien, et peut-être même avec plus de souplesse (je pense gestion multi-tag par deviceType pas exemple).
Du coup, je pense qu’il faudrait d’abord définir les différents usages des catégories possibles (a court, voir moyen terme) pour bien appréhender la meilleure structure, car c’est pas un truc qui va bouger tous les jours.


#14

Je rebondi sur ce que tu dis @piznel.
par exemple pour imperihome, il faut des codes précis pour chaque type de capteur. j’utilise donc les tags pour faire ça.
Je pense qu’il devrait être possible en effet de faire plusieurs tags par devicetype.
Par contre, dans le cas du brain, il faut aussi qu’il ai quelque chose pour savoir ce qu’est une lampe


#15

C’est bien ce que j’me disais… J’avais rien compris :confused:
OK.

On a une dépendance donc ?
Je rejoins @piznel sur le fait de cerner l’utilité de cette catégory.
C’est en partie pour ça que je ne m’étais pas risqué avant hier à faire une proposition :smiley:


#16

Voilà ce que j’ai compris sur le fonctionnement actuel du brain :
1- La phrase est “parsée” pour détecter des mots clefs :
a- Les pièces
b- les tags des devices types
c- une données temporels (heures, jours, etc…)
d- une maison

=> à l’issu, on obtient donc potentiellement une nouvelle phrase avec chaque mot identifié par sa variable, genre %ROOM% pour les pièces de la maison.

2- Il reste à comprendre l’action à faire. et c’est là qu’intervient la partie “phrases approuvées” du brain, qui, à chaque “commande” attache une “fonction”. Par exemple, en disant “allume”, quelque soit le le contexte, on aura toujours “deviceType.set-device-on”.

=> on a donc potentiellement le type d’action et le où les device-type sur lesquels il faut agir.

3- Il ne reste plus qu’à faire le lien entre le deviceType (avec son service associé) et la commande.

A ce niveau, pas besoin de la catégorie pour faire le job.

Pour reprendre l’exemple de @pierre-gilles : en demandant “allume le salon” cette fois, et sans rien préciser d’autre. Celà aboutira à allumer les lampes du salon, car “allume” va renvoyer la commande “deviceType.set-device-on”, et comme aucun deviceType n’a été trouvé, le brain va alors choisir de passer à “On” toutes les “lights” de la pièce identifiée. Et c’est à ce niveau là qu’intervient la catégorie.

N’hésitez pas à me corriger :slight_smile:


#17

Il faut que ça soit le besoin qui définisse les choix.

Par exemple, je veux pouvoir :
Allumer la lumière du salon à 30% => (double action) light, binary puis light, multilevel
Allumer la lumière de la chambre en rouge => (double action) light, binary puis light, color
Allumer la télé du salon => TV, binary
Allumer l’ampli du salon => multimedia, binary
Allumer la cafetière de la cuisine => outlet, binary
Baisser le volet de la chambre à 50% => motor, tristate (up/off/down)

Ce qui suppose aussi que les sentences soient adaptées.


#18

Je suis 100% d’accord qu’il faut définir le besoin d’abord!

Actuellement le seul usage des categories, c’est l’exemple que j’ai cité plus haut quand on dit “allume la lumière du salon”. Mais à l’avenir, j’aimerais que les categories soient nécessaires et utilisées à pas mal d’endroits!

Je le répète, pour moi une catégorie représente ce “qu’est” un deviceType :

  • Ce deviceType “est” une machine à laver
  • Ce deviceType “est” une lumière
  • Ce deviceType “est” un capteur de température

Usage n°1: Pour le brain, sélectionner des périphériques de même catégories

  • Allume la lumière du salon
  • Lance la machine à laver
  • Fais moi un café
  • Ouvre la porte du garage
  • Démarre ma voiture
  • Est-ce que la porte d’entrée est ouverte ?
  • Quel température fait-il dans le salon ?

Toutes ces phrases ne sont possible qu’avec l’usage de catégories !

Usage 2: Dans la vue, mieux afficher chaque deviceType

Si l’on veut pouvoir faire des vues customs genre une vue caméra affichant des caméras, ou alors afficher des icônes pour chaque catégories devant chaque deviceType, la catégorie peut être utile!

Le tag est un autre problème!

Pour moi, le tag n’était qu’une solution temporaire tant que toute la partie citée ci-dessus :arrow_up:n’était pas codée, mais à l’avenir, 90% de nos commandes textuelles/vocales devront passer par des catégories, sinon c’est le bordel!

On l’a vu, les tags ça se scale mal, ça créé des problèmes dur à résoudre (dépendant de ce que l’utilisateur à mis dans son champs tag), et surtout ça demande une configuration pas possible!

Alors que ce que veut l’utilisateur, c’est juste pouvoir dire des phrases, et que ça marche direct ^^

Ce n’est possible qu’avec l’usage de catégories et de phrases plus riches ajoutées au brain.

C’est exactement ça :slight_smile:

Mais comme je dis, c’est le fonctionnement actuel, et je pense que ce fonctionnement doit évoluer!

Non! C’est beaucoup plus compliqué que ça derrière le brain!

Ce que tu as observé, c’est du à la pauvreté du set de phrases actuel, qui fait que le modèle a déduit que dès qu’il voit “allume” => il classifie en “deviceType.set-device-on”. (il a probablement du mettre un poids très fort sur le mots “allume” dans son modèle)

Si on enrichit les phrases du brain avec de nouveaux usages, on aura plus forcément cette implication :wink:


#19

Pour mon utilité : vérifier tous les états d’un certain type de capteur :

  • quand je m’en vais : check de tous mes capteurs ouverture/fermeture
  • quand il pleut : check de mes capteurs fenêtres

C’est juste un petit exemple supplémentaire, les catégories simplifieraient au lieu d’aller chercher tous les IDs.


#20

Exactement @Hamtaro, j’avais oublié cet usage mais il est 100% dans ce que j’ai en tête!