Qu’est-ce que tu attends comme contenu (brièvement) ?
Une description haut-niveau, un flowchart, une “fausse” interface ?
Une description purement utilisateur du fonctionnement attendu (textuel) + une maquette 
Au niveau de la description, ça doit être vraiment concret: qu’est ce qui se passe dans l’UI ?
Un exemple de spec fonctionnelle que j’avais fais pour le multi utilisateur:
1 « J'aime »
Merci, je vais me pencher dessus !
ça va prendre un peu de temps, mais je mettrait ce sujet à jour dès que j’ai une première version 
1 « J'aime »
Ok cool Pour moi la partie “spécification” c’est le plus gros du boulot pour un développement, donc ça aide vraiment quand il y a des specs claires de ce qu’on veut !
1 « J'aime »
Oh j’en suis bien conscient, c’est tellement plus simple et rapide de développer quelque chose de déjà précis et cadré que de partir dans tous les sens !
Malheureusement je ne compte pas les heures passés sur des projets pas cadrés avec une pseudo idée comme base de projet…
1 « J'aime »
@pierre-gilles, cette maquette est-elle parlante déjà ?
(accès public) Maquette : récupérer un état dans le temps.
Spécification fonctionnelle
- “Récupérer le dernier état” devient “Récupérer un état”
- L’état d’un appareil peut être récupéré suivant plusieurs possibilités :
- Dernière valeur
- Temps relatif (Il y a …)
- Par date
- Sur une période
Détail des possibilités évoquées
1. Dernière valeur
C’est exactement ce qui est fait actuellement, et assez parlant 
2. Temps relatif
Ici l’idée est de pouvoir dire : je veux comparer la valeur d’il y a 10 minutes (basé sur l’heure d’exécution de la scène).
On va pouvoir comparer deux valeur à 10 minutes d’écart, sans attendre pour autant !
Si la scène s’exécute à 12h00 et que l’utilisateur à choisi “il y a 10 minutes”, la valeur sera comparée à celle de 11h50m00s (±30s pour trouver une valeur). Si aucune valeur n’est trouvé entre 11h49m30s et 11h50m30s, le test échoue.
3. Par date
C’est un peu identique au temps relatif, mais on peut préciser une date bien précise sans limite particulière. On va donc pouvoir comparer des valeurs à plusieurs jours voire mois d’écart.
On peut imaginer ici, faire une comparaison sur une “valeur de référence” à une date bien précise.
Attention ici : il faudra alerter l’utilisateur s’il choisi une date à laquelle il n’existe pas de valeur.
4. Sur une période
Il s’agit du plus intéressant je trouve : l’utilisateur va être en mesure de comparer une valeur sur toute celles récupérées pendant une certaine période de temps.
Exemples :
- On peut vérifier si un capteur de mouvement a détecté un mouvement dans les 10 dernières minutes (basé sur l’heure d’exécution de la scène).
- On peut vérifier si une prise a consommé un certain niveau de puissance instantané dans les 30 dernières minutes
- etc…
Dans le cas d’un capteur (ou actionneur) dont les valeurs peuvent changer très régulièrement et ne sont pas forcément binaires (température, consommation en Watt, luminosité en Lux, etc.), la valeur de “référence” utilisée dans la scène pour le test sera comparée à toutes celles enregistrées.
Si je veux vérifier que ma prise a consommé moins de 15W dans les 30 dernières minutes, le test va s’écrire : “Ma prise” < “15W” dans les “30 dernières minutes”.
Gladys va alors vérifier dans la base de données si dans toutes les valeurs récupérées ses 30 dernières minutes ne dépassent pas les 15W.
Récupération des valeurs de test
Comme pour le bloc “récupérer la dernière valeur”, il faudrait que la valeur utilisée lors des tests soit automatiquement récupérée (temps d’enregistrement de la valeur + valeur).
Exemple :
- Je fais un test sur l’équipement “mon-capteur” pour vérifier s’il y a eu du mouvement dans les 10 dernières minutes, donc entre 11h50 et 12h00 (heure d’exécution de la scène).
- Si du mouvement à été enregistré disons à 11h56, deux variables sont créées dans la scène : “mon-capteur-test-1-valeur” et “mon-capteur-test-1-heure”.
- Je suis en mesure d’envoyer un message avec ces deux variables, pour m’avertir “mouvement détecté (value = 1) à 11h56.”
1 « J'aime »
J’aime beaucoup tes propositions et je m’imagine déjà utilisé la période pour dire c’est bon j’éteins la lumière dans la pièce
Qu’est ce que ça veut dire pour toi « la valeur d’il y a 10 minutes » ?
Que se passe-il lorsqu’il y a plusieurs valeurs dans la période? Gladys prend laquelle?
Je n’ai pas l’impression que ce soit ce qu’on veut. Je vois très bien le besoin, mais sur la spec la façon dont tu répond au besoin me semble très étrange et bizarre 
@VonOx Sans lire la proposition ci-dessus pour pas t’influencer, comment tu verrais toi la mise en place de la scène dont tu me parlais avec tes capteurs de mouvements ?
J’ai rajouté quelques précision, est-ce plus compréhensible ?
Sinon, hésite pas à me dire ce qu’il manque, qui est flou ou peu donner lieu à des situations illogiques, je continuerai la réflexion !
Message mis à jour @pierre-gilles, avec plus de détails sur le fonctionnement attendu côté utilisateur et la gestion dans Gladys.
Je ne vois pas encore d’autres cas particuliers à gérer, voyons ce à quoi chacun pense pour améliorer tout ça
Ok ( mais trop tard j’ai lu déjà 
)
Trigger:
Motion détecté
Condition: ( Continuer seulement si )
Time range ( on défini une plage d’action )
1. Sélection directe sur un slider double
ou
2. En fonction de sunset / sunrise ( avec un offset car généralement on allume ses lumières avant que le soleil ne se couche )
Petit bonus si on peut choisir aussi quel jour de la semaine la scène est active
Action:
=> Allumer une pièce ou certaine lampes
Le petit plus à apporter pour faciliter la vie et éviter trop de scènes. Laisser la possibilité à l’utilisateur ( checkbox ? ) de choisir si Gladys doit éteindre ces lampes au bout d’un certain temps sans mouvement détecté ( genre 2 minutes )
Quelques screenshot de HA , c’est moche et on peut vraiment faire mieux en terme d’UX
Condition ( Sunset / Sunrise avec offset de 10 minutes )
Extinction au bout de 2 minutes
Tu penses quoi de ma proposition (modifiée entre temps) plus haut ?
Qu’est-ce qu’il faudrait modifier, ajouter, préciser pour toi ?
@VonOx et @pierre-gilles, comment je dois avancer sur la fonctionnalité côté spécification ?
Quels sont vos (nouveaux) retours ? 
Je suis pas entièrement d’accord avec ta proposition de mon côté, je pense qu’il faut vraiment penser plus à l’utilisateur final et à tous les cas d’usages qui vont découler de cette fonctionnalité.
J’ai pas de réponses précises à te donner sans travailler moi même sur le sujet à temps plein, je pense qu’il faut que je passe une paire d’heures dessus avant de pouvoir te répondre ça sera pas avant la fin de la semaine/semaine prochaine à mon avis
Hello!
Du coup j’ai travaillé toute la journée sur le sujet, et j’ai 3 propositions pour pouvoir répondre aux différentes problématiques
Je répond ici car c’est un sujet où on parle de scènes, mais ça n’a rien à voir avec le titre du topic. Une fois qu’on sera d’accord on pourra renommer le développement.
La problématique
Je suis reparti des différents besoins, sans penser au produit, juste au besoin final:
- Etre capable d’éteindre la lumière dans une pièce si il n’y a pas de mouvements pendant XX minutes
- Etre capable de recevoir une alerte si la température du frigo passe en dessous de 10°C pendant au moins 1h.
- Etre capable dans une scène de n’exécuter des actions que si le soleil est en état lever/coucher/avant lever moins 10 minutes, après coucher + 30 minutes, etc…
- Etre capable d’exécuter une scène (ou parti d’une scène) selon une condition temporelle. Exemple: si il est avant 12h/après 14h/entre 12h et 14h/le mardi, mercredi et jeudi entre 7h et 8h/et plein d’autres.
A partir de ce cahier des charges, j’ai creusé un peu comment on pourrait avoir ça dans Gladys.
J’ai pas mal aimé ce que faisait home assistant sur la partie “maintenir une condition pendant XX minutes”, et je suis parti sur une solution proche de la leur pour cette partie.
Après, je me pose encore des questions (marqué sur le document), tout n’est pas encore clair sur le fonctionnel.
Les maquettes (avec explications) sont disponibles ici: New scenes triggers/conditions/actions
Et aussi dispo en export image ci-dessous:
Qu’en pensez-vous ?
@lmilcent Au final c’est très différent de ta proposition 
Désolé, pour pas perdre de temps je suis parti sur ce que je voyais, et ensuite on peut effectivement voir qu’est ce qui répond le plus aux problématiques.
Note: Si vous avez des cas qui sont mal couvert par ma proposition, hésitez pas à rebondir dessus Je parle de cas pratiques et concret chez vous, on est vraiment dans la pratique là, pas dans de la théorie.
1 « J'aime »
Je vais regarder tout ça merci pour ton temps passé dessus
Ce matin justement j’y pensais en pensant à un nouveau besoin (lié) :
- Être en mesure d’exécuter une scène en fonction de la moyenne des valeurs d’un capteur sur une période de temps
Exemple : Si la température du frigo est en moyenne de 1°C ces 2 dernières heures, envoyer un message pour rappeler de changer le thermostat.
Je vais étudier ta proposition et te faire mes remarques dès que possible
1 « J'aime »
Intéressant ce besoin, est-ce que l’histoire de la moyenne est vraiment requise, où est-ce que une comparaison marcherait aussi ? Genre si tu dis « Si la température du frigo est inférieur ou égale à 1.5°C ces deux dernières heures », ça marcherait ? )
Pour moi c’est un peu différent de cette manière. Je pourrais savoir s’il y a eu un pic (haut ou bas) mais pas si le frigo est trop froid en général.
Seule la moyenne me permettra de savoir s’il est trop froid sur 2 h par exemple.
Condition Temporelle
- Case N°1 → OK
- Case N°2 → Si une condition n’est pas remplie, elle est vrai par défaut.
Dans l’exemple des condition horaires, “Après 9h00” et “Avant <vide>” sera vrai. A 8h, on ne sera pas après 9h, mais avant <vide>. La condition sera validée ou pas ?
Condition sur le soleil
C’est clair et limpide, je ne vois pas d’autres cas pour le moment.
Amélioration d’un capteur existant
C’est ce qui répond à une de mes problématiques
1. Il faut désormais que les capteurs de mouvement envoient un état “pas de mouvement détecté” juste après un “mouvement détecté”.
→ D’après l’interface web du projet Zigbee2Mqtt, mes capteurs Xiaomi Aqara Zigbee renvoient bien cet état.
Mais pour ceux qui sont identifiés comme n’envoyant pas cet état, Gladys (ou le service) peut le faire pour lui au après 20 secondes comme ça semble être le cas avec mon capteur ?
4. A définir: Que se passe-t-il si la condition est valide pendant 4 heures ? […] une execution potentiellement à l’infinie de la scène?
→ J’avais justement ce besoin : limiter le nombre d’exécution d’une scène dans la journée.
Exemple concret, qui serait résolu en même temps que cette problématique : mon capteur de mouvement (dans la boite aux lettre) génère 2x événements et ma scène est exécutée deux fois.
Home Assistant propose un “bouncer” je crois, pour ne prendre en compte qu’un seul des deux événements.
Je pensais aussi proposer dans les scène, au niveau de la condition de déclenchement, une nouvelle possibilité de limiter le nombre d’exécution. 1x / heure, 1x / minute, 10x / jours, etc.
Non, « Après 9h » la condition est vrai si il est après 9h c’est tout
Je voyais plus ça direct après le mouvement, en mode retour à 0 après un mouvement.
Cette question @VonOx je serais intéressé de savoir comment ça marche côté home assistant ?
Tu peux déjà le faire avec la condition « Exécuter seulement lorsque le seuil est passé ( et non pas à chaque valeur envoyée ) » sur la box « changement d’état de l’appareil ».
Cette condition fait que seule les changements de valeurs sont pris en compte, si il y a 2 fois la même valeur la scène ne sera exécutée qu’une seule fois
Je suis d’accord que ça peut être pratique! Après dans ce cas là, je pense pas que ce soit la solution, je pense que la box « changement d’état de l’appareil » gère le cas toute seule