-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sensor.hilo_defi change de status avec un délais(retard) #320
Comments
Meme chose ici, mais il me semble que c'était comme ca l'année passée aussi non? Le délai est à cause d'Hilo je crois.. ou c'est peut-être un poll time trop long qui devrait être raccourci pendant les défis pour être sur d'avoir toujours le bon état de sensor.défi.. ou en fait ca pourrait même être hardcodé car les heures sont toujours les mêmes... Mais bref moi ca fait un bout que je fais fonctionner mes automatisations avec des heures et non des changements d'états du sensor défi car sinon ca fait ce que tu rapportes parfois.. |
Ouin je vais peut être changer pour ca aussi.. J'aimais bien la simplicité du changement d'état du sensor.. J'ai le souvenir qu'il y avait parfois un délais l'an passé mais plus dans les 5-6mins que 30!
edit: Nevermind, je réalise que tout est décallé, pas seulement l'appréciation alors c'est peut être relié à un call chez hilo, aucune idée. Je suis disponible pour tester ou autre si besoin. |
Je confirme la même chose |
J'ai augmenté le setting de polling par défaut, ça peut probablement expliquer le délais supplémentaire versus l'an passé. |
Tu parles d'ici? hilo/custom_components/hilo/const.py Line 36 in caed4de
|
Exact. Avant c'était 600 (donc 10 minutes). |
Est-ce qu'on a vraiment besoin de faire du polling pour changer le status de ce sensor ? Je veux dire, une fois qu'il passe de off a scheduled, tout les attribut du sensor contienne déja les dates et heures de début de toutes les phases. On pourrais simplement utiliser ces valeurs pour changer le status du sensor ensuite ? |
J'aime l'idée, elle serait fiable même avec une perte d'internet, mais comment on ferait pour forcer le changement de state dans HA? Via des automatisations? C'est ce bout-là qui me tanne un peu. |
J'ignore comment ca peu se faire dans le component malheureusement mais si on peu coder un polling time pour appeler l'api et modifié le state selon la réponse, j'imagine qu'on pourrais coder d'utiliser ses propres atributs pour s'updater. Mais bon, tout à l'air facile et simple quand c'est pas toi qui code alors jvais vous laisser juger de tout ca :P |
J'ignore aussi comment le faire, je suis juste un gars qui s'essaye pis qui est chanceux des fois parce que ça marche haha. Peut-être que @valleedelisle aurait une solution élégante en tête. |
Peut-être domper le tout dans un yaml comme le token de login et relire dedans? |
salut gang, D'ici à ce que vous corrigiez direct dans l'intégration, voici un workaround pour contouner le lag que je me suis codé l'an passé. Ca a fonctionné très bien toute l'année passée et cette année aussi. Ca crée tout simplement un 2ième sensor (sensor.defi_hilo_phase) que vous pouvez utiliser pour déclencher/trigger vos automations. Ca se base directement sur les heures qui sont dans sensor.defi_hilo pour changer l'état du sensor, ainsi on élimine le lag complètement. J'ai ajouté qq éléments aussi pour le rendre "meilleur" (selon moi). Pour un défi du matin, la phase réduction va partir 5min avant et finir 5min après (c'est paramétrable via le "timedelta(minutes=5)"). C'est probablement pas nécessaire, mais je voulais être sûr que mes affaires soient bien arrêtés avant que le défi parte chez hilo. Également, j'ai ajouté une phase "boost" durant laquelle j'ai une scène qui laisse descendre la température un peu, afin de booster la phase d'appréciation (et donc booster les rewards). Dans mon cas, ca dure 2h avant la phase appréciation. C'est également paramétrables (via le bout timedelta(hours=2)) À noter que l'ensemble des attributs qui sont dans sensor.defi_hilo_phase ne sont pas recopiés dans mon sensor. C'est vraiment juste l'état. Faites-moi signe si vous trouvez des bugs! À mettre dans votre sensors.yaml (ou configuration.yaml si vous n'avez pas sensors.yaml)
Exemple pour le défi de mercredi: a+ |
Merci! J’ai checké la doc rapidos en dînant et je suis tombé là dessus, il serait peut-être utilisable tel quel: https://developers.home-assistant.io/blog/2020/11/09/system-health-and-templates |
Premiers essais infructueux:
Étrangement quand je rajoute cette classe là je plante le reste des sensors sur mon environnement de test... Je laisse ça ici d'un coup que quelqu'un serait en mesure de déjamboniser ça! |
Salut! J'avoue que je ne comprends pas trop ce que tu essaies de faire... tu veux que l'intégration créée automatiqueemnt le template sensor ? Je ne vois pas l'utilité vraiment... -pourquoi ne pas le mettre dans sensors.yaml tout simplement? Il me semble que tant qu'à vouloir améliorer l'intégration, il serait plus pertinent de la modifier afin que le vrai sensor fonctionne bien sans lag. Je pense que le meilleur moyen serait de modifier la fonction _async_update. Il faudrait qu'il y ait 2 "scan interval":
Si qqn est capable de m'expliquer comment je peux me monter facilement un environnement de DEV, je peux le coder moi-même... |
Je me disais (naïvement) que si c'était généré automatiquement ça serait mieux pour l'utilisateur qui veut juste un module plug and play sans trop se casser la tête. La doc de HA que j'ai linké semblait montrer qu'un template pouvait être planté dans le code. Je trouvais ça plus élégant de le créer d'emblée, dans ma tête. J'éssayais d'éviter de poller Hilo plus que nécessaire. Sinon est-ce que faire quelque chose du style:
Pourrait marcher comme patch temporaire? Pour ta question d'environnement de dev, mon HA roule en docker sur un RPI4. J'ai un NAS Synology aussi donc j'ai spinné un docker HA dessus pis je gosse dans le code de celui-là. Je ne suis pas un dev pour 2 cennes, j'ai appris le peu que je sais de python en gossant sur le code de ce custom component-ci. Je suis toujours willing d'en apprendre de meilleur que moi. |
voici ce que ca donnerait pour la class HiloChallengeSensor. Je pense que ca fait du sens, mais c'est 0 testé.... Faudrait attendre un vrai défi, à moins qu'on soit capable de faker un défi pour voir si ca passe... En gros, la logique est directement dans la property state, laquelle se base sur les attributs du sensor qu'il a récupéré lors du dernier scan. Le "pre_cold" est une invention de ma part.... ne pas en tenir compte pour maintenant.
|
Merci Veux-tu que je mette ça sur mon NAS en test pour pas que tu scrap ton prod? |
oui super. |
Okay, juste pour me garder des notes: const.py, ajout de:
config_flow.py:
Ensuite:
Ainsi que:
en.json:
fr.json:
init.py
Ensuite, je changerais ceci dans ton code @RayLation
|
#323 en test pour ça @arsenicks |
Fixed dans #323 , #327 et dvd-dev/python-hilo#144 |
Nice, good job boys! |
Good job, sorry j'ai déconnecté un peu de mon setup pendant une semaine.. Merci pour ton aide et tes contribs |
Version of the custom_component
v2023.11.1
Configuration
Config:
C'est pas super, j'ai maintenant activé le debug mais voici ce que j'ai comme logs depuis hier midi.
Describe the bug
Selon ma config, l'intégration devrait déclencher la période d'appréciation 4h avant le pre-heat. Donc minuit normalement le sensor.hilo_defi change pour appreciation et déclenche mes automatismes.
Le premier défi la nuit passé j'ai du déclencher mes automatismes moi même à 00:10 car le sensor hilo_defi ne changeait pas. Pourtant dans les attributs je vois bien que l'attribute appreciation_start et end à la bonne valeur. Le sensor hilo_defi à finalement changé de status pour appreciation mais seulement à 00:35, ensuite pre_heat en retard aussi, même chose pour reduction. Les heures sont dans les captures d'écran
Debug log
Je n'ai que des captures d'écran et les logs plus haut, j'ai activé le debug pour le prochain défi.
The text was updated successfully, but these errors were encountered: