Google Nest loses Matter bridged devices after Matter bridge reboot

[DenysKalyni]

I have Google Nest Gen 2 as a Matter controller for testing devices under development. Right now, I am developing Matter bridge device based on ESP32 MCU. I have connected it to controller and I am successfully using it as intended (bridged devices, when added by the bridge, are also added to Google Home App and to the controller GUI). The problem arises when I need to reboot my Matter bridge MCU, my controller 'loses' all bridged devices:
- MCU disconnects due to reboot -> bridge and its bridged devices are shown as 'offline'
- as MCU re-connects to the controller -> bridge is shown as 'online', bridged devices are shown as 'offline' at first, then they are removed from GUI shortly after.
Temporarily, I can delete and then re-add all bridged devices. This way devices could be added after bridge rebooting, but it is not suitable for the release version.
I also added my bridge device to chip-tool fabric for debugging purposes. After bridge MCU reboot, as I described earlier, Google Nest loses bridged devices. However, I can see all bridged devices with chip-tool by checking enabled endpoints list, and control all bridged devices, meaning that all bridged devices' information is present on bridge MCU and it should be accessible to primary controller (Google Nest).
Where should I look into first to resolve my issues?

[armen_dpe]

Have you implemented your own device firmware from scratch or are you using the CHIP repository as a base for your Matter bridge?
Can you please open an issue tracker here and reply back with bug id number. I'm going to forward your tracker to internal teams for further investigation.

 

[DenysKalyni · Accepted solution]

Thank You for reply.
I left issue tracker as instructed. I am using esp-matter SDK (Espessif's derivative of CHIP repository) for my device, and I used their Matter-Zigbee bridge example project and modified it to my needs.

[Jpadie]

Can you post see whether there is a change of ipv6 address of the esp and the nest mini before and after the event please.  Idem the ipv4.  

I've been participating in some discussions where similar behaviour is shown after the gateway IP address changes. 

My suspicion is that the nest mini does not handle IP address changes well and after a change takes a long time to rerun ipv6 neighbour discovery.  

If you're looking for a ZigBee bridge I have written a full implementation for node red.  https://github.com/jpadie/node-red-virtual-matter-devices.  

[armen_dpe]

Thanks for sharing. We forwarded the issue to internal teams for further investigation.

[armen_dpe]

Hi Denys,
Can you please share the binary and details of your ESP32 target (M5 Stack? Other?) in the issue tracker you reported. Thanks!

[Jpadie]

I am also seeing something similar; using a fully patched matter.js implementation as the environment for creating the synthetic devices.  In the logs generated by matter.js I can see that the nest device is querying the matter server and retrieving device state but this is not reflected in to google home.  The online status of the Matter Hub (an aggregator node) is offline in the same way as the synthetic lights, curtains and other virtual devices are all offline (no interactive GUI presented and greyed out in the devices page of google home).  

I have been seeing this inconsistency with google home since starting to test with it towards the end of Summer 2024.  

[Jpadie]

still happening.  

seems to be linked to a change in the google hub slaac addresses.  probably inadequate frequency of updating the neighbour cache perhaps. 

in the matter logs I see comms when checking the device details from the app.  the comms seem to be from the phone to the hub, from the IP addresses; which is not the way that other vendors have implemented things.  

Disabling IPv6 on the router has brought the devices back on line for me, and maintained the automations that involve those devices.

Seems a terrible work-around.