HA 2026.3 beta 🧹

[denisb88]

je viens de faire la maj et j’ai l’impression que l’intégration Toyota ne fonctionne plus

[Tochy]

Salut

C’est balot ça.

Mais quelle idée d’installer une version béta ? Surtout que tous les mois des personnes répètent d’attendre à minima la version .1 du mois.

Maintenant que tu as fais le béta testeur, fais remonter l’info au dev au moins ça aura servi à quelque chose

[denisb88]

j’ai installé l’intégration sur une version 2 2026, même chose donc ce n’est pas la beta la coupable mais un problème de connexion (dev prevenu)

[bastgau]

Il faut bien que des personnes installent les versions bêta et .0 pour faire avancer les choses.

[Tochy]

Oui, mais c’est pas sur le forum qu’il faut venir se plaindre ou chercher une solution dans ce cas et plutôt se tourner vers les devs parce que je ne pense pas qu’ils viennent sur hacf.

[bastgau]

On peut aussi faire les deux.

[Bob]

Bonsoir,
Bon à part l’option « [ Continuer en cas d’erreur »] et commander un sweat qui est tellement confortable je ne vois rien qui vaille dans mon cas, mais bravo pour la tenue des délais de MAJ
J’attendrais la 2026.3.3 je pense.
Bob

[bastgau]

Python 3.14 et ça c’est top!

[BBE]

@Bob

Bon à part l’option « [ Continuer en cas d’erreur »]

C’était déjà dispo, en YAML seulement, et attention, ça ne marche pas pour tous les types d’erreur…

Va juste falloir que je modifie l’article 3 (parution fin du mois… mode teasing OFF) sur les automatisations pour indiquer ça (je l’avais en YAML only…)

[GuiPoM]

L’idéal reste et restera de mettre les actions les plus critiques en début de blocs, autant que possible, pour éviter qu’elles puissent ne pas être exécutées.

Je sais que le try catch finally est une blague pour eux, mais sur des scripts d’alarme, ne pas pouvoir garantir l’exécution est sérieusement un soucis, et il faut être très prudent

[Tochy]

Pour qu’une action ne bloque pas le reste de l’auto ou du script en cas de plantage, il suffit de les mettre dans des séquences et dans ce cas juste la séquence plante, le reste continue à être executé.

[BBE]

tu veux dire en parallele par exemple?

[Tochy]

Alors je me suis mal exprimé car je l’utilisais avec des séquences d’actions, mais en fait il s’agit d’appeler un script comme dans cet exemple :

triggers: []
conditions: []
actions:
  - action: switch.turn_on
    metadata: {}
    target:
      entity_id: switch.sonoff_1000e91e95_2
    data: {}
  - action: script.turn_on
    metadata: {}
    target:
      entity_id: script.test_plantage
    data: {}
  - action: switch.turn_off
    metadata: {}
    target:
      entity_id: switch.sonoff_1000e91e95_2
    data: {}
mode: single

Ici la seconde action appelle un script dont je sais qu’il se plantera puisque je lui demande de faire une action qui n’existe pas. Cependant le plantage de ce script n’affectera pas l’automatisation principale.

Attention cependant le script doit bien être appelé comme indiqué dans l’exemple :

  - action: script.turn_on
    metadata: {}
    target:
      entity_id: script.test_plantage
    data: {}

Et non comme ceci :

  - action: script.test_plantage
    metadata: {}
    data: {}

Car dans le second, l’automatisation s’arrête et attend la fin du script pour pouvoir continuer.

Comme tu le dis ça revient à exécuter des actions en parallèle mais hors de l’automatisation. Si tu veux faire la même chose avec le bloc parallel dans l’automatisation ça planterai.

[BBE]

J’ai repris ton exemple dans l’article.

Merci. j’ai appris un truc nouveau aujourd’hui !

[Tochy]

Un cas d’utilisation dont je me sers.

Une automatisation d’arrosage qui envoie une notif en début de cycle et une en fin de cycle. En cas de plantage pour x raisons de l’envoi de la notif, je ne veux pas que ça coupe le cycle d’arrosage. L’envoi des notifs est déporté dans un script à part et ne gêne ainsi pas l’automatisation d’arrosage.

Ps: c’est la suite du teaser d’il y’a quelques mois déjà, mais j’arrive au bout.

[BBE]

et sinon avec un timer… et deux automatisation (ou deux triggers):

• début de cycle:
  • ouverture vanne
  • lancement timer
  • notif
• fin de timer
  • fermeture vanne
  • notif

c’est robuste aussi, et en plus c’est robuste à un reset HA en cours d’arrosage…

Avantage, si t’as spook, tu peux changer la durée du timer au lancement… Et donc avoir une durée variable fonction de la méteo, du l’humidité du sol et de l’age du capitaine…

Bon c’est un peu hors sujet… Et ça n’enlève rien à la façon sécurisée de lancer un script…

[Pulpy-Luke]

Hello

Alors, ça doit être mon p’tit cœur de vieux dev qui se brise quand je vois ce mécanisme de bypass d’erreur…
Même si je vois bien que de temps en temps c’est plus facile de poursuivre l’exécution, j’arrive encore mieux à imaginer toutes les automatisations bancales qui vont continuer à dérouler des actions dans des conditions pas propres… Et en ajoutant des conseils de l’IA là dessus, ça va être chaud à suivre coté utilisateur

[Bob]

Oh @Pulpy-Luke

Je comprends, je n’ai jamais eu d’erreur d’automatisation autres que mes erreurs.

Bob