Not an issue as such, more just the approach that was taken when originally developing these drivers. I could wrong about the intent here (I didn't develop these originally), but this is at least my understanding, which I agree with as an approach. This is essentially a trade-off between the effort in development of the drivers and the effect this has in how a device is presented to the platform, and I can't see a way around this at the moment unfortunately (happy for any ideas). I'll do my best to try and explain....
There are two drivers that make up this particular EcoWitt integration in HE, a gateway driver and a sensor driver. In very simple terms, the gateway driver handles receiving the data from the gateway, setting up sensor devices in HE as required, and passing on data to the relevant sensor HE device. The sensor driver takes the different data points (readings) it receives in HE and assigns it to the correct attribute, such as temperature, humidity and so on.
Pulling back from this specific set of drivers, in the HE platform in general, a driver needs to define the capabilities of the device up front in the code, i.e. a device using this driver is a temperature device or an air quality device (or both). This is what drives device selections in the HE UI, but also tells HE (and other systems), what data and commands to expect when dealing with the device in situations like creating an automation or displaying the device on a dashboard.
Due to the varied and changing nature of products offered by EcoWitt and multi-sensor devices in particular, the sensor driver was developed to cover the breadth of capabilities offered by supported EcoWitt devices, those being:
capability "Battery";
capability "Temperature Measurement";
capability "Relative Humidity Measurement";
capability "Pressure Measurement";
capability "Ultraviolet Index";
capability "Illuminance Measurement";
capability "Water Sensor";
capability "Carbon Dioxide Measurement";
capability "Air Quality";
If you think about outdoor weather stations in particular, there can be a range of combinations of sensors available. On the flip side, temperature sensors in particular can exist in a range of EcoWitt devices. To develop a separate driver for each combination of capabilities available and managing the selection of the resulting drivers for the device would make the task a lot bigger in maintaining the code. Similarly, creating separate drivers for each capability listed above and creating HE devices for each sensor linked to an EcoWitt device would generate a mess of devices in HE, not to mention needing to maintain the matrix of capabilities supported by devices.
I can understand the effect this has in how a device is presented in HE and other platforms, but I just can't see a way around it.
