[Contournement] Neo Coolcam Z-Wave - kWh parfois farfelus

[Chrominator]

EDIT : Si votre version de domoticz est postérieure au 7 janvier 2021, allez directement là.

J'ai plusieurs prises comme celle-là qui montrent une consommation du jour complètement farfelue, mais pas chaque jour ;

Le lave-vaisselle a terminé son programme.
J'ai reçu une notification grâce à un script :

Code : Tout sélectionner

2020-07-21 11:53:01.893  Status: dzVents: Info: monitor_machine.lua: Lave-Vaisselle. 
Puissance utilisée aujourd'hui : 2.048 kW, soit un coût de 2.67€.

Ce soir, je regarde le device qui donne cette consommation (1547), et c'est farfelu :

Screenshot_2020-07-21 Domoticz.png (54.54 Kio) Consulté 11509 fois

Ça ne me gênerait pas outre mesure si ce n'était que ça, mais en fait, parfois, mon script choppe cette valeur erronée en tant que consommation du jour, et là évidemment c'est plus la même marmelade !

Code : Tout sélectionner

2020-07-21 12:52:02.166  Status: dzVents: Info: monitor_machine.lua: Lave-Linge. 
Puissance utilisée aujourd'hui : 21474836.9 kW, soit un coût de 27960237.64€.

Pourtant le soir même, le device (1530) semble propre et bien refléter les deux cycles effectués par le lave-linge :

Screenshot_2020-07-21 Domoticz(1).png (53.42 Kio) Consulté 11509 fois

Je ne vois pas dans quelle direction chercher, j'ignore si c'est DZ qui calcule mal ou si mes capteurs sont en cause.
On voit les mêmes valeurs/anomalies dans DZ et dans le panneau de contrôle Open Z-Wave, c'est plutôt normal.

Une idée ou un autre soft capable d'interroger ces capteurs en dehors de DZ ?


EDIT : Merci à ogulf pour sa procédure détaillée permettant de corriger la base de données.
Pour éviter de devoir recorriger plus tard, le contournement est là.

Et un outil de correction en SQL ici.

[ogulf]

Que ce soit avec mes prises NeoCoolCam (les mêmes) ou mes Hank, j'ai le même problème.
Je pense que ça vient du réseau EDF, genre microcoupure ou autre (Mmais certainement pas 1 000 kW délivrés !!!).

La seule solution que j'ai trouvée, c'est analyse de la BDD sur le device, et reconstitution de la consommation (impacte 3 tables).

Je suis tenté par une correction automatique, car l'analyse est toujours là même, mais il suffirait d'une fois qu'il y ait un petit delta et je foire mon historique.
Vu que ça arrive entre 0 et 1 fois par mois, grosso modo, je gère à la main.

La prochaine fois, j'illustre mon mode opératoire de correction si ça peut te servir.

[Chrominator]

Merci pour ton retour, c'est une piste en effet.

Ce qui me surprend, c'est que dans mon cas la correction a été automatique ;
Dans l'exemple du lave-linge la consommation est farfelue à 12:52 au moment où mon script lance la notification mais ensuite elle semble cohérente à 19:47, sans intervention de ma part.

Cette même consommation "juste" est encore présente ce matin.
Accessoirement on ne voit pas ce pic énorme dans l'historique :

Screenshot_2020-07-22 Domoticz.png (22.86 Kio) Consulté 10806 fois

[ogulf]

Voici qui servira d'exemple dans la procédure de correction.
Les 3 images ne concernent qu'une seule et même prise NeoCoolCam.

Historique classique (1 semaine, 1 mois, 12 mois) :
- 1 pic le 25/06
- 1 pic le 16/07


Rapport juin 2020 :
On s'aperçoit qu'en fait le pic du 25/06 masque (dans le graphique précédent) un second pique le 27/06.
Par contre, on s'aperçoit aussi que la 1ère colonne (le total du compteur depuis sa mise ne marche) est cohérent, et donc on va pouvoir corriger de manière exacte


Rapport juillet 2020 :
1 seul pic le 16/07, mais tout semble faux... On va quand même pouvoir corriger de manière exacte


Sans rentrer dans le détail de la correction maintenant, les actions vont être possibles car il n'y a pas eu 2 jours consécutifs avec une anomalie.

J'espère pouvoir détailler avant de partir en congés.... sinon il faudra patienter.
Mais comme tu peux le voir, j'ai une anomalie qui a déjà presque 1 mois... donc ce n'est pas gênant (sauf dans les rapports mais ce n'est qu'un affichage issu des données en bases).

[ogulf]

Accessoirement on ne voit pas ce pic énorme dans l'historique :

Même dans les Rapports ?...
Je pense que ce n'est pas bon, mais il faut attendre au moins le lendemain, voire le surlendemain pour que le rapport soit impacté.

[Chrominator]

En effet, le pic apparaît sur la courbe du mois.

Bon vivement que je corrige ça, là c'est trop cher !

[ogulf]

Voilà la démarche que j'applique pour corriger ces pb de "pic" de consommation.

Je vais intervenir en base, donc avant toute chose pensez à bien faire une sauvegarde de cette dernière.

Prérequis :
- identifier un pic anormal de consommation sur un device de type compteur
- disposer d'un client SSH pour se connecter au Pi
- avoir installé sqlite3 sur le Pi (version 3.27.2 sur le mien)
- ne pas être réfractaire à quelques notions élémentaires de mathématique

Toutes les opérations décrites peuvent se faire sans arrêter domoticz.
Se placer dans le répertoire contenant la base domoticz.db (en général /home/pi/domoticz)
Pour toute la suite, le device qui me pose problème est le n°120, et les captures d'écran de mon post précédent concernent bien ce device.

On lance sqlite3 en tant que root

Code : Tout sélectionner

pi@raspberrypi:/home/pi/domoticz $ sudo sqlite3 domoticz.db
SQLite version 3.27.2 2019-02-25 16:06:06
Enter ".help" for usage hints.
sqlite>

et on quitte avec la commande .quit

Code : Tout sélectionner

sqlite> .quit
pi@raspberrypi:/home/pi/domoticz $

Rappel du contexte :



CORRECTION MOIS DE JUIN (1er cas de figure : 1 seule donnée fausse dans l'IHM)

Sélection de qques jours avant/après la date de l'anomalie dans la table historique (maille = jour).

Code : Tout sélectionner

sqlite> select * from meter_calendar where devicerowid=120 and date between '2020-06-21' and '2020-06-30';
120|330|695560|2020-06-21
120|660|696220|2020-06-22
120|220|696440|2020-06-23
120|270|696710|2020-06-24
120|16106126970|16106823680|2020-06-25
120|680|697840|2020-06-26
120|41943100|42640940|2020-06-27
120|270|698620|2020-06-28
120|260|698880|2020-06-29
120|450|699330|2020-06-30
sqlite>

Rappel : les 25 et 27 juin sont concernés par la correction

Là, déjà, on peut constater qu'il y a un écart entre ce qui est affiché dans Domoticz et ce qui est stocké en base.
Regardons le 25/06 en base : que des chiffres anormaux
Alors que la même date via l'IHM de Domoticz montre un compteur normal, mais une utilisation anormale...
A y regarder de plus près, on constate même que les données stockées ne sont pas affichées à l’identique et qu'il y a un décalage de 1 jour sur la consommation quotidienne.

Avec une image c'est plus simple !!



Le compteur total affiche 696,220 KWh le 23/06, 696,440 KWh le 24/06 et 696,710 KWh le 25/06 alors que « ces mêmes valeurs » sont stockées en base respectivement les 22, 23 et 24 juin.

En d’autres termes, via l’IHM on en déduit la formule F1 :
Compteur du 23/06 (696,220) + Consommé du 23/06 (0,220) = Compteur du 24/06 (696,440)
(F1) Compteur J + Consommé J = Compteur J+1

Alors qu’en base, on a la formule F2 :
Compteur du 22/06 (696 220) + Consommé du 23/06 (220) = Compteur du 23/06 (696 440)
(F2) Compteur J + Consommé J+1 = Compteur J+1
Notez au passage le facteur multiplicatif 1000... affiché en KWh, stocké en Wh…

Une fois qu’on a compris cette mécanique, tout est plus simple !
Et vous comprenez maintenant pourquoi je peux corriger car il n’y a pas 2 jours consécutifs faux ! Je suis sûr de m’y retrouver soit avec l’IHM, soit avec la base, soit avec les deux !

A l’affichage, j’ai manifestement un problème le 25/06 (et un autre le 27/06): je vais donc regarder ce qui se passe entre le 24/06, le 25/06 et le 26/06 pour rétablir la situation avec l’aide de la base et de l’IHM.

A noter : il faut TOUJOURS commencer par corriger l’anomalie la plus ancienne, puis la suivante et ainsi de suite.

Partant de la formule F1 (les données sont donc celles de l’IHM), j’ai :
Compteur 26/06 – Compteur 25/06 = Consommé du 25/06
Dans mon cas : 697,160 – 696,710 = 0,450 le 25/06
Ma consommation le 25/06 est donc 0,450
Oui je sais, ce n'est pas exactement la formule ci-dessus… mais c'est pour voir si vous êtes réfractaires aux notions élémentaires de mathématiques (cf prérequis !!)

Parfait, ça va corriger le 1er chiffre fantaisiste du 25/06 :
120|270|696710|2020-06-24
120|16106126970|16106823680|2020-06-25
120|680|697840|2020-06-26

Maintenant, grâce à la formule F2 (les données sont donc celles de la base), j’obtiens :
Compteur du 26/06 – Consommé du 26/06 = Compteur du 25/06
Dans mon cas, je devrais donc avoir : 697 840 – 680 = 697 160
Voilà qui corrige le 2nd chiffre fantaisiste du 25/06 :
120|270|696710|2020-06-24
120|16106126970|16106823680|2020-06-25
120|680|697840|2020-06-26

Je n’ai donc plus qu’à corriger cette ligne par la commande sql :

Code : Tout sélectionner

sqlite> update meter_calendar set value=450, counter=697160 where devicerowid=120 and value=16106126970 and counter=16106823680 and date='2020-06-25';
sqlite>

Vous verrez au passage que la clause where est la plus complète possible : je suis certain de cibler le bon enregistrement, et surtout pas un autre (l'IDX bien entendu, la date, l'ancien 'value' et l'ancien 'counter')
Attention, si vous oubliez la clause where…. ce sont toutes les données de tous vos compteurs que vous allez modifier … Et là merci la sauvegarde !

Petite requête de contrôle :

Code : Tout sélectionner

sqlite> select * from meter_calendar where devicerowid=120 and date between '2020-06-21' and '2020-06-30';
120|330|695560|2020-06-21
120|660|696220|2020-06-22
120|220|696440|2020-06-23
120|270|696710|2020-06-24
120|450|697160|2020-06-25
120|680|697840|2020-06-26
120|41943100|42640940|2020-06-27
120|270|698620|2020-06-28
120|260|698880|2020-06-29
120|450|699330|2020-06-30

La ligne du 25/06 est bien correcte.
Je peux aussi vérifier dans l’IHM que tout est correct



Maintenant, je visualise bien dans le graphique l’autre pic, mais je l’avais identifié à la lecture des données du rapport…

Plus qu’à adapter les chiffres et les dates, mais c’est la même méthode !
Ce qui me donne au final :

Code : Tout sélectionner

sqlite> update meter_calendar set value=510, counter=698350 where devicerowid=120 and value=41943100 and counter=42640940 and date='2020-06-27';
sqlite> select * from meter_calendar where devicerowid=120 and date between '2020-06-20' and '2020-06-30';
120|810|695230|2020-06-20
120|330|695560|2020-06-21
120|660|696220|2020-06-22
120|220|696440|2020-06-23
120|270|696710|2020-06-24
120|450|697160|2020-06-25
120|680|697840|2020-06-26
120|510|698350|2020-06-27
120|270|698620|2020-06-28
120|260|698880|2020-06-29
120|450|699330|2020-06-30
sqlite>

Et un joli graphique pour juin :




CORRECTION MOIS DE JUILLET (2nd cas de figure : 2 données fausses dans l'IHM)
Là… mauvaise surprise ce matin…. J’ai eu un pic hier….



Et du coup ce n’est plus du tout la même chose pour corriger cette dernière anomalie…. Car en base, à cause du décalage, le compteur ne m’a pas encore donné une journée correcte « autour » de l’anomalie….

Code : Tout sélectionner

sqlite> select * from meter_calendar where devicerowid=120 and date > '2020-07-12';
120|160|704000|2020-07-13
120|360|704360|2020-07-14
120|590|704950|2020-07-15
120|21559050920|84918952|2020-07-16
120|200|705480|2020-07-17
120|210|705690|2020-07-18
120|180|705870|2020-07-19
120|170|706040|2020-07-20
120|270|706310|2020-07-21
120|720|707030|2020-07-22
120|460|707490|2020-07-23
120|70052510|70760000|2020-07-24
sqlite>

Je n’ai pas encore la journée du 25/07 en base…. Puisqu’elle ne sera insérée que à minuit.
L’IHM me montre pourtant un début de journée du 25/07, mais c’est normal puisque Domoticz connait la consommation à un instant T….
Je pourrais vous montrer comment faire, mais c’est beaucoup plus complexe, et ça impacte 3 tables :
- meter_calendar qu’on vient de voir
- meter qui est l’historique des derniers jours, par tranche de 5 minutes (3 jours d’historique chez moi, mais c’est paramétrable dans Domoticz)
- devicestatus qui est LA table de tous les devices quel que soit leur type : on y trouve notamment la consommation instantanée et le cumul à l’instant T depuis la veille pour mon device 120

Il faudrait :
- Ne garder dans la table meter QUE les données depuis ce matin 25/07/20
- Recaler la table meter_calendar entre ce qu’on voit de l'IHM et ce qu’il y a la veille
- Recalculer correctement le cumul à l’instant T (cad celui de la veille + la consommation déjà actée depuis ce jour
- Et tout ça…. En moins de 5 minutes, je dirais même sans qu’il se passe une màj Domoticz (qui a lieu toutes les 5 minutes…… donc à faire entre 11h50’01" et 11h54’59" sinon faut recommencer….)

Le plus simple, et le plus sage, est d’attendre demain pour reprendre cette coquille du 24/07….
Les fameux deux jours clean qui encadrent une journée KO….

Je vais donc me contenter de corriger l’anomalie du 16/07, qui est un peu différente du mois de juin : j’ai en effet les deux données de l’IHM qui sont fausses….

Du coup je modifie un peu l’analyse… et voilà qui explique cette seconde approche (très légèrement différente).

Je commence par appliquer F2 pour le Compteur du 16/07 :
Compteur du 17/07 – Consommé du 17/07 = Compteur du 16/07 ==> 705 480 – 200 = 705 280

Et je dois maintenant m’appuyer sur ce résultat pour définir ma consommation du 16/07, toujours par la formule F2 :
Compteur 16/07 – Compteur 15/07 = Consommé du 16/07 ==> 705 280 – 704 950 = 330

Et j’ai donc la requête sql suivante :

Code : Tout sélectionner

sqlite> update meter_calendar set value=330, counter=705280 where devicerowid=120 and value=21559050920 and counter=84918952 and date='2020-07-16';
sqlite> select * from meter_calendar where devicerowid=120 and date > '2020-07-12';
120|160|704000|2020-07-13
120|360|704360|2020-07-14
120|590|704950|2020-07-15
120|330|705280|2020-07-16
120|200|705480|2020-07-17
120|210|705690|2020-07-18
120|180|705870|2020-07-19
120|170|706040|2020-07-20
120|270|706310|2020-07-21
120|720|707030|2020-07-22
120|460|707490|2020-07-23
120|70052510|70760000|2020-07-24
sqlite>

Désormais, j'ai repris tout ce que je pouvais reprendre, je corrigerai l'anomalie d'hier une autre fois…




Remarque :
Pour ceux qui m'ont lu jusqu'ici…. et qui ont bien suivi !!!.... ceux-là pourraient me dire que la 2nde méthode s'applique tout le temps…
Car en effet, si l'affichage IHM diffère dans les deux cas présentés, les données en base présentent la même "structure" : juste une journée fausse sur les 2 valeurs.
Oui… vous avez raison…. Mais dans le second cas je dois m'appuyer sur un résultat intermédiaire que j'ai moi-même calculé…. Je préfère m'appuyer sur des données non modifiées pour déterminer Consommé (value) et Compteur (counter).

Pour aller plus loin :
J'ai parlé d'automatisme…. c'est faisable si on n'applique QUE la 2nde méthode (je vois mal un automatisme aller lire un graphique… visuellement je veux dire !!)
L'automatisme pourrait tourner tous les 15 jours, et surveillerait les 30 jours qui le précèdent.
- Facile d'identifier une anomalie.
- Un peu plus difficile (mais faisable) de s'assurer qu'il n'y en a pas deux consécutives
- Et application de la seconde méthode avec MàJ automatique.

L'intérêt de surveiller 30 jours alors qu'on tourne tous les 15 jours, c'est justement s'il y a une anomalie "la veille" dans l'analyse. C'est mon cas aujourd'hui : si ça devait tourner le 25/07, alors l'analyse se ferait jusqu'au 24/07 inclut…. qui est en anomalie : difficile de corriger alors !
Du coup, le traitement ne ferait rien, mais la correction sera rattrapée par le déclenchement suivant (15 jours plus tard) qui prendra une période de 30 jours (j'aurais donc les données du 24/07 que je sais fausse, mais surtout j'aurais les données du 25/07 en base pour décider !)



Si ça peut servir…

[Keros]

Merci pour ces explications super détaillées

[Chrominator]

Oui merci beaucoup, c'est super détaillé et y a plus qu'à.

Maintenant corriger l'effet c'est bien mais j'aimerais bien quand même remonter à la source et savoir ce qui produit ces écarts gigantesques, si c'est CZ qui fait une erreur ou le firmware de ces prises qui est en cause.

J'ai écrit un dzVents pour surveiller les changements de valeurs, et j'espère ainsi tracker l'évènement qui cause ce trouble.

[Chrominator]

Bon, dans le forum batave ils disent que c'est le firmware et/ou le fichier de config z-wave qui pose le problème.
Il y a un forumeur qui a contourné le problème avec un script dzVents pour corriger ces valeurs à la noix dans DZ.
Ca fonctionne, il faut juste "amorcer la pompe" au début. (=mettre la valeur de la consommation totale en historique), les valeurs enregistrées dans la table meter sont enfin correctes.

Le script est là.