Bonjour,
Mon problème
Je jette une bouteille à la mer en espérant trouver un début de réponse, j’ai de temps en temps un comportement bizarre de certains sensors MQTT qui deviennent instables et font le yoyo entre la valeur réelle du sensor une valeur bidon qui sort de je ne sais pas où! Voici 2 exemples :
Pour l’instant, à part faire des redémarrages successifs de HA ou des intégrations liées à MQTT (Mosquitto, zigbee2mqtt, mqtt, …) jusqu’à ce que par chance ça revienne à la normale, je ne vois pas d’où vient ce problème…
Est-ce que quelqu’un aurait déjà eu un problème similaire ou saurait m’indiquer dans quelle direction chercher?
Merci d’avance.
Ma configuration
System Information
version |
core-2024.12.5 |
installation_type |
Home Assistant OS |
dev |
false |
hassio |
true |
docker |
true |
user |
root |
virtualenv |
false |
python_version |
3.13.0 |
os_name |
Linux |
os_version |
6.6.66-haos |
arch |
x86_64 |
timezone |
Europe/Paris |
config_dir |
/config |
Home Assistant Community Store
GitHub API |
ok |
GitHub Content |
ok |
GitHub Web |
ok |
HACS Data |
ok |
GitHub API Calls Remaining |
5000 |
Installed Version |
2.0.1 |
Stage |
running |
Available Repositories |
1554 |
Downloaded Repositories |
30 |
Home Assistant Cloud
logged_in |
true |
subscription_expiration |
7 janvier 2025 à 01:00 |
relayer_connected |
true |
relayer_region |
eu-central-1 |
remote_enabled |
true |
remote_connected |
true |
alexa_enabled |
true |
google_enabled |
true |
cloud_ice_servers_enabled |
true |
remote_server |
eu-central-1-1.ui.nabu.casa |
certificate_status |
ready |
instance_id |
2c0869c28d534ad59d8fa46abb448787 |
can_reach_cert_server |
ok |
can_reach_cloud_auth |
ok |
can_reach_cloud |
ok |
Home Assistant Supervisor
host_os |
Home Assistant OS 14.1 |
update_channel |
stable |
supervisor_version |
supervisor-2024.12.0 |
agent_version |
1.6.0 |
docker_version |
27.2.0 |
disk_total |
30.8 GB |
disk_used |
14.7 GB |
healthy |
true |
supported |
true |
host_connectivity |
true |
supervisor_connectivity |
true |
ntp_synchronized |
true |
virtualization |
kvm |
board |
ova |
supervisor_api |
ok |
version_api |
ok |
installed_addons |
Z-Wave JS (0.9.0), Samba share (12.3.2), Terminal & SSH (9.16.0), Studio Code Server (5.18.0), Node-RED (18.1.1), teleinfo2mqtt (9.0.4), Mosquitto broker (6.4.1), Zigbee2MQTT (1.42.0-2), Home Assistant Google Drive Backup (0.112.1), AppDaemon (0.16.7), Netatmo Favorites Weather Stations (0.9.8), Matter Server (7.0.0) |
Dashboards
dashboards |
3 |
resources |
17 |
views |
5 |
mode |
storage |
Recorder
oldest_recorder_run |
19 décembre 2024 à 14:47 |
current_recorder_run |
2 janvier 2025 à 09:15 |
estimated_db_size |
734.64 MiB |
database_engine |
sqlite |
database_version |
3.45.3 |
Solcast PV Forecast
Sonoff
version |
3.8.1 (ffa7e22) |
cloud_online |
0 / 0 |
local_online |
0 / 0 |
___
Bonjour,
Non vraiment personne ne connait ce problème?
C’est reparti de plus belle depuis 2 jours… 
Salut,
Pas d’idée, mais il faut aller chercher partout dans les logs (HA, z2M) pour voir s’il ne s’y cache pas un indice (même pas forcement en rapport avec MQTT)… Là juste les courbes, ça permet juste de dire : oui, il y a un souci
Bonsoir et merci pour ta réponse.
J’ai rien trouvé de particulier dans les logs. Le problème était revenu depuis 3 jours et les redémarrages de HA, Z2M, Mosquitto Broker n’y faisaient rien.
Je viens à l’instant de re-configurer l’intégration MQTT et tous mes capteurs sont revenus à la normale. Peut-être jusqu’au prochain bug donc à suivre… 
Si tu n’as pas bidouillé ta base de données… Question con, mais tu n’aurais pas 2 MQTT avec la même config (et la même ip par ex) ?
Genre, avec le conflit d’ip, HA se connecte aléatoirement sur l’un ou l’autre.
L’un est à jour avec les vraies données qui sont alimentées, l’autre contient les anciennes valeurs et n’est plus jamais mis à jour ? Indice la valeur ‹ ancienne › de linky date que quand ? Septembre/octobre ? Cohérent avec l’ancienne température de 14°C ?
En effet je vient de vérifier et l’ancien indice du linky date du 02/10/2024, et il est cohérent avec la température extérieure de ce jour là (12,5°C). Ce serait donc d’anciennes valeurs qui remontent mais pourquoi?
Je n’ai qu’un seul MQTT configuré avec l’IP 127.0.0.1 et à priori il est impossible d’avoir 2 entrées dans l’intégration MQTT :
Donc il faut essayer de te souvenir de ce qu’il s’est passé à cette époque…
2 mqtt, c’est pas impossible (tout est container, donc un ancien et un nouveau lacné par HA)…
Tu as essayé d’arrêter la machine sur laquelle ça fonctionne ?
Et regarde si tu ne vois pas des trucs sur les containers avec portainer par exemple
Me souvenir, j’ai bien regardé ce que j’ai pu faire sur HA à ce moment là mais je vois pas.
Je viens de redémarrer ma machine et le problème est revenu aussitôt. J’ai rechargé la configuration MQTT pour que ça revienne à la normale de nouveau. Mais le problème est toujours là…
Enfin pour « voir des trucs sur les containers avec portainer » on fait comment, là je t’avoue que ça dépasse mes connaissances actuelles… 
Pour information, HA tourne chez moi sur une VM sous Proxmox.
Et encore merci pour ton aide, déjà j’ai un début de piste…
Portainer est dispo dans les addons après ajout du repo
Doc incluse
Merci, c’est bon j’ai installé Portainer.
Je dois vérifier quoi dans les containers ensuite?
Il faut voir s’il n’y a pas des doublons (la c’est juste la 1ere page), un deuxième serveur MQTT ou un truc équivalent
Par exemple je vois un teleinfo qui remonte sans doute les infos du linky, mais le linky n’est-il pas aussi visible dans zigbee2mqtt ?
Voilà la liste complète, pas de doublon à priori :
Juste pour mon info, c’est normal tous ces logs de connexion/déconnexion dans mosquitto (voir ci-dessous) ?
Ca tient bon depuis plus de 24h, pourvu que ça dure…
Mes capteurs font de nouveau le yoyo depuis hier 13h, je ne sais plus quoi faire… 
Il s’est passé quoi hier vers 12H30 ?
Ensuite, il faut vérifier que la valeur ‹ pourrie › est issue de MQTT oui si elle arrive (générée) après dans HA.
Bref, il faut isoler la source en premier
J’ai un broker externe (IoBroker) pour ma batterie Zendure qui fait des siennes, mais je n’arrive pas à remonter assez loin dans les logs pour savoir si ça a commencé vers 12h30 hier. Après, savoir si c’est la cause ou la conséquence…

Ok, donc sans remonter dans le passer, vois-tu l’alternance des valeurs dans MQTT ?
Oui je vois bien les valeurs alterner en live
Donc il faut chercher en amont du broker
Coté zigbee tu vois cette alternance ?
Voilà par exemple les 10 derniers messages reçus pour le sensor « zigbee2mqtt/Temp Hum SdB Julien » :
Received 14:33:24
QoS: 0
Payload: battery: 100
humidity: 61.41
linkquality: 160
power_outage_count: 3
pressure: 960
temperature: 21.26
voltage: 3005
Received 14:33:30
QoS: 0
Payload: battery: 100
humidity: 61.41
linkquality: 160
power_outage_count: 3
pressure: 960
temperature: 21.26
voltage: 3005
Received 14:33:35
QoS: 0
Payload: battery: 100
humidity: 54.6
linkquality: 136
power_outage_count: 3
pressure: 959.2
temperature: 19.88
voltage: 3005
Received 14:33:35
QoS: 0
Payload: battery: 100
humidity: 54.65
linkquality: 136
power_outage_count: 3
pressure: 959.2
temperature: 19.88
voltage: 3005
Received 14:33:35
QoS: 0
Payload: battery: 100
humidity: 54.65
linkquality: 136
power_outage_count: 3
pressure: 959.3
temperature: 19.88
voltage: 3005
Received 14:33:36
QoS: 0
Payload: battery: 100
humidity: 61.41
linkquality: 160
power_outage_count: 3
pressure: 960
temperature: 21.26
voltage: 3005
Received 14:33:41
QoS: 0
Payload: battery: 100
humidity: 54.65
linkquality: 136
power_outage_count: 3
pressure: 959.3
temperature: 19.88
voltage: 3005
Received 14:33:42
QoS: 0
Payload: battery: 100
humidity: 61.41
linkquality: 160
power_outage_count: 3
pressure: 960
temperature: 21.26
voltage: 3005
Received 14:33:48
QoS: 0
Payload: battery: 100
humidity: 61.41
linkquality: 160
power_outage_count: 3
pressure: 960
temperature: 21.26
voltage: 3005
Received 14:33:54
QoS: 0
Payload: battery: 100
humidity: 61.41
linkquality: 160
power_outage_count: 3
pressure: 960
temperature: 21.26
voltage: 3005