jonsmirl
commented
1 week ago Commission your bridge using chip-tool. Add the 10 accessories. Use chip-tool to verify they are there. Use chip-tool to remove the fabric. Put your accessories back. Finally use chip-tool to verify if the parts-lists are right. Using chip-tool to go through all of the same steps will let you see what is going on.
Esp code should automatically populate the parts-lists. But... the remove fabric step could be breaking that behavior (which would be bug). Another test would be to reboot the bridge right after you remove the fabric and see if that has any impact on Apple Home.
You need to narrow down whether the problem is in the bridge or Apple Home. chip-tool will let you do that.
It is also a known fact that both Google and Apple will mess up if you combine fixed device endpoints (root/aggregator are not device endpoints) with bridged ones on the same device. The spec allows this but Google/Apple don't have it implemented correctly. The symptom you will see is lots of disappearing endpoints.
Arbitrarily composed composite devices don't work on Google/Apple either. For example if you put a light and a temp sensor together in a composed device it won't work right on Google/Apple even though they support both the light and temp sensor when not composed.
halilakpinarr
Bug Description
We are developing a Matter Bridge. We are using ESP32 as Telemetry Ethernet. (BLE: disabled, WiFi: disabled) Our problem is; when the bridge application is erased and flashed for the first time, we can create endpoints using the "app_bridge_create_bridged_device" API as in the Zigbee Bridge Example. After the first flashing, when we pair our bridge device with Apple Home, the accessory list is visible. After the first flashing, when we pair the mobile application and bridge device with Apple Home without pairing it with "idf.py monitor" or by cutting the power and returning it, the accessory list is visible the empty in the mobile application. After pairing while the accessory list is empty, we can add new dynamic endpoints with the same API "app_bridge_create_bridged_device". In this case, for example, while 10 endpoints are actually added in the mobile application, only the last endpoint we added is visible in the mobile application.
When we first flashed frimware to the device, for example, we added 10 dynamic points and then commissioned by apple home app, saw 10 accessories in the mobile application. Then, we deleted the fabric by saying "remove device" from the Apple Home application. Then, when we put the same device back into basic commissioning mode and paired it from the mobile application, although 10 endpoints were still added, only the bridge is visible in the mobile application. Again, if I add new accessories, I can only see the ones I added while they were already paired in the mobile application.
By the way, CONFIG_ESP_MATTER_ENABLE_DATA_MODEL and CONFIG_ESP_MATTER_ENABLE_MATTER_SERVER options are enabled.
Matter endpoints should normally be in the aggregator "PartsList" section and in the "PartsList" of the Root Node. Espressif "attribute::create_parts_list(cluster, NULL, 0, 0);" has a comment line in "esp_matter_cluster.cpp" indicating that this is managed internally. I think this may be the reason why we can't see the endpoints in the mobile application despite them being created.
By the way, after installing firmware on the device, we do not do anything via mfg_tool or chip-tool. Do we need to set anything?
We are waiting for your support or suggestions for a solution.
Environment
ESP-Matter Commit Id: 186212e9c705913468c755e6d6668671c28a89a0 (latest commit now on main branch)
ESP-IDF Commit Id: v5.2.1
SoC (eg: ESP32 or ESP32-C3): ESP32
Device Logs (Please attach the log file):
Host Machine OS: Ubuntu 22.04
Home hub app and versions if present: Apple TV, Google Nest Mini