@Jean-Marc_Collin Au top ! Merci 
1 « J'aime »
Oui c’est envisageable de collaborer, voir fusionner. Je m’étais à l’époque tourné vers un blueprint car je souhaitais migrer rapidement de eedomus. En plus tout le monde peut se l’approprier et le modifier.
J’ai plus une culture java/c++ que python, et ne me suis pas encore mis au développement HA, mais c’est dans ma TODO. C’est sûr qu’un développement d’un thermostat en python est très pertinent.
Débattre reste très intéressant dans tous les cas, et il y a pas mal de visions de la gestion du chauffage. Je trouve celle de @mycanaletto très pertinente.
J’ai vu plusieurs sujets et appels à questions.
Fonctionnement du thermostat
Le calcul de la puissance en %, est assuré par la formule suivante.
Puissance = coeff_c * (T consigne - T intérieure) + coeff_t * (T consigne - T extérieure)
avec un min a 0% et un max a 100%
- coeff_c est un coeff qui dépend de la puissance du chauffage et de la surface.
- coeff_t dépend lui de l’isolation de la pièce et des pertes thermiques.
Pour une installation standard au norme on a coeff_c = 0,6 et coeff_t = 0,01
Donc il y a bien la composante proportionnelle et un calcul de % à transformer en temps de fonctionnement.
Est-ce la même chose pour ton thermostat en mode LINEAR ?
Quelle est la formule en ATAN ?
Par contre le thermostat TPI prends en plus la température extérieur, ce qui permet d’envoyer de la chaleur pour compenser les pertes thermiques. Si il gèle dehors, le radiateur se stabilise à 20% pour compenser, ce qui est logique.
Est ce possible de rajouter cela sur ton thermostat ?
L’alternative est un mode d’apprentissage des pertes thermiques, ce que fait Nest, mais plus complexe à mettre au point.
Scheduler et gestion des modes
Je ne suis pas sûr de comment tu gères les consignes avec le scheduler. Mets tu dans le scheduler les modes (eco et confort donc) ou les consignes de température ?
Si première solution, as tu bien une consigne de température unique pour ECO et une consigne unique pour CONFORT ?
Je met moi les consignes de température dans le scheduler. Il faut alors 2 planifications : une pour ECO et une pour CONFORT. ECO est typiquement la planification confort avec un offset de 1 à 2 degrés en moins.
ECO est utile quand une pièce n’est pas occupée. ABSENCE utilise la planification ECO (mais permet de se rappeler qu’il faut le remettre en confort quand quelqu’un revient).
Suivant, la signification ECO et CONFORT est très différente, mais les 2 seraient acceptables.
- Si on met les modes dans le scheduler, c’est plus simple à gérer, on a une seule programmation (2 éventuellement pour distinguer semaine / week-end).
- Si on met les consignes c’est plus flexible (pour avoir 3 températures possibles par jour par exemple), mais plus complexe (2 programmations ECO et CONFORT à prévoir).
Mode absence
Dans ma gestion, le mode absence permet donc de baisser les consignes de température programmées en CONFORT quand on n’est pas la (quand alarme mise typiquement chez moi). En absence, on passe à la programmation ECO (tout en se rappelant des convecteurs qui étaient en CONFORT pour pouvoir les remettre à l’état initial).
Exemple d’une chambre avec le mode confort programmé comme cela : froide la journée, chaude en soirée et tiède la nuit.
Si on est absent, on passe en mode ECO qui typiquement permet de baisser ces température de 1 à 2 degrés.
Quand on revient, les convecteurs mis en ABSENT rebasculent dans les plages du mode CONFORT.
Avoir une température unique pour ce preset n’est à mon sens terrible. On devrait plutôt avoir un offset pour baisser les températures programmées. Si on revient en soirée de cinéma, la chambre sera potentiellement trop froide, ou on la chauffera trop la journée quand on est au travail.
A voir si tu peux adresser cela (?)
Mode manuel
Il est certes possible de changer la consigne si on est en mode eco ou confort. Mais ce n’est pas terrible de ne pas savoir quand elle sera changée, si ce sera dans 10mn ou 5 heures (un redémarrage de HA par exemple ou un changement dans le scheduler).
Ne faudrait t’il pas avoir un mode MANUEL qui permet d’avoir une température qui ne change pas ?
C’est ce que je propose.
Utilisation fil pilote et mesure consommation
Tu pilotes tes convecteurs directement en puissance et pas via des fils pilote. Mais cette solution est réputée détruire rapidement les cartes électroniques des convecteurs (quel ton avis ?).
Dans la doc, tu mets « this thermostat is not suitable for heaters with a pilot wire », mais on pilote en on-off via le fil pilote. C’est dommage de dissuader les personnes ayant un fil pilote de ne pas utiliser ton thermostat à la place de celui du convecteur 
Enfin, pour mesurer la consommation avec un fil pilote, je mesure le temps ON du switch et le multiplie pas la puissance du convecteur. Cela se fait indépendamment des blueprint et peut rester externe. Rien n’empêche d’injecter cela dans ton thermostat pour gérer ta fonction de délestage.
Mode boost
Belle idée. Mais ne faudrait t’il pas utiliser le mode ATAN pour le boost, et linéaire le reste du temps ?
input number pour les températures
C’est ce que tu mets dans la doc pour la température mesurée, mais ce devrait être un sensor, non ?
1 « J'aime »
Hello ! Je suis vraiment content si vous arrivez à prendre le meilleur des 2 mondes, c’est une super idée !
Et si vous arrivez, en plus, à intégrer un apprentissage et/ou une anticipation de chauffe (comme pour netatmo par exemple) vous touchez le jackpot avec un addon parfait 
. L’espoir fait vivre, mais je suis content de voir que 2 personnes avec des ressources en or puissent discuter d’un développement commun ! 
En tout cas, si cela aboutit, je me porte volontaire afin de vous aider dans les tests terrain. Je vous propose pas mon aide au développement, étant une grosse bille bien lisse… mais le cœur y est !
2 « J'aime »
Hello @Argonaute , merci pour ce super post. Y a plein de choses super intéressante dans ton post et je vais commencer par répondre point par point aux questions que tu te poses (légitimes)
Ma formule de calcul est fait comme ça. Je calcule un % de on vs off (puisque je ne fais que du on/off → mais faut que ça change on est d’accord).
le %On = fonction(T consigne - T interieure). → c’est bien du mode proportionnel
J’ai deux fonctions possibles car j’ai vu qu’en fonction de la configuration de la pièce (puissance du radiateur, isolation, …) on a besoin d’avoir une fonction de régulation plus aggressive :
- LINEAR : le % est une fonction linéaire de la diff: %On = 0.25 * delta_temp + biais
- ATAN : atan(delta_temp +biais) / 1.4 (atan est la fonction arc-tangente qui permet d’avoir une courbe entre 0 et 1 qui ressemble à ça) :
Donc Ca va chauffer plus vite lorsque l’écart est faible (d’où « l’aggressivité » plus forte mais avec risque d’oscillation autour de la valeur cible)
Le résultat de la fonction est cappé entre 0 et 1 et ça me donne un % de On. Multiplié par le cycle en minutes pour ce radiateur ça me donne un temps de chauffe vs un temps de repos.
le thermostat TPI prends en plus la température extérieur… possible de l’ajouter
Oui c’est possible. J’ajoute un capteur en config et je le rajoute dans la formule. Facile.
Mets tu dans le scheduler les modes (eco et confort donc) ou les consignes de température ?
Je programme le preset (et pas la température directement). L’idée des presets est justement de ne plus avoir à parler en ° mais en mode (confort, boost, …). Et j’ai bien une température unique de consigne par preset.
Sur la suggestion de @mycanaletto j’envisageais de rendre possible la configuration des temps des preset sous la forme d’un template. Ca serait beaucoup plus souple et ça permettrait typiquement de laisser un preset et de jouer avec les températures. J’avoue ne pas bien comprendre l’intérêt de ne pas utiliser les preset directement mais pourquoi pas. J’ai l’impression que ca permettrait de gérer les 2 en fonctions des préférences de l’utilisateur. Je ne sais pas encore faire mais ça me parait tout à fait faisable.
Mode absence
J’ai une automatisation qui force le mode « away » sur les thermostats quand il n’y a plus personne à la maison. Chaque temp_away est configurable sur chaque thermostat de façon indépendante. Ca revient donc à avoir un offset pour chaque radiateur.
Y a une deuxième fonction qui est intéressante dans ton cas: tu passes le thermostat en mode ‹ activity › et en fonction de la valeur d’un binary_sensor (pluggué sur un détecteur de mouvement chez moi mais ca peut être sur n’importe quoi), ca switch tout seul d’un preset à l’autre. Ca me permet typiquement de passer le bureau en mode « Boost » quand je suis dedans et en mode « Eco » quand je n’y suis pas. Je pense que ça répond à ton cas de rentré de cinéma si couplé à la programmation par template des températures. Je m’emballe peut être.
Ne faudrait t’il pas avoir un mode MANUEL qui permet d’avoir une température qui ne change pas ?
Ca existe nativement. C’est le mode preset off (sans préset du coup). Dès que tu touches manuellement à la température, ca enlève le mode preset (strictement équivalent au mode manuel donc).
Mais cette solution est réputée détruire rapidement les cartes électroniques des convecteurs (quel ton avis ?).
J’ai lu ça aussi quelque-part (certainement sur ce forum d’ailleurs). Comme mon thermostat ne fait que du mode on/off pour l’instant j’ai mis le warning.pas
Je connais du tout le mode par fil pilote j’ai rien pour le tester. Ce qu’il faut éviter c’est de couper le jus des cartes électroniques / remettre le jus en permanence. Si le switch off du radiateur équipé d’un fil pilote ne coupe pas le jus de la carte mais juste envoie un ordre d’extinction en effet c’est compatible et pas dangereux de l’utiliser.
Mais ne faudrait t’il pas utiliser le mode ATAN pour le boost, et linéaire le reste du temps ?
Pourquoi pas oui pour atteindre plus vite la consigne. Mais je redoute l’effet usine a gaz et notamment quand on doit remettre la fonction LINEAR du coup ?
C’est ce que tu mets dans la doc pour la température mesurée, mais ce devrait être un sensor, non ?
Ca marche avec les deux c’est d’ailleurs comme ça que je le teste : je mets des input_number que je fais varier comme je veux. La seule contrainte c’est que l’état soit un number.
A mon tour de te poser une question :
J’ai pas bien compris, tu as fait un thermostat en mode TPI c’est ça ? Si oui, quel est la formule complète de ce mode là ? J’ai vu des formules sur un post de ce forum mais ca ne dit pas comment on implémente tout ça (j’ai vu des maths et pas des algo). Parce-que ce qui serait intéressant ce serait que je finisse d’implémenter le reste. J’ai le P manque le T et le I. Et on ne dit pas PID (Proportionnel Integral et Dérivé ? Pourquoi TPI ?
Hello,
Merci pour tes réponses. Je comprend mieux.
En fait, tu as ma formule dans mon post précédent. C’est :
% = coeff_c * (T consigne - T intérieure) + coeff_t * (T consigne - T extérieure)
Et ta formule à toi pour linear est donc :
% = 0.25 * (T consigne - T intérieure) + biais
Elle sont très proches.
=> quelque part, ton biais serait remplacé par du proportionnel sur la température extérieur. Il faudrait rendre paramétrable ton 0.25 (coeff_c) qui dépend de l’inertie du chauffage / taille pièce, et rajouter coeff_t qui dépend des pertes thermiques.
Je ne sais pas si mon terme TPI (Time Proportional Integral) est adapté, ni si le nom des coefficients (coeff_c et coeff_t) sont pertinents.
A noter que ton 0.25 est probablement trop faible. j’utilise 0.6 qui permet de monter plus vite (évite le boost) sans pour autant osciller. Cela a fait l’objet de pas mal d’échanges et semble adapté. Certaines personnes mettent plus fort quand il y a de l’inertie.
Enfin, il reste un paramètre important : le temps d’un cycle on-off. C’est 10mn pour mon thermostat et devrait être aussi paramétrage (j’ai eu des demandes).
Cycle de 10mn - si chauffage à 40% => ON 4mn et OFF 6mn.
Quel est ton temps de période ? Est ce paramétrable ?
Je n’ai pas compris l’intérêt et comment cela fonctionnerait. Est ce pour pouvoir ne pas utiliser le scheduler ? Ou alors pour pouvoir ajuster les consignes dans l’interface ?
Ok vu et parfait, mais « off », on comprend que le chauffage est arrêté (mon mode OFF arrête d’ailleurs le thermostat). Je le renommerai.
Je comprends cela, Il y a un malentendu à ce sujet et c’est probablement le point dur.
Ma compréhension est que dans ton cas la consigne en absence est fixe pour toute la journée, ce n’est pas terrible.
En absence, il faudrait reprendre les plages ECO et CONFORT programmée dans le scheduler pour quand on est à la maison, et les abaisser de 1 a 2 degrés (offset paramétrable) pour quand quand on est absent. Quand on est de retour, on n’a ainsi que les 1 à 2 degrés à remonter quelque soit l’heure. C’est l’équivalent de ce que fait mon implémentation.
Ton thermostat devrait recevoir la consigne de la planification (confort / eco donc) et l’abaisser de l’offet quand en absence. Penses tu que ce serait possible ? Ce serait vraiment top et très efficace.
Oui, on utilise tous le fil pilote pour faire du ON-OFF : passer le convecteur en ON (en fait convecteur physiquement en mode confort, avec une température physiquement réglée haute - pas de tension sur le fil pilote) et OFF (demi-tension positive sur le fil pilote).
Cela se gère avec un sonoff et une simple diode (voir mon tuto). Ou alors directement avec un module type qubino.
ok. Je confondais avec PID comme dans le post suivant: Smart Thermostat - le chauffage contrôlé par PID Les formules sont super complexes et avec plein de paramètres manifestement complexes à régler quand je vois les post. Peut-être as-tu expérimenté ?
Si il suffit d’ajouter un coef_c, coef_t et la température extérieure, c’est en effet possible. On aurait alors possiblement la même formule. Ca rajoute 3 paramètres de conf mais si tu penses que c’est plus efficace, je vais le faire (ce week-end ?)
A noter que ton 0.25 est probablement trop faible
possible. Je l’ai choisi en me disant que si il y a 4 ° d’écart ca fait un allumage à 100%. Ca peut expliquer que @frankb trouvait que la consigne était atteinte plus lentement. Avec ton algo ce sera paramétrable (mon 0.25 ne l’était pas).
Cycle de 10mn - si chauffage à 40% => ON 4mn et OFF 6mn. Quel est ton temps de période ? Est ce paramétrable ?
Oui le temps de cycle est dans les paramètres spécifiables sur l’IHM (et modifiable ensuite via la même IHM). Chez moi je mets entre 5 min et 10 min de façon aléatoire pour éviter que tous les radiateurs s’activent en même temps.
j’envisageais de rendre possible la configuration des temps des preset sous la forme d’un template
Au lieu de paramétrer 20° comme température de confort, on pourrait mettre un template avec qqe chose comme {{ states(‹ input_number.ma_valeur_calculee ›) }} par exemple. Ca permet de rendre modifiable dynamiquement la température d’une consigne. J’ai cru comprendre que c’était aussi ton besoin. J’en ai pas besoin pour moi, mais vous êtes au moins 2 du coup à me parler de ça.
Ma compréhension est que dans ton cas la consigne en absence est fixe pour toute la journée, ce n’est pas terrible.
Oui. C’est le preset « away ». Je comprends ce que tu me proposes mais si je suis déjà en consigne Eco (17°) et que je m’absente, j’ai pas envie de passer à 15° par exemple. C’est beaucoup trop froid et il va falloir remonter de 5° quand je rentre. Avec mon système ca passe à la température du preset « away » qui est aussi 17° dans mon cas (donc ca bouge pas mais on change de preset).
Je vais déjà implémenter ton algo et voir si c’est facile de mettre les températures sous forme de template. Je vous tiens au courant.
Encore merci pour tous ces échanges passionnants.
Pour info, je fais de la régulation via Home Assistant depuis février 2021 et j’ai baissé ma consommation électrique de 30% sur mon chauffage depuis … Ca vaut vraiment le coup de s’y mettre pour ceux qui hésitent. J’ai amorti le PI4 + les switchs en 1 an.
1 « J'aime »
Très intéressant vos échanges !
possible. Je l’ai choisi en me disant que si il y a 4 ° d’écart ca fait un allumage à 100%. Ca peut expliquer que @frankb trouvait que la consigne était atteinte plus lentement. Avec ton algo ce sera paramétrable (mon 0.25 ne l’était pas).
Oui c’est possible effectivement.
Oui, on utilise tous le fil pilote pour faire du ON-OFF : passer le convecteur en ON (en fait convecteur physiquement en mode confort, avec une température physiquement réglée haute - pas de tension sur le fil pilote) et OFF (demi-tension positive sur le fil pilote).
Pour info, avec mon premier test, ma config tournait déjà avec un fil pilote. J’ai simplement renseigné mon switch (+ diode) qui commande le fil pilote dans les paramètres. Du coup je pense que tu peux lever la mention « pas recommandé sur fil pilote » parce que l’actionneur reste le même principe. Au lieu de couper l’alimentation du radiateur, on commande le fil pilote, tout simplement.
Donc au repos, mon switch est fermé, qui envoie une impulsion en demi alernance positive grace à la diode, vers le fil pilote → celui ci est en mode arrêt.
En mode confort, mon switch est ouvert, qui n’envoie plus de signal sur le fil pilote, et donc mon radiateur passe en mode « confort ». Le thermostat du radiateur lui même reste fonctionnel, et « l’astuce » est de mettre la consigne + 2°C afin d’éviter les surchauffes en cas de bug.
En tout cas je reste à votre dispo pour les tests
1 « J'aime »
Oui je comprends. Avec ma proposition, on a une planification libre pour mettre les températures et plages que l’on veut en absence, et donc anticiper la chauffe quand on sait que l’on va revenir. Du coup, on perd beaucoup la.
Top 
Non ce n’est pas mon besoin et je cherchais a comprendre l’utilité. C’est vrai que si cela permet de gérer les températures dans l’interface, cela a du sens.
A voir si on peut aussi gérer différentes températures en absence avec des consignes variables suivante l’heure et pas fixe, car cela reste bloquant pour moi. Si quelqu’un a une idée…
Impec. J’ai enlevé la mention.
En tout cas je reste à votre dispo pour les tests
Je suis en train de tester le mode TPI chez moi. Je te dis quand c’est livré. C’était vraiment très peu de modif. Si tout se passe bien se sera dispo en début d’aprem (ou fin de matinée au mieux).
Merci @frankb de te proposer pour tester, on sera plusieurs a tester en //, c’est toujours mieux
Ah oui tu n’as pas chaumé !! bah écoute à ta dispo avec plaisir
J’anticipe peut-être avant la livraison, penses-tu pouvoir mettre à disponibilité la valeur de la puissance calculé? pour l’implanter dans le graph (en rouge) je ne sais pas si cela te fait modifier ton code… :
@frankb , @Argonaute Je l’ai publié en béta. Ca fonctionne bien chez moi. Je vous laisse tester de votre coté. J’ai pas mis à jour la doc pour l’instant, j’attends d’éventuel retour.
Pour mettre à jour il faut autoriser les betas et choisir 0.2beta1:
Puis suivre les releases notes (aller dans Integration, choisir son Thermostat et cliquer sur « Configure » pour choisir la fonction TPI en entrer les paramètres).
Edit:
il faut recharger l’intégration après m’avoir modifiée en TPI:
Ah oui tu n’as pas chaumé !!
Faut battre le fer tout ça …
Comme c’est pas un attribut standard des « climates », je ne suis pas sur de pouvoir faire ça. Je vais déjà finir tout ce qu’on a dans le pipe.
Alors j’ai pu mettre en place ta mise à jour tout s’est bien passé, j’ai refait la programmation, les nouveaux paramètres etc.
Cependant, je n’ai pas vu de différence niveau fonctionnement du radiateur. J’ai fait baisser la température de la pièce et mis la température haute pour avoir justement un gros delta entre les 2. Mais le chauffage coupe suivant le cycle que j’ai mis (5 minutes). Il ne chauffe pas à 100% dans ce cycle-là.
Dans la formule de Argonaute, si je comprends bien, le delta (différence) entre la température de la pièce et la consigne le chauffage, pour atteindre la consigne va chauffer à 100% sans coupure. Lorsque ce delta se retrecie, à ce moment là il va baisser la puissance de chauffe, progressivement. Hors là je ne retrouve pas ce fonctionnement. Après j’ai peut être mal compris la formule.
Comme c’est pas un attribut standard des « climates », je ne suis pas sur de pouvoir faire ça. Je vais déjà finir tout ce qu’on a dans le pipe.
Ok pas de soucis, si je disais ça justement ça permettait de connaitre le % de chauffe dans le cycle, et voir si l’algorithme fonctionne. et visuellement c’est parlant sur le graph. Peut-être que @Argonaute a une idée
Je vais quand même laisser tourner pour avoir un peu de recul, je te tiens au courant !
Edit : etrange phénomène, j’ai passé le mode en eco car je vais partir de chez moi. Le temps de me préparer, et la je vois que le chauffage chauffe…
Impressionnant d’avoir déjà modifié !
Effectivement, compliqué de faire un test pertinent sans cela. Certes, on peut mettre un history_stats sur le switch pour avoir le temps de chauffe sur une période, mais son exploitation n’est pas immédiate.
J’ai du attendre un peu avant que ça se mette en place mais maintenant que c’est parti c’est bon :
Après allumage et consigne à 19° :
Et la fréquence d’allumage :
Je vais regarder pourquoi y a un temps d’attente au début (certainement une valeur de température pas bien initialisée au démarrage et il faut attendre un changement de valeur)
T’as bien mis un sensor sur la température extérieure ?
edit:
si tu as des doutes tu peux ajouter ça dans ton logger.yaml:
logs:
custom_components.versatile_thermostat: debug
et regarder le home-assistant.yaml.
je vois bien les valeurs de cycle calculée qui sont cohérentes avec les entrées :
2023-01-07 14:23:23.780 INFO (MainThread) [custom_components.versatile_thermostat.climate] VersatileThermostat-TPI Thermostat - Temperature changed. Event.new_state is <state input_number.fake_temperature_sensor1=17.0; initial=None, editable=False, min=0.0, max=35.0, step=0.5, mode=slider, icon=mdi:thermometer, friendly_name=Temperature @ 2023-01-07T15:23:23.778756+01:00>
2023-01-07 14:23:23.780 DEBUG (MainThread) [custom_components.versatile_thermostat.prop_algorithm] heating percent calculated for current_temp 17.0, ext_current_temp 4.0 and target_temp 19.0 is 1.00, on_time is 60 (sec), off_time is 0 (sec)
2
Le pourcentage calculé est dans « is 1.00 » ci dessus soit 100% dans l’exemple.
edit2: autre exemple à l’instant:
2023-01-07 14:26:51.781 DEBUG (MainThread) [custom_components.versatile_thermostat.prop_algorithm] heating percent calculated for current_temp 18.5, ext_current_temp 4.0 and target_temp 19.0 is 0.45, on_time is 26 (sec), off_time is 33 (sec)
Le pourcentage calculé est de 45% soit 26 sec On et 33 sec Off (cycle à 1 min de test).
Je vais ajouter le pourcentage en attribut, j’ai vu comment faire. Ce sera plus pertinent en effet (et fixer le bug sur l’init des températures).
Publication d’une beta.2 qui contient :
- l’ajout d’attributs custom. Exemple:
hvac_modes:
- heat
- 'off'
min_temp: 7
max_temp: 35
preset_modes:
- none
- eco
- away
- boost
- comfort
- power
- activity
current_temperature: 16.5
temperature: 19
hvac_action: heating
preset_mode: comfort
away_temp: 17
eco_temp: 15
boost_temp: 20
comfort_temp: 20
power_temp: 12
on_percent: 0.50
on_time_sec: 30
off_time_sec: 30
ext_current_temperature: 4
current_power: 290
current_power_max: 760
cycle_min: 1
bias: 0.25
function: tpi
tpi_coefc: 0.6
tpi_coeft: 0.01
is_device_active: false
friendly_name: TPI Thermostat
supported_features: 17
notamment les attributs suivants: on_percent: 0.50, on_time_sec: 30, off_time_sec: 30, is_device_active: false qui donne respectivement, le pourcentage du cycle a On, le temps en secondes a On, le temps en secondes à Off, si le device est actuellement actif.
Normalement, on va avoir tout ce qui faut pour bien vérifier que ça marche.
- le fix d’un big d’initialisation des temperature qui faisait que le thermostat mettait du temps à démarrer.
Je teste en // chez moi et ça se passe bien. Vous pouvez y aller.
C’est génial !!
Alors j’essai de faire la mise à jour, tout est ok, j’ai rebooté, rechargé l’entité et tout mais j’ai un nouveau message d’erreur :
ou
Si je vais dans l’état pour voir si il apparait les nouvelles données mais rien :
Ah oui même bug qu’au début 
. Je fixe (et définitivement cette fois)
edit: c’est fait. 0.2.beta4