Problème lors d'une ouverture avec télécommande

Bonjour,

J’ai un petit soucis lorsque j’utilise la télécommande d’un volet pour le fermer, le plug-in envoie des stops en continu. Pour résoudre le problème je dois redémarrer le démon.

Bonjour

Quel est votre configuration

J’ai des volets avec une motorisation ematronic et un RFXcom pour les piloter.

Bonjour,

Ah j’ai exactement le même problème suite à la màj du plugin et je croyais que cela venait de ma config ! du coup j’ai carrément désactivé le plugin dans l’urgence car enchainement de stop c’était la panique.

J’ai des modules DIO pour volet roulant et RFXcom mais le problème ne vient pas des modules donc je pense que c’est du côté de la condition sans retour d’état qu’il part en cacahuètes.
Je peux préciser que je n’ai pas eu ce soucis jusqu’à la màj.

Côté Jeedom c’est vraiment dommage qu’il n’y ait pas un bouton « aie ça ne fonctionne pas fais moi retourner à la version du plugin d’avant » car restaurer un backup complet c’est overkill comme on dit :slight_smile:

Appel de la fonction d’ouverture puis enchainement de stop dans le log :

[2021-06-17 06:43:57][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-06-17 06:44:26][INFO] : [Bureau Tests][Volet Bureau Proportionnel][Démon] Execution du stop
[2021-06-17 06:44:26][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-06-17 06:44:27][INFO] : [Bureau Tests][Volet Bureau Proportionnel][Démon] Execution du stop
[2021-06-17 06:44:27][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-06-17 06:44:28][INFO] : [Bureau Tests][Volet Bureau Proportionnel][Démon] Execution du stop

Bonjour,

J’ai exactement le même problème depuis la dernière mise à jour du plugin.
La seule solution que j’ai trouvé pour le moment, c’est d’enlever la commande STOP.

Le résultat est visible sur les log MQTT de mon Tasmota, toutes les secondes (temps entre 2 commandes)

[23:06:30] tasmota_88156F/cmnd/ShutterStop2
[23:06:30] tasmota_88156F/stat/RESULT {« ShutterStop »:« Done »}
[23:06:31] tasmota_88156F/cmnd/ShutterStop2
[23:06:31] tasmota_88156F/stat/RESULT {« ShutterStop »:« Done »}
[23:06:32] tasmota_88156F/cmnd/ShutterStop2
[23:06:32] tasmota_88156F/stat/RESULT {« ShutterStop »:« Done »}
[23:06:33] tasmota_88156F/cmnd/ShutterStop2
[23:06:33] tasmota_88156F/stat/RESULT {« ShutterStop »:« Done »}
[23:06:34] tasmota_88156F/cmnd/ShutterStop2
[23:06:34] tasmota_88156F/stat/RESULT {« ShutterStop »:« Done »}
[23:06:35] tasmota_88156F/cmnd/ShutterStop2
[23:06:35] tasmota_88156F/stat/RESULT {« ShutterStop »:« Done »}

La meme chose dans la log debug du plugin comme cité précédemment.

Un restart du daemon ne résout que temporairement le pb, car celui revient rapidement.

Avez vous pus identifier le problème ?
Merci de votre aide .

Je n’ai pas assez d’element et je n’arrive pas a reproduire le soucis

En fait le problème apparaît uniquement lorsque j’utilise les télécommandes pour une ouverture ou fermeture complète sans utiliser le bouton stop. Si j’utilise le plug-in pour ouvrir ou fermer les volets ça fonctionne, ça fonctionne également avec les télécommandes si je fait un stop avant la fin de l’ouverture ou fermeture.

Bonjour,

En fait a chaque fin de mouvement, monté ou descente, le plugin envoi un stop, sauf que l’envoi de la commande stop boucle en permanence, et bloque complètement toute commande suivante .
La solution est d’enlever la commande stop de chaque objet.
Mais cela engendre des comportements bizarre, du style fin de descente mal détecté, donc remonté impossible via les commandes du plugin. meme si la commande stop n’est plus paramètre, le plugin semble quand meme vouloir l’envoyer. Je ne sais pas si c’est qu’il ne détecte pas la fin du mouvement et pense qu’il est toujours en cours de descente.
Les commandes fonctionnement parfaitement depuis l’extérieur du plugin (via GUI Tasmota).

Voila. Dites moi si vous avez besoin de plus d’info.
Ci joint une petite capture pour la compréhension de ma modification enlever commande stop, et l’output debug du plugin pour les commandes stop envoyées en boucle lors de descente de volet.

Jerome

Capture d’écran 2021-06-28 à 14.11.49

Merci pour les précisions
Je vais chercher dans le code des buté

@jeromel73
Je ne trouve pas le probleme dans le code
Est ce qu’il serait possible de me faire une connexion sur ton jeedom?

Hello ,

Désolé du délai, pas mal de boulot :wink:
oui, on peut faire une session de partage.
Dis moi quand tu peux.

Merci.
Jerome

Hello,

Je viens de refaire des essai, et j’arrive a reproduire le problème systématiquement.
Une fois le mouvement de descente terminé par ex, le plugin envoi un stop. Normal.
Si une nouvelle commande de descente est faite, le plugin je pense voit le niveau deja en bas, mais envoi encore une commande de stop. Jusque la, pourquoi pas.
Mais si une nouvelle commande de descente est envoyé, la le plugin freeze quelques secondes, puis se mets a envoyer en permanence une commande de stop.
A ce moment la, les prochaines commandes ne sont plus prisent en compte.
Seul une action externe du volet, ou enlever la commande stop du setup permet d’arrêter cette boucle.

Voila.
Si ca peut aider dans le diagnostic.

Jerome

Bonjour,

J’ai refait le test dernièrement en réactivant le plugin et j’ai encore le problème de la commande en boucle.
Je ne peux que supposer qu’un test de valeur tourne en boucle mais il n’y a pas plus de log qu’avant qui permette de diagnostiquer le problème.
Dans tous les cas la seule chose que je sache est que c’est arrivé après une màj du plugin et que Jeedom ne permet pas de revenir à une version antérieure d’un plugin.

A minima ce serait bien qu’il y ait une protection en interne pour ne pas envoyer des commandes en boucle comme ça et que le bombardement de commandes soit détecté, pour que dans ce cas le plugin bascule sur un mode purement ON/OFF car les volets qui se mettent à bombarder les commandes c’était une catastrophe et ça va que j’étais là lorsque c’est arrivé.

Est-ce que qq’un a encore ce bug avec un module sans retour d’état ? dans mon cas c’est un module Chacon/DIO .

Bonne journée !

Hello Bender,

Pareil, toujours le « bug ».
Je ne sais pas si cela vient du plugin, ou du core Jeedom, mais en tout cas ton idée de mettre une protection des commandes en boucles et détection serait très utile.
Pour ma part, sur le plugin Volet Proportionel ou je rencontre ce pb, n’ayant pas de correction possible pour le moment, et le pb disparaissant temporairement avec un redémarrage du daemon, j’ai mis en place un scénario qui fait un stop/start du daemon toutes les 5 mns.

Ci dessous le code si cela peut t’aider ou quelqu’un d’autre :wink: .

Créer un scénario, et ajouter un bloc code.
Copier ce code dans le bloc, et changer le nom du plugin (ici voletProp)

// id du plugin
$_plugin_Id = ‹ voletProp ›;

// charger le plugin 
$_plugin = plugin::byId($_plugin_Id);
if (is_object($_plugin)) {
   	// Restart deamon ...
	$scenario->setLog('Arret du plugin ' . $_plugin_Id);    
	$_plugin->deamon_stop(true);  
	$scenario->setLog('Demarrage du plugin ' . $_plugin_Id);    
	$_plugin->deamon_start(true);  
	$scenario->setLog('status daemon du plugin : ' . $_plugin->deamon_info()['state']);
}
1 « J'aime »

Un démon est forcément une boucle
Si le plugin tourne en rond c’est qu’il y a certainement une incoherance avec vos retour d’etat
Pouvez vous essayer sans

Mika, avec ta question je viens de me souvenir d’un problème que j’ai eu lors de la sortie de la nouvelle version du plugin officiel Rfxcom.
J’appuyais sur mon interrupteur Chacon qui éteignait ma lumière (prise 220V Chacon) puis Jeedom détectait cet ordre (de la télécommande) et rallumait la lumière pendant 20s puis l’éteignait. C’était le comportement attendu pour que j’ai le temps de quitter la pièce.

Mais avec le nouveau Rfxcom j’ai la prise qui s’allumait et s’éteignait en boucle car je ne me souviens plus des détails mais j’avais une répétition, le fait d’envoyer un ordre par la telco déclenchait un événement qui relançait ma boucle à partir de l’envoi fait pour éteindre la lumière donc je dois creuser de ce côté.

Là je me demande si je n’aurais pas le même problème et que le plugin de volet recevrait un ordre en boucle qui déclencherait la condition d’état de montée/descente, en tout cas d’un coup cela me semble cohérent mais il faut que je réactive mon scénario avec la lumière pour identifier le problème plus facilement.

D’ailleurs l’ancien plugin Rfxcom fonctionnait impec avec mes modules chinois et le nouveau plugin Rfxcom a été une cata mais je n’ai plus eu le courage de passer des heures dessus, j’ai été épuisé par ces modules chinois avec les trames non standard.

Je vous tiens au jus.
@+

Pour le plugin Rfxcom qui déclenchait un événement sur le passage à 0 (qui me faisait une boucle) j’ai réactivé mon vieux scénario pour la lumière et ça ne le fait plus donc mauvaise piste.

Si qq’un est intéressé :


J’ai réactivé le plugin proportionnel, je ne touche à aucune télécommande Rfxcom/DIO/Chacon et je clique seulement sur les boutons de montée/descente de voletprop mais le problème est encore là :

[2021-10-08 19:20:30][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-10-08 19:20:52][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-10-08 19:20:52][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-10-08 19:20:58][INFO] : [Bureau Tests][Volet Bureau Proportionnel][Démon] Execution du stop
[2021-10-08 19:20:58][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-10-08 19:20:59][INFO] : [Bureau Tests][Volet Bureau Proportionnel][Démon] Execution du stop
[2021-10-08 19:20:59][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-10-08 19:21:00][INFO] : [Bureau Tests][Volet Bureau Proportionnel][Démon] Execution du stop
[2021-10-08 19:21:00][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-10-08 19:21:01][INFO] : [Bureau Tests][Volet Bureau Proportionnel][Démon] Execution du stop
[2021-10-08 19:21:01][DEBUG] : [Bureau Tests][Volet Bureau Proportionnel] Exécution de la commande [Bureau][Volet roulant bureau][Off]
[2021-10-08 19:21:02][INFO] : [Bureau Tests][Volet Bureau Proportionnel][Démon] Execution du stop

Et ça fait ça sans aucun temps mort et à l’infini.

Je remet ma config :

D’ailleurs j’ai remarqué que le slider de position du volet ne semble plus fonctionner et je ne me souviens plus avec quelle version mais les problèmes sont arrivés lors d’une màj de voletprop sans modification de mes scénarios entre temps.

Le log est en mode Debug mais je trouve qu’il n’est pas très détaille et du coup je ne sais pas si c’est juste une valeur vide qui poserait problème.
En tout cas pas de soucis si je peux tester ou vérifier autre chose.

Il faut regarder le cycle complet mais d’après ce que j’ai vue sur tes précédents log est la non réception du stop.

Je vois que tu l’a supprimé mais du coup ça ne peux pas fonctionner (sauf si le stop est émise par un up ou down).

Peux-tu faire un test sans aucun retour d’état

Exact ! sans aucun retour d’état ça a l’air ok mais je dois refaire le test demain.

En parallèle j’avais déjà commencé à regarder le php et je ne retrouvais pas le lien entre le Stop qui doit exécuter (dans le cas du module volet DIO/Chacon) le dernier ordre car Stop = Montée+montée ou Descente+descente .

Et je me souviens pour le retour d’état c’est parce que j’utilisais voletprop pour « attraper » les ordres de la télécommande Chacon pour déterminer sa position virtuelle vu que ma télécommande est liée directement au volet roulant pour ne pas avoir de surprise si Jeedom était HS.

Rien à voir mais lors de mes tests il m’arrivait de ne plus avoir de log de voletprop comme si le fichier était supprimé et/ou vidé entre temps.