Réflexion sur les capteurs d'ouverture

Bonjour,

Je souhaite savoir facilement à quelle heure à été ouverte ma porte d’entrée.
Pour ça j’ai crée un graphique binaire affichant la valeur de mon capteur d’ouverture, mais je ne trouve pas ça super.
D’abord, le graphique fait ce qu’on lui dit : affiche par rapport au temps l’état de mon capteur, sauf qu’une porte ça s’ouvre et se ferme en 10s, donc à l’échelle du graphique (au mieux 1h) on ne voit presque rien (juste un pic, des fois moins large que 1 pixel).
Et ensuite ce n’est pas très rapide d’accès, j’ai vu que je peux cliquer sur le graphique pour avoir plus de détail, mais ça reste laborieux (faut cliquer au bon endroit ect)

Est-ce qu’il y aurait une autre façon de faire ?
Sinon, est-ce qu’il n’y aurait pas un “objet de type porte” que l’on pourrait créer pour gérer ça ?
J’ouvre la question :slight_smile:

Bonjour @NineStars ,

Je suis entièrement d’accord avec le besoin. Pour validation de ton avis, et celui de @pierre-gilles avec 'aide de ClaudeAI :

Proposition : Nouveau widget « Historique d’événements »

Je recommande l’option 2 — un nouveau widget dédié — pour ces raisons :

  1. L’option 1 (clic dans « Appareils ») nécessiterait un système de popup/modal complexe qui n’existe pas dans Gladys, et ça mélange deux responsabilités
  2. Un widget dédié s’intègre naturellement dans le système existant et reste cohérent avec la philosophie Gladys (un widget = une fonction claire)

Nom proposé : event-history / « Historique d’événements »

Plus court que « Historique capteurs binaires » et potentiellement extensible à d’autres types plus tard.

Ce que le widget afficherait :

  • Liste verticale de changements d’état dans une box à hauteur fixe avec scroll
  • Chaque ligne : [pastille couleur] Nom du capteur — Nouvel état — HH:MM:SS
  • Regroupement par date (séparateurs « 24 mars 2026 », « 23 mars 2026 »…)
  • Uniquement les transitions (pas de répétition si la même valeur arrive plusieurs fois)
  • Dernières 24h affichées initialement, pagination automatique en scroll vers le bas
  • Couleurs configurables en édition (une couleur par état 0/1, par feature ou globale)
  • Temps réel via WebSocket (nouvelle transition = nouvelle ligne en haut)

Côté édition :

  • Sélection de features binaires uniquement (filtre sur type === 'binary' || type === 'push')
  • Choix des couleurs état 0 / état 1 (comme dans Chart)
  • Labels personnalisables pour 0/1 (ex: « Fermé »/« Ouvert ») — optionnel V2

Côté API :

  • Réutilisation possible de l’API aggregated_states existante pour les transitions binaires
  • Ajout d’un paramètre de pagination (offset/limit ou cursor-based) car l’endpoint actuel ne pagine pas

Propositions :


@Terdious , ta proposition fait un peu doublons avec la demande que j’avais posté. Non?

1 « J'aime »

Pour moi c’est deux choses différentes, toi tu proposes un onglet « Journal d’évènement » qui regroupe tous les appareils de la maison !

Ici, on parle juste d’un affichage différent des capteurs d’ouverture (porte/fenêtre) sur le tableau de bord !

Oui je suis d’accord mais sur la proposition de @Terdious il veut mettre un historique d’événements sur les différentes position. Cette partie historique d’événements fait pour moi doublon avec ma proposition de journal d’événements.

1 « J'aime »

Salut,

je pense qu’un historique peut être pratique, mais pas va bien plus loin que le besoin que j’avais formulé.

En y réfléchissant, je me dis que si l’on affiche sous / à côté / … la date du dernier changement d’état (donc que ma porte passe de ouverte à fermé, ou l’inverse) ça serait assez simple, et générique pour n’importe quel capteur binaire.
Ça pourrait être proposé dans l’édition du tableau de bord, quand on affiche un état binaire avec une case à cocher “afficher la date du dernier changement” par exemple si on veut rendre le truc paramétrable

C’est pas mal ! Surtout que c’est déjà quelque chose qu’on fait pour les capteurs de mouvements, et pour le widget « Utilisateurs présents » :