Ici un petit récap des données qui vont me permettre d’enregistrer les données de la dernière session de charge dans sensor.wallbox_charges.
J’ai déjà décrit toutes les entités de l’intégration Wallbox sur ce Retex :
Je préviens tout de suite, ce Retex n’est qu’à vocation pédagogique, je le rédige pour partager une méthodologie, à savoir que j’ai réalisé cette fonctionnalité différemment depuis, donc je n’ai pas ce process en prod. Lire la suite
Mon objectif est de réaliser une animation via un gif animé.
Je pourrai changer de gif en fonction de l’état d’une entité.
A noter que l’intégration décrite ci-dessous ne peut fonctionner que si la clé USB/RS485 est le seul équipement du bus RS485 connectée au EM112. En effet (et grâce à l’aide d’Eric G.) J’ai compris qu’il ne pouvait y avoir qu’un seul équipement maitre sur le bus. Or le maitre est celui qui interroge et l’esclave celui qui répond. l’EM112 est donc esclave.
Mon idée première était de sniffer les trames de dialogues entre l’EM112 et ma Wallbox, la Wallbox étant maitre, je ne peux faire cela. Pour la beauté de l’exercice, j’ai testé avec deux maitres, cela fonctionne on retrouve des valeurs mais de temps en temps, quand les deux maitres posent une question ensemble, on se retrouve avec une erreur.
Si quelqu’un peut m’orienter vers une manière de « snifer » le bus 485 pour intercepter les informations que le EM112 envoie à une Wallbox par exemple, je suis preneur car à ce stade, je ne peux avoir une Wallbox et une Clé RS485/USB en parallèle (deux maitres).
Pour pouvoir indiquer à mes automatisations ou scripts si j’autorisais ou pas l’arrosage automatique, je voulais créer un switch « virtuel », qui n’a de lien avec aucune entité (donc pas un template) et qui conserve son état à la relance de Home Assistant (persistant).
Voici la bête :
Il faut un peu peur avec ses 10 connecteurs à vis et son grand écran plein de chiffres.
J’avais supprimé en juillet dernier l’intégration Pronote, je repars donc tout neuf pour réactiver tout cela pour la rentrée de septembre.
Attention, pour cette rentrée, il est nécessaire d’installer la dernière modification de delphiki (passage en pronotepy 2.12.1), sinon l’authentification ne fonctionne plus. Lire la suite
Comme je l’ai expliqué dans :
Je pilote mon chauffage sur deux zones grâce à des fils pilotes. Dans le cadre de la bascule de Jeedom vers Home Assistant, il faut donc que j’arrive à piloter ces relais avec Home Assistant.
Mon objectif originel était de vouloir allumer les lumières extérieures quand le portail s’ouvre mais uniquement la nuit !
J’ai testé plusieurs intégrations :
Evidemment, ce binary_sensor prend deux valeurs :
Les plus puristes (qui cherchent les difficultés) pourront se faire plaisir et se créer un second binary_sensor pour le « il fait jour ». 😉
Code simplissime de ce binary_sensor, à créer dans binary_sensor.yaml en pensant à bien l’avoir déclaré dans configuration.yaml :
- platform: tod name: "Il fait nuit" unique_id: binary_sensor.nuit after: sunset after_offset: "-00:10" before: sunrise before_offset: "+00:10"
after_offset et before_offset à 10min, ce n’est pas par souci de perfection, c’est pour me souvenir la syntaxe de ce paramètre si je veux l’ajuster dans l’avenir.
Mon objectif est de n’allumer les lumières extérieures quand le portail s’ouvre QUE quand il faut nuit, voici donc la condition ajoutée :
Je ne mets pas la condition sur la fermeture, en effet si d’aventure il fait jour entre l’ouverture et la fermeture, les lumières resteraient allumées.
Comme évoqué dans le retex
il est surprenant de voir la vitesse à laquelle la base de données se remplie.
Dans ce retex, je vais tenter d’identifier les entités qui s’enregistrent le plus, vérifier si leur enregistrement est utile et configurer recorder de HA pour limiter la taille de la base. Lire la suite
