@cicoub13 I was thinking it would be tedious to maintain the z2m devices.
Couldn’t we automatically manage the mapping feature?
This information is available on the broker.
No. I had already considered this in two ways:
- via the message containing all devices https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttbridgedevices → the
exposesfield ofdefinitioncould be useful for automatic mapping, but I tested it many times with different devices and I never have this field
(example here: https://pastebin.com/CVAEpg0K) - via the first message of the device https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttfriendly_name → the problem is that it does not contain enough information. For example, a switch and a bulb will send the same message
{"state": "ON"}
If you have any ideas, I’m interested 
Oh I found it 
By adding include_device_information: true in the zigbee2mqtt container configuration, you can retrieve the list of features exposed by each device and perform automatic mapping.
I don’t know if it’s better to control the configuration of the devices we have tested OR to perform automatic mapping that will have to handle many cases.
{
"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"
}
}
There’s work to do for smart mapping, but once it’s done, we also have future compatibility.
Sensors themselves are easy to make, but switches are another story.
HA does it this way, but they have an advantage: everything is in MQTT HA format.
This option is part of my config (with the timestamp too), so I didn’t realize. I thought it was exposed by default.
Automatic detection of exposed features would be ideal to ensure all devices are supported by default.
But we can keep the best of both worlds:
- If a template file exists, it is used
- Otherwise, we automatically detect (and display in the UI?) the features
This way, all new devices are supported, but we can manage special cases by forcing a certain configuration.
For information, Gladys v4.2.2 is currently being built with the fixes from @VonOx and @cicoub13!
Build in progress here:
https://github.com/GladysAssistant/Gladys/actions/runs/726223336
Gladys v4.2.2 is now live with the changes 
Let me know if it’s good before I communicate about it
Same error for me
@pierre-gilles Wouldn’t it be the react select that was merged?
preact-i18n has been updated from 2.0.X to 2.3.X and in one version, they touched the context Release 2.1.1-preactx · synacor/preact-i18n · GitHub
I can take a look tonight to fix it
Would we have seen that with Cypress @AlexTrovato?
Too bad for the new devices 
Is this the build where my bulb is supposed to become a bulb again? (And not a switch)
Right now I deleted my device, re-added it, but nothing new.
Do I need to perform the full procedure again? That is, turning the bulb off and on five times?
You’re not on 4.2.2 because the discover tab is no longer accessible (it’s broken)
No, you don’t need to redo the pairing.
This also affects:
- device selection in the dashboard box
- the calendar
- scene editing
- bluetooth, mqtt, zigbee2mqtt services
- search in Integrations
@pierre-gilles I think the best is to rollback these 2 PRs and take more time to analyze (our use of this.context.intl is a hack in my opinion 
)
https://github.com/GladysAssistant/Gladys/pull/1128
https://github.com/GladysAssistant/Gladys/pull/1126
“This is fine”
We would have seen this with Cypress
Clearly yes, as soon as the tests are done.
But I have this problem with the preact migration (to test the Cypress coverage).
This comes only from this PR
https://github.com/GladysAssistant/Gladys/pull/1128/files
The second one is not impacted.
Oh crap!! I thought I had tested everything after all I must have forgotten a select
My bad!