La période réelle de Trame MQTT (routeur_rms_state) ne correspond pas à celle réglée dans l'interface.      

La période réelle est décalée de 1s, par exemple :
- avec 1 dans l'interface, on a une trame toutes les 2 secondes
- avec 2 dans l'interface, on a une trame toutes les 3 secondes
- avec 3 dans l'interface, on a une trame toutes les 4 secondes
... et avec 0, cette trame n'existe pas.

Du coup, impossible d'avoir une trame chaque seconde (ce qui me serait vraiment utilie, j'avoue )

Est-ce que la structure du programme le permettrait ? (cores/threads, déroulement, accès aux données, temps de calculs)

J'ai installé la dernière version (v15.08) afin d'être sûr que le problème n'avait pas déjà été réglé depuis la version (12.05 modifiée) que j'utilise normalement

Bonjour,
Vu que vous êtes en mesure de modifier le code, je me demande si ce comportement n'est pas lié à cette ligne dans le fichier MQTT.ino :
if (int((tps - previousMQTTenvoiMillis) / 1000) > MQTTRepet && MQTTRepet != 0) {
Peut-etre qu'un >= à la place du > corrigerai ce comportement soit :
if (int((tps - previousMQTTenvoiMillis) / 1000) >= MQTTRepet && MQTTRepet != 0) {

Je n'ai pas testé mais je pense que ça peut marcher.
Vous me direz

Bonjour,
Hmmm ah oui ça pourrait ressembler à ça, bien vu !

J’essaierai dès que je pourrai, voir si celà suffit (en espérant que les données soient mises à jour assez souvent)
Merci pour la recherche !

(prochaine étape : toutes les 500ms )

Attention aux période de répétitions trop rapides .
perso avec HA, je suis revenu à une répétition de 10 ( sur la page paramètres) afin de ne pas saturer inutilement HA .
Tout dépend, ce que vous souhaiter gérer derrière ..

> ou >= ne changera pas grand chose. On dépasse le temps à cause des temps de transfert qui s'additionne. Attention à ne pas saturer HA avec un sur echantillonnage qui n'apporte pas grand chose.
André

Je n'ai pas eu le temps de regarder le code, mais est-ce que ce serait envisageable d'atteindre la seconde en MQTT ?

Mon HA est loin de saturer, avec pourtant :
- 40 intégrations
- 1200 capteurs
- 2000 entités
- rétention des données sur 60 jours

L'occupation CPU est à 5%, la RAM à 32% (PC portable de récup, core i7, Debian et VM)

Dans mon cas, ça me serait utile pour alimenter entre-autres l'intégration de plusieurs batteries domestiques Zendure
(un oversampling effectivement, des données plus fréquentes et des filtres personnalisés pour éviter des commutations charges/décharges trop fréquentes tout en gardant une bonne réactivité)

Pour préciser l'idée derrière, c'est qu'il est plus facile de filtrer une valeur crête qui dure une seconde avec un retour au régime établi juste après, qu'un plateau de 2s ou 4s, pendant lequel les batteries domestiques ont eu le temps de changer de consigne (et de commuter leurs relais, souvent) pour rien.

Un petit exemple rapide :
   

Bon, j'ai enfin eu et pris le temps de remettre Arduino et tout le nécessaire sur mon PC, et j'ai testé le correctif de Mike.
Et... il s'avère que ça fonctionne !
La période MQTT respecte à la lettre le champ de la page de paramètres, et j'ai une trame de mesures par seconde.

Donc Merci et Bravo à Mike d'avoir apporté une solution à ma gourmandise de données, et merci pour la préservation attendue de mon matériel.

Merci du retour Youpimatin , bon à savoir .
A voir si André peut implémenter ce petit correctif de Mike dans une version à venir pour les personnes qui seraient intéressés

C'est fait dans la V15.10 à venir.

André