Représentation des features de la Porte de Garage sur le DashBoard
D’ailleurs cela pose le problème de l’extinction globale de l’éclairage !! Alors, je suppose que comme on en avait discuté, il faut créer des types de feature pour les portes de garage, ou encore pour les barrières (avec une possibilité de stop pour laisser ouvert). Mais cela veut-il dire que sur le dashboard, il y aura une fenêtre par pièce par type de feature ?
Serait-il possible d’envisager du coup la possibilité d’une barre de recherche en haut de fenêtre pour accéder à la pièce que l’on souhaite rapidement ? Car il est déjà compliqué de retrouver une pièce sur une navigation windows avec 3 colonnes. en ayant 20 appareils + 4 caméras. Mais sur le Dashboard du téléphone via Gladys plus, c’est encore plus compliqué. Pour ma part je dois défilé énormément de haut en bas pour retrouver ce dont j’ai besoin ^^
Bien sûr ce n’est pas une priorité, mais penses-tu que cela est à prendre en compte ?
Salut @pierre-gilles
Alors en fait c’est plus complexe qu’il n’y parait je pense. De par mon rex, mon usage hebdomadaire est le suivant :
Pour la barrière :
Commandes :
Impulsion Ouverture 2 battants puis Fermeture Automatique (depuis la barrière),
Impulsion Ouverture 1 battant si piétons puis Fermeture Automatique,
Ouverture bloquée 2 battants,
Ouverture bloquée 1 battant,
Fermeture,
Fermeture bloquée (j’utilise ce mode en cas d’absence prolongée),
Déblocage / Déverrouillage.
Etats :
1 battant ouvert / Semi-Ouverte,
2 battants ouvert / Ouverte,
Fermée,
Bloquée.
Et pour la porte de garage :
Commandes :
1.1. Impulsion Ouverture,
1.2. Impulsion Fermeture,
1.3. Impulsion Stop.
Ou
2.1. Impulsion Ouverture puis remettre à zéro cette commande pour la stopper,
2.2. Impulsion Fermeture puis remettre à zéro cette commande pour la stopper.
Etats :
Ouverte,
Fermée,
Intermédiaire.
Serait-il possible ou penses-tu que l’idée n’est pas bonne, de mettre une icône d’état en en-tête, et de mettre les commandes en dessous sous forme de bouton poussoir ?
^^ Laisse tomber, désolé, je n’avais pas fait l’essai, je pensais que lorsque tu allumais interrupteur global d’une pièce , ça allumait les type de feature switch également, notamment les "Ouverture / Fermeture porte de garage. Mais suite à essai, je vois que non. Désolé !!
Sur ce point, est-il prévu quelque chose ? Car comme tu peux le voir, sur les switchs, on ne reporte que le nom du device, et non celui de la feature !!
Merci pour tes réponses dans tout les cas, et en effet :
C’est bien cela qui m’apportera plus de lisibilité. Après c’était aussi l’objectif d’un dashboard graphique pour ma part !!
Oui je le sais bien. Et c’est déjà une très bonne chose que ce soit noté ^^
Oula c’est une usine à gaz ton truc J’ai pas compris grand chose. On va essayer de simplifier ça, parce que là c’est clairement pas user-friendly.
Est-ce que tu peux me décrire tes cas d’usage, sans parler de comment tu le fais actuellement?
Je veux qu’on parte du besoin, pas de la technique. Je trouverais une solution simple et user-friendly, parce que là j’ai l’impression que le constructeur qui a fait ta barrière n’était pas vraiment un UX designer ^^
Tu peux me dire :
« Le matin, je sors faire des courses en voiture, j’ouvre la barrière (2 portes) puis elle se referme seule. »
« Le soir, je sors à pied, j’ouvre la barrière (1porte) »
On fera en sorte que tes cas d’usages soient rempli par Gladys, mais on trouvera probablement une autre modélisation que celui qui a conçu tes commandes actuelles.
Je comprend ton problème, mais cette solution ne va pas convenir à tout le monde. J’ai créé une issue GitHub =>
Je t’explique le problème: ton problème vient du fait que tu as des device a rallonge avec beaucoup de features, notamment des binary en doublon.
La plupart des intégrations n’ont pas ce problème et donc les gens n’ont même pas la possibilité de modifier les features name (cas du Philips Hue par exemple)
Il va falloir trouver une solution hybride, mais qui ne soit pas « mystique » pour autant. A réfléchir à tête reposée
Rien de compliqué, et c’est moi qui l’ai custom par rapport à mon besoin - Toutes les barrières fonctionnent pareil A la base tu as :
Commande ouverture 1 battant (ou partielle pour les barrières sur rail),
Commande ouverture 2 battants (ou complète pour les barrières sur rail),
Fermeture,
Temporisation « possible » de fermeture après x secondes.
Ensuite sur la carte électronique tu as des contacts disponibles pour les mêmes fonction avec en plus :
Stop.
J’ai donc raccordé tout ces contacts à un Arduino pour le besoin suivant :
Je dois recevoir un colis dans la matinée ou l’après-midi, je fais une ouverture bloquée, l’Arduino envoi la commande d’ouverture puis après x secondes (temps d’ouverture de la barrière) j’actionne le relais « Stop » pour la bloquée en position. Une fois le livreur passé ou après un laps de temps, je désactive l’ouverture bloquée ou je fais une commande fermeture pour couper le stop et la lancer en fermeture,
Idem lorsque je reçois du monde, ça évite de devoir rouvrir à chaque arrivée ^^
Lorsque ma conjointe travail, un scénario « Début Orthophonie » ou « Début Equithérapie » lié aux modes « Travail Orthophonie » ou « Travail Equithérapie » lance l’allumage des éclairages des pièces utilisées au besoin de la luminosité ainsi que l’Ouverture bloquée de la barrière pour l’arrivée de la patientèle. Lorsqu’elle quitte ces 2 modes ou passe en mode « Retour maison », la barrière est débloquée et fermée.
Idem pour notre locataire avec le mode « Travail Psychomotricité » qui en plus permet de relever la séparation des charges pour les pièces communes.
Pour la fermeture bloquée, comme je le disais, c’est une sécurité « en plus » en cas d’absence prolongée.
Pour le reste j’utilise les fonctions normales Ouverture / Ouverture 1 battant / Fermeture selon le cas :
J’ai un tag NFC sur le tableau de bordv+ Tasker. Quand je sors ou je rentre, je pose mon tel sur le tableau de bord et la commande passe,
Je reçois un invité surprise, je prend le 1er truc que j’ai sous la main, soit la télécommande, soit le tel et j’ouvre.
La barrière est restée ouverte suite bug ou autre, j’utilise soit la télécommande, soit le tel et je ferme.
Je ne gère pas la barrière de façon automatique
C’est à peu près tout. Du coup comme tu peux le voir rien de complexe finalement, j’ai juste détaillé les possibilités d’usage qui se comptent à ce nombre. Après clairement, j’utilise tout ces points en permanence.
Sur ce point je ne comprend pas. Justement si on prend l’exemple des philips hue, sur le dashboard pour le moment n’est repris que l’allumage de la lampe. Mais on est bien d’accord que par la suite on aura également la possibilité de gérer la couleur, la luminosité et la température. Est-ce que ce sera directement dans la même box que l’éclairage ? Si c’est le cas on reprendra bien son nom de feature et non de device.
Autre exemple : actuellement j’ai un device pour sauvegarder la « Tension moyenne et Intensité totale de la maison » avec 1 feature « Tension maison moyenne » et 1 autre « Intensité totale maison ». Egalement 1 device pour chaque phase (Triphasé) des données de puissance/énergie avec chacun 3 features : « Puissance Phase 2 maison », « Energie Phase 2 maison », « Energie totale Phase 2 maison »
Et sur le Dashboard on récupère bien les noms des features et non du device.
En image
Il en va de même pour une prise ou pour 1 device qui contiendrait plusieurs actions et donc plusieurs feature. Par exemple une prise avec relevé de la consommation. Quoiqu’il arrive, si un device est configuré avec 1 seul switch, ça ne changerai rien au fait qu’on récupère son nom de device, ou que le nom de feature sois le même que son nom de device. Après j’ai peut-être une vision tronquée de par le fait que je n’utilise que principalement l’Arduino pour ma domotique. Mais j’essaye de m’équiper de tout les types d’appareils actuellement pour avoir une vision plus globale.
En effet ^^ Peut-être que le plus simple pour que tout le monde s’y retrouve et pour avoir le plus d’ouverture serait d’ajouter un bouton sur la carte du device pour choisir si on souhaite utiliser le nom du device ou de la feature pour les cas dérangeant ?
J’ai rajouté un lien vers ton message à la carte GitHub:
Après on est d’accord, pour l’instant tu arrives à faire sans problème dans le service MQTT ce fonctionnement sans avoir de type « garage door » natif?
Ce que je voulais dire, c’est que le Philips Hue n’a qu’une feature de chaque type par device. Une lampe n’a qu’un seul « binaire », qu’un seul « couleur », qu’un seul « intensité ».
C’est pas dit !
Par exemple, voilà comme l’application Philips Hue fonctionne:
J’ai la liste des ampoules, puis quand je clique je vois apparaitre un color picker que je peux modifier.
Est-ce que l’application Philips Hue est claire et simple à utiliser ? Oui.
Est-ce que le développeur de l’application Philips Hue a décidé de nommer chaque fonctionnalité de chaque Hue? Non.
ll faut penser expérience utilisateur.
Nommer chaque fonctionnalité n’a pas de sens partout, le plus simple le mieux. Il y a une vrai réflexion de haut niveau qu’on va réaliser à chaque implémentation, réflexion qu’on doit faire sans penser une seule seconde à la technique: comment ça fonctionne sous le capot, l’utilisateur s’en fout
Le type « binary » est géré différemment des autres types de features, du fait de l’intégration Philips Hue.
En fait, en l’état, le type binary n’a pas été pensé pour être utilisé plusieurs fois dans un device, après ce n’est pas figé.
A voir, je pense qu’un cas spécial pour les devices MQTT n’est pas « dérangeant ». Je pense que faire du cas par cas par intégration c’est le meilleur moyen d’avoir une intégration fine.
En effet, j’ai fais ça se matin, mais j’ai repris le code et le create pour créer un device par commande (switch) du coup côté Integration/MQTT/Device/Feature, ce n’est pas pratique et lisible (mais finalement avec la barre de recherche on s’y retrouve), mais côté Dashboard c’est nettement mieux.
En effet, je suis totalement d’accord avec toi. Au final ce n’est pas le même usage du tout, et effectivement, en tout cas pour le moment, nous n’aurons ce « souci » qui n’en est pas un que du côté MQTT, ou en tout cas dans les devices « fait maison » ou qui ont un fonctionnement particulier.
Tout à fait !! Et en effet je parlais bien exclusivement pour l’intégration MQTT.
@Terdious Tu avais quelques soucis sur Gladys Plus, j’ai enquêté et j’ai trouvé le souci: il y avait un souci de cache sur un fichier clé de Gladys Plus (le serviceWorker, sw.js ), et ainsi certains fichiers se mettaient mal à jour. ( Le fichier en question https://plus.gladysassistant.com/sw.js )
Gladys Plus est une progressive web app qui fonctionne entièrement en local en offline, et qui est ainsi très rapide à démarrer. Pour se mettre à jour, le fichier sw.js n’a volontairement pas d’ID unique et ne doit pas être cachée par le navigateur.
Hors, par défaut, sur Netlify, ce fichier a une directive de cache de 10 jours.
J’ai corrigé ça, ce fichier n’est plus mis en cache et normalement le système de mise à jour du front devrait fonctionner à nouveau.
Pour tester, est-ce que tu pourrais vider le cache de ton navigateur sur la page “plus.gladysassistant.com”, puis recharger la page? Normalement ça devrait éliminer certains bugs “mystique” que tu avais qui n’était juste du qu’à ce problème
Je te remercie beaucoup pour cette investigation. J’espère que ce n’était pas du temps perdu seulement pour moi et que ça servira au global.
Je viens de relancer le navigateur proprement, ça fonctionne bien. Je reviendrai ici te prévenir si jamais je vois des choses réapparaître, mais tu as visiblement bien cerné le problème donc pas de raison ^^
Bonjour à tous
Je ne sais ps si je suis au bon endroit, mais Gladys 4 se déconnecte seul de temps en temps
Ill me dit ensuite que mon dasboard n’est pas configuré :
ffectivement, quand j’essaie de passer par TightViewer ou Putty, il ne se connecte pas
C’est bien pour ça que j’ai dû à 2 reprises passer par une réinstallation sur la carte SD
Tu dois avoir raison, j’ai un pb de stabilité avec mon Pi, mon réseau semblant stable de son côté
Mais est ce que ça ne peut pas être simplement la carte SD ?
Probablement, tu as surement trop de secteurs qui sont cramés et donc le système se corrompt trop facilement ! C’est courant avec les cartes SDs, je te conseille d’en changer
j’ai l’impression qu’il y a un bug sur les capteur on/off, parfois cela affiche, il y a quelques secondes et parfois cela affiche dans quelques secondes (au début du changement d’état)
Second point, la box est resizée à chaque changement de durée, est-il prévu de fixer une dimension à ces paramètres pour éviter de faire apparaître la scroll bar au moment ou cela change de durée ?
Il doit y avoir un décalage de quelques secondes entre l’heure de ton Raspberry Pi et l’heure de ton ordinateur sur lequel tu affiches Gladys. Ainsi, dans l’UI, il pense que la valeur a été créé dans le futur, et par conséquent, affiche « dans quelque secondes ».
Après, je suis d’accord, c’est pas terrible. On peut rajouter un check sur la date retournée par le Raspberry Pi.
Je n’avais pas encore utilisé Gladys sur une tablette, uniquement sur un pc et sur le téléphone et je me rends compte que l’affichage du dashboard est le même que sur mobile.
Je perd les 3 colonnes qui sont sur une seul.
Pourtant l’affichage et suffisamment grand, beaucoup plus que sur mobile.
Y a t-il pas un paramètre à modifier pour choisir l’affichage ?
