Moi je viens de regarder pour tester ton intégration, globalement sur le fonctionnement / ui pas de soucis. J’ai pas vraiment pu tester ton intégration car mon instance de prod n’a aucune donnée en BDD. En gros il existe uniquement les dernières données. J’ai rien touché de particulier à mon instance de prod …
Pour c’est un capteur xiaomi intégré via zigbee2mqtt
Je cherche pourquoi il stocke pas plus de données …
keep_history à un … J’ai l’impression qu’il y a un bug …
Ah pareil ! Je c herchais ou était cette valeur
2 personnes qui ont la même chose bizarre 
Oui je cherchais aussi sur l’UI et si d’autres ont ce soucis ça pourrait être intéressant de l’afficher
Bizarre tout ça, je vais enquêter 
Et oui clairement il faut afficher la valeur dans l’UI maintenant qu’on utiliser l’historique
Pour information, @VonOx m’a fait un premier retour sur Github, auquel je viens de répondre ici: Add the ability to vizualize device states on the dashboard by Pierre-Gilles · Pull Request #1248 · GladysAssistant/Gladys · GitHub
Plein de bon retours, autant des bugs que des améliorations pratiques pour que la fonctionnalité soit vraiment utile pour l’utilisateur final.
C’est d’ailleurs ce genre de retour qui m’intéresse plus, je veux que vous disiez si selon vous c’est une fonctionnalité utile et utilisable, ou si il manque des choses.
L’objectif c’est d’avoir un truc en même temps:
Du coup je vais améliorer ma copie et essayer de proposer une deuxième itération corrigée 
Petite preview de sur quoi je bosse depuis ce matin, un affichage clean des erreurs dans la vue “tâches en arrière-plan” !
J’ai toujours été contre l’affichage des logs pures dans l’UI (car on sait ce que ça donne, ensuite on est flemmard et on fait des intégrations où on demande aux gens d’aller chercher des IDs dans les logs 
), en revanche je suis pour une vue de ce style, où:
Voilà à quoi ressemble la vue pour l’instant:
Vous en pensez quoi ?
On est le matin 
C’est clair car l’erreur est contextualisee par rapport à la tâche.
Un accès au log complet pourrai être un plus ( ça évite à l’utilisateur de faire du ssh) mais c’est un autre sujet.
C’est l’erreur complète.
Dans le cas de l’agrégation des capteurs, comme Node.js est single thread, je voulais pas bloquer le thread Gladys principale, et donc l’agrégation est faite dans un worker séparé.
Le log qui est affichée là est le log d’erreur complète envoyée par le worker, donc il n’y a rien de plus à aller voir en SSH 
Dans tous les cas, normalement il ne devrait pas y avoir d’erreur. J’ai ajouté ça justement pour qu’on soit prêt le jour où on pousse une bêtise, ou le jour où quelqu’un avec une énorme DB se prend une limitation technique de sa machine (comme ça on le voit), mais normalement ce cas ne devrait pas arriver très fréquemment.
Je parlais plus du log général, là tu le cas des tâches background.
Mon idée c’était plutôt pour tout ce qui est services etc…
C’est pour ça que je disais que c’était un autre sujet.
La next step pour moi, et c’est une tâche en arrière plan, c’est d’ajouter l’exécution des scènes à cette vue.
L’objectif c’est de pouvoir voir ce qui s’est passé:
Après ça sera hors de cette PR.
Quelques retours :
, il est aussi très réactif, quelque soit l’intervalle choisi
Super boulot en tout cas, c’est une belle fonctionnalité
Oui je suis d’accord, c’est hyper chiant si c’est en premier en plus 
J’ai corrigé en mettant le titre à la fin (ça fait plus sens), et j’ai retiré l’auto-remplissage, c’est à l’utilisateur de choisir un nom.
Corrigé
Je vais corriger !
Non, sur un Macbook Pro 
donc performances à nuancer. Il y a une image docker dispo ?
Nope , mais ça m’a surpri 4 minutes
A mon avis c’est la partie disque SSD du Macbook Pro qui est rapide, car c’est quasiment que du disque au final (lecture/échantillonage mais c’est assez rapide/écriture). Donc si t’as un bon SSD sur ton Pi, ça devrait être bon niveau performance aussi à mon avis
Je vais build une image
J’ai la réponse à cette énigme, c’est tout simple: -1 est censé représenter la valeur « illimitée », c’est ce qui est défini dans le code du signup lorsque tu clique sur le radio button « illimitée ».
Le souci, c’est qu’il y avait un double bug dans le code et dans les tests qui font que cette valeur -1 n’a jamais fonctionnée…
Ce qu’il s’est passé:
Il n’y avait pas de if(-1) pour bloquer la purge des états, je pense j’ai du oublier en le codant. Comme on utilisait pas encore les valeurs de capteurs passée, ça s’est pas vu. Ce qui m’étonne c’est qu’il me semble que @Terdious a bien un historique illimité sur son instance. Tu confirme @Terdious ? Je pense tu dois avoir supprimé cette variable volontairement en DB non ?J’ai corrigé le bug et j’ai rajouté des tests plus solides pour s’assurer que ça bouge pas.
Dans l’UI, il y a maintenant la possibilité de modifier la valeur dans les paramètres:
