Je reprend une réponse faite à un poste sur le forum il y a peu :
J’ai fait d’assez grosses modifications sur le plugin, j’y ai ajouté un certain nombre de fonctionnalités…
J’ai ajouté le support de :
Volets avancés (en tout cas pour le retour d’état, je peux facilement rajouter une commande avec un slider si nécessaire)
Énergie (en tout cas lecture des valeurs de puissance/consommation)
Commandes CEN+ (donc un bouton physique myhome peut déclencher un évènement dans Jeedom)
Les contacteurs secs (j’en utilise un par exemple pour un retour d’état pour ma porte de garage)
J’ai aussi corrigé un problème qu’on a sûrement tous rencontré, l’impossibilité de mettre plusieurs commandes myhomescs dans un scenario sans cocher la case « exécuter en parallèle ». Ça empêchait aussi de pouvoir en utiliser plusieurs dans un bloc code de scenario. Bref, c’est corrigé.
Aussi une petite amélioration dans la gestion des trames reçues sur le bus event, qui parfois pouvaient arriver tellement rapidement qu’elles étaient concaténées et du coup pas interprétées par Jeedom.
J’ai fait quelques autres petites optimisations par-ci par-là…
Mes questions du coup sont : est-ce que ça intéresse quelqu’un ? et si oui, est-ce qu’il est envisageable que ces changements soient ajoutés à la codebase officielle ? comment ?
J’aimerai effectivement supprimer tout les petits contournement que j’ai en place dans mes scénarios pour compenser les manques plugin et aussi avoir une chance de connaître l’état de mes volets (impossible actuellement car Jeedom ne comprends pas que les volets sont en mouvement)
@fabx4, est-ce qu’il y a un intérêt spécifique à ce que Jeedom sache que le volet est en mouvement ?
Actuellement ce que je fais c’est que j’interprète les « DIMENSION REQUEST RESPONSE » qui sont envoyées spontanément par les actionneurs avancés lorsqu’ils s’arrêtent et qui donnent la position.
En gros je ne connais la position que une fois que le volet s’est arrêté.
Je me suis très mal exprimé et j’ai mal interprété le terme volet avancé.
Mes volets (et BSO) sont commandés par des F411 qui ne sont pas des actionneurs avancés.
Toutefois, lorsqu’on lui demande de monter, le F411 confirme qu’il monte (à la mise en mouvement) et dit qu’il s’arrête lorsqu’il s’arrête. Pareil pour la descente.
Le problème est qu’actuellement, le plugin ne voit pas systématiquement la confirmation du mouvement ni même le stop. Parfois oui, souvent non.
C’est comme ça que j’en suis venu à cocher la case « exécuter en parallèle » en me disant que Jeedom enverrai les commandes sans se soucier qu’elles passent correctement.
Je m’en étais rendu compte lorsque j’ai voulu faire un scénario qui, par comptage du temps, devait déterminer approximativement la position du volet. J’ai alors trouvé un post sur l’ancien forum qui parlait du même problème.
J’ai constaté aussi que le problème ne concernait pas que les volets.
J’ai aussi une alarme Legrand MyHome. Pour que Jeedom sache qu’elle est activée ou pas, j’ai paramétré l’alarme pour qu’elle « allume » deux sorties de F411 différentes selon l’état ON ou OFF de l’alarme (cf vidéo de MyHomebox). Parfois, noyé parmis les trames de l’alarme, Jeedom n’interprète pas celle qui reflète l’état de l’alarme qui pourtant se comporte comme une lumière. La trame est bien dans les logs mais Jeedom ne l’a pas interprété.
Donc, si tu as fait des modifications qui corrigent tout ça, même si je n’ai pas d’actionneur avancé, je suis très intéressé.
Ahhhh, OK, je comprend mieux du coup !
Je n’ai pas du tout touché au calcul que le plugin fait pour essayer d’extrapoler la position en fonction du temps sur les volets « classiques ». Comme j’avais choisi de changer mes actionneurs pour en mettre des « avancés », je me suis concentré sur l’ajout du support de fonctionnalités OpenWebNet existantes.
J’ai par contre effectivement corrigé le problème qui empêche d’exécuter plusieurs commandes myhome dans le même scenario. Et pour l’histoire des trames non interprétées, mon problème était avec la gestion de l’énergie qui peut renvoyer des dizaines de trames en l’espace d’une ou deux secondes avec certaines commandes. Ça amenait à des situation ou je recevait #trame1###trame2## en une seule ligne, et Jeedom je savait pas quoi en faire.
Tu as des exemples de logs de tes trames non interprétées ? Je suis curieux de voir ce qu’il se passe.
Autrement, je ne pense pas qu’il soit délirant d’ajouter un support basique du module d’alarme si besoin, au moins pour un retour ON/OFF. Mais comme je n’ai pas d’alarme MyHome, je ne suis même pas certain de quelles informations sont disponibles sur le bus « automation »… (ou même de quelles actions/informations pourraient être intéressantes)
Salut,
Si tu es d’accord de donner ton code a l’équipe Jeedom, ils peuvent l’intégré. le plus simple est de me l’envoyer ou de l’envoyer directement a @Alexandre qui l’intégrera dans le plugin.
Le plugin ne s’occupe pas de faire le calcul, j’avais fait un scenario pour ça. Mais si le plugin le manque plus les infos, le scénario risque de beaucoup mieux fonctionner.
Pour avoir des exemples, ça risque de me prendre du temps et avec de la chance le plugin sera corrigé d’ici que je puisse le faire.
Je ne pense pas qu’il vaille la peine d’intégrer les trames de l’alarme dans le plugin:
1 - je n’ai pas trouvé la doc
2 - je n’ai pas trouvé la trame qui pourrait indiquer le status de l’alarme sur mes logs lorsque j’ai cherché
3 - quelq’un avait posté (sur l’ancien forum) son log sur le bus lors de l’activation et les trames qui passaient étaient différentes des miennes (certainement des affectations de zones différentes)
Je trouve que c’est trop de travail pour le peu de personne concerné et je suis certains que les concurrents de Jeedom passent par les AUX.
Le mieux reste la configuration de l’alarme pour activer des sorties auxiliaires (F411 ou autre configuré en éclairage mais branché sur rien), le tout étant que Jeedom ne loupe pas leur activation (ce qui devrait ne plus être le cas avec tes modifications).
En tout cas merci de partager et, pour l’équipe Jeedom, c’est pas parce que je dis que certaines choses fonctionnent mal que je ne suis pas content. Je viens d’une solution qui n’est pas communautaire, qui ne fonctionne pas, qui est beaucoup moins universelle et pour laquelle j’aurai du appelé l’installateur pour le moindre ajout de périphérique ou correction de scénario.
Les équipements « énergie » doivent avoir comme adresse « E5[identifiant myhome] » (ex: E51, E52, …, E5255)
Les commandes « RefreshP » (*#18*#WHERE#*#1200#1*255##) renvoient la puissance instantanée mesurée pour une durée de 255 minutes (c’est le dernier paramètre de la commande, et c’est le maximum admissible) donc pour avoir en permanence la puissance instantanée, j’exécute ces commandes dans un scénario avec une cron 0 0,4,8,12,16,20 * * *
Les commandes « RefreshC » (*#18*#WHERE#*54##) renvoient la consommation totale de la journée en cours. Ces valeurs ne sont mises à jour par le système MyHome que toutes les heures, donc j’exécute ces commandes dans une cron 5 * * * *
Il y a aussi une info « consumption_history » qui n’est pas remplie par défaut. Je la remplie tous les jours à 4h du matin par l’exécution d’un scénario qui me sort la consommation par heure de la veille.
Comme on peut le voir dans ce bout de scénario, on peut maintenant appeler myhomescs::send_trame() et lui passer en paramètre soit une trame en string soit un array de trames qui seront envoyées sur le bus.
Les équipements « CEN+ » doivent avoir comme adresse « C2[identifiant myhome] » (ex: C20, C21, …, C22047)
Dans les équipements « CEN+ » il y a des info « Button 0 » « Button 1 » etc… qui correspondent aux PushButton MyHome, on peut en créer jusqu’à 32 [0-31] par équipement CEN+ sur le même modèle. (info de type string avec « LogicalID » de type int qui correspond au numéro de PushButton et avec « Gestion de la répétition des valeurs » sur « Toujours répéter »)
Les contacts secs doivent avoir comme adresse « D3[identifiant myhome] » (ex: D31, D32, …, D3201)
Les volets interprètent les trames DIMENSION REQUEST RESPONSE même si ils ne sont pas configurés comme « avancés » dans Jeedom. Donc si vous avez des volets « avancés » mais qu’ils sont configurés comme volets simples dans Jeedom, vous aurez quand même un retour d’état correct.
N’hésitez pas à demander si vous avez des questions!
Bonjour. Merci pour les améliorations du plugin! Je voulais savoir si il était prévu d’ajouter les fonctions de thermorégulation. Je me suis inscrit récemment sur la communauté pour contribuer si nécessaire mais je n’ai pas eu de réponses. Comment puis-je accéder au repo du plugin et pouvoir éventuellement y mettre ma contribution.
Merci d’avance
Le repo est privé. Ce qui est logique sachant que c’est un plugin payant. Ce que tu peux toujours faire, c’est envoyer des modifs a @Alexandre. Il pourra, si c’est pertinent, les intégrer au plugin
Perso je ne suis pas équipé en thermorégulation MyHome, mais je veux bien essayer de donner un coup de main !
Est-ce que tu as déjà une idée des fonctionnalités principales qui pourraient être intégrées ?
Remontée de température de sonde déjà je suppose ?
(La documentation de la thermorégulation doit être la plus longue d’OpenWebNet je pense…)
ça m’intéresse! Je cale actuellement avec les problèmes ci-dessous, avec le plug-in officiel et des modules F401:
Le retour d’état des volets ne semble pas fonctionner du tout (les valeurs d’état retournées par status/statusnum sont fantaisistes!)
Commander plusieurs volets en parallèle dans un scénario… ne fonctionne pas à moins de démarrer les scénarios en parallèle et ne me semble pas toujours fonctionner à 100% - sauf à appeler les commandes individuellement hors scénario.
Apparemment,@anotherjulien, tu as corrigé ces soucis via tes modifs. Comment y accéder? @Poluket, je ne vois pas d’installation « beta » pour le plug-in SCS? (Je suis sous Jeedom 4.0.35 et plug-in MyHomeSCS 2019-11-14).
