With the latest giant strides made by @pierre-gilles and all the developers since the return from vacation, Gladys V4 is almost ready to move to RC. The only real missing feature for me for complete home use (I’m speaking for the household users), is multi-account and therefore personalized Dashboard configuration for each user.
Almost fully operational on V4 (except for the barrier), this missing feature is starting to create tensions (fortunately modest) at home to decide:
which camera to display first,
which device and in what order,
etc.
This is actually a very good sign, as it means Madame is fully engaged.
However, it is unusable on the professional side by our healthcare professionals as long as this feature is not present. Therefore, I keep one foot in V3 for mode management as well.
Ah … then I must have misunderstood the vision of things because for me too it is two distinct things but I am indeed talking about multi-users.
Multi-dashboard, at least in what I understood and expected, is to have multiple configurable dashboards for each user account.
Multi-user is being able, as in Gladys V3, to log in with your email or account name and have your own Dashboards, in this case today your main Dashboard, as well as your scenes, your calendar, your owntrack.
And so each professional logs into their account, for which I have preconfigured the dashboard with their necessities. In the end, I thought that multi-dashboard was not needed for this;
I thought that in the DB
[details=« In the selector column you could put the account name and "_main" (here "thomas_main") »] image|690x175
[/details]
This leaves room to define multi-dashboard.
Of course, I was planning to do that too, but I didn’t have time this morning ^^ because this also interests me personally ^^
Mmm ok. I just want to remind you that your use case is really very very particular But we need to take it into account, while trying not to overcomplicate things for the majority who are in a simple situation.
My vision for v4 was to simplify, simplify, simplify. In v3, everything was « per user, » and frankly, it was too complex. Gladys is a product that the majority install « within a circle of trust, » so I wanted to avoid the trap of over-complicating access rules.
For the dashboards, for now, the dashboard feature was designed in « public » mode. There can be several dashboards, visible to everyone.
We will need to discuss this (maybe in a community call with several people?), I wonder if we want either:
Make dashboards personal
or leave dashboards public, and each person can choose their default dashboard.
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.
Having just finished developing injected variables in scenes, I’m starting on this highly requested feature
I’ve written functional specifications and designed a few screens, and I wanted to see what you think about them.
Functional Specification
As the first user of a Gladys instance, I am by default an « administrator ».
This user has the ability to create other users, other « administrators » or other « users »
Administrator: The default role of the first Gladys user, they have all rights.
User: A user has a restricted role with fewer rights. Hidden and blocked for them: All integrations in the « Devices » and « Weather » categories. They can configure the « Telegram » and « Caldav » integrations. The « Settings » tab is hidden for them.
Create a New User
The administrator goes to « Settings » => « Users »
They can create a user and set a password. It is considered that being in a circle of trust (the family) + for simplicity of configuration, the fact that the administrator sets the user’s first password is not a problem (the user can change this password later)
For me, the part I find more obscure is the rights section. You block integrations (service configurations), that’s fine, but you can also refuse to allow a person to access specific information. For example, access to the portal opening, access to certain cameras, access to a connected safe, etc.
To understand the requirement, would a list of « blacklisted » devices per user be sufficient?
Example:
User A is not allowed to use device X. They will not see the device anywhere and will not be able to control it.
The issues I see are:
Shared dashboards: What happens if you share a dashboard with someone whose device used on the dashboard is blacklisted?
Voice commands: If a device is blacklisted for a user, does that mean it is blacklisted in the « public unauthenticated » voice sensors of the house, since we can’t know who is speaking?
Scenes: We must ensure that a user has no indirect way to control a blacklisted device.
All future developments will always have to consider these permissions.
In principle, I’m not against it, but I get the impression that managing rights is mostly a utopia that everyone has in mind in the way of « I want to control everything, » and in reality, it’s mostly a tangled mess that makes product use and development twice as complex.
Even Apple doesn’t do it, honestly, it scares me They have hundreds of engineers earning $200k a year working on it since 2014, and even after so many years, they don’t do it
Yes completely! For me, it is necessary to give the possibility not to control certain devices. For example, at your place, you have a connected lock. You will have guests, you give them access to Gladys. You may not want these guests to unlock your front door. That’s how I see it.
Blacklisting is a good idea and in terms of integration, it’s rather « easy ».
They may not have thought about it / given it importance
Well then!! I wasn’t expecting that so soon!! What great news.
For my part, my opinion is not very important because we all now know the use I want to make of Gladys and I should not let my personal interest interfere too much.
However, even by setting aside the pro side etc., I agree with @damalgos.
There are indeed guests, but not only. We can already start with the children. Gladys’ accessibility and simplicity (which is its major asset and which you are very attached to @pierre-gilles - and now we are too) can quickly allow, for example, to integrate the barrier, or as @damalgos says, to the dashboard for a child. But also the management of the apartment/house heating, etc. etc.!! and more.
Administrator/user point of view not at all in the end. We start from the post that we want something simple, ok, and well, it is enough that it is only a possibility and not an obligation. With your idea of blacklisting devices, no problem. The user who does not need this right management does not touch anything at all. In the end, only developers like us will have a little more work.
And not only Apple, same for Alexa (I use it I haven’t found anything like that either), nevertheless, many people make the complaint. But they do not make the same product as Gladys, I think this will be a strong point that you can highlight.
Indeed, we must still see where it leads for the management of scenes etc. In a first step if this point of rights is implemented, it will be to effectively make only private for the dashboards and the scenes. Then just put the locks according to. For the chat, also.
In any case, what you present there is already very appetizing I find ^^ I loooooove ^^
I really like the idea. Only thing, how to allow an admin to configure the user’s dashboard who doesn’t have the right to do so? But it’s the easiest solution to implement that also doesn’t penalize the development side.
I was responding regarding this right. If your son does not have permission to modify the dashboard (No edit button), we need to determine how this Dashboard can be modified.
That’s an argument not to do it It’s no surprise if Apple/Amazon manage to get millions of users on their product: it’s simple and gets to the point.
If they don’t pay attention to it, it means it wasn’t that important in the end and there were surely more important features they dedicated their resources to (and they have plenty of resources! :p)
We must not forget that for every feature we develop, there’s a feature we don’t develop.
It’s simple: the community voted, it’s one of the most requested features, so I’m doing this feature We’re gradually moving forward in the list, it’s great!
However, they have millions of users, so their solution’s simplicity of use has paid off!
Whoa, a rights matrix is really something I want to avoid. From my experience in software development, it’s just a nightmare (both for the user experience and for the developer)!
Well, I’ve thought about it, and for me, it’s really two different subjects: multi-user and fine-grained rights management on devices.
It’s always something we can add later (it won’t be more complicated to add it later).
So my opinion:
We keep the « multi-user » feature alone, without complexity. No rights management on devices, no blacklist. So that we avoid a three-month tunnel effect, and that multi-user + multi-dashboard can be released quickly.
Once we have multi-user, we create a card in « feature request » for the device blacklist story, and it will be prioritized by the community against everything else!
I prefer to break down features into small developments to be able to release every week/2 weeks as we’ve been doing from the beginning, at least we’re able to iterate in short cycles and avoid infinite developments that don’t progress
Yes and no. Apple/Amazon/… aim for the general public with a maximum of basic features, compatibility, and very good overall functionality. On the other hand, Gladys targets users who potentially want to go a bit further in configuration. Scenes, management of all equipment with each other with a certain coherence. (not only other points in terms of data control, DIY, …)
These companies think in terms of cost. But the need is still present.
The issue in this example is that the need is different. Someone who buys an Alexa speaker wants, above all, a hub to perform daily actions without almost ever configuring home automation (timer, radio, music). With the added power of the notoriety/advertising, etc., of these companies, of course they dominate! And yet it doesn’t meet all needs. That’s why in home automation you have plenty of other players who are sometimes more relevant.
From the developer’s side, I don’t know, but from the user’s side, once it’s set up, you don’t touch it anymore.
If the user wants access to another integration, the administration can or cannot activate it.
In 2 steps, it’s good, it gives you time to refine.
But we need to take it into account, while trying not to overcomplicate things for the majority who are in a simple situation.
They have hundreds of engineers earning $200k a year working on it since 2014, and even after so many years, they don’t do it 
