C’est difficile de faire une réponse générale, ça dépend de l’utilisation de chacun.
Il faudra gérer séparément chaque hyper, soit un ordre de priorité sur charge/décharge, soit en partageant entre les 2. D’un point de vue rendement/efficacité énergétique, c’est plus intéressant d’utiliser un hyper au max de ses capacité, plus le second si le 1er ne suffit plus…
Dans mon cas, j’ai préféré avoir 2 Hyper avec 2 batteries chacun pour avoir les 2400w, pour le micro-ondes, cafetière, … c’est intéressant. Je réfléchis même à un troisième pour couvrir totalement.
Par contre avec les automatisations de Julien, ce n’est pas simple.
Par contre les intégrations qui commencent à arriver (à minima celle de FireSon) là avec 2 hyper (ou plus) cela semble être prometteur.
Dans mon cas, j’utilise un peu des deux (de Julien et de FireSon) et aussi du manuel sur l’application
Il manque une limite basse à + de 50% mais cela va venir avec une intégration je n’en doute pas car c’est possible d’après ce thread (mais pas avec iobroker je crois).
Donc pour le moment je fait des mix de tout et cela fonctionne bien… Mais c’est en hiver prochain (tempo et jours rouges) ou là si les intégrations ne sont finies … je fonctionnerait avec les automatisations de Julien.
Du coup tu as modifié les scripts d’automatisations en prenant en compte ces valeurs ?
J’ose pas trop toucher les fichiers depuis que ça marche au top.
Mais effectivement la batterie quand la production solaire titille le talon fait le yoyo entre charge et décharge…
Je pense que c’est une bonne stratégie de mettre un seuil plus élevé dans les consignes charge/décharge.
Oui il y a ça mais surtout le rendement qui est très mauvais à faible puissance. En charge secteur il peut descendre à seulement 25% (75% de pertes!) si on charge à 50W par exemple. En décharge secteur, c’est un peu moins pire, 50% (50% de pertes) à faible puissance. Pour moi un rendement « acceptable » sur la conversion AC/DC et DC/AC est de 90% par conversion, ce qui fait une déjà perte totale de 20% sur un cycle complet, et on l’obtient avec une charge AC > 450W et décharge AC > 350W.
Avec un simple IF. Avant d’envoyer la consigne de charge/décharge à l’hyper, tu vérifies SI elle est supérieur à un seuil réglable (type input_number). Si OUi tu envoie la consigne calculée, si NON tu envoie une consigne 0.
Après c’est un choix personnel, il y en a qui se moquent des pertes et préfèrent lisser complétement leur consommation à 0 ou autoconsommer 100% de la prod solaire, quitte à perdre en effet joule 50% de la prod ou de l’énergie stockée.
Pour autoconsommer à 100% en production j’ai mon routeur qui fait le job. Et en consommation, j’accepte pour l’instant de consommer un faible talon sur le réseau. Et avec la gestion de la décharge par le coût moyen de l’énergie stockée que je suis en train de mettre en place, je vais peut-être revoir ça différemment …
Pour information, le développeur de Zendure sur IoBroker vient de sortir une nouvelle version qui prends en charge en version SANS CLOUD et un utilitaire pour passer son Hyper en mode sans cloud.
Du coup c’est possible d’être en direct sur son Hyper sans passer par Zendure avec IoBroker ou sinon sans IoBroker en MQTT avec les commandes qui vont bien.
Je sais pas quand je vais pouvoir tester tout ça, mais cela semble très prometteur.
J’ai testé mais ce qui me gène c’est que le développeur a recréé des plans énergétiques à sa sauce. Il ne permet pas d’utiliser les plans énergétiques natifs de Zendure et de switcher entre ces plans (suivant un planning horaire par exemple). Impossible également de gérer la charge / décharge en manuel comme on peut le faire avec IoBroker, c’est dommage. J’ai posé la question sur sont Github mais il semble qu’il ne veille pas laisser pour l’instant la possibilité de changer manuellement le « AC mode ». Donc pour moi cette solution manque clairement de flexibilité et de personnalisation dans le contrôle. Je vais donc rester sur IoBroker qui permet d’aller bien plus loin en terme de personnalisation du fonctionnement de l’hyper à l’aide d’automatisations HA. Par contre, pour ceux qui veulent uniquement remonter les informations sur HA (en lecture seule), l’intégration est un moyen simple et efficace!
@cob94440
Non, le bluetooth est utilisé avec un pc windows juste le temps de configurer le Hyper 2000 sur un broker MQTT local. Tout le reste se fait toujours en Wifi.
Merci pour l’info, je vais tester ça très très rapidement! J’ai lu rapidement mais de ce que j’ai compris, ça ouvre la possibilité de contrôler totalement l’hyper en mode local cloudless via mqtt, c’est top !
C’est bien ce qui semble être possible, un contrôle complet en MQTT et sans cloud. Le top !
Dans l’explication, il détaille comment envoyer les commandes MQTT…
Mon regret, c’est de pas pouvoir tester ça tout de suite…
Petite contrainte…le broker MQTT doit être sur le port 1883 et sans mot de passe…ce qui n’est pas le cas de mon broker actuel…