Tu as bien mis la bonne pince ? Quand tu as une production solaire faible c’est pas censé aller dans la batterie, c’est censé aller dans ta maison… jusqu’à ce que la production solaire dépasse ta conso de ta maison, alors là le surplus ira dans la charge de la batterie.
Ton comportement n’est pas normal. Tu as bien désactivé le HEMS dans l’appli Zendure ?
Yes c’est la bonne pince car le reste du temps le comportement est ok et j’ai bien une recherche du 0W de rejet dans le réseau (sauf le cas que j’ai mentionné avant qui arrive en général en début de grosse production)
Ce que tu indiques est valable si le soc de la batterie est inférieur au soc mini ? Par exemple le matin je suis en général 1-2% sous le minisoc dû au perte de la nuit avec la fraicheur hivernal. Donc j’imagine que l’intégration essaie de remettre la batterie au soc mini puis passe sur l’alimentation de la maison. C’est en tout cas le comportement que j’observe une fois les 30% atteint.
Pas d’HEMS d’activé, je n’utilise même pas l’application. Tout est configuré en local sur HomeAssistant via MQTT.
Voici la conf :
J’essaierai de reprendre un screen sur le cas où on voit un envoi sur le réseau et la batterie en veille (mode contournement) alors qu’elle est à 30%
Vraiment bizarre, j’ai déjà eu mes batteries à 4% au réveil (alors que la limite basse est à 10%) et pourtant elles ont bien attendu que j’ai suffisamment de production pour charger. J’ai jamais vu mes batteries charger en tirant sur le réseau en mode couplage intelligent.
Edit: tu as un SF800 et tes panneaux sont branchés dessus j’imagine ? Alors là le comportement est peut-être différent, je saurais pas te dire. Peut-être qu’effectivement la priorité est donnée à la batterie au lieu du réseau…
Salut Garfunk,
Un grand merci pour ton aide, je commences à y voir plus clair 
Voilà ce qu’il faudrait que je fasse je pense au final :
1. Création du capteur
# -----------------------------
#
# ZENDURE
#
# -----------------------------
- name: "Grid Power Net Zendure"
unique_id: grid_power_net_zendure
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set p = states('sensor.grid_power_net') | float(0) %}
{% if p > 350 %}
0
{% else %}
{{ p | round(0) }}
{% endif %}
2. Changement du capteur dans l’intégration HA
Changement du capteur :
Au lieu de me baser directement sur le capteur Shelly (sensor.shellypro3em_ac15187ba824_energy_meter_0_puissance), il faudrait que je me base donc sur ce nouveau capteur (grid_power_net_zendure) :
et que je laisse le mode en couplage intelligent :
3. Configuration du groupe de fusibles
Je suis passé sur « L’appareil a son propre circuit ou phase » comme tu me l’as indiqué :
4. Application Zendure
Il faut que je désactive le mode HEMS de l’hyper 2000 :
Par contre, c’est pour l’histoire du mode ui ne changera jamais le comportement de ton système que je ne suis pas sûr 
Voici les 3 modes que j’ai dans l’application Zendure (ZENKI, automatique ou Expert) :
et en mode expert, j’ai ensuite :
ChatGPT me conseille de passer sur le mode « Charge de base » parce que c’est le plus « bête » et que comme ça, Zendure ne viendra pas en conflit avec HA, tu valides ?
5. Automatisations
Au final, pas besoin d’automatisation puisque l’intégration se base directement sur le capteur grid_power_net_zendure et que je reste en mode « Couplage », on est bien d’accord ?
PS : Je suis conscient qu’utiliser les 3 pinces du Shelly ne fonctionne pas correctement avec l’application Zendure, je verrai peut-être plus tard pour acheter un autre shelly si je vois que ça pose vraiment trop de problème. Pour le moment, je vais rester ainsi 
En tout cas, grand grand merci de ton aide et de ta patience avec quelqu’un qui ne comprend pas tout encore 
C’est nickel, t’as tout géré comme il faut (merci ChatGPT, je reconnais bien le style 
)
Charge de base oui c’est bien, avec aucun programme renseigné. Mais normalement quand tu le sors du HEMS plus rien ne le contrôle côté app Zendure, c’est juste pour éviter les soucis en cas de bug, et les surprises le jour où tu repasses sur l’app Zendure pour une raison X ou Y.
Et oui, a priori pour le besoin que tu as décrit, pas besoin d’automatisation. A voir si ça marche vraiment bien, en théorie oui mais c’est pas dit qu’en pratique ça fasse des trucs un peu bizarres, on est jamais sûrs. Je t’invite à te faire un tableau de bord complet avec toutes les infos importantes pour surveiller de visu : la pince Shelly, ton capteur perso, l’état du manager, la puissance renvoyée, etc…
Edit: une autre solution aurait été d’avoir une automatisation qui détecte quand ta conso est > 350W et qui passe le Hyper en “arrêt” ou qui le relance quand la conso est inférieure pendant X sec. Ca peut être une piste à explorer si le Hyper s’arrête et se relance comme un bourrin quand ta conso est proche des 350W.
OK parfait, je te remercie encore pour ton aide super appréciée !!
Je vais tester tout ça rapidement et reviendrais pour tout détailler (ça pourrait aider les personnes dans le même cas )
C’est vrai que ce n’est pas évident au début de tout comprendre (lien entre application Zendure, intégration Fireson, la gestion via Zendure manager, etc…).
Et l’intégration manque cruellement d’une doc…
Grand merci encore !
PS : si problème il y a avec HA, je pourrais toujours repasser en HEMS dans l’appli et virer les tores autres que celle du réseau (c’est relou mais possible tout de même). Il faudrait vraiment que Zendure améliore la prise en charge du Shelly, c’est un peu trop léger leur support
Edit: une autre solution aurait été d’avoir une automatisation qui détecte quand ta conso est > 350W et qui passe le Hyper en “arrêt” ou qui le relance quand la conso est inférieure pendant X sec. Ca peut être une piste à explorer si le Hyper s’arrête et se relance comme un bourrin quand ta conso est proche des 350W.
Oui, c’est ce que m’avait dit de faire ChatGPT.
Le tout avec une temporisation de 20s.
Un truc un peu comme ça :
alias: Zendure – Gestion intelligente batterie
mode: restart
trigger:
- platform: state
entity_id:
- sensor.grid_power_net
- sensor.hyper_2000_soc_status
for: "00:00:30" # anti-oscillation (nuages, pics courts)
action:
- choose:
# --------------------------------------------------
# 1️⃣ PROTECTION BATTERIE (PRIORITÉ ABSOLUE)
# --------------------------------------------------
- conditions:
- condition: or
conditions:
- condition: numeric_state
entity_id: sensor.hyper_2000_soc_status
below: 20
- condition: numeric_state
entity_id: sensor.hyper_2000_soc_status
above: 95
sequence:
- service: select.select_option
target:
entity_id: select.zendure_manager_mode
data:
option: "Arrêt"
# --------------------------------------------------
# 2️⃣ CHARGE BATTERIE (SURPLUS SOLAIRE)
# --------------------------------------------------
- conditions:
- condition: numeric_state
entity_id: sensor.grid_power_net
below: 0
- condition: numeric_state
entity_id: sensor.hyper_2000_soc_status
below: 95
sequence:
- service: select.select_option
target:
entity_id: select.zendure_manager_mode
data:
option: "Charge intelligente"
# --------------------------------------------------
# 3️⃣ DÉCHARGE BATTERIE (BRUIT DE FOND < 350 W)
# --------------------------------------------------
- conditions:
- condition: numeric_state
entity_id: sensor.grid_power_net
above: 0
below: 350
- condition: numeric_state
entity_id: sensor.hyper_2000_soc_status
above: 20
sequence:
- service: number.set_value
target:
entity_id: number.zendure_manager_manual_power
data:
value: 350
- service: select.select_option
target:
entity_id: select.zendure_manager_mode
data:
option: "Puissance manuelle"
# --------------------------------------------------
# 4️⃣ PAR DÉFAUT → ARRÊT
# --------------------------------------------------
default:
- service: select.select_option
target:
entity_id: select.zendure_manager_mode
data:
option: "Arrêt"
C’est overkill, et a priori t’as pas besoin d’un mode manuel, ça tu peux le faire toi-même en mettant le mode du manager et la puissance manuelle dans ton dashboard. Pareil pour le niveau du SOC, l’intégration le respectera mieux que n’importe quelle automatisation, ça sert à rien.
Le seul intérêt de l’automatisation par rapport au capteur virtuel c’est que tu peux mettre de la temporisation, soit toutes les 20s comme tu disais soit tu peux lui dire “tu te mets en off si la puissance demandée dépasse les 350W pendant 10s”, ce qui est plus souple que via le système de capteur. Mais en soit l’intégration ne fait pas des aller-retours à tire larigot, elle est souple elle aussi.
Je te conseille de démarrer avec le capteur virtuel, et si tu constates des comportements erratiques ou pas très logiques, de basculer sur l’automatisation en remettant le capteur Shelly de base.
Edit: en plus cette automatisation force l’envoi de 350W nets quand la demande est inférieure à 350W, ce qui fait que si ta maison consomme 200W :
Si j’étais dans ta situation et que je voulais une automatisation, ça serait beaucoup plus simple:
Ca demande de calculer la conso de la maison “seule” sans ce qui est actuellement injecté depuis le Hyper.
D’ailleurs je me rends compte que ce que je t’ai suggéré ne va pas fonctionner pour la même raison qu’au-dessus: la conso mesurée sur la pince Enedis (avec ou sans le capteur virtuel) inclut l’injection du Hyper… Donc en fait dans le capteur il faut prendre la mesure d’Enedis moins ce qu’injecte le Hyper pour avoir la vraie conso de la maison.
Il faut donc laisser tomber la technique du capteur virtuel et plutôt partir sur une automatisation. Mais pour calculer le seuil des 350W il faut prendre la conso Enedis, moins ce qu’injecte le Hyper dans la maison (ce qui peut être 0). Normalement dans l’intégration au niveau du Hyper tu as un sensor qui indique combien le Hyper décharge (en tout cas je l’ai pour mon SF2400AC).
Pourquoi ne pas reprendre simplement l’idée des scripts plus haut avec un seul automatisme qui gère le passage en mode charge ou décharge intelligente (et arrêt si tu veux) selon ses propres seuils. Je fais ça (même si pour moi c’est pour à l’inverse ne décharger que quand ma conso devient importante, p.ex >350W) et ça marche nickel.
Oui j’ai pareil avec mon hyper 2000 + panneaux (et pas avec mon flow 800 sans panneaux). C’est côté firmware pour éviter les fortes décharges. Mais à mon sens a été implémenté vite fait par Zendure, charger 1h à 30w ça sert pas à grand chose…
Salut crick3100,
Tu pourrais me faire passer ton automatisme ou me donner le lien des scripts (ce sujet contient énormément de messages 
) ?
Sinon, j’ai testé l’idée du capteur Zendure en me basant sur celui du Shelly… Ce n’est pas ce que je recherche malheureusement 
Parce que si on se base sur la conso réseau et que la batterie est en décharge, on est souvent quasiment à 0 du coup sur le capteur Shelly et le capteur Zendure ne fonctionne pas comme il faut.
A noter aussi que la limite des 350W tirés sur la batterie ne fonctionne pas (le minimum étant de 600W, comme pas de puissance manuelle, il tire la max donc ça draine la batterie).
Actuellement je pense que ça pourrait fonctionner dans le cas où la batterie délivre ses 600W de puissance en sortie et qu’on consomme en plus du réseau 350W soit 950W au final.
Il faut que je creuse une autre solution (un peu ce que tu dis, un seul automatisme qui gère le passage en mode charge ou décharge intelligente avec gestion manuelle de la puissance voire arrêt si SOC trop bas ou batterie chargée…).
Un truc dans ce style (généré par chatGPT donc à vérifier et améliorer) :
alias: Zendure – Gestion intelligente batterie
mode: restart
trigger:
- platform: state
entity_id:
- sensor.grid_power_net
- sensor.hyper_2000_soc_status
for: "00:00:30" # anti-oscillation (nuages, pics courts)
action:
- choose:
# --------------------------------------------------
# 1️⃣ PROTECTION BATTERIE (PRIORITÉ ABSOLUE)
# --------------------------------------------------
- conditions:
- condition: or
conditions:
- condition: numeric_state
entity_id: sensor.hyper_2000_soc_status
below: 20
- condition: numeric_state
entity_id: sensor.hyper_2000_soc_status
above: 95
sequence:
- service: select.select_option
target:
entity_id: select.zendure_manager_mode
data:
option: "Arrêt"
# --------------------------------------------------
# 2️⃣ CHARGE BATTERIE (SURPLUS SOLAIRE)
# --------------------------------------------------
- conditions:
- condition: numeric_state
entity_id: sensor.grid_power_net
below: 0
- condition: numeric_state
entity_id: sensor.hyper_2000_soc_status
below: 95
sequence:
- service: select.select_option
target:
entity_id: select.zendure_manager_mode
data:
option: "Charge intelligente"
# --------------------------------------------------
# 3️⃣ DÉCHARGE BATTERIE (BRUIT DE FOND < 350 W)
# --------------------------------------------------
- conditions:
- condition: numeric_state
entity_id: sensor.grid_power_net
above: 0
below: 350
- condition: numeric_state
entity_id: sensor.hyper_2000_soc_status
above: 20
sequence:
- service: number.set_value
target:
entity_id: number.zendure_manager_manual_power
data:
value: 350
- service: select.select_option
target:
entity_id: select.zendure_manager_mode
data:
option: "Puissance manuelle"
# --------------------------------------------------
# 4️⃣ PAR DÉFAUT → ARRÊT
# --------------------------------------------------
default:
- service: select.select_option
target:
entity_id: select.zendure_manager_mode
data:
option: "Arrêt"
N’hésites pas à fournir ton script
Merci par avance !
Salut Garfunk,
Oui je me suis rendu compte de ça aussi.
Comme je l’indique dans un autre post, actuellement, ça pourrait fonctionner dans le cas où la batterie délivre ses 600W de puissance en sortie (le minimum que j’ai pu configurer) et qu’on consomme en plus 350W du réseau soit 950W au final.
Du coup, ça draine trop la batterie.
Je vais réfléchir à trouver une autre solution :
A réfléchir donc… 
Mais merci encore parce que tu m’as permis d’y voir un peu plus clair dans tout ça (pas simple, beaucoup de choses à prendre en compte, une intégration que je ne maîtrise pas encore, etc…)
Oui elle existe aussi pour l’hyper 2000 :
Je vais tester rapidement en soustrayant la puissance de la batterie à la puissance réseau voir ce que ça donne
EDIT : ça ne le fera pas le capteur virtuel, la batterie délivre 600W en sortie minimum donc dans tous les cas, ça la videra trop vite. Je continue de méditer sur le sujet mais je penche de plus en plus pour une automatisation avec puissance manuelle
EDIT 2 : normal qu’en mode Arrêt la batterie continue de se décharger à 350W ??? Ce mode n’est pas censé mettre la batterie en OFF / veille ?
Et tu n’as pas l’effet de feedback loop que je décris ? Parce que l’arrivée Enedis inclut ce que la batterie envoie dans le système, donc c’est le meilleur moyen d’entrer dans un cercle vicieux
Euh non le mode OFF coupe tout normalement ?
Salut @Olivi38 ,
Le voici ci-dessous avec des entités à la place de seuils en durs pour pouvoir jouer avec eux et changer sans modifier le script idée de @Georambo .
Pour les limites de SOC je crois que tu te complique la vie. Il suffit juste de les paramétrer dans la config de ton hyper. En gros moi j’ai un reglage hiver (22%-100%) et un reglage été (10%-95%). Je joue un peu avec les prévision solaires en hiver pour descendre un peu le soc min si je vois que demain il annonce une bonne production.
Pour la légende:
Pour ta logique de ne consommer que ton bruit de fond (ce que je ne recommande pas au vu des rendements de conversion médiocre sous 300w), il te suffit d’inverser les above et below, ou d’inverser les id forte et faible conso.
Un conseil utile qu’on m’a donné, alterne entre l’éditeur YAML et l’éditeur visuel pour mieux comprendre l’automatisme.
amuse-toi bien
alias: my Zendure – Optimisation rendement batterie (stable)
description: |
Gestion intelligente Zendure :
- priorité maison
- surplus → batterie
- export en dernier
- décisions stables ≥ 10 s
triggers:
- trigger: numeric_state
entity_id: sensor.shellypro3em_puissance
above: input_number.parc_zendure_seuil_de_conso
for: "00:00:10"
id: forte_conso
- trigger: numeric_state
entity_id: sensor.shellypro3em_puissance
below: input_number.parc_zendure_seuil_de_conso
for: "00:00:10"
id: faible_conso
- trigger: numeric_state
entity_id: sensor.parc_zendure_sortie
below: input_number.parc_zendure_seuil_decharge
for: "00:00:10"
id: decharge_trop_faible
actions:
- choose:
- conditions:
- condition: trigger
id: forte_conso
sequence:
- condition: or
conditions:
- condition: numeric_state
entity_id: sensor.shellypro3em_puissance
above: input_number.parc_zendure_seuil_de_conso
- condition: numeric_state
entity_id: sensor.parc_zendure_sortie
above: input_number.parc_zendure_seuil_decharge
- device_id: 31d5f701f752f5d6e647f89d16220ebc
domain: select
entity_id: f9772471491021a0df56a15a96259bbe
type: select_option
option: smart_discharging
- conditions:
- condition: or
conditions:
- condition: trigger
id: faible_conso
- condition: trigger
id: decharge_trop_faible
sequence:
- condition: and
conditions:
- condition: numeric_state
entity_id: sensor.shellypro3em_puissance
below: input_number.parc_zendure_seuil_de_conso
- condition: numeric_state
entity_id: sensor.parc_zendure_sortie
below: input_number.parc_zendure_seuil_decharge
- device_id: 31d5f701f752f5d6e647f89d16220ebc
domain: select
entity_id: f9772471491021a0df56a15a96259bbe
type: select_option
option: smart_charging
mode: single
Pas avec mon automatisme ci-dessus. le delai de 10s et l’hystérésis de 400w EDF - 300W sortie batterie l’empêche.
Vraiment bizarre, j’ai déjà eu mes batteries à 4% au réveil (alors que la limite basse est à 10%) et pourtant elles ont bien attendu que j’ai suffisamment de production pour charger. J’ai jamais vu mes batteries charger en tirant sur le réseau en mode couplage intelligent.
Edit: tu as un SF800 et tes panneaux sont branchés dessus j’imagine ? Alors là le comportement est peut-être différent, je saurais pas te dire. Peut-être qu’effectivement la priorité est donnée à la batterie au lieu du réseau…
Je reviens sur le sujet avec un exemple, voici typiquement un cas où la recharge ne se fait pas :
Peut être que je suis trop tatillon
Bonjour à tous,
Comme je vois que ça intéresse certains d’améliorer le rendement des leurs batteries et de jouer avec les entités des seuils de déclenchements pour parfaire les réglages à chaud au lieu de modifier l’automatisme, voici le script YAML (un peu plus long à mettre en œuvre que mon automatisme avec des valeurs fixes que je vous avais précédemment partagé) :
alias: SolarFlow 2400 – Optimisation batterie réglable
description: |
Pilotage intelligent du SolarFlow avec seuils réglables et arrêt logique.
triggers:
- entity_id:
- sensor.c_injection_soutirage_power
- sensor.puissance_d_entree_de_la_batterie
- sensor.puissance_de_sortie_de_la_batterie
- input_number.sf_seuil_decharge
- input_number.sf_seuil_charge
- input_number.sf_seuil_batterie_active
- input_number.sf_seuil_charge_entree
trigger: state
actions:
- choose:
- conditions:
- condition: or
conditions:
- condition: numeric_state
entity_id: sensor.c_injection_soutirage_power
below: input_number.sf_seuil_charge
- condition: numeric_state
entity_id: sensor.puissance_d_entree_de_la_batterie
above: input_number.sf_seuil_charge_entree
sequence:
- device_id: c9252b0605d069db79233ab92bc39ebb
domain: select
entity_id: 9f67adf91e7c67290e1e9fc97f605383
type: select_option
option: smart_charging
- delay:
hours: 0
minutes: 0
seconds: 15
milliseconds: 0
- conditions:
- condition: or
conditions:
- condition: numeric_state
entity_id: sensor.c_injection_soutirage_power
above: input_number.sf_seuil_decharge
- condition: numeric_state
entity_id: sensor.puissance_de_sortie_de_la_batterie
above: input_number.sf_seuil_decharge
- condition: not
conditions:
- condition: numeric_state
entity_id: sensor.solarflow_2400_ac_electric_level
below: 11
sequence:
- device_id: c9252b0605d069db79233ab92bc39ebb
domain: select
entity_id: 9f67adf91e7c67290e1e9fc97f605383
type: select_option
option: smart_discharging
- delay:
hours: 0
minutes: 0
seconds: 15
milliseconds: 0
- conditions:
- condition: or
conditions:
- condition: and
conditions:
- condition: numeric_state
entity_id: sensor.solarflow_2400_ac_electric_level
below: 11
- condition: numeric_state
entity_id: sensor.shellyproem50_08f9e0e89e74_em0_power
below: 10
- condition: or
conditions:
- condition: numeric_state
entity_id: sensor.puissance_d_entree_de_la_batterie
below: input_number.sf_seuil_batterie_active
- condition: numeric_state
entity_id: sensor.puissance_de_sortie_de_la_batterie
below: input_number.sf_seuil_batterie_active
enabled: true
sequence:
- device_id: c9252b0605d069db79233ab92bc39ebb
domain: select
entity_id: 9f67adf91e7c67290e1e9fc97f605383
type: select_option
option: "off"
mode: single
Pour que l’automatisme fonctionne avec des seuils réglables il faut créer des entrées :
SF Seuil Décharge : input_number.sf_seuil_decharge
SF Seuil Charge : input_number.sf_seuil_charge (fonctionne avec l’entité d’un Shelly dans l’automatisme avec des valeurs positives et négatives)
SF Seuil Charge Entrée : input_number.sf_seuil_charge_entree (fonctionne avec l’entité du SolarFlow 2400 dans l’automatisme avec des valeurs toujours positives)
En principe ces deux seuils de charge ont la même valeur, mais j’ai dû faire deux entrées distinctes pour des problèmes de logique de fonctionnement dans l’automatisme avec des valeurs toujours +/- pour un seuil et des valeurs toujours positives pour l’autre.
SF seuil batterie active : input_number.sf_seuil_batterie_active
Pour régler à chaud ces seuils il faut créer une barre horizontale de Bubble Card (en haut à droite de mon dashboard ci-dessous) :
type: horizontal-stack
cards:
- type: custom:bubble-card
show_state: true
show_attribute: false
show_last_changed: false
force_icon: false
sub_button:
main: []
bottom: []
show_icon: false
scrolling_effect: false
card_layout: large
icon: ""
name: Seuil décharge
button_type: slider
styles: |-
.bubble-button-card-container {
border-radius: 0 0 0 0 !important;
}
attribute: friendly_name
show_name: true
card_type: button
entity: input_number.sf_seuil_decharge
- type: custom:bubble-card
show_state: true
show_attribute: false
show_last_changed: false
force_icon: false
sub_button: []
show_icon: false
scrolling_effect: false
card_layout: large
icon: ""
name: Seuil charge
button_type: slider
styles: |-
.bubble-button-card-container {
border-radius: 32px 0 0 32px !important;
}
attribute: friendly_name
show_name: true
card_type: button
entity: input_number.sf_seuil_charge
- type: custom:bubble-card
show_state: true
show_attribute: false
show_last_changed: false
force_icon: false
sub_button: []
show_icon: false
scrolling_effect: false
card_layout: large
icon: ""
name: Seuil entrée
button_type: slider
styles: |-
.bubble-button-card-container {
border-radius: 32px 0 0 32px !important;
}
attribute: friendly_name
show_name: true
card_type: button
entity: input_number.sf_seuil_charge_entree
- type: custom:bubble-card
show_state: true
show_attribute: false
show_last_changed: false
force_icon: false
sub_button: []
show_icon: false
scrolling_effect: false
card_layout: large
icon: ""
name: Seuil d'activité
button_type: slider
styles: |-
.bubble-button-card-container {
border-radius: 0 32px 32px 0 !important;
}
attribute: friendly_name
show_name: true
card_type: button
entity: input_number.sf_seuil_batterie_active
grid_options:
columns: 12
rows: 1
Voici une vue de mon dashboard « Batterie SolarFlow 2400 AC » :
Il ne me reste plus qu’à vous souhaiter bon courage pour adapter ça à votre configuration
