How To Set Matter Reporting Interval Configuration?

Developer Programs Support
1

I’m playing around with the Matter driver for lights, wanted to add transition times to the brightness level changes.

At least in my WiZ lights, setting a transition time other than 0 to a MoveToLevel or using a Move command makes the light emit a insane amount of CurrentLevel reports while it is moving (like 100 in 2 seconds), making the hub sluggish while it processes everything.

Looking at the SmartThings API I can’t find anything to configure the reporting interval. Looking at the Matter specification there seems to be a MinIntervalFloor when subscribing to an attribute that I’m not sure if it’s what I’m looking for (would it miss the final level report when the transition ends?).

Since subscriptions in Matter are handled automatically by the platform and the driver just specifies the attributes it’s interested in, I guess configuring a sensible default reporting interval would be useful.

Edit: Out of curiosity I tried with StepColorTemperature using a transition. While there were a lot of reports too it was “only” 10 events per second. Also, seems like there’s a bug in WiZ since DOWN step mode works but UP results in the light reporting a temperature of 0 mireds. I see a funny comment in the stock driver “– shouldn’t happen, but has”. Indeed.

2

Hello,

4 years ago when I started using smartthing I ran into this same problem of lack of custom reporting configurations in groovy zigbee DTHs.

That made me start my first posts and modifications of DTH’s in groovy, to find a solution to the excessive battery consumption of my smartthings motion and contact sensors, with unnecessarily frequent temperature reports.

I had no idea what zigbee or zwave was and 4 years later all my edge drivers have customized configurations of the most important attributes for users. I’m glad this helps someone.

Smartthings still does not offer custom zigbee configurations in any stock drivers, incomprehensible!!!

In Zwave, only some certified devices have preferences to configure parameters and I see that in Matter they continue with the same bad policy.

I see myself reflected in you, with enthusiasm for improving custom drivers with functions that users request.

I am on the downhill slope and much less motivated than a few years ago.

I see you improving the Matter drivers!!, :smile:starting with the same thing that caught my attention, how can smarttings not enhance such an important utility to sell a product?: The personalized use of the device.

Good luck with the task!! :clap: :clap:

By the way, don’t hesitate to ask @nayelyz for help.

Taking advantage of the fact that we are almost April 25th and making a small modification to a Spanish saying about the carnation revolution in Portugal in '74, I can tell you that, we will always have Nayeliy!

9 Likes
3

Thanks! Your work during these years is amazing and adding support for devices you don’t even have is just crazy. I’m just testing some ideas with colour lights that may not see the light, no pun intended.

Except for the transitions stuff which requires a lower-level access to the driver, for most custom features I would prefer if Edge just had some sort of “plugins” support so to speak or “secondary” drivers that would just receive the same messages of the main driver and emit events for that device.

That would leave the important work to the main official driver that is regularly updated to fix stuff and the secondary driver to emit attribute changes (like brightness, colour, etc.) and implement custom capabilities, which would not need a constant maintenance to keep up with the official updates.

1 Like
4

Regarding Matter devices, I have not even tried to see the code in these two years, I do not want, at the moment, to enter them.

Regarding the transitions, I have seen that it is practically identical to zigbee.

In zigbee the main problem is that it is not a mandatory implementation in the devices and there are many cheap manufacturers that do not use custom transitions because they need more complicated hardware with a variable rate change for the transitions to work correctly.

I don’t know if this argument is mandatory or optional in Matter.

This means that many devices have a fixed transition implemented in the hardware/firmware, which is activated by sending a transition value 0xFFFF
In the zigbee smartthings defaults, the value 0xFFFF is sent, this way the device will use its default transition time, like IKEA, or it will be as fast as possible, like in many Tuya light bulbs.

This makes it difficult for implementing custom transition times in preferences to work well on all devices, but it doesn’t create any problems on them either.

This is easy to implement and if you want to prevent the driver from handling each message received during the transition, you can inhibit the function during that transition time and then perform a call_with_delay() to read the attribute when the transition has finished and obtain the final state of the device.

You can also see how the options_mask and options_override arguments work in matter

4 Likes
5

Thanks again Mariano, they’re pretty similar indeed, same clusters, commands, attributes, etc. I guess the initialisation is different when a bridge is involved or if it has to manage child devices too, I prefer to consider that part a black box.

Advanced Matter features like transitions seem to be not there yet. In Home Assistant they recently added a transition by default to Matter lights, then they had to roll it back because most lights would not implement it correctly and made lights extra slow to change attributes :sweat_smile:.

The problem with the flood of level reports is that, even if you don’t process them in the driver, they already hit the hub and generated logs, so the hub still has a hard time processing those mostly useless reports.

I actually made a event suppressor that would only let in one level report every second. While it improved things and made the history less crowded, it’s not the solution. I was using it for the classic “hold and release dimming”, but so far the experience is better with just singular steps or the scene switcher cycling through a few pre-determined brightness levels.

6

This refers to wifi bulbs matter.

I mean matter over thread. The default libraries do consider the transition times the same as in Zigbee.

function MoveToLevelWithOnOff:init(device, endpoint_id, level, transition_time, options_mask, options_override)

In the stock matter-switch driver you only have to replace the cmd.args.rate with a value that is selected in preferences.
(1 sec = value 10).

local function handle_set_level(driver, device, cmd)
  local endpoint_id = device:component_to_endpoint(cmd.component)
  local level = math.floor(cmd.args.level/100.0 * 254)
  local req = clusters.LevelControl.server.commands.MoveToLevelWithOnOff(
    device,
    endpoint_id,
    level,
    cmd.args.rate or 0,
    0,
    0
  )
  device:send(req)
end

It is as implemented in my Zigbee Light Multifunction Mc driver, which is on my github

1 Like
7

That’s exactly what I did and what results in a level reporting festival that floods the hub and makes it unusable while the transition lasts.

My WiZ lights, which are Matter over WiFi by the way, will send a report every time the level value changes so, if you are going from 0 to 254 in 2 seconds you receive around 100 level reports every second :dizzy_face:

I guess WiZ is doing it right though. Report every change unless explicitly configured to not report too frequently.

Edit: In fact, I’d say the light sends the reports in 2 seconds but the hub queues them and takes few more seconds to catch-up.

8

Totally confirmed now, the lights send a current level report every time the value changes. That’s up to 254 reports if you start from lowest to highest.

If the transition time is short, the hub just can’t handle it, will buffer the reports and take forever to handle them, being completely saturated until then.

SmartThings needs to configure the minimum reporting interval if they’re not doing it or should talk to WiZ if they’re doing it and the lights are not obeying it, they’re WWST certified after all.

Otherwise, short transition times are completely unusable. The hub takes like 40 seconds to process all the events that the light sent in 5 seconds. And, until it has processed the queue, it won’t be able to process new commands.

With long transition times that’s not a problem, I did a nice brightness transition from 1% to 100% lasting 15 minutes and it was buttery smooth and the hub was happy because that was roughly one report every 4 seconds. Works nice for a custom wake-up routine which usually spans minutes :sunrise: But in the current state can’t be used for dimmers where the transition time is few seconds and the hub is exhausted for a long time.

Edit: MoveToHueAndSaturation command with a transition time is even worse because it’s twice the reports, which is a pity because the colour changing effect is so smooth when using that command. But, again, without something limiting the report rate is not usable in practice.

1 Like
9

Hmm from what I remember about the early benchmarks, the hub should be able to handle a message every 10ms so it should take no more than a few seconds to process all the messages. Tagging @alissa.dornbos @steven.green

1 Like
10

I guess logging also hurts, but it’s possible to make the lights generate reports at higher frequency. A colour transition for instance with MoveToHueAndSaturation means double the reports because Hue and Saturation are reported independently. And, if you add a MoveToLevel on top of that, it’s a reporting feast.

There should be a way to configure the reporting interval, in fact Matter has the option, I just can’t see it in the SmartThings Edge API.

11

For the stock matter-switch driver, there are no preferences defined in the presentations so the rate always defaults to 0. For example, here is the light-color-level profile:

name: light-color-level
components:
- id: main
  capabilities:
  - id: switch
    version: 1
  - id: switchLevel
    version: 1
  - id: colorTemperature
    version: 1
  - id: colorControl
    version: 1
  - id: firmwareUpdate
    version: 1
  - id: refresh
    version: 1
  categories:
  - name: Light
metadata:
  mnmn: SmartThingsEdge
  vid: generic-rgbw-color-bulb-2580K-7050K

So, while the driver has the code to implement the transition rate, in typical ST fashion, it’s not exposed in the mobile app. It can be done in the AWA or CLI however.

Clipboard01
Clipboard011920×696 61.5 KB

12

Not sure what hub you have, but my Matter devices are using the software hub in the fridge Family Hub. And while I see the same behavior of the device reporting each level step, it doesn’t really seem to affect how fast the light comes up except at really short rates or like 1 or 2 (which is less than 1 sec).

1 Like
13

It doesn’t indeed, that’s not the issue. The light does its job and transitions as it should.

The problem is that the hub (Aeotec) is so busy during the transition that it you try to do anything else it will lag a lot. Not just during the transition but a few seconds after while it catches up.

14

Perhaps a difference between the Aeotec and the fridge hub. I don’t experience the same lag.

1 Like
15

I notice it using buttons, the button that toggles that light on/off can take few seconds to actually turn it off if pressed in the middle of a transition.

Sometimes is fast as usual even in the middle of a transition, I guess it depends on the queue of messages and the timing, maybe even if you have a logcat session opened or not. Also it’s not the same having just one light or having, let’s say, three, that would be triple the reports.

The Aeotec might not be the fastest hub, that’s why it would be best to be able to configure the reporting interval, I don’t need 762 level reports in five seconds of three lights going from 1% to 100% and the hub does not want it either :sweat_smile:. That’s an average of a report every 6 ms and it’s a use case you could find in practice.

16

Now this is funny, while MoveToLevel with a transition time only reports when the level brightness changes one unit (so at least for long times does not flood the hub), using any MoveToColor / Hue / Saturation with transition time will produce reports of Hue and Saturation every 80 ms even if the value does not change! Also, you cannot trust the log times because the date is added later when it’s processed, not when the message is received and buffered.

As you can see, same hue / sat values reported three times in a row. The hub struggles with this because it can’t keep up with the rhythm so it starts buffering and lagging.

	Line 41: 2024-04-28T10:05:24.286953667Z INFO Matter Dev  <MatterDevice: 048443b7-5292-4c7c-aea7-a31d3cc7f0b8 [4CB43E8A550818D6-7C399BB24C949A00] (Bola Matter)> received InteractionResponse: <InteractionResponse || type: REPORT_DATA, response_blocks: [<InteractionResponseInfoBlock || status: SUCCESS, <InteractionInfoBlock || endpoint: 0x01, cluster: ColorControl, attribute: CurrentHue, data: Uint8: \x04>>, <InteractionResponseInfoBlock || status: SUCCESS, <InteractionInfoBlock || endpoint: 0x01, cluster: ColorControl, attribute: CurrentSaturation, data: Uint8: \x8C>>]>
	Line 58: 2024-04-28T10:05:24.373203500Z INFO Matter Dev  <MatterDevice: 048443b7-5292-4c7c-aea7-a31d3cc7f0b8 [4CB43E8A550818D6-7C399BB24C949A00] (Bola Matter)> received InteractionResponse: <InteractionResponse || type: REPORT_DATA, response_blocks: [<InteractionResponseInfoBlock || status: SUCCESS, <InteractionInfoBlock || endpoint: 0x01, cluster: ColorControl, attribute: CurrentHue, data: Uint8: \x04>>, <InteractionResponseInfoBlock || status: SUCCESS, <InteractionInfoBlock || endpoint: 0x01, cluster: ColorControl, attribute: CurrentSaturation, data: Uint8: \x8C>>]>
	Line 76: 2024-04-28T10:05:24.459981Z INFO Matter Dev  <MatterDevice: 048443b7-5292-4c7c-aea7-a31d3cc7f0b8 [4CB43E8A550818D6-7C399BB24C949A00] (Bola Matter)> received InteractionResponse: <InteractionResponse || type: REPORT_DATA, response_blocks: [<InteractionResponseInfoBlock || status: SUCCESS, <InteractionInfoBlock || endpoint: 0x01, cluster: ColorControl, attribute: CurrentHue, data: Uint8: \x04>>, <InteractionResponseInfoBlock || status: SUCCESS, <InteractionInfoBlock || endpoint: 0x01, cluster: ColorControl, attribute: CurrentSaturation, data: Uint8: \x8C>>]>

Not being able to use transition times for colour or levels is bad… Again, since SmartThings does not expose the configuration of the subscription it’s hard to say if it’s a misconfiguration in the SmartThings part or a misbehaviour in WiZ lights.

17

Looks like Tapo does the same (worse actually since they don’t transition in time), reporting in every level change: Tapo L535 RGBW Bulb slow level transition - Matter - Hubitat Maybe Hubitat does not configure the reporting interval either.

A user there says the Nanoleaf is not so “chatty” when it comes to updates while transitioning, I’m so curious that I’ve just ordered one. They recently published a firmware with Matter 1.2 compatibility and numerous fixes so may be the time to try a Matter over Thread light.

1 Like
18

It does, however, some bulbs do not obey the Matter subscription minimum reporting time configuration. I ended up filtering the spammy level change messages in a custom driver, as soon as the subscribed level attribute is received by the hub.

2 Likes
19

I do that too but it’s not enough, at least for WiZ and the Aeotec hub. Also, at least in SmartThings, you cannot distinguish a final report from the transition reports (I don’t even know if Matter does that distinction actually).

Would be nice to know if SmartThings configures the reporting interval or not, at least in the API or the Lua libraries there’s no mention about it.

20

You can look at the code here.

I simply delay sending the level/hue/saturation/RGBname events by a configurable time threshold value in milliseconds. The first level report is stored internally and then a timer is started. Only when the timer expires, the last stored attribute value will be sent as a new event, will be logged, etc. If a new report arrives before the timer has expired, the last value is stored internally in a state variable, and the timer is restarted, decreasing the time when the delayed event will be fired.

This way, if the transition from 0 to 100% level is performed by the bulb for, lets say, 3 seconds, and the spammyReportsFilter value is 1000 ms, there will be only 3 events fired - the last reported value after the first 1000 ms interval (33% as an example), then the last reported value after the next 1000ms time interval, etc… All the level reports 0…32 will be ignored - they will just decrease the delayedEvent scheduled job, but will not overload the hub as no events are generated, stored and processed by all apps that listen for this event. All the processing of the event levels 0…32, 34…65. 67…99 happens in the memory only.

The price is delaying the spammy events with the filter time value, but this is not critical for levels, hue, saturation, color, etc… The on/off events are not delayed.

1 Like