Closed Gonta01 closed 10 months ago
Hello can you try again with this log at 1 #define CHIP_DETAIL_LOGGING 1 in CHIPProjectConfig.h Thanks Yoann
In one cases device doesn't connect to Google Home. In another it could connect but without any controls available. This time device connected to Google Home but it isn't possible to control it.
Logs: stm32wb_matter_log_2.log
Hello, When you are doing the commissioning, the controller is losing the ble link with the end devices before the end of the commissioning. That why you cannot control the end device after because for him you didn t receive the commissioning complete from the controller.
Hello.
Could you please explain what logs have given you such information?
What are possible reasons of this problem and how to fix them?
Also I see in the logs the following message: CHIP:DMG: CHIP_ERROR_PERSISTED_STORAGE_NOT_FOUND
Could it be the problem also?
you have those log.
[RTSM] - BLE LL FSM 2 -> 0
[RTSM] - BLE LL FSM 2 -> 0
[RTSM] - BLE DISCONNECTION Reason : BLE_REASON_MASTER_CLOSE => Task to switch Radio
[RTSM] - TASK Trigged Switch => Radio granted to 15.4
** DISCONNECTION EVENT WITH CLIENT CHIP:DL: Gap disconnect CHIP:DL: BLE GATT connection closed (con 2049)
just before creating the SRP. The best way to solve this issue is to take a ble sniffer and check the trace. To know if it's the google home application that leave the connection or the end device that disconnect for non-reason.
CHIP:DMG: CHIP_ERROR_PERSISTED_STORAGE_NOT_FOUND => No it's good, just mean that you don t have the key in the nvm but it's normal. It's more like a check if not present matter will create it.
While using CHIP-tool the following logs occurred on CHIP-tool side:
[1689086105.840279][9838:9840] CHIP:CTL: Commissioning stage next step: 'SendAttestationRequest' -> 'AttestationVerification'
[1689086105.840301][9838:9840] CHIP:CTL: Performing next commissioning step 'AttestationVerification'
[1689086105.840313][9838:9840] CHIP:CTL: Verifying attestation
[1689086105.897140][9838:9840] CHIP:CTL: Failed in verifying 'Attestation Information' command received from the device: err 601. Look at AttestationVerificationResult enum to understand the errors
[1689086105.897212][9838:9840] CHIP:CTL: Error on commissioning step 'AttestationVerification': '../.espressif/esp-matter/connectedhomeip/connectedhomeip/examples/chip-tool/third_party/connectedhomeip/src/controller/CHIPDeviceController.cpp:1075: CHIP Error 0x000000AC: Internal error'
[1689086105.897233][9838:9840] CHIP:CTL: Failed to perform commissioning step 8
[1689086105.897255][9838:9840] CHIP:CTL: Going from commissioning step 'AttestationVerification' with lastErr = '../.espressif/esp-matter/connectedhomeip/connectedhomeip/examples/chip-tool/third_party/connectedhomeip/src/controller/CHIPDeviceController.cpp:1075: CHIP Error 0x000000AC: Internal error' -> 'Cleanup'
So there is some problem with certificates.
In CHIPProjectConfig.h file there is such lines of code:
/**
* CHIP_DEVICE_CONFIG_DEVICE_PRODUCT_ID
*
* 0x8005: example lighting app
*/
#define CHIP_DEVICE_CONFIG_DEVICE_PRODUCT_ID 0x8004
Does it mean that for Lighting app example I need to change Product Id on 0x8005? But as I see the QR code is for 0x8004 product ID.
hello, this software is compatible with matter chip-tool controller V1.0.0 and will not be compatible with other versions of chip-tool. Product_id can stay 0x8004 for a lighting application.
hello, thank you for your answers and explanations. Continue to investigate the problem and I have an assumption. Maybe the cause of the problem is that BLE and Thread for some reason can't work simultaneously on microcontroller? Radio granted to 15.4. 15.4 stands for Thread as I understand.
[RTSM] - BLE LL FSM 2 -> 0
[RTSM] - BLE LL FSM 2 -> 0
[RTSM] - BLE DISCONNECTION Reason : BLE_REASON_MASTER_CLOSE => Task to switch Radio
[RTSM] - TASK Trigged Switch => Radio granted to 15.4
The strange thing is that in some cases commissioning is successful. But still it isn't possible to control device in app. For example logs: stm32wb_matter_log_5.txt
hello can you try with chip-tool : https://github.com/project-chip/connectedhomeip/tree/v1.0-branch with RPi + Border Router. BR
Hello. Successfully commissioned device with the usage of Android chip tool from this repository. Works fine, it is possible to control LED. Another OTBR was used, not the one recommended here. stm32wb_android_chip_tool.log As it can be seen from logs BLE is off after commissioning completed.
In the case of connecting to Google Home BLE is off before commissioning finished. The problem remains. How make software of STM32WB compatible with off-the-shelf Matter commissioner like Google Nest hub?
Are these logs generated by wireless coprocessor?
[RTSM] - BLE LL FSM 2 -> 0
[RTSM] - BLE LL FSM 2 -> 0
[RTSM] - BLE DISCONNECTION Reason : BLE_REASON_MASTER_CLOSE => Task to switch Radio
[RTSM] - TASK Trigged Switch => Radio granted to 15.4
There isn't any functions that generate such logs in source files. Is this implemented in stm32wb5x_BLE_Thread_ForMatter_fw.bin
?
hello, yes those logs are generated by the RTSM module. this module provides the switch between the ble ip et thread ip.
Get it. Is it possible to figure out the reason why BLE disconnects before commissioning finished in the case of Nest hub? Or it is hidden in binary files so the reason cannot be figured out from my side?
if it s only with google. the best way would be to retrieve the google home log with adb. I think the google home app close the ble link with the end device.
Product ID (0xFFF1) and Vendor ID (0x8004) were added to Google Developer Console. During Commissioning process Blue led was turned on then turned off. Next green led was turned on. Logs: