sensor.defi_hilo devient brièvement off pendant la phase de réduction

[DLav007]

Pendant le défi PM du 8 janvier 2024, sensor.defi_hilo est brièvement (< 1s) passé à off 2 fois (18:49:54 et 19:04:55). La valeur du sensor est rapidement revenue à la bonne valeur, reduction.

Ces glitchs dans la valeur du sensor font dérailler les automatisations qui en dépendent.

[ic-dev21]

Salut.

Ce sont des glitchs momentanés et locaux.

À part te suggérer de revoir tes automatisation en utilisant les exemples fournis dans le repo je ne travaillerai pas là dessus, ça ne vaut pas la peine à cause de #486. Si tu as besoin d’aide avec tes automatisation y’a une bonne gang de user sur discord ou pars une discussion.

Merci

[DLav007]

J'ai modifié mes automatisations pour ignorer les transitions vers l'état off pendant une période de réduction. Ça devrait permettre de contourner le problème.

Si je comprends bien, régler #486 pourrait éliminer ces glitchs ?

Si oui, je marquerai cet issue as blocked avec une dépendance sur #486.

[ic-dev21]

J'ai modifié mes automatisations pour ignorer les transitions vers l'état off pendant une période de réduction. Ça devrait permettre de contourner le problème.

Si je comprends bien, régler #486 pourrait éliminer ces glitchs ?

Si oui, je marquerai cet issue as blocked avec une dépendance sur #486.

Je le souhaite mais pas de promesses, j'ai du temps (et des connaissances) limitées en python faque la job est longue et fastidieuse à faire.

[bennydiamond]

C'est encore arrivé aujourd'hui.
Pendant moins d'une seconde, l'état est passé de "scheduled" à "off" puis est revenu à "scheduled".

FYI, j'ai une condition dans mes automatisations qui vont tenter de limiter l'impact de ces glitchs.

À ajouter comme condition "template" dans les automatisations.

{% set previous_state_last_changed_timestamp = trigger.from_state.last_changed %}
{% set current_state_last_changed_timestamp = trigger.to_state.last_changed %}
{% set minimum_state_steady_state_minutes = timedelta(minutes=1) %}
{{ (current_state_last_changed_timestamp - previous_state_last_changed_timestamp) >= minimum_state_steady_state_minutes }}

La valeur de last_changed ne survie pas un restart donc c'est toujours possible que ça déclenche si vous redémarrez votre instance de Home Assistant au mauvais moment!

[DLav007]

Est-ce qu'on pourrait implémenter dans l'intégration le correctif d'ignorer ces conditions lorsqu'on est dans n'importe quel état autre que off ? Autrement dit, ne pas altérer sensor.defi_hilo à off lorsque la condition d'erreur est observée dans l'intégration ?

L'avantage de cette solution, c'est qu'elle évite à tous les utilisateurs de l'intégration de devoir modifier leurs automatisations.

Il me semble que ça ne devrait pas être compliqué mais je peux me tromper.

[ic-dev21]

Est-ce qu'on pourrait implémenter dans l'intégration le correctif d'ignorer ces conditions lorsqu'on est dans n'importe quel état autre que off ? Autrement dit, ne pas altérer sensor.defi_hilo à off lorsque la condition d'erreur est observée dans l'intégration ?

L'avantage de cette solution, c'est qu'elle évite à tous les utilisateurs de l'intégration de devoir modifier leurs automatisations.

Il me semble que ça ne devrait pas être compliqué mais je peux me tromper.

Je ne comprends pas la question?

Le statut off vient du call d'API, si l'API qui est deprecated a roté, y'a pas grand chose que je puisse faire.

[DLav007]

Je pense que tu pourrais juste ignorer le off retourné par l'API quand l'état actuel est différent de recovery.

Cette logique est grosso modo équivalente à ce que les utilisateurs font dans leurs automatisations.

[ic-dev21]

Je pense que tu pourrais juste ignorer le off retourné par l'API quand l'état actuel est différent de recovery.

Cette logique est grosso modo équivalente à ce que les utilisateurs font dans leurs automatisations.

Comme j'ai dis plus haut, je ne mettrai pas d'effort là dessus car l'API ferme bientôt. Je vais concentrer mes efforts sur la méthode websocket, qui a entre autre comme avantage une gestion 100% locale des données. Il est assez aisé de créer des automatisations qui ne se déclenchent pas inutilement en suivant les exemples de la doc.

[bennydiamond]

Euh pour vrai!? Hilo vont vers une intégration locale pour HA? Malade.

Est-ce que ya un beta program chez Hilo pour activer ça?

[ic-dev21]

Euh pour vrai!? Hilo vont vers une intégration locale pour HA? Malade.

Est-ce que ya un beta program chez Hilo pour activer ça?

Pas tout à fait. L'API est mort, ils le gardent ouvert juste parce qu'on est ben fins.

Tout leur stock natif a passé à la méthode websocket il y a un méchant bout. Un des gros avantage c'est que c'est du "push" et non du "pull".

Sur le nouveau code, une fois l'info du websocket reçue, je n'ai plus besoin de communiquer avec les serveurs de Hilo, je traite l'info localement à partir de là.

Le code actuel poll l'API à un intervalle fixe et si ça rote, ça fait le comportement que tu vois.

C'est win-win, y'a moins de demande sur les serveurs de HQ, pis nous les défis se comportent mieux. J'vais finir par y arriver mais j'pas dev pour deux cennes alors c'est long.

Comme l'info du compteur doit remonter à HQ Hilo ne sera jamais 100% local, ever.