Autre matériel de brassage ⇒ Votre thermostat fait maison en Open Source

[taspoff]

(houla : grosse tartine finalement)

Plusieurs problèmes :

- PID : j'en ai besoin de 2 : un qui va piloter une résistance électrique dans ma chaudière a eau, et un pour piloter une pompe de circulation entre la chaudière et un serpentin dans le moût (comme le système de "Denis") pour "l'ajustage et le maintien du pallier". J'ai un réchaud gaz pour manuellement accélérer la montée de pallier (et l’ébullition), mais j'ai vraiment peur d'essayer de l'automatiser et de faire finalement une bombe dans mon garage ...
Pour en revenir au PID, il y a 3 paramètres internes propres au fonctionnement du PID (Kp, Ki et Kd), qui sont suffisamment ésotérique à mon goût au point de me poser la question de l'utilité réel de cet algorithme ... Au vu de la capacité de chauffe inégale (serpentin+réchaud) et de l'inertie thermique de mes casseroles, un simple "si (T° = T°cible - pouillème) alors Stop Chauffe" suffirait peut être avec un calcul approximatif et prédictif de la vitesse de chauffe pour l'estimation du "pouillème" (et c'est pas vraiment comme ça que l'algo PID fonctionne en mode relais On / Off, quand on y regarde bien... c'est plutôt adapté a du "micro ajustage" très lent avec une erreur qui évolue et s'adapte très lentement, inadapté pour des paliers de chauffe en mode on/off sur 30sec)...

- la connexion Wifi: un seul microcontrôleur (genre esp8266 ES12) pour 12 capteur et 12 actionneur, ça fait de la filasse partout, et la panne de l'algo sur le microcontrôleur impacte toute la chaîne de brassage... D'autant plus qu'il doit gérer plus de chose sur une seule IHM, les recettes, avec de l'affichage "un peu joli", etc... plus de chose a gérer donne plus de code et donc plus de bugs... le microcontrôleur, bien que puissant, n'est pas aussi puissant qu'un PC multicore 64Bits pour gérer des erreurs, relancer un process pour une reprise en cours de route, etc,etc... pour ça il faut un OS, et donc je pense qu'un ordinateur (ou un téléphone?) s'impose...

En plus, un ESP8266 ES01, c'est au max 4 port IO. donc comme le microcontrôleur prend une ip sur une livebox, il faut donc gérer 12 capteurs et 12 actionneurs sur 3 à 12 adresses IP différentes et autant d' IHMs différentes... compliqué

Donc je suis donc parti sur un serveur central juste Wifi, et autant de capteur/actionneur indépendant les uns les autres, mais chacun avec un code simple, pour une meilleur adaptabilité a mes humeurs de pico ("et si je mettais cet vanne là, plutôt que là?"), et plus de possibilité de reprise en cours de route... je prefere modifier ensuite la configuration sur le serveur central : plus confortable, rien a "reprogrammer" coté µcontroleurs

Accessoirement, le fait de minimiser le rôle du microcontrôleur en le rendant "générique", ca me permet de récupérer la température des pièces de ma maison, son humidité, d'assurer le maintien d'une future zone chaude, d'un frigo, etc etc, le tout accessible depuis le même outil d'IHM Central Sur le long terme, j'y gagne en confort (enfin, bon, quand ca marchera )
De plus, d'un point de vue sécurité, avoir le "serveur web" accessible sur l’équipement, c'est pas top : ça reste un mini-serveur http qui ne gère pas bien la sécurité d’accès. C'est le truc a se faire ouvrir la mauvaise vanne au mauvais moment par la mauvaise personne et envoyer le moût par terre avant d'avoir mis la dame Jeanne, a faire bouillir les fermenteurs en zone chaude ou a m'allumer la lumière du salon de 3h du matin a 22h en mode morse

La librairie Arduino pour passer les échanges en mode publish/Suscribe sur un serveur MQTT déjà tout prêt me permets de sécuriser l'utilisation du capteur/actionneur, et permet aussi d'identifier a un seul endroit tous mes équipements... En plus, Jeedom le gère particulièrement bien....
Au lieu d'un raspberry, ou PC dedié, j'ai mis le serveur MQTT chez OVH (mais on peut mettre ce qu'on veut comme broker MQTT, y en a plein en accès public) j'ai un taux de panne quasi nul, et plus de soucis de configuration NAT de la livebox et un nom de domaine pour quelques euros... un vrai plus coté maintenance pour un faignant comme moi :p


et sinon sur la partie électronique j'avais des soucis : l'esp8266 perdait la connexion wifi quand il activait le relais SSR : ca marchait bien qu'avec une diode quoi.... problème de puissance a mon avis entre l’ampérage du relais et l’ampérage pour le Wifi.... pas trop méchant (j'ai grillé qques µproc ), mais chronophage...

Le truc qui m'a vraiment bloqué longtemps : c'est la naissance de mon petit troisième duraille de souder/coder dans la même chambre qu'un nourrisson qui voulait pas dormir




--> le shema "IT"...


--> oui c'est une usine a gaz : et alors?

[Tranquille]

Je pense que cette vision sur l'ESP est la bonne : ça sert à faire un thermostat ou à remonter une température en wifi, mais ça s'arrête là. Il n'y a aucune puissance de calcul

[efdé]

OK merci pour les précisions. En fait t'es un dingue, on envisage de faire un thermostat, et toi t'as déja fait une pico complète !

[Catuvolcos]

Tu as des CI très simples à mettre en œuvre (genre un TCA9535 : 16E/S pour 3 pins) qui te permettent de démultiplier le nombre d'E/S dispo. L'avantage c'est que tu n'as toujours qu'un seul microcontrôleur pour gérer tout ce monde là, et tu contrôle tout via un bus SPI ou I2C unique. Une seule carte, un seul algo, donc une meilleure consistance de l'ensemble, et moins de sources d'emmerdes.

Tu sembles penser qu'avoir plein de systèmes distribués c'est une sécurité. S'ils sont interdépendants, comme dans le cas d'une pico, ça peut être une source de problème car tu multiplies les causes de défaillance.
Avoir un système unique qui gère les températures, les pompes etc., bref un automate, secondé par un truc en réseau qui lui file les consignes et s'occupe de l'IHM c'est beaucoup plus robuste. Problème de communication entre les deux unités ? Pas grave, l'automate continue son petit bonhomme de chemin, à la reconnexion on le récupèrera. Et ça ne t'empêche pas de changer de configuration facilement.

Un algo PID est tout à fait capable de gérer des paliers. A la différence d'un thermostat, tu supprimeras les problèmes d'oscillation et d'overshoot. Le tuning des paramètres est justement là pour intégrer toutes les contraintes physiques (déperditions, puissance de chauffe, inertie, bref le comportement de ton système), de telle sorte que ton système puisse se dire "Si j'en suis à cette température (P), que ça monte à cette vitesse (D), et qu'on a parcouru ce chemin (I), alors je dois donner telle consigne". Les paramètres Kp, Kd, et Ki sont là pour adapter la consigne en fonction de ces trois données. Y'a pas de magie ni d'ésotérie là dedans.

Quant à la puissance de calcul, le core CPU de l'ESP8266 est nativement à 100 MIPS, à comparer aux 20MIPS d'un arduino ... alors gérer deux PIDs, même si tu envoies de temps en temps de paquets WiFi, ça passera.

Pour ton gaz, tu as des électrovannes faites pour ça, qui ouvrent/coupent le gaz, font l'étincelle nécessaire et contrôlent qu'il y a bien la présence d'une flamme grâce à un thermocouple. C'est ce qu'il y a sur les chaudières et c'est super fiable.

[Aed]

taspoff, ton architecture distribué me parait ultra compliqué, as tu déjà commencé à coder le soft de contrôle ? Il faut penser a tous les cas de défaillances, avoir l'état de chaque élément de ta brasserie en temps réel (enfin a qq seconde prêt) si tu mets 10s à récupérer les infos et envoyer les consignes d'urgence (genre ca déborde -> couper l'arrivée d'eau...) ca peut craindre.
pour le wifi : perso je préfère que tous les éléments critiques soit connectés en filaire, le Wifi c'est juste pour la configuration et l'IHM
pour OVH : arghh quelle hérésie, du calcul distribué pour contrôler un process local ... bon après je suis un anti-cloud forcené (à prononcer "clou")

[taspoff]

Sur mon architecture, un PID(*) est bien géré dans un seul microcontroleur qui gère la lecture d'une seule température et d'un seul relais de pilotage (y a un petit PID en haut a gauche sur le shema des microcontrôleurs...)... Par contre, la consigne de température cible et l’arrêt/relance du PID se font bien au travers de l'IHM déportée via POST http ou par MQTT vers le microcontrolleur. (en gros, je sépare la couche IHM de la couche automatisme), et un microcontroleur, ne gère qu'un seul PID.

L'IHM nécessaire pour donner les consignes est plus compliquée: suivant la phase de brassage (changer la config des électrovannes et les start/stop du PID (qui lui contrôle le relais de la pompe)), récupérer et suivre une recette issue de brewsmith, gérer l'animation des bubulles dans les casseroles.... le serveur qui gère l'IHM est hébergée sur le serveur chez OVH, un PC dans le salon, ou ce qu'on veut du moment qu'il ai un DNS ou une IP fixe pour que les microcontrôleurs s'y abonnent....

sur http://drink.a.homebroo.space (cf mail précédent), je n'avais qu'un seul équipement électroniques de type DS18B20+relais+PID, j'ai donc fait des bouchons pour simuler les autres...et non, on ne gère pas les erreurs... d'ailleurs, on gère pas grand chose encore : juste des scenario on/off sur des vannes ou des pompes, la mise en place des consignes de température, et l'activation des PIDs. La récupération de températures via http/json est plus pour l'affichage graphique qu'autre chose, on a pas de PID sur le serveur OVH...


(*) je continue de vouloir automatiser le PID au niveau du microcontroleur, mais je suis pas fan de l'algorithme que j'ai utilisé pour mon cas (celui de l'algorithme PID des librairies arduino)... Quand je dis de contrôler par la méthode du pouillème, c'est toujours le microcontroleur qui s'en charge : l'IHM ne gère que les logs d'affichage et les consignes...

[Aed]

tu n'as aucun capteur de prévu pour les volumes de liquides dans les cuves? je ne vois pas trop a quoi cela sert d'avoir des électrovannes dans ce cas, ou alors en jouant sur les timing mais c'est risqué...
incessamment sous peu je mets en ligne mon prog de contrôle pour avis

[taspoff]

J'avais prévu de bosser sur les niveaux de liquide : j'ai des "interrupteurs flotteurs" en inox a installer sur mes cuves, qui peuvent servir de garde fou en série sur la pompe, mais j'aimerai aussi tester l'usage de capteurs de distance a ultrasons : connaissant le diamètre et la hauteur totale de mes faitout, et si j'arrive a avoir la distance du couvercle au liquide, je doit pouvoir calculer un volume de liquide... (même si mes capteurs sont étanches, dans la vapeur d'eau, pas sur que ça marche...)...

je vais ouvrir un post sur homebroo et faire ma présentation : j'ai un peu trop pollué le post initial...