Je pensais que le problème devait être résolu dans la nouvelle version (à l’époque nous étions encore en 4.2), mais, apparemment, le bug est toujours présent.
Pourrais-je savoir si la correction a été apportée sur la version 4.3.15?
Merci de votre retour.
Je n’ai pas testé mais est-ce que cela ne serait pas lié au paramètre « quote automatique » dans la config jeedom? Essaye de l’activer ou de le désactiver
Ps: pourquoi avoir tag le plugin mode ? Il n’en est pas question dans le post que tu cites
Pour répondre à ta question, je te rappelle le contexte.
J’utilise un équipement du plugin Mode pour piloter le fil pilote d’un radiateur électrique.
L’avantage est, d’une part d’avoir un widget sexy, d’autre part de pouvoir gérer le retour au mode précédent.
Mon programme consiste à déclencher le mode confort dans la salle de bain via une télécommande puis, après 45mn, revenir au mode précédent (ECO en hiver, OFF en été).
Actuellement c’est fait par scénario avec un bloc DANS et ça fonctionne.
J’ai voulu faire la même chose sans scénario en utilisant les actions temporisées des commandes info.
J’ai donc appliqué cette logique à la commande « Mode » de l’équipement et c’est là que j’ai été confronté au problème.
L’équipement change bien de mode (de confort à eco) mais l’action n’est pas exécutée.
Sur mon dashboard l’équipement est en eco alors que le radiateur est toujours en confort.
C’est donc l’action du plugin mode qui n’est pas exécutée et non pas celle de la commande info « Mode » temporisée.
Comme s’il y avait un problème de récursivité, l’exécution fonctionnerait au premier niveau mais pas au second.
Mais je dis peut-être n’importe quoi.
Que j’utilise le mode « Retour mode précédent » ou un quelconque mode, « ECO » par exemple, le problème est le même.
Ok mais donc ce n’est pas du tout ce dont-on parlait dans le post précédent qui parlait bien du CORE jeedom (catégorie dans laquelle se trouvait le post)
donc, comme tu le dis, l’action sur valeur (qu’on configure dans la config avancée de la commande) a eu lieu puisque le mode de ton équipement #plugin-mode est revenu sur « eco »; et c’était ca le point qui a fait l’objet d’une correction.
donc pour ce (nouveau) problème sur le plugin mode, si tu fais l’action manuellement de « retour mode précédent », l’action d’entrée (mise en hors gel de ZRadiateurSdE) est-elle effectuée?
C’est la suite du même sujet. Lorsque je l’avais ouvert, je ne connaissais pas cette exécution sur tempo.
C’est en l’utilisant que j’étais tombé sur le problème. D’ailleurs le sujet avait été clôturé lorsque Salviaff avait dit avoir corrigé le bug, mais peu importe.
Les logs en debug permettent effectivement de se rendre compte du problème. Je le mets en entier en détaillant les séquences :
On voit qu’au passage en mode confort l’action en entrée commande fil pilote est exécutée (passage en mode Confort).
Sortie du mode Confort après tempo d’une minute sur l’info « Mode » et retour au mode précédent :
[2023-02-22 12:53:01][INFO] : [Salle Eau 2][Radiateur] L\'équipement est déverrouillé : changement de mode autorisé vers Retour mode précedent
[2023-02-22 12:53:01][INFO] : [Salle Eau 2][Radiateur] L\'équipement est déverrouillé : changement de mode autorisé vers Hors Gel
[2023-02-22 12:54:29][INFO] : [Salle Eau 2][Radiateur] L\'équipement est déverrouillé : changement de mode autorisé vers Hors Gel
On voit qu’aucune action en entrée de mode n’est exécutée bien que le retour au mode précédent soit effectif.
Forçage manuel du mode Hors Gel :
[2023-02-22 12:54:29][DEBUG] : [Salle Eau 2][Radiateur] Entrée dans le mode Hors Gel (mode précédent : Hors Gel)
[2023-02-22 12:54:29][DEBUG] : [Salle Eau 2][Radiateur] Exécution de l\'action #10291# (options : Array ( [enable] => 1 [background] => 0 ) )
On voit que l’action en entrée d’exécution de la commande fil pilote est exécutée.