Savoir quand l'énergie est la moins chère, à temps pour l'utiliser

Vous pouvez consulter les prix d'hier sur n'importe quel écran. Ce qui est difficile, c'est de savoir, à l'instant, si cette période de 15 minutes fait partie des moins chères, et de faire agir quelque chose en conséquence sans comparer les prix à la main et sans tout réécrire à chaque changement de tarif.

Le hub fait la comparaison. Il détermine quelles périodes sont les moins chères selon les règles que vous définissez, et publie un petit message indiquant ce qui est ouvert maintenant et ce qui s'ouvre ensuite. Un autre élément lit ce message et agit.

⚠️ Le hub ne commute rien. Il n'a pas de relais, et aucun réglage ne lui permet d'allumer ou d'éteindre quoi que ce soit. Il calcule des fenêtres et les publie. La décision et la commutation reviennent à ce qui lit la notification : une automatisation Home Assistant, un répartiteur, une borne de recharge abonnée elle-même à MQTT. Si vous cherchez un appareil qui pilote une charge selon son prix, ce n'est pas celui-ci.

Ce n'est pas réservé aux prix dynamiques

Les règles portent sur le prix d'achat tout compris de chaque période de 15 minutes : le prix dynamique lorsqu'il couvre cette période, et sinon le tarif de la zone de votre forfait, avec ses frais. Un hub sur un simple forfait à heures pleines et heures creuses obtient donc lui aussi des fenêtres bon marché : elles suivent simplement vos propres zones, et les frais de réseau selon l'heure entrent dans la comparaison comme le reste.

Cette page vaut donc la peine d'être lue, que vous utilisiez ou non les prix dynamiques. Ce qui change avec un prix de marché, c'est l'amplitude des déplacements des périodes bon marché d'un jour à l'autre ; le mécanisme reste le même.

Les règles exigent que l'horloge du hub soit réglée, et elles utilisent le fuseau horaire du hub pour définir ce qu'est « un jour » et ce qu'est « 07:00 » — voir Time.

Trois types de règle

Jusqu'à huit règles, chacune avec un nom que vous choisissez et qu'on peut activer ou désactiver individuellement. Un nom compte au plus 23 octets tel que le hub le stocke : l'application l'indique clairement, et une lettre cyrillique compte pour deux.

Prix inférieur à un seuil

L'application l'appelle Price below a level. Vous indiquez un prix à ce niveau ou en dessous duquel la fenêtre s'ouvre, et un prix à ce niveau ou au-dessus duquel elle se ferme. La fenêtre est un signal ; ce qu'on en fait reste à la charge de ce qui la lit.

Les deux seuils existent pour qu'un prix qui oscille autour d'une valeur ne fasse pas clignoter la fenêtre à chaque période. Si vous les mettez égaux, vous obtenez exactement ce clignotement : laissez donc un écart.

Utilisez-la quand votre seuil est absolu : « fonctionner chaque fois que l'électricité coûte moins de 10 centimes. »

Périodes les moins chères dans une plage horaire

L'application l'appelle Cheapest periods in a time span — « for a load that can run any time in a span, such as a water heater ». Vous indiquez un nombre de périodes de 15 minutes et les heures dans lesquelles les chercher.

Utilisez-la quand la durée de fonctionnement est ce que vous connaissez : « les quatre périodes de 15 minutes les moins chères entre 22:00 et 06:00. » Avec consecutive activé, vous obtenez une heure ininterrompue au lieu de quatre périodes dispersées — ce qu'il faut pour tout ce qui supporte mal d'être interrompu.

Périodes les moins chères avant une heure donnée

L'application l'appelle Cheapest periods before a time — « for a load that must be done by a time, such as an EV by 07:00 ». Même principe que ci-dessus, ancré sur l'heure à laquelle la charge doit être terminée.

Le hub examine chaque jour les 24 heures qui se terminent à cette heure, et y choisit les périodes les moins chères.

Utilisez-la quand l'échéance est la vraie contrainte : « deux heures de fonctionnement avant 07:00, en choisissant les deux heures les moins chères de la nuit pour le faire. »

Une règle est refusée plutôt que tronquée discrètement si elle ne peut pas être satisfaite : demander plus de périodes que la fenêtre n'en contient est renvoyé avec le nom du champ fautif. C'est volontaire : une fenêtre raccourcie en silence pour tenir ne serait pas la règle que vous avez écrite.

Deux indicateurs, pour quand vous n'avez pas besoin d'une fenêtre

En plus des règles, deux niveaux simples :

Un niveau non renseigné laisse son indicateur à faux. Ce ne sont pas des fenêtres : il n'y a ni hystérésis ni anticipation, seulement une affirmation sur le prix de l'instant. L'indicateur de vente est celui à surveiller sur un site disposant d'une production : c'est le signal bon marché pour utiliser sa propre énergie au lieu de l'exporter.

Ce qui est publié

Un message, de moins d'un kilo-octet, sur rbgrid/<mac>/price — retenu, afin que tout ce qui se connecte plus tard reçoive immédiatement l'état actuel. Il est aussi disponible à GET /api/v1/signal, et dans la version ESPHome via rbgrid_cmd.

C'est un état, pas un événement

La notification est republiée à chaque limite de période de 15 minutes, et immédiatement dès que quelque chose change — une fenêtre qui s'ouvre ou se ferme, de nouveaux prix qui arrivent, une règle ou un seuil modifié.

Construisez votre automatisation sur la valeur actuelle, pas sur l'arrivée d'un message. Un consommateur qui traite chaque publication comme un événement se déclenchera à répétition pendant une longue fenêtre, et manquera une transition survenue pendant qu'il était hors ligne. Un consommateur qui lit windows[].active et agit selon ce qu'il indique est juste à chaque instant, y compris au moment où il se reconnecte — c'est à cela que sert retained.

Les ouvertures et fermetures sont aussi écrites dans le journal du hub, où vous pouvez les relire ensuite dans Events :

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

L'exemple, dessiné honnêtement

Une chaudière qui fonctionne pendant les deux heures les moins chères de la nuit :

1. Sur le hub : une règle nommée Boiler, de type cheapest periods of a daily window, 8 périodes, de 22:00 à 06:00, avec consecutive activé.
2. Dans Home Assistant : une automatisation déclenchée par le sujet MQTT rbgrid/<mac>/price (ou, dans la version ESPHome, par l'entité propre du hub).
3. Sa condition lit l'entrée nommée Boiler dans windows[]. Active — Home Assistant allume l'interrupteur de la chaudière. Non active — elle l'éteint.

Chaque décision de cette liste après l'étape 1 relève de Home Assistant. Le hub n'a apporté qu'une phrase : cette période fait partie de la fenêtre que vous avez décrite. Un répartiteur, ou une borne de recharge abonnée au sujet lui-même, fonctionne de la même façon, et la répartition des rôles est identique : le hub énonce un fait sur le prix, l'autre appareil décide quoi en faire.

Cela signifie aussi que le hub ne peut pas être la cause d'un échec. Si l'automatisation ne s'est pas déclenchée, la notification est la première chose à lire : elle indique ce que le hub croyait, et cela se vérifie.

Ce qu'il ne fait pas

• Aucune commutation d'aucune sorte par le hub. C'est tout le principe de conception, et non une lacune en attente d'être comblée.
• Huit règles. Une neuvième est refusée, et non ignorée en silence.
• Pas de fenêtres côté vente. Les fenêtres utilisent le prix d'achat tout compris ; pour l'export, utilisez l'indicateur sell is low.
• Rien ne se produit sans horloge réglée. Les règles décrivent des heures et des jours, et un hub dont l'horloge n'est pas synchronisée ne peut pas les situer.

Lorsque cela ne fonctionne pas comme prévu : quoi vérifier

Une fenêtre ne s'ouvre jamais. Lisez la notification elle-même — windows[] porte next_start pour chaque règle active. Si next_start est présent, la règle fonctionne et vous êtes en avance. Si la règle manque dans la liste, elle est désactivée.

Une fenêtre s'ouvre à une heure différente chaque jour, alors que j'en attendais une fixe. C'est une règle de périodes les moins chères qui fait son travail : les périodes bon marché se déplacent quand les prix bougent. Si vous voulez les mêmes heures chaque jour, c'est une zone de votre forfait qu'il vous faut, et non une fenêtre.

La fenêtre clignote. Une règle de prix inférieur à un seuil dont les deux niveaux sont trop proches, avec un prix situé entre les deux. Élargissez l'écart entre la mise en marche et l'arrêt.

Ma règle a été refusée à l'enregistrement. La réponse nomme le champ. Les deux cas habituels : plus de périodes que la fenêtre ne peut en contenir, ou un prix d'arrêt inférieur au prix de mise en marche.

Les fenêtres ignorent le prix dynamique et suivent mon forfait. Elles suivent le prix d'achat tout compris de chaque période, qui revient au forfait chaque fois qu'aucun prix dynamique ne couvre cette période. Vérifiez le champ provenance dans la notification : plan signifie qu'aucun prix de marché n'était en vigueur pour cette période — voir Where your price comes from.

rank_buy vaut 0. Le rang n'a pas encore de dénominateur : les prix d'aujourd'hui ne sont pas entièrement connus. Il se complète à mesure que les prix arrivent.

Mon automatisation se déclenche sans cesse pendant une même fenêtre. Elle se déclenche sur le message au lieu de lire l'état. La notification est republiée toutes les 15 minutes par conception ; conditionnez l'automatisation sur windows[].active.

Mon automatisation a manqué une fenêtre que le journal indique comme ouverte. Le consommateur était hors ligne au moment de la transition et attend un événement qui a déjà eu lieu. Lisez le message retenu à la connexion — c'est pour cela qu'il est retenu.

Les heures sont fausses d'un décalage fixe. Les règles utilisent le fuseau horaire du hub, et non celui de votre téléphone ou de Home Assistant. Vérifiez Time.

Je veux que la fenêtre tienne aussi compte de mon terme de puissance. Ce n'est pas le cas : les fenêtres portent sur le prix par kilowattheure. Le pic d'import d'un cycle de facturation est mesuré séparément et n'est intégré à aucun prix : voir Import peaks.

⚠️ Pour toute intervention à l'intérieur d'un tableau électrique, faites appel à un électricien qualifié.