J’ai trouvé la cause et la solution chez moi, je la partage si ça peut aider.
Contexte :
SmartMeter 3CT en MQTT
SolarFlow 800 via intégration zendure_ha (pas en MQTT direct)
Symptômes :
après reboot HA, SmartMeter indisponible
SolarFlow repasse à 0W
dans l’activité Zendure, rafale de unknown / valeurs qui sautent
Cause : mon automation de recovery était trop agressive (stop/start Mosquitto + reload Zendure répétés), ce qui provoquait des déconnexions temporaires d’entités et des 0/unknown.
Ce qui a stabilisé :
- Garder SolarFlow sur zendure_ha uniquement (pas de MQTT direct SolarFlow).
- Créer un capteur template sensor.power_actual pointant sur le SmartMeter réel :
sensor:
- name: "Power Actual"
unique_id: power_actual
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{{ states('sensor.te31njn8n381735_l3_p') | float(0) }}
availability: >
{{ has_value('sensor.te31njn8n381735_l3_p') }}
- Dans Zendure, utiliser p1meter: sensor.power_actual.
- Recovery au reboot : éviter les reloads en boucle ; ne relancer MQTT/Zendure que si SmartMeter indisponible.
- Ajouter une automation de sécurité : si number.solarflow_800_output_limit reste à 0 après reboot, remettre 800.
Automation utile pour la limite de sortie :
alias: "SolarFlow800 - Réappliquer limite sortie après reboot"
mode: restart
trigger:
- platform: homeassistant
event: start
- platform: state
entity_id: number.solarflow_800_output_limit
to: "0"
for: "00:00:10"
action:
- delay: "00:00:30"
- repeat:
until:
- condition: template
value_template: >
{{ has_value('number.solarflow_800_output_limit') or repeat.index >= 12 }}
sequence:
- delay: "00:00:10"
- repeat:
count: 4
sequence:
- choose:
- conditions:
- condition: template
value_template: "{{ states('number.solarflow_800_output_limit') | float(0) == 0 }}"
sequence:
- service: number.set_value
target:
entity_id: number.solarflow_800_output_limit
data:
value: 800
- delay: "00:00:15"
Point important :
si vous voyez beaucoup de unknown côté SolarFlow juste après reboot, vérifiez vos automations de recovery : souvent c’est la séquence de reload qui crée le problème.
Le bloc sensor: (template Power Actual) va dans templates.yaml (déjà inclus par configuration.yaml avec template: !include templates.yaml).
Le bloc d’automation va dans automations.yaml (dans la liste existante avec les autres - id: / alias🙂.
Ensuite dans HA :
Paramètres > Contrôle serveur > Vérifier la configuration
Recharger les automatisations et Recharger les entités template
Si besoin, redémarrer HA.
Pour le smartmeter 3ct :
Dans l’automation actuelle, on corrige surtout le 0W, mais on ne journalise pas explicitement “SmartMeter 3CT indisponible”.
Ajoute cette automation pour le tracer clairement :
- id: '1763231000002'
alias: "Alerte SmartMeter 3CT indisponible"
mode: single
triggers:
- trigger: state
entity_id: id sensor smartmeter 3ct
to: "unavailable"
for: "00:00:30"
actions:
- action: system_log.write
data:
level: warning
message: "SmartMeter 3CT indisponible depuis 30s (id sensor smartmeter 3ct)."
- action: persistent_notification.create
data:
title: "SmartMeter 3CT indisponible"
message: "Le capteur MQTT id sensor smartmeter 3ct est indisponible depuis plus de 30 secondes."
Et pour confirmer l’état en direct :
Outils de développement → États → sensor.te31njn8n381735_l3_p
Historique de cette entité pour voir les passages unavailable.