Problème sensors MQTT instables

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
can_reach_server ok
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… :cry:

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… :crossed_fingers:

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… :sweat_smile:

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… :sob:

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…

image

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