Ca ne vaut pas un grafcet… 
oui c’est celle-ci. Tu gères comment le planning de la température ?
Je ne le gère pas, ce sont mes radiateurs qui le font pour moi pour cette partie car ils se gèrent très bien tout seul… 
Je ne m’occupe simplement que de la commande, pas de la consigne…
Il me semble que le thermostat native gère l’hystérésis :
Température ou consigne de mode c’est identique, donc saches juste que tu n’auras pas ce problème si tu le prévois dans le code.
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
Faut que je trouve un exemple de script d’un planning de température (thermostat qui change de valeur suivant les heures et les jours).
Voir ma réponse plus haut… 
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.
Merci @Dim33 
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).
Possible d’ajouter cette option dans ton blueprint ?
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.
Hello,
Une desactivation et reactivation d’une automatisation faite dans le scheduler via un schema force aussi la replanification. Il suffit de le faire dans une automatisation se déclenchant quand on a besoin de forcer la replanification (ou un blueprint).
OK, merci. Tu penses faire la modif. de ton blueprint rapidement ?
Tu peux le faire toi très simplement : il suffit de remplacer les « switch.turn_off » par « switch.turn_on » dans le YAML du blueprint (et inversement) 
Le retour d’état est implicite. Si un module s’affiche ON c’est qu’il est ON (je sent de vieux souvenirs Jeedom ou avec certains modules qui en étaient dépourvus on simulait un pseudo retour d’état).
Certes, mais vu qu’on ne sait pas quand le faire je préfère une replanif auto. J’avais demandé à ce que le Scheduller ait cette fonction, mais l’auteur n’était pas chaud, les devs sont parfois têtus
1 « J'aime »