@cicoub13 je me disais que ça aller être chiant à maintenir les devices z2m.
On pourrait pas gérer le mapping feature automatiquement ?
Ces informations étant disponibles sur le broker.
Non. J’avais déjà réfléchi à ça de deux manières :
- via le message contenant tous les devices MQTT topics and message structure | zigbee2mqtt.io => le champ
exposesdedefinitionpourrait nous être utile pour un mapping automatique, mais j’ai testé plein de fois avec des périphériques différents et je n’ai jamais ce champ
(exemple ici : Zigbee devices - Pastebin.com) - via le premier message du device MQTT topics and message structure | zigbee2mqtt.io => le souci, c’est qu’il ne contient pas assez d’information. Par exemple, un interrupteur et une ampoule enverront le même message
{"state": "ON"}
Si tu as une idée, je suis preneur 
Ah beh trouvé 
En ajoutant include_device_information: true dans la configuration du container zigbee2mqtt, on peut récupérer la liste des fonctionnalités exposées par chaque device et faire un mapping automatique.
Je ne sais pas si c’est mieux de contrôler la configuration des appareils qu’on a testés OU de faire un mapping automatique qui devra gérer beaucoup de cas.
{
"date_code" : "20191205",
"definition" : {
"description" : "Aqara temperature, humidity and pressure sensor",
"exposes" : [ {
"access" : 1,
"description" : "Remaining battery in %",
"name" : "battery",
"property" : "battery",
"type" : "numeric",
"unit" : "%",
"value_max" : 100,
"value_min" : 0
}, {
"access" : 1,
"description" : "Measured temperature value",
"name" : "temperature",
"property" : "temperature",
"type" : "numeric",
"unit" : "°C"
}, {
"access" : 1,
"description" : "Measured relative humidity",
"name" : "humidity",
"property" : "humidity",
"type" : "numeric",
"unit" : "%"
}, {
"access" : 1,
"description" : "The measured atmospheric pressure",
"name" : "pressure",
"property" : "pressure",
"type" : "numeric",
"unit" : "hPa"
}, {
"access" : 1,
"description" : "Voltage of the battery in millivolts",
"name" : "voltage",
"property" : "voltage",
"type" : "numeric",
"unit" : "mV"
}, {
"access" : 1,
"description" : "Link quality (signal strength)",
"name" : "linkquality",
"property" : "linkquality",
"type" : "numeric",
"unit" : "lqi",
"value_max" : 255,
"value_min" : 0
} ],
"model" : "WSDCGQ11LM",
"supports_ota" : false,
"vendor" : "Xiaomi"
}
Y’a du taf pour faire un smart mapping mais une fois que c’est fait on a aussi une compatibilité future.
Les sensors en soit c’est facile à faire, les switchs c’est une autre histoire.
HA ils font comme ça mais ils ont un avantage, tout est au format mqtt HA.
Cette option fait partie de ma conf ( avec l’horodatage aussi) donc j’avais pas tilté. Je pensais que c’était exposé par défaut.
La détection automatique des features exposées ça serait vraiment l’idéal pour s’assurer que tous les périphériques sont supportés par défaut.
Mais on peu garder le meilleur des deux mondes :
- Si un fichier modèle existe, celui-ci est utilisé
- Sinon on détecte automatiquement (et on l’affiche dans l’UI ?) les features
Comme ça tous les nouveaux périphériques sont supportés, mais on peut gérer les cas particulier en forçant une certaine configuration.
Pour info, Gladys v4.2.2 est en cours de build avec les fix de @VonOx et @cicoub13 !
Build en cours ici:
https://github.com/GladysAssistant/Gladys/actions/runs/726223336
3 « J'aime »
Gladys v4.2.2 est bien live avec les changements 
Dites moi si c’est bon avant que je communique dessus
Est ce que quelqu’un peut vérifier rapidement le z2m, impossible d’accèder au discover en 4.2.2
FF:
edge:
Même erreur pour moi
preact-i18n a été mis à jour de 2.0.X à 2.3.X et dans une version, ils ont touché au context Release 2.1.1-preactx · synacor/preact-i18n · GitHub
Je peux regarder ce soir pour corriger
Est-ce dans cette build que mon ampoule est sensée redevenir une ampoule ? (et pas un interrupteur)
Là j’ai supprimé mon device,rre-aajouté, mais rien de neuf.
Dois-je refaire la manip complète ? C’est à dire avec extinction/allumage de l’ampoule 5 fois?
T’es pas en 4.2.2 puisque l’onglet discover n’est plus accessible (c’est pété)
Non pas besoin de refaire L’appairage.
T’en veux du boulet ?
2 « J'aime »
Ça touche aussi :
- la sélection de devices dans la box du dashboard
- le calendar
- l’édition de scènes
- les service bluetooth, mqtt, zigbee2mqtt
- la recherche dans Intégrations
@pierre-gilles Je pense que le mieux est de rollback ces 2 PR puis de prendre un peu plus de temps pour analyser (notre usage de this.context.intl est un hack à mon avis 
)
https://github.com/GladysAssistant/Gladys/pull/1128
https://github.com/GladysAssistant/Gladys/pull/1126
Eh beh il a tout péter Rob 
C’est la que l’on se rend compte qu’il n’y a aucun test sur le front.
“This is fine”
On l’aurais vu avec Cypress
Clairement oui, à partir du moment où les tests sont faits.
Mais ce problème je l’ai sur la migration preact (pour tester le coverage cypress).
ça vient de cette PR uniquement
La seconde n’est pas impactée.
1 « J'aime »
Ah mince !! Je pensais avoir tout testé pourtant j’ai du oublier un select
My bad !