temperatureMeasurement capability and new temperatureRange attribute

Mariano_Colmenarejo · October 14, 2024, 6:27pm

I’m curious to know how the addition of the temperatureRange attribute (MinMeasuredValue and MaxMeasuredValue attributes) will affect the temperatureMeasurement capability, I can’t find any information in the documentation and I see a lot of code changes in the stock drivers code and 54.x libraries.

I see that this attribute has been added to the temperatureMeasurement capability and in its presentation it is now used as temperature supportedValues .
What is it and how will this supportedValues field limit the temperature values? nothing is explained in the documentation, capability presentation section.

temperatureMeasurement Presentation

{
    "dashboard": {
        "states": [
            {
                "label": "{{temperature.value}} {{temperature.unit}}",
                "alternatives": [
                    {
                        "key": "C",
                        "value": "°C",
                        "type": "active"
                    },
                    {
                        "key": "K",
                        "value": "°K",
                        "type": "active"
                    },
                    {
                        "key": "F",
                        "value": "°F",
                        "type": "active"
                    }
                ]
            }
        ],
        "actions": [],
        "panelItems": []
    },
    "detailView": [
        {
            "label": "{{i18n.label}}",
            "displayType": "slider",
            "slider": {
                "range": [
                    -20,
                    50
                ],
                "unit": "temperature.unit",
                "supportedValues": "temperatureRange.value",
                "value": "temperature.value",
                "valueType": "number"
            }
        }
    ],
    "automation": {
        "conditions": [
            {
                "label": "{{i18n.label}}",
                "displayType": "numberField",
                "numberField": {
                    "value": "temperature.value",
                    "valueType": "number",
                    "unit": "temperature.unit",
                    "range": [
                        -20,
                        50
                    ],
                    "supportedValues": "temperatureRange.value"
                }
            }
        ],
        "actions": []
    },
    "id": "temperatureMeasurement",
    "version": 1
}

According to the zigbee 3.0 cluster libarary specification, MinMeasuredValue and MaxMeasuredValue attributes are used in all measurement clusters and determine the range of values between which the device operates, in this case minimum and maximum temperature range.

Although they are mandatory attributes, they are allowed to not have a minimum and maximum value defined and those attributes will have a value of 0x8000.

My doubt about how this will affect users comes from:

There is a PR that has modified 38 files of different stock drivers, which have temperature measurement, to add the handling of these attributes to emit them in the temperatureMeasurement capability, temperatureRange attribute, as an object type, which includes the MinMeasuredValue and MaxMeasuredValue values.
In the 54.x libraries, the handling of the temperatureRange attribute has been added to the temperatureMeasurement defaults library This makes most of the changes in the stock drivers of the previous PR unnecessary, since it will be handled by default now, in fact you can see that attribute emitted by default on the advanced users page.
the presentation of temperatureMeasurement has a range of -20º to 50º. Is this range going to be replaced by the “supportedValues” range of the temperatureRange attribute when there are valid values or with what criteria will they be applied?

I say all this because in the devices I have installed I see a very different behavior of these MinMeasuredValue and MaxMeasuredValue attributes and I am worried about how this will affect when it works, maybe in the next app update?

For example, the Aeotec (smartthings, samjin) multipurpose and motion sensors do not comply with the zigbee specification since they emit a value = 0 for MinMeasuredValue and MaxMeasuredValue, which prevents those values from being emitted in the temperatureRange attribute since one condition is that MinMeasuredValue must always be less than MaxMeasuredValue.

2024-10-14T18:09:28.997582978Z INFO Zigbee Contact Mc <ZigbeeDevice: d5c46aef-8f26-4442-a671-2f36f00e42e5 [0xD599] (Puerta Casa)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0xD599, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: TemperatureMeasurement >, lqi: 0xD8, rssi: -74, body_length: 0x0009, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x3B, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0002, ZclStatus: SUCCESS, DataType: Int16, MaxMeasuredValue: 0 > > > >
2024-10-14T18:09:29.103696603Z DEBUG Zigbee Contact Mc Puerta Casa device thread event handled
2024-10-14T18:09:29.233272270Z TRACE Zigbee Contact Mc Received event with handler zigbee
2024-10-14T18:09:29.241767562Z INFO Zigbee Contact Mc <ZigbeeDevice: d5c46aef-8f26-4442-a671-2f36f00e42e5 [0xD599] (Puerta Casa)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0xD599, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: TemperatureMeasurement >, lqi: 0xD8, rssi: -74, body_length: 0x0009, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x3C, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0001, ZclStatus: SUCCESS, DataType: Int16, MinMeasuredValue: 0 > > > >

There are Tuya TS0201 sensors, widely used in the community, which store in these attributes the minimum and maximum values that the sensor has been measuring during its operation.
This also does not meet the specification, but it does meet the condition for the temperatureRange attribute to be emitted with values that have nothing to do with the device’s operating limits.
Could this restrict device operation?

image3975×309 32.6 KB

image3967×293 31.7 KB

EDIT: I have another device a sonoff SNZB02 (manufacturer: eWeLink, model :TH01), and It seems that this one does comply with the Zigbee 3.0 specification and has a defined operating range between -10ºC and 50ºC

2024-10-14T19:16:53.275667619Z INFO Zigbee Temp Sensor with Thermostat Mc <ZigbeeDevice: 18f2c16e-ab66-4e51-be10-77c261ffd14e [0x103C] (Temp Humid Cocina)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x103C, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: TemperatureMeasurement >, lqi: 0xD2, rssi: -67, body_length: 0x0009, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x0A, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0002, ZclStatus: SUCCESS, DataType: Uint16, MaxMeasuredValue: 5000 > > > >
2024-10-14T19:16:53.444419286Z DEBUG Zigbee Temp Sensor with Thermostat Mc Temp Humid Cocina device thread event handled
2024-10-14T19:16:53.817998411Z TRACE Zigbee Temp Sensor with Thermostat Mc Received event with handler zigbee
2024-10-14T19:16:53.857533536Z INFO Zigbee Temp Sensor with Thermostat Mc <ZigbeeDevice: 18f2c16e-ab66-4e51-be10-77c261ffd14e [0x103C] (Temp Humid Cocina)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x103C, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: TemperatureMeasurement >, lqi: 0xD4, rssi: -68, body_length: 0x0009, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x0B, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0001, ZclStatus: SUCCESS, DataType: Int16, MinMeasuredValue: -1000 > > > >

I don’t have any other models of temperature measuring devices, but there are many more models in the drivers with possible non-standard operations.
Will this have any consequences on future operation?

I wouldn’t understand so much code change for nothing and perhaps it would be good to know how this is going to be implemented.

Maybe I’m putting the bandage on before I have the wound, but I want to try to be clear about what I can do so that these automatic temperature ranges, which I understand are intended to be applied at some point, do not affect me negatively.

Maybe you could get some information about from the team for us?
Thanks

nayelyz · October 14, 2024, 6:49pm

Hi, @Mariano_Colmenarejo
Thanks for reaching out. Please, allow us some time to review your questions and comments, I already shared this post with the engineering team. Once we have more information, we’ll let you know.

milandjurovic71 · October 15, 2024, 11:36am

@Mariano_Colmenarejo I think that Range is meant for Routines. I have already used that in one of my routines. It is like precondition but is not. I have it setup as IF Range is between 60 and 72, and night switch turns on, THEN set temperature to 73. It will set temperature if it’s at that range at that time when switch is turned on or if is on already.

It works differently than Equal or Below, which check temperature
• If reached Equal temperature, or
• if is equal or below at specific time/event

Range is monitoring temperature changes regardless of event change or state. Tested.

Mariano_Colmenarejo · October 15, 2024, 1:10pm

Hi @milandjurovic71

That’s another thing.

Your example is a comparisons for routine conditions and in Android they are called maximum and minimum intervals, where you can write values within the range that you have defined in the capability presentation or in the device presentation.

Now the range between which you can enter values is -20ºC and 50ºC, but in the capability presentation they have introduced a “supportedValues” field that has the value of the range of the new temperatureRange attribute.

    "detailView": [
        {
            "label": "{{i18n.label}}",
            "displayType": "slider",
            "slider": {
                "range": [
                    -20,
                    50
                ],
                "unit": "temperature.unit",
                "supportedValues": "temperatureRange.value",
                "value": "temperature.value",
                "valueType": "number"
            }
        }
    ],
    "automation": {
        "conditions": [
            {
                "label": "{{i18n.label}}",
                "displayType": "numberField",
                "numberField": {
                    "value": "temperature.value",
                    "valueType": "number",
                    "unit": "temperature.unit",
                    "range": [
                        -20,
                        50
                    ],
                    "supportedValues": "temperatureRange.value"
                }
            }
        ],
        "actions": []
    },
    "id": "temperatureMeasurement",
    "version": 1

The question is how will that “supportedValues” field work:

Does it replace the value range -20 to 50 when there is a valid value for the temperatureRange attribute?
Will the one with the highest range or the one with the lowest range be chosen?

Matter drivers are also already using it for temperature, but it is also being used for colorTemperatureRange in Matter bulbs. It is exactly the same as for temperature

mocelet · October 15, 2024, 1:27pm

In that example it’s different, that’s just a safeguard with constants to detect “impossible values” -less than 1000K and more than 15000K-, it’s not the reported range of the device (used for the temperature picker in the details view) or the one in the profile (used for automations).

milandjurovic71 · October 15, 2024, 1:42pm

It is definitely for automations only. I have tried it with virtual thermometer, changing temperature values within and out of range, and it works well, with or without other conditions or events.

Mariano_Colmenarejo · October 15, 2024, 1:51pm

Hi @mocelet

I think that’s how I’m telling you.

These minimum and maximum color temperature values are what the Matter device reports as its operating limits. Exactly the same as those that exist in Zigbee.

They are set in the matter switch driver and emitted to the colorTemperatreRange attribute in these matter switch driver functions, if they meet the conditions of not being null and the minimum value received being less than the maximum received.

These values are then combined to limit the operation of the bulb within that range.

local mired_bounds_handler_factory = function(minOrMax)
  return function(driver, device, ib, response)
    if ib.data.value == nil then
      return
    end
    if (ib.data.value < COLOR_TEMPERATURE_MIRED_MIN or ib.data.value > COLOR_TEMPERATURE_MIRED_MAX) then
      device.log.warn_with({hub_logs = true}, string.format("Device reported a color temperature %d mired outside of sane range of %.2f-%.2f", ib.data.value, COLOR_TEMPERATURE_MIRED_MIN, COLOR_TEMPERATURE_MIRED_MAX))
      return
    end
    local temp_in_kelvin = mired_to_kelvin(ib.data.value, minOrMax)
    set_field_for_endpoint(device, COLOR_TEMP_BOUND_RECEIVED..minOrMax, ib.endpoint_id, temp_in_kelvin)
    local min = get_field_for_endpoint(device, COLOR_TEMP_BOUND_RECEIVED..COLOR_TEMP_MIN, ib.endpoint_id)
    local max = get_field_for_endpoint(device, COLOR_TEMP_BOUND_RECEIVED..COLOR_TEMP_MAX, ib.endpoint_id)
    if min ~= nil and max ~= nil then
      if min < max then
        device:emit_event_for_endpoint(ib.endpoint_id, capabilities.colorTemperature.colorTemperatureRange({ value = {minimum = min, maximum = max} }))
      else
        device.log.warn_with({hub_logs = true}, string.format("Device reported a min color temperature %d K that is not lower than the reported max color temperature %d K", min, max))
      end
      set_field_for_endpoint(device, COLOR_TEMP_BOUND_RECEIVED..COLOR_TEMP_MAX, ib.endpoint_id, nil)
      set_field_for_endpoint(device, COLOR_TEMP_BOUND_RECEIVED..COLOR_TEMP_MIN, ib.endpoint_id, nil)
    end
  end
end

 matter_handlers = {
    attr = {
      [clusters.OnOff.ID] = {
        [clusters.OnOff.attributes.OnOff.ID] = on_off_attr_handler,
      },
      [clusters.LevelControl.ID] = {
        [clusters.LevelControl.attributes.CurrentLevel.ID] = level_attr_handler,
        [clusters.LevelControl.attributes.MaxLevel.ID] = level_bounds_handler_factory(LEVEL_MAX),
        [clusters.LevelControl.attributes.MinLevel.ID] = level_bounds_handler_factory(LEVEL_MIN),
      },
      [clusters.ColorControl.ID] = {
        [clusters.ColorControl.attributes.CurrentHue.ID] = hue_attr_handler,
        [clusters.ColorControl.attributes.CurrentSaturation.ID] = sat_attr_handler,
        [clusters.ColorControl.attributes.ColorTemperatureMireds.ID] = temp_attr_handler,
        [clusters.ColorControl.attributes.CurrentX.ID] = x_attr_handler,
        [clusters.ColorControl.attributes.CurrentY.ID] = y_attr_handler,
        [clusters.ColorControl.attributes.ColorCapabilities.ID] = color_cap_attr_handler,
        [clusters.ColorControl.attributes.ColorTempPhysicalMaxMireds.ID] = mired_bounds_handler_factory(COLOR_TEMP_MIN), -- max mireds = min kelvin
        [clusters.ColorControl.attributes.ColorTempPhysicalMinMireds.ID] = mired_bounds_handler_factory(COLOR_TEMP_MAX), -- min mireds = max kelvin
      },

Mariano_Colmenarejo · October 15, 2024, 2:00pm

Ranges are used both in automations and in the detail view. In the capabilities presentations, all the fields must be defined.

If the value to be shown in the detail view has a value outside the defined limits, it will not be shown in the detail view and you will not be able to perform automations with values outside the range defined in the presentation, now -20ºc and 50ºc, the app will prevent you from doing so

Are you sure that these changes are already in operation?

They have just introduced it in the 54.x libraries and not all users have it in their hub and I think that it will be implemented with future updates of the App, that is why I ask how it will be implemented in case it affects the drivers already in use and changes have to be made

mocelet · October 15, 2024, 2:00pm

That’s another range There are three different ranges at play on the Matter switch driver:

The color temperature range written in the profile, for instance 2200K to 6500K.
A hardcoded sane temperature range to discard wrong values due to buggy implementations (1000K to 15000K).
The color temperature range reported by the device (called temperature bound in the driver).

The driver does not discard values reported outside the range reported by the device.

It uses the reported range just so the manual temperature picker has the correct range and avoid having to copy-paste the profile multiple times changing the temperatures for different brands/devices.

The values in the profile are still used in one place, when creating automations and picking a temperature.

Mariano_Colmenarejo · October 15, 2024, 2:23pm

You are right in this, value events are not limited by device limits

Until when or how will the values defined in the profiles be used?

I think they are trying to do is automate the profile limits with a dynamic field in the capability presentation, which will be updated and customized with the limit values defined in the device itself, when there are any, because they are not mandatory

Initially, a VID had to be created to overwrite the range values of the capability presentation.
Then, range configuration values began to be used in the profile that overwrite the capability presentation and the VIDs.

Otherwise, why would they make so many changes in capabilities and handler code, so that they are not used for anything?

mocelet · October 15, 2024, 2:42pm

Yes, that’s the idea, SmartThings has always relied on static profiles with fingerprints for each certified device but that just doesn’t make sense anymore, especially with Matter (discussed the topic a bit here).

The reported range already overrides the one in the profile for the details view. Why they don’t use those values when building routines, no idea. Eventually, the ranges in the profile will not be needed, after all they’re overridden.

Ultimately, the final step would be dynamic profiles, being able to add or remove capabilities from the driver according to what the device supports.

Mariano_Colmenarejo · October 15, 2024, 3:24pm

These are the things that should be explained or documented before implementing it.

I don’t know the real cases in Matter, but in zigbee each manufacturer is implementing the maximum and minimum values in different ways and it is not mandatory to set those temperature range values.

So it would be necessary to know if the dynamic range will be set whenever there is a valid device read range and in which fields, detail view and/or automations it is applied.

This could create problems or not in some devices

mocelet · October 15, 2024, 3:49pm

In Matter at least they have a check in place to see if the values seem right. It checks if there is a min and a max reported, if the range belongs to the “sane” range (1000K-15000K) and if the minimum is indeed less than the maximum. Only if everything seems right they emit the range.

But they really have to extend the use of the reported range to routines, there are certified lights with wrong profile values that would be fixed. For instance, Nanoleaf Matter lights have a fingerprint that uses a profile that starts in 2700K, but they actually can go down to 2100K. In the detail view you can pick 2100K because the reported values override the profile, but you can’t create a scene with 2100K because the minimum you can pick there is 2700K.

Funny example that sometimes individual device fingerprints are worse than just relying on generic profiles.

Mariano_Colmenarejo · October 15, 2024, 3:56pm

In the Zigbee code this is also taken into account before emitting the temperatureRange.

The problem is that there are devices that send values that meet the requirements to emit the temperatureRange event, but are not their real operating limits.

mocelet · October 15, 2024, 4:01pm

Could be seen as a good opportunity for vendors to fix their protocol compliance. Maybe for Zigbee it’s late since it’s already a jungle with all those ecosystems and custom flavours and they probably don’t care about SmartThings integration if it’s not WWST certified.

However, in Matter the more compliance issues are exposed, and the sooner, the better so users can ask for a fix or even return the device and get another brand.

Mariano_Colmenarejo · October 15, 2024, 4:18pm

Well, I don’t know what to tell you, the smartthings devices themselves, now Aeotec, do not comply with them in this specific case.

Mariano_Colmenarejo · November 3, 2024, 10:56am

Hi,

With the new version of the App 1.8.21.28, the automatic temperature ranges read from the device during installation are now applied.
They are applied to the details view and automation conditions of all devices that have the temperature capability.

They are applied according to the data attributes read during installation (added lifecycle):

If the device does NOT have valid defined values, then the default ranges are applied, -20ºc to 50ºc.
If device has valid values, those supported min and max values are applied.

The problem with some TUYA, TS0201, devices is that it stores the reported temperature values in those attributes and sets them as maximum and minimum supported, and they are not deleted when the device is uninstalled and reset.

During a first installation, the values sent by the device may not be valid and the default limits may apply.

If the device is reinstalled at some point then those incorrect stored limits will be applied.
It’s not a smartthings problem, it’s a problem with the device not meeting the zigbee specification for those attributes.

I don’t know if there are other manufacturers that don’t meet these specifications correctly.

In my drivers I will correct it to apply a default range to all and not apply the automatic temperature ranges.

mocelet · November 3, 2024, 11:19am

They’re using the reported values in Matter lights too for the colour temperature in actions and conditions. A much needed improvement that Nanoleaf users will welcome since the profile had wrong values and the reported ones are correct.

Itati · November 27, 2024, 7:20pm

Hi @Mariano_Colmenarejo

What is it and how will this supportedValues field limit the temperature values?

The range overrides the values in the capability presentation.
It doesn’t affect the operation of the device.

Is this range going to be replaced by the “supportedValues” range of the temperatureRange attribute when there are valid values or with what criteria will they be applied?

Yes

Could this restrict device operation?

No, values outside the range are accepted. The only view affected by this limit could be “Routines” since the conditions are based on that limit.

Andreas_Roedl · November 27, 2024, 8:23pm

Do we still have to populate the temperatureRange manually or does it become obsolete?

Topic		Replies	Views
Issues changing the default range of a stock capability Support	8	613	December 28, 2021
Temperature scale for thermostatHeatingSetpoint/thermostatCoolingSetpoint vs temperatureMeasurement Support temperature , edge-device	5	722	June 20, 2022
Custom Attribute Problems Writing Device Types	3	544	December 13, 2019
What form should be `temperature` attribute in Schema connector to refresh states? Support developers	2	613	May 11, 2020
Needing help with two issues with device-config Support	4	322	November 22, 2024

temperatureMeasurement capability and new temperatureRange attribute

Related topics