Ce développement n’est pas pensé pour des capteurs binaires, tout le fonctionnement interne est basé sur de l’échantillonnage, ce qui fait sens pour des valeurs de température, mais n’a aucun sens pour des binaires: comme tu disais, ça sert à rien d’avoir une valeur de 0.75 pour un capteur d’ouverture de porte.
Je pense que pour les capteurs binaires il faut qu’on se mette autour d’une feuille, faire l’étude du besoin, trouver une solution, et ensuite développement. C’est un beau chantier, et je pense pas qu’on arrivera à faire un truc satisfaisant avec ce qui a été fait là (qui est un tout autre chantier)
Du coup suite à ce qu’on s’est dit @lmilcent, j’ai désactivé à nouveau les graphiques pour les appareils suivants:
Binaires
Push
Camera
Couleur
Pour les binaires/Push, on fera un développement spécifique bien fait, je sais que c’est frustrant de pas avoir la fonctionnalité tout de suite, mais bon c’est plus dans la philosophie de la v4 de faire bien les choses plutôt que d’essayer de mettre du scotch à droite à gauche
@lmilcent Tu nous créé une demande de fonctionnalité ?
Il manque la modification du terme “Barre” => “Histogramme” (si toujours d’actualité)
La ligne rouge est en pointillée ce qui empêche de la sélectionner lorsqu’on se situe entre 2 pointillé (voir le curseur ci-dessous - qui est malheureusement gris clair sur l’imprim écran)
Prévisualisation dans l’édition seulement en cas de modification de la box (toujours si possible) - 20s pour afficher la vue Edition … c’est long
Je valide la remarque de @lmilcent, mais en détail :
Autre retour : J’affiche l’humidité + température de chaque pièce ici. La variation ne correspond à rien, ni la température (autour de 20°C) ni l’humidité (autour de 60%).
Quelques solutions pour moi :
Afficher deux indicateurs de variation, mais ça alourdit l’affichage
Spécifier quelle est la valeur principale qui sera utilisée (ou prendre le 1e, ici l’humidité)
Lorsque la variation est affichée sur plus de 24h, c’est une valeur calculée qui est affichée. Sur le moment j’ai trouvé ça bizarre que mon ordi + 2 écrans ne consomment que 0.03W.
Ce n’est pas un bug pour le coup, mais j’aurais aimé pouvoir afficher la consommation actuelle en grand, et la variation en rouge sur la période.
Par exemple : 80W actuel, -100% sur la période de 7 jours.
EDIT : En fait je suis tellement obnubilé par les graphiques que j’en oublie le reste des possibilités :
Pour la partie “Tâches”, finalement c’est toujours buggué sur le “NaN”. J’ai l’impression que c’est pendant une tâche que le bug arrive.
Lorsque ça sera terminé, les valeurs affichées seront surement les bonnes (pari).
En fait, quand tu sélectionne une courbe autre que dernière heure, je me base sur les données aggrégées qui ne sont pas « live »
Et du coup, il manque toujours le dernier bout de données qui n’a pas été aggrégée.
Si tu sélectionne les 7 derniers jours, en vérité c’est les 8 derniers jours jusqu’à hier (les données live du jour actuel ne sont pas affichées)
Sauf que je suis d’accord, c’est pas fou, donc je m’étais dis à la base « Ok mais c’est simple, je vais coller la donnée live à la donnée aggrégée », l’idée était de faire un mix aggrégation / live pour avoir tout.
Sauf que ça marche pas du tout, en fait ça donne un rendu bizarre, vu que les données live sont pas encore aggrégée, ça fait que tu te retrouve avec une courbe qui est aggrégée et « assez générale » sur 80% de la courbe, et le dernier 20% c’est de la donnée hyper précise, et ça fait dégeu
Mais je suis d’accord avec toi, dans l’idée il faudrait avoir tout jusqu’à maintenant.
Par contre c’est uniquement sur la vue avec les axes, la vue sans axe je sais pas pourquoi mais Apexchart déconne complètement quand on afficher la légende (la légende se retrouve mélangé au graph), j’ai testé des techniques sans succès
Pour ma part ça ne me gênera pas. La vue sans axe je ne l’utiliserai que pour des cas bien particulier et de toute façon si on veut avoir la valeur il faudra mettre le curseur (ou le doigt) sur la courbe, on aura donc la légende. C’est parfait pour moi de ce côté.
Super idée le bouton, j’adore
Je n’ai pas encore réussi à observer la chose ^^ je tombe toujours après coup ^^
En effet pour moi dans ce cas sur mélange de catégorie ça n’a pas de sens et l’utilisateur devrait lui même laisser la variation désactivée. Comme on le disait ça doit rester une vue simplifiée. Par contre je pense qu’il est très important de pouvoir laisser le choix de mixer des catégories différentes. Dans l’exemple de @lmilcent il est très intéressant de pouvoir afficher dans la même courbe la température et l’humidité d’une pièce mais la variation ne fais pas sens dans cette box et complexifierai d’autant l’édition de la vue. Toutefois dns une vue dédiée plus tard là …
Bon sinon @Terdious, j’ai bossé une bonne partie de la matinée sur l’optimisation de la performance de la route de GET des valeurs aggrégées, pour que l’affichage soit plus rapide chez toi !
Je suis parti de ce que tu m’as donné (les stats que tu m’as extraites), j’ai mis ça en forme dans un tableur et ordonné par temps d’exécution:
Comme on peut voir, ce qui est lent c’est les requêtes sur la DB.
En investiguant, déjà je me suis rendu compte qu’au début de la route je faisais une requête getDeviceFeatureBySelector qui pourrait juste être remplacée par un appel au cache en RAM.
J’ai retiré la requête, hop, déjà ça divise par deux le nombre de requête !
Ensuite, je me suis rendu compte que l’appel à la vue “Dernière 24h” ne passait pas par les données aggrégées, mais par les données live
En fait, il manquait ce cas dans les requêtes, et à défaut de faire un calcul à partir de la data aggrégée, on passait par les données live ( ce qui est beaucoup plus lent)
En passant par les données aggrégées, j’arrive à faire en sorte que au maximum, la requête renvoie 288 states, ce qui est super petit (je sais pas toutes les combien des données sont insérées? En 24h, tu as combien de state écrits?)
Je finalise tout ça, et je te tiens au courant quand une nouvelle image est prête pour tester !
Le truc qui me chiffonne c’est lié au “débat” Device name ou feature name.
On peut constater que si je veux une légende correcte ( qui m’aide quoi ! ) je dois renommer les features
Mon premier graph affiche les température des chambres
Bleu => mon fils
Rouge => ma fille
Jaune => ma chambre
Pour moi ça n’a pas de sens de renommer la feature par les prénom par exemple.
Donc est ce que la légende ne devrait pas utiliser le nom du device ?
En fait le problème c’est que chaque cas est unique, dans ton cas ça fait sens, mais dans le cas de @Terdious ça fait pas du tout sens. Du coup il y aura forcément un frustré (battez vous )
@VonOx c’est des périphériques venant de quelle intégration ?
(J’ai pas le bug chez moi)
:
