Failed to connect to Google Nest Hub 2nd Generation about stm32wb-matter-device-over-thread HOT 16 CLOSED

Hello can you try again with this log at 1 #define CHIP_DETAIL_LOGGING 1 in CHIPProjectConfig.h
Thanks
Yoann

from stm32wb-matter-device-over-thread.

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.
#define CHIP_DETAIL_LOGGING 1 was set in CHIPProjectConfig.h
Logs: stm32wb_matter_log_2.log

from stm32wb-matter-device-over-thread.

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.

from stm32wb-matter-device-over-thread.

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?

from stm32wb-matter-device-over-thread.

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.

from stm32wb-matter-device-over-thread.

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.

from stm32wb-matter-device-over-thread.

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.

from stm32wb-matter-device-over-thread.

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.

from stm32wb-matter-device-over-thread.

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

from stm32wb-matter-device-over-thread.

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

from stm32wb-matter-device-over-thread.

hello can you try with chip-tool : https://github.com/project-chip/connectedhomeip/tree/v1.0-branch with RPi + Border Router.
BR

from stm32wb-matter-device-over-thread.

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?

from stm32wb-matter-device-over-thread.

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?

from stm32wb-matter-device-over-thread.

hello, yes those logs are generated by the RTSM module. this module provides the switch between the ble ip et thread ip.

from stm32wb-matter-device-over-thread.

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?

from stm32wb-matter-device-over-thread.

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.

from stm32wb-matter-device-over-thread.