Closed zekje closed 1 year ago
Salut, Ce sont des informations de "pointe" :
6.2.3.15. Début pointe mobile et fin de pointe mobile Le compteur transmet les informations relatives à l’engagement des pointes mobiles qu’il connaît. Le contrat peut définir 3 profils de jours de pointe mobile différents (PM1, PM2 et PM3). Si plusieurs commandes identiques coexistent pour la même pointe mobile, l’information diffusée correspond à la première action chronologique.
Je ne pense que ce soit pas des données intéressantes à exploiter. Pour la perte du INST je ne sais pas, il faudrait faire une automatisation pour avoir un horodatage lorsqu'il y a le pb, et ensuite aller fouiner dans les logs ;)
peut t on ne pas remonter les infos non interessantes , ex PPOINTE DPM1 FPM1 , ca ferais moins de données a traiter ?
Le lun. 13 févr. 2023 à 17:11, spamoi33 @.***> a écrit :
Salut, Ce sont des informations de "pointe" :
6.2.3.15. Début pointe mobile et fin de pointe mobile Le compteur transmet les informations relatives à l’engagement des pointes mobiles qu’il connaît. Le contrat peut définir 3 profils de jours de pointe mobile différents (PM1, PM2 et PM3). Si plusieurs commandes identiques coexistent pour la même pointe mobile, l’information diffusée correspond à la première action chronologique.
Enedis-NOI-CPT_54E.pdf https://github.com/fmartinou/teleinfo2mqtt/files/10723985/Enedis-NOI-CPT_54E.pdf
Je pense que ce ne sont pas des données intéressante à exploiter. Pour la perte du INST je ne sais pas, il faudrait faire une automatisation pour avoir un horodatage lorsqu'il y a le pb, et ensuite aller fouiner dans les logs ;)
— Reply to this email directly, view it on GitHub https://github.com/fmartinou/teleinfo2mqtt/issues/47#issuecomment-1428216448, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHBIBLXVD2VSC6XWUAX3WDLWXJMM5ANCNFSM6AAAAAAU2DVEBA . You are receiving this because you authored the thread.Message ID: @.***>
peut t on ne pas remonter les infos non interessantes , ex PPOINTE DPM1 FPM1 , ca ferais moins de données a traiter ?
A ce jour, il n'est pas possible d'ignorer une liste d'étiquettes.
Je ne pense pas que ça soit utile à implémenter puisque ce qui fait vraiment la différence, c'est de jouer sur le EMIT_INTERVAL
.
en regardant dans les logs, je vois ça toutes les secondes ( pourquoi si j ai un refresh a 15s ? )
Le refresh influe sur le fait d'envoyer ou non la trame via mqtt mais n'influe pas sur la lecture des trames sur le port série, qui elle est faite en continu (1 trame par seconde).
11:59:56.304 WARN teleinfo2mqtt: Error on parsing the value [00] and the timestamp [ 230214060000] for label [FPM1]: [Invalid timestamp ( 230214060000] 11:59:56.672 WARN teleinfo2mqtt: Invalid value received for label PPOINTE [00004003 06004004 22004003 NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE] 11:59:57.376 WARN teleinfo2mqtt: Error on parsing the value [00] and the timestamp [ 230213060000] for label [DPM1]: [Invalid timestamp ( 230213060000]
Il y a peut-être une erreur de code sur la gestion du FPM1 => je vais regarder.
J'ai trouvé d'où vient l'erreur de parsing pour FPM1
.
Le format d'horodatage reconnu par teleinfo2mqtt
doit commencer par un H (heure hiver) ou un E (heure été), ce qui n'est pas le cas pour FPM1
parce que... il y avait une petite ligne à lire dans la spec ENEDIS (que je n'avais pas lue évidemment ^^)
Dans certains cas, le caractère saison n'est pas applicable, et est remplacé par le caractère « Espace » (caractère ASCII 0x20). Il s'agit des groupes d'information de début et de fin de pointe mobile.
Je vais corriger.
J'ai fait un fix qui peut être testé avec la version fmartinou/teleinfo2mqtt:fix__47_ppointe
.
@zekje ; peux-tu tester ? (mon compteur n'est pas en mode STANDARD)
Si ok , alors je ferai une release.
Bonjour, J utilise un module rail din USB sur ma téléinfo ( linky mode standard et contrat tempo )
depuis quelques jours je m aperçoit que le INST n'est pas mis à jour pendant un long temps ( plus d une heure quand je m en aperçoit ) , alors que j'ai mis un rafraichissement à 15s ....
en regardant dans les logs, je vois ça toutes les secondes ( pourquoi si j ai un refresh a 15s ? )
11:59:56.304 WARN teleinfo2mqtt: Error on parsing the value [00] and the timestamp [ 230214060000] for label [FPM1]: [Invalid timestamp ( 230214060000] 11:59:56.672 WARN teleinfo2mqtt: Invalid value received for label PPOINTE [00004003 06004004 22004003 NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE] 11:59:57.376 WARN teleinfo2mqtt: Error on parsing the value [00] and the timestamp [ 230213060000] for label [DPM1]: [Invalid timestamp ( 230213060000]
en debug pour avoir plus d infos :
`11:50:12.591 DEBUG teleinfo2mqtt: Raw frame [PPOINTE 00004003 06004004 22004003 NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE ! ] 11:50:12.592 DEBUG teleinfo2mqtt: Split frame [PPOINTE,00004003 06004004 22004003 NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE,! ] 11:50:12.592 WARN teleinfo2mqtt: Invalid value received for label PPOINTE [00004003 06004004 22004003 NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE NONUTILE]
11:56:46.322 DEBUG teleinfo2mqtt: Raw frame [DPM1 230213060000 00 ^ ] 11:56:46.322 DEBUG teleinfo2mqtt: Split frame [DPM1, 230213060000,00,^ ] 11:56:46.322 DEBUG teleinfo2mqtt: Value for label DPM1 = 00 11:56:46.322 WARN teleinfo2mqtt: Error on parsing the value [00] and the timestamp [ 230213060000] for label [DPM1]: [Invalid timestamp ( 230213060000] 11:56:46.337 DEBUG teleinfo2mqtt: Raw frame [FPM1 230214060000 00 ! ] 11:56:46.338 DEBUG teleinfo2mqtt: Split frame [FPM1, 230214060000,00,! ] 11:56:46.338 DEBUG teleinfo2mqtt: Value for label FPM1 = 00 11:56:46.338 WARN teleinfo2mqtt: Error on parsing the value [00] and the timestamp [ 230214060000] for label [FPM1]: [Invalid timestamp ( 230214060000]`
est ce que c est normal ? comment le corriger ?