Je suis disponible vendredi après-midi si tu veux, mais je sais pas si j’aurais plus de choses à te dire que là !
Je ne vois que 2 issues à ce problème :
Soit on veut afficher l’exhaustivité sur 24h, et donc ça mouline un peu sur les très rare capteurs à envoyer un états toutes les 30 secondes… Il y a sûrement des petites optis à faire néanmoins pour ce cas précis.
Soit on restreint à 1h mais c’est dommage pour tous les autres binaires moins verbeux
Je pense quand même que le cas des capteurs binaires qui envoient des valeurs toutes les 30 secondes est ultra rare sur une installation domestique classique…
Je serais curieux de savoir quels sont ces capteurs !
Salut @pierre-gilles , je serais ravi qu’on puisse de toute façon échangé sur les datas cette après-midi. Redis moi.
En effet, pour moi le 1er point s’impose mais on ne peut pas se permettre de consciemment faire mouliner des instances même si ce ne sera pas la majorité du temps (aujourd’hui par exemple pas de soucis, je n’ai qu’une 50aine d’état par feature). Du coup j’ai mis une logique en place, mais je préfère en parler avec toi directement.
Notamment pour une méthode de stockage des binaires (et autre si affinité) mais qu’on pourra voir dans un second temps.
Suite à des tests plus poussés, j’observe que :
récupérer 3000 états chacun sur 7 features non binaires (3 box chart) s’affiche pratiquement instantanément
Mais que récupérer 500 états chacun sur 3 features binaires (1 box) lag énormément.
Je suppose donc que la forte compression des valeurs binaires impact les performances à la décompression ?
Je souhaiterais donc implémenter (pour test) une complétion, au delà de 300 valeurs, de la courbe avec une zone « tampon » spécifiant les données manquantes permettant d’appliquer un zoom pour visualiser cette ligne de temps et n’empechant pas les autres features de la box et qui contiendrait moins de données d’être visualisées :
Mais cela implique que je travaille sur la partie zoom.
Je peux push avant le call si tu veux.
PS HS : Avec tout ces tests, ça me fait également penser que c’est dommage d’avoir cette vue lorsqu’on a pas eu de nouvel état, alors qu’en fait on est bien dans un état tant qu’on est pas sûr que ce n’est pas un soucis de connexion :
Je pense qu’ici, on devrait afficher la dernière valeur reçue avec pourquoi pas un message d’incertitude si il le faut (last_value_changed < intervalle = message)
PS HS2 : Sur l’image ci-dessus, il faut qu’on change le warning du message qui n’a plus lieu d’être puisqu’il n’y a plus d’aggrégation.
