zigbee-herdsman icon indicating copy to clipboard operation
zigbee-herdsman copied to clipboard

PM2.5 invalid cluster definition

Open devbis opened this issue 2 years ago • 6 comments

This commit https://github.com/Koenkk/zigbee-herdsman/commit/c413c02ef4f7e8be9cd300da17cb9fb305f28f5a 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: { ... } 
    }
  1. 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},
        },
    }
  1. 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: https://github.com/Koenkk/zigbee-herdsman-converters/commit/d8c4f20d9c6e2774ce5277a58f0eb38e97ccae73

devbis avatar Dec 15 '23 08:12 devbis

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

Koenkk avatar Dec 15 '23 19:12 Koenkk

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 avatar Dec 15 '23 21:12 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

peterkappelt avatar Dec 15 '23 21:12 peterkappelt

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.

devbis avatar Dec 16 '23 12:12 devbis

#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 avatar Dec 17 '23 22:12 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.

sjorge avatar Dec 29 '23 20:12 sjorge

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

github-actions[bot] avatar Jun 27 '24 00:06 github-actions[bot]

Implemented in https://github.com/Koenkk/zigbee-herdsman/pull/1116

devbis avatar Aug 28 '24 16:08 devbis