MTRBaseDevice InvokeCommand method

Question

Created 6d

Replies 2

Boosts 0

Participants 2

I am calling InvokeCommand on a MTRBaseDevice I received from HomeKit. The device receiving the command is using Matter 1.3 and is expecting a Boolean State Configuration new to that version of the spec. That may be the reason why I get the following error:

MTRInteractionErrorDomain Code=133 "The cluster command is malformed, has missing fields, or fields with invalid values.Command not carried out."

I am sending the following as the commandField parameter:

["type": "UnsignedInteger", "value": 1]

When I look into those values more deeply, the value is specified as an NSNumber holding an Int16 value of 1. I created the NSNumber using a Uint8(1). The docs suggest this should result in an NSNumber treated as an unsigned char, but the debugger reports it as a Int16. I tried changing the type in the command field to "SignedInteger" and this had no effect on the error I receive. So I suppose the problem could also be that my parameters always get a signed value when an unsigned value is expected. Is this something I can correct using the current APIs, or do I need to wait for Matter 1.3 support?

Boost

Answer 1

DTS Engineer OP

Apple

18h

First off, sorry for a bit of a delay getting back to you on this, it's been a busy week.

Let me start here:

When I look into those values more deeply, the value is specified as an NSNumber holding an Int16 value of 1. I created the NSNumber using a Uint8(1).

Basically, no, NSNumber isn't really the issue, as it basically just doesn't work this way. The input value type doesn't really matter and, frankly, it's probably weaker at enforcing value configuration than it should be. I would use "numberWithBool" as the initializer but that's primarily an ascetic choice.

However...

I am sending the following as the commandField parameter: ["type": "UnsignedInteger", "value": 1]

Did you try using "Boolean"?

Looking at the spec side of this:

The device receiving the command is using Matter 1.3 and is expecting a Boolean State Configuration new to that version of the spec.

I think this was basically just renaming an existing cluster, not actually defining a new type. I'm not sure how the framework handles new "stuff", but my expectation is that it wouldn't allow you to retrieve/create objects that it wouldn't also let you send commands too.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 2

LaserPuzL OP

16h

The value is 2 Boolean values stored as bits 0 and 1 in a UInt8. I chose the value I was trying to set as one that could be represented as a “Boolean”, but when I tried that as the type I still got the code 133 error.

My firmware guys told me about the 1.3 Boolean State Configuration, I’ll try learning more about that and if it is a simple rename perhaps I can use something from 1.2 instead. I’ll also see if the firmware guys can tweak something to make it work.

0