Pouvoir modifier les pièces des divers features composant un device avec multiples relais

Feature Requests
#1

Exemple concret d’un relais sonoff 4-ch pro :
En général ce dernier est installer dans un tableau électrique. Il peut être utilisé pour contrôler 4 devices dans différentes pièce, mais aussi différents type de device (ex: une prise dans le salon, un éclairage dans la cuisine, une commande d’ouverture 12/24V et une commande de fermeture 12/24V pour la barrière extérieure)
Or à ce jour, il est remonté comme un seul device sur Tasmota et ne peut donc être dissocier dans differentes pièces, ni être modifier en catégorie.

Il serait intéressant de pouvoir avoir le choix à la création de dissocier 1 ou plusieurs relais (features) en 1 ou plusieurs devices. Et de pouvoir modifier les catégories de ceux-ci en autres catégories de type binaire.

Ceci est également le cas pour les Sonoff 4CH, Sonoff DUAL, […]. Liste à remplir en cas de besoin.

Editer le type de feature des devices Philips Hue
#2

Pour le choix de la pièce, je n’ai pas poussé la réflexion.

En revanche, pour changer une prise en lumière, j’ai pris le temps.

Je vois qu’il est assez simple de proposer de pouvoir changer de prise à lampe pour un device dans Gladys.
Mais je ne vois pas comment revenir à l’état d’origine.

Pour illustrer :

  1. Aujourd’hui tu branches une lampes sur ta prise, tu décides donc de changer le type de l’appareil dans Gladys de prise (ou interrupteur) à lumière.
    Pour moi, ça a du sens.

  2. Demain, tu branches ta machine à café sur la même prise. Hors dans Gladys, c’est une lumière. Et la pour moi ça n’a pas de sens de pouvoir changer le type d’un appareil lumière.

Il faudra soit supprimer le device pour le recréer de 0 (au risque de perdre les scènes et autres configurations / historique),
soit ajouter l’information sur la feature pour conserver le type original (pas trop fan).

#3

Alors là je ne comprends pas ton inquiétude. Pour moi dans ton cas n°2, tu pourras toujours sélectionner la catégorie prise à nouveau. Et il faudra bien que tu changes ton scénario car tu ne feras certainement pas la même chose avec une cafetière qu’avec une lampe. Et dans 1 mois si tu veux remettre une lampe dessus tu pourras le repasser en éclairage.

Au final avec Alexa en ce moment c’est exactement ce que je fais avec une simple prise hue. Elle contrôlait la mise en marche de la pompe de la piscine cet été. Elle était donc en prise. Cet hiver elle est installée sur une lampe de salon. Je l’ai juste modifiée en éclairage pour pouvoir l éteindre lorsque je dis “Alexa éteint le salon” avec toutes les autres lumières.

#4

Est ce que c’est possible de mettre un choix multiple lors de la création du device?

  • lampe
  • prise
  • …

Est ce sur c’est possible de pouvoir changer le type de device lorsque l’on édite celui-ci.

Qu’est ce que cela implique si le device est une lampe ou une prise? A part on et off.

Pourquoi est ce important de revenir à l’état d’origine?

#5

Ca implique que lorsque tu éteins une pièce, toutes lumières s’éteignent mais pas les prises. D’où l’importance de pouvoir modifier pour une prise ou pour les devices que je décrivais dans mon premier post.

Tu peux voir mon exemple juste au-dessus avec Alexa.

1 Like
#6

Pour moi l’état d’origine n’a aucune importance dans ce cas. Il faut juste pouvoir l’éditer quand on le souhaite. On peut juste mettre une info sur le device pour dire que celui-ci peut être modifié.

#7

Pourquoi on parle de ça ici? ^^ je croyais justement qu’on avait créé ce sujet pour séparer les deux conversations :stuck_out_tongue:

Sinon je suis 100% d’accord avec ton analyse @AlexTrovato. Je pense qu’il faut que dans l’UI on ait la connaissance de “ce qu’était” le périphérique original, pour pouvoir juste display un toggle “cette prise a une lampe au bout” OUI/NON" et pouvoir jouer avec le toggle en fonction de ce qu’on branche au bout.

Je pense pas qu’on ait besoin de rajouter de la data dans la feature, on peut juste se baser sur le “model” et au cas par cas display ce toggle, qui lui se base sur le type pour être en “OUI ou NON”

1 Like
#8

Pourquoi on parle de ça ici?

On n’est toujours pas au bon endroit ?? A moitié oui :stuck_out_tongue:

on peut juste se baser sur le “model”

On n’utilise pas ce champ pour certains services ? Pour les commandes setValue ?
Il ne faudrait pas que cela ait des impacts.
Mais :+1: pour le toggle !

Mais cela ne règle pas le problème des devices multi-features.
J’ai une multi-prises, sur un seul plug j’ai une lampe. Les 3 autres restent des simples “interrupteurs”.

#9

Je parlais d’utiliser le model juste pour savoir si c’est une prise, et donc pour display le toggle, mais pas de modifier le model !

Donc pas de problème pour les multi-prises

1 Like
#10

De mon point de vue, parce que finalement il se trouve que c’est 2 problèmes différents si on part sur cette voie. L’autre sujet sur Philips Hue évoque un équipement qui est physiquement une prise et donc entendu comme telle. On peut brancher un éclairage dessus et on aimerait pouvoir éteindre cette lumière en même temps que l’éclairage de la pièce … ou pas. Pour le coup la case a cocher semble un bon compromis.

Or dans le cas évoqué ici, le sonoff, ce n’est pas du tout ça. L’équipement est un relais qui est physiquement exactement la même chose qu’un interrupteur. Il a été programmé sur l’integration Tasmota comme un “switch” mais ce n’est pas le cas. Cet appareil a été vendu pour contrôler n’importe quel équipement, et finalement rarement une prise, qui elles généralement son prise sur un câble pour plusieurs prises. Il peut contrôler des volet roulant (qui sera certainement une autre catégorie, un éclairage en va et vient avec un interrupteur en parallèle, ou en direct, une prise, du 12v, … bref de nombreuses “catégorie”. Pour le coup je ne vois pas bien quel est l’intérêt de garder un état initial de cet appareil qui n’en a pas de base.
Après on peut décider de ne pas le faire, ce qui je pense serais dommage, mais la flexibilité sur ce point tout en gardant le point essentiel, le type binary, me semble pertinent. Et la case a cocher ne représente pas bien le périphérique réel car finalement si on avait mis “light” de base dans l’intégration cela aurait été tout aussi vrai car on peut l’utiliser pour contrôler seulement 4 plafonnier de 4 pièces différentes (ou 3 plafonniers + 1 applique de 3 pièces différentes). Et je pense d’ailleurs que la gamme sonoff (basic, dual, 4ch, 4ch Pro) sont utilisés la plupart du temps en ce sens.

Toutefois, je ne connais pas les autres marques, mais ZWave par exemple semble proposer également des produits similaires (pour remplacer ou doubler un interrupteur d’éclairage) qui peuvent necessiter la meme logique. Le fibaro single switch 2 par exemple peut tout aussi bien être utilisé derrière un interrupteur pour un éclairage, que pour une prise.

2 Likes
#11

On s’est mal compris, je suis d’accord avec ce que tu évoque mais ce n’est pas le titre du sujet.

Ce sujet parle du problème des périphériques qui ont plusieurs features dans différentes pièces !

1 Like
#12

Pour ma part j’ai justement un problème de périphérique avec un interrupteur double de chez XIAOMI sur les 2 en ma possessions. Je m’explique :

image
image1544×846 57.5 KB

Le 1er est dans ma cuisine, le bouton de droite gère le néon et celui de gauche le plafonnier donc pas de souci, hormis le libellé du dashboard.

image
image782×716 32.1 KB

Par contre le 2ème interrupteur qui est sur le mur entre la salle à manger et le salon est plus ennuyeux car le bouton de droite gère le plafonnier de la salle à manger et celui de gauche du salon. (Pour infos j’ai les 2 mêmes plafonnier). Je préférerais dire dans le futur à gladys. Allume le salon ou la salle à manger afin de bien les dissocier sans trouver des noms différents entre “plafonnier et spots” par exemple. (Pas très logique je trouve)

image
image1560×844 41.8 KB

#13

que tu peux changer, non?

Je comprend, c’est exactement le problème qu’on veut résoudre dans ce sujet.

Pour l’instant, on a rien trouvé comme solution. (je parle pas techniquement, je parle en terme d’expérience)

Est-ce que quelqu’un a déjà vu comment font les autres ? Par exemple, Apple ils font comment si tu ajoutes ce genre de périphérique dans Home ? Google font comment ?

#14

Par exemple pour Home assistant par défaut tu affecte un device à une pièce, mais tu peux affecter un device feature à une autre pièce au besoin.

Pour Gladys ça reviendrai à cliquer sur la feature ( bloc gris) et modifier la pièce.

#15

Il faut prendre le problème à l’envers
Chaque fonctionnalité doit être rattachée à une pièce pas le périphérique
Mon périphérique est dans ma buanderie (tableau électrique) il gère 8 interrupteurs
chaque interrupteur est rattaché à une pièce (qui peut être la même)
exemple
Peripherique: Xiaomi
SID Xiaomi:…
Fonctionnalités:
commutateur1 -> pièce: salon -> nom: plafonnier
commutateur2 -> pièce: salon -> nom: applique gauche
commutateur3 -> pièce: cuisine -> nom: plafonnier
…

#16

Bonjour

Dans Jeedom, le périphérique (“equipement”) est assigné a une pièce mais on peut créer un “virtuel” qui ne contient que les fonctionnalités (“commandes”) nécessaires et l’associé à une pièce et lui donner un nom. On peut donc aussi mixer 2 périphériques dans un “virtuel”.

1 Like
#17

Je suis ne suis pas forcément d’accord, je trouve que ça complexifie beaucoup le produit pour résoudre un cas particulier qui représente qu’une petite partie de l’usage.

Pour repartir de la modélisation:

Dans Gladys 4, un device = un périphérique “physique” (une prise, une lampe, un interrupteur, etc…)

L’idée de la “pièce d’un device”, c’était juste de dire : ce device se trouve “physiquement” dans cette pièce. Jusque là vous me suivez, un device ne peut pas être physiquement dans plusieurs pièces en même temps donc là dessus pas de problème.

Du coup, si on a interrupteur/relais qui contrôle d’autres device physique, pour moi il faudrait que ces autres objets aient eux aussi un device dans Gladys. La solution des devices “virtuels” (je mets entre guillemet car ils ne sont pas virtuel, c’est bien des objets de la vie réel) me semble la plus proche de ce qu’on souhaite

Si on a un interrupteur qui contrôle 4 appareils dans 4 pièces différentes, pour moi ce n’est pas l’interrupteur qu’on veut contrôler, c’est les appareils dans les pièces. Donc il faudrait 5 device dans Gladys: 1 pour l’interrupteur, et 4 pour décrire les 4 appareils qu’on veut contrôler.

La brique manquante à Gladys actuellement reste le pont entre le périphérique contrôleur et le périphérique contrôlé.

1 Like
Retour module ewelink
#18

Je valide totalement le fait qu’un device physique 4 relais commande 4 devices. Je plussoie donc ton analyse. Maintenant il s’agit de rendre ca user friendly. Créer un device “virtuel” qui serait contrôler par une scène ne l’ai absolument pas à mon sens et on se retrouverait avec un nombre incalculable de scène à gérer.
Avoir un bouton qui créerai un device “virtuel” contrôlé par la feature lié le serait peut-être beaucoup plus.

#19

Je suis d’accord! Il faut faire un comportement natif et simple à mettre en place.

En fait il faudrait une intégration “device virtuel” ou l’utilisateur peut créer des devices autant qu’il veut, manuellement.

Il peut créer des features pour ces devices et chaque feature peut être “lié” à une autre feature d’un device existant dans n’importe quel autre intégration.

Quand la feature virtuel est contrôlée (Off -> On par exemple), alors l’état est propagé à la feature lié qui lui fait son boulot classique.

Est-ce que ça répondrait au problème de manière général?

1 Like
#20

En théorie je pense oui. A essayer donc, mais ce serait clairement efficace et utilisable pour tout les services où cette problématique se pose.

2 Likes