Tuto Multimédia Graph De Température, Humidité, Consommation...sur Nas

[sebcbien]

Oui un bouton delete est une bonne solution, ça arrive rarement effectivement

Sent from my SM-N910F using Tapatalk

[Invité chris6783]

Plutôt hide. On garderais le point dans la db. Pour compter éventuellement les aberrations. Un bouton commentaire sur un point peut être utile pour enrichir une courbe. Genre j'ai changé un truc àmon installation et comme ça on pourrait associer ce changement àson effet sur une courbe

Envoyé de mon SM-G850F en utilisant Tapatalk

[jojo]

oui mais, supprimer un point de la DB, c'est facile, car le graphe affiche tous les points qu'il trouve.

mettre un point en hide, est plus compliqué, il faudrait le supprimer de la table des graphes et le mettre dans une table séparée qui contiendrait toutes les incohérences. Mais sera-t-elle utilisée dans la réalité ???

Pour rajouter un commentaire àun point, cela implique

1. de rajouter un champ comment dans chacune des tables
2. de modifier le code php pour avoir un rigth click spécifique.

Voilàce que j'en dis. Je laisse maintenant la paroles aux spécialistes php et autre ...

[Lazer]

Plus simple : tu rajoutes aussi un champs 'hidden' pour les points, et quand tu fais la requêtes des graphs, tu filtres avec une requête du genre "... WHERE hidden=false", mais ça implique de faire de même pour generate_trends, c'est dire l’alimentation des tables d'historique (si on ne veut pas que les min/max par jour soient impactés)

J'avais volontairement supprimé ces valeurs aberrantes car :

- c'est plus simple (pas besoin de créer de champs supplémentaire, de modifier les requêtes, etc)

- pour moi, aucun intérêt de conserver une valeur aberrante (bug de la sonde, parasite de  communication 1-Wire, etc...)

- et surtout, la table des points est purgée au bout de 3 semaines, alors je ne vois pas l'intérêt de se prendre la tête pour une donnée qui va disparaitre bientôt.

 

Pour le commentaire sur un point, c'est une bonne idée, mais lourd à  gérer... car pareil, ça va être purgé au bout de 3 semaines, alors si on veut le conserver, il faut le recopier dans les tables historique..... perso je suis pas trop motivé.

[sebcbien]

Oui je pense aussi que c'est un peu "too much"

Sent from my SM-N910F using Tapatalk

[sebcbien]

Quand on change le nom d'un capteur, ou qu'on le change de pièce, la courbe précédente s’arrête et une nouvelle commence.

Une suggestion d'amélioration serait de permettre de renommer l'ancienne courbe avec le nom de la nouvelle pour assurer une continuité dans certains cas.

Peut être pas via une interface graphique, mais une méthode via phpmyadmin pour moi serait suffisant.(en ayant fait un bon backup avant ;-) )

[Lazer]

Normalement, quand on renomme un capteur ou qu'on le change de pièce, c'est bien la même courbe qui est conservée ! Non ?

Ce que tu décris ressemble àun changement d'ID du module (donc exclusion/inclusion, ou reconfiguration).

Ah moins que ça ne soit un bug....

[sebcbien]

c'est bien possible que l'ID aie changé, mais je ne pourrais pas le certifier àcoup sur... :-/

[Invité chris6783]

Le renommage est bien supporté chez moi. pour le changement id il faut faire un update dans les tables de mesures et principalement celles historisees . pour coller les 2 courbes. La jonction courante va disparaître dans 3 semaines donc pas bien grave ☺. Il faut remplacer toutes les références vers l'ancien id par le nouveau. Et supprimer la ligne qui correspond au vieil id dans la tables des modules pour le faire disparaître de la liste des courbes

Envoyé de mon SM-G850F en utilisant Tapatalk

[sebcbien]

Merci Chris,

Tu n'a pas la query SQL sous la main par hasard ? (àadapter au cas par cas, mais ce serait déjàun bon départ car je n'ai aucune idée de la structure de la DB)

Merci ;-)

[jojo]

si tu vas dans phpmmyadmin, tu verras tout. Mais comme la structure va changer avec la v4 de Lazer, j'attendrais la nouvelle structure

[Lazer]

La structure reste globalement la même; notamment tout ce qui touche aux ID.

 

Il me semble que j'avais déjà  donné les requêtes SQL pour changer l'ID d'un device, les revoici :

-- Remplacement d'ID
-- Ancien ID 49 => Nouvel ID 185
UPDATE domotique_temperature SET device_id=185 WHERE device_id=49
UPDATE domotique_temperature_day SET device_id=185 WHERE device_id=49
UPDATE domotique_device SET id=185 WHERE id=49
UPDATE domotique_device_type SET device_id=185 WHERE device_id=49

[jojo]

Lazer, 

bête remarque au passage, je vois que tous les id des device s'appelle device_id, sauf pour la table domotique_device.

Certe, c'est évident que l'id est le device_id, mais si le nom technique était le même partout, ne serait-ce pas plus "cohérent". On pourrait peut-être profiter du passagee à  la v4 pour harmoniser cela ?

[Invité chris6783]

Il vaut mieux garder les noms différents car id signe un clée qui identifie l'entité stockée dans sa table alors que device_id dit clairement qu'il s'agit d'une référence vers un device stocké ailleurs. En général on utilise id pour les clefs et pour les références entite_id et pour les références avec un rôle on ajoute le nom du rôle dans le nom de la référence. La lisibilité du sql et meilleure en respectant ce nommage

Envoyé de mon SM-G850F en utilisant Tapatalk

[Lazer]

Je n'aurais pas mieux répondu que chris6783

[Nico]

Top top tout ça, j'ai hate Lazer ! Moi je ferai de toute façon un erase pour refaire, car ma version bricolée V3/V4 a un peu souffert

[jojo]

merci chris6783 pour ce petit cours de sql

[Invité chris6783]

De rien mais je voulais pas faire l'âne savant :-). C juste qu'au cours des 15 dernières années j'en ai codé et relus un paquet donc pas trop de mérite :-) ! D'ailleurs je veux bien aider si vous rencontrez des pb de conception de db (ceci n'est pas un appel ànos amis polonais....) Mon quotidien c de concevoir des systèmes qui avalent et triturent des centaines de millions de lignes par jour.

[Sakkhho]

@Lazer, je voulais lancer cette requête car j'ai un FGMS qui avait fait des siennes donc j'ai du l'exclure 

mais phpmyadim me renvoie ca

UPDATE domotique_temperature SET device_id=263 WHERE device_id=12
UPDATE domotique_temperature_day SET device_id=263 WHERE device_id=12
UPDATE domotique_device SET id=263 WHERE id=12
UPDATE domotique_device_type SET device_id=263 WHERE device_id=12
MySQL a répondu: Documentation

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UPDATE domotique_temperature_day SET device_id=263 WHERE device_id=12
UPDATE do' at line 2 

as tu une idée ?

[Lazer]

Si tu as envoyé toutes les requêtes en même temps, il faut mettre un point-virgule àla fin de chaque ligne.

[Sakkhho]

merci lazer,

est ce que si l'ID existe deja ca coince ? l'idée était de lier les anciennes data du 12 vers le nouveau 263

#1062 - Duplicate entry '263' for key 'PRIMARY'

[Lazer]

cette erreur, je suppose que tu l'as pour les tables domotique_device et domotique_device_type ?

C'est normal si tu as attendu plus de 24h, car le bouton Device du VD a été appuyé àminuit, donc le nouvel ID du device a déjàété inséré dans les 2 tables en question.

[Sakkhho]

oui c'est ca et c'est deja dans la table depuis qq jours memes.

il y a moyen de corriger ?

[Lazer]

Y'a rien àcorriger, puisque le système a automatiquement ajouté le nouvel ID dans les bonnes tables.

Tout au plus peux tu nettoyer le vieil ID afin de ne pas laisser de lignes inutiles dans les tables :

DELETE FROM domotique_device WHERE id = 12
DELETE FROM domotique_device_type WHERE device_id = 12

[Sakkhho]

ok mais je perds un peu d'historique. ce que je pensais faire c'est dire toutes les valeurs de l'id 12 deviennent les valeurs de l'id263