Erreur Sensor:904 sur Linky

HESSER · Mars 25, 2024, 10:00

Bonjour,
J’ai installé un capteur sur mon compteur Linky
Je remonte bien mes informations (pas toutes) mais j’ai en permanence des erreurs de ce type:

[10:53:59][D][sensor:094]: 'Intensité souscrite': Sending state 30.00000 A with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Index Heures Creuse': Sending state 3363461.00000 WH with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Index Heures Pleine': Sending state 4631223.00000 WH with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Période Tarifaire 0=HP 1=HC': Sending state 0.00000 Wh with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Intensité Instantanée': Sending state 2.00000 A with 0 decimals of accuracy
[10:53:59][E][teleinfo:038]: bad crc: got 57 except 66
[10:53:59][D][sensor:094]: 'Intensité souscrite': Sending state 30.00000 A with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Index Heures Creuse': Sending state 3363461.00000 WH with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Index Heures Pleine': Sending state 4631223.00000 WH with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Période Tarifaire 0=HP 1=HC': Sending state 0.00000 Wh with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Intensité Instantanée': Sending state 2.00000 A with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Puissance Apparente': Sending state 530.00000 VA with 0 decimals of accuracy
[10:53:59][D][sensor:094]: 'Horaire Heures Creuse': Sending state 0.00000 H with 0 decimals of accuracy
[11:10:14][W][component:232]: Component teleinfo took a long time for an operation (141 ms).
[11:10:15][W][component:233]: Components should block for at most 30 ms.

Ce doit être une histoire du nombre de décimales attendue ou reçue???

Avez-vous une idée pour résoudre ce problème?

Pulpy-Luke · Mars 25, 2024, 10:16

Salut @Hesser
Pourquoi mettre ce sujet dans la catégorie de tutoriels ? Il s’agit d’une demande d’aide et non d’une proposition de solution. non ?

jrvrcd · Mars 25, 2024, 10:22

Salut

quel type de capteur ?
a priori un esp avec l’interface qui va bien

quel est le code yaml que tu as utilisé pour l’ESP

merci de nous aider a t’aider

l’erreur que tu signale c’est:
[10:53:59][E][teleinfo:038]: bad crc: got 57 except 66

ou

[11:10:14][W][component:232]: Component teleinfo took a long time for an operation (141 ms).
[11:10:15][W][component:233]: Components should block for at most 30 ms.

WarC0zes · Mars 25, 2024, 10:23

Bonjour,

sensor:94 est pas une erreur. Chez moi c’est pareil dans les logs. Une erreur est soit en jaune pour moyen, ou en rouge pour elevé.

[11:20:16][D][sensor:094]: 'Still Energy': Sending state 13.00000 % with 0 decimals of accuracy
[11:20:16][D][sensor:094]: 'wifi_signal_db': Sending state -64.00000 dBm with 0 decimals of accuracy
[11:20:16][D][sensor:094]: 'WiFi Signal Percent': Sending state 72.00000 % with 0 decimals of accuracy
[11:20:17][D][sensor:094]: 'light': Sending state 93.00000  with 0 decimals of accuracy
[11:20:18][D][sensor:094]: 'Still Energy': Sending state 11.00000 % with 0 decimals of accuracy
[11:20:18][D][sensor:094]: 'light': Sending state 94.00000  with 0 decimals of accuracy
[11:20:19][D][sensor:094]: 'Still Energy': Sending state 10.00000 % with 0 decimals of accuracy
[11:20:19][D][sensor:094]: 'light': Sending state 93.00000  with 0 decimals of accuracy
[11:20:20][D][sensor:094]: 'Still Energy': Sending state 7.00000 % with 0 decimals of accuracy
[11:20:20][D][sensor:094]: 'light': Sending state 94.00000  with 0 decimals of accuracy
[11:20:21][D][sensor:094]: 'Still Energy': Sending state 9.00000 % with 0 decimals of accuracy
[11:20:21][D][sensor:094]: 'light': Sending state 93.00000  with 0 decimals of accuracy
[11:20:22][D][sensor:094]: 'Still Energy': Sending state 20.00000 % with 0 decimals of accuracy
[11:20:23][D][sensor:094]: 'Still Energy': Sending state 22.00000 % with 0 decimals of accuracy
[11:20:23][D][sensor:094]: 'light': Sending state 94.00000  with 0 decimals of accuracy
[11:20:24][D][sensor:094]: 'Still Energy': Sending state 25.00000 % with 0 decimals of accuracy
[11:20:24][D][sensor:094]: 'light': Sending state 93.00000  with 0 decimals of accuracy
[11:20:25][D][sensor:094]: 'Still Energy': Sending state 20.00000 % with 0 decimals of accuracy
[11:20:26][D][sensor:094]: 'Still Energy': Sending state 11.00000 % with 0 decimals of accuracy
[11:20:27][D][sensor:094]: 'Still Energy': Sending state 9.00000 % with 0 decimals of accuracy
[11:20:28][D][homeassistant.sensor:024]: 'sensor.atc_20a2_temperature': Got state -15.25

ERROR

With this log level, only errors are logged. Errors are issues that prevent the ESP from working correctly. Color: red

WARN

With this log level, warnings and errors are logged. Warnings are issues like invalid readings from sensors that ESPHome can recover from. Color: yellow

INFO

With this log level, everything up to info messages are logged; so errors, warnings and info. Color: green

DEBUG (Default)

Everything up to this log level is logged. Debug messages include the current readings from a sensor and status messages. Color: cyan

VERBOSE

Like debug, but a few more messages that are usually deemed to be spam are also included. Color: grey

VERY_VERBOSE

All internal messages are logged. Including all the data flowing through data buses like I²C, SPI or UART. Warning: May cause the device to slow down and have trouble staying connecting due to amount of generated messages. Color: white

HESSER · Mars 25, 2024, 10:26

Désolé de l’erreur.
Comment déplacer le sujet???

Et dans quel rubrique le mettre?

Merci

Pulpy-Luke · Mars 25, 2024, 10:26

Oui, edite ton titre, ça donne accès à la catégorie également

HESSER · Mars 25, 2024, 10:30

Oui, il s’agit d’un ESP32 précédé d’un optocoupleur PITInfo connecté sur la sortie du Linky.

Le code est le suivant:

 Entrée sorties
output:
  # LEd témoin programmation
  - id: light_output
    platform: gpio
    pin: GPIO2

uart:
  id: uart_bus
  rx_pin: GPIO16  # RX2
  baud_rate: 1200 # 9600 == mode standard, 1200 == mode historique
  parity: EVEN
  data_bits: 7
  stop_bits: 1

text_sensor:
  - platform: template
    name: Uptime
    id: uptime_human
    icon: mdi:clock-start

  - platform: wifi_info
    ip_address:
      name: Linky IP Address
    mac_address:
      name: Linky Wifi Mac Address

teleinfo:
  update_interval: 5s
  historical_mode: true 

sensor:
  - platform: wifi_signal
    name: "WiFi Signal"
    update_interval: 60s
    unit_of_measurement: dB
    accuracy_decimals: 0
    force_update: false
    icon: mdi:wifi

  - platform: uptime
    id: uptime_seconds
    name: "Uptime"
    update_interval: 60s
    unit_of_measurement: s
    accuracy_decimals: 0
    force_update: false
    icon: mdi:timer
    on_raw_value:
      then:
        - text_sensor.template.publish:
            id: uptime_human
            state: !lambda |-
              int seconds = round(id(uptime_seconds).raw_state);
              int days = seconds / (24 * 3600);
              seconds = seconds % (24 * 3600);
              int hours = seconds / 3600;
              seconds = seconds % 3600;
              int minutes = seconds /  60;
              seconds = seconds % 60;
              return (
                (days ? to_string(days) + "d " : "") +
                (hours ? to_string(hours) + "h " : "") +
                (minutes ? to_string(minutes) + "m " : "") +
                (to_string(seconds) + "s")
              ).c_str();

  # Intensité souscrite
  - platform: teleinfo
    tag_name: "ISOUSC"
    name: "Intensité souscrite"
    unit_of_measurement: A
    device_class: current
    state_class: measurement
    icon: mdi:current-ac

   # Intensité Instantanée
  - platform: teleinfo
    tag_name: "IINST"
    name: "Intensité Instantanée"
    unit_of_measurement: A
    device_class: current
    state_class: measurement
    icon: mdi:current-ac

  # Puissance Apparente
  - platform: teleinfo
    tag_name: "PAPP"
    name: "Puissance Apparente"
    unit_of_measurement: VA
    state_class: measurement
    device_class: apparent_power
    icon: mdi:gauge

  # Période Tarifaire
  - platform: teleinfo
    tag_name: "PTEC"
    name: "Période Tarifaire 0=HP 1=HC"
    icon: mdi:key

  # Index Heures Pleine
  - platform: teleinfo
    tag_name: "HCHP"
    name: "Index Heures Pleine"
    unit_of_measurement: WH
    icon: mdi:HCHP

  # Index Heures Creuse
  - platform: teleinfo
    tag_name: "HCHC"
    unit_of_measurement: WH
    name: "Index Heures Creuse"
    icon: mdi:HCHC

  # Horaire Heures Pleines Heures Creuses
  - platform: teleinfo
    tag_name: "HHPHC"
    unit_of_measurement: H
    name: "Horaire Heures Creuse"
    icon: mdi:Heures

Soit dit en ^passant, l’information PTEC reste à 0. Mais c’est un autre problème.

D’après ce que je viens de lire, il y a 3 type de messages:
D → debug → ‹ Intensité souscrite ›: Sending state 30.00000 A with 0 decimals of accuracy
Problème du nombre de décimal; ça devrait pouvoir se régler en spécifiant quelque par cette valeur
C’est plutôt ça que j’aimerai corriger
W → Warning → [component:232]: Component teleinfo took a long time for an operation (81 ms).
E → Error → bad crc: got 57 except 66
Le Warning et l’Erreur se régleront probablement quand je n’aurais plus 8m entre l’ESP et le Linky

jrvrcd · Mars 25, 2024, 10:39

Regarde ce lien

je crois de mémoire que tu as tous les cas de figures proposé ( mono tri, historique, standard…)

gist.github.com

https://gist.github.com/mathieucarbou/886d2a6f5c0b51bb261d6a1329beb08d

README.md

# Linky Teleinformation (TIC) + ESPHome + Home Assistant

## Vue Home Assistant

![Safari Screenshot 2023-02-15 01 58 53](https://user-images.githubusercontent.com/61346/218898203-f5be773c-81e2-4d68-b81e-d8342b2b7a3d.jpg)

## Vue du Web Server

![Screenshot 2023-02-15 at 12 24 23](https://user-images.githubusercontent.com/61346/219016390-f4d80a56-7fcc-4f1a-9f15-770e52e06f07.png)

This file has been truncated. show original

linky.yaml

esphome:
  name: linky

# https://esphome.io/components/esp8266.html
esp8266:
  board: d1_mini

# https://esphome.io/components/esp32.html
#esp32:
#  board: lolin_s2_mini

This file has been truncated. show original

jrvrcd · Mars 25, 2024, 10:49

cette discussion est aussi plutot complete

essaye d’y jeter un coup d’oeil

avec le lien… c’est mieux

HESSER · Mars 25, 2024, 3:21

@ jrvrcd
Effectivement, j’ai trouvé cette information à ajouter dans le code de l’esp.

Avant:

uart:
  id: uart_bus
  rx_pin: GPIO16  # RX2
  baud_rate: 1200 # 9600 == mode standard, 1200 == mode historique
  parity: EVEN
  data_bits: 7
  stop_bits: 1

Après

uart:
  id: uart_bus
  rx_pin: GPIO16  # RX2
  baud_rate: 1200 # 9600 == mode standard, 1200 == mode historique
  parity: EVEN
  data_bits: 7
  stop_bits: 1
  rx_buffer_size: 2048

L’ajout du rx_buffer_size fait que je n’ai pratiquement plus (1 fois sur 10) l’erreur:
bad crc: got 57 except 66
qui apparaissait très fréquemment précédemment. ((1 fois sur 3)

PS: ça n’apporte rien d’augmenter encore ce rx_buffer_size

jrvrcd · Mars 25, 2024, 3:27

si tu veux adapter le nombre de decimales

regardes dans la doc ESPHOME

je crois que le parametre a utiliser est

accuracy_decimals (Optional, int): Manually set the number of decimals to use when reporting values. This does not impact the actual value reported to Home Assistant, it just sets the number of decimals to use when displaying it.

jrvrcd · Mars 25, 2024, 4:22

De retour a la maison

pour le parametre PTEC
c’est un text_sensor en non un sensor tout court

je pense que c’est la raison pour laquelle tu n’as rien

text_sensor:
  - platform: teleinfo
    tag_name: "PTEC"
    name: "ptec"
    teleinfo_id: myteleinfo

HESSER · Mars 25, 2024, 4:28

Ouiiii c’est ça; PTEC est du texte. C’est bon. j’ai maintenant l’info
Merci beaucoup.