PM2.5 invalid cluster definition

[devbis]

This commit c413c02 actually creates an incorrect definition contrary to ZCL. (4.13.1.3 and 4.13.2.1 for attributes description).

All Concentration Measurement attributes should be of type "single precision".

I'm asking about a possible solution for this case. I don't know if attributes for devices with uints have manufacturerCodes and what are they.
Options I'm thinking about:

1. Two clusters definitions with the same ID

    pm25Measurement: {
        ID: 0x042a,
        attributes: { ... }
        
    },
    
    pm25MeasurementUint16: {
        ID: 0x042a,
        attributes: { ... } 
    }

2. One cluster with duplicate IDs for attributes:

    pm25Measurement: {
        ID: 0x042a,
        attributes: {
            measuredValue: {ID: 0x0000, type: DataType.singlePrec},
            measuredMinValue: {ID: 0x0001, type: DataType.singlePrec},
            measuredMaxValue: {ID: 0x0002, type: DataType.singlePrec},
            measuredTolerance: {ID: 0x0003, type: DataType.singlePrec},
            // heiman, aqara, xiaomi: values reported as uint16 contrary to standard
            measuredValueUint16: {ID: 0x0000, type: DataType.uint16},
            measuredMinValueUint16: {ID: 0x0001, type: DataType.uint16},
            measuredMaxValueUint16: {ID: 0x0002, type: DataType.uint16},
            measuredToleranceUint16: {ID: 0x0003, type: DataType.uint16},
        },
    }

3. Manual configuring for devices with not standard value types and leave just zcl-compliant attributes in zcl file.

What is the best way to handle it?

Corresponding breaking changes in converters: Koenkk/zigbee-herdsman-converters@d8c4f20

[Koenkk]

@peterkappelt can you try this change and see if it breaks your device?

[peterkappelt]

I don't really think that my commit causes this inconsistency with the spec to be honest.

What I did was only:

• renaming heimanSpecific cluster to more general PM25 cluster name (keeping the existing wrong specification of the measuredValue attribute)
• add the measuredValueIkea attribute which uses the correct single precision type. I opted to add an own attribute with the correct type (rather than modifying measuredValue to the correct type) since I wasn't sure whether the existing devices that used this cluster relied on measuredValue having a wrong type (or not)

My commit didn't touch the existing spec of the measuredValue type, so the right question to ask is rather if all of the devices that use this cluster (except for the IKEA air quality thing) work with singlePrecision type

[peterkappelt]

What would maybe the cleanest way to get around this:

• Rename measuredValue to measuredValueLegacyHeimann and change it for all the existing devices
• Rename measuredValueIkea to measuredValue and remove the manufacturer code. Modify the IKEA device to use measuredValue

This way, all future devices can correctly use the measuredValue attribute with the correct type, while the legacy devices can still use the measuredValueLegacyHeimann attribute with the wrong type

[devbis]

One of the possible problems is that ZCL attributes should be without manufacturer's code, while Heiman/Aqara should contain a manufacturer's code, which i don't know.

Otherwise, i don't understand how z2m would distinguish the same attributes with different types.

[sjorge]

#789 tagging this issue as they are somewhat related, ideally we need a way to have duplicate cluster definitions but linked to specific devices.

[sjorge]

One of the possible problems is that ZCL attributes should be without manufacturer's code, while Heiman/Aqara should contain a manufacturer's code, which i don't know.

Otherwise, i don't understand how z2m would distinguish the same attributes with different types.

If one of them sends a manufactuereCode in the message that would indeed work. But I think the vindsturka at least does not send one.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days