Non cela modifie à chaque fois que la valeur change :
(#[Maison][PACAIREAU][2 - State]#==1)
si la commande state n’est pas égale à 1 alors la commande état vaudra 0.
1 « J'aime »
Je viens de tester en effet niquel cela bascule ma nouvelle commande binaire à 0.
Parfait merci 
1 « J'aime »
C’est déjà corrigé chez moi… Si j’ai compris le problème.
Ce n’est pas que state mais toutes les infos binaire qui ne se mettent pas à jour.
J’ai mis à jour la version bêta hier, donc soit c’est disponible aujourd’hui, soit demain, je n’ai pas encore la main pour forcer la mise à jour.
Hello,
Je viens de corriger un petit problème côté market qui récupérait pas les updates.
Je viens de force push cette update également, elle devrait donc être dispo depuis 5 min
Cordialement
Thibaut
3 « J'aime »
Bonjour,
Tu parles de la problématique de remise à la valeur 0 de la commande state lorsque la climatisation est stoppée dans ton correctif ?
Si oui, je peux retirer la solution de contournement de @laurent.da-col ?
PS : c’est dommage de se priver de ton plugin en version stable juste pour la documentation car il est top et fonctionne vraiment très bien.
Merci
Oui, j’ai effectué la correction, je n’ai plus de soucis de remonter chez moi.
En attente de vos retours.
2 « J'aime »
Je viens de tester en effet la commande « State » se met bien à jour avec la valeur 0.
Good news
Merci
Bonsoir,
Pour information j’ai testé d’allumer la clim avec la télécommande : remonté state ok
Puis éteindre avec l’application Onecta : state reste sur allumé assez longtemps
Le rafraîchissement de l’état a pris au moins 5 minutes
C’est le cas depuis toujours pour moi.
Je fais systématiquement un wait après chaque action pour vérifier la bonne prise en compte :
Cela prend en général quelques minutes et parfois effectivement plus de 5 minutes :
Hello,
Je me permets de répondre à la place de @sagitaz, puisqu’il est encore en train de prendre en main le code du plugin.
Le temps de latence que vous observez ne provient pas d’une limitation de notre plugin, mais bien de Daikin.
Le plugin intègre plusieurs petites fonctionnalités destinées à rendre les latences liées aux commandes et aux remontées d’informations aussi transparentes que possible lorsque vous utilisez uniquement celui-ci.
Cependant, si vous interagissez avec la climatisation via la télécommande ou l’application officielle, il faut attendre le prochain rafraîchissement, qui se déclenche périodiquement dans le plugin.
Je rappelle que Daikin impose une limite de 200 requêtes par jour. Une requête correspond à :
- 1 action (toute interaction avec l’appareil depuis le plugin)
- 1 lecture d’information (toute récupération de l’état des appareils)
Pour vous donner une idée, le plugin dispose de plusieurs mécanismes pour optimiser et réduire les requêtes :
- Vérification, lors d’une action, qu’un vrai changement est nécessaire afin d’éviter une requête inutile.
- Lors de la mise à jour des informations, récupération des données de tous les appareils connectés au compte en une seule requête.
- Rafraîchissement complet des appareils une minute après une commande afin d’obtenir un retour fiable. Ce délai a été fixé à une minute car l’API met du temps à traiter les actions : elle envoie la commande à l’appareil, attend son retour, puis met à jour les informations — ce qui prend entre 20 et 40 secondes lors des tests.
Voici la configuration actuelle du démon pour rester stable malgré la limite de requêtes :
- Actualisation des informations toutes les 15 minutes
- Actualisation des informations entre 1 minute et 1 minute 30 secondes après une action ayant réellement modifié l’appareil
Lien de la documentation de Daikin sur la limitation : Developer Portal
Pour ce qui sont pas connecté sur le portail Developer Daikin :
Cdt
Thibaut
3 « J'aime »
Pour ma part le décalage n’est pas un problème je fais avec depuis toujours. Je n’utilise pas de télécommande le plugin est seul à interfacer ma pac et je constate un délai de rafraichissement après action souvent supérieur à 1 minute 30 secondes.
Merci en tout cas pour ces explications vraiment très claires sur le fonctionnement du plugin.
Salut,
Je ne sais pas ce que sagitaz décidera de faire de ce « problème » mais personnellement j’aurais tenté de faire un mécanisme, lors d’une action déclenchée dans Jeedom (donc par le plugin), qui :
- Passe immédiatement la valeur info de la commande en adéquation avec la demande pour ne pas attendre environ 1 minute d’avoir un retour visuel sur l’action demandée
- Informe (mise à jour d’une commande spéciale ?) lors du prochain check cloud si le retour d’info n’est pas en adéquation avec ce qui a été demandé
Bon c’est sûr que si y’en a un qui s’amuse à faire l’action depuis Jeedom et un autre depuis la télécommande alors … ça risque d’être pénible à gérer 
Pour le moment, je n’ai rien décidé, comme je l’ai dit, je reprends le plugin afin de le passer en stable (surtout), d’y ajouter une petite documentation et le reste ce sera comme je peux.
Le boulot + le bébé ne me laissent que peu de temps pour la geekerie, mais bon je n’en avais apparemment pas assez avec 3 plugins à gérer 
Le souci de forcer la valeur sans attendre le retour de Daikin, c’est que si cela foire, ce n’est pas la joie.
Une nouvelle commande info « commandes validées » qui passerait à false lorsqu’on exécute une action et qui, une fois la réponse de Daikin, si ok, repasse à true ? Pourquoi pas, pas trop compliqué à mettre en place.
Alors oui c’est une idée, mais dans ce cas, j’ai du mal à voir comment on pourrait se déclencher une petite action (scénario) qui nous alerte sur le possible raté de l’exécution.
En utilisant une commande info « commandes validées », je pense qu’il faudrait 3 états (qui peuvent être numérique mais je l’écris en toute lettres c’est plus compréhensible) : En attente, Validée et Non validée
-
Envoi d’une action
1.a Passage de la commande info correspondante en adequation avec l’action
1.n Passage de la commande « commandes validées » à « En attente » -
Interrogation Cloud
2.a Si « commandes validées » == « En attente » et que la commande Cloud est la même que la commande info → « commandes validées » devient « Validée »
2.b Si « commandes validées » == « En attente » et que la commande Cloud est différente de la commande info → « commandes validées » devient « Non validée »
L’oscillation normale serait entre « En attente » et « Validée » et dès ça passe en « Non validée » on pourrait déclencher une petite alerte via l’outil de notif préféré
Hello,
Merci @Thibaut_T pour ces explications précises et détaillées 
J’avais juste une petite remarque/suggestion :
Je comprends tout à fait au vu des limitations imposées par l’API que l’actualisation soit cyclique et qu’il faille faire attention à ne pas « cramer » trop d’appels pour rien, mais je trouve dommage qu’on ne puisse pas forcer une actualisation avec une commande action par exemple sur un besoin bien précis.
Par exemple quand je vais me coucher, je change une commande mode en « Nuit » et j’ai un scénario qui se déclenche pour lancer tout un tas d’actions événementielles (éteindre les lumières, la musique, fermer les volets, allumer l’alarme …)
J’aurais voulu que pour ce cas la je puisse éteindre ma clim si elle est en marche et sans attendre le prochain rafraichissement (qui pourrait se produire après que mon scénario ait fini de s’exécuter).
Donc avoir la possibilité de forcer à la demande (et avec parcimonie) un refresh pour un cas bien précis comme celui ci.
Il me semble que si je redémarre le daemon c’est ce qu’il va faire pour se resynchroniser avec l’état réel coté daikin mais je trouve que c’est un peu lourd juste pour forcer un état.
Qu’en pensez vous ?
Je regarde pour vous ajouter une commande refresh.
2 « J'aime »