Bonjour a tous
Vous alllez me dire qu il n y a pas de question bête
Mais je ne trouve pas la réponse
Je viens d acquérir un 2 eme hyper 2000 qui est bien dans mon application Zendure
Sous home assistant je vois bien les 4 batteries « 2 batteries pour chaque hyper «
Par contre je vois un seul hyper 2000
Est ce normal ?
Un seul est piloté
L autre rien à faire il reste en veille
Hello Julien, yes malheureusement ils sont déjà bien configurés sur ce paramètre et j’en ai testé d’autres sans succès.
Bonjour à toutes et à tous,
J’ai 2 hypers avec chacun 2 AB2000S, tous les deux sont bien reconnus et fonctionnent bien sous Zendure Home Assistant Integration en local et avec un Shelly Pro 3EM..
Mon souci se situe au niveau du couplage intelligent.
Si je passe en couplage intelligent depuis un autre mode (Arret par exemple) un seul des 2 hypers se décharge tant que la demande en énergie ne dépasse pas les 1200w. Si la demande en énergie dépasse les 1200w durant une petite minute alors les 2 hyper se déchargent et la décharge se répartie entre les 2 hyper.
Ex :
Activation du mode « Couplage Intelligent »
Conso maison de 350W => 1 seul hyper se décharge à 350W
Conso maison passe à 2100W (micro onde) => les 2 hyper déchargent à 1050W
Quand la conso de la maison redescend à 350W alors chacun des 2 hypers se décharge à 175W
Ce comportement est-il normal ou bien s’agit-il d’un bug ?
Je m’attendais à ce que la décharge se répartisse les deux hypers dès le passage sur « Couplage Intelligent ».
Bonne fin de journée
Salut Pr0d1G3
Tu as fait quelquechose de speciale pour mettre tes 2 hypers dans l integration?
Pour ma part rien a faire un seul de visible et l autre reste en veille
Si quelqu un a une idée
Merci d avance
Je n’ai rien fait de spécial.
Il faut juste que dans l’application Zendure les deux Hypers ne soit pas en cluster, ensuite NE PLUS UTILISER l’appli Zendure.
Dans l’intégration de Home Assistant les deux Hypers doivent avoir pour réglage dans [Groupe de fusibles] > « L’appareil a son propre circuit ».
Après avoir ajouté le deuxième hyper, as tu refait la configuration de l’intégration ?
Je pense que ça doit être nécessaire pour que l’intégration récupère la liste des appareils.
Les 2 hypers ne sont pas en cluster
Oui j ai bien refait la configuration de l integration
Je vais tout refaire je pense
Tes 2 hypers ont été acheter en meme temps ?
Pour ma part 1 hyper est de novembre 2024 et l autre de ce mois
Il y a des ses differences en firmware pourtant ils sont a jour
Peut être que le problème vient de la
Non non, pas acheté en même temps et en plus Z>endure vient de m’en changer un car il était HS
Bonjour à tous,
Tout nouveau sur le forum, mais fervent utilisateur de tous ses précieux conseils et infos depuis plus d’un an !
Merci ++ @Georambo pour tes recherches et ton script d’optim que j’ai repris et qui a l’air de bien fonctionner chez moi aussi. Effectivement, je partage ton point de vue sur le fait que laisser le smart gérer sans limites de charge et décharge peut énormément diminuer la rentabilité des investissements tant en termes de conso que de longévité des batteries.
Pour ma part j’ai :
Quelques remarques toutefois sur les contraintes firmware de zendure, j’ai noté/compris que le matin lorsque les batteries de l’hyper sont à leur SOC min (30% dans mon cas), le firmware force la charge de ses batteries via le solaire, une sorte de patch pour être sûr de faire remonter les batteries au dessus du SOc min.
Du coup malgré ton script, ça charge 30 min tous les matins de 1w à 60w environ 
puis ça reprend un mode normal selon ton script.
Bonjour,
En fait j’ai fait évoluer mon automatisme après plusieurs jours d’utilisation. J’ai commencé par mettre une temporisation de 10 s une fois le mode activé, car la montée en puissance met du temps et commence par un petit 60 w pendant environ 5 secondes avant d’utiliser la totalité de la puissance injectée détectée. S’il n’y a pas cette temporisation, l’automatisme recommence un cycle immédiatement et constate par exemple une puissance de charge inférieure aux paramètres choisis et arrête la charge.
Je viens de modifier l’automatisme que j’avais partagé pour y intégrer ces modifications de temporisation qui le rendent plus stable, avec des valeurs de puissances d’injection et d’entrées-sorties batterie figées dans l’automatisme (pour les changer il faut modifier l’automatisme). Si tu le télécharges ça devrait régler tes problèmes.
Mais j’ai encore fait évoluer cet automatisme, qui fonctionne maintenant avec des valeurs modifiables dans des Entrées (Helpers) accessibles dans mon Dashboard Batterie sous forme d’une barre Bubble Card.
Si tu le souhaites je peux partager cet automatisme final qui fonctionne maintenant dans toutes les situations grâce aux temporisations et que je peux modifier à chaud en observant les réactions de la batterie sur la carte de mon Dashboard « Power Flow Card Plus ». C’est un peut plus long à faire, mais cela permet d’affiner ses réglages en fonction de son installation et de ses priorités du jour (par exemple privilégier la recharge au détriment du rendement de la batterie, un jour où il y a des passages nuageux).
Voici ce que donne mon Dashboard batterie, les entrées réglables de l’automatisme sont réunies dans la Bubble Card en haut à droite (valeurs réglées suivant conditions météo très nuageuses) :
Hello,
Je viens d’avoir une nouvelle fois le cas mais sur mon autre batterie. Je l’ai simplement éteinte et débranché/rebranché et c’est rentré dans l’ordre. Du coup je me pose la question de mettre une prise connectée sur la batterie pour l’éteindre et la rallumer en espérant que ça force la reconnexion, plutôt que d’éteindre la box car ça m’ennuie un peu.
Un avis ?
hello,
j’ai eu le même problème hier, j’ai dû réinitialisé le wifi sur une des deux hyper2000 pour qu’elle se reconnecte.
Super, bonne idée les entités pour jouer avec sans changer l’automatisme. J’ai une petite idée de comment le faire mais ma faignantise me pousse à dire que je veux bien ton script final 
Edit: finalement je l’ai fait moi-même 
Juste quelques remarques / questions:
1- Dans ton code quelle est la différence entre ton entité injection/export et le shelly pro em50 que tu as rajouté à la fin ? Ce n’est pas dans tous les cas pour avoir l’import/Export EDF ?
2- Dans mon cas (Hyper2000 + flow 800 plus) j’ai créé des entités pour les gérer ensemble (pourcentage, entrées, sorties pour tout le parc) par contre lors de situations de retour à “off” le solar flow 800 plus garde les dernières valeurs et d’entrée et de sortie imposées par le smart charge ou decharge (contrôle zenSDK ??). Résultat il peut continuer à charger ou décharger malgré tout → J’ai ajouté quelques lignes pour forcer le retour à zero de ces valeurs lors du passage en “off”.
3- Est-ce que toi (ou d’autres personnes) observez le comportement décris plus haut, à savoir une charge faible le matin quand on est au SoC min quel que soit le mode ? Ce n’est que pour le hyper (relié aux panneaux), pas pour le flow 800 sur AC seulement.
Bonjour,
1 - les entités sont :
soutirage et injection réseau : sensor.c_injection_soutirage_power
puissance d’entrée batterie : sensor.puissance_d_entree_de_la_batterie
puissance de sortie batterie : sensor.puissance_de_sortie_de_la_batterie
production solaire : sensor.shellyproem50_08f9e0e89e74_em0_power
appareil Zendure Manager : c9252b0605d069db79233ab92bc39ebb
entité de choix du mode de fonctionnement : 9f67adf91e7c67290e1e9fc97f605383
Pour mieux comprendre je te conseille de regarder l’automatisme en mode UI et non en mode YAML.
2 et 3 - Moi j’ai un Solarflow 2400 AC et je n’observe pas ce comportement. Par contre as-tu téléchargé l’automatisme que j’ai modifié dans mon premier post, avec les temporisations pour éviter les recharges à 60 w le matin (mais sans les entrées modifiables à chaud dans un tableau de bord car un peu trop complexe à partager) ? Si tu ne l’as pas encore fait le voici :
alias: Zendure SolarFlow – Optimisation rendement batterie
description: >
Active Charge/Décharge intelligente uniquement au-dessus des seuils de
rendement (>90 %) et maintient l'état grâce aux puissances batterie.
triggers:
- entity_id:
- sensor.c_injection_soutirage_power
- sensor.puissance_d_entree_de_la_batterie
- sensor.puissance_de_sortie_de_la_batterie
trigger: state
actions:
- choose:
- conditions:
- condition: or
conditions:
- condition: numeric_state
entity_id: sensor.c_injection_soutirage_power
below: -450
- condition: numeric_state
entity_id: sensor.puissance_d_entree_de_la_batterie
above: 450
sequence:
- device_id: c9252b0605d069db79233ab92bc39ebb
domain: select
entity_id: 9f67adf91e7c67290e1e9fc97f605383
type: select_option
option: smart_charging
- delay:
hours: 0
minutes: 0
seconds: 10
milliseconds: 0
- conditions:
- condition: or
conditions:
- condition: numeric_state
entity_id: sensor.c_injection_soutirage_power
above: 330
- condition: numeric_state
entity_id: sensor.puissance_de_sortie_de_la_batterie
above: 330
- 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: 10
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: 100
- condition: numeric_state
entity_id: sensor.puissance_de_sortie_de_la_batterie
below: 100
sequence:
- device_id: c9252b0605d069db79233ab92bc39ebb
domain: select
entity_id: 9f67adf91e7c67290e1e9fc97f605383
type: select_option
option: "off"
mode: single
Bonjour à tous
Pour info
Mon problème est résolu
Mon 2eme hyper ne se connectait pas a mon esp32 proxy mais a mes shelly qui gravitent autour se qui provoquait le problème
Maintenant la connection est rétabli et mes 2 hypers sont visibles dans l intégration .
Merci j’avance. Il me manquait le fait de tenir compte de la prod solaire.
Par contre dans ton cas 3, si tes conditions sont vraies alors tu as sequence: [ ]
Mais du coup il n’y a pas d’action ? c’est juste pour garder le dernier état ?
Oups, j’avais oublié l’action, … C’était pour voir si tu suivais 
En fait j’ai refait l’automatisme avec les valeurs fixes en vitesse en oubliant la fin. En ce moment l’automatisme tourne correctement mais il n’a pas fait l’action finale : arrêter la batterie. J’ai donc complété l’automatisme tu peux le télécharger.
Dans l’option 3 la batterie s’arrête quand il n’y a plus de production solaire et que le niveau de batterie est inférieur à 11 (pour un SOC 10%), ou bien quand dans la journée la puissance d’entrée ou de sortie de la batterie est inférieure à 100 W.
Tout le monde a besoin de se reposer même la batterie 
En fait je me suis aperçu que ça réinitialise la batterie quand elle a un bug.
Bonjour à tous,
Je sais qu’il y a une perte entre la charge et décharge, mais là je trouve ça quand même énorme vous pensez que c’est normal? On est pas loin des 25% quand même 
.
La journée le zendure management est en couplage intelligent.
Ouaip, c’est plus ou moins correct en effet. Il y a beaucoup de pertes pour la conversion et quand tu charges puis décharges c’est double peine. Tu peux voir la différence entre ce qui est injecté dans le Solarflow (c’est la valeur visible ici) et ce qui atteint réellement les batterie (tu as des capteurs dans HA), tu verras qu’il y a en moyenne 50W de différence.
Quand tu charges ou décharges 200W, c’est en réalité 250W qui sortent de ta batterie (ou 150W qui y rentrent). Sur des petites valeurs, ça fait un gros delta. Sur des grosses valeurs, 2000W par exemple, ça représente pas grand chose.
C’est ça que @Georambo essaye d’éviter avec son couplage intelligent maison en ne chargeant ou déchargeant que quand la puissance demandée est suffisante, si je ne dis pas de bêtise ?
hello,
Ben c’est justement le sujet des échanges ci-dessus avec @Georambo . Si tu laisses faire le couplage intelligent il y a beaucoup de charges et décharges à faibles puissances avec des rendements <50%.Et aussi on voit que le couplage à pas mal oscillé et que tu as “perdu” persque 1Kwh vers le réseau.
Avec les premiers essais de son automatisme d’optimisation ci-dessus (et par temps pourri pour l’instant) j’arrive déjà à 90% de rendement et 99% d’énergie solaire autoconsommée.
@Georambo merci pour la précision.
Le problème du mode ‘off’ que j’observe chez moi, c’est qu’il ne met pas la batterie en arrêt vraiment. S’il y a du solaire alors elle se charge et au final, je pense que garder le mode smart charge est toujours mieux que de balancer sur le réseau car il me semble que le transfert PV en DC vers batterie en DC a un meilleur rendement que le PV en DC vers réseau en AC.
Pire, avec le solar flow 800 en mode ZenSDK, la dernière valeur entée/sortie AC configurée par le dernier mode smart reste et est utilisée en off. Ce qui peut conduite à une décharge ou charge selon le cas.
Pour un vrai off, Il faudrait pouvoir manipuler le mode bypass, ce que je ne vois pas dans mon intégration.
Aussi, pourquoi ajouter cette limite de Soc à 11% alors qu’il y a dejà des limites min et max des SOC de chaque batterie dans l’intégration qui arrête toute décharge ?
Merci
