Modules volets roulant X4VR Inversion

Je suis d’accord avec toi. Il n’a pas à interpréter le fonctionnement du module et je ne parle pas non plus de normaliser. Je vois Jeedom comme le point central de ma domotique et c’est par lui que je passe pour personnaliser le tout peu importe les équipements que je connecte.

Dans mon exemple, j’ai d’un coté Apple de l’autre GCE chacun a implémenté son concept de volet roulant. Jeedom me permet de faire communiquer les deux par l’intermédiaires des deux plugins (homebridge/IPX800V4) il ne doit pas interpréter mais me permettre de configurer/personnaliser les interactions. La possibilité d’inverser le pourcentage dans la commande même me semble être une option interessante. Exactement comme c’est fait pour les relais par exemple.

PS: dans mon post précédent j’avais mis deux fois le même screen shot. J’ai modifié pour que vous puissiez comprendre l’histoire du #slider#

Dans le relais l’inversion n’est que visuel sur le widget ca n’impact rien d’autre. La pour moi il faut ajouter l’inversion dans homebridge comme je l’ai fait pour google ou alexa

@Loic

puis-je te rappeler cette discussion : https://community.jeedom.com/t/plugin-gsh-manque-linversion-des-commandes-en-option-pour-rideaux/1673/5?u=nebz

ca doit être gérer dans le core, comme nous avions convenus, ce n’est pas à un plugin de gérer cela (comme pour un booléen).

Je m’en rappelle plus du tout mais ya plus rien de prévu la dessus c’est trop complexe a gérer je sais pas faire je laisse au plugin de gérer ces cas là mtn comme pour gsh et ash

Ça n’a pas de sens… pourquoi le core gérerait l’inversion des booléens et pas des numériques bornés ?

1 « J'aime »

Car j’ai pas le temps de le faire et que je voulais trouver la solution la plus rapide possible pour l’utilisateur.

Mais très bien c’est le core qui le fera je l’ajoute pour la 4.2 (minimum 24mois)

Et c’est loin d’être aussi que sur les binaire la faut aussi inverser la commande action donc faut la retrouver avant donc pas sûr d’y arriver.

Lol comme ça c’est clair. ^^

Je repose juste une question sur le plugin IPX800V4 à laquelle tu n’a pas répondu plus haut @Loic :

Quand je crée une commande pour mon IPX avec le template volet roulant, l’action générée possède un champ pré-rempli avec la valeur #slider#. A quoi sert ce champs ? (Si je change #slider# par 100-#slider# je crois que ça n’est pas interprété. C’est normal ?

Dans tous les cas, je posterais ma solution si je trouve une astuce pour patienter les 2 ans minimum.

Ben ça lui indique que la valeur est la valeur du champs slider du tableau passé en paramètre de l’exécution de la commande. Et non pas de calcul là dessus.

Finalement j’ai pu le faire en 4.1 faut encore que je teste mais ca devrait marcher. Par contre il y a un fort impact sur jeedom du a l’alignement pour les binaire aussi, globalement ca va demander de la reconfiguration (2h ce matin chez moi)

Finalement j’ai fait retour arriere c’est trop impactant meme en 1 journée j’ai pas reussi a remettre ma domotique en état.

Conclusion c’est au plugin de gerer ca le core ne le fera pas.

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

@Loic

je pense que tu as mal perçu la demande.

pour un binaire, le fait de cocher « invertBinary » n’inverse pas la valeur réellement mais indique que celle-ci est inversée.

donc pourquoi pas faire cela pour une action numérique ?

Car je sais pas comment faire techniquement si j’inverse juste pour le widget en quoi ça t’aide dans le plugin ? Tu auras pas la valeur inversé donc ça marchera pas

non mais je saurai qu’elle est inversée et donc pourrai faire le traitement.

exactement comme un binaire en fait… et idem pour les widgets

Je suis pas pour c’est pas une solution surtout que le widget a son propre paramètre invert justement pour ca

Ça serait plutôt l’option invettbinary qui devrait disparaître au profite d’une option sur le widget

Les widget ne sont qu’un moyen d’afficher une information… l’app mobile en est un autre, GSH en est un autre, Alexa en est un autre et Homebridge aussi…

donc en déplaçant ca dans le widget, tu obligerais les utilisateurs à cocher un paramètre central dans la partie l’affichage… (et dans chacun d’entre eux)

Oui ça me choque pas dans le sens où chaque service a ça prendre conception des choses

je dirais plutot que chaque plugin a sa propre conception des choses. et chaque service aussi. au milieu il y a jeedom qui peut apporter une norme.

c’est tout le principe des types génériques ,ils doivent avoir un comportement générique aussi ! donc il faut une norme… imagine une lampe avec un etat chaine « allumé » « éteint », comment GSH peut voir qu’il s’agit d’un binaire et que « allumé » = ON et « éteint » = OFF… il faut un minimum de normes…

Donc c’est bien la modification que j’ai voulu faire et c’est trop impactant pour que je le fasse ou même que jeedom sas l’accepte désolé

@Loic

une autre solution plus logique serait peut-être de faire deux types génériques…


'FLAP_STATE' => array('name' => __('Volet Etat d\'ouverture',__FILE__), 'family' => __('Volet',__FILE__), 'type' => 'Info'),
'FLAP_STATE_CLOSING' => array('name' => __('Volet Etat de fermeture',__FILE__), 'family' => __('Volet',__FILE__), 'type' => 'Info'),

ainsi on garde la logique qu’un type générique doit avoir un comportement générique également.

2 « J'aime »