J’ai pu lire ce sujet ( lien ci-dessous) ( et d’autres du même type ) qui correspond exactement à la même situation que la mienne mais pas vraiment de contournements possible ni de solution immédiate à part attendre 1 an et demi la 4.2 ?!.
Malheureusement, le sujet est cloturé avec une solution en 4.2 annoncé dans 1 an et demi sans vraiment de contournements possible ? ( et encore cela n’a pas l’air certain ? )
Est ce bien la conclusion que je dois tirer ? Je vais finir par en perdre mon propre latin à devoir inverser le mot ouvrir et fermer quand je discute avec siri pendant si longtemps ;D
Je n’ai pas encore bien réfléchi au sujet mais les virtuels pourraient il aider en recalculant à l’envers l’état et les actions des volets ?
Oui solution est sensé arriver par le core, ou pas… de mon côté je vois pas trop quoi faire non plus… soit prendre du temps et faire la solution de mon côté (comme d’habitude) mais bon si c’est après pour que le core sorte qqch sans prendre en compte ce que j’ai fait et devoir encore tout refaire pour s’adapter car on a pas été consulté je sais pas… ça motive pas…
Mais bon comme d’hab c’est ce que je vais faire… donner un contournement pour que les utilisateurs puissent faire ce dont ils ont besoin… mais bon… on verra quand …
Bonjour,
Malheureusement nos tests en poc pour integrer cela dans le core n’ont pas été concluant (il aurait fallu que tous les utilisateurs de jeedom reconfigure toute leur commande et widget, meme moi j’ai pas reussi en 3 semaines). Cela a donc était abandonné et il faut gerer ca au niveau du plugin (comme pour gsh, ash…)
en fait il faudrait faire comme pour le binaire… la valeur n’est pas réellement inversée, ce n’est que une indication qui dit qu’elle est inversée par rapport à la norme…
l’autre solution que je t’avais proposée est deux types génériques :
ce qui est à mon sens plus logique encore puisque lié directement à un type d’équipement.
(il faut aussi le type générique sur l’action qui coincide forcément : FLAP_SLIDER et FLAP_SLIDER_CLOSING, les FLAP_UP et FLAP_DOWN sont aussi mal només en soit, car ca empèche la gestion de stores à lamelles qui sont left/right mais surtout pour être plus générique FLAP_OPEN FLAP_CLOSE serait encore mieux…(avec une back compat))
ce qui m’ennuie ici c’est que je pourrais mettre ça en place de mon coté mais comme avec LIGHT_BRIGHTNESS je ne suis pas sur d’etre mis au courant ou consulté en cas de modification ou ajout d’un type dans le core… (et qui dans ce cas précis n’est pas logique, car il change la fonction de LIGHT_STATE sans migrer l’existant !)
oui c’est l’action qui posait problème car non inversable… en effet tu rêgles le problème pour le dashboard et c’est une très bonne idée ! mais il reste les scénarios ou il faut penser que la valeur est inversée aussi…
Oui tout à fait, mais en scenario, j’en ai très peut sous JEEDOM pour mes volets.
L’ouverture est la fermeture son gérer par l’IPX, pas soucis en cas de problème de JEEDOM.
De mon côté, n’utilisant pas vraiment l’interface de l’IPX, j’ai finalement tout simplement inverser les fils de la montée et de la descente directement sur l’IPX des volets.
Donc, j’ai maintenant dans le bon sens mes volets à l’endroit ou j’utilise ma domotique, c’est à dire dans jeedom et homekit mais plus sur l’IPX
Dome, effectivement, je n’aurai pas pensé à cela. Je pense que j’aurai un peu peur de ne plus savoir maintenir tout cela avec le temps qui passe mais cela permettra surement à certains de se débloquer immédiatement mais merci quand même.
Dans tous les cas, il n’existe visiblement pas encore de solution idéale ( propre et maintenable dans le temps ), donc le sujet mérite d’être suivi pour les prochains