Bonjour,
Première « mauvaise surprise » en usage réel depuis ma migration …
Le script ci-joint déclenché hier soir pour passer la maison en mode nocturne est resté « bloqué » en running toute la nuit sur la séquence de fermeture du groupe de volets # Shutters to close et n’a donc jamais exécuté les opérations suivante.
En cause un des volets du groupe qui n’a probablement jamais été considéré « fermé », pourtant physiquement bien fermé.
Probablement qu’il a fermé jusqu’à 1% et n’a donc pas atteint 0%, ça se produit parfois avec les modules fibaro, l’état de position s’arrête à 1% de de la fin aussi bien en fermeture qu’en ouverture, il m’est arrivé d’avoir des volets ouverts à 98% au lieu de 99%.
Et généralement une simple commande de fermeture ou d’ouverture supplémentaire le fait passer de 98 à 99% ou de 1 à 0% sans même que le moteur ne doive tourner physiquement.
Une recalibration peut parfois être nécessaire.
Toujours est-il que je ne m’attendais pas à ce que cela puisse bloquer complètement mon script, et que donc par exemple la défaillance d’un équipement puisse mettre au sol tout un process.
Imaginons qu’un des volets tombe vraiment en panne alors touts les scripts sensés le piloter vont donc bloquer dessus ?
Toujours aussi étonnant c’est qu’après avoir renvoyé ce matin une commande de fermeture manuellement sur le volet qui devait être fermé via le bouton de sa carte lovelace et l’avoir vu passer à l’état « fermé » instantanément sans que le volet ne bouge physiquement vu qu’il était déjà fermé, le script ne s’est pas « débloqué » pour autant, j’ai donc finalement stoppé son exécution moi-même.
Et d’après son historique il était vraiment bloqué sur cette étape car l’étape suivant # Check for opened access point était « non exécutée » et la timeline spécifiait « still running » depuis 7h
J’ai relancé le script juste après l’avoir tué et il s’est parfaitement exécuté jusqu’à la fin vu que les volets étaient à ce moment encore tous fermés.
L’idéal serait de ne pas attendre sur l’exécution du service cover.cover_close mais hormis mettre cette action dans une couche de script supplémentaire pour pouvoir l’exécuter avec un script.turn_on je ne vois pas trop comment éviter que cela se reproduise.
Le problème c’est que j’ai d’autres scripts de transition de mode qui eux aussi doivent positionner les volets, comme celui qui passe la maison en « mode absence », et pour lesquels un blocage de l’exécution pour une raison secondaire serait bien plus problématique.
Et devoir ajouter une couche supplémentaire de script pour toutes les actions sur volet serait assez lourd et encombrant dans la configuration.
En gros, comment feriez vous pour éviter que ce problème ne puisse se reproduire ?
Et pourrait-il arriver aussi sur un service « light.turn_off » sur un groupe de lumières si une des lumières du groupe était injoignable par exemple et ne passait donc pas en état « éteint » ?
###########
# SCRIPTS #
###########
script:
#----------------------------------------
# Transition to Home Mode Night
#----------------------------------------
home_mode_night:
alias: "Home Mode Night"
icon: "mdi:weather-night"
description: "Switch Home to Night Mode"
mode: single
sequence:
# Kill other modes scripts
- service: script.turn_off
target:
entity_id:
- script.home_mode_away
- script.home_mode_presence
- script.home_mode_bedtime
# Light to turn off
- service: light.turn_off
target:
entity_id:
- light.group_outdoor
# Shutters to open
- service: cover.open_cover
target:
entity_id:
- group.shutter_night_mode_to_open
# Shutters to close
- service: cover.close_cover
target:
entity_id:
- group.shutter_night_mode_to_close
# Check for opened access point
- service: script.turn_on
target:
entity_id: script.prompt_to_close_access_point
data:
variables:
notif_data:
prefix_text: ""
media_player_entity_id: media_player.echo_sejour
target:
- voice
- mobile_app
who:
- stephane
timeout: 60
reminder: no
# Waits 5 minute
- delay:
minutes: 5
# Enable presence auto automation
- service: automation.turn_on
target:
entity_id: automation.home_mode_presence_auto
