Avec les dernières avancées à pas de géant de @pierre-gilles et de tous les devs depuis le retour de vacance, Gladys V4 est presque fin prête à passer en RC. Le seul vrai manque pour moi pour un usage complet à la maison (je parle donc pour LES utilisateurs du domicile), c’est le multi-compte et donc la configuration personnalisée pour chacun du Dashboard.
Etant presque plein pot sur la V4 (sauf pour la barrière) ce manque arrive à créer des tensions (modeste heureusement ^^) à la maison pour savoir :
quelle camera afficher en 1er,
quel device et dans quel ordre,
etc.
Ce qui est est très bon signe d’ailleurs, car cela signifie que Madame s’y intéresse pleinement.
Toutefois inutilisable du côté pro par nos professionnelles de santé tant que cette fonctionnalité n’est pas présente. Du coup je garde un pied dans la V3 pour la gestion des modes également.
@Terdious Très intéressant ton retour, parce que ce que tu exprime comme besoin c’est pas que le multi-utilisateur te manque, c’est que le multi-dashboard te manque!
Pour moi c’est deux choses différentes, qu’on va faire certes, mais il faut prioriser.
Est-ce que tu pourrais faire une autre carte pour le multi-dashboard et parler de ton cas d’usage là bas?
Ah … alors j’ai dû faire erreur sur la vision des choses car en effet pour moi également il s’agit de 2 choses distinctes mais je parles bien du multi-utilisateurs.
Le multi-dashboard, en tout cas dans ce que j’en comprenais et attendais c’est avoir plusieurs dashboard configurable sur chaque compte utilisateur.
Le multi-utilisateur c’est pouvoir, comme dans Gladys V3, pouvoir chacun se connecter avec son adresse mail ou nom de compte et avoir ses propres Dashboard, en l’occurence à ce jour son Dashboard principal, ainsi que ses scènes, son calendrier, son owntrack.
et du coup chaque professionnel se connecte sur son compte dont j’ai préconfiguré le dashboardavec leur nécessaire. Au final je pensais qu’il n’y avait pas besoin du multi-dashboard pour cela;
Mmm ok. Ton cas d’usage est vraiment très très particulier je le rappelle Mais il faut le prendre en compte, tout en essayant de ne pas trop complexifier pour la majorité qui est dans une situation simple.
Ma vision sur la v4, c’était justement de simplifier simplifier simplifier. La v3 tout était “par utilisateur”, et franchement c’était trop complexe. Gladys c’est un produit que la grande majorité installe “dans un cercle de confiance”, je voulais donc éviter le piège de l’over-complexification des règles de droits.
Pour les dashboard, pour l’instant la feature dashboard a été conçu en mode “publique”. Il peut y avoir plusieurs dashboard, visible par tous.
Il va falloir en discuter (peut-être en appel communauté à plusieurs?), je me demande si on veut soit:
Rendre les dashboard personnel
ou laisser les dashboard publique, et chacun peut choisir son dashboard par défaut.
En effet je pense qu’il peut-être intéressant de faire un appel communauté, intégrant ce point précis, mais peut-être pourrais-tu créer un fil pour préparer celui-ci dans le but de regrouper plusieurs sujet. De mon côté je suis très intéressé par ces appels ^^ Si tu en as le temps, serait-il possible d’en prévoir à nouveau de manière récurrente ?
En effet pour ce cas bien précis (je veux dire des professionnels de santé), c’est très particulier. Mais ce n’était là qu’un exemple de cas particulier pour faire transparaître que chacun peut en avoir, et que si Gladys peut réussir à faire en sorte de gérer cette flexibilité, tout en ayant une façon simple de le configurer, ça peut intéresser beaucoup de monde.
Je suis totalement d’accord, et ce depuis le départ, sur la vision et la construction que tu fais de Gladys. Mais surtout sur la ligne de conduite à tenir et notamment la documentation qui devient au fur et à mesure un point des plus important. Mais AMHA, cela ne doit pas empêcher de gérer des choses un peu plus précises. Car dans ce cas on écarte une grande partie de la population. Et toujours AMHA, même dans un « cercle de confiance », on ne devrait pas « interdire » à l’utilisateur d’aller plus loin.
Bon je reste sur le cas du Multi-utilisateur et je me permet 2 exemples :
Je suis un utilisateur lambda, j’utilise Gladys seul ou en couple Condition préalable : Avoir côté DEV mis en place un « Type de Scène » qui peut être de Type « Principale » ou « Compte Utilisateur » en DB + dans la table "t_scene avoir ajouté une colonne Type de Scène ou bien automatiser la colonne Selector pour y intégrer le Type de Scene.
Je peux :
soit créer mon compte (Admin de base), donner l’accès à mon/ma conjoint(e) et on partage tout. Rien de plus à configurer par rapport à aujourd’hui. Lorsque je crée une scène, elle est de toute façon créée en « Principale »
soit créer 2 comptes (Admin de base - rien à toucher de supplémentaire par rapport à maintenant, à la création du compte on propose de base le type Admin), chacun à son compte et :
configure son dashboard à partir de tout les devices créés,
chacun configure son Agenda (lié à son compte mail / agenda),
chacun peut créer et voir / modifier des scènes du type « main » (liste déroulante en ouvrant les scènes proposant les types "Main / Compte utilisateur [càd prise en compte du créateur de la scène]) qui peut-être défini côté dev dans une nouvelle colonne de la DB ou en ajoutant « _main » ou « _nomcompte » au selector si on ne veut pas toucher à la DB.
chacun configure ses scènes sur Agenda (messages envoyés sur le compte Telegram configuré par ex.) en type « Compte Utilisateur ».
Je suis un utilisateur qui souhaite m’équiper entièrement en domotique et utiliser pleinement la sécurité et la facilité d’automatisation que peut offrir la domotique : Condition préalable : Idem 1. + Avoir créer une table « Types de comptes utilisateur » + Développer une page pour définir (de manières simple, cela peut-être en haut de page un champs ou on tape le nom de type de compte avec un bouton « Nouveau » et en dessous la liste des types de comptes avec un bouton « Configurer » à côté) ces « Types de comptes utilisateur » pour définir ce qu’ils peuvent voir / modifier (par exemple cacher toutes les vues à part le Dashboard ; cacher les scènes de type « Principale » mais laisser l’utilisateur créer ses propres scènes ; etc.) tout ceci de manière simple (par exemple case à cocher) + Ajouter une colonne dans la table t_device ou t_device_feature de la DB de type multiple pour pouvoir définir les types de comptes qui peuvent y avoir accès.
Du coup je peux :
Créer mon compte Admin,
Créer un compte Admin pour ma conjointe, identique au point 1.
Créer un Type de compte « Ados », ma fille/mon fils a 16 ans et elle/il connait la domotique, je lui laisse les accès aux vues Dashboard / Chat / Intégrations / Calendar / Maps / Scènes et lui laisse l’accès aux Intégrations seulement de Type Calendar / Communication. Pour son Dashboard, je lui laisse la possibilité d’afficher la Météo / la Présence Utilisateur à la Maison / aux Devices des pièces communes et de sa chambre mais pas de notre chambre ni des devices automatisés / Aux caméras principales mais pas à toutes / A ses propres Scènes mais pas aux Scènes définies en type « Principale »,
Créer un Type de compte « Enfants », ma fille/mon fils a 10 ans et s’initie à la domotique, je lui laisse les accès aux vues Dashboard / Chat / Maps. Pour son Dashboard, je lui laisse la possibilité d’afficher la Météo / la Présence Utilisateur à la Maison / aux Devices des pièces communes mais pas à la télé et de sa chambre mais pas de notre chambre ni des devices automatisés / A la caméras de l’enclos des poules par ex. mais pas aux autres / A ses propres Scènes mais pas aux Scènes définies en type « Principale »,
Créer un Type de compte « Invités de confiance », mes amis/ma famille qui passent de temps en temps souhaitent pouvoir gérer la musique, la télé ou une ambiance, de temps à autre ils viennent à la maison m’emprunter un outil mais je ne suis pas souvent là, je leurs laisse les accès aux vues Dashboard / Scènes. Pour leur Dashboard, je laisse la possibilité d’afficher la Météo / Pas la présence utilisateur / aux Devices du salon, de l’extérieur et du garage, notamment la serrure de la porte de cette dernière pièce ainsi qu’à la barrière mais pas au reste / Pas aux caméras / Au Scène type « Principale » mais je lui interdit de définir ses propres scènes,
Créer un Type de compte « Entretien ménager », j’ai une femme de ménage qui vient 1 fois par semaine le Mardi entre 13h et 16h, je lui laisse l’accès à la vue Dashboard seulement que je vais définir avec les Devices de la barrière, la serrure électronique de la porte d’entrée de la maison, les éclairages de la maison, la musique, et la vanne d’eau de la cuisine mais à rien d’autre. J’activerais son compte (par l’intermédiaire d’une scène par exemple ?) le Mardi à partir de 12h et désactiverais ce même compte à partir de 19h (heure de mon retour - au cas où elle finisse plus tard un jour) ce même jour,
Créer un Type de compte « Entretien extérieurs », j’ai un jardinier qui vient 3 fois par semaine les Lundi, Mercredi, Vendredi entre 17h et 18h30, je lui laisse l’accès aux vues Dashboard / Scènes avec pour les Devices : la barrière, la serrure électronique de la porte du garage et celle de la serre (oui il y a des outils dedans ^^), les éclairages du garages, des extérieurs (pour l’hiver) et de la serre, la musique extérieure (ça j’ai vraiment ^^), la prise de la pompe du puit et les vannes d’alimentation en eau des chevaux, de la serre et des plantes extérieurs. J’activerais son compte les jours correspondants à partir de 16h30 et désactiverais ce même compte à 18h35 (je ne souhaite pas qu’il termine plus tard un jour) ces mêmes jours,
Exemples professionnels
Pour @Shermi (sur slack) :
Créer un Type de compte « Clients », j’ai un petit hôtel avec 10 chambres et j’ai installé des serrures connectées sur chaque porte. Je crée un compte utilisateur par chambre et je peux modifier le mot de passe de chaque compte depuis mon compte Admin. Je peux grâce à un jeux de configuration précréer des scènes par chambre pour gérer des ambiances dont il aura accès sur la seule vue Dashboard, et référencer un compte Télégram puis désactiver la vue des Intégrations. Un client réserve pour la semaine, j’active le compte pour cette même durée et donne le couple nom de compte / mdp lors de son arrivée il a accès via l’adresse https configuré par le gestionnaire directement à sa porte de chambre, à la zappette télé et à tout ce qui peut-être domotisé dans sa chambre ainsi qu’aux démarrage des scènes liées au compte (donc à la chambre). Pourquoi pas également grâce au chat à des demandes direct pour commander son petit déjeuné en précisant son numéro de chambre. Lorsque son séjour est terminé, je désactive le compte.
Pour moi :
Créer un Type de compte « Cabinet Professionnel n°1 », J’ai un cabinet médical partagé par 2 professionnelles qui partagent notre portail d’entrée. Je crée un compte utilisateur par professionnelle. Je leur donne accès aux vues Dashboard / Chat / Intégrations / Calendar / Maps / Scènes et leur laisse l’accès aux Intégrations seulement de Type Calendar / Communication. Pour leur Dashboard, je leur laisse la possibilité d’afficher la Météo / les Devices portail, éclairages extérieurs, de leur cabinet, de la salle d’attente et des toilettes / La caméra du portail (Arrivée patient sur sonnette = sécurisation) / A leurs propres Scènes mais pas aux Scènes définies en type « Principale », je peux ainsi configurer sur chacun de leur compte en lien avec leur compte, l’automatisation des éclairages et du portail par rapport à leurs horaires de travail via l’Agenda,
Créer un Type de compte « Emplacement Camping », dans le même ordre d’idée que l’exemple de l’hôtel au-dessus pour gérer les emplacements indépendamment.
(Tout ceci ne sont que des exemples de ce qui pourrait être envisagé, je n’ai pas encore d’enfants, mais au vue de ce qu’on a pu lire sur le forum depuis toutes ces années, j’imagine les cas de figurent pour certain(e)s)
Voilà, désolé beaucoup d’exemples, mais je préférais parler de tout ce que j’avais en tête sur ce sujet. Et côté expérience utilisateur, pour le point 1., elle ne change rien à aujourd’hui. Tout serait automatiquement créer en « Admin », toutes les options cochées de base, tout devices accessibles à tout utilisateur et toute scène créée en « Principale ». La configuration ne serait que dans le sens down. Il suffirait ensuite dans la vue création d’un utilisateur de mettre un lien vers la doc (ex. : « Pour aller plus loin ») et d’y expliquer comment configurer tout ça si et seulement si on souhaite configurer spécifiquement des comptes.
PS : C’est sûr que côté DEV ça demande du temps à passer, mais AMHA les possibilités de domotisation complète, mais aussi du coup de bouche à oreille et de démonstration serait énorme.
Venant de finir le développement des variables injectées dans les scènes, je me lance sur cette fonctionnalités qui est dans les plus demandées
J’ai écris des spécifications fonctionnelles + designé quelques screens et je voulais voir avec vous ce que vous en pensiez.
Spécification fonctionnelle
En tant que premier utilisateur d’une instance Gladys, je suis par défaut “administrateur”.
Cet utilisateur a la possibilité de créer d’autres utilisateurs, d’autres “administrateurs” ou d’autres “utilisateurs”
Administrateur : Le rôle par défaut du premier utilisateur Gladys, il a tous les droits.
Utilisateur: Un utilisateur a un rôle restreint avec moins de droits. Lui sont masqués et bloqués: Toutes les intégrations de catégorie “Devices” et “Weather”. Il peut configurer les intégrations “Telegram” et “Caldav”. L’onglet “Settings” lui est masqué.
Créer un nouvel utilisateur
L’administrateur se rend dans “Settings” = > “Users”
Il peut créer un utilisateur et lui définir un mot de passe. On considère qu’étant dans un cercle de confiance (la famille) + par simplicité de configuration, le fait que l’administrateur définisse le 1er mot de passe de l’utilisateur n’est pas un problème (l’utilisateur peut modifier ce mot de passe par la suite)
Moi la partie que je trouve plus obscure c’est la partie droit. Tu bloques les intégrations (configuration des services) ca ok, par contre tu peux très bien refuser qu’une personne accède à des informations spécifiques. Par exemple accès à l’ouverture du portail, accès à certaines caméras, accès à un coffre connectés etc.
Que je comprenne le besoin, est-ce qu’une liste de device “blacklisté” par utilisateur serait suffisante ?
Exemple:
Utilisateur A n’a pas le droit d’utiliser le device X. Il ne verra pas le device nul part et ne pourra pas le contrôler.
Les problèmes que je vois, c’est:
Les dashboard partagé: que se passe-t-il si tu partage un dashboard avec quelqu’un dont le device utilisé sur le dashboard est blacklisté ?
Quid des commandes à la voix ? Si un device est blacklisté pour un utilisateur, est-ce que ça veut dire qu’il est blacklisté dans les capteurs de voix “publique non authentifié” de la maison, vu qu’on est incapable de savoir qui parle ?
Scène: Il faut être sur qu’un utilisateur n’a pas de moyen détourner de contrôler un device blacklisté
Tous les développements futurs devront toujours prendre en compte ces permissions.
Dans l’idée, je ne suis pas contre, mais j’ai l’impression que la gestion des droits c’est surtout une utopie que chacun se fait en mode “je veux tout contrôler”, et dans la réalité c’est surtout un sac de noeud qui rend l’utilisation du produit, et le développement 2x plus complexe.
Quand même Apple le fait pas, franchement ça me fait peur Ils ont des centaines d’ingénieurs à 200k l’année qui travaille dessus depuis 2014, et même après autant d’années ils le font pas
Yes complètement ! Pour moi il faut donner la possiiblité de ne pas contrôler certains équipements. Par exemple chez toi tu as une serrure connecté. Tu vas avoir des invités, tu leurs donnes accès à Gladys. Tu ne veux ptet pas que ces invités déverrouillent ta porte d’entrée. Moi je vois ça comme ça.
Blacklister c’est une bonne idée et niveau intégration c’est plutôt « facile ».
Alors là !! Je ne m’y attendais pas si vite !! Quelle bonne nouvelle.
Pour ma part, mon avis n’est que peu important car on sait maintenant tous l’usage que je veux faire de Gladys et je ne dois pas faire entrer trop personnellement mon intérêt.
Toutefois, même en mettant de côté le côté de pro etc, je suis du même avis que @damalgos.
Il y a certes les invités, mais pas que. On peut déjà commencer par les enfants. L’accessibilité de Gladys et sa simplicité (qui est son atout majeur et sur lequel tu es très attaché @pierre-gilles - et maintenant nous aussi) peuvent amener très rapidement à pouvoir intégrer par exemple la barrière, ou comme le dit @damalgos, au dashboard pour un enfant. Mais également la gestion du chauffage de l’appart / la maison, etc. etc. !! et on en passe.
Point de vue administrateur/utilisateur au final pas du tout. On part du posta qu’on veut un truc simple, ok, et bien, il suffit que ce ne soit qu’une possibilité et pas une obligation. Avec ton idée de blacklister les appareils, aucun soucis. L’utilisateur qui n’a pas besoin de cette gestion de droit ne touche absolument à rien. Au final il n’y aura que les développeurs comme nous qui auront un peu de boulot en plus.
Et pas que Apple, pareil pour Alexa (je l’utilise je n’ai rien trouvé de tel non plus), pour autant, de nombreuses personnes en font le reproche. Mais il ne font pas non plus le même produit que Gladys, ce sera je pense un point fort que tu pourras justement mettre en avant.
En effet, il faut tout de même voir où ça amène pour la gestion des scènes etc. Dans un premier temps si ce point des droits est mis en place, il s’agira de ne faire effectivement que du privé pour les dashboards et les scènes. Après ne reste qu’à mettre les verrous en fonction. Pour le chat, également.
Dans tout les cas, ce que tu présentes là est déjà très appâtant je trouve ^^ J’adoooooore ^^
J’aime beaucoup l’idée. Seule chose, comment laisser un admin configurer le dashboard de l’utilisateur qui n’en a pas le droit ? Mais c’est la solution la pus “facile” à mettre en oeuvre qui en plus ne pénalise pas la partie développement.
Je répondais par rapport à ce droit. Si ton fils n’a pas l’autorisation de modifier le dashboard (Pas de bouton éditer), il faut définir comment on pourra modifier ce Dashboard.
C’est un argument pour ne pas le faire ça C’est pas une surprise si Apple/Amazon arrivent à avoir des millions d’utilisateurs sur leur produit: c’est simple et ça va à l’essentiel.
Si ils n’y portent pas de l’importance, c’est que ce n’était pas si important que ça au final et qu’il y avait sûrement des fonctionnalités plus importante auxquels ils ont dédiés leurs ressources (et ils en ont des ressources eux ! )
Il ne faut pas oublier que pour chaque fonctionnalité qu’on développe, il y a une fonctionnalité qu’on ne développe pas.
C’est simple: la communauté a voté, c’est une des fonctionnalités la plus demandée, je fais donc cette fonctionnalité On avance progressivement dans la liste, ça fait plaisir !
Pour autant, ils ont des millions d’utilisateurs, c’est donc que la simplicité d’usage de leur solution a payé !
oula, une matrice des droits c’est vraiment le truc que je veux éviter. D’expérience en développement logiciel, c’est juste l’enfer (autant pour l’expérience utilisateur que pour le développeur) !
Bon j’ai réfléchi, et pour moi c’est vraiment 2 sujets différents le multi-utilisateurs et la gestion fine des droits sur les devices.
C’est toujours quelque chose qu’on peut rajouter plus tard (ça sera pas plus compliqué que de l’ajouter là).
Donc mon avis:
On garde la fonctionnalité « multi-utilisateurs » seule, sans complexité. Pas de gestion des droits sur les devices, pas de blacklist. De sorte qu’on évite un effet tunnel de 3 mois, et que le multi-utilisateur + multi-dashboard puisse sortir vite.
Une fois qu’on a le multi-utilisateurs, on créé une carte dans « feature request » pour l’histoire de la blacklist des devices, et ce sera priorisé par la communauté contre tout le reste !
Je préfère découper les fonctionnalités en petit développements pour pouvoir release toutes les semaines / 2 semaines comme on fait depuis le début, au moins on est capable d’itérer en cycle court et on évite les développements infinis qui n’avancent pas
Oui et non. Apple / amazon / … visent le grand publique avec un max de fonctionnalité basique, de compatibilité et un fonctionnement global très bon. Par contre gladys vise des utilisateurs qui veulent potentiellement aller un peu plus loin sur la configuration. Scènes, gestion de tous les équipements entre eux avec une certaine cohérence. (pas que d’autres points en terme de contrôle de données, diy, …)
Ces entreprises réfléchissent en terme de coût. Mais le besoin il est quand même présent.
Le soucis dans cet exemple c’est que le besoin est différent. Quelqu’un qui va acheter une enceinte alexa, il veut avant tout, une borne pour réaliser des actions du quotidien sans presque jamais configurer de domotique (minuteur, radio, musique). Avec en plus la force de la notoriété / pub etc de ces entreprises, forcément qu’ils dominent ! Et pourtant ça répond pas à tous les besoins. Pour ca qu’en domotique tu as pleins d’autres acteurs qui sont parfois plus pertinents.
Du côté du développeur je ne sais pas, mais du côté de l’utilisateur une fois que c’est paramétré on y touche plus.
Si l’utilisateur veut avoir accès à une autre intégration, l’administration peut ou non l’activer.
En 2 étapes, c’est bien, ça te laisse le temps de peaufiner.
Mais il faut le prendre en compte, tout en essayant de ne pas trop complexifier pour la majorité qui est dans une situation simple.
Ils ont des centaines d’ingénieurs à 200k l’année qui travaille dessus depuis 2014, et même après autant d’années ils le font pas 
C’est pas une surprise si Apple/Amazon arrivent à avoir des millions d’utilisateurs sur leur produit: c’est simple et ça va à l’essentiel.