Ce qui est bien est parfois un peu compliqué à appréhender. Et c’est le cas de Shedy. En plus la prise en compte des modifs yaml sous AppDaemon est dynamique et c’est top. La philosophie yaml reste identique à HA. Je me sert aussi de ControlerX qui est sous AppDaemon.
Quant à NR, la réponse est non, c’est pas juste que je n’aime pas, je déteste. Bon, blague à part, c’est bien et même intéressant, surtout pour ceux qui ne réussissent pas à entrer dans la logique yaml, ce qui se comprends très bien. Mais dans l’absolu ça n’a pas besoin de HA, à part pour l’interface, ah oui NR n’a pas d’interface utilisateur, juste une interface dev. Bon, après chacun son truc.
Il y a aussi les Blueprint, et ça va changer bcp de choses sous HA je crois.
Bref, dans toutes ces solutions, seul Shedy sait faire de la replanification dynamique, c-a-d que toutes les x minutes il reconsidère l’état des lieux et agit en fonction. Les autres se contentent de faire ON au début et OFF à la fin (ou augmenter la consigne et la baisser).
Au printemps dernier je n’avais pas pris le temps de vraiment creuser Schedy, mais je vais peut être reconsidérer, au moins pour expliquer et écrire un article. Après le manque d’interface est cruel !
Merci pour ton partage d’expérience @pyg
Je suis également fan de Node Red, mais comme l’indique @mycanaletto je crois que les blueprint vont être une très bonne alternative. J’ai vaguement regardé et cela s’annonce pas mal dutout.
La notion de partage sur le même principe que ce que propose Node Red est un grand plus et vu que je suis partisan dès que possible d’utiliser les fonctions les plus proche du Core pour des raisons de maintenabilité entre les versions et bien je vais essayer de migrer vers les Blueprint.
Bonjour,
Merci pour ton « ping » et ton article. Tu as réussi à raviver la flamme Schedy
Malgré son côté austère, il a de nombreux avantages : robuste/stable, les fautes de syntaxe sont faciles à identifier, logs bien détaillés pour comprendre les décisions prise, ré-envoi en cas d’échec de prise en compte des commandes, gestion des réglables manuels et reprise du « scheduling » après un certain délai.
Merci pour tes astuces: 1) externaliser les variables de Schedy, 2) fichiers de variables dans /config/packages/*.yaml, 3) typages de variables pour créer une interface facilement dans Lovelace.
Variables Home Assistant
OK ça fait beaucoup de variables (booléen, début, fin, templates, …) mais ça se génère bien à coup de script.
Exemple pour 3 pièces et 4 planifications par pièces
/bin/bash
test -d /config/packages || mkdir /config/packages
cd /config/packages
cat >heating_global.yaml<<EOF
input_boolean:
heating_enabled:
name: Heating Global
icon: mdi:toggle-switch
EOF
for room in bureau sdb_rdc sdb_1er
do
for period in {1..4}
do
cat >${room}_heating_period_${period}.yaml<<EOF
input_datetime:
${room}_heating_period_${period}_start:
name: "Heating Period ${period} Start Time"
has_date: false
has_time: true
${room}_heating_period_${period}_end:
name: "Heating Period ${period} End Time"
has_date: false
has_time: true
sensor:
platform: template
sensors:
${room}_heating_period_${period}_start:
value_template: "{{ (state_attr('input_datetime.${room}_heating_period_${period}_start', 'timestamp') / 60)|int }}"
${room}_heating_period_${period}_end:
value_template: "{{ (state_attr('input_datetime.${room}_heating_period_${period}_end', 'timestamp') / 60)|int }}"
input_number:
${room}_heating_period_${period}_temperature:
name: Heating Period ${period} Temperature
min: 18
max: 25
step: 1
unit_of_measurement: °C
input_boolean:
${room}_heating_period_${period}:
name: Heating Period ${period} Enabled
icon: mdi:toggle-switch
EOF
done
done
exit
Puis tester la configuration « check configuration » et recharger les éléments nécessaire:
« reload input booleans »
« reload input date times »
« reload input numbers »
« reload templates entities »
Petite update pour le paramétrage Shedy, avec l’option par défaut « supports_hvac_modes: true », il envoie dans la foulée un « climate.set_hvac_mode » et un « climate.set_temperature ». Chez moi avec mes Fibaro Heat Controller, dans la plupart des cas, la deuxième instruction « climate.set_temperature » était ignorée (droppée ?). Shedy passait son température à faire des « Re-sending value due to missing confirmation ».
Avec l’option « supports_hvac_modes: false », OK le chauffage n’est plus jamais mis en OFF mais à une température de chauffe basse (kif-kik nan ?), ainsi Shedy n’envoie que la commande « climate.set_temperature » qui, chez moi, passe dès le premier coup.
@pyg
Merci pour ton script, j’ai adapté à mon besoin et mis à jour mon article. Pour bien faire je vais ajouter la création des input_number pour les consignes par defaut (chauffage off et plage off).
Il me faut également trouver une solution pour planifier les 1/2 journées de travail (cas de qq un qui bosse le samedi matin…) Idées welcome
Il semblerait que si j’ai une plage qui se termine à 10.30 et une autre qui commence à 10.30 ça ne fonctionne pas. C’est ce que je voudrais utiliser pour juste changer la température de consigne.
Il me reste à l’adapter au mode froid pour cet été…
EDIT : En fait les plages ne sont pas prises en compte correctement. As tu changé qq chose ?
Hello @pyg !
Je continue à améliorer l’interface avant de la publier…
Le cas de figure que je traite ici est plus complexe car il me faut gérer :
Jours de semaine non férié
Jours fériés et dimanche
Samedi non fériés avec le matin travaillé…
Ca me fait 3 x 4 plages à gérer par pièce. Schedy fait ça sans soucis en partant sur la base de ton script… J’aimerais tout gérer avec un des binary et je me casse un peu la tête…
A la base on a ça et ça fonctionne :
binary_sensor:
- platform: template
sensors:
heating_antoine_1:
entity_id: sensor.time
friendly_name: Mode Confort
value_template: >
{% set t = states('sensor.time') %}
{% set day = now().weekday() in (0,4) %}
{% set start = states('input_datetime.heating_antoine_start_1') [0:5] %}
{% set stop = states('input_datetime.heating_antoine_end_1') [0:5] %}
{{ start <= t < stop if start < stop else (start <= t or t < stop) }}
Si j’ajoute mes deux contraintes pour jouer avec, ça ne fonctionne que si l’heure de fin ne dépasse pas minuit… Si j’ai une heure de début à 22:00 et fin à 00.45 le résultat n’est pas correct, en fait il ne tient pas compte du workday: ou du weekday.
{% set t = states('sensor.time') %}
{% set start = states('input_datetime.heating_antoine_start_1') [0:5] %}
{% set stop = states('input_datetime.heating_antoine_end_1') [0:5] %}
{{ is_state('binary_sensor.workday_sensor', 'off')
and now().weekday() in (0,1,2,3,4)
and start <= t < stop if start < stop else (start <= t or t < stop) }}
Donc si tu a une idée lumineuse pour faire fonctionner ce template, ou une autre Facon de gérer ça…
PS : l’idée du binary est intéressante car elle va me permettre d’afficher la plage active dans l’interface et de gérer des cartes conditionnelles. Il faut donc qu’un seul binary puisse être à on à un instant donné…
Si tu parles du retour que fait Schedy dans HA, ce sont des données brute destinées éventuellement à être traitées, donc on et non On ou ON.
Si tu veux les afficher proprement il te faudra passer par un template…
template:
- sensor:
- name: "Dehumidifier Buanderie"
state: >
{% if is_state('schedy_room.dehumidifier_buanderie', 'on') %}
ON
{% else %}
OFF
{% endif %}
Quelque chose dans ce genre en attendant que l’on puisse directement formater un résultat dans Lovelace… (peut être possible avec une carte Markdown… mais je m’avance surement).
Salut à tous, tout nouveau sur le forum, mais j’ai lu quelques articles déjà.
Je m’intéresse à Schedy pour programmer les plages de chauffe de mes radiateurs.
Par contre, je n’ai pas les mêmes hypothèses de départ de vos configurations.
J’ai mes radiateurs connectés via des modules Qubino Fil Pilote. Je ne cherche donc pas à faire du on/off mais à basculer sur les différents modes (HG, Eco, Confort, …).
Est ce que c’est possible ?
Schedy n’est pas fait pour gérer le chauffage à la française et je te conseille vraiment pour un meilleur confort de le gérer avec des sondes et du on/off (ou du eco/confort). Mais si tu y tiens vraiment je pense que c’est malgré tout possible, mais dans ce cas il gèrera simplement des acteurs de type switch…
Hello, tes articles sur HomeAssistant sont Top et je suis très intéressé à passer par Schedy.
Cependant, j’ai un peu de mal avec la logique entre la partie config sous appdaemon et la partie sous packages.
Pourrais-tu expliquer avec un exemple ce qui est interne à schedy et ce qui est repris des tes intégrations pour le fonctionnement ?
Ce repo va t’aider, il reprend les différentes répertoires. Dans la racine tu a aussi le code de la carte Convecteur et de la carte Clim. Pour les exploiter il te faudra quelques extensions dont tu retrouvera le nom dans le code des cartes et que tu peux ajouter depusi HACS…
EDIT : pourrasi-tu me donner ton avis sur la façon d’adapter ton code pour tenir compte de jour de télétravail à gérer.
Aujourd’hui, j’utilise des input_boolean sur L/M/M/J et V en les définissants sur On ou Off en fonction de mes jours de télétravail. Derrière, cela active ou désactive autant de calendrier (Chambre / SdB / Zone Vie et Bureau par ex).
Mais j’ai un peu de mal à me projeter sur la façon de le faire via Schedy.
Le mieux est tt de même que tu le monte comme j’ai fait et que tu regarde comment je gère le samedi travaillé avec un binary par exemple, tu devrais pouvoir adapter.
Mais ton info télétravail ne sera pas automatique ? Quelle source ? Donc il faut prévoir un bolean la veille par exemple ou faire un link avec outlook ou gmail ?
Je vais essayer de voir comment fonctionne le samedi travaillé.
Ma gestion du télétravail est très manuelle.
J’ai un boolean pour chaque jour de la semaine.
D’une sem à l’autre, je peux déclarer quel jour est télétravaillé ou non.
Et en fonction des jours de télétravail, j’active ou non des schedule prédéfinis
