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


#41

Salut @pierre-gilles !

Je t’explique ce qui m’a amené à cette proposition.

Je viens de réinstaller des pinces amperemetrique qui mesurent la conso de certains circuits electriques en temps réel. Elles sont actuellement gérées par mon ecodevice mais si elles intègrent un jour Gladys, une catégorie “électricité” serait alors la bienvenue.

Autre exemple, ayant un abonnement EDF Tempo, je regarde comment modifier un icône dans imperihome en fonction de la couleur du jour et du lendemain.
Pour ce faire, Gladys récupère actuellement lesdites couleur et modifie la valeur de 2 devices virtuels en fonction des résultats.
Si je pouvais classer les devices virtuels dans des catégories, ça serait pas mal.

On peut pousser la réflexion à des devices virtuels qui seraient modifiés en fonction HP/HC (perso, pas besoin, mais si ça ce trouve, quelqu’un en aurait l’utilité.)

Du coup, effectivement, il n’y a pas vraiement d’objet physique à proprement parlé, mais il y a des devices quand même. S’ils ne sont pas classés, rien de grave, cela ne me manquera pas et ne nuira pas au fonctionnelent, mais quitte à implémenter quelque chose, autant imaginer tout ce qui pourrait être fait non ?


#42

Je comprend très bien ton usage, mais j’essaie de penser logique! :slight_smile:

A quoi te servirait les catégories ici en fait ?

On créé des catégories pour décrire physiquement les périphériques et permettre des usages vocaux, ici j’ai même du mal à voir en quoi utiliser des devices virtuels pour faire ce que tu fais est une chose “logique” :slight_smile:

Je ne pense pas que tout faire passer par les devices est une bonne chose!

A ce compte là, on va faire des périphériques virtuels pour la météo qui stockerait la météo… Et on perd toute la logique d’un périphérique!

La météo par exemple, ce n’est pas une périphérique virtuel, mais une API native, avec toute une entité qui décrit ce qu’est la météo.

Pourquoi ne pas faire pareil pour l’électricité ?

Imaginons :

gladys.electricity.getCurrentTempo()

Avec derrière des scénarios natifs pluggé sur ça genre “SI XXX et TEMPO = bleu ALORS”

( Et c’est pas forcément parce que les autres box domotique le font que c’est bien de le faire, c’est pas une excuse :stuck_out_tongue: Souvent ce genre de chose est fait comme ça pour permettre un développement rapide en se pluggant sur ce qui existe déjà, mais j’aime bien avoir une réflexion dans le long terme! )


#43

A dire vrai, pas à grand chose car de toutes façons, cela ne changerait rien au fonctionnement attendu. Je ne savais pas jusqu’où devait être poussées les propositions, donc j’ai proposé :wink:

Je comprends tout à fait ton point de vue !

Effectivement, mais cela demanderait beaucoup plus de développement pour probablement peu d’utilisation.


#44

Créé un set de fonction natif c’est assez rapide, je pense pas que ça soit un gros dev… :wink:

En tout cas l’approche device pour moi n’a pas d’utilité ici, ça serait pas logique!

Du coup on est good pour lancer le projet ? :slight_smile:


#45

Ça semble bien parti pour l’être en tout cas !


#46

Bonjour,

Désolé d’arriver aussi tard, je viens de voir ce sujet très intéressant sur les “category” et je n’ai pas vu de proposition sur une partie sur laquelle je bosse actuellement, je soumet :

“Barrière” et/ou “Porte de Garage”

  1. Ouverture
  2. Fermeture
  3. Ouverture piéton
  4. Blocage ouverture
  5. Blocage fermeture
  6. Mode automatique

En espérant que cela pourra aider, dans le cas contraire on regardera pour un fonctionnement module/box.

A bientôt


#47

Bonjour à tous,

Après avoir analysé ce qui se faisait en terme de catégorie de périphérique dans d’autres systèmes, j’ai fait une synthèse que vous pouvez consulter ici.

Comme vous pouvez le voir, l’idée de @Boimb de faire des catégories et des sous-catégories a été retenue :slight_smile:

Avant de proposer un changement, n’hésitez par à relire le post d’origine de @pierre-gilles, pour bien comprendre ce que représente une catégorie :

Le but est également de trouver de jolis icônes, à minima pour les catégories.
Merci à tous du temps que vous prendrez à contribuer à l’évolution de Gladys :slight_smile:


#48

Chez Xiaomi, ils ont sorti un capteur de vibration. (Et je crois que ça existe chez d’autres fabricants)

Tu caserais ça dans quoi ?


#49

Oui, tu as raison. Dans capteur ou alarm sensor, plutôt. Xiaomi le classe dans les détecteurs de mouvement, ce qui me semble assez cohérent.


#50

@piznel : Je suis d’accord pour pas mal, sauf la catégorie “switch” et “outlet”, les sous catégories sortent de l’utilisation des catégories, c’est plus des types que tu as décris là non ?


#51

Salut @pierre-gilles,
Pour moi, ce sont bien des fonctionnalités possibles de certains switch ou outlet : Certains outlets te remontent leur conso électrique instantanée (comme la Wemo Insight de Belkin), et dans les switchs, comme dans le Xiaomi Smart Wireless Switch, tu as bien les fonctionnalités du double-click et appui long, ce qui rentre dans la sous-catégorie “multiple-choice” pour moi.


#52

J’ai aussi une fonctionnalité d’inactivité sur un capteur de mouvement Xiaomi… C’est une durée.
On pourrait inclure une sous-catégorie “time” ?


#53

En fait, l’idee Est de définie des fonctionnalités de devices, et du coup d’y rattacher des fonctions. Pour un détecteur de mouvement, pour moi, c’est du natif.


#54

Revenons à la définition d’une catégorie dans Gladys:

Pour revenir à ce que tu dis, ce serait pas plus des types que tu as décris ? Les catégories sont utiles uniquement que le brain puisse reconnaitre ce qu’est chaque deviceType dans la vraie vie. Est-ce que ces sous-catégories apportent une information utile au brain? Est-ce que tu as un exemple d’usage à me donner pour me convaincre ? :slight_smile:

J’ai l’impression que tu ne décris pas ce qu’est l’objet, mais plus tu décris un fonctionnement technique…

Les catégories ne sont pas là pour remplacer les types!

“Allume la lumière du salon” = “categorie: light” + “type: binary”

Non! :smiley: Vous ne décrivez pas ce “qu’est” un deviceType là, vous décrivez des features!

La catégorie est ce qu’est le deviceType physiquement. “time” n’est rien de physique, c’est une feature!


#55

En fait, je suis allé plus loin dans mon raisonnement. Aujourd’hui, ce n’est effectivement utilisé que par le brain, ce qui est dommage.
L’idée est de standardiser d’une certaine manière les devices : je créé un device d’une catégorie et sous-catégorie donnée, Gladys me crée alors les devicetypes associés de base, avec fonctionnalités associées.

En suivant ton raisonnement, seul les catégories suffisent du coup.


#56

Je ne dis pas qu’à l’avenir ça ne sera pas utilisé par d’autres choses que le brain, c’est juste qu’on s’était mis d’accord sur une définition des catégories et là c’était plus ça :smiley: Il faut penser globalement le truc! Si on décide d’abolir les types, ok, mais dans ce cas on en discute :slight_smile:

Je pense pour l’instant juste établir la liste des catégories c’est un bon début.

Pour Gladys v4 (dont le débat et la conception va commencer en décembre) je propose qu’on relance le sujet de manière plus globale.

Mais sinon à part ces 2 points ta liste est top, on peut partir sur ça!


#57

chauffage :slight_smile: fait froid hiver


#58

Le chauffage est un device @promachos
Pour lui tu aura un deviceType binary et temperature


#59

binary tu parles … qubino leader car pleins options confort,confort-1/-2,hors gel, eco etc bref cest pas du binaire. Et vue que le chauffage poste de depense no1 cest un des premiers trucs à faire.
Si tas des enfants en bas age ca tevite de refaire une seance dodo 1H30 :slight_smile: au moins


#60

Les modes sont justes des consignes (durée, température, puissance) qui peuvent être gérées par le module.
Le chauffage en lui-même est allumé ou éteint. Enfin c’est ce que je crois…