Comme expliqué sur d’autres post, je migre doucement mon système de Domoticz vers HA. J’ai commencé gentiment et maintenant je commence à rentrer dans le dur, c’est à dire la domotisation de mon chauffage électrique sous HA (je commence maintenant pour etre pret cet automne ).
Pour faire simple, sous Domoticz, les thermostats (au nombre de 4 : cycle boulot, à la maison, absent) avaient un planning et suivant les heures et les jours, la température de ces derniers étaient modifiées. Un switch principal permettait de sélectionner manuellement les modes (normal, à la maison, absent). D’autres switchs secondaires pouvait faire varier la température de façon temporaire.
Le tout via des scripts lua (1 pour chaque piece).
Cela a fonctionné parfaitement pendant au moins 4 ans. Le seul reproche était que si Domoticz était éteint (coupure de courant par ex) lors d’un changement de température (via planning), la température précédente était conservé.
Apres lecture de posts dont ceux de @mycanaletto, Schedy permet d’éviter ça (enfin de ce que j’ai compris …) par contre ce n’est pas simple à mettre en oeuvre.
Scheduler semble plus simple de ce coté mais je me retrouve avec le même pb que Domoticz.
Je souhaiterai avoir votre retour d’expérience sur ce sujet (à mon sens, essentiel). Merci.
Sincèrement Schedy n’est pas compliqué. La ou ça se complique un peu (mais pas trop) c’est si tu veut faire une interface à destination de qq d’autre. Je l’ai fait, mais finalement j’édite le fichier yaml. Et ce qu’il faut savoir c’est que les modif du yaml de Schedy qui tourne en AppDaemon sont prise en temps réel (pas besoin de reloader une automation)
Je suis le seul administrateur du domicile .
Je n’ai pas trouvé beaucoup de tuto sur le sujet, hormis le tien.
Et compte tenu de ma faible connaissance de HA, pour l’instant je nage.
En avril 2020, tu avais écris ce post :
"Après avoir regardé j’ai fait le choix de ne pas utiliser Schedy qui est un composant externe Appdaemon lourd. C’est sérieux, mais ça peut sauter lors d’une mise à jour. Après je sais qu’ils bossent sur un vrai scheduler avec interface graphique."
Finalement, ça tient ?
Merci pour ton aide.
Pourquoi pas en Yaml mais quid de la problématique que j’évoque dans mon post ?
J’ai des horaires de boulot très basiques et identiques sur 5 jours (lundi au vendredi).
Plutôt qu’un long discours, mon script lua (trés facile à lire), j’ai supprimé les détails :
1 script par pièces.
----------------------------------
--- Gestion de la température ----
----------------------------------
local temperature = tonumber(string.sub(otherdevices_svalues[sonde],1,4)) -- Température relevée dans la pièce
-- Adaptation de la consigne suivant le mode choisi --
if (otherdevices[mode] == 'Normal') then consigne = consigne_normal end
if (otherdevices[mode] == 'Vacances') then consigne = consigne_vacances end
if (otherdevices[mode] == 'Absent') then consigne = consigne_abs end
if (otherdevices[mode] == 'Eco') then consigne = consigne_eco end
if (uservariables['JF'] == 1) and (otherdevices[mode] == 'Normal') then consigne = consigne_vacances end
if ((temperature < (consigne-hysteresis)) and (otherdevices[mode] ~= 'Arret') and (otherdevices[commande] == 'On')) then
commandArray[radiateurr]='Off' -- Radiateur allumé : gestion fil pilote
commandArray[radiateur]='On' -- Radiateur virtuel pour afficher sur le tableau de bord que le radiateur est allumé
print('Chauffage ' .. nom .. ' -. ON .-')
print('il fait '..temperature..'°C pour une consigne de '..consigne..'°C dans la ' .. nom)
elseif ((temperature > (consigne+hysteresis)) and (otherdevices[mode] ~= 'Arret') and (otherdevices[commande] == 'On')) then
commandArray[radiateurr]='On'
commandArray[radiateur]='Off'
print('Chauffage ' .. nom .. ' -. OFF .-')
print('il fait '..temperature..'°C pour une consigne de '..consigne..'°C dans la ' .. nom)
elseif ((otherdevices[mode] == 'Arret') or (otherdevices[commande] == 'Off')) then
commandArray[radiateurr]='On'
commandArray[radiateur]='Off'
print('Chauffage ' .. nom .. ' -. COUPE .-')
end
« consigne » = renvoi à 4 thermostats avec planning (consigne_normal, consigne_vacances, …)
"JF "= Jours fériés
« commande »= switch qui permet d’éteindre qqsoit la plage
Hello,
Normalement, si tu fais un schema avec le scheduler, il reprend la bonne consigne en fonction de l’heure au redémarrage. Idem si tu désactives puis réactives l’automation générée par le scheduler. La bonne consigne est retrouvée et forcée en fonction de l’heure qu’il est.
C’est ce que j’utilise dans la gestion de chauffage que j’ai proposé : Gestion du chauffage de bout en bout
Excellent boulot @Argonaute.
Mais j’ai toujours la même question concernant les plannings (voir mon premier post), que se passe t-il si HA est arrêté (coupure de courant par exemple) lors d’un changement de consigne ?
Comment déterminer les coefficient (coeff_c et coeff_t) ? ils sont propres à chaque habitation.
Oui il retrouve bien la bonne consigne. Pour essayer, tu crées dans le scheduler une planification type schema qui pilote une consigne dans un input number. Tu mets une valeur de test dans la consigne et redemarre HA. La valeur de test sera bien effacée et la bonne consigne du schema reprise en fonction de l’heure.
Pour coeff_c et coeff_t ils peuvent en théorie se calculer en fonction de la puissance de chauffage installée, le volume a chauffer, le coefficient calorifique de l’air et le coefficient de déperdition (isolation). Mais le plus simple est de prendre les valeurs par défaut et regarder le comportement (avec les courbes d’historique) : coeff_c sera la pente de chauffe ( a augmenter si met trop longtemps a atteindre la consigne) et coeff_t la compensation des pertes thermiques (a augmenter si la puissance injectée ne suffit pas a compenser les pertes thermiques, et qu’il y a oscillation). C’est mieux qu’un système a hysteresis ignorant la température extérieure.
Le temps de recalcul est aussi a considérer : 10mn est parfait pour des convecteurs electriques mais devra être augmenté pour des systèmes a inertie (chaudière, radiateurs a fluides).
OK. Je commande mes radiateurs électriques par le fil pilote (juste en ON/OFF = Confort/Arret) mais le signal est inversé, c’est à dire que pour allumer le radiateur il ne faut pas de signal (c’est la norme).
Oui sans pb. Il faut juste un switch et l’état peut être inversé dans le blueprint. Perso j’utilise des qubino zwave fil pilote, mais tu peux aussi utiliser des shelly, comme décrit par @mycanaletto
Pour ma part, je pilote mes radiateurs via le fil pilote avec des modules DIO en 433Mhz.
Je me tâte pour passer en Wifi (Schelly 1 par exemple) pour avoir le retour d’état même si je n’ai eu aucun pb avec mes modules en 433Mhz depuis 4 ans.
Cela pourrait être une option dans ton blueprint (inversion commande).
Tu sais Avril 2020 c’est loin, très loin à l’échelle de l’évolution de HA et de mes connaissances.
Actuellement je gère :
Le chauffage électrique (Shelly, sondes + climate) et la clim de mon frère avec le Scheduller : il faut qu’il ait la main
Mon chauffage electrique (IPXv2, sondes + climate) avec mes YAML d’il y a un an. Ca fait le taff avec interface, que je mets à jour de temps à autre
Pour ma clim je fait avec Schedy car c’est le seul qui fait de la replanif et parfois le module WIFI Daikin loupe un ordre. J’ai fait une interface et si j’ai le temps je ferait peut être tout avec ça.
).
