-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to complete commission process with Home Assistant #11
Comments
Pull request #13 should fix this issue since this is related to read attribute wildcards not handled. |
Pull request #13 does not completely fix this issue. I see more messages in HA now after the 'Cleanup' line (compared to before)...
But I don't see the device in HA... here is what I see from node-matter (don't see any further read requests than before)
|
After enabling debug logs on HA, here is what I am seeing. Not sure what ResolveNode does...
|
0/48/4 has been invoked (CommissioningComplete) so the commissioning should have succeeded. Can you capture the network packets to check what is going on? |
Any chance to get a network capture to investigate this issue? |
Here are two pcap files - both captured on home-assistant side. One is with succesful commissioning of ESPDev device that HA tutorial used. The other is almost successful (but not quite) capture with node-matter. Hope Assistant IP: 192.168.1.57 (IPV6: fe80::a199:dcb4:dc7) tcpdump command used to capture (on HA machine):
Hope this helps. |
Thanks! I know that many mandatory clusters / attributes are not implemented in node-matter. Many if we pinpoint the attributes that HA plugin expects, I can add just those one. In matter_server/client/matter.py#L86 can you add a few logs to check if self.client.driver.device_controller.commission_with_code is returning? Does "ERROR Operational discovery failed for" happens each time? Previous log says that it waited for 15s but that doesn't match with the other timestamps in the logs, since logs start less than a second ago. |
Agree the MDNS was only related to discovering commissionable device. The logs and tcpdump capture don't agree on timing, because I failed to capture logs when I was using tcpdump, so they are from a different run. I tried to edit the matter_server files to add log statements, but within HA this is not easily done because the matter server is a docker image that I can't easily manipulate. I am out of town for next two weeks so when I return, perhaps I will try to build my own docker container for matter server and insert the debug statements. |
Does the zipped version of node-matter includes all fixes up until to this point? Thanks. |
Hi Javier, If you download the sip of the main branch, it will contain all the latest fixes. Thanks,
|
The last log means that the commissioning was successful. To turn on/off one LED on a Raspberry Pi, here is the command: matter -on "echo 255 > /sys/class/leds/led1/brightness" -off "echo 0 > /sys/class/leds/led1/brightness" You can run your own scripts on "on" / "off" to do something more advanced. Thanks!
|
As a matter of fact, I have Matter deployed on a Raspberry Pi 4. So I ran the chip-tool on it to pair with your Matter server. Thanks again. |
I have previously mentioned that chip-tool can successfully pair with node-matter after the following issue was fixed: #3 (comment). T his particular issue is inability to complete pairing process with Home Assistant Matter Add-on. |
Inadvertently, the HA aspect of the issue didn't register, just the issue of the commission process I will start a separate issue, for any further non-HA questions/problems. |
Upon further debugging interview_node is failing because of missing "Descriptor" field in some attribute returned by node-matter. The affected code is in matter_server/client/model/node.py (line 129)
Here is the stack dump
|
The working ESP device seems to send following attributes and other fields (as printed by HA add-on)
|
Thanks you very much for this debugging! |
Here is a PR that adds the Descriptor cluster: #17 Let me know if this allows to pass one extra steps with HA! |
With this change, interaction with HA goes much further (the device shows up in UI - but broken). It is likely because following error in node-matter
I am seeing the descriptor in HA logs
Here is one more log snippet from HA that may help
|
Message type 3 on the interaction protocol is SubscribeRequest per this file: https://github.com/project-chip/connectedhomeip/blob/master/src/protocols/interaction_model/Constants.h And yes, this is not implemented yet. Both ReadRequest (implemented) and SubscribeRequest returns a SubscribeResponse so half of it is already implemented but subscribe mean the server should inform the client when the value changes so that would be the first message initiated by the server rather than the client, which will probably require some large refactoring. I can do a quick hack and just have SubscribeRequest acting as ReadRequest, this should probably make it works for now. |
Thanks for your help testing this! |
Even if the message is not supported, the code should not throw an exception and exit. It should log an error/info message and continue. This is true when handling MDNS requests too. Currently, I am getting exception with MDNS requests from 127.0.0.1 that results in code throwing an exception and exiting. I will open up another issue for MDNS. |
Here is a fake implementation of subscribe that should allow to pass that step: #20 A correct handling of unsupported operations is more complex then just ignoring it since it can lead to incorrect states. |
I tried the above PR and things seem to progress much further, but now HA is repeatedly issuing following logs (the key error seems to be ../../src/app/MessageDef/ReportDataMessage.cpp:90: CHIP Error 0x00000026: Wrong TLV type:
And node-matter keeps printing the following message repeatedly
|
Looking at the code base, it seems like one of the attribute node-matter is returning needs to be an array:
|
Thanks as usual for your detailed debugging! Somehow, this bug did crash the Andoid test app, I did test the subscribe request with it... |
With this change, I am able to successfully add device to HA and have it appear in the UI. When I try turning the light ON using the UI, the node-matter prints proper echo message (e.g. matter -on "echo itson") However, I suspect that since the subscription message is a dummy implementation, the state of the light within HA reverts back to Off and then HA tries to re-subscribe periodically. Here is the log from HA
Here is log from node-matter
|
Fantastic, we are close now! The Android app has a subscribe button, so I should be able to do the real implementation of "subscribe". It will require some refactoring though since I now need to keep a state per attribute telling who has subscribe to it, so it will take a couple of days. |
This is the right answer. For a simple test, I just hardcoded my ipv6 address into node-matter and Commissioning with Google Home App worked and devices showed up in my "Home". But it immediately went offline. This is a repeatable behaviour so we should be able to debug it. When I tried the same hardcoded ipv6 address hack with Android HA Companion App, the commissioning went much further but somehow the HA app just got stuck (waiting for some response or such). |
I will experiment around with it tomorrow and potrovide an experimental PR. Idea wopuld be to sort the adresses and start with the "most global one" found ... For Google home "went offline after commissioning": Do you have just the App or also a Google/Nest Hub? If not then this behaviour is to be expected, see our Readme! Google, Apple and ALexa all need a "hub" to operate the devices. Pairing works via app on Google and Apple, but after that only the hubs are communicating. For Alex even the commissioning process is done by their Hubs (aka Echo devices) |
Aha - I don't have a hub - that explains it. |
exactly.No idea how it work with HA, but I assume that HA server would be the "hub" then afterwards ... ?! |
That is the idea - matter-server add-on is supposed to be the hub |
Attached are captured logs from node-matter and android phone (adb logcat | grep matter) when trying to Commission with HA Android Companion app (with hardcoded ipv6 address in node-matter). It seems like things progress up-to a certain point and then stall. |
For comparison, attached are node-matter and adb logs with Commissioning actually does complete when using Google Home app. |
In fact according to the ligs in my eyes nothing is "stalled" ... it just has been commissioned correctly... see also
Also the adb log shows
So the initial step is done. For Apple/Google this is konf og the part the app does. AFter that you get a new connection to the device coming from "the hub" to initiate the operational connection that then subscrie to values and such So here the question would go to HA about what is supposed to come next |
The lines you are seeing is in successful commissioning with Google HA app. The logs for commissioning with HA Companion app (one reply above that) don't have the 'completed' lines. |
I'm not sure after investigating. especially for MDNS traffic which is supposed to be "local discovery" it makes more sense to use local interfaces over global ones |
then please show the logs when pairing with Companion app?? :-) |
They are already posted here. I posted logs with HA App first and then with Google Home app. |
Good news (at least for me). It seems like my router was somehow not enabled for IPv6 routing on the LAN. After enabling IPV6 routing on my local LAN, the node-matter code now works without any modifications (for hardcoding IP) - the Google Home App can now consistently find and commission. The HA app now consistently finds the device and starts commissioning but fails to complete it (as seen in logs I posted earlier #11 (comment)). Attached is the screenshot of my working IPV6 router settings (I am using Unify USG router). This shows the LAN ipv6 properties. |
Ok, then the reason is that we do not yet respon correctly to read requests for unknown attributes.
I already solved this locally and PR will come soon |
Ok the PR that fixes the read response of unknown attributes is in. Please try again and provide a new log. Thank you |
Yes!!!! With this change I am able to commission the node-matter device and control it with HA. We can close the issue now. |
Can you please (for completeness) post a node-mater log from such a pairing process? Then I close |
For future reference, attached is log from node-matter and corresponding logs from HA Matter server of a successful commissioning and turning the switch on/off from HA a couple of times Hopefully closing this issue for good now. |
Let's see ... I have one PR that I will merge soon that could get interesting so I would poke again here after merging for a last test if ok for you. But interesting ... Hass even registers 3 Fabrics on the devcie which is 1 more then Apple/Google ... no idea why they do that. Seems like the "Google way" plus then one of their own. |
sure |
With latest release of Home Assistant and Matter Add-on, I can no longer commission with node-matter. However, this is not an issue with node-matter. It is an issue with HA because it is now refusing to commit devices with test vendor id (0xfff1). I am still looking for a workaround similar to how you have to add test vendor/product Id to the Google backend for pairing with Google Home. |
With the infos from above and the "HA companion App" which uses Google in the background please check the readme about the instructions on how to use the Google Developer Console to whitelist this vendor/product id ... I would expect that this helps then?! |
DId you opened an issue on Homeassistent to get details? |
Can you please post logs from both parties (node-matter and also HA). |
No logs from node-matter - it doesn't even get a connection request. Will post HA logs in a day but I didn't see any errors or logs. I will likely have to get phone logs.
Jatin
…Sent from my mobile device
________________________________
From: Ingo Fischer ***@***.***>
Sent: Wednesday, March 8, 2023 6:56:35 AM
To: mfucci/node-matter ***@***.***>
Cc: Jatin Desai ***@***.***>; State change ***@***.***>
Subject: Re: [mfucci/node-matter] Unable to complete commission process with Home Assistant (Issue #11)
Can you please post logs from both parties (node-matter and also HA).
Are you sure that only HA was updated or did you also updated node-matter? because we now generate correct certificates and not use the "full testing default chain". But chiptool and all othersd are ok with it, so would be interesting to see the logs
—
Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmfucci%2Fnode-matter%2Fissues%2F11%23issuecomment-1460047087&data=05%7C01%7C%7C1917df74a1fd4744ff6d08db1fcc2b99%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638138733981354700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=n5z%2FfS2Y%2FlegbwfM3RzX1hb4U4okg3WeIHBPoW7O6gc%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADBZQWBAGAF3GRF22PANSETW3BXXHANCNFSM53TPMB6A&data=05%7C01%7C%7C1917df74a1fd4744ff6d08db1fcc2b99%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638138733981510932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1%2B9nK7MDYvBIoeaVA1iXAGBFSTt0wyWw5sVCcxGhl80%3D&reserved=0>.
You are receiving this because you modified the open/close state.Message ID: ***@***.***>
|
But sorry when e have not a singel connection request then it CAN NOT be certificates or such ... then it is more network or UDP data flow |
Not sure what happened, but after another upgrade of HA, it started working again... Sorry for the noise. |
After modifying the code to make clusterId and attribute Id optional by returning zero when either of the fields are not present), commissioning with Home Assistant progresses further and from node-matter it seems like the device paired - but somehow HA add-on gives up after receiving response from last read... Here is how it looks from the node-matter side:
No further communication from HA to node-matter after this read request. However, HA doesn't complete the full commissioning process. Not sure what is going on, but here are some HA logs...
Without specs, it is hard for me to tell what is going on. But HA add-on is also WIP, so will wait till it stabilizes
Originally posted by @jdesai61 in #8 (comment)
The text was updated successfully, but these errors were encountered: