ESP32C6, Matter issues, have become confused and got stuck=(

[amunabv]

Hey all, thanks for reading, hit a roadblock and need your help!!!

I followed Tasmota steps to add Matter support with Google Home Developer Console.
Doing nothing fancy, just got a simple LED on GPIO7, configured as Relay on Tasmota. Control from Tasmota WebUI is all fine and dandy.

Next I took the code from https://github.com/google-home/sample-apps-for-matter-android/archive/refs/tags/v2.0.0.zip

This compiles into an app is named: GHSAFM-3p-ecosystem

You can add Matter devices there, so I tried to pair up the Tasmota 14.0.0.1.

This seemed to work. The device commisioning went successful and the device was added to the list.
However it quickly became apparent there was something instable. As soon as I pressed the "On/Off" switch the GHSAFM-3p-ecosystem app would crash. (Error log at bottom, error code 0x81)

I played around adding and removing the device again untill at one point I got a message while removing the device:
"There was a problem removing the device from the fabric."

After that the device wouldnt pair up anymore. I could scan the QR code, but the GHSAFM-3p-ecosystem / Play Framework just wouldnt find the device anymore, and come up with the error message it was unable to find the device.

I got stuck here for a while. I fully reset the device, restarted from original factory image, removed and re-added the project in the Google Home Developer Console, etc. etc. nothing worked.

In the end the solution was to Remove Storage/Clear Cache on the Google Play Services and Play framework. After that I was able to pair the device again using the QR code in the GHSAFM-3p-ecosystem app. (I also noticed the pairing code changed at this point)

This would get me back to where I was before. This is where I'm stuck now. The device shows the Power Outlet icon in the GHSAFM-3p-ecosystem app. When I try to toggle the On/Off switch the app crashes with a 0x81 error code from the CHIP-TOOL error codes. When the GHSAFM-3p-ecosystem app is then restarted it will no longer 'reach' the device. It will display Off in the Home tab, and when opening the device details it says "Offline", clicking on Inspect will inform the user the device is offline. The only way to 'reach' the device again is to remove and repair it, the Inspect button will then give output again.

Android logcat when pretting the On/Off on GHSAFM-3p-ecosystem home tab:

23:16:19.877 11730-11730 GHSAFM-3p-...eViewModel      D  updateDeviceStateOn: Device [6233479082658025933]  isOn [false]
23:16:19.878 11730-11730 GHSAFM-3p-...iceStateOn      D  Handling real device
23:16:19.879 11730-11730 GHSAFM-3p-...tersHelper      D  setOnOffDeviceStateOnOffCluster() [6233479082658025933] isOn [false] endpoint [1]
23:16:19.879 11730-11730 CSM                          D  FindOrEstablishSession: PeerId = [1:5681C43304A8D1CD]
23:16:19.879 11730-11730 CSM                          D  FindOrEstablishSession: No existing OperationalSessionSetup instance found
23:16:19.879 11730-11730 DIS                          D  Found an existing secure session to [1:5681C43304A8D1CD]!
23:16:19.879 11730-11730 DIS                          D  OperationalSessionSetup[1:5681C43304A8D1CD]: State change 1 --> 5
23:16:19.879 11730-11730 GHSAFM-3p-...icePointer      D  Got connected device pointer
23:16:19.880 11730-11730 DMG                          D  ICR moving to [AddingComm]
23:16:19.880 11730-11730 DMG                          D  ICR moving to [AddedComma]
23:16:19.881 11730-11730 EM                           D  <<< [E:44515i S:55806 M:259230694] (S) Msg TX to 1:5681C43304A8D1CD [2B0A] --- Type 0001:08 (IM:InvokeCommandRequest)
23:16:19.881 11730-11730 IN                           D  (S) Sending msg 259230694 on secure session with LSID: 55806
23:16:19.881 11730-11730 DMG                          D  ICR moving to [CommandSen]
23:16:19.907 11730-11809 EM                           D  >>> [E:44515i S:55806 M:41214673 (Ack:259230694)] (S) Msg RX from 1:5681C43304A8D1CD [2B0A] --- Type 0001:09 (IM:InvokeCommandResponse)
23:16:19.907 11730-11809 EM                           D  Found matching exchange: 44515i, Delegate: 0xb40000772c2d7838
23:16:19.907 11730-11809 EM                           D  Rxd Ack; Removing MessageCounter:259230694 from Retrans Table on exchange 44515i
23:16:19.907 11730-11809 DMG                          D  ICR moving to [ResponseRe]
23:16:19.907 11730-11809 DMG                          D  InvokeResponseMessage =
23:16:19.907 11730-11809 DMG                          D  {
23:16:19.907 11730-11809 DMG                          D  	suppressResponse = false, 
23:16:19.907 11730-11809 DMG                          D  	InvokeResponseIBs =
23:16:19.907 11730-11809 DMG                          D  	[
23:16:19.907 11730-11809 DMG                          D  		InvokeResponseIB =
23:16:19.907 11730-11809 DMG                          D  		{
23:16:19.907 11730-11809 DMG                          D  			CommandStatusIB =
23:16:19.907 11730-11809 DMG                          D  			{
23:16:19.907 11730-11809 DMG                          D  				CommandPathIB =
23:16:19.907 11730-11809 DMG                          D  				{
23:16:19.907 11730-11809 DMG                          D  					EndpointId = 0x1,
23:16:19.907 11730-11809 DMG                          D  					ClusterId = 0x6,
23:16:19.907 11730-11809 DMG                          D  					CommandId = 0x0,
23:16:19.907 11730-11809 DMG                          D  				},
23:16:19.907 11730-11809 DMG                          D  				
23:16:19.907 11730-11809 DMG                          D  				StatusIB =
23:16:19.907 11730-11809 DMG                          D  				{
23:16:19.907 11730-11809 DMG                          D  					status = 0x81,
23:16:19.907 11730-11809 DMG                          D  				},
23:16:19.907 11730-11809 DMG                          D  				
23:16:19.907 11730-11809 DMG                          D  			},
23:16:19.907 11730-11809 DMG                          D  			
23:16:19.907 11730-11809 DMG                          D  		},
23:16:19.907 11730-11809 DMG                          D  		
23:16:19.907 11730-11809 DMG                          D  	],
23:16:19.907 11730-11809 DMG                          D  	
23:16:19.907 11730-11809 DMG                          D  	InteractionModelRevision = 1
23:16:19.907 11730-11809 DMG                          D  },
23:16:19.907 11730-11809 DMG                          D  Received Command Response Status for Endpoint=1 Cluster=0x0000_0006 Command=0x0000_0000 Status=0x81
23:16:19.910 11730-11809 GHSAFM-3p-...OffCluster      E  Failure for getOnOffDeviceStateOnOffCluster
                                                                                                    chip.devicecontroller.ChipClusterException: CHIP cluster error: 129
23:16:19.910 11730-11809 DMG                          D  ICR moving to [AwaitingDe]
23:16:19.910 11730-11809 EM                           D  <<< [E:44515i S:55806 M:259230695 (Ack:41214673)] (S) Msg TX to 1:5681C43304A8D1CD [2B0A] --- Type 0000:10 (SecureChannel:StandaloneAck)
23:16:19.910 11730-11809 IN                           D  (S) Sending msg 259230695 on secure session with LSID: 55806
23:16:19.911 11730-11809 EM                           D  Flushed pending ack for MessageCounter:41214673 on exchange 44515i
23:16:19.935 11730-11730 AndroidRuntime               E  FATAL EXCEPTION: main
                                                                                                    Process: , PID: 11730
                                                                                                    chip.devicecontroller.ChipClusterException: CHIP cluster error: 129
                                                                                                    	Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@430d6c9, Dispatchers.Main.immediate]
23:16:19.947 11730-11730 Process                      I  Sending signal. PID: 11730 SIG: 9
---------------------------- PROCESS ENDED (11730) for package  ----------------------------

Output of inspect on GHSAFM-3p-ecosystem app when the device is just paired:

Descriptor Cluster
<<< Endpoint 0 >>>
Device Types
[0x0016] Root Node
Server Clusters
[0x001D] Descriptor
[0x001F] Access Control
[0x0028] Basic Information
[0x002B] Localization Configuration
[0x002C] Time Format Localization
[0x0030] General Commissioning
[0x0032] Diagnostics Logs
[0x0033] General Diagnostics
[0x0034] Software Diagnostics
[0x0037] Time Synchronization
[0x003C] Administrator Commissioning
[0x003E] Node Operational Credentials
[0x003F] Group Key Management
Client Clusters
[0x001F] Access Control
<<< Endpoint 2 >>>
Device Types
[0x010A] Outlet
Server Clusters```

[s-hadinger]

Thanks for the details

0x81 means UNSUPPORTED_COMMAND. This is not a reason for the application to crash when chiptool returns a non-fatal error code. This means that the app is not handling well error codes.

To make further investigation, I need the logs from Tasmota (weblog 3 or seriallog 3) for the pairing and when the toggle happens.

[amunabv]

commissioning.log

Log On/Off press:

17:31:33.339 MTR: >Command1  ( 27507) [01]0006/0001 On
17:31:33.342 MTR: <Replied   ( 27507) Status=0x81 exch=38634

[s-hadinger]

Thanks. The explanation is simple:

• Endpoint 01 is the "aggregator" endpoint that simulates a bridge mode. Its type is 0x000E (Aggregator)
• Endpoint 02 is the relay, its type is 0x010A (On/Off Plug-in Unit)

This is why Tasmota sends UNSUPPORTED_COMMAND when the On/Off is sent to endpoint 01.

I suspect that the app is really poorly written and assumes that the relay is on endpoint 01 which is a wrong assumption.

[amunabv]

Ok, thanks, I'll be looking into the android code. Happy I got a direction again =)