Les valeurs envoyées par pyHeatpump au serveur ne sont pas correctes, comparées aux valeurs envoyées par RPiPasserelle.
J’ai uploadé les logs sur le repo git (dossier logs/bug).
Je vais analyser les valeurs et les adresses avec diff pour mieux comprendre d’où vient l’erreur.
Les valeurs envoyées par pyHeatpump au serveur ne sont pas correctes, comparées aux valeurs envoyées par RPiPasserelle.
J'ai uploadé les logs sur le repo git (dossier logs/bug).
Je vais analyser les valeurs et les adresses avec diff pour mieux comprendre d'où vient l'erreur.
Les adresses doivent être décalées pour commencer à “1” pour correspondre à l’automate, par contre, pas de raison pour que le module javascript l’interprète comme ça (à par pour coller vraiment au fonctionnement de leur “écran de contrôle”).
Enfin, c’est quelque chose qui doit pouvoir être configurable dans pyHeatpump.
Tel que précisé dans le document
doc/Protocollo_Modbus_controlli_pCO.pdf
Les adresses doivent être décalées pour commencer à "1" pour correspondre à l'automate, par contre, pas de raison pour que le module javascript l'interprète comme ça (à par pour coller vraiment au fonctionnement de leur "écran de contrôle").
Enfin, c'est quelque chose qui doit pouvoir être configurable dans pyHeatpump.
*Appel avec christophe (retour test image 2020/12/06)*
Après les retours des tests utilisateurs, on à toujours des problèmes de valeurs erronées, mais sur les valeurs négatives.
Il faut donc ajouter la possibilité de valeurs négatives dans la récupération (fetch).
@nas : si tu veux jeter un coup d'oeuil, et comparer les données entre écran RPi/Supervision (même en configuration de test)
@maxime-alves : Je m'occupe de regarder le code.
Les valeurs négatives sont offsettées par le bit de complément à un. Le code java gérait cette spécificité, il faudrait analyser la manière de faire. De toute manière, si le premier bit est signifiant, les valeurs peuvent aller de :
Les valeurs négatives sont offsettées par le bit de complément à un. Le code java gérait cette spécificité, il faudrait analyser la manière de faire. De toute manière, si le premier bit est signifiant, les valeurs peuvent aller de :
1111111111111111 à 0111111111111111 (-32767 à 32767)
Principe :
https://en.wikipedia.org/wiki/Ones%27_complement
Explication de la solution et documentation des opérateurs utilisés
https://wiki.python.org/moin/BitwiseOperators
la résolution du problème des nombres négatifs à été merge sur master mais pas testé en prod.
j’ai écris cependant les tests unitaires censés valider les conversion
la résolution du problème des nombres négatifs à été merge sur master mais pas testé en prod.
j'ai écris cependant les tests unitaires censés valider les conversion
Encore un problème, lorsque les adresses ne commencent pas à 1, elles sont toutes shiftées (shift_response).
10, 11, 12, 13
deviens donc
1, 2, 3, 4
Un effet de bord de la fonction shift_response à gérer.
Encore un problème, lorsque les adresses ne commencent pas à 1, elles sont toutes shiftées (shift_response).
10, 11, 12, 13
deviens donc
1, 2, 3, 4
Un effet de bord de la fonction shift_response à gérer.
J’ai par contre détecté un bug au niveau de la récupération des valeurs , il semble qu’il prend toujours la plus vieille valeur.
Après test, je me rend compte que c’est l’ordre d’insertion des variables (même si on le fait en raw SQL via db/test_variable_values.sql) qui va déterminer laquelle est la plus récente. Ce n’est pas problématique car en production on insert à chaque fois de nouvelles variables courantes. Par contre, en test et dans les cas de récupération de données perdues cela pourrait l’être.
J'ai déplacé le shift dans la classe VariableType. Vu que chacun connaît son offset ça devrait être bon.
55c943c149
J'ai par contre détecté un bug au niveau de la récupération des valeurs , il semble qu'il prend toujours la plus vieille valeur.
Après test, je me rend compte que c'est l'ordre d'insertion des variables (même si on le fait en raw SQL via db/test_variable_values.sql) qui va déterminer laquelle est la plus récente. Ce n'est pas problématique car en production on insert à chaque fois de nouvelles variables courantes. Par contre, en test et dans les cas de récupération de données perdues cela pourrait l'être.
## Fonctionnel
La nouvelle image avec le dernier commit 26bdba4
https://www.freepoteries.fr/~msleaveamix/2020-12-16_rpios-buster_pyheatpump-26bdba4.img.xz
maxime-alves
Les valeurs envoyées par pyHeatpump au serveur ne sont pas correctes, comparées aux valeurs envoyées par RPiPasserelle.
J’ai uploadé les logs sur le repo git (dossier logs/bug).
Je vais analyser les valeurs et les adresses avec diff pour mieux comprendre d’où vient l’erreur.
Les indices des valeurs reçues avec pyHeatpump et RPiPasserelle sont décalées.
EDIT : Suppression des logs
Range des variables envoyées en prod :
Digital : [ 1, 1000 ]
Analog : [ 1, 1250 ]
Integer : [ 1, 1250 ]
Tel que précisé dans le document
doc/Protocollo_Modbus_controlli_pCO.pdf
Les adresses doivent être décalées pour commencer à “1” pour correspondre à l’automate, par contre, pas de raison pour que le module javascript l’interprète comme ça (à par pour coller vraiment au fonctionnement de leur “écran de contrôle”).
Enfin, c’est quelque chose qui doit pouvoir être configurable dans pyHeatpump.
Fix (tests dans le commit suivant)
af948be5e9
Appel avec christophe (retour test image 2020/12/06)
Après les retours des tests utilisateurs, on à toujours des problèmes de valeurs erronées, mais sur les valeurs négatives.
Il faut donc ajouter la possibilité de valeurs négatives dans la récupération (fetch).
@nas : si tu veux jeter un coup d’oeuil, et comparer les données entre écran RPi/Supervision (même en configuration de test)
@maxime-alves : Je m’occupe de regarder le code.
Les valeurs négatives sont offsettées par le bit de complément à un. Le code java gérait cette spécificité, il faudrait analyser la manière de faire. De toute manière, si le premier bit est signifiant, les valeurs peuvent aller de :
1111111111 à 0111111111 (-32767 à 32767)
Principe : https://en.wikipedia.org/wiki/Ones%27_complement
Explication de la solution et documentation des opérateurs utilisés https://wiki.python.org/moin/BitwiseOperators
la résolution du problème des nombres négatifs à été merge sur master mais pas testé en prod.
j’ai écris cependant les tests unitaires censés valider les conversion
Encore un problème, lorsque les adresses ne commencent pas à 1, elles sont toutes shiftées (shift_response).
10, 11, 12, 13
deviens donc
1, 2, 3, 4
Un effet de bord de la fonction shift_response à gérer.
J’ai déplacé le shift dans la classe VariableType. Vu que chacun connaît son offset ça devrait être bon.
55c943c149
J’ai par contre détecté un bug au niveau de la récupération des valeurs , il semble qu’il prend toujours la plus vieille valeur.
Après test, je me rend compte que c’est l’ordre d’insertion des variables (même si on le fait en raw SQL via db/test_variable_values.sql) qui va déterminer laquelle est la plus récente. Ce n’est pas problématique car en production on insert à chaque fois de nouvelles variables courantes. Par contre, en test et dans les cas de récupération de données perdues cela pourrait l’être.
J’ai fix un mauvais signe dans le get des variables à partir d’une date.
88d947ea9dJe recréé une image avec le dernier commit.
https://www.freepoteries.fr/~msleaveamix/2020-12-16_rpios-buster_pyheatpump-26bdba4.img.xz
(mail envoyé)
c64710b
J’ai annulé le commité du mauvais signe, mea culpa je n’avais pas vu la valeur par défaut de since.
Fonctionnel
La nouvelle image avec le dernier commit 26bdba4
https://www.freepoteries.fr/~msleaveamix/2020-12-16_rpios-buster_pyheatpump-26bdba4.img.xz
Confirmation par Christophe ce vendredi 18 décembre par téléphone : les valeurs envoyées sont ok.
De la même manière, les ordres négatifs n’étaient pas pris en compte.
#35