Pour moi c’est codé
Pas testé de mon côté
Il ne faut pas mettre une valeur numérique ?
Ca serait bien de renseigner cette info quelque part lorsqu’un device est gérer par Gladys. Airtable ou direct Gladys.
Airtable c’est deja dedans (meme avec une fonctionnalité en moins) 
tu peux tester et faire un retour 
Je me suis mal exprimé.
Je voulais dire qu’il faudrait mentionner quelque part:
1 appui court = 1
2 appui court = 2
? appui long = ?
je confirme pas de retour appui long sur Gladys , mais dans dasboard z2Mqtt OK
bonjour @VonOx
Pour l’appui long on a pas la conversion « appui long » en un chiffre (5 par exemple pour être en concordance avec Xiaomi)
comme l’écrit @Tlse-vins
1 appui court = 1
2 appui court = 2
? appui long = ?
Ce sont les mêmes constantes justement pour uniformiser côté Gladys
const BUTTON_STATUS = {
CLICK: 1,
DOUBLE_CLICK: 2,
LONG_CLICK_PRESS: 3,
LONG_CLICK_RELEASE: 4,
LONG_CLICK: 5,
};
Super
Mais pour le Sonoff en position long clic ça ne fonctionne pas. Pour les boutons Xiaomi, ça fonctionne
Ok le sonoff renvoi « long », je sais pas comment gérer ça avec les switch case ( cc @AlexTrovato @pierre-gilles)
Ce que j’ai toujours dis c’est que ces valeurs ne devraient jamais être présenté à l’utilisateur, c’est pas la philosophie de cette v4 !
Au lieu de devoir écrire manuellement 1, 2, 3 ou 4, l’utilisateur devrait juste voir un sélecteur dans les scènes, un peu comme ça :
(c’est pas codé, juste un mockup)
Comme ça personne ne doit se rappeler de ces constantes qui sont juste de la tambouille interne 
Je suis preneur d’une PR sur le sujet
A vu d’oeil je pense que c’est le readValue que tu dois modifier:
Je laisse @AlexTrovato confirmer.
Je suis d’accord, avec toi, si tous les clic sont codés pas besoin de connaitre les valeurs.
1 « J'aime »
Ok pour le readValue pas de problème, du coup dans le cas des boutons comme ça le writeValue ne sert jamais ?
J’essaie de comprendre 
.
Je ne suis pas l’auteur du code donc je saurais pas dire, mais je pense effectivement que dans le cas d’un capteur qui n’est jamais contrôlé, seul le readValue est utile
1 « J'aime »
+1
Ça m’intéresse de creuser le sujet, la logique ça serai quoi? Juste un affichage côté front ou quelques chose de plus poussé côté backend ?
J’ai aussi le cas sur le lixee tic, il renvoi la tarification en cours ( valeur texte HP HC etc…) donc des choses intéressantes à exploiter dans les scènes.
Ça vaut le coup de dédier un sujet
C’est juste de l’affichage oui ! Après rien de nouveau, on le fait déjà pour pas mal de types :
Binaire:
Appareil de présence:
Capteur avec unité:
L’idée, c’est qu’on affiche jamais des valeurs qui sont de notre tambouille interne dans l’UI, on affiche toujours un beau component, traduit, et clair à utiliser.
Il manque juste un component pour les boutons pressions type Xiaomi.
Après, ce qu’il faut s’assurer, c’est que seul ce bouton est classifié comme tel, il faut savoir sur quoi faire la distinction dans l’UI.
2 « J'aime »
Dans un 1er temps une PR pour gérer le bouton
1 « J'aime »
@VonOx ta PR casse la compatibilité ascendante sur le LONG_CLICK qui passe de 5 à 6
L’ancien long est devenu hold donc non ( la valeur hold z2m était mapper sur long donc ça faisait pas sens ) => Du coup ça me semblait logique
J’inverse quand même ?
Pas de souci pour le nom de la variable (ça c’est notre code en interne), par contre la valeur numérique doit rester le même ad vitam (sauf si on code une migration).
Si quelqu’un avait fait une scène en rentrant manuellement 5 parce qu’il avait remarqué que 5 ça marchait, sa scène devient cassée avec cette PR, et ça il faut à tout prix l’éviter !
Il faut juste que le comportement du 5 reste le même
Avant ma Pr
Z2m envoi « hold » => Gladys LONG_CLICK => 5
Ma PR:
Z2m envoi « hold » => Gladys HOLD_CLICK => 5
Z2m envoi « long » => Gladys LONG_CLICK => 6
En fait je vois pas bien ce que ça casse du coup puisque
Le mapping hold = 5 est toujours le même
2 « J'aime »