Modif. automatisée du param 01 (UTI-SOL-SBU) en fonction du SOC (State Of Charge)

[jlm]

Suite aux échanges que j'ai eus avec Mickaël ,
qui fait tourner depuis quelques semaines maintenant la version smartphoton délivrant le statut des batteries.
Il en ressort un début de scénario que je vous livre ci-dessous.
Volontiers à l’écoute de vos commentaires. Qu'en pensez-vous ?


Paramètres donnés par l'utilisateur dans l'interface utilisateur (page web):

SOC_to_SOL =  SOC valeur basse limite désirée
SOC_to_SBU =  SOC valeur pour repasser en SBU

Paramètre live:

Actual_SOC = Valeur mesurée actuelle du SOC


Programmer ceci:

Règle 1)     If Actual_SOC < SOC_to_SOL then change-onduleur-to-SOL and Send-Alarm-by-email

Règle 2)     If Actual_SOC > SOC_to_SBU then change-onduleur-to-SBU and Send-Alarm-by-email

Exemple 1:
SOC_to_SOL = 20 & SOC_to_SBU = 50
SOC actuel à 18%, la règle 1 s'applique. Donc le Paramètre01 onduleur sera passé à SOL pour ne plus piocher dans les batteries

Exemple 2:
SOC_to_SOL = 20 & SOC_to_SBU =50
SOC actuel à 51%, la règle 2 s'applique. Donc le Paramètre01 onduleur sera passé à SBU pour pouvoir recharger les batteries

[gazzzzton]

Je valide puissance 1000  :D
Je le fait déjà avec home assistant grâce aux données qui remontent de smartphoton mais s'il peut le faire lui même c est encore mieux  :)

[jlm]

Tu as suivi la même logique ? Pas d'autres paramètres à tenir compte ?
Oui l'idée c'est qu'il reste indépendant d'autres infrastructures que tout le monde n'a pas.
Tu vas voir que dans un avenir proche ce sera une solution de domotique multi compétences

[gazzzzton]

Oui même logique de mon côté depuis plusieurs mois et ça tourne comme une horloge (juste rajouter a coté des choix multiples un commentaire comme tu as fait pour les autres réglages précisant qu'en dessous de 20% de SOC batterie ça fait baisser la durée de vie en nombre de cycle et qu'en dessous de 10% c'est a vos risques et périls).

Pour le seuil haut c'est surtout une histoire de confort d'utilisation des batterie donc au bon vouloir de chacun.

[jlm]

Voilà la version Bêta de l'automatisation en fonction des seuils du SOC.
Celle-ci est débrayable à la demande avec un simple bouton.
Ces seuils sont définis par l'utilisateur sur le tableau de bord.
Une fois ces seuils atteints, le paramètre 01 sera changé et un mail de rappel envoyé à l'utilisateur.
Reste plus qu'à trouver un cobaye pour tester en vrai  

Voici la démo ci-dessous.

Comme le SOC était autour des 68%, j'ai simulé le fait qu'il passe en dessous de la barre des 20%.
Celle que j'ai définie au-paravent dans le tableau de bord.

On peut voir aussi l'envoi du mail et la lecture des mails reçus. Un pour le seuil bas, ensuite l'autre pour le seuil haut.
(Cliquez sur l'image pour l'avoir en plein écran)

   

[gazzzzton]

Je veux bien servir de cobaye 

[jlm]

Je vais tester un moment chez moi et aussi chez Mickaël pour voir comment cela se comporte. C'est en fonction depuis ce midi.

Il faudra aussi que je mette la version virtualisée pour toi, juste ?!

J'ai encore des soucis avec le point d'accès au 1èr démarrage lors de la 1ère configuration. Ça fonctionne, ça fonctionne pas. Tjs l'informatique :-//

C'est pour cela que je ne libère pas la version 3.3.

[gazzzzton]

Je vais tester un moment chez moi et aussi chez Mickaël pour voir comment cela se comporte. C'est en fonction depuis ce midi.

Il faudra aussi que je mette la version virtualisée pour toi, juste ?!

J'ai encore des soucis avec le point d'accès au 1èr démarrage lors de la 1ère configuration. Ça fonctionne, ça fonctionne pas. Tjs l'informatique :-//

C'est pour cela que je ne libère pas la version 3.3.

Oui prends ton temps y'a pas d'urgence de mon côté, node red se démerde très bien tout seul pour gérer le Parametre 01 en fonction du SOC batterie pour l’instant  

Pour la version virtualisé oui j'avais réussit a la lancer sous proxmox en faisant deux trois manip mais j'avais un problème d’accès réseau (ethernet) même en changeant de carte reseau paravirtualisé avec la VM et impossibilité de gérer ça n'ayant pas accès au linux donc j'ai mis en standby en attendant la version 3.3 et si ça se reproduit a ce moment la je te donnerai l'accès a ma vm sur proxmox que tu puisse accéder a la console linux voir ce qui cloche. (en attendant ça tourne sur un raspberry).

[jlm]

Ah debian 11 m'aura fait souffrir. J'ai enfin trouvé pourquoi le point d'accès ne fonctionne plus.
Il suffisait de lire la doc debian . RTFM pour ceux qui connaissent.
Grrrr des heures à chercher partout pourquoi ça fonctionnait avant et plus maintenant.
La prochaine fois je travaille avec DOS V3.1 et ça ira mieux ?

Why this one was abandoned
This still had subtle race conditions, required /etc to be on a writable file system, and had problems with virtualization, so it's no longer supported upstream. The plan (still taken for granted in most of the documentation) was for it not to be supported in Debian 10 "buster", but hand-crafted .rules files should continue to work. In Debian 11 "bullseye" this is not working anymore.

[gazzzzton]

Et donc y'a une solution a ca ?

[jlm]

Je fais en sorte, toujours en avant avec l'informatique. Ça va le faire.

[jlm]

Ce matin avant de partir, le temps était moche et mes batteries à descendue à 20 %.
Selon l'automatisme que j'avais un peu oublié, j'avais demandé à smartphoton de passer en mode SOL si ce seuil était atteint.

Puis vers 11h00 je vois le temps changer, des trouées de ciel bleu ensoleillé alors que la météo n'avait pas prévu ce temps.
Je me dis, Jean-Luc va regarder à distance l'état de ton installation et selon ce que je verrais, je pensais passer en SBU.

Je lance mon VPN, regarde mon écran de téléphone et oh surprise mon onduleur était en mode SBU alors je le l'avais quitté en mode SOL.
Un blanc me traverse l'esprit .... et tout à coup, j'ai fait tilt, l'automatisme avait fait son œuvre.
J'avais programmé en sorte que si les batteries avaient atteint le seuil haut, 50% pour moi, il basculerait  C'est bien ce qu'il avait fait tout seul.
Je me suis dit "c'est cool quand même ce truc !"
Voilà pour la petite histoire vécue

Sur l'exemple ci-dessous, c'est la pastille No 1

   

[Samsara32]

C'est vraiment génial ce truc bravo !

[Samsara32]

Bonjour à tous 
pouvez-vous m'expliquer quelque chose ? 
Le paramètre 12
"Retour sur Edf  si tension batterie inférieure à" est règle a 48v
Du coup je ne comprends pas comment comment on peut atteindre les 20%
Est il regle trop élevé ?

[gazzzzton]

un petit coup d'oeil dans les differents posts sur lesquels on a traiter du sujet batterie et en particulier soc batterie t'aiderai grandement a comprendre pourquoi :)

[Samsara32]

Bonjour Oui en effet cela a deja été débattu merci
Du coup que doit on mettre dans les sections

12 Retour EDF si tension batterie inférieure à: ?
Le parametre 29 pour les pylons on n'y touche pas ?

Et dans parametre generaux seuil tension alarme ? en ce moment j'ai 47 et 54 est ce bon ?
Merci

[Samsara32]

Hello
Avec l'automatisation Je reçois des mails : *** Changement du paramètre 01. . Possibilité de piocher dans les batteries *** alors qu'il n'y a pas apparemment de changement d'état , qqun a une explication sur cet étrange phénomène ?

[jlm]

Alors dans mon cas, lorsque le SOC de la Pylontech la plus faible du pack atteint 45%  (il devait être en dessous auparavant) l'automatisme modifie le paramètre 01 en SBU et envoie ce mail tout seul.

   


L'autre seuil c'était plus valable pour les batteries plombs, à mes débuts. J'ai perso mis des valeurs qui ne risquent pas d'être atteintes car le BMS du Pylontech pilote lui même ses seuils. Ce qui n'était pas le cas pour les plombs ou les différences de tensions étaient très grands, pas comme les lithium