Commande Suspendre exécutée dans un bloc A : reprise immédiate avec délai incohérent

Plugins
1

Bonjour,

Je pense avoir identifié un problème avec la commande Suspendre du plugin Gestion Volets / SunShutter, lorsqu’elle est exécutée depuis un bloc programmé A.

Contexte :

  • Équipement concerné : [Bureau][Volet (pilotage thermique)]

  • Paramétrage de l’équipement :

    • Reprendre la main : Oui, après délai

    • Délai de reprise : 120 minutes

  • Objectif : suspendre temporairement la gestion automatique du volet le matin, pour éviter qu’il ne s’ouvre avant qu’une présence soit détectée dans la pièce.

J’ai fait plusieurs tests et le résultat est très clair :

  1. Si j’exécute manuellement la commande :
    #[Bureau][Volet (pilotage thermique)][Suspendre]#

    la suspension fonctionne correctement. Le plugin reste suspendu et le log indique bien, quelques minutes plus tard, un délai cohérent, par exemple :

    Gestion automatique suspendue, vérification du délai avant reprise (120 minutes) : 5 minutes
    Gestion automatique suspendue manuellement : aucune action

  2. Si j’exécute la même commande Suspendre depuis un scénario simple, lancé directement, cela fonctionne également.

  3. En revanche, si la commande Suspendre est exécutée depuis un bloc A, par exemple :

    A time_op(#[Timing][Éphéméride][LeverSoleil]#,-15)

    alors la suspension est immédiatement annulée.

Extrait de log :

[2026-07-02 05:23:03] DEBUG [Bureau][Volet (pilotage thermique)] Suspension manuelle de la gestion automatique
[2026-07-02 05:23:03] DEBUG [Bureau][Volet (pilotage thermique)] Gestion automatique suspendue, vérification du délai avant reprise (120 minutes) : 29717483 minutes
[2026-07-02 05:23:03] DEBUG [Bureau][Volet (pilotage thermique)] Délai de reprise atteint : réactivation de la gestion automatique

Le nombre 29717483 minutes semble indiquer que la date/heure de suspension n’est pas correctement initialisée dans ce cas précis, comme si le calcul était fait par rapport à une date nulle ou très ancienne. Le plugin considère donc immédiatement que le délai de reprise est dépassé et réactive la gestion automatique.

Résultat concret : le volet est censé rester suspendu le matin, mais SunShutter reprend immédiatement la main et peut ouvrir le volet quelques minutes plus tard.

Pour moi, le problème ne vient donc pas de la commande Suspendre elle-même, mais du contexte d’exécution lorsqu’elle est appelée depuis un bloc programmé A.

Est-ce un comportement connu ? Y a-t-il une limitation des blocs A avec les commandes Suspendre / Reprendre, ou bien peut-on considérer cela comme un bug du plugin ?

@+

2

En complément, j’ai pu reproduire systématiquement un problème avec Suspendre lorsqu’il est exécuté depuis un bloc A.

Exemple :

A time_op(#[Timing][Éphéméride][LeverSoleil]#,-15)
→ #[Bureau][Volet (pilotage thermique)][Suspendre]#

Le log donne alors :

Suspension manuelle de la gestion automatique
Gestion automatique suspendue, vérification du délai avant reprise (120 minutes) : 29717483 minutes
Délai de reprise atteint : réactivation de la gestion automatique

En regardant le code, le bloc A crée une tâche scenario::doIn exécutée à la seconde 00, donc sur le même top minute que le cron() de SunShutter.

Or Suspendre fait actuellement :

stateHandling = false
...
beginSuspend = time()
manualSuspend = true

Le cron peut donc voir stateHandling=false alors que beginSuspend vaut encore 0 et manualSuspend est encore faux. Le calcul du délai devient alors énorme (~29,7 millions de minutes), ce qui déclenche immédiatement la reprise.

Cela explique le caractère systématique du problème avec un bloc A.

Correction proposée :

setCache('beginSuspend', time());
setCache('manualSuspend', true);
checkAndUpdateCmd('stateHandling', false);

et idéalement ajouter aussi une garde dans le cron si beginSuspend <= 0.

Ça ressemble donc bien à un bug d’ordonnancement dans le plugin.

3

Bonjour,

La proposition (de l’IA) n’est pas satisfaisante, elle ne fait qu’inverser le problème, et encore pas partout.
Et beginSuspend ne peut jamais être < 0.

Beta a tester demain si le problème est réglé.

4

Ok merci Mips. Je m’étais absenté.

J’ai installé la beta, essayé de reproduire le problème dans un scénario de test, mais je n’arrive plus à faire coïncider suffisamment l’exécution du bloc A avec le passage du cron SunShutter… Les deux traitements sont décalés de plusieurs secondes, donc le défaut ne se manifeste pas et je ne vois pas s’il ne se manifesterait plus…