Bug de récupération de la dernière position connue lorsque la condition change

Salut,

J’ai bien lu et j’ai bien compris que le soucis vient au moment du changement de mode c’est pour ca qu’il me faudrait les logs a ce moment la.

Mais j’ai tout mis dans mes posts. Je n’ai pas plus de logs. Je suis en debug.

Il y a bien dans mes logs le passage au mode Jour/Nuit :

Je comprends pas je suis pas convaincu du bug plus un soucis de comprehension. La quand je vois ton log tout est bon :

  • le volet a été bougé donc c’est suspendu
  • changement du mode en mode force mais aucun action donc le volet reste suspendu
  • ensuite a un moment la condition devient valide et le plugin est dans le bon mode mais comme toujours suspendu il bouge pas.

En gros meme si un changement de mode bypass la suspension si il n’y a aucun action a faire le volet reste suspendu.

Oui, on est en phase.

Aucune action? De quelle action du parle?
Quand je passe en mode Nuit, il ne se passe jamais rien donc normal.

Je ne comprends quand tu parles que le volet reste suspendu.
Le volet ou la gestion automatique?

Non, la gestion automatique ne devrait pas être suspendu vu que l’option Reprendre sur changement de mode est activée.

Le problème est que la position du volet ne se met pas à jour lors du changement de mode si et seulement si à ce moment la condition n’est plus valide.

Cas OK :

  • Condition OK. Gestion auto ok. Volet à 30% (normal) :

  • Mouvement manuel à 67%. Stop de la gestion auto car Reprendre la main à Non :

  • Je passe en mode Nuit avec toujours la condition OK (testAuto), il reprend la gestion automatique car l’option Reprendre sur changement de mode est activée.


    La dernière position se met donc à jour. Tout ce qui a de plus normal.

Là donc est donc OK.

Cas NOK :

  • Condition OK. Gestion auto ok. Volet à 30% (normal) :

  • Mouvement manuel à 67%. Stop de la gestion auto car Reprendre la main à Non :

  • La condition passe à NOK (testAuto) :

  • Je passe en mode Nuit avec toujours la condition NOK (testAuto), il est censé reprendre la gestion automatique car l’option Reprendre sur changement de mode est activée. Sauf qu’avec une condition NOK, au changement de mode, il ne met pas à jour la dernière position :

Donc quand je vais passer en mode Jour, la dernière position connue sera 30% au lieu de la réelle à 67%.
Quand la condition sera remplie (testAuto OK) et que le cron se lancera :

[2024-01-22 10:32:04][DEBUG] : [Bureau][autoVoletSunshutter] Démarrage de la gestion automatique
[2024-01-22 10:32:05][DEBUG] : [Bureau][autoVoletSunshutter]Position actuel du volet 65
[2024-01-22 10:32:05][DEBUG] : [Bureau][autoVoletSunshutter] Ecart avec la dernière position connue : 35.35 %
[2024-01-22 10:32:05][DEBUG] : [Bureau][autoVoletSunshutter] Ecart avec la dernière position connue supérieur à 4 % : suspension de la gestion automatique

Il me détectera un écart avec la dernière position connue. Tout cela, parce que cette fichue dernière position ne s’est pas mise à jour.

Et je crois que c’est le même problème ici :

Tu confirmes @gdseb ?

Je confirme donc c’est pas un bug c’est le fonctionnement attendu. Si tu change de mode avec reprise mais que aucune action ne se fait (car aucune condition valide) alors la gestion automatique reste suspendu.

Le changement de mode avec reprise (je pense le nom est pas bon c’est changement de mode forcé en vrai) désactive la suspension de la gestion automatique si et seulement si il y a une action applicable si elle ne fait rien alors pas de désactivation de la suspension sur la gestion automatique.

Je ne suis pas certain de comprendre. C’est quoi une action dans ton explication ?
Une action manuelle du volet?

Si je change de mode avec reprise et que la condition est ok alors la gestion automatique devrait reprendre non?
Tu me dis le contraire. Et si c’est ça et que ce n’est pas un bug c’est totalement illogique.

Ce n’est donc pas logique qu’après un changement de mode puis reprise de la gestion automatique avec toutes les conditions OK, le plugin signale un mouvement de volet qui n’a pas eu lieu (car il n’a pas mis à jour la dernière position malgré plusieurs changement de mode).

Tu ne peux pas me dire que c’est logique que le plugin démarrage la gestion automatique (avec toutes les conditions OK) et qucron qu’il arrête la gestion automatique parce que j’ai soit disant bouger un volet (alors que non… enfin oui mais la veille et plusieurs changements de mode ont eu lieu entre-temps).

Ben oui, je suis d’accord. Si pas d’action applicable car pas toutes les conditions OK alors il ne fait rien.
Mais moi je parle d’un changement de mode avec actions applicables car toutes les conditions OK.

Je sais pas comment l’expliquer… tu as un mode A avec une condition 1. La gestion de volet est en mode forcer la reprise au changement de mode.

Ton volet a été mis à 0% par le plugin de gestion tu le bouge à 30%. La gestion automatique est donc suspendu.

Tu lances le mode A, vu qu’il force la reprise le plugin analyse les conditions malheureusement la condition 1 n’est pas valide. Il ne se passe donc rien et la gestion automatique reste suspendue.

La condition 1 devient vrai mais tu es toujours suspendu donc le volet ne bouge pas.

Pas de bug là dedans c’est le fonctionnement attendue il faut que lors du passage sur le mode A une condition soit vrai et que le volet bouge pour que ça lève vraiment la suspension.

Jusque là, on est d’accord.

Ben c’est là que ça coince… Soit c’est illogique, soit ça bug.
Car à ce moment là, je lis bêtement les logs mais :

[2024-01-22 10:32:04][DEBUG] : [Bureau][autoVoletSunshutter] Démarrage de la gestion automatique

Il y a bien un redémarrage de la gestion automatique.

Sauf que :

[2024-01-22 10:32:05][DEBUG] : [Bureau][autoVoletSunshutter]Position actuel du volet 65

Il a toujours la position de la veille.

Effectivement dans ce cas, cela fonctionne, je suis d’accord.
Et c’est illogique.

Je prends mon vrai exemple : je me base sur la température max du jour dans la condition de vérification.
En gros, quand il fait chaud, je veux que les volets se ferment quand le soleil tape sur la fenêtre.
Lorsque le volet s’ouvre la première fois dans la journée, il passe en mode Jour.

Sauf que… La valeur de la température max du jour change de temps en temps (plugin officiel).
Et si cette valeur change, et ben il va me détecter un changement de position alors que je n’ai pas du tout toucher au volet depuis qu’il est passé en mode jour… et du coup, la gestion sera arrêtée.

Je comprends ce que tu as expliqué et je comprends aussi que t’as cerné ma problématique.

Pourquoi le plugin ne pourrait simplement pas récupérer la position du volet au moment du changement de Mode ? Il ferait simplement une MAJ de la position.
Et quel intérêt à ne pas le faire?

Je pourrais très bien mettre ma règle de température max du jour dans les conditions de positionnement de volet au lieu de la mettre dans condition pour vérification, cela réglerait très certainement mon problème.
Mais si je poste ici, c’est pour que cela en profite à tout le monde.

Bonjour,

En faite ca marche pas comme ca, le plugin enregistre le derniere ordre qu’il a demandé et non la position actuel du volet. Si il envoi pas d’ordre alors forcement il désactive la gestion automatique. C’est vraiment pas un bug mais le comportement attendu. On pourrait voir pour faire une demande d’évolution auprès de jeedom mais a voir si c’est pertinant car ca changerait pas mal de le comportement et donc il va avoir des gens qui vont dire que ca va pas et demander un retour arriere.

Hello,

Du coup, il y a deux choses qui ne vont pas avec ce fonctionnement :

  • Le log n’est pas bon car il indique bien une reprise de la gestion automatique (Démarrage de la gestion automatique). D’après tes explications, il ne devrait pas reprendre du tout.
  • L’option Reprendre sur changement de mode (cocher la case pour reprendre la gestion automatique en cas de changement de mode) n’est pas forcément le bon terme. Ce serait plutôt Reprendre sur changement de mode si et seulement si la condition de vérification était valide pendant les différents changements de mode. Enfin, tu vois ce que je veux dire et où je veux pointer du doigt. D’où le fait que je ne trouve pas logique.

Mais peut-être quelque chose m’échappe dans cette logique.
As-tu un exemple concret à me donner pour que je comprenne (j’aime comprendre, surtout quand je ne trouve pas un comportement logique) le fait de ne pas mettre à jour la dernière position connue si la condition de vérification n’est pas OK lors du changement de mode?
Et dans quel cas, cela pourrait poser problème? Je ne vois vraiment pas. Mais je n’ai pas la science infuse.

Je ne suis pas d’accord avec toi sur ce point. Le plugin met bien à jour la position du volet actuel du volet au moment du changement de mode (quand condition de vérification OK).
Dans les screens ci-dessous, l’ordre de plugin sunshutter était de mettre le volet à 30%. J’ai bougé manuellement le volet à 67%. Et lors du changement du mode, la dernière position s’est bien mise à jour.
De plus, on parle bien de dernière position et non de dernier ordre (ça non plus, ce ne serait pas logique).

Bonjour,

  1. Le log est bon car il dit je reprend le mode automatique le temps de la verification des conditions
  2. Oui le texte n’est pas assez détaillé

Pour l’exemple je l’ai mis plus haut :

Je sais pas comment l’expliquer… tu as un mode A avec une condition 1. La gestion de volet est en mode forcer la reprise au changement de mode.

Ton volet a été mis à 0% par le plugin de gestion tu le bouge à 30%. La gestion automatique est donc suspendu.

Tu lances le mode A, vu qu’il force la reprise le plugin analyse les conditions malheureusement la condition 1 n’est pas valide. Il ne se passe donc rien et la gestion automatique reste suspendue.

La condition 1 devient vrai mais tu es toujours suspendu donc le volet ne bouge pas.

Pas de bug là dedans c’est le fonctionnement attendue il faut que lors du passage sur le mode A une condition soit vrai et que le volet bouge pour que ça lève vraiment la suspension.

Pour la position si, la tu montres la position du volet mais elle n’est absolument pas utilisé sur le check dans le code, tu l’as la : plugin-sunshutter/core/class/sunshutter.class.php at beta · jeedom/plugin-sunshutter · GitHub. C’est enregistré en cache tu ne peux le voir que dans les informations de l’équipement une fois que tu as cliqué sur configuration avancé. Comme l’indique la variable c’est bien la derniere ordre de position envoyé et non la position réel du volet.

Salut,

Le lien est inexploitable.

Sinon oui, (Loic) ce serait bien d’ouvrir à tous la repo de ce plugin aussi :wink:

@bad pour info

A oui le repo est privé j’avais pas vu désolé, je viens de demander a jeedom de l’ouvrir.

Ben non…
Encore une fois, je ne suis pas d’accord :sweat_smile:

Tu me dis que le plugin n’utilise pas la dernière position mais le dernier ordre qui est indiqué en cache.
C’est faux (ou je n’ai pas compris). La preuve en image ci-dessous.

Dernier ordre à 30%. Positionnement manuel du volet à 67% (donc arrêt de la gestion automatique) :

Le cache indique bien lastPositionOrder à 30% comme tu le signales :

Ensuite, je change de mode (le dernier ordre sunshutter était pour rappel à 30% et moi, j’ai bougé le volet manuellement à 67%) :

D’après ce que tu dis, dans le cache, il est censé indiqué lastPositionOrder à 30%. Or ce n’est pas le cas :

Il indique 67%, soit le mouvement manuel et non l’ordre.
Donc Dernière position du widget = lastPositionOrder du cache.

N’aurais tu pas dans le plugin sunshutter un positionnement a 67% qui s’est appliqué quand tu as envoyé l’ordre ?

Pour info avec la log ca serait quand meme bien plus pratique.

Les logs (mais rien de neuf par rapport à ce que j’ai déjà mis) :

[2024-01-25 14:43:04] DEBUG  : [Bureau][autoVoletSunshutter] Démarrage de la gestion automatique
[2024-01-25 14:43:04] DEBUG  : [Bureau][autoVoletSunshutter]Position actuel du volet 67
[2024-01-25 14:43:04] DEBUG  : [Bureau][autoVoletSunshutter] Ecart avec la dernière position connue : 37.37 %
[2024-01-25 14:43:04] DEBUG  : [Bureau][autoVoletSunshutter] Ecart avec la dernière position connue supérieur à 4 % : suspension de la gestion automatique
[2024-01-25 14:44:04] DEBUG  : [Bureau][autoVoletSunshutter] Gestion automatique suspendue : aucune action
[2024-01-25 14:45:14] DEBUG  : [Bureau][autoVoletSunshutter] Gestion automatique suspendue : aucune action
[2024-01-25 14:45:17] DEBUG  : [Bureau][autoVoletSunshutter] Passage en mode Nuit
[2024-01-25 14:45:17] DEBUG  : [Bureau][autoVoletSunshutter] Démarrage de la gestion automatique 1
[2024-01-25 14:45:17] DEBUG  : [Bureau][autoVoletSunshutter]Position actuel du volet 67
[2024-01-25 14:45:17] DEBUG  : [Bureau][autoVoletSunshutter] Calcul de positionnement - Conditions non remplies : #2165#=='Jour' Elévation = -90°-90 Azimuth = 0°-500° (30 %)
[2024-01-25 14:45:17] DEBUG  : [Bureau][autoVoletSunshutter]Position actuel du volet 67
[2024-01-25 14:45:17] DEBUG  : [Bureau][autoVoletSunshutter] Calcul de positionnement - Action par défaut : Ne rien faire

Et non, dans le plugin, il n’y a strictement rien à 67%. Uniquement à 30%.
J’ai mis tous les screens quelques posts plus haut quand j’ai expliqué comment j’ai effectué les tests.

Et pour moi, ce qu’indique logs est logique…

Doit avoir un truc quelque part je viens a nouveau de relire tout le log il y a 3 endroits dans le code ou le cache du derniere ordre est mis a jour :

Ya que le 1er qui peut etre executé sans qu’il y un ordre qui soit envoyé au volet (les 2 autres ont un execCmd avant) et si c’est le 1er il y a forcement la log « Ecart avec la position cible inférieur à 4 % : aucune action » c’est pas ton cas.

J’ai donc aucune idée de ou ca passe dans le code. La je ne sais pas comment t’aider, le code est ouvert a voir si d’autre comprenne on a atteint la limite de mes compétences la. Désolé.

Donc il y a un bien un truc qui ne va pas.

Comme dit, si tu veux reproduire mes tests, j’ai tout indiqué de comment faire.
Pour moi, il y aurait deux choses à faire :

  • Renommer lastPositionOrder par lastPosition car visiblement la variable prend la dernière position et non le dernier ordre
  • Mettre à jour cette variable au changement de mode que ce la condition de vérification soit valide ou non (car au final, c’est juste une info de dernière position… qui est réelle).