Pour essayer de remplacer le mode intelligent et gérer les charges, regarde le post de @Julien_Galliot ci-dessous.
Après le tuto, il donne les automatisations qu’il utilise.
Pour ma part j’ai codé ce script :
script:
zendure1_gestion:
description: "Ce script à pour but de déterminer la puissance que le zendure doit sortir pour maximiser l'utilisation du ballon d'eau chaude."
sequence:
- action: number.set_value
metadata: {}
data:
value: >-
{# # Contraintes :
# la puissances minimale pouvant sortir du zendure est de 30W
# la batterie doit être à sa charge minimale avant d'envoyer dans la maison
# On injecte toute l'énergie dans le ballon jusqu'à la moitié de sa capacité
# une fois la moitié de l'énergie injecté on commence à rediriger vers la batterie
# ne jamais injecté plus de puissance que ce que consomme la maison #}
{# # Données nécessaires au fonctionnement :
# énergie injecté dans le ballon d'eau chaude #}
{% set ballon_energie = states('sensor.cave_1_energie') | float(0) %}
{% set ballon_capacite = 9 %}
{% set ballon_facteur = 0.8 %}
{# # niveau de la batterie #}
{% set batterie_niveau = states('sensor.zendure1_niveau_batterie') | int(50) %}
{% set batterie_min = states('number.zendure1_charge_mini') | int(20) %}
{# # puissance solaire #}
{% set solaire_puissance = states('sensor.zendure1_pv_puissance') | int(0) %}
{# # puissance consommée, à pleine puissance (1000W) le talon de consommation représente environs 10% #}
{% set consommation_puissance = states('sensor.puissance_mini') | int(0) %}
{% set consommation_min = 10 %}
{# # zendure #}
{% set zendure_puissance_marge = 150 %}
{% set zendure_conso_onduleur = 30 %}
{% set zendure_puissance_sortie = states('number.zendure1_puissance_decharge') | int(0) %}
{% set zendure_puissance_sortie_min = 50 %}
{% set zendure_puissance_sortie_max = states('sensor.zendure1_puissance_sortante_max') | int(1200) %}
{% set zendure_puissance_sortie_limite = zendure_puissance_sortie + consommation_puissance - zendure_puissance_marge %}
{# # on restreint la puissance de sortie limite
# elle ne doit pas être inférieure à 0, ni supérieure à la sortie max ou la puissance solaire
# si elle set inférieure à 0 #}
{% if zendure_puissance_sortie_limite < 0 %}
{% set zendure_puissance_sortie_limite = 0 %}
{# # si elle dépasse la puissance solaire #}
{% elif zendure_puissance_sortie_limite > solaire_puissance %}
{% set zendure_puissance_sortie_limite = solaire_puissance - zendure_conso_onduleur %}
{# # si elle est supérieure à max #}
{% elif zendure_puissance_sortie_limite > zendure_puissance_sortie_max %}
{% set zendure_puissance_sortie_limite = zendure_puissance_sortie_max %}
{% endif %}
{# # on calcule l'équation d'une droite de pente négative pour diminuer progressivement la puissance
# envoyé à la maison au fur et à mesure qu'on se rapproche de la capacité du ballon #}
{% set a = (100 - consommation_min)/(ballon_capacite * (0.5-ballon_facteur)) %}
{% set b = 100 - a * ballon_capacite/2 %}
{% set y = a * ballon_energie + b %}
{% set puissance = solaire_puissance * y/100 %}
{# # comme précédemment on limite cette nouvelle puissance #}
{% if puissance < 0 %}
{% set puissance = 0 %}
{% elif puissance > zendure_puissance_sortie_limite %}
{% set puissance = zendure_puissance_sortie_limite %}
{% endif %}
{# # Si la puissance solaire est inférieure au minimum, ou que la batterie n'est pas à son minimum #}
{% if solaire_puissance < zendure_puissance_sortie_min or batterie_niveau < batterie_min %}
0
{# # Si on a pas encore chauffé la moitié du ballon on envoie la puissance limite #}
{% elif ballon_energie < (ballon_capacite/2) %}
{{zendure_puissance_sortie_limite}}
{# # Si on arrive ici alors on envoie la fraction de puissance calculée précédemment #}
{% else %}
{{puissance}}
{% endif %}
target:
entity_id: number.zendure1_puissance_decharge
icon: mdi:home-battery-outline
En ce qui concerne le mode du zendure j’ai utilisé ceci dans la liste des entitées MQTT :
- switch:
- name: "Mode"
unique_id: "zendure1_mode"
object_id: "zendure1_mode"
state_topic: "adresse_du_topic/control/acMode"
command_topic: "adresse_du_topic/control/acMode/set"
device_class: "switch"
value_template: "{{ value }}"
payload_off: "1"
payload_on: "2"
retain: true
device:
name: "zendure1"
identifiers: "numéro_de_série"
serial_number: "numéro_de_série"
manufacturer: "Zendure"
model: "Zendure Hyper 2000"
De cette manière j’ai un simple switch à piloter pour le passer en mode charge ou décharge. Ce qui simplifie pas mal les automatisations.
1 « J'aime »
@Jackbot & @olivr2s , merci pour votre retour je n’avais pas vu cette partie dans le tuto.
Je vais regarder ça et programmer.
Bonjour,
j’ai un soucis, pas mal de valeurs remontent à « inconnu » alors que dans MQTT explorer je les ai toutes, mais pas dans HA :
- name: "Temps de décharge restant"
unique_id: "iobroker_hyper_2000_decharge_restant"
state_topic: "zendure-solarflow/0/gDaxxx/64xxxxx/remainOutTime"
value_template: "{{ value }}"
device_class: "duration"
unit_of_measurement: "min"
device:
name: "IoBroker-Zendure"
identifiers: "Io-Zendure"
manufacturer: "IoBroker-Zendure"
model: "Hyper 2000"
et dans mqtt explorer:
par exemple « puissance charge batterie » fonctionne mais je vois pas de différence de config ou pourquoi ca fonctionnerait pas :
- name: "Puissance charge batteries"
unique_id: "iobroker_hyper_2000_puissance_charge_batteries"
state_topic: "zendure-solarflow/0/gDaxxx/64xxxxxx/outputPackPower"
unit_of_measurement: "W"
device_class: "power"
value_template: "{{ value }}"
state_class: "measurement"
device:
name: "IoBroker-Zendure"
identifiers: "Io-Zendure"
manufacturer: "IoBroker-Zendure"
model: "Hyper 2000"
ma config dans mosquitto HA :
connection zendure-solarflow
remote_username xxxxxxxx
remote_password Lxxxxxxxxxxxxxxxxxx4
address 192.168.1.194:3883
topic # in
topic zendure-solarflow/# out
si quelqu’un a une idée svp, je sèche…
merci
Bonjour, les valeurs remontent dans HA que sur changement d’état. Ce qui explique que tu auras souvent des valeurs inconnues quand tu recharges ta configuration yaml. Pour tester les données associées a la décharge, le mieux est de lancer une décharge manuellement et d’attendre que les données remontent. Penses aussi à mettre des valeurs par défaut dans tes configurations, pour éviter les inconnues, car c’est souvent bloquant pour les automatisations. Par exemple pour le niveau de charge batterie, je considère qu’il est a 50% s’il est inconnu, en attendant que la vraie valeur remonte.
1 « J'aime »
merci @Julien_Galliot
en fait il suffisait de redémarrer le système (serveur) et pas juste redémarrer HA 
Dans MQTT-explorer j’avais bien les valeurs qui changeaient toutes les 1s à 15s selon les capteurs, donc je me suis douté et surtout souvenu que pour des capteurs templates ou des MQTT il faut redémarrer le système pour que ce soit opérationnel.
oui j’y ai pensé, comment tu procèdes pour mettre une valeur par défaut dans les sensor stp?
edit : j’ai trouvé ton post https://forum-test.hacf.fr/t/tuto-connecter-controler-sa-batterie-hyper2000-zendure-depuis-ha/52981/35
sacré boulot! merci beaucoup
je dois adapter tes automatisations car j’ai un système Huawei (7800wc de panneaux et onduleur hybride 6kw + 2 batteries LUNA 5Kw) et je souhaite qu’il continue à prendre la main pour la décharge le soir. Une fois les batteries déchargées, les batteries zendures prendront le relais, j’ ai 4 AB2000 et un 1 hyper2000 avec 2 panneaux 530wc en direct dessus.
c’est un poil plus compliqué mais je vais y arriver avec le boulot que tu as déja fait
merci
1 « J'aime »
Pour les valeurs pas défaut, j’ai pas trouvé (mais pas cherché non plus) comment le faire sur le sensor MQTT brut, du coup j’ai créé un nouveau sensor avec le code suivant :
- name: Niveau Batterie Zendure
unique_id: "Zendure_SOC"
unit_of_measurement: "%"
state: >
{% if has_value('sensor.iobroker_zendure_niveau_batterie_zendure') %}
{{ states('sensor.iobroker_zendure_niveau_batterie_zendure') }}
{% else %}
{{ 50 }}
{% endif %}
Je fait ça uniquement pour les quelques sensors qui me servent dans mes automatisations, comme là par exemple le niveau de batterie qui autorise ou interdit la charge/décharge et qui bloquait tout quand la valeur était inconnue. Et comme pour que la valeur devienne connue il faut la faire varier (donc charger ou décharger), il faut bien pouvoir lancer les automatismes même sur valeur inconnue.
1 « J'aime »
Salut à toutes et à tous.
Pour ceux que ça peut intéresser, j’ai fait un « tuto » pour faire remonter les valeurs (pas piloter…) de la batterie Zendure dans HA:
https://youtu.be/mZIxnoMFmKc
Je rencontre un petit soucis, j’ai l’entité MQTT « Remain Input Time » qui ne remonte plus (j’ai peut être fait un mauvaise manip), quelqu’un sait comment je pourrais la récupérer ?
Salut, tu as essayé avec MQTT explorer? SI ça remonte bien dans explorer, c’est un problème de configuration yaml dans HA.
Salut a tous,
j’ai finalisé mes automatisations et j’en ai 5, dans mon cas précis (système principal Huawei 7.8wc de panneaux, onduleur hybride 6Kw et batteries 10Kw Huawei) j’ai 5 automatisations, beaucoup plus simple que les tiennes, mais ca fonctionne:
1 : mode 2 decharge max 0W quand les batteries zendures sont en dessous de 21%
2 : charge AC puissance max : quand il y a au moins 0.5kw produits par les 2 panneux connectés à l’hyper + 1kw d’exporté vers EDF tant que les batteries zendure sont inférieures à 100%.
3 : surplux solaire de mes 2 panneaux de l’hyper vers EDF quand batteries zendure à 100% (j’ai un contrat de rachat EDF).
4 : quand la puissance totale produite solaire passe en dessous de la conso maison : décharge puissance max.
5 : Decharge AC : toutes les 10s check de ce qui est nécessaire avec un sensor « puissance de décharge temps réel » et adaptation dans l’hyper pour décharger que ce qui est nécessaire : c’est surtout utile le temps que la prod solaire descende jusqu’à 0, après l’hyper décharge à max, 1200w jusqu’à ce que les batteries arrivent à 20%.
puis c’est les 2 batteries huawei qui prennent le relais. j’ai entre 50 et 40% encore disponible quand la recharge repart le lendemain matin. Précision : mon talon de conso est énorme, même la nuit…j’ai une baie informatique avec 2 serveur et un réseau 10Gbits fibre, les commutateurs manageables fibre ca chauffe et ca consommes plus qu’un switch classique + un routeur pfsense sur un mini pc dédié (2 ports SFP+ et 4 ports 2.5Gbits) qui consomme 75w à lui tout seul.
Bref, ca fonctionne plutôt pas mal, je peaufine.
Par contre @Julien_Galliot je voulais te dire que pour les problèmes de sensor « inconnu » sous iobroker, j’ai trouvé la parade :
création d’un shell_command :
restart_iobroker_mqtt: "ssh -i /config/ssh_keys_remote_pi/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@192.xxx.xxx.xxx iobroker restart mqtt.0 --allow-root"
et d’une automatisation simple qui se lance après chaque démarrage ou si un sensor mqtt de iobroker est « indisponible »:
alias: Zendure - Restart IoBroker MQTT instance after HA
description: ""
triggers:
- trigger: homeassistant
event: start
- trigger: state
entity_id:
- sensor.iobroker_zendure_charge_maxi
to: unavailable
conditions: []
actions:
- delay:
hours: 0
minutes: 0
seconds: 10
- action: shell_command.restart_iobroker_mqtt
metadata: {}
data: {}
mode: single
il y a 2 choses à faire avant : 1 autoriser le ssh root dans le countainer IoBroker (pour ceux qui on un LXC sous proxmox comme moi https://klabsdev.com/enable-remote-ssh-on-proxmox-lxc/) et 2 -c’est copier la clé publique ssh de HA sur iobroker :
ssh-copy-id -f -i /config/ssh_keys_remote_pi/id_rsa.pub root@xxx.xxx.xxx.xxx
pour que le shell_command fonctionne. C’est immédiat pour moi, les capteur « inconnus » ils restent même pas 2 secondes lol
Si ca peux aider d’autres personnes qui ont des soucis avec leur automatisations quand un capteur passe à « indisponible » ca marche plutôt bien aussi.
@Geekarchitecte j’ai eu un problème similaire et la seule solution c’est que j’ai restauré ma LXC IoBroker sous proxmox a J-1.