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é
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 »