Du jour au lendemain, sur tous les volets Velux IO, j’ai perdu les commandes qui permettent de faire les remontée de l’état, c’est à dire les commandes de type info, celle qui donne les core:ClosureState / core:NameState / core:OpenClosedState / coreStatusState / …
J’ai supprimé le volet et lancé une synchro du plugin Tahoma. Le volet est bien redétecté. Quand je regarde ses commandes, celles de type Info sont revenues:
Mais elles disparaissent dès la première sauvegarde (après avoir activé l’historisation par ex.).
Ou plutôt, il ne reste plus que l’ID de la commande dans la liste:
Suppression de plugin et reinstall + reboot Jeedom
Note: aucun problème côté Somfy, l’état des volets remonte bien sur leur app/site et leur pilotage fonctionne bien.
Comprends pas pourquoi ça fait ça… Si quelqu’un a une idée miraculeuse, je suis preneur. Je n’ai pas contacté le developpeur, mais le plugin n’étant officiel, il n’est pas tenu de répondre, non ?
A tout hasard la passerelle tahoma n’est pas compatible homekit? (Je sais que les derniers kit de connectivité Somfy le sont. )
Si elle est compatible homekit il doit être possible d’utiliser le plugin hkcontrol.
je rencontre le même soucis depuis quelques temps (alors qu’aucun soucis auparavant).
pour ma part, je crois que c’est apparu suite à la mise à jour du plugin.
C’est vraiment embêtant, plus d’état donc Alexa pas contente et tous mes scénarios de volets en carafe
Si quelqu’un a une solution, je suis preneur
Merci antar, kenin & Nex008 pour vos commentaires.
Je viens de contacter le developpeur, peut être a-t-il repris du service car le plugin a eu de nouvelles versions ces derniers temps. Croisons les doigts.
Si ça ne donne rien, je vais reprendre une solution que j’avais envisagée quand j’avais déjà eu un problème avec ce plugin, c’est à dire le mode développeur de Somfy.
Oui car même si le bug du plugin se règle, il garde un handicap majeur: le plugin s’appuye encore sur le Cloud de Somfy alors qu’il y a maintenant une API locale accessible directement sur les Tahoma.
(détail ici: GitHub - Somfy-Developer/Somfy-TaHoma-Developer-Mode: A collection of requests to use a local API with Somfy TaHoma gateways)
J’avais commencé à creuser le sujet pour piloter les volets via curl, par exemple la commande ci dessous pour ouvrir un volet:
Ligne de commande testée et approuvé pour ouvrir
Par contre, mais je n’arrive pas à trouver la commande pour remonter l’état aussi (comme la fonctionn disparue du plugin…)
Si quelqu’un a un peu d’expérience sur le sujet, je peux bien de l’aide !
Bonjour Nex008,
En effet, la solution est valable aussi pour mon cas.
Merci, je ne l’avais pas trouvée !
Du coup, je mets le plugin Tahoma en mode « Ne pas mettre à jour »
Pour l’API locale, il n’y a pas de « push » pour l’instant, donc il faut procéder ainsi:
créer un « event listener » via l’API /events/register
« poller » de manière régulière l’API /events/{listenerId}/fetch pour recevoir tous les évènements de la box depuis le dernier appel
analyser les événements reçus pour mettre à jour l’état des ouvrants
Un listener est supprimé automatiquement après 10 minutes sans avoir été interrogé (ou au reboot de la box), donc il faut faire des appels en continu.
Je n’utilise pas le plugin Tahoma, mais comme j’ai déjà NodeRed et MQTT (+ le plugin jMQTT), j’ai créé un flux nodered pour :
envoyer une commande vers un appareil via un post dans un topic MQTT (un par appareil)
poller les événements de la Tahoma, filtrer ceux qui m’intéressent et poster les changements d’état dans le topic MQTT de l’appareil
créer des équipements jMQTT pour envoyer les commandes et récupérer l’état courant dans Jeedom
Pour faire ça proprement et ne pas surcharger la box par des appels inutiles, il faudra une fréquence d’interrogation des événements relativement longue par défaut (30 secondes, 1 minute, ou même plus), et avoir augmenter le nombre d’appels API dans la période de 2 minutes qui suivent l’envoi d’une commande (par exemple toutes les 3 secondes) pour avoir un retour d’état plus immédiat.
Bonjour Kimagure,
Merci beaucoup pour ces infos.
Je comprends mieux pourquoi la solution ne se trouve pas si facilement dans les forums, c’est un peu plus ardu que les commandes ouverture/fermeture…
Je ne suis pas encore rendu à utiliser les MQTT, mais je vais tenter, merci d’avoir détailler la séquence.
A+
Une fois que tu as réussi à récupérer le token, et à taper l’API locale pour lancer une commande, il n’est pas beaucoup plus compliqué de faire le pool des events. Un appel (pas très différent de ceux qui lancent les commandes) pour créer un listener, puis en boucle un appel pour récupérer les events… C’est pas beaucoup plus complexe
Le plus compliqué c’est que la documentation est un peu chiche, je trouve, sur les events que l’on va récupérer. Et après, oui, il faut traiter correctement les events récupérés en réponse suivant le cas.
A noter que meme si ca n’est pas recommandé de le faire trop souvent, l’appel à /setup permet de récupérer l’ensemble des informations.
La grosse lacune, à mon sens, de l’API locale pour le moment, c’est qu’elle ne permet pas de gérer ni meme déclencher un scenario Tahoma.
