Home Assistant, restauration d'état après une coupure secteur

Comme d'aucuns ont pu le remarquer, les ampoules connectées s'allument après une coupure secteur (Mi, Hue, Ikea, Tuya, etc...)., c'est logique car si on les actionne depuis un inter d'origine il faut bien que l'ampoule répondre en dehors de tout contexte domotique, bien que certaines, Shelly par exemple, permettent comme les prises commandées et modules de choisir cet état.

Pour palier à ce problème et ne pas retrouver toutes mes ampoules allumées quand je rentre à cause d'une coupure ayant eu lieu dans la journée, j'ai fait un groupe d'ampoules (dans light.yaml) à éteindre après que l'onduleur ait signalé la reprise électrique (ça sous entend bien sur d'avoir configuré un addon sur l'onduleur afin d'avoir le binay_sensor: idoine).

- platform: group
  name: Groupe de Coupure
  entities:
    - light.tuya_cour_1
    - light.tuya_cour_2
    - light.tuya_chevet
    - light.tuya_strip_antoine
    - light.hall_1
    - light.hall_2
    - light.cuisine_led
    - light.sejour_led
    - light.cuisine_lampe_de_table
    - light.bureau_led_bt
    - light.ikea_r14_entree
    - light.ikea_e27_tv

Et une petite automation :

- alias: P - Light OFF après reprise électrique
  description: ''
  trigger:
  - platform: state
    entity_id: binary_sensor.ups
    from: 'off'
    to: 'on'
  condition: []
  action:
  - service: light.turn_off
    data: {}
    entity_id: light.groupe_de_coupure

Ca fonctionne mais ce n'est pas satisfaisant car ça éteint toutes les ampoules, et pas seulement celles qui étaient éteintes avant la coupure. J'ai commencé par me dire qu'idéalement il faudrait connaitre leur état avant la coupure, le stocker dans des input quelque chose et faire une automation de malade à exécuter lors du rétablissement électrique. Ca m'a donné mal au crane et j'ai procrastiné la chose...

Et puis, en discutant dans notre groupe préféré et confidentiel, la lumière jaillit ! Il y a une fonctionnalité souvent peu utilisée dans Home Assistant, ce sont les scènes. En général on crée une scène, genre j'allume des ampoules à telle ou telle intensité ou couleur, je baisse les stores, et je lance un film sur Netflix... Mais, si on lit la doc jusqu'au bout on découvrira que l'on peut également créer des scènes à la volée, un peu comme un snapshoot de l'état de certaines entités.

Et là ça devient très simple. Si une ampoule n'est plus alimentée, elle ne signale pas son état à Home Assistant. Il suffit alors d'enregistrer son état dans une scène dès lors que le binary de l'onduleur passe à OFF :

- alias: P - Sauve l'état des lampes lors d'une coupure
  trigger:
  - platform: state
    entity_id: binary_sensor.ups
    from: 'on'
    to: 'off'
  condition: []
  action:
  - service: scene.create
    data:
      scene_id: light_state
      snapshot_entities:
      - light.tuya_cour_1
      - light.tuya_cour_2
      - light.tuya_chevet
      - light.tuya_strip_antoine
      - light.hall_1
      - light.hall_2
      - light.cuisine_led
      - light.sejour_led
      - light.cuisine_lampe_de_table
      - light.bureau_led_bt
      - light.ikea_r14_entree
      - light.ikea_e27_tv

Et de restaurer la scène quand celui ci passe à ON :

- alias: P - Restaure l'état des lampes lors d'une coupure
  trigger:
  - platform: state
    entity_id: binary_sensor.ups
    from: 'off'
    to: 'on'
  condition: []
  action:
  - delay : '00:00:60' # On ajoute une temporisation afin que les ampoules se reconnectent
  - service: scene.turn_on
    data:
      entity_id: scene.light_state

Et on retrouve l'état de l'éclairage avant qu'Enedis ait sévit. Car si les coupures électriques sont peu fréquentes en ville, à la campagne le moindre aléa climatique en provoque, ce qui en dit long sur l'état du réseau. 

J'ai pris ici l'exemple de l'éclairage lors d'une coupure secteur. Mais il est tout à fait possible de restaurer ainsi l'état d'autres entités, mais également de s'en servir dans d'autres contextes, par exemple sauvegarder un état d'éclairage avant de fermer les volets ou de regarder un film, et de le restaurer ensuite. Avec Emby (et surement d'autres triggers) on peu par exemple jouer deux états selon que l'on appuie sur PLAY ou PAUSE... La suite n'étant qu'une question d'imagination ;-)

 

 

Home Assistant & Planification, la suite !

Ce qui déroute souvent quand on débute avec Home Assistant c'est l'absence de planificateur intégré, alors même que la chose parrait évidente. Il y a tout de même plusieurs façons de planifier des évènements et on a déjà examiné ici plusieurs solutions :

  • En codant des des automation basées sur des input_time, etc... On peut obtenir quelque chose de très personnalisé. Mais il faut pas mal d'huile de coude.
  • Avec des agendas externes comme Google Agenda ou Microsoft 365, ou encore des agendas plus geeks... (ics, etc).

Il y a une autre solution qui bien que dépourvue d'interface est vraiment très puissante, mais un peu compliquée à appréhender. Je veux parler de Shedy. Ca impose d'installer AppDaemon et ensuite ça se passe en YAML, à ceci près que sous AppDaemon la prise en compte des modifications apportées au code YAML est dynamique, et ça c'est très sympa.  AppDaemon c'est un addon qui s'installe dans la section addon de HA et je m'en sert également pour ControlerX. 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 de tous les paramètres, là ou les autres se contentent de faire ON au début et OFF à la fin (ou augmenter la consigne et la baisser).

Depuis peu il y a aussi les BluePrint, ça va changer beaucoup de choses sous HA et surement permettre de proposer des planifications simples et prêtes à l'emploi.

On a peut être aussi des possibilités avec NodeRed, mais pour moi c'est non, vous le savez, je n'aime pas. 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.

Et puis il y a le Scheduler dont je veux vous parler aujourd'hui et pour lequel je vous conseille de suivre cette conversation.

L'idée de son auteur est de créer un scheduler entièrement graphique, donc à l'opposé de Schedy. A vrai dire j'aurais préféré qu'il fasse une interface pour Schedy. Mais les développeurs sont ce qu'ils sont et lui est parti sur deux modules, un composant moteur et une carte d'interface. Du coup si l'interface est très réussie il reste encore des choses à voir coté motorisation pour arriver au niveau de Schedy, qui lui gère notamment la notion de re planification dynamique. Attention, ce n'est pas un reproche, Niels a fait un travail remarquable en très peu de temps, et comme c'est un perfectionniste, je ne doute pas qu'au fil des semaines cet outil, déjà totalement utilisable, gagnera en fonctionnalités.

Je vous passe les détails de l'installations décrits ici, et , en gros on installe le composant depuis HACS, on redémarre et on installe la carte. Ensuite on va créer une carte à laquelle on attribuera des objets à planifier avec des conditions. Par exemple, je veux que le thermostat de la cuisine passe à 21° tous les matins à 07:15 et qu'il repasse à 19.5° à 09:00 (avec plusieurs plages possibles dans la journée), mais à condition que nous soyons en semaine, que le commutateur qui autorise le chauffage soit à ON et que je ne soit pas en voyage, etc...

On va donc créer une carte avec les objets dont on a besoin que l'on peut choisir par type ou mieux individuellement. Par exemple un thermostat, et les input_bolean: Chauffage ON/OFF et Mode Absent ON/OFF : 

Je prends l'exemple des thermostats qui me préoccupait, mais on peut bien sur planifier tout ce qui est actionnable, directement, via des scripts ou des scènes.

Il est bien sur possible de faire ça par le code, ce qui permet en plus d'ajouter des options de présentation de la carte. Personnellement j'ai choisit d'utiliser une carte de type "Vertical Stack" "Panel Mode", ce qui sera bien plus agréable à utiliser pour planifier une journée. Ce mode n'est pas très adapté au mobile, mais c'est le genre de choses que je fais depuis mon PC.

type: vertical-stack
cards:
  - type: 'custom:scheduler-card'
    discover_existing: false
    display_options:
      primary_info:
        - '<b>{entity} / {name}</b>'
      secondary_info:
        - >-
          <b>Next</b> : {relative-time} ({days} {time}) | <b>Action</b> :
          {action} ({additional-tasks})
      icon: 'mdi:radiator'
    include:
      - climate.daikin
      - input_boolean.thermostats_ac_on_off
      - input_boolean.thermostats_away
      - input_boolean.thermostats_on_off
      - input_select.chauffage
    title: AC Daikin
  - type: 'custom:scheduler-card'
    discover_existing: false
    display_options:
      primary_info:
        - '<b>{entity} / {name}</b>'
        - '<b>Next</b> : {relative-time} | <b>Action</b> : {action}'
        - additional-tasks
      secondary_info:
        - '{days} {time}'
      icon: 'mdi:radiator'
    include:
      - climate.thermostat_lionel
      - input_boolean.thermostats_ac_on_off
      - input_boolean.thermostats_away
      - input_boolean.thermostats_on_off
      - input_select.chauffage
    title: Thermostat Chambre Lionel

J'utilise ici une carte de la pile pour chaque thermostat et dans chaque carte je vais pouvoir ajoute plusieurs planifications. Par exemple une pour la semaine et une pour les week-end et jours fériés. A noter que workday: est supporté, ce qui simplifie grandement la gestion des jours férié. A droite de chaque planification on a un interrupteur qui permet d'activer ou désactiver la planification, fonction également possible par une automation. On peut également la laisser activée et la soumettre à une condition pour peu qu'on ait associé l'objet idoine, un input_bolean: par exemple...

Quand on ajoute une entrée on choisit l'objet sur lequel on peut agir, ici un thermostat, on précise l'entité et le type d'action unique à exécuter (allumer, éteindre plus adapté à d'autres équipements, ou mieux de faire un schéma, ce qui sera pleinement adapté à un thermostat :

Par exemple ici j'ai choisit de chauffer le séjour, le week-end, de 08:00 à 22:30 à 21.5°. Sauf que si on laisse la chose en l'état à 22:30 le thermostat continuera à chauffer à 21.5°. La logique actuelle veut que l'on crée une plage suivante avec une autre température, mais également une précédente, contrairement à Schedy qui lui va considérer une température de base (Eco) et uniquement augmenter les plages définies pour revenir ensuite à sa température de base.

Le développeur me répond qu'il ne veut pas faire un planificateur trop spécifique au chauffage. Mais je pense l'avoir convaincu de changer sa logique, et pour chaque plage définie ainsi prévoir une action de début et une action de fin, ce qui me paraitrait un bon début.

Il n'y a pas ici d'options de replanification dynamique. Si Home Assistant redémarre, le thermostat conservera son état (à condition de ne pas utiliser l'option initial_hvac_mode:), par contre face à d'éventuelles coupures secteur, il faut utiliser des actionneurs capables de retrouver leur état avant coupure et de les configurer ainsi. C'est les cas des Shelly ou des cartes IPX800, mais certains actionneurs resteront muets après coupure et ne sont donc pas conseillés pour cette utilisation.

Avec le bouton Options en bas à droite on va pouvoir ajouter des conditions supplémentaires basées sur l'état des entités que l'on aura choisies, ici un input_bolean: qui conditionne le fonctionnement du chauffage. Donc si cette condition n'est pas remplie la planification ne s'exécutera pas, la validation se faisant en début de planification. 

J'ai par exemple un input_bolean: qui conditionne le chauffage des chambres de ma fille et mon fils qui vivent à l'autre bout de la France. Ce commutateur s'actionne soit manuellement, soit en en fonction de leur date d'arrivée que j'aurais saisie (et peut être un jour automatisée en fonction des billets TGV reçus... ou en fonction de leur localisation...).

Voilà pout un petit tour rapide. Alors vous allez me demander pourquoi utiliser une solution plutôt qu'une autre ? Il y a plusieurs questions à se poser, la plus évidente étant de savoir si vous êtes le seul à agir ou si vous voulez un système plus WAF accessible à tous les membre de la maison.

Par exemple j'ai monté un Home Assistant chez mon frère, ce n'est pas un geek et je n'avais pas l'intention d'intervenir chaque fois qu'il souhaite ajuter ses plages de températures. Au départ j'avais basé ses planifications sur Google Agenda, une solution qui fonctionne très bien, mais pas idéale coté expérience utilisateur, en effet cela nécessitait deux interfaces, celle de HA et celle de Google Agenda. De plus les jours fériés n'étaient pas pris en compte (il aurait fallut faire des automations plus complexes). J'ai donc remplacé tout ça par ce Scheduler et ça lui va très bien.

En ce qui me concerne j'ai le nez dans le code et j'avais dès le début fait pas mal d'automations pour gérer les différentes situations (présent, absent, j'ai du monde à diner, à coucher, des amis passent le week-end ici, etc...) et pour l'instant ça reste ainsi. Mais mon installation est également un labo et j'ai installé Schedy pour le tester en live, notamment au niveau des conditions et situations particulières. J'aimerais aussi pouvoir le personnaliser avec un minium de GUI. Je ne suis pas un bon exemple à suivre...

En conclusion je dirais que ce Scheduler est vraiment ce que tout le monde attendait et qu'il couvrira la majorité des besoins. Après il y avait un vague projet de scheduler intégré au core, mais pour l'heure ça reste une arlésienne.

 

Home Assistant & Tuya zéro cloud

On le sait tous, la domotique nous fait acheter beaucoup de bricoles qui souvent deviennent obsolètes, bref il y a toujours mieux. Par exemple les prises et autres objets Tuya ou Sonoff qui nécessitent le cloud, alors qu'un prise Shelly dispose de base de MQTT, peut être flashée avec ce que l'on souhaite et dans tous les cas fonctionne en local. Bien sur on ne va pas parler des prises en RF433 genre DIO mise au rebus faute de retour d'état, pas plus que des solutions Zigbee qui se traitent autrement. Tuya c'est du matériel OEM disponibles en marque blanche que des entreprises peuvent distribuer sous leur étiquette. Je trouve d'ailleurs scandaleux qu'une marques comme Konyks soit labelisée French Tech alors qu'il se contente de distribuer de produits chinois sous leurs marque sans aucune R&D... Bref !

Nous avons donc en Wi-Fi...

  • L'écosystème Sonoff : en dehors de quelques modèles DIY, il faudra en général ouvrir et souder pour flasher. Heureusement il existe une intégration qui permet leur utilisation en local / cloud. En gros l'intégration mets à jour à intervalles réguliers ce qu'il trouve sur le cloud Sonoff et les actions sont ensuite locales.
  • L'écosystème Tuya : de base 100% cloud et géré nativement par HA, mais on va voir plus loin comment contourner ça.
  • L'écosystème Shelly : Cloud ou 100% nativement local et MQTT, flashable si vous aimez ça. C'est clairement ce que je vous conseille pour de nouveaux achats.

Tuya sans cloud

Heureusement il y a des petits malins qui adorent faire du reverse engineering, ce qui va nous permettre d'utiliser nos produits Tuya localement avec bien souvent plus de fonctionnalités, comme par exemple la remontée des information de consommation qui ne se fait pas de base sous HA.

Dans tous les cas, comme pour les produits Xiaomi/Aqara, il faudra trouver la clé... Au fil du temps les méthodes changent, mais aujourd'hui ça n'a jamais été aussi facile. Je vous conseille donc de récupérer vos clés, même si vous ne comptez pas les utiliser tout de suite.

On part du principe que vous avez un compte Tuya/ SmartLife (ou une application OEM comme celle de Konyks, c'est la même chose) et que vos équipements y sont enregistrés. En substance on va passer par la plateforme IoT de Tuya sur lequel vous allez vous créer un compte développeur et suivre les instructions de cet article dont je me suis inspiré. (Je ne suis pas sur que tout soit utile, vous me direz...).

  1. Créez un nouveau compte sur iot.tuya.com et assurez-vous que vous êtes connecté. Allez dans Cloud -> Projet dans le tiroir de navigation de gauche et cliquez sur "Create". Après avoir créé un nouveau projet, cliquez dessus. L'ID d'accès et la clé d'accès sont équivalents à la clé d'API et aux valeurs secrètes d'API requises.
  2. Allez dans App -> App SDK -> Development dans le tiroir de navigation. Cliquez sur "Create" et entrez ce que vous voulez pour les noms de package et Channel ID (pour le nom du package Android, vous devez entrer une chaîne commençant par com.). Prenez note de l' ID de chaîne que vous avez entré. Cela équivaut à la valeur schema requise plus loin. Ignorez les clés d'application et les valeurs secrètes d'application que vous voyez dans cette section car elles ne sont pas utilisées.
  3. Allez dans Cloud -> Projet et cliquez sur le projet que vous avez créé précédemment. Cliquez ensuite sur "Link Device". Cliquez sur l'onglet «Link devices by Apps», puis sur «Add Apps». Vérifiez l'application que vous venez de créer et cliquez sur "Ok".
  4. Toujours dans Cloud -> Projet et cliquez sur le projet que vous avez créé précédemment. Cliquez ensuite sur "Link Device". Cliquez sur l'onglet «Link devices by App Account», puis Add App Account et ajouter votre compte Tuya/SmartLife et vous devriez retrouver vos petits....
  5. Sur la même page, cliquez sur "Groupe d'API" sur le côté gauche. Modifiez le statut en Ouvert pour les trois groupes d'API suivants en cliquant sur "Appliquer" pour chaque ligne, en saisissant une raison quelconque et en cliquant sur "OK": "Authorization Management", "Device Management", "Device Control", "User Management", "Network Management", "Data Service", "Home Management", "Device User Mangement" and "Device Statistics".. Cela peut prendre 10 à 15 minutes pour que ces modifications prennent effet.
  6. Ensuite sur Device List / App Account / Europe vous listez vos devices et vous récupérez les devices ID
  7. Enfin on va dans API Explorer / Get Device details, on choisit Europe et on rentre le device ID et par magie la local_key apparaitra.
{
  "result": {
    "active_time": 1609598200,
    "biz_type": 0,
    "category": "cz",
    "create_time": 1609598200,
    "icon": "smart/icon/154028815822y4yx2k5jz_0.jpg",
    "id": "871720fsdfsdfsfd8e997fec",
    "ip": "70.22.16.3",
    "local_key": "8dfsdfsdfsgggsg10ecb6",
    "name": "Konyks Priska Plus 6",
    "online": true,
    "owner_id": "19956557",
    "product_id": "j6cVsdgfsdfgsdfsdfeYpli",
    "product_name": "Konyks Priska Plus",
    "status": [
      {
        "code": "switch_1",
        "value": false
      },
      {
        "code": "countdown_1",
        "value": 0
      },
      {
        "code": "cur_current",
        "value": 0
      },
      {
        "code": "cur_power",
        "value": 0
      },
      {
        "code": "cur_voltage",
        "value": 2339
      }
    ],
    "sub": false,
    "time_zone": "+01:00",
    "uid": "eu15345fgsdfsdfdsf9crK3G",
    "update_time": 1609565564,
    "uuid": "8717244465sd6f46sdf7fec"
  },
  "success": true,
  "t": 1609606041296
}

Ceux qui sont familiers de Node JS pourront lancer le script comme décrit ici et obtenir toute les clés en une seule manipulation.

Ensuite on a deux solutions :

  • La première, Trade Face Tuya Gateway est indépendante de la solution domotique choisie car full MQTT, elle peut s'installer dans un Docker et nos amis encore sous Jeedom pourront ainsi en profiter.
  • La seconde, Local Tuya, est une simple intégration pour Home Assistant qui permettra de reconnaitre nos équipements en quelques clics et s'installe depuis HACS. Le discovery fera le reste et il faudra juste tâtonner un peu quand on configure un équipement Tuya pour faire correspondre les bonnes valeurs, mais c'est expliqué ici.

Vous aurez compris, ce qui compte encore une fois c'est d'avoir les clés. Ensuite il existe surement d'autre solutions pour exploiter. Attention : Pour toutes ces manips pensez à fermer l'application mobile (Tuya/SmartLife) car un équipement Tuya ne supporte qu'une seule connexion simultanée.

EDIT 04/01/2021 : Il y a un soucis dans le v3.2 ou on perd certains équipement au reboot. Revenir à la 3.1 résout le problème en attendant mieux.

Merci Yvon pour cette exploration nocturne et conjointe d'un jour de l'an sous couvre-feu & Enjoy ;-)

 

Home Assistant & Enedis

Dans le grand foutoir de la pseudo concurrence des fournisseurs d'électricité on trouve Enedis qui gère les infrastructures et vous colle d'autorité un compteur Linky. On ne va pas parler ici des polémiques que cela à suscité, sa dangerosité sanitaire est très certainement moindre que toutes les technologies que nous utilisons, tout au moins pourrais t'on s'interroger sur son cout global qui sera nécessairement répercuté sur les clients.

Ce qui m'intéresse ici c'est ce que l'on peut en faire. Enedis remonte en temps (presque) réel (toutes les heures) les informations de consommation et on peut donc imaginer qu'il est possible de récupérer facilement ces informations qui après tout nous appartiennent. En fait ce n'est pas si simple et il semblerait que ce soit tout le contraire, Enedis faisant tout pour en limiter l'usage à la consultation de son piètre site web, tout en ayant certainement une arrière pensé de monétisation possible... Ainsi, au fil du temps, les diverses extensions permettant la récupération de ces informations ont été mises en échec.

A ce jour, et d'après mes informations, la règle est que seule une société a la possibilité de demander un accès (gratuit pour l'instant) à l'API. Ca limite fortement nos habitudes de DIY !

Alors un développeur de la communauté (M4dm4rtig4n) a eu la riche idée, un projet personnel qui se sert de la façade légale de son employeur, de monter une passerelle d'accès : https://enedisgateway.tech. On lui fait confiance, il fera tout pour assurer la confidentialité des données, mais l'utilisation de cette passerelle sous entend de confier l'accès à vos données à cette société. Le risque est faible, les données peu sensibles, le jeton est révocable, et surtout rien ne vous force à utiliser cette passerelle qui pour l'instant est la seule solution fonctionnelle.

Dans la pratique

On commence, si ce n'est pas fait, par créer un compte sur le site Enedis et y associer votre compteur Linky. Attention, j'espère qu'Enedis maitrise mieux le réseau électrique que le CSS car il y a pas mal de bugs et il vaudra mieux faire tout ça avec Firefox, car aléatoirement ça ne passe pas sous Edge ou Chrome (qui est juste le navigateur le plus utilisé au Monde). Ensuite on se rend sur la passerelle (https://enedisgateway.tech) et on crée un token qui aura cette forme :

Votre token : 1ETPfWPjxmkHe2GfsggdfhdgfshgfhgfNRKnhdgfhMpOrGzKe3i

Vos points de livraison : 258465654641

Il ne faut pas oublier d'activer l'enregistrement de la consommation horaire et de sa collecte si on veut disposer des infos HP/HC. Une commande de test est fournie, elle permettra de vérifier que ça fonctionne avant de passer à la suite

curl -X POST https://enedisgateway.tech/api -H 'Authorization: 1ETPfWPjxmkHe2G2hj87w8shfgsdfghsdfghhsfghgfhjsfOrGzKe3i' -H 'Content-Type: application/json' -d '{"type": "consumption_load_curve","usage_point_id": "25464656546695","start": "2020-11-10","end": "2020-11-11"}'

A partir de là on peu repasser sous Home Assistant et installer dans HACS deux Custom repositories créés par un autre développeur de talent (saniho) de la communauté HACF, qui correspondent d'une part à un composant qui va créer un sensor personnalisé, et d'autre part une carte pour Lovelace.

Une fois ces deux installations terminées on redémarre Home Assistant, et on crée le sensor, ce qui nécessitera un nouveau redémarrage.

sensor:
    - platform: myEnedis
      token: fTEHWCldfsgsdfghsjdhjdFGHJFHSDHDSFGhfdfhNfWqwCE3
      code: 464554438199434
      heures_creuses: "[['00:00','05:00'], ['21:30', '24:00']]"
      hc_cout: 0.1337
      hp_cout: 0.1781
      scan_interval: 3600
      delay: 7200  # OPTION

Après un redémarrage et le temps que tout se mette en place, le sensor.myenedis devrait nous retourner ces informations :

attribution: ''
version: 1.0.2.5
lastSynchro: '2020-11-20T23:51:21.456065'
lastUpdate: '2020-11-20T23:51:21.456048'
timeLastCall: '2020-11-20T23:51:21.456021'
yesterday: 53347
last_week: 240629
day_1: 53347
day_2: 42741
day_3: 42420
day_4: 30767
day_5: 36311
day_6: 35932
day_7: 32130
daily:
  - 53.347
  - 42.741
  - 42.42
  - 30.767
  - 36.311
  - 35.932
  - 32.13
halfhourly: []
offpeak_hours: 19.947
peak_hours: 33.4
peak_offpeak_percent: 62.60895645490843
yesterday_HC_cost: 2.6669139000000004
yesterday_HP_cost: 5.94854
daily_cost: 8.6154539
current_week: 169275
last_month: 909684
current_month: 702447
last_year: null
current_year: 2670999
errorLastCall: >-
  {'error': 'result_404', 'enedis_return': {'error': 'no_data_found',
  'error_description': 'no measure found for this usage point', 'error_uri':
  'https://bluecoder.enedis.fr/api-doc/consulter-souscrire'}}
monthly_evolution: 0
unit_of_measurement: kWh
friendly_name: myEnedis

Vous pourrez utiliser ces données à souhait, ce sont des attributs, mais le plus simple reste de créer une carte custom et on y coller ça :

type: 'custom:content-card-linky'
entity: sensor.myenedis
showInTableUnit: false

Et le résultat est tout de suite bien plus lisible. Voilà. Et pour suivre le projet ça se passe ici sur HACF.

Alternatives

Ici je vous ai parlé d'une solution native dans Home Assistant. Mais les afficionados de NodeRed vous diront que non, que c'est nul et qu'il faut le faire en NR. Vu que je ne parle jamais de NodeRed, vous avez déjà compris que je ne suis pas fan, même si j'ai pas mal testé et que je trouve le concept génial, pour l'heure je préfère me cantonner au YAML, après tout j'en ai bien chié pour comprendre, et comme disais ma tante qui n'avais jamais eu de descendance, je ne vais pas jeter tout de suite le bébé avec l'eau du bain ! Mais bon, pour ceux qui veulent faire tout ça avec NodeRed, ça se passe ici, toujours sur HACF.

Une autre possibilité est de se servir de la prise Teleinfo que l'on trouve sur les compteurs, mêmes plus anciens. Il existe plusieurs montages DIY, certains à base ESP et même sous Tasmota. Mais ça on en reparlera bientôt.

 

Redimensionner un disque Hassio sur ESXi

Pour redimensionner un disque ESXi sous Windows c'est facile. On change la taille du disque dans la console VMWare et on agrandit la partition avec le gestionnaire de disque Windows. Il est également possible de réduire, mais c’est plus compliqué et je vous laisse un peu chercher car ce n’est pas le but de cet article.

Dans le cas d'une partition Linux c’est un peu différent. J'avais le cas avec ma VM Home Assistant HASSIO qui de base est configurée avec 6 GO, ce qui s'avère rapidement trop juste.

Avec les dernières versions de ESXi on doit pouvoir faire la partie VMWare directement en augmentant directement la taille dans la la console (à condition de ne pas avoir de snapshot), sauf que dans mon cas (ESXi 5.5) c'est impossible, grisé dans le client VShere et erreur dans le client web. Et sans ça impossible d'aller plus loin.

La solution

Elle passe par SSH après avoir arrêté la VM :

1 - on va dans le répertoire ou se trouve notre disque virtuel
cd /vmfs/volumes/datastore1/hassio/
2 - on clone le disque virtuel existant
vmkfstools -i hassio.vmdk hassio_clone.vmdk
3 - on redimensionne le clone
vmkfstools -X 40g hassio_clone.vmdk
4 - on le renomme si on le souhaite...
vmkfstools -E "originalname.vmdk" "newname.vmdk"

Redimensionner

Maintenant on va pouvoir réellement redimensionner la partition :

  1. Dans les paramètres de la machine on supprime l'ancien disque et on ajoute le nouveau et on sauvegarde.
  2. On ouvre à nouveau les paramètres pour ajouter un lecteur de CD qui pointe sur l'ISO de GParted que l'on aura au préalable téléchargé ici.
  3. Dans les options de la VM on change le boot de EFI vers BIOS et on sauvegarde.
  4. On lance la VM qui va démarrer sur le CD de GParted (une petite vidéo pour vous faire une idée).
  5. Important, quand GParted vous demande de réparer (fix) la partition vous répondez OUI !
  6. Ensuite il suffit de redimensionner la partition /dev/sda8 sans oublier d'appliquer votre choix.
  7. On ferme tout ça et on édite la VM pour retirer le lecteur de CD virtuel et surtout repasser le boot en mode EFI.
  8. On sauvegarde et on peu relancer la VM avec son disque ainsi redimensionné. Si tout va bien on fera le ménage en supprimant l'ancien VMDK.

Sources