Valeur par défaut dans un Template - Nouvelle version de HA

Xek · Novembre 13, 2021, 5:21

Bonjour,

Avec la nouvelle version de HA j’ai plusieurs alertes concernant des templates, il faut maintenant une valeur par défaut.
J’aurai besoin d’aide pour les modifier afin de les rendre conformes avec la future version qui en l’état ne les fera plus fonctionner…

Pas du tout à l’aise avec les variables et autres, j’ai trouver ce post afin d’essayer d’adapter mes valeurs mais sans succès :

Par exemple, ce template :

value_template: >-
       
          {% set myitem = states('sensor.octoprint_start_time') %}
          {{ as_timestamp(strptime(myitem, '%dd %Hh %Mm')) | timestamp_custom('%H:%M') }}

M’affiche cette erreur :

Alerte HA :

Template warning: 'strptime' got invalid input '2021-11-13T14:29:47.179298+00:00' when rendering template '{% set myitem = states('sensor.octoprint_start_time') %} {{ as_timestamp(strptime(myitem, '%dd %Hh %Mm')) | timestamp_custom('%H:%M') }}' but no default was specified. Currently 'strptime' will return '2021-11-13T14:29:47.179298+00:00', however this template will fail to render in Home Assistant core 2022.1

J’en ai pas mal dans le même genre, une piste serait top

Merci d’avance.

Herbs · Novembre 13, 2021, 6:42

Salut Xek,

Tu peux aller faire un tour ici :

Xek · Novembre 13, 2021, 7:54

Salut @Herbs , merci pour ce post que je n’avais pas vu, ça reprend les essais que j’avais déjà essayés sans succès

Par Exemple :

 {% set myitem = states('sensor.octoprint_start_time') %}
          {{ as_timestamp(strptime(myitem, '%dd %Hh %Mm'), 0 ) | timestamp_custom('%H:%M', 0 ) }}

 {% set myitem = states('sensor.octoprint_start_time') %}
          {{ as_timestamp(strptime(myitem, '%dd %Hh %Mm', 0) ) | timestamp_custom('%H:%M') }}

Mon sensor « sensor.octoprint_start_time » renvoi la date sous cette forme :

2021-11-13T18:52:53.090525+00:00

Peut être que c’est lié avec la syntaxe qui ne serait pas bonne ?

Je sèche… ce qui est dommage c’est que dans les outils de dev pas moyen de savoir si la modif est OK, faut à chaque test modifier le sensor et reboot le serveur…

Herbs · Novembre 13, 2021, 8:05

Où alors peut-être en forçant l’état de « sensor.octoprint_start_time » à unavailable avec les outils de dev (je n’ai pas testé).

Xek · Novembre 13, 2021, 8:07

Je pense pas car pour l’instant HA affiche qu’un avertissement dans les Logs, pour les outils de dev la valeur actuel du template est bonne mais à la prochaine MAJ le template sera HS…

Pulpy-Luke · Novembre 13, 2021, 8:09

2022 … donc c’est pas tout à fait demain …
Sinon, le plus simple c’est de relancer HA. Si l’avertissement disparait des logs, c’est que la config est correcte.
C’est déjà bon signe d’avoir une valeur cohérente pour l’instant

Herbs · Novembre 13, 2021, 8:20

Tu as l’erreur au boot car la template est évaluée avant que « sensor.octoprint_start_time » ne soit dispo et là est le but de leur modif : imposer la mise en place de valeur par défaut pour que les templates soient toujours « évaluable » et empêcher qu’elles ne remontent des valeurs bidons.

Donc je testerai quand même en forçant l’état, on ne sait jamais …

Herbs · Novembre 13, 2021, 8:27

Du moment que le sensor est dispo la template n’utilise pas la valeur par défaut donc le résultat est OK.

Par contre et par exemple si tu forces l’attribut « next.rising » du sensor « sun.sun » à « unavailable » et que tu vas dans « modèle » des outils de dev tu « trigg » l’erreur :

Bref il faut forcer d’une façon ou d’une autre l’utilisation de la valeur par défaut pour déclencher la log.

Le truc « fun » c’est que même les devs n’ont pas pris la peine de mettre à jour les templates dans les outils de dev

Xek · Novembre 13, 2021, 8:41

@Pulpy-Luke ha oui, j’avais cru voir 2021-12, ça laisse un peu plus de temps
C’est ce que je fait, je relance HA à chaque fois , mais c’est pas tip top…

@Herbs , j’ai l’erreur au boot mais pas seulement, en quelques minutes j’ai plus de 200 erreurs pour 4/5 templates similaires malheureusement

Demain je test de forcer le statut, j’avais zappé cette possibilité, merci pour le rappel, en espérant que ça m’évite de rebooter toutes les 2 minutes.

Et oui, si les outils avait été a mis à jour ce serait bien plus simple, peut être dans la prochaine version

Pulpy-Luke · Novembre 13, 2021, 8:41

Ce que je voulais dire, c’est que le restart permet de vérifier que la valeur par défaut est bien présente coté template.
Effectivement ça permet pas de tester l’impact (ce que tu fais en mettant un état unavailable) mais bon … on faisait déjà plus ou moins sans valeur par défaut

Herbs · Novembre 13, 2021, 9:40

Trop rapide j’ai été

avec la valeur par défaut c’est mieux :

Bon maintenant j’espère que le soleil se lèvera quand même demain

Xek · Novembre 14, 2021, 7:23

J’ai pensais avoir solutionné mon problème grâce à ce poste mais sans succès ! Pas mal d’erreur également…

Après l’ajout d’un ,true ou d’un ,false c’est bien mieux mais c’est pas encore ça !

      octoprint_heure_fin:
        friendly_name: 'Octoprint  - Heure Fin'
        value_template: >
          {% if not is_state('sensor.octoprint_current_state', 'Operational') %}
            {{ as_timestamp(states('sensor.octoprint_estimated_finish_time')) | timestamp_custom('%H:%M', true)}}
          {% else %}
            N/A
          {% endif %}	  

      octoprint_heure_debut:
        friendly_name: 'Octoprint  - Heure Début'
        value_template: >
          {% if not is_state('sensor.octoprint_current_state', 'Operational') %}
            {{ as_timestamp(states('sensor.octoprint_start_time')) | timestamp_custom('%H:%M', true)}}
          {% else %}
            N/A
          {% endif %}

Template warning: ‹ as_timestamp › got invalid input ‹ unknown › when rendering template ‹ {% if not is_state(‹ sensor.octoprint_current_state ›, ‹ Operational ›) %} {{ as_timestamp(states(‹ sensor.octoprint_start_time ›)) | timestamp_custom( ›%H:%M’, true)}} {% else %} N/A {% endif %}’ but no default was specified. Currently ‹ as_timestamp › will return ‹ None ›, however this template will fail to render in Home Assistant core 2022.1

Template warning: ‹ timestamp_custom › got invalid input ‹ None › when rendering template ‹ {% if not is_state(‹ sensor.octoprint_current_state ›, ‹ Operational ›) %} {{ as_timestamp(states(‹ sensor.octoprint_start_time ›)) | timestamp_custom( ›%H:%M’, true)}} {% else %} N/A {% endif %}’ but no default was specified. Currently ‹ timestamp_custom › will return ‹ None ›, however this template will fail to render in Home Assistant core 2022.1

Template warning: ‹ as_timestamp › got invalid input ‹ unknown › when rendering template ‹ {% if not is_state(‹ sensor.octoprint_current_state ›, ‹ Operational ›) %} {{ ((as_timestamp(states(‹ sensor.octoprint_estimated_finish_time ›)) - as_timestamp(states(‹ sensor.octoprint_start_time ›))) | timestamp_custom( ›%H:%M’, false)) }} {% else %} N/A {% endif %}’ but no default was specified. Currently ‹ as_timestamp › will return ‹ None ›, however this template will fail to render in Home Assistant core 2022.1

J’ai un autre template qui calcule la durée (heure de fin moin heure de début) que j’ai modifié et qui fonctionne aussi mais qui m’affiche également des erreurs…

 octoprint_duree:
         friendly_name: 'Octoprint - Durée'
         value_template: > 
           {% if not is_state('sensor.octoprint_current_state', 'Operational') %}
           {{ ((as_timestamp(states('sensor.octoprint_estimated_finish_time')) - as_timestamp(states('sensor.octoprint_start_time'))) | timestamp_custom('%H:%M', false)) }}
           {% else %}
             N/A
           {% endif %}

TemplateError(‹ TypeError: unsupported operand type(s) for -: ‹ float › and ‹ NoneType › ›) while processing template ‹ Template("{% if not is_state(‹ sensor.octoprint_current_state ›, ‹ Operational ›) %} {{ ((as_timestamp(states(‹ sensor.octoprint_estimated_finish_time ›)) - as_timestamp(states(‹ sensor.octoprint_start_time ›))) | timestamp_custom( ›%H:%M’, false)) }} {% else %} N/A {% endif %}")’ for attribute ‹ _attr_native_value › in entity ‹ sensor.octoprint_duree ›

Avez vous une idée ?
Merci

Pulpy-Luke · Novembre 14, 2021, 7:30

Salut

Pourquoi true/false ? Et pourquoi l’un et parfois l’autre ? Normalement :

as_timestamp retourne un entier
timestamp_custom retourne une chaine

Il vaut mieux respecter le type pour s’assurer que ça s’interprète à minima

Xek · Novembre 15, 2021, 9:03

A vrai dire à force de tout essayer j’ai fait un peu n’importe quoi !
@Pulpy-Luke , ton message m’a mis sur la bonne piste, merci
Voilà la solution, fini les erreur

{% if not is_state('sensor.octoprint_current_state', 'Operationnal') %}
          {{ as_timestamp(states('sensor.octoprint_estimated_finish_time'), 0) | timestamp_custom('%H:%M', True)}}
          {% else %}
            N/A
          {% endif %}

Pulpy-Luke · Novembre 15, 2021, 9:25

De rien.
Par contre comme dis plus haut, true, c’est pas le meilleur choix possible. Ça fonctionne parce que tu ne passes actuellement pas par la valeur par défaut (et que syntaxiquement c’est correct) mais le jour où ça ne fonctionnera pas, booléen dans l’affichage ça va faire tout drôle

Xek · Novembre 15, 2021, 9:29

Si je met False, l’heure n’est pas bonne, il y a un décalage d’une heure …

Pulpy-Luke · Novembre 15, 2021, 9:40

Pour moi c’est ni true ni false…

Xek · Novembre 15, 2021, 9:51

Il m’avait semblé y avoir des erreurs sans True ou False, j’ai basculé sur 1 plutôt que True et ça semble OK, merci

{% if not is_state('sensor.octoprint_current_state', 'Operationnal') %}
          {{ as_timestamp(states('sensor.octoprint_estimated_finish_time'), 0) | timestamp_custom('%H:%M', 1)}}
          {% else %}
            N/A
          {% endif %}