[BUG] bridge-app use on Apple Home - Thread Border required warning

[mustafayuce33]

Reproduction steps

1.I have built bridge-app on Debian based device 2.I run the executable file on Debian device by command "./chip-bridge-app" 3.I try to add this matter device on Apple Home 4. I go to Apple Home and click add accessory button 5. I see my device in discovered devices list then click that device enter passcode 6. Apple Home says "Thread Border required".

But this device is just a virtual device running on Debian for testing and I do not understand why Apple says it needs Thread Border router.

Bug prevalence

Whenever I do this

GitHub hash of the SDK that was being used

https://github.com/project-chip/connectedhomeip/commit/b9d32ecefd004adb7cc4c70a5f4a567dca199da0

Platform

darwin

Platform Version(s)

No response

Anything else?

No response

[bzbarsky-apple]

@mustafayuce33 Is this bridge-app from the SDK, completely unmodified? And is it running on-network, or are you trying to commission it over BLE?

The single Network Commissioning cluster bridge-app defines has FeatureMap set to "2", which means "supports Thread networking", so if the commissioning is happening over BLE a Thread network would need to be set up on the bridge-app, which does require a Thread border router. If the commissioning is happening over IP, then I would not expect that message...

[mustafayuce33]

Thanks for quick reply @bzbarsky-apple. It is completely unmodified. How can I set my bridge-app to run over on-network? And how do we set FeatureMap so that commissioning will be made over IP? Thanks for your kind help

[bzbarsky-apple]

How can I set my bridge-app to run over on-network?

Is the device it's running on actually on the network you are trying to commission it onto? Is the app being discovered over BLE or over DNS-SD?

And how do we set FeatureMap so that commissioning will be made over IP?

Set the value to 4 instead of 2 is the simplest thing (that claims "ethernet"). But that will only work if the device is in fact on the network you want to commission onto.

[mustafayuce33]

@bzbarsky-apple

Is the device it's running on actually on the network you are trying to commission it onto? Is the app being discovered over BLE or over DNS-SD?

App is being discovered over DNS-SD

Set the value to 4 instead of 2 is the simplest thing (that claims "ethernet"). But that will only work if the device is in fact on the network you want to commission onto.

Where do I set that value? In which file is it?

[bzbarsky-apple]

App is being discovered over DNS-SD

That is extremely strange. In that case I would not have expected the "border router" thing to come up at all...

Where do I set that value? In which file is it?

You would want to change it in examples/bridge-app/bridge-common/bridge-app.zap and then regenerate the generated code for that app. But again, if you're being discovered over DNS-SD that should not be needed.

[bzbarsky-apple]

@mustafayuce33 Is the device connected to the IP network via WiFi or Thread?

[mustafayuce33]

@bzbarsky-apple Device is just a raspberry pi cm4 module and it is connected to Wifi network. And that cm4 module does not have bluetooth adapter. Let me explain what I did so far;

I have linux machine and run the bellowing commands

Linux: $ cd "~/dev/connectedhomeip/examples/bridge-app"
Linux: $ source third_party/connectedhomeip/scripts/activate.sh
Linux: $ gn gen --args='target_cpu="arm" target_os="linux" sysroot="/opt/pi/sysroot" system_libdir="lib/arm-linux-gnueabihf" chip_config_network_layer_ble=false is_clang=true' out/cm4
Linux: $ ninja -C out/cm4

Here I make an executable for raspberry pi on my linux machine with cross compile. And I move binary file in out/cm4 to Pi Cm4 module and run it as follows;

PiCm4 : $ ./chip-bridge-app

After that I try commissioning but Apple home says "Thread border required"

I also tried with ./chip-bridge-app --wifi but still no success.

[mustafayuce33]

Here is the log file attached. May be it could help. Btw I tried setting FeatureMap to 4 in bridge-app.zap but still no success

matter.log

[mustafayuce33]

Set the value to 4 instead of 2 is the simplest thing (that claims "ethernet"). But that will only work if the device is in fact on the network you want to commission onto.

@bzbarsky-apple But I noticed that there are so many FeatureMap attributes in examples/bridge-app/bridge-common/bridge-app.zap. Will I change all of them? And I will change the default value to 4?

[bzbarsky-apple]

@mustafayuce33 A few things:

1. I did some checking, and Home does not special-case on-network pairing: if the device claims to be Thread-capable-only it will try to configure Thread networking and give you the observed error message if that's not possible.
2. You need to change the FeatureMap for the Network Commissioning cluster on endpoint 0. Every single cluster has a FeatureMap; you need to change the one for this one specific cluster. This is most simply done using the ZAP tools's UI (via ./scripts/tools/zap/run_zaptool.sh examples/bridge-app/bridge-common/bridge-app.zap), but can be done by hand in the JSON if you are careful.
3. Just changing the .zap file is not enough. You need to also regenerate the generated code for bridge-app, and in particular the endpoint_config.h file. You can do this by running:

   ./scripts/tools/zap/generate.py examples/bridge-app/bridge-common/bridge-app.zap -o zzz_generated/bridge-app/zap-generated
   

   You could also just manually edit the endpoint_config.h and skip changing the .zap file, but again you have to edit the right part of it.
4. Fundamentally, the issue is that the bridge app does not really implement the network commissioning clusters correctly. note the lack of a Clusters::NetworkCommissioning::Instance in it, and compare to other example apps.... If it did, then none of this would be a problem.

[mustafayuce33]

@bzbarsky-apple Yes it worked well after I did all those steps that you suggested. But I did not see such a documentation which is mentioned about these steps in the documents/guides. I am curious whether I could not find it or no documentation yet at all?

And also I got a lot of errors while using run_zaptool.sh. Here are the things that I did for me to be able to use that tool which might help for the other people;

$ cd ~/dev/connectedhomeip/third_party/zap/repo
$ export NODE_OPTIONS=--openssl-legacy-provider
$ sudo apt install libcups2 libnss3 libxss1 libasound2 libatk-bridge2.0-0 libgtk-3-0 libgbm-dev
$ npm i
$ npm install keyv --save
$ unset NODE_OPTIONS
$ ./scripts/tools/zap/run_zaptool.sh 

Thanks for your fast help. I really appreciate it.

But I still did not understand in detail why this happens. Only that feature claims that device supports Thread-capable-only or not.

[bzbarsky-apple]

I am curious whether I could not find it or no documentation yet at all?

src/app/zap-templates/README.md exists, but may not be linked from anywhere useful....

But I still did not understand in detail why this happens.

The device was saying "the only networking technology I support is Thread", since it had a Network Commissioning cluster for Thread and nothing else. This didn't match what it actually supported, but it was what the commissioner had to work with....

[mustafayuce33]

@bzbarsky-apple I got it. What I understand from this is that all device(s) information are kept in Zap file(s) and we generate some source codes from that file(s). What if we want to add devices at runtime instead of doing that at build time?

[bzbarsky-apple]

Then you use dynamic endpoints.

[mustafayuce33]

ok thank you so much for your help.

[plan44]

@bzbarsky-apple is there anything planned/going on regarding more ZCL framework support for dynamic endpoints? I noticed the new dynamic-bridge-app example, but it seems there are a few points to address such as:

• enpoint numbering - the specs mandate increasing endpoint numbers for new devices (up to 65536 and only then wrapping around) and NOT re-using gaps earlier. As it is now, we can't go beyond CHIP_DEVICE_CONFIG_DYNAMIC_ENDPOINT_COUNT+FIXED_ENDPOINT_COUNT.
• endpoint numbering - current code does not allow gaps in dynamic endpoint numbering at all. I have patched this to allow it, but it would need a real solution, too. Probably an additional endpoint-ID to dynamic endpoint index mapping.
• storage of attributes for complicated clusters in dynamic endpoints, such as scenes. Re-implementing external attributes for these wastes a lot of the mechanisms already there for clusters in fixed endpoints.
• better ways to construct dynamic endpoints with variable cluster compositions than the marco solution which needs to duplicate a lot of information that is in the .zap template.

I'd prefer to invest my work in helping to extend ZCL to support dynamic storage etc. rather than in working around these limitiations in my own code too much, long term (at the moment I have to, to get my bridge running, which is OS itself on github btw).

But I bet there are already ideas around for these issues, so just starting to dig into ZCL too much without coordination probably makes not much sense, either?

[bzbarsky-apple]

@plan44 I know there are various people at Silicon Labs and Google who have been thinking about some of those issues, though the dynamic endpoint not allowing gaps bit is news to me... Please file issues so we make sure this stuff is tracked!

Past that, if you have access to the CSA Slack that's maybe the simplest place to talk to people about their plans. If not, let me know and I can look around to find people who are working in this space and point them to your issues.

[plan44]

@bzbarsky-apple Past that, if you have access to the CSA Slack that's maybe the simplest place to talk to people about their plans.

I wish I had, but IMHO that needs csa-iot membership which is prohibitively expensive for a one-person company like me, at least for now. So - unfortunately, github issues and PRs are the only channels I can use right now.

[...] though the dynamic endpoint not allowing gaps bit is news to me...

I'll rebase my patches related to the gaps in dynamic endpoints and make PRs hopefully soon - I had a few crazy weeks with very little time for matter - the one-person shop sometimes needs to make some money in between digging around in matter ;-)

[bzbarsky-apple]

@plan44 Totally understood. Again, if you file issues and @-mention me I will point people at them (hopefully with less lag... although this time of year everyone is going to be laggy due to vacations).