Les heures les moins chères sans contrôleur : le hub signale, Home Assistant décide

Demandez à Home Assistant quelles heures seront les moins chères demain, et vous vous retrouvez là où vous ne comptiez pas aller : une intégration de planification, un capteur template avec une macro, une liste triée des heures, et une automatisation qui compare l'heure en cours à ce résultat. Ça fonctionne, et des gens maintiennent exactement cette installation depuis des années. C'est aussi beaucoup de pièces mobiles pour une question qui a une réponse d'un mot : est-ce le bon moment ?

Le hub répond lui-même à cette question. Il connaît les prix de chaque période de 15 minutes, il peut donc déterminer quelles périodes sont bon marché, et il publie le résultat sous forme de fenêtre : ouverte ou fermée, jusqu'à quand, et quand la suivante commence.

Ce qu'il ne fait pas, c'est agir en conséquence. Cette partie vous revient.

Ce qu'est une fenêtre

Vous décrivez la règle ; le hub l'évalue sur les prix qu'il a.

Deux seuils plutôt qu'un seul dans la première règle ne relève pas du détail : un prix qui oscille autour d'un seul nombre ferait clignoter la fenêtre à chaque période. Laissez-vous un écart.

À côté des règles, il y a deux indicateurs simples — achat bon marché sous et vente basse sous — qui disent quelque chose du prix à l'instant, sans planification ni hystérésis. L'indicateur de vente est le plus utile sur une installation qui produit : c'est le signal que votre propre énergie vaut plus consommée qu'exportée.

Huit règles est la limite. Une neuvième est refusée plutôt que silencieusement ignorée.

Lisez l'état, pas le message

C'est le seul conseil qui décide si votre automatisation fonctionne.

L'état de la fenêtre est republié à chaque limite de 15 minutes, et immédiatement à chaque changement — une fenêtre qui s'ouvre ou se ferme, de nouveaux prix qui arrivent, une règle modifiée. C'est un état, pas une annonce.

Construisez donc sur la valeur courante. Une automatisation qui traite chaque publication comme un événement se déclenche en boucle pendant toute une longue fenêtre, et manque la transition survenue pendant son redémarrage. Une automatisation qui demande « cette fenêtre est-elle active ? » est juste à chaque instant, y compris au moment où elle revient.

Le lire depuis Home Assistant : les deux routes, telles qu'elles sont aujourd'hui

Ici, la réponse honnête dépend de la façon dont vous faites tourner le hub.

Sur la route propre au hub, via MQTT, l'état arrive sous forme de message retenu sur rbgrid/<mac>/price — moins d'un kilo-octet, avec une entrée par règle : son nom, si elle est active, jusqu'à quand, et quand elle recommence. « Retenu » est le mot important : tout ce qui se connecte plus tard reçoit l'état courant immédiatement, donc un redémarrage ne vous coûte rien. Le message est au format JSON ; la forme habituelle est un capteur MQTT avec un template qui extrait la règle qui vous intéresse — la référence du hub contient un exemple complet de ce cas, avec les noms des champs.

Sur la route ESPHome, les fenêtres sont aussi des entités : un capteur binaire par règle, sur l'appareil du hub, à on tant que la fenêtre est ouverte, avec l'heure de fermeture et celle de la prochaine ouverture. À côté, un indicateur prix bon marché, un indicateur prix de vente bas et un capteur de rang pour la période en cours. Ils se rafraîchissent chaque minute et immédiatement après chaque événement de prix du hub.

Une automatisation se résume donc à une condition d'état sur une seule entité, sur l'une ou l'autre route. Le rang, puisqu'il apparaît aux deux endroits : c'est la place de la période actuelle parmi les périodes du jour dont les prix sont connus — 1 étant la plus basse, le dénominateur étant le nombre de périodes pour lesquelles le hub a des prix jusqu'ici.

⚠️ Si votre intégration est plus ancienne que cela, les fenêtres ne sont pas des entités et l'état doit être demandé — par une action qui renvoie la même structure que celle du message MQTT. La recette pour cela est un capteur template déclenché par événement, et elle fonctionne toujours ; elle n'est simplement plus nécessaire. Mettez à jour l'intégration et l'étape disparaît.

Une limite à garder en tête : les capteurs par règle ont été vérifiés en test, et non observés en train de s'ouvrir sur un hub en service, car le banc a été mis hors tension avant qu'une fenêtre n'arrive. La correspondance est contrôlée ; le fait de la voir ne l'est pas encore.

Ce à quoi se résume une automatisation

La plomberie diffère, comme ci-dessus. La logique, elle, ne change pas, et une fois l'état accessible à votre automatisation, cela tient en trois lignes :

1. La fenêtre appelée Boiler est-elle active ? — interrogez l'état.
2. Oui → votre automatisation allume l'interrupteur du chauffe-eau.
3. Non → votre automatisation l'éteint.

Toute décision après l'étape 1 revient à Home Assistant. Le hub n'a fourni qu'un booléen et la raison de celui-ci.

Et les ouvertures et fermetures sont aussi écrites dans le journal du hub, de sorte que vous pouvez relire après coup ce qui s'est passé pendant que vous ne regardiez pas :

price: window 'Boiler' on until <time>
price: window 'Boiler' off, next <time>

Le seul blueprint livré, et à quoi il sert

L'intégration apporte deux blueprints. Le premier, RBgrid — notify on hub events, fait ce que son nom indique : il notifie. Sa liste de types d'événements par défaut couvre les événements matériels et de connexion — flux inverse, module disparu ou revenu, nœud hors ligne ou en ligne, bus bloqué, firmware, pannes.

Les événements de prix ne figurent pas dans cette liste par défaut. Vous pouvez ajouter vous-même le type price, et vous serez alors notifié des fenêtres — ainsi que de chaque autre événement de prix, y compris chaque récupération réussie, car ils partagent un même type et ne peuvent pas être séparés.

Le second, RBgrid — cheap window turns a switch on and off, prend un capteur de fenêtre et un interrupteur, une lampe, un ventilateur ou un booléen d'entrée, avec une option d'inversion. Il faut être précis sur ce que cela signifie, car c'est la même limite que partout ailleurs dans cet article : l'automatisation commute ; le hub signale. Le blueprint est une automatisation préparée, pas une capacité du compteur.

Ce que le hub ne fera jamais

• Il ne commande rien. Il n'a pas de relais, et aucun réglage ne lui fait allumer quoi que ce soit.
• Il ne planifie pas pour vous au-delà de la règle. Une règle décrit les périodes qui répondent à un critère ; le hub l'applique et indique le résultat.
• Il n'y a pas de fenêtres côté vente. Les fenêtres utilisent le prix d'achat tout compris. Pour l'export, l'indicateur vente basse est le signal.
• Rien ne se passe sans horloge réglée. Les règles décrivent des heures et des jours ; un hub dont l'horloge n'est pas synchronisée ne peut pas les situer.

Quand elle ne s'est pas ouverte alors que vous l'attendiez

• Vérifiez que les prix sont arrivés — et lisez le paragraphe suivant, car c'est le cas le plus courant. Une règle sur les périodes les moins chères d'une plage a besoin des prix de cette plage. Le journal du hub indique ce qui a été enregistré et quand.
• Vérifiez les deux seuils. Des seuils égaux font clignoter la fenêtre ; un écart trop large la maintient fermée.
• Vérifiez l'horloge. Voir ci-dessus — c'est celle qui passe inaperçue.
• Vérifiez le prix utilisé pour la période. Si la source a échoué et que votre plan a couvert la période, la fenêtre a été évaluée avec le tarif du plan, qui est un autre chiffre. Le journal indique la source pour chaque période.

La nuit où les prix de demain sont arrivés en retard

Cela mérite un paragraphe à part, car cela produit une fenêtre qui semble fausse alors qu'elle ne l'est pas.

Le hub n'attend pas les prix et ne saute pas les heures pour lesquelles il n'a pas de prix de marché. Il classe chaque période de la fenêtre au prix qu'il facturerait pour cette période — la source du marché, puis votre source de secours, puis le tarif de zone de votre plan avec ses frais et sa TVA. Ensuite, il redécide en continu : quand les prix arrivent, la fenêtre se déplace vers les heures réellement les moins chères parmi celles qui restent à venir.

Deux conséquences, et toutes deux relèvent d'un comportement honnête plutôt que d'une panne :

• la fenêtre peut s'ouvrir à un moment auquel vous ne vous attendiez pas — le soir, si les prix du marché de la journée y sont plus bas que le tarif de votre plan, ou la nuit au tarif du plan quand rien d'autre n'est connu ;
• la fenêtre peut durer moins longtemps que demandé. Une période déjà écoulée n'est pas annulée ; si le nouveau groupe le plus bas inclut des périodes passées, elles comptent comme choisies et ne peuvent plus tourner, et le hub ne complète pas la nuit par des périodes supplémentaires. Le lendemain est normal.

Si les prix n'arrivent jamais, tout est classé au tarif de votre plan et la fenêtre tombe sur les périodes les moins chères du plan — généralement la zone de nuit, si votre plan en a une.

Dans chacun de ces cas, la fenêtre s'est ouverte correctement pour les données que le hub avait à ce moment-là. Le journal des événements montre chaque déplacement, et la colonne source du journal des prix indique les périodes tarifées à partir du plan plutôt qu'à partir du marché.

Pour aller plus loin

• Notifications de prix et fenêtres bon marché — la référence complète : chaque paramètre, les champs publiés et l'exemple détaillé.
• D'où vient votre prix — comment une période reçoit son prix en premier lieu.
• Événements — le journal propre au hub, y compris les lignes de fenêtre ci-dessus.
• Deux façons d'utiliser RBgrid — le choix de route dont dépend le dernier tiers de cet article.