j’ai enfin eu le temps de faire quelques tests. J’ai fait un actor générique pour gérer les différents modes.
ca marche bien pour la 1ère affectation mais il a l’air d’attendre un retour de l’ordre et au bout de 10 tentative, il arrête et ne réévalue jamais sauf si je change un paramètre.
Ca parle à quelqu’un ?
2021-10-15 22:58:57.033948 WARNING schedy_heating: !!! [R:salon] [A:light.radiateurs_rdc] Re-sending value due to missing confirmation.
2021-10-15 22:59:27.034026 WARNING schedy_heating: !!! [R:salon] [A:light.radiateurs_rdc] Gave up sending value after 10 retries.
Je m’auto répond. En spécifiant send_retries: 0 je n’ai plus ces messages.
Par contre, j’ai l’initialisaiton, mais quand je change de période, il n’y a pas de réévaluation …
Parce que je pilote mes capteurs Qubino fil pilote et qu’ils sont reconnus comme des lights avec différentes valeurs de brightness pour les différentes modes.
Du coup, j’ai utilisé un actor de type generic2 :
Il me semble que tu peux le faire avec des switche selon cet exemple et tu dois pouvoir te servir des expression_environment: ou définir les valeurs une fois pour toutes… Je vais esayer de piloter des switch cette semaine, je te dirais
Résumé
## This goes in schedy_coffee.yaml in AppDaemon’s apps directory:
schedy_coffee: # This is our app instance name.
module: hass_apps_loader
class: SchedyApp
actor_type: switch
expression_environment: |
def schedule_mode():
return state("input_select.schedule_mode")
watched_entities:
- input_select.schedule_mode
Merci pour cette belle idée d’utiliser des binary_sensor dans les trigger pour déclencher l’exécution d’automations ainsi que toute la logique possible dans les directives choose avec les ['and', 'or'].
Je me suis largement inspiré de ton article pour abandonner Schedy sur Appdaemon.
Mes automations :
autant qu’il y a de regroupements de type de chauffe (pièces à vivre, chambres, SDB, …). Elles n’envoient pas directement la température de chauffe mais alimentent un input_number.heat_temp_<nom>
une qui surveille les input_number.heat_temp_<nom> et envoie la température au radiateur concerné
une qui vérifie régulièrement que la température du radiateur correspond à input_number.heat_temp_<nom> et renvoie la température si nécessaire
une qui alimente input_number.heat_temp_<nom> depuis la température envoyée par le radiateur (action manuelle sur le radiateur)
Ce qui me manque encore : un moyen de remettre la température de chauffe initiale après X minutes si on l’a changé sur le radiateur directement (ce que Schedy faisait).
Je suis intéressé par la solution présentée dans ton dernier article.
J’ai aujourd’hui une vieille chaudière où il m’est impossible de la gérer via un thermostat. La seule parade que j’ai trouvé et qui me permet de faire de belles économies est de faire du ON/OFF avec une prise connectée. Ce n’est certes pas parfait en termes de régulation (si on peut parler de régulation) mais ça marche car j’ai une petite maison …
J’ai travaillé sur une solution Node-Red, qui fonctionne bien mais je souhaite aller plus loin avec de la planification telle que tu as pu le présenter dans tes articles avec l’utilisation de Schedy.
Seulement, je ne comprends pas par où commencer car je n’ai que très peu utilisé les automatisation. J’ai bien trouvé tes fichiers exemple sur ton Github. Peux-tu me donner les grandes étapes afin que je sache par où commencer ?
J’ai tellement fait évoluer cette solution au fil des que je comprends qu’elle soit un peu confuse pour qui débarque. Je vais essayer de reprendre ça quand j’ai un moment, sachant que dans ton cas il te faut un seul thermostat.
Là je n’ai pa strop le temps mais je t’ai mis à jour sur le Github les fichiers AC andi que celui e la carte dans sa dernière version. (ac-card.yaml). Attention ça utilise des composants externes et j’ai ajouté un mode auto/manuel.
Je te conseille de copier le code dans une carte vierge et d’aller ajouter les custom qui te manquent
Hello
L’hiver arrivant à grand pas, je me lance dans la domotisation de mon chauffage.
Je suis tombé sur ton site que je trouve très intéressant et j’aurai deux questions :
si tu partais d’une feuille blanche, reproduirais-tu cette approche ou en privilégierais-tu une autre ?
tes fichiers de packages sont-ils à jour ? (J’ai des erreurs de syntaxe sur la gestion des conditions de l’automation principale)
Pour information, j’ai regardé rapidement : merci pour la mise à jour.
Pour information c’est ce code qui ne passe pas chez moi (adapté à mon contexte bien entendu) : j’ai une erreur dans l’historique des executions (e.replace is not a function) : il passe bien chez toi ?
J’ai dû loupé un épisode, car sauf erreur de ma part c’est ce que l’on trouve dans ton dernier articule sur le sujet : Home Assistant, planification, encore…
on y voit des conditions de ce type :
(je suis un ancien développeur)