Évolution plugin : cron

Bonjour,

@Flobul : Serait-il possible d’envisager une petite évolution du ce plugin afin que « l’intervalle de rafraichissement des information (cron) » soit plus court que la minute ?

« 30 secondes » ou « 15 secondes » par exemple

Par avance, merci


Informations Jeedom Atlas

Core : 4.4.9 (V4-stable)
DNS Jeedom Atlas : oui

Plugin : LG ThinQ
Version : 2024-05-12 19:00:32 (stable)

Bonjour.

Non, ce n’est pas prévu.

Car la connexion MQTT gérée par le démon permet de récupérer les notifications des commandes info en temps réel.

Donc inutile de surcharger les serveur LG Thinq avec des requêtes suspectes. Sachant que l’API n’est pas officielle et peut à tout moment sauter.

Sans compter que pour certains jeedom sur PI, il faut plus d’une minute pour un cron.

Ca m’intéresse de savoir comment récupérer ces informations temps réel. Car c’est récupérer les information temps réel que je cherche. Quelle que soit la méthode.

C’est déjà dans le plugin.
C’est le démon qui fait tout.
Dans les logs en debug tu vois les infos qui remontent via des lignes qui commencent par :

[2024-08-12 15:55:01] DEBUG  : DÉMON MQTT :  ...

Si tu veux rafraichir toutes les 30 secondes, tu peux faire une scénario en déclenchement à chaque minute, de mettre un sleep 30 et lancer la commande rafriahcir de l’équipement.
Mais encore une fois, c’est déconseillé dans la doc scénario de jeedom :https://doc.jeedom.com/fr_FR/core/4.3/scenario

je ne suis pas sur d’être au bon endroit dans Jeedom. Je suis un néophyte en ce qui concerne les debug des plugins de jeedom.

J’ai passé le plugin lgthing2 en Debug, suite à ta suggestion (c’est ce que j’ai compris), j’ai envoyé quelques commandes depuis le plugin, je les vois bien passer dans le log, j’entends ma clim qui reçoit les ordres. par contre, aucune ligne qui commence par DEBUG : DEMON MQTT dans les logs.

Est-ce que c’est là qu’il faut chercher ? car je ne vois rien qui concerne MQTT dans la config du plugin lgthings.

Elles arrivent que pour quelques commandes, lorsque l’appareil les communique, ou lors d’un changement de valeur (porte du frigo qui s’ouvre, durée du filtre aui est périmé )

J’ai indiqué une solution :

ok merci pour tes explication, je vais faire avec ce que j’ai et la commande rafraichir que je n’avais pas vu.

Au passage de l’analyse de mes lignes de debug, j’ai constaté ceci :

j’envoi une commande windStrength avec la valeur 2 et sur la 4eme ligne on voit le retour "data" : "" alors que dans l’idéal data devait etre égal au « 2 » envoyé par la commande.

Ca fait ça sur n’importe quelle commande envoyée, pas seulement windStrength.

« Donnée envoyée »: c’est les données envoyées par jeedom
« Réponse reçue » : c’est le retour qu’a fait LGthinq suite aux données envoyées.
|17:38:46]||DEBUG|Action sur OperationbasicCtrlairState.windStrength avec options i « background »: « 0 »

Je lis que tu envoies la commande airStarte.windStrength à la valeur 2.
Et que l’API répond 0000, donc parfaitement exécutée. Le résultat dans data n’est pas forcémeent alimenté lors des commandes action.

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.