Présentation de la saga DomoMG
tous les codes de DomoMG sont sur le GitHub
Liste des épisodes publiés :
EPISODE 1 - L’atelier de développement
EPISODE 2 - Installation - la class ‹ mg › - TABULATOR
EPISODE 3 - Le suivi des consommations électriques
EPISODE 4 - Le chauffage
Bonjour à tous,
Aujourd’hui nous allons voir comment fonctionne la gestion des chauffages dans DomoMG et j’en profiterez pour faire une petite digression sur l’usage des capteurs de température.
Donc commençons par voir le résultat dans un design :
Rien de très remarquable à ce niveau,
le ‹ mode › courant du chauffage est rappelé en libellé avec sa consigne, en dessous le bouton de réglage de la consigne ‹ confort › (merci à @salviaff pour les icones du boutons ! que je lui ai « empruntée » 
)
5 scrips PHP permettent la gestion de l’ensemble
- CH_Chauffages_Mode : c’est lui qui va calculer le « mode » courant ainsi qu’un ratio de l’inertie thermique de la pièce concernée. C’est avec ce ratio que l’on calculera l’heure de démarrage des chauffages pour avoir xx° à telle ou telle heure. Cela donnera une évolution de la température de ce type
Le décrochage en début de nuit au passage en mode ‹ eco › se voit bien, ainsi que la reprise à 6:58 pour avoir la température de confort à 8:30, dans cet exemple on l’a atteint à 8:22
. Ensuite elle est maintenu à environ ± 0.2° / ±0.3°
Ce ratio est recalculé tous les jours et stocké, on exploite sa moyenne sur 7 jours. L’intérêt de cette moyenne est de prendre en compte les changements important de conditions climatiques qui influent directement sur ce ratio (condition de température / vent).
Le lancement/arrêt proprement dit des chauffages/climatisations est gérés dans le script : - CH_Chauffages_Regulation.php . La encore rien de bien remarquable.
- CH_Chauffages_Auto-Force.php : Ce script est utilisé pour « forcer » les modes à ‹ eco › ou ‹ HG ›. Utilisé essentiellement par le système d’alarme.
- CH_Ouvertures_Salon.php : Ce script va gérer la surveillance des ouvertures pour demander à fermer les fenêtres si la température extérieure est inférieure à la température de confort, de même il demande leurs ouvertures lorsque la température extérieure est supérieure à celle de confort.
Bien sur le process est inversé en été !!!
Tous ces systèmes s’appuie évidemment sur des capteurs de température, nous allons regarder comment il se comporte pour essayer de mieux comprendre comment les gérer.
A titre d’exemple je vais vous montrer les courbes de températures (même période que l’exemple ci dessus) des quatre types que j’utilise :
- des oregons classique:
- Les ‹ oeils › fibaro ou les thermomètres aquara de xiaomi (globalement équivalent à l’échantillonnage près) :
- les thermomètres des capteurs de mouvement xiaomi (et la ça change !!!) :
La première conclusion auxquelles on arrivent est que tous ces capteurs offrent une précision acceptable (si on corrige l’offset individuellement), ce qui les distingue le plus est leur réactivité/échantillonnage qui peut osciller de qq secondes à 1 heures ou plus 
.
Pour avoir un système résilient l’idée est d’utiliser TOUTES les infos de TOUS les capteurs disponibles en les retraitant intelligemment.
Pour cela j’utilise les ‹ résumés › de jeedom, qui permettent d’avoir la moyenne des x capteurs d’une pièce, entre les capteurs de mouvement qui intègre la température (œil fibaro, aquara xiaomi, etc …) et les capteurs spécifiques de températures cela peut faire du monde …
Seulement une moyenne brute d’informations hétérogènes … cela manque un peu de fiabilité !! 
, d’où l’idée de quelques corrections :
-
La première est un recalcul périodique (toute les 8 - 12 heures) de l’offset à appliquer aux commandes de températures en utilisant la moyenne donnée par le résumé comme référence, On voient qu’au bout de 3-4 itérations les corrections se stabilisent et tous les capteurs sont dans une marge d’exactitude de 0.1 à 3 % maximum.
-
La deuxième est d’activer/désactiver dynamiquement les capteurs pris en compte dans les résumes :
Pour cela le programme va désactiver le capteur si (par exemple et selon le paramétrage) le capteur est est à plus de 3 % de la moyenne du résumé OU si la valeur à plus de 15 mn, il le réactivera si la précision revient à moins de 3 % ET que la valeur date de moins de 5 mn.
Au final on à une jolie régulation à ± 0.25% qui est d’une extrême résilience vis à vis de la fiabilité des capteurs.
Cela à en outre l’avantage « d’absorber » les aléas de l’exploitation (un four qui se met en route et qui fait s’envoler le capteurs d’à coté ou un capteur qui ne se réveille que de manière aléatoire par exemple)
Dernier point, les paramétrages :
Voila, je crois avoir fait le tour complet, la prochaine fois on s’attaquera à la gestion de la présence sur le réseau des équipement ainsi qu’a la présence PHYSIQUE des utilisateurs !!!