Unable to comision device with Smartthings

[JimBuzbee]

Failed to add node-matter "device" with Smarthings app. The commision process starts with expected messages after I scan the QR code, then I get a warning about a non-certified device, then the app appears to partially crash sending me back a couple of screens to the scan QR screen again and no device showing up in Smarthings.

smartthings.txt

[JimBuzbee]

Update - I guess I'm not that familiar with SmartThings because I did find that the device had been added, but it is non-functional. See screenshots attached.

[JimBuzbee]

One more update - I am getting some interaction between node-matter and Smartthings. I can turn my light on (for me, Govee), but not off. Every button press in the App sends an "On". Maybe the message "The device hasn't updated all of its status..." means that Smarthings doesn't know if the light is on or off so it always sends an "on" ? Does the spec call for a periodic on/off status message that we are still lacking causing Smarthings to be confused?

[Apollon77]

is the above log really complete?

[JimBuzbee]

@Apollon77 - It may not be, I probably confuse myself with too many node-matter instances running plus Alexa, Google Home and SmartThings on my net at the same time :-) Attached is new log of what I think is a complete, clean run of adding a new Matter device and then hitting the On/Off button twice in the SmartThings app. You will see two sets of output from "curl" which is what I use to control my Govee lights. Both look like they were told by SmartThings to turn the lights on rather than one "on" and one "off".

smartthings1.txt

[mfucci]

Thanks for reporting this! There are a few hacky code paths that I am cleaning up right now and I will update on this thread when there is some chance that it might now be fully working.

[Apollon77]

I think the relevant part here is

2023-0-5 14:37:6.332 ERROR InteractionMessenger Error: Unsupported message type 6

@mfucci I will try to implement it

[Apollon77]

@JimBuzbee if you like try https://github.com/Apollon77/node-matter/tree/writereqest-support, this should add support for writeRequest ... Please provide the log in any case

[JimBuzbee]

@Apollon77 - thanks for the update. Log attached.

Behavior is similar to before. It takes over three minutes after scanning the QR code before I see any debug output, but once it starts, things go fairly quickly. I spot one error in the log regarding a mandatory field, but behavior is as before.

The SmartThings app appears to partially crash near the end of the process, but the device is added. When I bring it up in the app I get the message saying "This device hasn't updated all of its status information yet. Check again later" Both "on" and "off" operations send an "on" command to node-matter.

smartThings.txt

[Apollon77]

@JimBuzbee Please update branch again ... I changed some fields to optional... lets see where it ends now :-)

For the "on and off triggers on" I can just also refer to the log ... it sends "on"

2023-0-4 6:24:59.911 DEBUG CommandServer Invoke on with data {} 2023-0-4 6:25:16.454 DEBUG CommandServer Invoke on with data {}

So this seems more a bug to report to Smartthings

[JimBuzbee]

@Apollon77 Thanks. Hope I updated properly - I'm also a "git" novice :-) New log attached.

I see similar behavior. Regarding the on/off - I wonder if SmartThings is trying to do a toggle, but it can't determine the current state so it always sends an "on" ?

smartThings1.txt

[Apollon77]

Hi,

yes you did the update right and please try again :-)

It will still not work,but log more details now.

They are sending a Write to MA-rootdevice(0x0)/Basic Information(0x28)/* ... so to "multiple" attribues ... I do not understand how that can make ever sense :) Thats why I returned an error in this case...

Reading specs too

[Apollon77]

For on/off:

They should know the value because they get subscribed infos according to log:

2023-0-4 6:53:28.099 DEBUG SubscriptionHandler Sending subscription changes: [{"path":{"endpointId":1,"clusterId":6,"id":0},"valueVersion":{"version":1,"value":true},"schema":{}}]

Additionally Mater itself offers a toggle action ... so it should be straight forward

[JimBuzbee]

Here's an updated log.

Regarding on/off - I wonder if SmartThings is just in a bit of a bad state because of what I think it is crash.

smartThings2.txt

[Apollon77]

Ok, I added some more logic to the impelemtation, but still tgis write request is strange ...lets see what happens now :-)

I assume they just want to set the "Node label" but they sed a write for "*" on one object ... The new code is now tryig to set the value a defined ...lets see :-)

[Apollon77]

Wait .... give me some mins

[Apollon77]

Now ready ... lets try again :-)

[JimBuzbee]

OK - Here's another run. Looks pretty much the same from the App's point of view. One thing I will mention, I did see one attempt to add a device not crash - timing issue somewhere? The process completed and I saw a message quickly flash across the App's screen about downloading an add-on to determine the devices state. But if it did something, I see no change even after restarting the app. Every other time I've attempted, it crashed and is still crashing.

smartThings3.txt

[Apollon77]

Ok, then again another try ... found an issue (need more coffee too today, thats another issue it seems ;-) ) :-)

[JimBuzbee]

I'm fully loaded with coffee this morning. Took the dogs out for a walk here in Denver with a temperature of 9f/-12c and 7 inches of snow.

Log attached. From App's point of view, looks the same.

smartThings4.txt

[Apollon77]

Ok, I now added a very bad hack ... check it please ...

@mfucci I need a hint how to:

• get info if a field is writable or not
• make sure the field validator also respects length requirements and such

According tospecs als "mass writes" are supported and all fields that are ot writeble or where the constrains do not match (type, length ....) are ignored basically ...

[Apollon77]

@JimBuzbee But I assume that also this will not change that much ... you see that after "setting the node label" the Smartthings app registers a subscription and also receives the response. So if something is incorrect there then it feels more like to be reported to them

[JimBuzbee]

OK - Thanks! Here's the log and as suspected, from the App's point of view, it looks the same. I would guess that the SmartThings developers have some work to do as well. During the process of adding a device I get a warning about an uncertified Matter device that might not function properly, so I would guess they won't entertain bug reports from this "device", but I'll see what I can find as far as reporting.

smartThings5.txt

[Apollon77]

The info of an uncertified device will stay because this lib never will get any certification in this regard for "open source" usage.

And yes the log with that hack now looks "as expected", but no idea what they behave as they behave

[JimBuzbee]

No change, but I attempted to send a problem report to SmartThings via a "contact us" menu in the app, but It crashed. :-)

As a followup, I assume that the following debug line is node-matter periodically sending the light status to SmartThings, where "true" signifies that the light is on?

SubscriptionHandler Sending subscription changes: [{"path":{"endpointId":1,"clusterId":6,"id":0},"valueVersion":{"version":1,"value":true},"schema":{}}]

Which brings up the question, what is the thought for how node-matter will determine the state of the light? All of my smart switches and plugs have a physical button that allow direct change, potentially making the device state out of synch with node-matter. I would guess that this is out of scope for the Matter protocol with the assumption that the device somehow always knows the state of "itself".

[Apollon77]

node-matter has the state as it was last set ... means: default = false, when you set "on" then stat is "on" ... if you set "off", state is off. In the current "highly test phase" with this command interface exposed any "side actions" will break the state because node-matter do not know about these changes.

In fact correct that ndoe-matter sends the state and it should do that for any change ... if you say it is "constantly" doing this without any action then there is a bug

[JimBuzbee]

Regarding side actions on a device, as a test I added the attached bit of code to Device.js to allow specification of a script to be called periodically via an optional command line argument. For example

-status "cat /sys/class/leds/led1/brightness"

I don't typically like polling for changes, but It seems to work fine allowing side actions to be synched to node-matter and sent out to subscribers. I realize that this conflicts with your work to allow multiple devices to be specified on the command line and I'm not sure it fits the node-matter design, but it was a fun experiment for me :-)

diff.txt

[Apollon77]

@JimBuzbee In fact this interface currently is just "to exactly play around" easiely. Like the idea ... but would for now not include it :-)

[Apollon77]

@JimBuzbee If you like it could be an iodea to try again with latest main branch ... lets see if somethings changes now that we answer correctly to subscriptions

[JimBuzbee]

I've tried a few times recently with the latest main branch and am seeing a bit of difference in behavior. Previously SmartThings would crash near the end of the commission process, but now it just gives a generic error of "something went wrong". The device gets added anyway, but as before, it complains that the device hasn't updated its status. When trying to use the UI on the node-matter device, SmartThings always sends an "ON", never an "OFF".

Also, SmartThings does not show the light intensity adjustment like Google Home and Alexa do when using my new Level Adjustment cluster.

If it is of interest, I came across another Android app on the Google Play store that is supposed to be able to work with Matter, "Smart Life". When I try to add a node-matter "device", I see lot of message exchanges in the console and in the adb log, but fairly quickly the app gives an error of "The Matter Device is not supported" If you'd like I can create a new issue for this app and attach logs.

[Apollon77]

Would be interesting to add another iddue for Smartlife (did myself: https://github.com/mfucci/node-matter/issues/261 ) with a log that I can check how it goes. And also an updated log for Smartthings would be cool

[Apollon77]

PS: SmartLife is the "Tuya" Ecosystem. I will also try that

[JimBuzbee]

@Apollon77 - Here's a couple of log files. One from the node-matter side and one from the Smartthings side. Note near the end of the SmartThings log where it complains about a timeout. That was after a long wait and just before I saw the error on the screen. SmartThings was waiting on something - not clear to me what, but it always complains that "the device hasn't updated its status information yet. Check back later"

• 02-24 07:32:11.409 5403 5444 E [-7]oneconnect[1.7.97.22_01][MAIN_UI]: [Onboarding] MatterRegisteringPresenter.rendezvous - timeout exception kotlinx.coroutines.TimeoutCancellationException: Timed out waiting for 180000 ms
• 02-24 07:32:11.428 5403 5403 I [-7]oneconnect[1.7.97.22_01][MAIN_UI]: [Onboarding] MatterErrorPresenter.onViewCreated - [error]RENDEZVOUS_RESULT_TIMEOUT

The logs also contain a couple of commands sent from the app to node-matter. As always, both are an "on" command.

P.S. - node-matter party trick that amused me. I have a weather station my backyard and it's hooked up to node-matter with the TemperatureMeasurement cluster so I created a backyard "room" in Google Home. Now I can say "OK Google. what's the temperature in the backyard?". And it replies using the correct temperature from node-matter! Unfortunately for us Americans, it always uses Celsius ;-)

SmartThingsLogcat.txt SmartThingsNode-Matter.txt

[Apollon77]

Hm ... Do you REALLY used newest main branch and also did "npm build"? Subscription wise there are different logs in the meantime and the subscription is still "wrong" ... So I doubt it a bit ;-) Can you please recheck? The relevant PR was merged 5 days ago

Additionally to subscriptions he tries to read some value that we do not have defined, so it could be blocked by that because we do not answer correctly to such a read request. it is about the "gloabl feature flags" 0xfffb, 0xfff9, 0xfff8, 0xfffa

[JimBuzbee]

Good catch. My process has been to Sync my branch from github. It tells me "This branch is up to date with mfucci/node-matter:main." then I do a pull from my local machine and then "tsc". Maybe I was missing the "clean" step that "npm run build" was doing?

Anyway, I did a fresh pull and build from main and got better results. I still get a timeout error from SmartThings when adding the node-matter device, but afterwords, it works! i.e. It now sends both "on" and "off" commands. I did notice on Twitter that an update to the SmartThings app is going out, so that also could the change.

New logs attached.

SmartThingsLogcat-1.txt SmartThingsNode-Matter-1.txt

[Apollon77]

Cool, then lets wait when we can have the "read for unknown attributes" fix in and then try again .. I would hope it is about that

[JimBuzbee]

I also tried the Humidity and Temperature devices. SmartThings accepted them and they showed up in the app after the error, but were non functional with the same "The device hasn't updated its status information yet. Check back later" message. Hopefully it's the same "read for unknown attributes" issue.

[Apollon77]

Ok please retry with main branch and provide a new log. Thank you

[JimBuzbee]

OK - Here's a set of logs. Unfortunately, I still get the same timeout message in the logs and error in the app.

SmartThingsLogcat-2.txt SmartThingsNode-Matter-2.txt

[Apollon77]

Ok, we now answer correctly to the read request .. so no idea. what this timrout is all about

[JimBuzbee]

Tried pairing again this morning and seeing something interesting. My first attempt succeeded without the timeout (but I neglected to grab a log). So I tried again and got the same failure. And then failed again with the Humidity cluster. Tried again with the Temperature cluster and succeeded. Log attached.

I still get an error/warning in the app stating that the device hasn't updated status yet, but it is functional. Screenshot attached where you can see it is forming nice little temperature graph, but not sure why it thinks there's a battery. This inconsistent behavior leads me to believe there's a timing issue somewhere and most of the time SmartThings and node-matter don't sync up.

SmartThingsNode-Matter-3.txt

[Apollon77]

In general I also have this effect sometimes in ios and also google where all is established and subscription is setup and anything but the Apps show "device not connected". As soon as I "open" the device itself then it shows as "uptodate". So seems to me like still also some App internal "data update issues", especially when it switches from "The App does the pairing and then the Hub takes over for the "operative" connection".

Seems same for Smartthings.

2023-02-28 09:15:17.304 INFO PaseServer Pase server: Received pairing request from udp://192.168.1.22:5541

... then it starts pairing ... then commissioning is finished from ...

2023-02-28 09:15:29.666 INFO CaseServer Case server: Received pairing request from udp://fe80::26fd:5bff:fe03:cc52%wlp3s0:56087

... then it swiches back for second fabric and start again from

2023-02-28 09:15:38.388 INFO PaseServer Pase server: Received pairing request from udp://192.168.1.22:46106

... and finishe from

2023-02-28 09:15:40.218 INFO CaseServer Case server: Received pairing request from udp://fe80::2c0a:c5ff:fe7b:68a6%wlp3s0:50453

Can you check what is what? (App, Hub ...)

[JimBuzbee]

@Apollon77 - I see the same type of "device not connected" behavior with Google and Alexa, but SmartThings seels a bit different. Its "device has not updated its status" message is permanent. As far as versions, here's what I can find:

• Hub firmware: 000.046.00010
• Controller version: 2.3.17-11

• App version: 1.7.98.21

  I spent some time trying to get more consistent behavior without much luck, but here's some findings:

Out of 12 pairing attempts, only the first one succeeded without a timeout (I saw same behavior yesterday, i.e. first attempt of the day succeeded)

For the OnOff Light device, both the successful and the timeout pairings had same behavior (after dismissing the SmartThings error). The device is fully functional, although there was no Intensity adjustment UI like I see in Google and Alexa

For Temperature and Humidity devices I did not get a non-timeout pairing, but after dismissing the error I see a complaint about the device not updating its status every time I bring the device to full-screen in the app. This message continues to show even on a node-matter Temperature device I've had running overnight. Otherwise both are functional, but they show an empty battery status display - wonder if that is what the complaint is about? For some reason, SmartThing thinks there should be a battery status returned?

Stack-traces from node-matter - Attached is a log with a couple of stack-traces from node-matter. The first one in the file is commonly seen (always?) after I have paired a device, removed it from SmartThings, restarted node-matter, restarted the SmartThings app and tried to pair a new device. After this message, I stop node-matter, kill the app and try again without the problem. Wonder if SmartThings has some persistence and tries the same connection again? I only recall seeing the second stack-trace once.

SmartThings-Crash-1.txt

[M4rkoV2]

Any news on this? I also couldn't connect it to SmartThings. Can't even add the device.

Always fails.

[Apollon77]

@M4rkoV2 Please see readme. node-matter is deprecated and oputdated. Please switch to matter.js ... all works there