Happy to report that I can compute the power factor
Comme vous savez le facteur K est égal a P/S = cos phi
Intéressant de noter que k suit les courbes de puissance ce qui est logique.
A forte puissance le K monte a 90% et a faible puissance il descent à 68%.
Quand les « gros appareils » ne tirent plus les « apparels electroniques » avec un facteur de forme pourri prennent le dessus 
Et tu as utilisé SINSTS et CCASN pour cette calculation ? Est-ce-que tu fait la calculation sur l’ESP ou en HA ? Tu peut nous montrer ton YAML / lambda ?
D’après mes relevés CCASN fournis la puissance réelle avec une période d’intégration qui porte sur les trente dernières minutes (mis a jour a hh:00 et hh:30). SINSTS est la puissance apparente instantanée (calcule sur une période d’une seconde). Afin que le rapport de ces deux puissances soit plus cohérent j’ai créé un sensor qui calcule la valeur moyenne de SINSTS sur les 30 dernières mn en utilisant l’intégration GitHub - Limych/ha-average: Average Sensor for Home Assistant et donc mon PF = CCASN/SINSTS(averaged)
Comme les deux valeurs ne sont pas « synchronisés » le facteur K avait des fluctuations transitoires au moment de la mise à jour des deux puissances. Donc je calcul K a l’heure et la demi-heure décalé de une seconde (hh:01 et hh:31) et je le stock dans un compteur pour affichage.
Donc dans configuration.yaml
counter:
store_pf:
initial: 0
name: "Store power factor"
sensor:
- platform: template
linky_pf:
friendly_name: "Linky power factor"
value_template: >-
{{states('counter.store_pf')|int}}
unit_of_measurement: "%"
# Average the apparent power over a period of 30 mn
- platform: average
name: 'Apparent power (average)'
duration:
minutes: 30
entities:
- sensor.linky_sinsts
Dans automation
- id: '1632663873518'
alias: Store mean app power
description: Store in a couter the computed average value of apparent power
trigger:
- platform: time_pattern
minutes: '01'
- platform: time_pattern
minutes: '31'
condition: []
action:
- service: counter.configure
target:
entity_id: counter.store_pf
data:
value: '{{states("sensor.compute_pf") |float}}'
mode: single
Et je display dans lovelace
type: custom:apexcharts-card
graph_span: 1d
all_series_config:
stroke_width: 2
apex_config:
chart:
zoom:
enabled: true
toolbar:
show: true
tools:
zoom: true
zoomin: true
zoomout: true
pan: true
reset: true
header:
show: true
title: 'Power: App.(avg)/Real + Power factor'
show_states: true
colorize_states: true
series:
- entity: sensor.linky_ccasn
name: Real
yaxis_id: first
- entity: sensor.apparent_power_average
name: Apparent(avg)
yaxis_id: first
- entity: sensor.linky_pf
name: PF
yaxis_id: second
yaxis:
- id: first
apex_config:
tickAmount: 4
- id: second
opposite: true
show: true
apex_config:
tickAmount: 4
Ce n’est pas parfait mais cela semble donner des résultats cohérents.
Je pense que c’est le mieux que l’on peut faire avec les données transmises par le Linky même si par moment j’ai des résultats curieux
English :
According to my readings CCASN provides the real power with an integration period that covers the last thirty minutes. SINSTS is the instantaneous apparent power (calculated over a period of one second). In order for the ratio of these two powers to be more coherent I created a sensor that calculates the average value of SINSTS over the last 30 minutes using the average integration
and thus my PF = CCASN/SINSTS(averaged)
As the two values are not « synchronized » the K factor had transient fluctuations at the time of the update of the two powers. So I calculate K on the hour and half hour (off by one second) and store it in a counter for display.
Intéressante étude en tous cas
Le cosphi était une donnée facile à gérer en fait . Donnée principalement générée par des machines tournantes ( des moteurs en clair)
Ça se réglait avec des condensateurs .
Avec les alim à découpage, ce n’est plus un cosphi mais effectivement un facteur de forme lié au découpage .
Le cosphi provenait du déphasage entre la tension sinusoïdale et un courant lui aussi sinusoïdal
Le facteur de forme provient du couple entre une tension sinusoïdale et un courant “coupé en tranches »
C’est pas évident d’en faire un modèle
C’est pour cela que les normes ont imposé l’ajout de correcteur de facteur de forme pour les alimentations à découpage à partir d’une certaine puissance .
Pour les petites puissances type chargeur, c’est dans le bruit de fond de la consommation
Hello,
petite question, on a une longueur max sur les câbles entre le compteur et le PCB, car le compteur n’est pas chez moi mais sur un pallier ?
A++
Oui plusieurs centaines de mètres !
Aucun problème
Phil
Bonjour,
J’ai un compteur Linky triphasé configuré en mode standard, mon câblage est correct, car j’arrive à avoir les données brutes avec le code fourni par Jpsy.
Mais quand je passe avec une configuration classique les valeurs afficher dans HA son inconnu.
Voici les logs :
[08:35:39][W][ota:036]: Last Boot was an unhandled reset, will proceed to safe mode in 4 restarts
[08:35:39][C][api:135]: API Server:
[08:35:40][C][api:136]: Address: 192.168.0.48:6053
[08:35:40][C][api:140]: Using noise encryption: NO
[08:35:40][C][wifi_signal.sensor:009]: WiFi Signal 'WiFi Signal Sensor'
[08:35:40][C][wifi_signal.sensor:009]: Device Class: 'signal_strength'
[08:35:40][C][wifi_signal.sensor:009]: State Class: 'measurement'
[08:35:40][C][wifi_signal.sensor:009]: Unit of Measurement: 'dB'
[08:35:40][C][wifi_signal.sensor:009]: Accuracy Decimals: 0
[08:35:40][C][wifi_signal.sensor:009]: Icon: 'mdi:wifi'
[08:35:40][V][wifi_signal.sensor:009]: Unique ID: '84cca8b06d8b-wifisignal'
[08:35:44][D][text_sensor:015]: 'Uptime': Sending state '2m 47s'
[08:35:51][V][sensor:070]: 'WiFi Signal Sensor': Received new state -65.000000
[08:35:52][D][sensor:121]: 'WiFi Signal Sensor': Sending state -65.00000 dB with 0 decimals of accuracy
[08:35:52][V][component:207]: Component wifi_signal.sensor took a long time for an operation (0.06 s).
[08:35:52][V][component:208]: Components should block for at most 20-30ms.
[08:35:52][V][component:207]: Component ota took a long time for an operation (0.06 s).
[08:35:52][V][component:208]: Components should block for at most 20-30ms.
[08:36:15][V][component:207]: Component ota took a long time for an operation (0.07 s).
[08:36:15][V][component:208]: Components should block for at most 20-30ms.
[08:36:34][W][teleinfo:058]: Internal buffer full
[08:36:34][V][sensor:070]: 'Uptime Sensor': Received new state 227.578003
[08:36:34][D][sensor:121]: 'Uptime Sensor': Sending state 227.57800 s with 0 decimals of accuracy
[08:36:34][V][component:207]: Component uptime.sensor took a long time for an operation (0.06 s).
[08:36:34][V][component:208]: Components should block for at most 20-30ms.
[08:36:42][V][component:207]: Component ota took a long time for an operation (0.07 s).
[08:36:42][V][component:208]: Components should block for at most 20-30ms.
[08:36:44][D][text_sensor:015]: 'Uptime': Sending state '3m 47s'
[08:36:51][V][sensor:070]: 'WiFi Signal Sensor': Received new state -65.000000
[08:36:52][D][sensor:121]: 'WiFi Signal Sensor': Sending state -65.00000 dB with 0 decimals of accuracy
[08:36:52][V][component:207]: Component wifi_signal.sensor took a long time for an operation (0.06 s).
[08:36:52][V][component:208]: Components should block for at most 20-30ms.
[08:37:34][V][sensor:070]: 'Uptime Sensor': Received new state 287.522003
[08:37:34][D][sensor:121]: 'Uptime Sensor': Sending state 287.52200 s with 0 decimals of accuracy
[08:37:34][V][component:207]: Component uptime.sensor took a long time for an operation (0.05 s).
[08:37:34][V][component:208]: Components should block for at most 20-30ms.
[08:37:34][V][component:207]: Component ota took a long time for an operation (0.07 s).
[08:37:34][V][component:208]: Components should block for at most 20-30ms.
Je suis a jour de ESPHome.
Merci pour votre aide.
Bonjour et merci pour toutes ces infos, je suis tout neuf sur la communauté et j’essaye de me lancer dans la domotique. J’ai commencé il y a 2 jours en installant HA et en connectant mes 3 thermometres xiaomi mijia2 carrés. Je voudrais maintenant pouvoir suivre ma consommation EDF et je suis tombé sur ce sujet (et sur d’autres).
Comme le sujet est la depuis presque 1 an j’essaye de récapituler le matériel dont j’ai besoin et ce que je dois faire.
Le post de Jcpas ici : https://forum.hacf.fr/t/teleinfo-via-wifi/1077/78 m’a d’ailleurs aidé. j’ai bien sur lu aussi celui de myCanaletto mais si j’ai bien compris il utilise un autre systeme.
Mon linky est dans ma baie electrique donc alimentation OK.
En matériel il faudrait donc :
S’il y a des cartes « toutes pretes » pourquoi avoir fait fabriquer des circuits imprimés ?
Logiciel :
Ensuite :
comment brancher les cables du PIT sur le linky ? ça s’emboite ?
Comment savoir si la sonde récupere bien des infos du compteur ? pour debug
Comme HA va recevoir (ou prendre) les infos de l’esp8266 ?
OU commander le materiel ? amazon ?
Merci pour votre aide
Salut @Albertos
Je vais essayer de répondre au mieux.
Matériel :
Logiciel :
Bonjour,
Je respecte bien sûr ton envie de développer le système toi même.
Néanmoins si tu cherches un système hyper bien intégré qui fonctionne du premier coup et pas cher du tout, regarde du côté du teleinfokit
https://342apps.net/home/
Phil
Est-ce qu’il faut une alim ?
Parce qu’il y a le projet ZLinky_TIC de Lixee qui m’a l’air très bien, dès qu’il sera intégrable dans Home Assistant (ce qui devrait arriver très vite).
Oui un chargeur quelconque usb.
Le Linxee est intéressant quand le Linky est éloigné et sans possibilité de tirer une paire de la TIC vers l’intérieur .
Il reste très cher vis à vis du teleinfokit
Super merci pour tes réponse,
Merci ! Ca à l’air pas mal du tout ça mais je vois pas de prix 
C’était 15 € il y a quelques mois . Demandez lui
A part l’aspect hébergement d’une base volumineuse sur mariadb sur ton nas, tu as noté un gain de rapidité HA a passer d’une base SQLite hébergé sur ton HA à une base mariadb sur ton nas? Je suis en cours de réflexion, bien que ma base SQLite sur mon rpi4 ha ne dépasse pas les 600mo avec purge tous les 30j.
Je n’ai pas vraiment vu de gain de perf, je n’ai pas l’impression que HA soit lourd. A quel niveau tu sens une lenteur ?
J’ai surtout migré vers mon NAS à cause des nombreux plantages dus au fichier SQLite trop volumineux, qui me faisait perdre mon historique.
Là avec Mariadb je lance un dump 2 fois par jour pour qui est automatiquement synchronisé avec mon Google Drive.
C’est vrai que le prix n’est pas le même.
Bonjour, j’ai utilisé le module et ça marche nikel ! merci à @NicoP4 .
J’ai une base influxdb, et j’ai mis à 0 sec le reglage pour l’actualisation. Est ce que ça va saturer la base ? Comment le vérifier ? merci à vous