Closed waseltzer closed 1 year ago
Power-cycled the Home Assistant Raspberry Pi 4 and now the ESP32 and the Matter Server are communicating. Now I have a Matter device, but with no entities. Hmm. The Matter Server reports errors. I opened an issue for the Home Assistant Matter integration: https://github.com/home-assistant/core/issues/85091
Let's see if my problem with the Home Assistant Matter or the ESP32 light sketch.
Trying to connect the ESP32 device with a Google Home Mini and the Android Google Home App. Home App finds the devices, scans the QR code, then I get "Something went wrong Make sure you're connected to your network and try again" Confirmed that the Android phone and the Google Home Mini are on the same WiFi
The ESP32 serial monitor says: (end of a long output...)
`D (11506) chip[DMG]: Received command for Endpoint=0 Cluster=0x0000_003E Command=0x0000_0004
I (11514) chip[ZCL]: OpCreds: Received a CSRRequest command
D (11519) chip[ZCL]: OpCreds: Finding fabric with fabricIndex 0x0
I (12639) chip[ZCL]: OpCreds: AllocatePendingOperationalKey succeeded
I (13205) chip[ZCL]: OpCreds: CSRRequest successful.
D (13206) chip[DMG]: Command handler moving to [ Preparing]
D (13206) chip[DMG]: Command handler moving to [AddingComm]
D (13210) chip[DMG]: Command handler moving to [AddedComma]
D (13215) chip[DMG]: Decreasing reference count for CommandHandler, remaining 0
I (13224) chip[EM]: <<< [E:33r M:211027915] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:0 9 (IM:InvokeCommandResponse)
I (13233) chip[IN]: (S) Sending msg 211027915 on secure session with LSID: 52988
D (13241) chip[DMG]: Command handler moving to [CommandSen]
D (13245) chip[DMG]: Command handler moving to [AwaitingDe]
E (13251) chip[DL]: Long dispatch time: 1859 ms, for event type 7
I (13339) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (13436) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (13534) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (24605) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 0 ) ind icate = 0
I (24605) chip[DL]: CHIPoBLE unsubscribe received
I (24608) chip[DL]: BLE GAP connection terminated (con 0 reason 0x208)
D (24606) chip[IN]: Clearing BLE pending packets.
I (24619) chip[BLE]: Releasing end point's BLE connection back to application.
I'm guessing that Google Home app and the ESP32 light application are communicating via Bluetooth, but the ESP32 isn't connecting to the Google Home Mini via Wifi? Thread?
I confirmed that the Google Home Mini is running the latest update. https://support.google.com/googlenest/answer/7365257 Google Home Mini 1.56.324896
Ideas on how to troubleshoot this? Thanks! `
I noticed some problems with BT stability during comissioning. I also saw that there were some fixes with ESP32 Bluetooth stability on Matter repo that weren't moved to this library. I'm working on next update right now and will be available in next few days. This might be worth to try it. I will let you know when update is ready ^_^
@waseltzer I have tried to connect my ESP to Google and I have the same problem like you. The same version of repository worked properly few weeks ago, so it looks like Google changed something in their services or are temporarily broken. I have also tested newest Matter build (V1.0.0.2, there is ongoing branch and pull request with this) but ended up with same result...
hello, i had the same problem 7h ago, but right now is working, i changed nothing, just tried again
testing with google home
I encountered the same problem the week before christmas (not tested again since then, I'll try to do it next week). Alltought my BLE GAP error was 0x13
.
My local setup was the same as in my post here. same Versions on the Nest Hub, nRF light_bulb and this repos ESP32 light_bulb. Except that the GHA got updated to v2.62.1.9
.
During the time my setup was working I made a test out of curiosity and found out, that with the Google setup "every Matter command" goes to the server in the first place and then comes back to the local setup (so with Google it is not a 100% local setup, which Matter advertises).
My guess now is that the updates of the server and the app must "align" or match. But because the distribution is spread through time this is not guaranteed. If someone has a better clue, please tell me!
See also my Google issue
Yeah, it's working now without any changes, so it was Google's fault. I would really love to see some more descriptive errors than Something went wrong, that Google tends to use a lot in their software... Yesterday I have tried looking into logcat but haven't found anything that could point me to problem with Google services.
Tried connecting with the Android Alexa app. The device is detected, I scanned the QR code, and the ESP32 seems to think it was connected:
I (371442) chip[DL]: IPv6 addr available. Ready on WIFI_STA_DEF interface: fe80:0000:0000:0000:ae67:b2ff:fe35:c7b4
I (371452) chip[DIS]: Updating services using commissioning mode 0
I (371459) chip[DIS]: CHIP minimal mDNS started advertising.
D (371475) chip[DL]: Using wifi MAC for hostname
I (371475) chip[DIS]: Advertise operational node 04C159740B4EDB34-00A4BC800353A020
D (371476) chip[DIS]: Responding with _matter._tcp.local
D (371480) chip[DIS]: Responding with 04C159740B4EDB34-00A4BC800353A020._matter._tcp.local
D (371488) chip[DIS]: Responding with 04C159740B4EDB34-00A4BC800353A020._matter._tcp.local
D (371496) chip[DIS]: Responding with AC67B235C7B4.local
D (371502) chip[DIS]: Responding with AC67B235C7B4.local
D (371506) chip[DIS]: Responding with _I04C159740B4EDB34._sub._matter._tcp.local
I (371514) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 04C159740B4EDB34-00A4BC800353A020.
I (371531) chip[DIS]: mDNS service published: _matter._tcp
I (371743) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 0 ) indicate = 0
I (371744) chip[DL]: CHIPoBLE unsubscribe received
I (371747) chip[DL]: BLE GAP connection terminated (con 0 reason 0x213)
D (371745) chip[IN]: Clearing BLE pending packets.
I (371758) chip[BLE]: Releasing end point's BLE connection back to application.
However, the Alexa app says "Something went wrong." I was expecting to connect this to an Amazon Echo device. I don't know if there a log or diagnostic for the Alexa app so we can look into this in more detail. Ideas?
I don't have Amazon hardware to be able to test it but I would try looking into adb logcat
. I was able to detect one issue with Google Home app few months ago with this tool. Unfortunately, it depends on developer if such errors are logged and what type of exception is being catched, so this is hit-and-miss. Anyway, this might be worth a try.
Comment from Home Assistant Matter issue: https://github.com/home-assistant/core/issues/85091
marcelveldt commented 4 days ago Looks like the device is not spec compliant or implements a device type we did not yet implement in the HA integration. The project looks interesting though so I'll take a look if I can find something obvious.
First thing to check is if the project is compatible with the Matter 1.0 spec and is not behind or ahead. We are currently only compatible with the v1.0 spec.
Tried commissioning in Home Assistant MT:Y.K9042C00KA0648G00. I still get a Matter device with no entities. And, the Matter integration says "Failed to setup" and log 2 errors:
Error setting up entry Matter for matter
File "/usr/src/homeassistant/homeassistant/components/matter/__init__.py", line 109, in async_setup_entry
await matter.setup_nodes()
RuntimeError: coroutine raised StopIteration
Unexpected exception: coroutine raised StopIteration
File "/usr/src/homeassistant/homeassistant/components/matter/__init__.py", line 131, in _client_listen
await matter_client.start_listening(init_ready)
RuntimeError: coroutine raised StopIteration
When I pressed the button on the ESP32, I'm seeing messages in the Home Assistant Matter server log.
`2023-01-09 00:49:03 core-matter-server chip.EM[126] INFO >>> [E:24904r M:248382543] (S) Msg RX from 1:0000000000000002 [13C6] --- Type 0001:05 (IM:ReportData)`
Any ideas? Maybe I should give up and wait for Home Assistant software updates?
Just FYI, I've also been unable to get a device running this firmware to work successfully with Home Assistant Matter.
I don't have all the debug info here right now, but I've tried all three example sketches from this most recent release, and although I was able to provision the "Light" example, it did not show any endpoints in Home Assistant. I could not provision the other two examples.
I resigned myself to waiting for more updates.
I just updated my Home Assistant instance to 2023.1.6. And, my ESP32 running the "light" example from this Arduino library is now working! The button on the ESP32 toggles the LED and Home Assistant updates the status immediately. And, toggling the light entity from Home Assistant toggles the LED on the ESP32.
Cool! Now I have the basis for building my own Matter device with Arduino. Thanks for your work on this library, Jakub!
From my perspective, this issue can be closed. Hope others can report successes with today's Home Assistant update.
Thanks for developing this library! I'm looking forward to learning about Matter.
I am running the light example on an ESP-WROOM-32. And, I'm running the beta Matter server on Home Assistant (2023.1.0b5).
After attempting to commission the device, the ESP32 says:
The Home Assistant Matter server says:
I'm not seeing a new device in Home Assistant.
Perhaps someone can provide some troubleshooting advice?
On the Home Assistant Raspberry Pi, bluetoothctl scan shows Bluetooth devices with addresses. Not sure what the address is of the ESP32. Maybe there's an easy way to add that to the light example sketch?
Thanks! Wayne