This accessory is not responding on HomeKit based on light example (CON-576)

Hello,
In the main branch using the light example, when pairing up with HomeKit it shows This accessory is not responding.

I have tried with ESP32-PICO-MINI-02, ESP32, and ESP32C3 all had the same issue.

@law-ko Please share the logs from device, esp-idf and esp-matter commit IDs.

Also, can you try flashing light example on C3 from here: https://espressif.github.io/esp-launchpad/?solution=matter

@law-ko Please share the logs from device, esp-idf and esp-matter commit IDs.

@shubhamdp
ESP-IDF commit ID a4afa44435ef4488d018399e1de50ad2ee964be8 HEAD V5.0.1
ESP-Matter commit ID f8105768252e89dd6bd5b5bb9b0f3f2118b0edff (HEAD -> main, origin/main, origin/HEAD)
The launchpad wasn't able to connect to my ESP32.

It only supports, Google Chrome, were you using Chrome?
Also, please share the logs from device for earlier run.

@shubhamdp I am trying on Chrome with Mac and the serial port cannot be found. I've also used the same commit ID to test both ESP32 and ESP32C3 they both failed.

@shubhamdp  Here is the datalog, there is no further output after pairing with HomeKit, this is on ESP32C3 with above commit ID
I (30) boot: ESP-IDF v5.0.1 2nd stage bootloader
I (30) boot: compile time 23:12:18
I (30) boot: chip revision: v0.3
I (32) boot.esp32c3: SPI Speed      : 80MHz
I (37) boot.esp32c3: SPI Mode       : DIO
I (42) boot.esp32c3: SPI Flash Size : 4MB
I (46) boot: Enabling RNG early entropy source...
I (52) boot: Partition Table:
I (55) boot: ## Label            Usage          Type ST Offset   Length
I (63) boot:  0 esp_secure_cert  unknown          3f 06 0000d000 00002000
I (70) boot:  1 nvs              WiFi data        01 02 00010000 00006000
I (78) boot:  2 nvs_keys         NVS keys         01 04 00016000 00001000
I (85) boot:  3 otadata          OTA data         01 00 00017000 00002000
I (93) boot:  4 phy_init         RF data          01 01 00019000 00001000
I (100) boot:  5 ota_0            OTA app          00 10 00020000 001e0000
I (108) boot:  6 ota_1            OTA app          00 11 00200000 001e0000
I (115) boot:  7 fctry            WiFi data        01 02 003e0000 00006000
I (123) boot: End of partition table
I (127) boot: No factory image, trying OTA 0
I (132) esp_image: segment 0: paddr=00020020 vaddr=3c100020 size=373b0h (226224) map
I (174) esp_image: segment 1: paddr=000573d8 vaddr=3fc94200 size=03164h ( 12644) load
I (177) esp_image: segment 2: paddr=0005a544 vaddr=40380000 size=05ad4h ( 23252) load
I (184) esp_image: segment 3: paddr=00060020 vaddr=42000020 size=feb28h (1043240) map
I (345) esp_image: segment 4: paddr=0015eb50 vaddr=40385ad4 size=0e640h ( 58944) load
I (362) boot: Loaded app from partition at offset 0x20000
I (406) boot: Set actual ota_seq=1 in otadata[0]
I (406) boot: Disabling RNG early entropy source...
I (417) cpu_start: Pro cpu up.
I (427) cpu_start: Pro cpu start user code
I (427) cpu_start: cpu freq: 160000000 Hz
I (427) cpu_start: Application information:
I (430) cpu_start: Project name:     light
I (435) cpu_start: App version:      v1.0
I (439) cpu_start: Compile time:     Jun 18 2023 23:12:08
I (445) cpu_start: ELF file SHA256:  75dfa3c687d89969...
I (451) cpu_start: ESP-IDF:          v5.0.1
I (456) cpu_start: Min chip rev:     v0.3
I (461) cpu_start: Max chip rev:     v0.99
I (466) cpu_start: Chip rev:         v0.3
I (470) heap_init: Initializing. RAM available for dynamic allocation:
I (478) heap_init: At 3FCA8C30 len 00033AE0 (206 KiB): DRAM
I (484) heap_init: At 3FCDC710 len 00002950 (10 KiB): STACK/DRAM
I (491) heap_init: At 50000020 len 00001FE0 (7 KiB): RTCRAM
I (498) spi_flash: detected chip: generic
I (502) spi_flash: flash io: dio
W (506) rmt(legacy): legacy driver is deprecated, please migrate to `driver/rmt_tx.h` and/or `driver/rmt_rx.h`
I (517) coexist: coexist rom version 9387209
I (521) cpu_start: Starting scheduler.
I (530) led_driver_ws2812: Initializing light driver
I (530) gpio: GPIO[9]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
W (550) esp_matter_core: Command 0x00000047 on cluster 0x00000300 already exists. Not creating again.
I (550) app_main: Light created with endpoint_id 1
I (560) pp: pp rom version: 9387209
I (560) net80211: net80211 rom version: 9387209
I (580) wifi:wifi driver task: 3fcb4670, prio:23, stack:6656, core=0
I (580) system_api: Base MAC address is not set
I (580) system_api: read default base MAC address from EFUSE
I (580) wifi:wifi firmware version: 17afb16
I (590) wifi:wifi certification version: v7.0
I (590) wifi:config NVS flash: enabled
I (590) wifi:config nano formating: disabled
I (600) wifi:Init data frame dynamic rx buffer num: 32
I (600) wifi:Init management frame dynamic rx buffer num: 32
I (610) wifi:Init management short buffer num: 32
I (610) wifi:Init dynamic tx buffer num: 32
I (620) wifi:Init static tx FG buffer num: 2
I (620) wifi:Init static rx buffer size: 1600
I (620) wifi:Init static rx buffer num: 10
I (630) wifi:Init dynamic rx buffer num: 32
I (630) wifi_init: rx ba win: 6
I (640) wifi_init: tcpip mbox: 32
I (640) wifi_init: udp mbox: 6
I (640) wifi_init: tcp mbox: 6
I (650) wifi_init: tcp tx win: 5744
I (650) wifi_init: tcp rx win: 5744
I (660) wifi_init: tcp mss: 1440
I (660) wifi_init: WiFi IRAM OP enabled
I (660) wifi_init: WiFi RX IRAM OP enabled
I (670) chip[DL]: NVS set: chip-counters/reboot-count = 1 (0x1)
I (680) chip[DL]: NVS set: chip-counters/total-hours = 0 (0x0)
I (680) chip[DL]: NVS set: chip-config/unique-id = "C150D5903F206535"
I (690) chip[DL]: Real time clock set to 946684800 (0100/00/01 00:00:00 UTC)
I (700) BTDM_INIT: BT controller compile version [80abacd]
I (700) phy_init: phy_version 950,11a46e9,Oct 21 2022,08:56:12
W (710) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration
I (760) BTDM_INIT: Bluetooth MAC: 60:55:f9:c9:3a:5e

I (760) NimBLE: GAP procedure initiated: stop advertising.

I (760) CHIP[DL]: BLE host-controller synced
I (1260) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable)
I (1260) NimBLE: GAP procedure initiated: advertise;
I (1260) NimBLE: disc_mode=2
I (1260) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (1270) NimBLE:

I (1280) chip[DL]: CHIPoBLE advertising started
I (1280) chip[DL]: Starting ESP WiFi layer
I (1290) wifi:mode : sta (60:55:f9:c9:3a:5c)
I (1290) wifi:enable tsf
W (1290) wifi:Haven't to connect to a suitable AP now!
I (1300) chip[DL]: Done driving station state, nothing else to do...
W (1300) wifi:Haven't to connect to a suitable AP now!
I (1310) chip[DL]: Done driving station state, nothing else to do...
I (1320) chip[SVR]: Initializing subscription resumption storage...
I (1320) chip[SVR]: Server initializing...
I (1330) chip[TS]: Last Known Good Time: [unknown]
I (1330) chip[TS]: Setting Last Known Good Time to firmware build time 2023-06-18T23:16:24
I (1340) chip[DMG]: AccessControl: initializing
I (1350) chip[DMG]: Examples::AccessControlDelegate::Init
I (1350) chip[DMG]: AccessControl: setting
I (1360) chip[DMG]: DefaultAclStorage: initializing
I (1360) chip[DMG]: DefaultAclStorage: 0 entries loaded
I (1370) chip[ZCL]: Using ZAP configuration...
I (1370) esp_matter_cluster: Cluster plugin init common callback
I (1380) chip[DMG]: AccessControlCluster: initializing
I (1390) chip[ZCL]: 0x3c109940ep 0 clus 0x0000_0030 attr 0x0000_0000 not supported
I (1400) chip[ZCL]: Initiating Admin Commissioning cluster.
E (1400) chip[ZCL]: Duplicate attribute override registration failed
I (1410) chip[DIS]: Updating services using commissioning mode 1
I (1420) chip[DIS]: CHIP minimal mDNS started advertising.
I (1420) chip[DIS]: Advertise commission parameter vendorID=65521 productID=32768 discriminator=3840/15 cm=1
I (1430) chip[DIS]: CHIP minimal mDNS configured as 'Commissionable node device'; instance name: 20F789CC7262DAE3.
I (1440) chip[DIS]: mDNS service published: _matterc._udp
I (1450) chip[IN]: CASE Server enabling CASE session setups
I (1460) chip[SVR]: Joining Multicast groups
I (1460) chip[SVR]: Server Listening...
I (1470) esp_matter_core: Dynamic endpoint 0 added
I (1470) esp_matter_attribute: ********** W : Endpoint 0x0001's Cluster 0x00000003's Attribute 0x00000001 is 0 **********
I (1480) esp_matter_attribute: ********** W : Endpoint 0x0001's Cluster 0x00000004's Attribute 0x00000000 is 128 **********
I (1490) esp_matter_attribute: ********** W : Endpoint 0x0001's Cluster 0x00000004's Attribute 0x0000FFFC is <invalid type: 0> **********
I (1510) esp_matter_attribute: ********** W : Endpoint 0x0001's Cluster 0x00000005's Attribute 0x00000000 is 0 **********
I (1520) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000006's Attribute 0x0000FFFC is 1 **********
I (1530) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000006's Attribute 0x00004003 is null **********
I (1540) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000006's Attribute 0x00000000 is 1 **********
I (1550) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000006's Attribute 0x00000000 is 1 **********
I (1560) chip[ZCL]: Endpoint 1 On/off already set to new value
I (1570) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000008's Attribute 0x00000002 is 1 **********
I (1580) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000008's Attribute 0x00000003 is 254 **********
I (1590) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000008's Attribute 0x0000FFFC is 3 **********
I (1610) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000008's Attribute 0x00000000 is 64 **********
I (1620) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000008's Attribute 0x00004000 is 64 **********
I (1630) esp_matter_attribute: ********** W : Endpoint 0x0001's Cluster 0x00000008's Attribute 0x00000000 is 64 **********
I (1640) led_driver_ws2812: led set r:0, g:0, b:0
I (1650) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000300's Attribute 0x00004010 is null **********
I (1660) esp_matter_core: Dynamic endpoint 1 added
I (1670) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable)
I (1670) chip[DL]: Device already advertising, stop active advertisement and restart
I (1680) NimBLE: GAP procedure initiated: stop advertising.

E (1690) esp_matter_core: Failed to open the node nvs_namespace
I (1690) NimBLE: GAP procedure initiated: advertise;
I (1700) NimBLE: disc_mode=2
I (1700) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (1710) NimBLE:

I (1720) app_main: Commissioning window opened
I (1720) chip[DL]: WIFI_EVENT_STA_START
W (1730) wifi:Haven't to connect to a suitable AP now!
I (1730) chip[DL]: Done driving station state, nothing else to do...
I (1740) led_driver_ws2812: led set r:0, g:0, b:0
I (1740) led_driver_ws2812: led set r:0, g:0, b:0
I (1750) led_driver_ws2812: led set r:63, g:51, b:40
> I (8150) chip[DL]: BLE GAP connection established (con 1)
I (8150) chip[DL]: CHIPoBLE advertising stopped
I (9190) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (9190) chip[BLE]: local and remote recv window sizes = 5
I (9200) chip[BLE]: selected BTP version 4
I (9200) chip[BLE]: using BTP fragment sizes rx 244 / tx 244.
I (9370) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 1 ) indicate = 1
I (9370) chip[DL]: CHIPoBLE subscribe received
I (9370) NimBLE: GATT procedure initiated: indicate;
I (9380) NimBLE: att_handle=14

I (9460) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (9460) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (9480) chip[EM]: >>> [E:21678r S:0 M:158465526] (U) Msg RX from 0:B3B1DF885E6AE09F [0000] --- Type 0000:20 (SecureChannel:PBKDFParamRequest)
I (9490) chip[EM]: <<< [E:21678r S:0 M:219481722] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:21 (SecureChannel:PBKDFParamResponse)
I (9500) chip[IN]: (U) Sending msg 219481722 to IP address 'BLE'
I (9500) NimBLE: GATT procedure initiated: indicate;
I (9520) NimBLE: att_handle=14

I (9550) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (9610) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (9610) chip[EM]: >>> [E:21678r S:0 M:158465527] (U) Msg RX from 0:B3B1DF885E6AE09F [0000] --- Type 0000:22 (SecureChannel:PASE_Pake1)
I (10250) chip[EM]: <<< [E:21678r S:0 M:219481723] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:23 (SecureChannel:PASE_Pake2)
I (10260) chip[IN]: (U) Sending msg 219481723 to IP address 'BLE'
I (10270) NimBLE: GATT procedure initiated: indicate;
I (10280) NimBLE: att_handle=14

I (10360) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (10360) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (10380) chip[EM]: >>> [E:21678r S:0 M:158465528] (U) Msg RX from 0:B3B1DF885E6AE09F [0000] --- Type 0000:24 (SecureChannel:PASE_Pake3)
I (10390) chip[EM]: <<< [E:21678r S:0 M:219481724] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:40 (SecureChannel:StatusReport)
I (10400) chip[IN]: (U) Sending msg 219481724 to IP address 'BLE'
I (10400) NimBLE: GATT procedure initiated: indicate;
I (10410) NimBLE: att_handle=14

I (10420) chip[SC]: SecureSession[0x3fc9b480]: Moving from state 'kEstablishing' --> 'kActive'
I (10430) chip[SVR]: Commissioning completed session establishment step
I (10430) chip[DIS]: Updating services using commissioning mode 0
I (10440) chip[DIS]: CHIP minimal mDNS started advertising.
I (10440) chip[SVR]: Device completed Rendezvous process
I (10450) app_main: Commissioning session started
I (10460) app_main: Commissioning window closed
I (10480) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (10480) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (10500) chip[EM]: >>> [E:21679r S:60365 M:224535876] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:02 (IM:ReadRequest)
I (10510) chip[EM]: <<< [E:21679r S:60365 M:202760045] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:05 (IM:ReportData)
I (10510) chip[IN]: (S) Sending msg 202760045 on secure session with LSID: 60365
I (10530) NimBLE: GATT procedure initiated: indicate;
I (10540) NimBLE: att_handle=14

I (10570) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (10570) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (10590) chip[EM]: >>> [E:21680r S:60365 M:224535877] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:02 (IM:ReadRequest)
I (10600) chip[EM]: <<< [E:21680r S:60365 M:202760046] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:05 (IM:ReportData)
I (10600) chip[IN]: (S) Sending msg 202760046 on secure session with LSID: 60365
I (10620) NimBLE: GATT procedure initiated: indicate;
I (10630) NimBLE: att_handle=14

I (10660) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (10660) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (10680) chip[EM]: >>> [E:21681r S:60365 M:224535878] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:02 (IM:ReadRequest)
I (10690) chip[EM]: <<< [E:21681r S:60365 M:202760047] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:05 (IM:ReportData)
I (10690) chip[IN]: (S) Sending msg 202760047 on secure session with LSID: 60365
I (10710) NimBLE: GATT procedure initiated: indicate;
I (10720) NimBLE: att_handle=14

I (10750) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (10750) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (10770) chip[EM]: >>> [E:21682r S:60365 M:224535879] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:02 (IM:ReadRequest)
I (10780) chip[EM]: <<< [E:21682r S:60365 M:202760048] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:05 (IM:ReportData)
I (10780) chip[IN]: (S) Sending msg 202760048 on secure session with LSID: 60365
I (10800) NimBLE: GATT procedure initiated: indicate;
I (10810) NimBLE: att_handle=14

I (10840) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (10840) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (10860) chip[EM]: >>> [E:21683r S:60365 M:224535880] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:02 (IM:ReadRequest)
I (10870) chip[EM]: <<< [E:21683r S:60365 M:202760049] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:05 (IM:ReportData)
I (10870) chip[IN]: (S) Sending msg 202760049 on secure session with LSID: 60365
I (10890) NimBLE: GATT procedure initiated: indicate;
I (10900) NimBLE: att_handle=14

I (10930) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (10930) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (10950) chip[EM]: >>> [E:21684r S:60365 M:224535881] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:02 (IM:ReadRequest)
I (10960) chip[EM]: <<< [E:21684r S:60365 M:202760050] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:05 (IM:ReportData)
I (10960) chip[IN]: (S) Sending msg 202760050 on secure session with LSID: 60365
I (10980) NimBLE: GATT procedure initiated: indicate;
I (10990) NimBLE: att_handle=14

I (11020) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (11020) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (11040) chip[EM]: >>> [E:21685r S:60365 M:224535882] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:02 (IM:ReadRequest)
I (11050) chip[DL]: NVS set: chip-config/reg-location = 0 (0x0)
I (11050) esp_matter_attribute: ********** R : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 0 **********
I (11070) chip[EM]: <<< [E:21685r S:60365 M:202760051] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:05 (IM:ReportData)
I (11080) chip[IN]: (S) Sending msg 202760051 on secure session with LSID: 60365
I (11080) NimBLE: GATT procedure initiated: indicate;
I (11090) NimBLE: att_handle=14

I (11170) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (11170) NimBLE: GATT procedure initiated: indicate;
I (11180) NimBLE: att_handle=14

I (11230) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (11230) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (11250) chip[EM]: >>> [E:21686r S:60365 M:224535883] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (11260) esp_matter_command: Received command 0x00000000 for endpoint 0x0000's cluster 0x00000030
I (11260) chip[FS]: GeneralCommissioning: Received ArmFailSafe (60s)
I (11270) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 3 **********
I (11290) chip[EM]: <<< [E:21686r S:60365 M:202760052] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (11300) chip[IN]: (S) Sending msg 202760052 on secure session with LSID: 60365
I (11310) NimBLE: GATT procedure initiated: indicate;
I (11310) NimBLE: att_handle=14

I (11350) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (11350) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (11370) chip[EM]: >>> [E:21687r S:60365 M:224535884] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (11380) esp_matter_command: Received command 0x00000002 for endpoint 0x0000's cluster 0x00000030
I (11390) chip[DL]: NVS set: chip-config/reg-location = 0 (0x0)
I (11400) chip[DL]: NVS set: chip-config/country-code = "XX"
I (11400) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 4 **********
I (11410) chip[EM]: <<< [E:21687r S:60365 M:202760053] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (11420) chip[IN]: (S) Sending msg 202760053 on secure session with LSID: 60365
I (11430) NimBLE: GATT procedure initiated: indicate;
I (11440) NimBLE: att_handle=14

I (11500) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (11500) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (11520) chip[EM]: >>> [E:21688r S:60365 M:224535885] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (11530) esp_matter_command: Received command 0x00000002 for endpoint 0x0000's cluster 0x0000003E
I (11540) chip[ZCL]: OpCreds: Certificate Chain request received for PAI
I (11550) chip[EM]: <<< [E:21688r S:60365 M:202760054] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (11560) chip[IN]: (S) Sending msg 202760054 on secure session with LSID: 60365
I (11560) NimBLE: GATT procedure initiated: indicate;
I (11570) NimBLE: att_handle=14

I (11620) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (11620) NimBLE: GATT procedure initiated: indicate;
I (11630) NimBLE: att_handle=14

I (11740) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (11740) NimBLE: GATT procedure initiated: indicate;
I (11750) NimBLE: att_handle=14

I (11800) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (11800) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (11820) chip[EM]: >>> [E:21689r S:60365 M:224535886] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (11830) esp_matter_command: Received command 0x00000002 for endpoint 0x0000's cluster 0x0000003E
I (11840) chip[ZCL]: OpCreds: Certificate Chain request received for DAC
I (11850) chip[EM]: <<< [E:21689r S:60365 M:202760055] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (11860) chip[IN]: (S) Sending msg 202760055 on secure session with LSID: 60365
I (11860) NimBLE: GATT procedure initiated: indicate;
I (11870) NimBLE: att_handle=14

I (11920) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (11920) NimBLE: GATT procedure initiated: indicate;
I (11930) NimBLE: att_handle=14

I (12010) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (12010) NimBLE: GATT procedure initiated: indicate;
I (12020) NimBLE: att_handle=14

I (12070) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (12070) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (12090) chip[EM]: >>> [E:21690r S:60365 M:224535887] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (12100) esp_matter_command: Received command 0x00000000 for endpoint 0x0000's cluster 0x0000003E
I (12110) chip[ZCL]: OpCreds: Received an AttestationRequest command
I (12170) chip[ZCL]: OpCreds: AttestationRequest successful.
I (12180) chip[EM]: <<< [E:21690r S:60365 M:202760056] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (12190) chip[IN]: (S) Sending msg 202760056 on secure session with LSID: 60365
I (12190) NimBLE: GATT procedure initiated: indicate;
I (12200) NimBLE: att_handle=14

I (12250) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (12250) NimBLE: GATT procedure initiated: indicate;
I (12260) NimBLE: att_handle=14

I (12340) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (12340) NimBLE: GATT procedure initiated: indicate;
I (12350) NimBLE: att_handle=14

I (12430) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (12460) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (12460) chip[EM]: >>> [E:21691r S:60365 M:224535888] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (12480) esp_matter_command: Received command 0x00000000 for endpoint 0x0000's cluster 0x00000030
I (12490) chip[FS]: GeneralCommissioning: Received ArmFailSafe (60s)
I (12490) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 8 **********
I (12500) chip[EM]: <<< [E:21691r S:60365 M:202760057] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (12520) chip[IN]: (S) Sending msg 202760057 on secure session with LSID: 60365
I (12530) NimBLE: GATT procedure initiated: indicate;
I (12530) NimBLE: att_handle=14

I (12580) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (13630) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (13640) chip[EM]: >>> [E:21692r S:60365 M:224535889] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (13650) esp_matter_command: Received command 0x00000004 for endpoint 0x0000's cluster 0x0000003E
I (13660) chip[ZCL]: OpCreds: Received a CSRRequest command
I (13770) chip[ZCL]: OpCreds: AllocatePendingOperationalKey succeeded
I (13830) chip[ZCL]: OpCreds: CSRRequest successful.
I (13840) chip[EM]: <<< [E:21692r S:60365 M:202760058] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (13850) chip[IN]: (S) Sending msg 202760058 on secure session with LSID: 60365
I (13850) NimBLE: GATT procedure initiated: indicate;
I (13860) NimBLE: att_handle=14

I (13930) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (13930) NimBLE: GATT procedure initiated: indicate;
I (13940) NimBLE: att_handle=14

I (13990) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (14020) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (14080) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (14090) chip[EM]: >>> [E:21693r S:60365 M:224535890] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (14100) esp_matter_command: Received command 0x0000000B for endpoint 0x0000's cluster 0x0000003E
I (14110) chip[ZCL]: OpCreds: Received an AddTrustedRootCertificate command
I (14320) chip[ZCL]: OpCreds: AddTrustedRootCertificate successful.
I (14320) chip[EM]: <<< [E:21693r S:60365 M:202760059] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (14330) chip[IN]: (S) Sending msg 202760059 on secure session with LSID: 60365
I (14340) NimBLE: GATT procedure initiated: indicate;
I (14340) NimBLE: att_handle=14

I (14380) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (14380) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (14440) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (14450) chip[EM]: >>> [E:21694r S:60365 M:224535891] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (14460) esp_matter_command: Received command 0x00000006 for endpoint 0x0000's cluster 0x0000003E
I (14470) chip[ZCL]: OpCreds: Received an AddNOC command
I (14470) chip[FP]: Validating NOC chain
I (14680) chip[FP]: NOC chain validation successful
I (14680) chip[FP]: Added new fabric at index: 0x1
I (14680) chip[FP]: Assigned compressed fabric ID: 0x638C92F1B94D5355, node ID: 0x000000004974C1F1
I (14690) chip[TS]: Last Known Good Time: 2023-06-18T23:16:24
I (14700) chip[TS]: New proposed Last Known Good Time: 2023-06-19T06:57:47
I (14700) chip[TS]: Updating pending Last Known Good Time to 2023-06-19T06:57:47
I (14720) chip[ZCL]: OpCreds: ACL entry created for Fabric index 0x1 CASE Admin Subject 0x665071AB2A2908C9
I (14720) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (14740) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (14750) chip[DIS]: mDNS service published: _matter._tcp
I (14750) chip[ZCL]: OpCreds: successfully created fabric index 0x1 via AddNOC
I (14760) chip[EM]: <<< [E:21694r S:60365 M:202760060] (S) Msg TX to 1:FFFFFFFB00000000 [5355] --- Type 0001:09 (IM:InvokeCommandResponse)
I (14770) chip[IN]: (S) Sending msg 202760060 on secure session with LSID: 60365
I (14790) NimBLE: GATT procedure initiated: indicate;
I (14790) NimBLE: att_handle=14

I (14790) app_main: Fabric is updated
I (14830) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (14830) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (14850) chip[EM]: >>> [E:21695r S:60365 M:224535892] (S) Msg RX from 1:FFFFFFFB00000000 [5355] --- Type 0001:08 (IM:InvokeCommandRequest)
I (14860) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 14 **********
I (14870) chip[EM]: <<< [E:21695r S:60365 M:202760061] (S) Msg TX to 1:FFFFFFFB00000000 [5355] --- Type 0001:09 (IM:InvokeCommandResponse)
I (14890) chip[IN]: (S) Sending msg 202760061 on secure session with LSID: 60365
I (14890) NimBLE: GATT procedure initiated: indicate;
I (14900) NimBLE: att_handle=14

I (14950) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (14950) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (14970) chip[EM]: >>> [E:21696r S:60365 M:224535893] (S) Msg RX from 1:FFFFFFFB00000000 [5355] --- Type 0001:08 (IM:InvokeCommandRequest)
I (14980) chip[NP]: ESP NetworkCommissioningDelegate: SSID: PandaBun
W (14980) wifi:Haven't to connect to a suitable AP now!
I (14990) chip[DL]: WiFi station mode change: Enabled -> Disabled
I (15000) chip[DL]: WiFi station mode change: Disabled -> Enabled
W (15010) wifi:Haven't to connect to a suitable AP now!
I (15010) chip[DL]: Attempting to connect WiFi station interface
I (15020) chip[DL]: WiFi station state change: NotConnected -> Connecting
I (15020) chip[DL]: Done driving station state, nothing else to do...
W (15030) wifi:Haven't to connect to a suitable AP now!
I (15030) chip[DL]: Attempting to connect WiFi station interface
E (15050) wifi:sta is connecting, return error
E (15050) chip[DL]: esp_wifi_connect() failed: ESP_ERR_WIFI_CONN
W (15060) wifi:Haven't to connect to a suitable AP now!
I (15060) chip[DL]: Attempting to connect WiFi station interface
E (15070) wifi:sta is connecting, return error
E (15070) chip[DL]: esp_wifi_connect() failed: ESP_ERR_WIFI_CONN
W (15070) wifi:Haven't to connect to a suitable AP now!
E (15080) chip[DL]: Failed to get configured network when updating network status: Error ESP32:0x0500300F
I (17430) wifi:new:<11,0>, old:<1,0>, ap:<255,255>, sta:<11,0>, prof:1
I (18040) NimBLE: GATT procedure initiated: indicate;
I (18040) NimBLE: att_handle=14

I (18050) wifi:state: init -> auth (b0)
I (18130) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (19050) wifi:state: auth -> init (200)
I (19050) wifi:new:<11,0>, old:<11,0>, ap:<255,255>, sta:<11,0>, prof:1
I (19050) chip[DL]: WIFI_EVENT_STA_DISCONNECTED
I (19060) chip[DL]: WiFi station state change: Connecting -> Connecting_Failed
W (19060) wifi:Haven't to connect to a suitable AP now!
I (19080) chip[DL]: WiFi station state change: Connecting_Failed -> NotConnected
I (19080) chip[DL]: Next WiFi station reconnect in 100 ms
I (19090) chip[DL]: Done driving station state, nothing else to do...
W (19090) wifi:Haven't to connect to a suitable AP now!
E (19100) chip[DL]: Failed to get configured network when updating network status: Error ESP32:0x0500300F
W (19100) wifi:Haven't to connect to a suitable AP now!
E (19110) chip[DL]: Failed to get configured network when updating network status: Error ESP32:0x0500300F
W (19190) wifi:Haven't to connect to a suitable AP now!
I (19190) chip[DL]: Attempting to connect WiFi station interface
I (19190) chip[DL]: WiFi station state change: NotConnected -> Connecting
I (19200) chip[DL]: Done driving station state, nothing else to do...
W (19200) wifi:Haven't to connect to a suitable AP now!
E (19220) chip[DL]: Failed to get configured network when updating network status: Error ESP32:0x0500300F
I (20620) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (22570) chip[DL]: WIFI_EVENT_STA_DISCONNECTED
I (22570) chip[DL]: WiFi station state change: Connecting -> Connecting_Failed
W (22580) wifi:Haven't to connect to a suitable AP now!
I (22580) chip[DL]: WiFi station state change: Connecting_Failed -> NotConnected
I (22590) chip[DL]: Next WiFi station reconnect in 100 ms
I (22590) chip[DL]: Done driving station state, nothing else to do...
W (22600) wifi:Haven't to connect to a suitable AP now!
E (22610) chip[DL]: Failed to get configured network when updating network status: Error ESP32:0x0500300F
W (22620) wifi:Haven't to connect to a suitable AP now!
E (22620) chip[DL]: Failed to get configured network when updating network status: Error ESP32:0x0500300F
W (22690) wifi:Haven't to connect to a suitable AP now!
I (22690) chip[DL]: Attempting to connect WiFi station interface
I (22700) chip[DL]: WiFi station state change: NotConnected -> Connecting
I (22710) chip[DL]: Done driving station state, nothing else to do...
I (22700) wifi:new:<11,0>, old:<11,0>, ap:<255,255>, sta:<11,0>, prof:1
I (22720) wifi:state: init -> auth (b0)
I (22720) wifi:state: auth -> assoc (0)
I (22730) wifi:state: assoc -> run (10)
I (22750) wifi:connected with PandaBun, aid = 1, channel 11, BW20, bssid = c0:56:27:32:f5:87
I (22760) wifi:security: WPA2-PSK, phy: bgn, rssi: -28
I (22780) wifi:pm start, type: 1

I (22780) wifi:set rx beacon pti, rx_bcn_pti: 14, bcn_timeout: 14, mt_pti: 25000, mt_time: 10000
I (22780) chip[DL]: WIFI_EVENT_STA_CONNECTED
I (22790) chip[DL]: WiFi station state change: Connecting -> Connecting_Succeeded
I (22790) wifi:<ba-add>idx:0 (ifx:0, c0:56:27:32:f5:87), tid:6, ssn:2, winSize:64
I (22810) chip[DL]: WiFi station state change: Connecting_Succeeded -> Connected
I (22810) chip[DL]: WiFi station interface connected
I (22810) wifi:AP's beacon interval = 102400 us, DTIM period = 1
I (22820) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 16 **********
I (22840) chip[EM]: <<< [E:21696r S:60365 M:202760062] (S) Msg TX to 1:FFFFFFFB00000000 [5355] --- Type 0001:09 (IM:InvokeCommandResponse)
I (22850) chip[IN]: (S) Sending msg 202760062 on secure session with LSID: 60365
I (22860) NimBLE: GATT procedure initiated: indicate;
I (22860) NimBLE: att_handle=14

I (22860) chip[ZCL]: WiFiDiagnosticsDelegate: OnConnectionStatusChanged
I (22870) chip[DL]: Done driving station state, nothing else to do...
I (22880) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (22890) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (22900) chip[DIS]: mDNS service published: _matter._tcp
I (22900) chip[SVR]: Operational advertising enabled
I (22910) chip[DL]: Updating advertising data
I (22900) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (23780) esp_netif_handlers: sta ip: <IP_ADDRESS>, mask: <IP_ADDRESS>, gw: <IP_ADDRESS>
I (23780) chip[DL]: IP_EVENT_STA_GOT_IP
I (23780) chip[DL]: IPv4 address changed on WiFi station interface: <IP_ADDRESS>/<IP_ADDRESS> gateway <IP_ADDRESS>
I (23790) chip[DL]: IPv4 Internet connectivity ESTABLISHED
I (23800) app_main: Interface IP Address changed
I (23800) chip[DIS]: Updating services using commissioning mode 0
I (23810) chip[DIS]: CHIP minimal mDNS started advertising.
I (23820) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (23830) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (23840) chip[DIS]: mDNS service published: _matter._tcp
I (23960) wifi:<ba-add>idx:1 (ifx:0, c0:56:27:32:f5:87), tid:0, ssn:0, winSize:64
I (23960) chip[EM]: >>> [E:21697r S:0 M:158465529] (U) Msg RX from 0:F5D927D7DD63D669 [0000] --- Type 0000:30 (SecureChannel:CASE_Sigma1)
I (23980) chip[IN]: CASE Server received Sigma1 message . Starting handshake. EC 0x3fc9cd38
I (23990) chip[IN]: CASE Server disabling CASE session setups
I (23990) chip[EM]: <<< [E:21697r S:0 M:219481725 (Ack:158465529)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (24000) chip[IN]: (U) Sending msg 219481725 to IP address 'UDP:<IP_ADDRESS>%st1:51725'
I (24020) chip[SC]: Received Sigma1 msg
I (24020) chip[SC]: CASE matched destination ID: fabricIndex 1, NodeID 0x000000004974C1F1
I (24290) chip[EM]: <<< [E:21697r S:0 M:219481726 (Ack:158465529)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:31 (SecureChannel:CASE_Sigma2)
I (24300) chip[IN]: (U) Sending msg 219481726 to IP address 'UDP:<IP_ADDRESS>%st1:51725'
I (24300) chip[SC]: Sent Sigma2 msg
I (24470) chip[EM]: >>> [E:21697r S:0 M:158465529] (U) Msg RX from 0:F5D927D7DD63D669 [0000] --- Type 0000:30 (SecureChannel:CASE_Sigma1)
I (24480) chip[EM]: <<< [E:21697r S:0 M:219481727 (Ack:158465529)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (24490) chip[IN]: (U) Sending msg 219481727 to IP address 'UDP:<IP_ADDRESS>%st1:51725'
I (24560) chip[DL]: IP_EVENT_GOT_IP6
I (24560) chip[DL]: IPv6 addr available. Ready on WIFI_STA_DEF interface: fe80:0000:0000:0000:6255:f9ff:fec9:3a5c
I (24570) app_main: Interface IP Address changed
I (24570) chip[DIS]: Updating services using commissioning mode 0
I (24580) chip[DIS]: CHIP minimal mDNS started advertising.
I (24590) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (24590) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (24610) chip[DIS]: mDNS service published: _matter._tcp
E (24610) chip[SVR]: Server initialization complete
I (24620) chip[DIS]: Updating services using commissioning mode 0
I (24630) chip[DIS]: CHIP minimal mDNS started advertising.
I (24640) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (24640) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (24650) chip[DIS]: mDNS service published: _matter._tcp
I (24660) chip[IM]: No subscriptions to resume
I (24670) chip[EM]: >>> [E:21697r S:0 M:158465530 (Ack:219481726)] (U) Msg RX from 0:F5D927D7DD63D669 [0000] --- Type 0000:32 (SecureChannel:CASE_Sigma3)
I (24680) chip[EM]: <<< [E:21697r S:0 M:219481728 (Ack:158465530)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (24690) chip[IN]: (U) Sending msg 219481728 to IP address 'UDP:<IP_ADDRESS>%st1:51725'
I (24700) chip[SC]: Received Sigma3 msg
E (24710) chip[SC]: The device does not support GetClock_RealTimeMS() API: 6c.  Falling back to Last Known Good UTC Time
I (25130) chip[EM]: <<< [E:21697r S:0 M:219481729 (Ack:158465530)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:40 (SecureChannel:StatusReport)
I (25140) chip[IN]: (U) Sending msg 219481729 to IP address 'UDP:<IP_ADDRESS>%st1:51725'
I (25150) chip[SC]: SecureSession[0x3fc9b538]: Moving from state 'kEstablishing' --> 'kActive'
I (25160) chip[IN]: CASE Session established to peer: <665071AB2A2908C9, 1>
I (25170) chip[IN]: CASE Server enabling CASE session setups
I (25180) chip[EM]: >>> [E:21698r S:60366 M:234345074] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:08 (IM:InvokeCommandRequest)
I (25190) esp_matter_command: Received command 0x00000004 for endpoint 0x0000's cluster 0x00000030
I (25190) chip[FS]: GeneralCommissioning: Received CommissioningComplete
I (25210) chip[FP]: Metadata for Fabric 0x1 persisted to storage.
I (25220) chip[TS]: Committing Last Known Good Time to storage: 2023-06-19T06:57:47
I (25220) chip[ZCL]: OpCreds: Fabric index 0x1 was committed to storage. Compressed Fabric Id 0x638C92F1B94D5355, FabricId<PHONE_NUMBER>000003, NodeId<PHONE_NUMBER>74C1F1, VendorId 0x1349
I (25240) chip[FS]: GeneralCommissioning: Successfully commited pending fabric data
I (25250) chip[FS]: Fail-safe cleanly disarmed
I (25250) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 0 **********
I (25260) chip[EM]: <<< [E:21698r S:60366 M:260988910 (Ack:234345074)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:09 (IM:InvokeCommandResponse)
I (25280) chip[IN]: (S) Sending msg 260988910 on secure session with LSID: 60366
I (25290) chip[EM]: >>> [E:21697r S:0 M:158465531 (Ack:219481729)] (U) Msg RX from 0:F5D927D7DD63D669 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (25300) app_main: Fabric is committed
I (25300) chip[SVR]: Commissioning completed successfully
I (25300) chip[DIS]: Updating services using commissioning mode 0
I (25320) chip[DIS]: CHIP minimal mDNS started advertising.
I (25330) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (25330) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (25340) chip[DIS]: mDNS service published: _matter._tcp
I (25350) chip[SC]: SecureSession[0x3fc9b480]: Moving from state 'kActive' --> 'kPendingEviction'
I (25360) chip[BLE]: Releasing end point's BLE connection back to application.
I (25370) app_main: Commissioning complete
I (25370) esp_matter_core: Commissioning Complete
I (25370) app_main: Commissioning window closed
I (25380) chip[EM]: >>> [E:21698r S:60366 M:234345075 (Ack:260988910)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (25400) chip[EM]: >>> [E:21699r S:60366 M:234345076] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (25410) chip[EM]: <<< [E:21699r S:60366 M:260988911 (Ack:234345076)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (25430) chip[IN]: (S) Sending msg 260988911 on secure session with LSID: 60366
I (25360) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 1 ) indicate = 0
I (25440) chip[DL]: CHIPoBLE unsubscribe received
I (25440) chip[DL]: BLE GAP connection terminated (con 1 reason 0x213)
E (25440) chip[BLE]: no endpoint for unsub recvd
I (25450) NimBLE: GAP procedure initiated: stop advertising.

I (25470) esp_matter_core: BLE deinit successful and memory reclaimed
I (25530) chip[EM]: >>> [E:21699r S:60366 M:234345077 (Ack:260988911)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (25790) chip[EM]: >>> [E:21700r S:60366 M:234345078] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (25790) chip[EM]: <<< [E:21700r S:60366 M:260988912 (Ack:234345078)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (25800) chip[IN]: (S) Sending msg 260988912 on secure session with LSID: 60366
I (25990) chip[EM]: >>> [E:21700r S:60366 M:234345079 (Ack:260988912)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26010) chip[EM]: >>> [E:21701r S:60366 M:234345080] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26020) chip[EM]: <<< [E:21701r S:60366 M:260988913 (Ack:234345080)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26030) chip[IN]: (S) Sending msg 260988913 on secure session with LSID: 60366
I (26060) chip[EM]: >>> [E:21701r S:60366 M:234345081 (Ack:260988913)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26070) chip[EM]: >>> [E:21702r S:60366 M:234345082] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26090) chip[EM]: <<< [E:21702r S:60366 M:260988914 (Ack:234345082)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26100) chip[IN]: (S) Sending msg 260988914 on secure session with LSID: 60366
I (26300) chip[EM]: >>> [E:21702r S:60366 M:234345083 (Ack:260988914)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26310) chip[EM]: >>> [E:21703r S:60366 M:234345084] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26330) chip[EM]: <<< [E:21703r S:60366 M:260988915 (Ack:234345084)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26340) chip[IN]: (S) Sending msg 260988915 on secure session with LSID: 60366
I (26380) chip[EM]: >>> [E:21703r S:60366 M:234345085 (Ack:260988915)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26400) chip[EM]: >>> [E:21704r S:60366 M:234345086] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26410) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000008's Attribute 0x0000FFFC is 3 **********
I (26410) chip[EM]: <<< [E:21704r S:60366 M:260988916 (Ack:234345086)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26430) chip[IN]: (S) Sending msg 260988916 on secure session with LSID: 60366
I (26450) chip[EM]: >>> [E:21704r S:60366 M:234345087 (Ack:260988916)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26460) chip[EM]: >>> [E:21705r S:60366 M:234345088] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26480) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000300's Attribute 0x0000FFFC is 24 **********
I (26480) chip[EM]: <<< [E:21705r S:60366 M:260988917 (Ack:234345088)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26490) chip[IN]: (S) Sending msg 260988917 on secure session with LSID: 60366
I (26510) chip[EM]: >>> [E:21705r S:60366 M:234345089 (Ack:260988917)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26530) chip[EM]: >>> [E:21706r S:60366 M:234345090] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26540) esp_matter_attribute: ********** R : Endpoint 0x0001's Cluster 0x00000006's Attribute 0x0000FFFC is 1 **********
I (26550) chip[EM]: <<< [E:21706r S:60366 M:260988918 (Ack:234345090)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26560) chip[IN]: (S) Sending msg 260988918 on secure session with LSID: 60366
I (26580) chip[EM]: >>> [E:21706r S:60366 M:234345091 (Ack:260988918)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26590) chip[EM]: >>> [E:21707r S:60366 M:234345092] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26610) chip[EM]: <<< [E:21707r S:60366 M:260988919 (Ack:234345092)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26620) chip[IN]: (S) Sending msg 260988919 on secure session with LSID: 60366
I (26630) chip[EM]: >>> [E:21707r S:60366 M:234345093 (Ack:260988919)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26650) chip[EM]: >>> [E:21708r S:60366 M:234345094] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26660) chip[EM]: >>> [E:21709r S:60366 M:234345095] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26670) chip[EM]: <<< [E:21708r S:60366 M:260988920 (Ack:234345094)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26680) chip[IN]: (S) Sending msg 260988920 on secure session with LSID: 60366
I (26690) chip[EM]: <<< [E:21709r S:60366 M:260988921 (Ack:234345095)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26710) chip[IN]: (S) Sending msg 260988921 on secure session with LSID: 60366
I (26710) chip[EM]: >>> [E:21708r S:60366 M:234345096 (Ack:260988920)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26720) chip[EM]: >>> [E:21709r S:60366 M:234345097 (Ack:260988921)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26740) chip[EM]: >>> [E:21710r S:60366 M:234345098] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:02 (IM:ReadRequest)
I (26750) chip[EM]: <<< [E:21710r S:60366 M:260988922 (Ack:234345098)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:05 (IM:ReportData)
I (26770) chip[IN]: (S) Sending msg 260988922 on secure session with LSID: 60366
I (26790) chip[EM]: >>> [E:21710r S:60366 M:234345099 (Ack:260988922)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (26910) chip[EM]: >>> [E:21711r S:60366 M:234345100] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:0a (IM:TimedRequest)
I (26920) chip[EM]: <<< [E:21711r S:60366 M:260988923 (Ack:234345100)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:01 (IM:StatusResponse)
I (26930) chip[IN]: (S) Sending msg 260988923 on secure session with LSID: 60366
I (26950) chip[EM]: >>> [E:21711r S:60366 M:234345101 (Ack:260988923)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0001:08 (IM:InvokeCommandRequest)
I (26970) esp_matter_command: Received command 0x00000000 for endpoint 0x0000's cluster 0x0000003C
I (26970) chip[ZCL]: Received command to open commissioning window
I (26980) chip[DIS]: Updating services using commissioning mode 2
I (26980) chip[DIS]: CHIP minimal mDNS started advertising.
I (27000) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (27000) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (27020) chip[DIS]: mDNS service published: _matter._tcp
I (27020) chip[DIS]: Advertise commission parameter vendorID=65521 productID=32768 discriminator=0584/02 cm=2
I (27030) chip[DIS]: CHIP minimal mDNS configured as 'Commissionable node device'; instance name: F1592B75BD6E7D39.
I (27060) chip[DIS]: mDNS service published: _matterc._udp
I (27060) chip[ZCL]: Commissioning window is now open
I (27060) chip[EM]: <<< [E:21711r S:60366 M:260988924 (Ack:234345101)] (S) Msg TX to 1:665071AB2A2908C9 [5355] --- Type 0001:09 (IM:InvokeCommandResponse)
I (27080) chip[IN]: (S) Sending msg 260988924 on secure session with LSID: 60366
I (27090) app_main: Commissioning window opened
I (27100) chip[EM]: >>> [E:21711r S:60366 M:234345102 (Ack:260988924)] (S) Msg RX from 1:665071AB2A2908C9 [5355] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (33670) chip[EM]: >>> [E:56403r S:0 M:156920691] (U) Msg RX from 0:BEC1ED6EE58DC7BC [0000] --- Type 0000:20 (SecureChannel:PBKDFParamRequest)
I (33680) chip[EM]: <<< [E:56403r S:0 M:219481730 (Ack:156920691)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (33700) chip[IN]: (U) Sending msg 219481730 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (33700) chip[EM]: <<< [E:56403r S:0 M:219481731 (Ack:156920691)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:21 (SecureChannel:PBKDFParamResponse)
I (33710) chip[IN]: (U) Sending msg 219481731 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (34080) chip[EM]: >>> [E:56403r S:0 M:156920692 (Ack:219481731)] (U) Msg RX from 0:BEC1ED6EE58DC7BC [0000] --- Type 0000:22 (SecureChannel:PASE_Pake1)
I (34090) chip[EM]: <<< [E:56403r S:0 M:219481732 (Ack:156920692)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (34100) chip[IN]: (U) Sending msg 219481732 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (34730) chip[EM]: <<< [E:56403r S:0 M:219481733 (Ack:156920692)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:23 (SecureChannel:PASE_Pake2)
I (34740) chip[IN]: (U) Sending msg 219481733 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (35100) chip[EM]: >>> [E:56403r S:0 M:156920693 (Ack:219481733)] (U) Msg RX from 0:BEC1ED6EE58DC7BC [0000] --- Type 0000:24 (SecureChannel:PASE_Pake3)
I (35120) chip[EM]: <<< [E:56403r S:0 M:219481734 (Ack:156920693)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35130) chip[IN]: (U) Sending msg 219481734 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (35130) chip[EM]: <<< [E:56403r S:0 M:219481735 (Ack:156920693)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:40 (SecureChannel:StatusReport)
I (35150) chip[IN]: (U) Sending msg 219481735 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (35160) chip[SC]: SecureSession[0x3fc9b480]: Moving from state 'kEstablishing' --> 'kActive'
I (35170) chip[SVR]: Commissioning completed session establishment step
I (35170) chip[DIS]: Updating services using commissioning mode 0
I (35190) chip[DIS]: CHIP minimal mDNS started advertising.
I (35210) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (35210) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (35230) chip[DIS]: mDNS service published: _matter._tcp
I (35230) chip[SVR]: Device completed Rendezvous process
I (35240) chip[EM]: >>> [E:56403r S:0 M:156920694 (Ack:219481735)] (U) Msg RX from 0:BEC1ED6EE58DC7BC [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35260) chip[EM]: >>> [E:56404r S:60368 M:27493959] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:02 (IM:ReadRequest)
I (35270) app_main: Commissioning session started
I (35270) app_main: Commissioning window closed
I (35280) esp_matter_attribute: ********** R : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 0 **********
I (35290) chip[EM]: <<< [E:56404r S:60368 M:91449959 (Ack:27493959)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:05 (IM:ReportData)
I (35300) chip[IN]: (S) Sending msg 91449959 on secure session with LSID: 60368
I (35330) chip[EM]: >>> [E:56405r S:60368 M:27493960] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (35340) esp_matter_command: Received command 0x00000000 for endpoint 0x0000's cluster 0x00000030
I (35350) chip[FS]: GeneralCommissioning: Received ArmFailSafe (60s)
I (35360) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 3 **********
I (35370) chip[EM]: <<< [E:56405r S:60368 M:91449960 (Ack:27493960)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (35380) chip[IN]: (S) Sending msg 91449960 on secure session with LSID: 60368
I (35390) chip[EM]: >>> [E:56404r S:60368 M:27493961 (Ack:91449959)] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35400) chip[EM]: >>> [E:56406r S:60368 M:27493962] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (35420) esp_matter_command: Received command 0x00000002 for endpoint 0x0000's cluster 0x00000030
I (35430) chip[DL]: NVS set: chip-config/reg-location = 0 (0x0)
I (35430) chip[DL]: NVS set: chip-config/country-code = "XX"
I (35440) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 4 **********
I (35450) chip[EM]: <<< [E:56406r S:60368 M:91449961 (Ack:27493962)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (35470) chip[IN]: (S) Sending msg 91449961 on secure session with LSID: 60368
I (35480) chip[EM]: >>> [E:56405r S:60368 M:27493963 (Ack:91449960)] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35500) chip[EM]: >>> [E:56407r S:60368 M:27493964] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (35510) esp_matter_command: Received command 0x00000002 for endpoint 0x0000's cluster 0x0000003E
I (35510) chip[ZCL]: OpCreds: Certificate Chain request received for PAI
I (35530) chip[EM]: <<< [E:56407r S:60368 M:91449962 (Ack:27493964)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (35540) chip[IN]: (S) Sending msg 91449962 on secure session with LSID: 60368
I (35540) chip[EM]: >>> [E:56406r S:60368 M:27493965 (Ack:91449961)] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35560) chip[EM]: >>> [E:56408r S:60368 M:27493966] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (35570) esp_matter_command: Received command 0x00000002 for endpoint 0x0000's cluster 0x0000003E
I (35580) chip[ZCL]: OpCreds: Certificate Chain request received for DAC
I (35590) chip[EM]: <<< [E:56408r S:60368 M:91449963 (Ack:27493966)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (35600) chip[IN]: (S) Sending msg 91449963 on secure session with LSID: 60368
I (35610) chip[EM]: >>> [E:56407r S:60368 M:27493967 (Ack:91449962)] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35630) chip[EM]: >>> [E:56409r S:60368 M:27493968] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (35640) esp_matter_command: Received command 0x00000000 for endpoint 0x0000's cluster 0x0000003E
I (35640) chip[ZCL]: OpCreds: Received an AttestationRequest command
I (35660) chip[EM]: <<< [E:56409r S:60368 M:91449964 (Ack:27493968)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35670) chip[IN]: (S) Sending msg 91449964 on secure session with LSID: 60368
I (35740) chip[ZCL]: OpCreds: AttestationRequest successful.
I (35750) chip[EM]: <<< [E:56409r S:60368 M:91449965 (Ack:27493968)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (35760) chip[IN]: (S) Sending msg 91449965 on secure session with LSID: 60368
I (35760) chip[EM]: >>> [E:56408r S:60368 M:27493969 (Ack:91449963)] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35810) chip[EM]: >>> [E:56410r S:60368 M:27493970] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (35820) esp_matter_command: Received command 0x00000000 for endpoint 0x0000's cluster 0x00000030
I (35820) chip[FS]: GeneralCommissioning: Received ArmFailSafe (60s)
I (35830) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 8 **********
I (35850) chip[EM]: <<< [E:56410r S:60368 M:91449966 (Ack:27493970)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (35860) chip[IN]: (S) Sending msg 91449966 on secure session with LSID: 60368
I (35860) chip[EM]: >>> [E:56409r S:60368 M:27493971 (Ack:91449965)] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35880) chip[EM]: >>> [E:56410r S:60368 M:27493972 (Ack:91449966)] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35890) chip[EM]: >>> [E:56411r S:60368 M:27493973] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (35910) esp_matter_command: Received command 0x00000004 for endpoint 0x0000's cluster 0x0000003E
I (35920) chip[ZCL]: OpCreds: Received a CSRRequest command
I (35920) chip[EM]: <<< [E:56411r S:60368 M:91449967 (Ack:27493973)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (35940) chip[IN]: (S) Sending msg 91449967 on secure session with LSID: 60368
I (36060) chip[ZCL]: OpCreds: AllocatePendingOperationalKey succeeded
I (36120) chip[ZCL]: OpCreds: CSRRequest successful.
I (36120) chip[EM]: <<< [E:56411r S:60368 M:91449968 (Ack:27493973)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (36130) chip[IN]: (S) Sending msg 91449968 on secure session with LSID: 60368
I (36180) chip[EM]: >>> [E:56412r S:60368 M:27493974] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (36200) esp_matter_command: Received command 0x0000000B for endpoint 0x0000's cluster 0x0000003E
I (36200) chip[ZCL]: OpCreds: Received an AddTrustedRootCertificate command
I (36210) chip[EM]: <<< [E:56412r S:60368 M:91449969 (Ack:27493974)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (36220) chip[IN]: (S) Sending msg 91449969 on secure session with LSID: 60368
I (36440) chip[ZCL]: OpCreds: AddTrustedRootCertificate successful.
I (36440) chip[EM]: <<< [E:56412r S:60368 M:91449970 (Ack:27493974)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (36460) chip[IN]: (S) Sending msg 91449970 on secure session with LSID: 60368
I (36470) chip[EM]: >>> [E:56411r S:60368 M:27493975 (Ack:91449968)] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (36480) chip[EM]: >>> [E:56413r S:60368 M:27493976] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (36500) esp_matter_command: Received command 0x00000006 for endpoint 0x0000's cluster 0x0000003E
I (36500) chip[ZCL]: OpCreds: Received an AddNOC command
I (36510) chip[EM]: <<< [E:56413r S:60368 M:91449971 (Ack:27493976)] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (36520) chip[IN]: (S) Sending msg 91449971 on secure session with LSID: 60368
I (36530) chip[FP]: Validating NOC chain
I (36740) chip[FP]: NOC chain validation successful
I (36740) chip[FP]: Added new fabric at index: 0x2
I (36740) chip[FP]: Assigned compressed fabric ID: 0x0459C5EAC7ADA78D, node ID: 0x000000004AD8F3A3
I (36760) chip[TS]: Last Known Good Time: 2023-06-19T06:57:47
I (36770) chip[TS]: New proposed Last Known Good Time: 2023-06-19T06:58:09
I (36770) chip[TS]: Updating pending Last Known Good Time to 2023-06-19T06:58:09
I (36790) chip[ZCL]: OpCreds: ACL entry created for Fabric index 0x2 CASE Admin Subject 0x491622BAC79E9642
I (36790) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (36800) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (36820) chip[DIS]: mDNS service published: _matter._tcp
I (36820) chip[DIS]: Advertise operational node 0459C5EAC7ADA78D-000000004AD8F3A3
I (36830) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 0459C5EAC7ADA78D-000000004AD8F3A3.
I (36850) chip[DIS]: mDNS service published: _matter._tcp
I (36850) chip[ZCL]: OpCreds: successfully created fabric index 0x2 via AddNOC
I (36870) chip[EM]: <<< [E:56413r S:60368 M:91449972 (Ack:27493976)] (S) Msg TX to 2:FFFFFFFB00000000 [A78D] --- Type 0001:09 (IM:InvokeCommandResponse)
I (36880) chip[IN]: (S) Sending msg 91449972 on secure session with LSID: 60368
I (36880) chip[EM]: >>> [E:56412r S:60368 M:27493977 (Ack:91449970)] (S) Msg RX from 2:FFFFFFFB00000000 [A78D] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (36900) app_main: Fabric is updated
I (37050) chip[EM]: >>> [E:56413r S:60368 M:27493978 (Ack:91449972)] (S) Msg RX from 2:FFFFFFFB00000000 [A78D] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (43500) chip[EM]: >>> [E:56415r S:0 M:156920696] (U) Msg RX from 0:766752F722F26FD1 [0000] --- Type 0000:30 (SecureChannel:CASE_Sigma1)
I (43510) chip[IN]: CASE Server received Sigma1 message . Starting handshake. EC 0x3fc9cd38
I (43510) chip[IN]: CASE Server disabling CASE session setups
I (43530) chip[EM]: <<< [E:56415r S:0 M:219481736 (Ack:156920696)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (43540) chip[IN]: (U) Sending msg 219481736 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (43550) chip[SC]: Received Sigma1 msg
I (43560) chip[SC]: CASE matched destination ID: fabricIndex 2, NodeID 0x000000004AD8F3A3
I (43810) chip[EM]: <<< [E:56415r S:0 M:219481737 (Ack:156920696)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:31 (SecureChannel:CASE_Sigma2)
I (43830) chip[IN]: (U) Sending msg 219481737 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (43830) chip[SC]: Sent Sigma2 msg
I (44010) chip[EM]: >>> [E:56415r S:0 M:156920697 (Ack:219481737)] (U) Msg RX from 0:766752F722F26FD1 [0000] --- Type 0000:32 (SecureChannel:CASE_Sigma3)
I (44030) chip[EM]: <<< [E:56415r S:0 M:219481738 (Ack:156920697)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (44040) chip[IN]: (U) Sending msg 219481738 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (44040) chip[SC]: Received Sigma3 msg
E (44060) chip[SC]: The device does not support GetClock_RealTimeMS() API: 6c.  Falling back to Last Known Good UTC Time
I (44470) chip[EM]: <<< [E:56415r S:0 M:219481739 (Ack:156920697)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:40 (SecureChannel:StatusReport)
I (44480) chip[IN]: (U) Sending msg 219481739 to IP address 'UDP:<IP_ADDRESS>%st1:60631'
I (44490) chip[SC]: SecureSession[0x3fc9b5f0]: Moving from state 'kEstablishing' --> 'kActive'
I (44500) chip[IN]: CASE Session established to peer: <491622BAC79E9642, 2>
I (44500) chip[IN]: CASE Server enabling CASE session setups
I (44510) chip[EM]: >>> [E:56416r S:60367 M:174668872] (S) Msg RX from 2:491622BAC79E9642 [A78D] --- Type 0001:08 (IM:InvokeCommandRequest)
I (44530) esp_matter_command: Received command 0x00000004 for endpoint 0x0000's cluster 0x00000030
I (44540) chip[FS]: GeneralCommissioning: Received CommissioningComplete
I (44540) chip[FP]: Metadata for Fabric 0x2 persisted to storage.
I (44560) chip[TS]: Committing Last Known Good Time to storage: 2023-06-19T06:58:09
I (44560) chip[ZCL]: OpCreds: Fabric index 0x2 was committed to storage. Compressed Fabric Id 0x0459C5EAC7ADA78D, FabricId<PHONE_NUMBER>000002, NodeId 000000004AD8F3A3, VendorId 0x1384
I (44590) chip[FS]: GeneralCommissioning: Successfully commited pending fabric data
I (44590) chip[FS]: Fail-safe cleanly disarmed
I (44600) esp_matter_attribute: ********** W : Endpoint 0x0000's Cluster 0x00000030's Attribute 0x00000000 is 0 **********
I (44610) chip[EM]: <<< [E:56416r S:60367 M:13365380 (Ack:174668872)] (S) Msg TX to 2:491622BAC79E9642 [A78D] --- Type 0001:09 (IM:InvokeCommandResponse)
I (44620) chip[IN]: (S) Sending msg 13365380 on secure session with LSID: 60367
I (44630) chip[EM]: >>> [E:56415r S:0 M:156920698 (Ack:219481739)] (U) Msg RX from 0:766752F722F26FD1 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (44640) app_main: Fabric is committed
I (44650) chip[SVR]: Commissioning completed successfully
I (44650) chip[DIS]: Updating services using commissioning mode 0
I (44670) chip[DIS]: CHIP minimal mDNS started advertising.
I (44680) chip[DIS]: Advertise operational node 638C92F1B94D5355-000000004974C1F1
I (44680) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 638C92F1B94D5355-000000004974C1F1.
I (44700) chip[DIS]: mDNS service published: _matter._tcp
I (44700) chip[DIS]: Advertise operational node 0459C5EAC7ADA78D-000000004AD8F3A3
I (44710) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 0459C5EAC7ADA78D-000000004AD8F3A3.
I (44730) chip[DIS]: mDNS service published: _matter._tcp
I (44730) chip[SC]: SecureSession[0x3fc9b480]: Moving from state 'kActive' --> 'kPendingEviction'
I (44740) app_main: Commissioning complete
I (44750) esp_matter_core: Commissioning Complete
I (44750) chip[EM]: >>> [E:56416r S:60367 M:174668873 (Ack:13365380)] (S) Msg RX from 2:491622BAC79E9642 [A78D] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (44770) chip[EM]: >>> [E:56417r S:60367 M:174668874] (S) Msg RX from 2:491622BAC79E9642 [A78D] --- Type 0001:02 (IM:ReadRequest)
I (44770) app_main: Commissioning window closed
I (44790) chip[EM]: <<< [E:56417r S:60367 M:13365381 (Ack:174668874)] (S) Msg TX to 2:491622BAC79E9642 [A78D] --- Type 0001:05 (IM:ReportData)
I (44800) chip[IN]: (S) Sending msg 13365381 on secure session with LSID: 60367
I (44810) chip[EM]: >>> [E:56417r S:60367 M:174668875 (Ack:13365381)] (S) Msg RX from 2:491622BAC79E9642 [A78D] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (44830) chip[EM]: >>> [E:56418r S:60367 M:174668876] (S) Msg RX from 2:491622BAC79E9642 [A78D] --- Type 0001:02 (IM:ReadRequest)
I (44840) chip[EM]: <<< [E:56418r S:60367 M:13365382 (Ack:174668876)] (S) Msg TX to 2:491622BAC79E9642 [A78D] --- Type 0001:05 (IM:ReportData)
I (44850) chip[IN]: (S) Sending msg 13365382 on secure session with LSID: 60367
I (44870) chip[EM]: >>> [E:56418r S:60367 M:174668877 (Ack:13365382)] (S) Msg RX from 2:491622BAC79E9642 [A78D] --- Type 0000:10 (SecureChannel:StandaloneAck)

I'm having the same issue. Also tried adding it to SmartThings, using the SmartThings Station (Thread), but it gets to the same logs as HomeKit, being already connected to the Thread network but not responding to Matter commands.
I'm using the ESP32-C6 with a modified sdkconfig.defaults.esp32c6:
CONFIG_IDF_TARGET="esp32c6"

# libsodium
CONFIG_LIBSODIUM_USE_MBEDTLS_SHA=y

# NIMBLE
CONFIG_BT_ENABLED=y
CONFIG_BT_NIMBLE_ENABLED=y
CONFIG_BT_NIMBLE_EXT_ADV=n
CONFIG_BT_NIMBLE_HCI_EVT_BUF_SIZE=70
CONFIG_USE_BLE_ONLY_FOR_COMMISSIONING=n

# FreeRTOS should use legacy API
CONFIG_FREERTOS_ENABLE_BACKWARD_COMPATIBILITY=y

# Enable OpenThread
CONFIG_OPENTHREAD_ENABLED=y
CONFIG_OPENTHREAD_SRP_CLIENT=y
CONFIG_OPENTHREAD_DNS_CLIENT=y
CONFIG_OPENTHREAD_LOG_LEVEL_DYNAMIC=n
CONFIG_OPENTHREAD_LOG_LEVEL_NOTE=y
CONFIG_OPENTHREAD_CLI=n

# Disable lwip ipv6 autoconfig
CONFIG_LWIP_IPV6_AUTOCONFIG=n

# Use a custom partition table
CONFIG_PARTITION_TABLE_CUSTOM=y
CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions_thread.csv"

# LwIP config for OpenThread
CONFIG_LWIP_IPV6_NUM_ADDRESSES=8
CONFIG_LWIP_MULTICAST_PING=y

# MDNS platform
CONFIG_USE_MINIMAL_MDNS=n
CONFIG_ENABLE_EXTENDED_DISCOVERY=y

# Enable OTA Requestor
CONFIG_ENABLE_OTA_REQUESTOR=y

# Disable STA and AP for ESP32C6
CONFIG_ENABLE_WIFI_STATION=n
CONFIG_ENABLE_WIFI_AP=n

# Button
CONFIG_BUTTON_PERIOD_TIME_MS=20
CONFIG_BUTTON_LONG_PRESS_TIME_MS=5000

# Enable chip shell
CONFIG_ENABLE_CHIP_SHELL=y

# Enable DS Peripheral
CONFIG_ESP_SECURE_CERT_DS_PERIPHERAL=y

esp-matter: bd692f3b9e600d93fc3a70400b57db1e6d6d9902
esp-idf: ea5e0ff298e6257b31d8e0c81435e6d3937f04c7

@law-ko Logs are pretty clear, Apple Home added the device to both of its fabric and then see the following logs.
I (44830) chip[EM]: >>> [E:56418r S:60367 M:174668876] (S) Msg RX from 2:491622BAC79E9642 [A78D] --- Type 0001:02 (IM:ReadRequest)
I (44840) chip[EM]: <<< [E:56418r S:60367 M:13365382 (Ack:174668876)] (S) Msg TX to 2:491622BAC79E9642 [A78D] --- Type 0001:05 (IM:ReportData)
I (44850) chip[IN]: (S) Sending msg 13365382 on secure session with LSID: 60367
I (44870) chip[EM]: >>> [E:56418r S:60367 M:174668877 (Ack:13365382)] (S) Msg RX from 2:491622BAC79E9642 [A78D] --- Type 0000:10 (SecureChannel:StandaloneAck)

>>> logs are data received to the device and <<< are data sent from device.
See the last few logs, device received read request and it served it with response and got an ack.
So, device is not stuck, its not receiving any request from the client. Can you check if you see the same behaviour using chip-tool? Commission using chip-tool and try reading few attributes, and you do a wildcard subscribe.
./chip-tool any subscribe-by-id 0xFFFFFFFF 0xFFFFFFFF 3 10 (NODE_ID) (EP_ID)

Can you please try that and attach the log file (please don't paste it here) for both esp32 and chip-tool?

It seems that my issue was something I'd done to the config variables. Deleting sdkconfig and making a clean configuration solved the problem.

Thanks for the confirmation @marciogranzotto . @law-ko I will close this issue now. Please re-open if you still see it, with the data requested


[DOC] expand coding standards

Addresses #31, #62

To be discussed : Do we want to add recommendations on using LLMs in coding ?

cc @sjshim, please let me know if you have any feedback on this ! 👩💻

This is definitely much better!

Definitely will be good to get more ideas down following that discussion 😸
@poldrack, let us know if this looks OK (enough, for now) to merge on your end !


Avoid using password file when using ciphertool

Problem
As of now, when using the 'Secure Vault'[1] for WSO2 APIM, it needs to store the internal key-store password to file(password-tmp or password-persist).
For Kubernetes based deployments, there are external CSI drivers that can copy the password value dynamically to password-tmp or password-persist files as guided in [2].
Also, we know the WSO2 products support Hashcrop vault integration as per[3].
Taking those as an advantage, is there any possibility to avoid having the password saved in the file system during startup in the 'password-tmp' like connecting to the external vaults and performing the server startup?
[1] - https://apim.docs.wso2.com/en/4.0.0/install-and-setup/setup/security/logins-and-passwords/working-with-encrypted-passwords/#resolving-already-encrypted-passwords-during-server-startup
[2] - https://github.com/wso2/helm-apim/blob/4.2.x/all-in-one/templates/am/wso2am-conf-entrypoint.yaml#L45
[3] - https://github.com/wso2-extensions/carbon-securevault-hashicorp
Thanks,
Solution
Connecting to the external vaults and getting the password value during the startup in a more secured way.
Affected Component
APIM
Version
No response
Implementation
No response
Related Issues
No response
Suggested Labels
No response

Something like this works for Apache Tomcat: https://stackoverflow.com/questions/16194052/encrypt-tomcat-keystore-password
And here is a useful link: https://cwiki.apache.org/confluence/display/TOMCAT/Password


Make do_get_basic, do_get_storage and do_get_block_hash public

Motivation
Making these functions public will enable us to easily pre-cache some account data and/or storages.

Solution

PR Checklist

[ ] Added Tests
[ ] Added Documentation
[ ] Breaking changes

Of course, you are right, and I apologize for not noticing earlier. Sorry for wasting your time.

no worries :)
ty!


Update scrivo/highlight.php

Maybe it added better support for attributes:

Thanks for merging. Let's make a new release next week because I don't want to tag a new release and have some bugs while docs are rebuilt during the weekend.


Validation: Do not allow defined activity with zero amount

Currently, we allow zero amount payments to be skipped over to allow for the possibility that our random payment amount generation spits out a zero value every once in an hour.
Right now we don't validate that we're provided with a non-zero defined activity amount, so we'll hit the same check and just endlessly not dispatch payments if we're given a zero value.
We should update validate_activity to disallow zero values.

Hey @carlaKC am interested in working on this issue.

@carlaKC
On validate_activity function  I added validation to check for zero amount_msats.

On running cargo run I get the validation error

Which is fine but it seems to skip on running sim-cli

Is that the expected behaviour?

Which is fine but it seems to skip on running sim-cli

Have you re-installed sim-cli before you test?

That fixed it. Thank you


Speedup matmul when the matrices are vectors

In the WebGL backend, we can parallelize dot products by calling tf.mul(x,y).sum() -- this is due to the fact that the WebGL's sum() uses divide-and-conquer and is O(sqrt(N)).
Have matmul() in WebGL call tf.mul(x, y).sum() when we have matrix x vector, vector x matrix, or vector x vector and the shared dimension is longer than 1000 (see benchmark below).
Fixes https://github.com/tensorflow/tfjs/issues/881
Benchmark of [1,K]x[K,1] for different Ks:
=== OLD ===
LOG: 'K = 1, Took 0.72 ms'
LOG: 'K = 10, Took 0.67 ms'
LOG: 'K = 100, Took 0.59 ms'
LOG: 'K = 1000, Took 0.64 ms' --- slower after K>1000.
LOG: 'K = 10000, Took 1.18 ms'
LOG: 'K = 100000, Took 10.66 ms'
LOG: 'K = 1000000, Took 110.90 ms'
=== NEW ===
LOG: 'K = 1, Took 0.62 ms'
LOG: 'K = 10, Took 0.62 ms'
LOG: 'K = 100, Took 0.67 ms'
LOG: 'K = 1000, Took 0.67 ms' --- faster after K>1000.
LOG: 'K = 10000, Took 1.12 ms'
LOG: 'K = 100000, Took 0.88 ms'
LOG: 'K = 1000000, Took 0.94 ms'
Benchmarked mobilenet, coco-ssd, and posenet --  no perf impact there.
PERF

This change is

Hold on for a bit, I'm going to generalize this further for any matrix-vector, vector-matrix product based on the excellent observation of @DirkToewe in https://github.com/tensorflow/tfjs/issues/881#issuecomment-436045897

This is ready for review


Not work when targeting latest Chrome versions.

For example:
# .babelrc
{
  "presets": [
    ["@babel/preset-env", {
      "modules": false,
    }],
  ],
}

# browserslist
last 2 Chrome versions

This is what I got:

Error: An unexpected situation arose. Please raise an issue at https://github.com/rollup/rollup-plugin-babel/issues. Thanks!

Can we add a way to skip preflightCheck if I'm sure which plugin I'm using?

I figured out that I should not use @babel/plugin-external-helpers. The preflightCheck did not work as expected though.


Create book.rb and book_spec.rb

Create a Book class in a separate .rb file.
All Book class properties visible in the diagram should be defined and set up in the constructor method.
Add unit tests for all implemented methods in the book class.

Approved 👏
Highlights 🚀 :heavy_check_mark: :heavy_check_mark:

Git/GitHub flow best practices have been followed:heavy_check_mark:
You have descriptive PR:heavy_check_mark:
You successfully pass unit tests for all classes. :heavy_check_mark:

Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉

Cheers and Happy coding!👏👏👏


Switch a few more unit tests to async message delivery.

Problem
Our loopback transport defaults to synchronous message delivery, with replies coming in before the send call returns.  This causes various problems in code that does not expect this behavior, which can't happen in normal operation.
Change overview
Move the "do async message delivery" up into a class defined in MessagingContext.h, so it's not IM-specific, and use it in two tests that should exercise some edge cases:

src/messaging/tests/TestExchangeMgr.cpp to test that tests in src/messaging work with this setup.
src/protocols/secure_channel/tests/TestPASESession.cpp to test that tests with a custom transport impl work with this setup.

Testing
Unit tests still pass with the new setup.

@woody-apple I'd really like this to get a look from @pan-apple before we merge, to make sure I am not missing something that would make the tests no longer be testing what we want them to test.


Replace NFD with NFKD normalization

See also https://tonsky.me/blog/unicode/

Honestly no idea anymore where I was going with this.


Refined nested-group sample application according to the standards

Refined nested-group sample application according to the standards

@dinithis Thanks for looking into this, as it looks like this pull request contains changes in the CLI. Were those included on purpose?
Thanks


How to set custom field values when creating new page via API ?

Is it possible to pass custom field values when creating a new page via api ?

I answered in the forum https://forum.bludit.org/viewtopic.php?f=6&t=2152

I answered in the forum https://forum.bludit.org/viewtopic.php?f=6&t=2152

I replied, I'm unable to send the custom fields value when creating a new page. Please tell me, what is the correct format to use when sending custom field data along with the new page data?
Everything is being passed except the custom data and I've been stuck on this problem for a day now.
$fields = array(
            'token' => "ahblah",
            'authentication' => "blahblah",
            'title' => $szz['title'],
            'content' => $szz['description'],
            'slug' => $szz['slug'],
            'coverImage' => $mainimg,
            'tags' => $tagsz,
            'custom' => array (
      'boxart' => $szz['boxart'],
      'horizontalHeaderImage' => $szz['horizontalHeaderImage']
    )
        );
$fields_string = http_build_query($fields);


[BUG]  Exclude password-like fields for considering reparse (#9844)

backport #9844 to 1.7

Problem

Solution

Checklist

[ ] I have read the contributing guide and understand what's expected of me
[ ] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX
[ ] This PR includes type annotations for new and modified functions

@graciegoheen @martynydbt  do we need to backport this to 1.6？I saw adapter PR get backported to both 1.6 and 1.7.

@ChenyuLInx Medtronic is running 1.7.11 and they are still not getting parse caching on runs due to a user profile change.
I feel like this fix should be live for them at this point.. Thoughts?
Sample run:
https://cloud.medtronic.getdbt.com/deploy/2/projects/16/runs/815569
Tagging @graciegoheen for awareness as well


Multiple colored bars in Bar Chart??

Is it possible to set different fill colors in one Bar Chart for each bar? I am not talking about Bar Groups, just a simple Bar chart

not at this time.

You could always create a multi-series bar chart with one series per x value.


Fix mac icon assignments

issue #543
Icon paths in forge.config.js have been ignored.
Moved mac icon path config from forge.config.js to electron-builder.json
Account Number
94161c7f2d143eb387aab95b1ee4d334df57a233a63bd466c8b2368148c4917d

@amarjeet987 no this ones fine because it was before my PR

oh my lord that looks so good :D

oh my lord that looks so good :D

Yeah, aesthetic xD


Epic: Redesign course and program about pages

As a learner, I'd like to:

know that I can enroll for free.
see that I can pay for a certificate and how much it will cost, and when the upgrade deadline is
know how I can apply for financial assistance
be able to learn more about certificates
be able to enroll in a course that is closed and understand that I can't get a certificate
know when a course is part of a MicroMasters program or a Learning Path

Designs and Mockups

Figma design: https://www.figma.com/proto/Gs4zIhOFv5gVvafawwl6PF/MITx-Online?page-id=37%3A4307&type=design&node-id=37-4311
Updated design (whole thing): https://www.figma.com/proto/Gs4zIhOFv5gVvafawwl6PF/MITx-Online?page-id=0%3A1&type=design&node-id=558-2708&viewport=-1130%2C359%2C0.1&t=gwT4VDKtWVtv71cH-1&scaling=scale-down&mode=design

Acceptance Criteria:
These are high level requirements and split into functional areas. Items will link to individual tickets where they can.

CMS Changes

[ ] Add "Show More" functionality to rich text content blocks
[ ] Make sure these context blocks are rich text: Course Intro, About (new), What You'll Learn
[ ] Add selectable Meet Your Instructors block

Main Content

[ ] Add new CMS block for Course Intro
[ ] Implement "Show More" functionality within all content blocks
[ ] Add anchor tab
[ ] Update styling to match the design

Infobox

[ ] Add container and styling for courseware object information
[ ] Add timing information
[ ] Add certificate track/pricing information
[ ] Add program path information

Modals

[ ] Reformat upsell message for individual courses
[ ] Add upsell message for programs (this will contain an enrollment selector)
[ ] Any other modals

Miscellaneous

[ ] Add feature flag to enable/disable the new design
[ ] Add feature flag to enable/disable program about pages

Out of Scope

Feature flag implementation: this should not be done in the old manner and instead use the new infrastructure coming in https://github.com/mitodl/hq/issues/1981.

Related issues
Course About Page - https://github.com/mitodl/hq/issues/1542
Reusable Faculty Members - https://github.com/mitodl/hq/issues/1543
Program About Page - https://github.com/mitodl/hq/issues/1544
About Page Enrollment Dialogs - https://github.com/mitodl/hq/issues/1947
Feature Flag Support - https://github.com/mitodl/hq/issues/1981
Program Type Support - https://github.com/mitodl/hq/issues/1982
Related PRs
https://github.com/mitodl/mitxonline/pull/1778
https://github.com/mitodl/mitxonline/pull/1786

Spoke with James.  He believes there is nothing left to do for this epic to be complete.  Closing.


grpc::ChannelArguments::SetSocketMutator() should either be removed or made usable.

Should this be an issue in the gRPC issue tracker?
Yes.
What version of gRPC and what language are you using?
1.9.0-dev
What operating system (Linux, Windows, …) and version?
Linux, macOS, Windows, this applies to any OS where gRPC is supported.
What runtime / compiler are you using (e.g. python version or version of gcc)
C++.
What did you do?
Mostly read the documentation, but tried to use grpc::ChannelArguments::SetSocketMutator()
What did you expect to see?
I expected the grpc_socket_mutator struct to be fully defined when including (a) ideally the grpc++/grpc++.h header, or (b) some other header installed by gRPC.  Alternatively, if the call is not supposed to be used by the application it should not be exposed through one of the public APIs, remove it completely, or move to some internal namespace.
What did you see instead?
The grpc_socket_mutator is forward declared (in include/grpc/impl/codegen/grpc_types.h), the definition is in a header that does not get installed with gRPC (src/core/lib/iomgr/socket_mutator.h).
Anything else we should know about your project / environment?

This will be resolved as part of #14648


Support resolveDockerTagsByTimestamp for Docker virtual reporitories

Is your feature request related to a problem? Please describe.
We can't set resolveDockerTagsByTimestamp on a Docker virtual repository today.
Describe the solution you'd like
Add a field resolveDockerTagsByTimestamp on a virtual docker repository
Thanks

@jcoste-orange it's released in v6.19.0, thanks!

Thank you to you @danielmkn.


Change canonisation method from minimsation to something less intrusive

BTW why do you need that at all? Can't you just take the DOM content literally and that's it?

I fully agree. I understand JS might be slow in crypto so minizing then verifying signature seams easier, but come one, just do a hash of content, and then sign it. No minimizing required.

You need to add a comment at the top of the html file (right after the doctype if exists) that contains the detached PGP signature of the content of the  tag after it has been minified with minimized with a specific set of settings.

I was reading. everything before, and it was all nice, until this part. WTF.
It imposes huge burden on development setup, build tools, and is going to break when the page and extensions are using different versions https://github.com/Swaagie/minimize that change output format slightly. Which is very likely to happen.

I understand JS might be slow in crypto

Actually not really with the Web Crypto API, which is natively implemented in browsers and which I think this extension, uses.

As mentioned in the README and in https://github.com/tasn/webext-signed-pages/issues/15#issuecomment-397678162, this is not possible. You can't take the DOM content in a consistent manner across browsers. I don't remember the exact inconsistencies I got, but they were plentiful. I could maybe do some less aggressive, home-made, canonisation. I think the differences were not that crazy and I can probably play this cat-and-mouse game with browsers, I just hope it won't break on browsers I'm not testing on.
I'm leaving this one open, but going to change the title a bit.

From #15:

Okay so there is an issue for filterResponseData in Chromium.
Don't know whether you offer your extension for other browsers, but if this is implemented there, we could drop that requirement.
BTW am I right that on Firefox you don't apply the minimizer then – as the original content should be minimized correctly?

Once it's out in Chromium we can completely drop it, yes.
At the moment it's also done for Firefox because the paged is only signed with one signature. The moment the whole versioning scheme described in #13 and #15 is implemented, we can just have two signatures. Original and minimised so we can also support old browsers (on the signed page side), or to be honest, we can probably just drop old version support at the moment because signed-pages is not yet widely used.

Indeed drop old browser-support. BTW don't know how old the browsers actually are you support, but they have to support SRI, at least.


As in Life, So in Death should allow for any ancestry

As in Life, So in Death should allow for any ancestry, but when selected in foundry, one only gets to select from the common list as standard adopted ancestry

Adopted Ancestry was relaxed, so this issue is now moot


Enhancement: Improve output from running php-cs-fixer

This PR

[x] improves the output when running php-cs-fixer via composer lint

Codecov Report

Merging #147 into develop will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop     #147   +/-   ##
==========================================
  Coverage      98.73%   98.73%
  Complexity      1603     1603
==========================================
  Files            110      110
  Lines           3796     3796
==========================================
  Hits            3748     3748
  Misses            48       48

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8d838f2...2dfb1bc. Read the comment docs.

Thank you, @mikaelcom!


Other Vulkan bindings

Not really an issue, but rather something to help @jwollen a bit:
There is another C# Vulkan binding out there: https://github.com/mono/VulkanSharp
Apparently, it's generator is open source as well! :D You might be able to incorporate parts of it into your code (though, that is a lot of work and usually only worth it, if there is an issue that you can't figure out how to solve)

Yep, monitoring those, too.
They look a bit different, though. I'd like to keep them mostly unsafe and struct-based.
Maybe we can join forces at some point, once I include the generator and both projects are a bit more mature.


refactor: encapsulate some globals 2

Continuing https://github.com/D-Programming-Language/dmd/pull/5065

What's with these random heisenbugs?
gmake[2]: Leaving directory `/usr/home/braddr/sandbox/at-client/pull-1734592-FreeBSD_64_64/druntime/test/coverage'
grep: ./obj/freebsd/64/mytrace.log: No such file or directory

Auto-merge toggled on


rearchitect the project to make it more modular

sdr module included

I prefer to follow the convention naming from substrate to avoid barrier for understanding new word, use srml  instead of evrml

For the other part (e.g. executor, cli, service...) I'm going to merge first, but suggest to avoid duplication if we can just directly depend on the crate from substrate.


up to 943862

up to 943862

Hi Haji!
It looks like when you made this pull request, you made it for the branch main instead of the data branch. I'm going to close this pull request; once I've done that, can you recreate it? Basically, just make sure that when you create the pull request, you are requesting that I pull your changes into the "data" branch instead of the "main" branch.
Feel free to message me on slack or on here if you have any questions!
-Noah

(Nevermind! I can edit the base myself!)


csearch/cgrep exit with status 1 regardless of matches found or not

What steps will reproduce the problem?
1. csearch int
2. echo $?
3. csearch SomeStringNotAppearingInYourSourceTree
4. echo $?

What is the expected output? What do you see instead?
In both cases, a '1' is displayed indicating that csearch believes it found no
matches.  This is because the Grep.Match field is not updated when a match is
found.

What version of the product are you using? On what operating system?
tip, darwin

Please provide any additional information below.
A one line fix setting g.Match = true in match.go:Grep.Reader():430 should fix
this.

Original issue reported on code.google.com by dgryski on 29 Jan 2012 at 8:27

Just realized the line number (430) is probably incorrect because I already
modified match.go with my fix for issue # 8.

			if m1 < chunkStart {
 				break
 			}
+                     g.Match = true
 			if g.L {
 				fmt.Fprintf(g.Stdout, "%s\n", name)
 				return
                        }

Original comment by dgryski on 29 Jan 2012 at 8:53

This issue was closed by revision 52cb1715a33c.

Original comment by dgryski on 2 May 2012 at 8:56

Changed state: Fixed


DNN-7525 Remove field length limitation on Answer field

Arguably the limit shouldnt have been removed, but instead set to match the database where it appears this is th PasswordAnswer	nvarchar(128)	column in aspnet_membership. However with it being unlikely any user would provide such a long answer, I've elected to merge this.

I don't disagree - I thought about that - but that would have meant more work as we would have needed to change all occurrences of the Answer field (which has no limit in many other places).  I think this should be reviewed when we make changes in 8.x for Security


Ads: The wrong anchor link with the enabled "Comment" button

Now it generates the URL's addon like #cmts-anchor-bx-ads-2 instead of #cmts-anchor-bx-ads-reviews-2

Ads app has both Comments and Reviews. Reviews are enabled by default. This Comment button is associated with Comments, which are disabled by default.


Update golang.org/x/net

Result of go get -u golang.org/x/net && make tidy. Fixes https://pkg.go.dev/vuln/GO-2024-2887.

Actually it does not fix the linked issue which is in net, not x/net, but the update is good to have in any case if it passes CI.


how to install it ?

sudo make,
it build correctly but when i try to run it sudo ./k810 on, it run segmentation fault with nothing happen, any idea how to fix it ?

in my case the problem is a remapping software (karabiner), sorry


drivers: rtc: rv8263-c8: Alarm reworking

Improve the alarm handling for the RV8263-C8 RTC, reduce the code size, and fix some bugs.

Fix typos for alarm field identification
Fix a bug where an alarm interrupt starts update interrupts
Rework interrupt code to reduce code size and complexity

@Kampi . We are only merging PR's that have an issue associated with it. Can you help add an issue with the details of the problem seen and link the issue to this PR.

@Kampi . We are only merging PR's that have an issue associated with it. Can you help add an issue with the details of the problem seen and link the issue to this PR.

@mmahadevan108 sure. I will create the issue tomorrow and link it to the PR.

@Kampi . We are only merging PR's that have an issue associated with it. Can you help add an issue with the details of the problem seen and link the issue to this PR.

@mmahadevan108 I added the issue to this PR.


Is there any evaluation code for unseen camera view?

Hi,
I want to evaluate trained model for unseen camera view of zju-mocap dataset.
I trained model on camera view 0, and I will evaluate this on view 1~22.
However, your repository doesn't give any evaluation code, only freeview & t-pose rendering code.
So, Can you tell me how to get unseen camera view evaluation code?
Thanks

Hello,
Please refer to the issue to know the details about how we evaluated the trained models.


[e2e]: go schedule main adversarial-binary-upload slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/3252008569
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.schedule.main.adversarial-binary-upload.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.go.schedule.main.adversarial-binary-upload.slsa3.yml
Trigger: workflow_dispatch
Branch: main
Date: Fri Oct 14 18:24:50 UTC 2022

Closing since adversarial tests are disabled.


Linux: Fix missing onDuration event, free previous source when set url

Closes #1126

Sorry not sure why windows is failing. Something to do with flutter 3.0.0 and melos call flutter pub get which somehow accessing the same resource.

I made a PR for this: https://github.com/flame-engine/flame/pull/1630


CMake Error

I tried to build nnvm in Windows 10, and there was an error as following:
-- Build with TVM libary: E:/workspace/cpp/nnvm/tvm/build/Release/tvm.lib
CMake Error at CMakeLists.txt:108 (install):
  install Library TARGETS given no DESTINATION!

I reference this page to modify
line 108   install(TARGETS nnvm LIBRARY DESTINATION lib)

to
line 108   install(TARGETS nnvm ARCHIVE DESTINATION lib LIBRARY DESTINATION lib)

and it works now

Hi, can you now successfully build the nnvm_compiler.dll?  I am getting lots of unresolved symbol errors like below
1>compile_engine.obj : error LNK2019: unresolved external symbol "class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl Halide::operator<<(class std::basic_ostream<char,struct std::char_traits<char> > &,struct Halide::Type const &)" (??6Halide@@YAAEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@AEAV12@AEBUType@0@@Z) referenced in function "int __cdecl nnvm::compiler::GetTypeFlag(struct Halide::Type)" (?GetTypeFlag@compiler@nnvm@@YAHUType@Halide@@@Z)

@cudawarped I can build nnvm_compiler.dll successfully. Did you use the proper version of VS2015?

Thanks GarrickLin, I am not sure what I was doing incorrectly, but I started the build again from scratch using your fix above, and everything built successfully.


fix  styles and typo in the README.md

fix  styles and typo  in the README.md

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank your for your contributions! But this issue already fix by other people, it's conflicting now.