"Matter over WiFi" + Matter Server Won't Retain Configuration

Configuration Matter/Thread
, , , ,
1

Hello,

I have been scouring the forums, using AI assisted troubleshooting, and tearing my hair out (not literally thankfully) trying to figure out what is going on with my Home Assistant OS install and why it won’t retain the Matter configuration for any paired devices.

I run Home Assistant OS within a TrueNAS 25.4.10 VM. Has been setup and working for ~2 years without issues, and previously had Apple HomeKit Bridge devices paired with Home Assistant even, and all was seemingly working great. I ended up creating my own custom router and after doing so the Apple HomeKit stuff stopped working with it, so I just removed it thinking that was likely just a router side issue and would get to it later. After that, I then just recently purchased the new Aqara W200 Thermostat that supposedly uses “Matter over WiFi” and therefore wouldn’t require a Thread radio in order to pair it… so I setup the Matter Server and started to pair it, and that did work (after some troubleshooting) and the device was working inside Home Assistant as well as paired with Apple Home and controlled fully… only to reboot Home Assistant and discover the device drops off of the config and never reconnects to the Matter Server.

In troubleshooting with AI and reviewing the forums, I haven’t been able to find other people having this issue, but according to the logs the device does pair, and shows an fe80 IPv6 Link-Local address even though I use IPv4 as my primary network config and don’t have IPv6 enabled on my router, just allow IPv6 packets to traverse the network. The path it says that the configuration files are being saved to ( /data/chip.json or other /data/chip* ini files) has never had the files saved to it and it says in the logs that it saved it, but it is clearly ONLY writing to memory and it will retain the config and the Thermostat works great… until I reboot, and then it’s back to having to re-pair the device every single time to Home Assistant.

I don’t know if there is something incorrect about the way the Home Assistant OS VM was installed (excuse my moderate knowledge, but from memory basically just used the qcow file and extracted it out to the zvol that was made in my VM datasets in TrueNAS), or if something along the way has somehow either lost permissions or what…

Using the AI recommendations, I had attempted to use touch to create the files and then change their permissions, but not even sure I did that part right… either way, it didn’t fix it, and I have uninstalled and re-installed Matter Server (and the device integration) several times to no avail.

This is what it shows when the device is paired:

(MainThread) INFO [chip.storage] Initializing persistent storage from file: /data/chip.json
(MainThread) INFO [chip.storage] Loading configuration from /data/chip.json...
(MainThread) INFO [chip.CertificateAuthority] Loading certificate authorities from storage...
(MainThread) INFO [chip.CertificateAuthority] New CertificateAuthority at index 1
(MainThread) INFO [chip.CertificateAuthority] Loading fabric admins from storage...
(MainThread) INFO [chip.FabricAdmin] New FabricAdmin: FabricId: 0x0000000000000002, VendorId = 0x134B
(MainThread) INFO [matter_server.server.stack] CHIP Controller Stack initialized.
(MainThread) INFO [matter_server.server.server] Matter Server initialized
(MainThread) INFO [matter_server.server.server] Using 'enp0s3' as primary interface (for link-local addresses)
(MainThread) INFO [matter_server.server.server] Starting the Matter Server...
(MainThread) INFO [matter_server.server.helpers.paa_certificates] Skip fetching certificates (already fetched within the last 24h).
(MainThread) INFO [chip.FabricAdmin] Allocating new controller with CaIndex: 1, FabricId: 0x0000000000000002, NodeId: 0x000000000001B669, CatTags: []
(MainThread) INFO [matter_server.server.vendor_info] Loading vendor info from storage.
(MainThread) INFO [matter_server.server.vendor_info] Loaded 414 vendors from storage.
(MainThread) INFO [matter_server.server.vendor_info] Fetching the latest vendor info from DCL.
(MainThread) INFO [matter_server.server.vendor_info] Fetched 413 vendors from DCL.
(MainThread) INFO [matter_server.server.vendor_info] Saving vendor info to storage.
(MainThread) INFO [matter_server.server.device_controller] Loaded 0 nodes from stored configuration
(MainThread) INFO [matter_server.server.server] Matter Server successfully initialized.
(MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning with code using Node ID 1.
(Dummy-2) INFO [chip.ChipDeviceCtrl] Established secure session with Device
(Dummy-2) INFO [chip.ChipDeviceCtrl] Commissioning complete
(MainThread) INFO [matter_server.server.device_controller] Commissioned Node ID: 1 vs 1
(MainThread) INFO [matter_server.server.device_controller] Matter commissioning of Node ID 1 successful.
(MainThread) INFO [matter_server.server.device_controller] Interviewing node: 1
(MainThread) INFO [matter_server.server.device_controller] <Node:1> Setting-up node...
(MainThread) INFO [matter_server.server.device_controller] <Node:1> Setting up attributes and events subscription.
(MainThread) INFO [matter_server.server.device_controller] <Node:1> Subscription succeeded with report interval [1, 60]
(MainThread) INFO [matter_server.server.device_controller] Commissioning of Node ID 1 completed.
(MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
(MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
(MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
(MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
(MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
(MainThread) INFO [matter_server.server.device_controller] <Node:1> The SDK is communicating with the device using fe80::56ef:44ff:fe9a:a24f

And then I saw this on a subsequent event:

(MainThread) INFO [chip.storage] Initializing persistent storage from file: /data/chip.json
(MainThread) ERROR [chip.storage] [Errno 2] No such file or directory: '/data/chip.json'
(MainThread) CRITICAL [chip.storage] Could not load configuration from /data/chip.json - resetting configuration...
(MainThread) WARNING [chip.storage] No valid SDK configuration present - clearing out configuration
(MainThread) WARNING [chip.storage] No valid REPL configuration present - clearing out configuration

I REALLY do not want to redo my entire VM and potentially lose anything here, but if anybody has any idea what has gone on here, and how I might fix it… that would be a huge help, and enable me to get things working properly.

EDIT: So for future people who may have TrueNAS VM issues with Home Assistant… I went back at it with the AI troubleshooting and discovered that the issue regarding the data retention with the chip.json file was actually (for whatever reason) that the Home Assistant OS VM was somehow giving the wrong write permissions to the folder / files and wasn’t retaining what was being written from the pairing. I was able to resolve the file retention / writing issues within the Matter Server with this command in the TrueNAS VM’s Serial Shell:

chmod 644 /mnt/data/supervisor/addons/data/core_matter_server/chip_*.ini
chmod 644 /mnt/data/supervisor/addons/data/core_matter_server/chip.json

It appears that Aqara has hardcoded something in the firmware for the Matter Hub side of the W200 Thermostat it is just ignoring the IPv4 address assigned to the device via the LAN (WiFi) DHCP settings it has been statically assigned, and refusing to pair with ANYTHING but the fe80 IPv6 link-local address… so the device still drops off of my Matter Server every reboot until / unless I can get Aqara to update that in their firmware.

I have contacted Aqara about all of that prior to this original posting, but so far they have not updated the firmware to allow for this (or allow toggling of IPv6 if you only want the pairing side of it and not the Matter Hub in it)

2

As far as i know IPv6 must be enabled in Router an manually in HA using the command:
ha docker options --enable-ipv6=true
in HA Terminal.
Matter Communication is IPv6 based.

3

I did run that to ensure the HA OS VM reflects internally that IPv6 is enabled (which externally it was, but previously internally it wasn’t), however this appears to have had no effect.

I uninstalled the Matter Server and rebooted, then reinstalled it… and this is the current output, yet again saying that it could not find the chip.json etc.

-----------------------------------------------------------
 Add-on: Matter Server
 Matter WebSocket Server for Home Assistant Matter support.
-----------------------------------------------------------
 Add-on version: 8.4.0
 You are running the latest version of this add-on.
 System: Home Assistant OS 17.2  (amd64 / qemux86-64)
 Home Assistant Core: 2026.4.3
 Home Assistant Supervisor: 2026.04.0
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
s6-rc: info: service banner successfully started
s6-rc: info: service matter-server: starting
s6-rc: info: service matter-server successfully started
s6-rc: info: service legacy-services: starting
INFO: Starting Matter Server...
: service legacy-services successfully started
INFO: Using Python Matter Server
INFO: Using 'enp0s3' as primary network interface.
INFO: Successfully send discovery information to Home Assistant.
(MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Logging...
(MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Controller Stack...
CHIP:CTL: Setting attestation nonce to random value
CHIP:CTL: Setting CSR nonce to random value
CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_kvs
CHIP:DL: Wrote settings to /tmp/chip_kvs
CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_factory.ini
CHIP:DL: Wrote settings to /data/chip_factory.ini
CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_config.ini
CHIP:DL: Wrote settings to /data/chip_config.ini
CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_counters.ini
CHIP:DL: Wrote settings to /data/chip_counters.ini
CHIP:DL: Wrote settings to /data/chip_factory.ini
CHIP:DL: NVS set: chip-factory/unique-id = "0B17497E51F4D5AC"
CHIP:DL: Wrote settings to /data/chip_factory.ini
CHIP:DL: NVS set: chip-factory/vendor-id = 65521 (0xFFF1)
CHIP:DL: Wrote settings to /data/chip_factory.ini
CHIP:DL: NVS set: chip-factory/product-id = 32769 (0x8001)
CHIP:DL: Wrote settings to /data/chip_counters.ini
CHIP:DL: NVS set: chip-counters/reboot-count = 1 (0x1)
CHIP:DL: Wrote settings to /data/chip_counters.ini
CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)
CHIP:DL: Wrote settings to /data/chip_counters.ini
CHIP:DL: NVS set: chip-counters/boot-reason = 0 (0x0)
CHIP:DL: Wrote settings to /data/chip_config.ini
CHIP:DL: NVS set: chip-config/regulatory-location = 0 (0x0)
CHIP:DL: Wrote settings to /data/chip_config.ini
CHIP:DL: NVS set: chip-config/location-capability = 2 (0x2)
CHIP:DL: Wrote settings to /data/chip_config.ini
CHIP:DL: NVS set: chip-config/configuration-version = 1 (0x1)
CHIP:DL: Got Ethernet interface: enp0s3
CHIP:DL: Found the primary Ethernet interface:enp0s3
CHIP:DL: Failed to get WiFi interface
CHIP:DL: Failed to reset WiFi statistic counts
CHIP:PAF: WiFiPAF: WiFiPAFLayer::Init()
(MainThread) INFO [chip.storage] Initializing persistent storage from file: /data/chip.json
(MainThread) ERROR [chip.storage] [Errno 2] No such file or directory: '/data/chip.json'
(MainThread) CRITICAL [chip.storage] Could not load configuration from /data/chip.json - resetting configuration...
(MainThread) WARNING [chip.storage] No valid SDK configuration present - clearing out configuration
(MainThread) WARNING [chip.storage] No valid REPL configuration present - clearing out configuration
(MainThread) INFO [chip.CertificateAuthority] Loading certificate authorities from storage...
(MainThread) INFO [chip.CertificateAuthority] New CertificateAuthority at index 1
(MainThread) INFO [chip.FabricAdmin] New FabricAdmin: FabricId: 0x0000000000000002, VendorId = 0x134B
(MainThread) INFO [matter_server.server.stack] CHIP Controller Stack initialized.
(MainThread) INFO [matter_server.server.server] Matter Server initialized
(MainThread) INFO [matter_server.server.server] Using 'enp0s3' as primary interface (for link-local addresses)
(MainThread) INFO [matter_server.server.server] Starting the Matter Server...
(MainThread) INFO [matter_server.server.helpers.paa_certificates] Fetching the latest PAA root certificates from DCL.
(MainThread) INFO [matter_server.server.helpers.paa_certificates] Fetched 74 PAA root certificates from DCL.
(MainThread) INFO [matter_server.server.helpers.paa_certificates] Fetching the latest PAA root certificates from Git.
(MainThread) INFO [matter_server.server.helpers.paa_certificates] Fetched 2 PAA root certificates from Git.
(MainThread) INFO [chip.FabricAdmin] Allocating new controller with CaIndex: 1, FabricId: 0x0000000000000002, NodeId: 0x000000000001B669, CatTags: []
(MainThread) INFO [matter_server.server.vendor_info] Loading vendor info from storage.
(MainThread) INFO [matter_server.server.vendor_info] Loaded 0 vendors from storage.
(MainThread) INFO [matter_server.server.vendor_info] Fetching the latest vendor info from DCL.
(MainThread) INFO [matter_server.server.vendor_info] Fetched 413 vendors from DCL.
(MainThread) INFO [matter_server.server.vendor_info] Saving vendor info to storage.
(MainThread) INFO [matter_server.server.device_controller] Loaded 0 nodes from stored configuration
(MainThread) INFO [matter_server.server.server] Matter Server successfully initialized.

Seems to have had no effect on retaining anything either, as the device dropped off after a subsequent reboot.

4

I pulled the IPv6 states , does this look correct from internal in the Terminal app within HA OS?

net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.accept_ra_defrtr = 1
net.ipv6.conf.all.accept_ra_from_local = 0
net.ipv6.conf.all.accept_ra_min_hop_limit = 1
net.ipv6.conf.all.accept_ra_min_lft = 0
net.ipv6.conf.all.accept_ra_mtu = 1
net.ipv6.conf.all.accept_ra_pinfo = 1
net.ipv6.conf.all.accept_ra_rtr_pref = 1
net.ipv6.conf.all.accept_redirects = 1
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_untracked_na = 0
net.ipv6.conf.all.addr_gen_mode = 0
net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.all.dad_transmits = 1
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.all.disable_policy = 0
net.ipv6.conf.all.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.all.drop_unsolicited_na = 0
net.ipv6.conf.all.enhanced_dad = 1
net.ipv6.conf.all.force_mld_version = 0
net.ipv6.conf.all.force_tllao = 0
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.all.hop_limit = 64
net.ipv6.conf.all.ignore_routes_with_linkdown = 0
net.ipv6.conf.all.ioam6_enabled = 0
net.ipv6.conf.all.ioam6_id = 65535
net.ipv6.conf.all.ioam6_id_wide = 4294967295
net.ipv6.conf.all.keep_addr_on_down = 0
net.ipv6.conf.all.max_addresses = 16
net.ipv6.conf.all.max_desync_factor = 600
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.all.mldv1_unsolicited_report_interval = 10000
net.ipv6.conf.all.mldv2_unsolicited_report_interval = 1000
net.ipv6.conf.all.mtu = 1280
net.ipv6.conf.all.ndisc_evict_nocarrier = 1
net.ipv6.conf.all.ndisc_notify = 0
net.ipv6.conf.all.ndisc_tclass = 0
net.ipv6.conf.all.proxy_ndp = 0
net.ipv6.conf.all.ra_defrtr_metric = 1024
net.ipv6.conf.all.ra_honor_pio_life = 0
net.ipv6.conf.all.ra_honor_pio_pflag = 0
net.ipv6.conf.all.regen_max_retry = 3
net.ipv6.conf.all.regen_min_advance = 2
net.ipv6.conf.all.router_probe_interval = 60
net.ipv6.conf.all.router_solicitation_delay = 1
net.ipv6.conf.all.router_solicitation_interval = 4
net.ipv6.conf.all.router_solicitation_max_interval = 3600
net.ipv6.conf.all.router_solicitations = -1
net.ipv6.conf.all.rpl_seg_enabled = 0
net.ipv6.conf.all.seg6_enabled = 0
sysctl: error reading key 'net.ipv6.conf.all.stable_secret': I/O error
net.ipv6.conf.all.suppress_frag_ndisc = 1
net.ipv6.conf.all.temp_prefered_lft = 86400
net.ipv6.conf.all.temp_valid_lft = 604800
net.ipv6.conf.all.use_oif_addrs_only = 0
net.ipv6.conf.all.use_tempaddr = 0

this is what it shows from ther Serial Terminal in the TrueNAS VM :

net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.accept_ra_defrtr = 1
net.ipv6.conf.all.accept_ra_from_local = 0
net.ipv6.conf.all.accept_ra_min_hop_limit = 1
net.ipv6.conf.all.accept_ra_min_lft = 0
net.ipv6.conf.all.accept_ra_mtu = 1
net.ipv6.conf.all.accept_ra_pinfo = 1
net.ipv6.conf.all.accept_ra_rtr_pref = 1
net.ipv6.conf.all.accept_redirects = 1
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_untracked_na = 0
net.ipv6.conf.all.addr_gen_mode = 0
net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.all.dad_transmits = 1
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.all.disable_policy = 0
net.ipv6.conf.all.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.all.drop_unsolicited_na = 0
net.ipv6.conf.all.enhanced_dad = 1
net.ipv6.conf.all.force_mld_version = 0
net.ipv6.conf.all.force_tllao = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.hop_limit = 64
net.ipv6.conf.all.ignore_routes_with_linkdown = 0
net.ipv6.conf.all.ioam6_enabled = 0
net.ipv6.conf.all.ioam6_id = 65535
net.ipv6.conf.all.ioam6_id_wide = 4294967295
net.ipv6.conf.all.keep_addr_on_down = 0
net.ipv6.conf.all.max_addresses = 16
net.ipv6.conf.all.max_desync_factor = 600
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.all.mldv1_unsolicited_report_interval = 10000
net.ipv6.conf.all.mldv2_unsolicited_report_interval = 1000
net.ipv6.conf.all.mtu = 1280
net.ipv6.conf.all.ndisc_evict_nocarrier = 1
net.ipv6.conf.all.ndisc_notify = 0
net.ipv6.conf.all.ndisc_tclass = 0
net.ipv6.conf.all.proxy_ndp = 0
net.ipv6.conf.all.ra_defrtr_metric = 1024
net.ipv6.conf.all.ra_honor_pio_life = 0
net.ipv6.conf.all.ra_honor_pio_pflag = 0
net.ipv6.conf.all.regen_max_retry = 3
net.ipv6.conf.all.regen_min_advance = 2
net.ipv6.conf.all.router_probe_interval = 60
net.ipv6.conf.all.router_solicitation_delay = 1
net.ipv6.conf.all.router_solicitation_interval = 4
net.ipv6.conf.all.router_solicitation_max_interval = 3600
net.ipv6.conf.all.router_solicitations = -1
net.ipv6.conf.all.rpl_seg_enabled = 0
net.ipv6.conf.all.seg6_enabled = 0
net.ipv6.conf.all.suppress_frag_ndisc = 1
net.ipv6.conf.all.temp_prefered_lft = 86400
net.ipv6.conf.all.temp_valid_lft = 604800
net.ipv6.conf.all.use_oif_addrs_only = 0
net.ipv6.conf.all.use_tempaddr = 0
5

If any of the developers (or those in the know) happen to know what devices are currently supported etc. under the 8.4.0 Matter Server, is “Matter over WiFi” currently properly supported within the Matter Server integration, with direct pairing over ethernet connections on the server through your LAN over WiFi with devices such as the Aqara W200 Thermostat?

Starting to wonder if there is a software limitation here that isn’t properly supporting the “Matter over WiFi” protocols since most people who use Matter are adding a third party Matter over Thread or other radio to Home Assistant (which I have not done, as I have no current intention on using Matter over Thread devices)

6

Trying to follow this, but sorry…can’t. Seems you fixed your file error problem, and have been able to pair a Aqara Matter/WiFi device, but then what?

One should expect to use the FE80 address to talk to the Aqara device and it should be on the same LAN/WiFi/IP network (i.e. flat).

7

So the issue I have now it seems, is related to how the device / Matter Server integration in Home Assistant reads the device and only seems to apply the IPv6 address at fe80 (link-local) even though I can ping the device’s IPv4 address both on my PC outside the VM, as well as inside the Home Assistant VM. The device responds and is active, and can be immediately re-paired, but for whatever reason (either in the firmware or in the Matter Server itself / app) it is ignoring the IPv4 address completely and as soon as I reboot (even though I fixed the data retention issue with those permission changes) it still disconnects and goes “unavailable” on reboot.

My router allows the IPv6 traffic on the network, but because I don’t want to use any of the IPv6 features of Matter etc, I just have Static IPv4 DHCP reservations for all devices on my LAN / WiFi network and outside this device (and my Apple HomeKit, whole other mess), everything else works perfectly inside Home Assistant and doesn’t drop or anything.

8

Matter by definition of the standard only uses IPv6. Matter/WiFi devices are indeed known to have IPv4 addresses, and the vendor’s app may use the ipv4 address, but the Matter Server is suppose to only use IPv6 for communication to the Matter devices.

Since you are only using Matter/WiFi, you should be OK with just using IPv6 link-local addresses (those starting with FE80), so should not need to have your routers, DHCP, etc. running IPv6 (just have it enabled in HA, and make sure HA is on a flat network with the Matter/WiFi device).

So if the Matter/WiFi device works fine during normal operation, but restarting Matter App causes the device to becom unavailable in HA never to show up again, then it kinda sounds like a retention problem still. Are you still seeing INFO [matter_server.server.device_controller] Loaded 0 nodes from stored configuration in the logs?

9

So from what I can tell, based on viewing the contents of the chip.json file, it is storing the encrypted info about the device and vendor etc.

This was the last reboot, before I paired the device… and haven’t rebooted it again afterward (as to not lose it yet again), but basically that fe80 address never comes back and it has no “cached IPs” when it reboots either

-----------------------------------------------------------
 Add-on: Matter Server
 Matter WebSocket Server for Home Assistant Matter support.
-----------------------------------------------------------
 Add-on version: 8.4.0
 You are running the latest version of this add-on.
 System: Home Assistant OS 17.2  (amd64 / qemux86-64)
 Home Assistant Core: 2026.4.3
 Home Assistant Supervisor: 2026.04.0
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
s6-rc: info: service banner successfully started
s6-rc: info: service matter-server: starting
s6-rc: info: service matter-server successfully started
s6-rc: info: service legacy-services: starting
INFO: Starting Matter Server...
s6-rc: info: service legacy-services successfully started
INFO: Using Python Matter Server
INFO: Using 'enp0s3' as primary network interface.
INFO: Successfully send discovery information to Home Assistant.
(MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Logging...
(MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Controller Stack...
CHIP:CTL: Setting attestation nonce to random value
CHIP:CTL: Setting CSR nonce to random value
CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_kvs
CHIP:DL: Wrote settings to /tmp/chip_kvs
CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_factory.ini
CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_config.ini
CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_counters.ini
CHIP:DL: Wrote settings to /data/chip_counters.ini
CHIP:DL: NVS set: chip-counters/reboot-count = 4 (0x4)
CHIP:DL: Got Ethernet interface: enp0s3
CHIP:DL: Found the primary Ethernet interface:enp0s3
CHIP:DL: Failed to get WiFi interface
CHIP:DL: Failed to reset WiFi statistic counts
CHIP:PAF: WiFiPAF: WiFiPAFLayer::Init()
:34.134 (MainThread) INFO [chip.storage] Initializing persistent storage from file: /data/chip.json
:34.134 (MainThread) INFO [chip.storage] Loading configuration from /data/chip.json...
:34.190 (MainThread) INFO [chip.CertificateAuthority] Loading certificate authorities from storage...
:34.190 (MainThread) INFO [chip.CertificateAuthority] New CertificateAuthority at index 1
:34.191 (MainThread) INFO [chip.CertificateAuthority] Loading fabric admins from storage...
:34.191 (MainThread) INFO [chip.FabricAdmin] New FabricAdmin: FabricId: 0x0000000000000002, VendorId = 0x134B
:34.191 (MainThread) INFO [matter_server.server.stack] CHIP Controller Stack initialized.
:34.191 (MainThread) INFO [matter_server.server.server] Matter Server initialized
:34.191 (MainThread) INFO [matter_server.server.server] Using 'enp0s3' as primary interface (for link-local addresses)
:34.192 (MainThread) INFO [matter_server.server.server] Starting the Matter Server...
:34.195 (MainThread) INFO [matter_server.server.helpers.paa_certificates] Skip fetching certificates (already fetched within the last 24h).
:34.196 (MainThread) INFO [chip.FabricAdmin] Allocating new controller with CaIndex: 1, FabricId: 0x0000000000000002, NodeId: 0x000000000001B669, CatTags: []
:34.234 (MainThread) INFO [matter_server.server.vendor_info] Loading vendor info from storage.
:34.236 (MainThread) INFO [matter_server.server.vendor_info] Loaded 416 vendors from storage.
:34.237 (MainThread) INFO [matter_server.server.vendor_info] Fetching the latest vendor info from DCL.
:35.250 (MainThread) INFO [matter_server.server.vendor_info] Fetched 415 vendors from DCL.
:35.250 (MainThread) INFO [matter_server.server.vendor_info] Saving vendor info to storage.
:35.257 (MainThread) INFO [matter_server.server.device_controller] Loaded 0 nodes from stored configuration
:35.262 (MainThread) INFO [matter_server.server.server] Matter Server successfully initialized.
:38.093 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning with code using Node ID 1.
:38.302 (Dummy-2) INFO [chip.ChipDeviceCtrl] Established secure session with Device
:39.034 (Dummy-2) INFO [chip.ChipDeviceCtrl] Commissioning complete
:39.035 (MainThread) INFO [matter_server.server.device_controller] Commissioned Node ID: 1 vs 1
:39.035 (MainThread) INFO [matter_server.server.device_controller] Matter commissioning of Node ID 1 successful.
:39.035 (MainThread) INFO [matter_server.server.device_controller] Interviewing node: 1
:39.491 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Setting-up node...
:39.493 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Setting up attributes and events subscription.
:39.697 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Subscription succeeded with report interval [1, 60]
:39.697 (MainThread) INFO [matter_server.server.device_controller] Commissioning of Node ID 1 completed.
:42.640 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
:42.647 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
:56.740 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
:56.742 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
:58.153 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Node could not be discovered on the network, returning cached IP's
:58.155 (MainThread) INFO [matter_server.server.device_controller] <Node:1> The SDK is communicating with the device using fe80::56ef:44ff:fe9a:a24f

IPv6 is set to automatic in the Home Assistant network settings, and yet it still doesn’t seem to be able to communicate internally with the device after it handshakes and pairs it and reboots. A restart retains the info, it only happens on full reboot.

One thing the AI pointed out, was that the device is not able to be found on the network within 3 seconds after pairing. So I don’t know if there is a firmware issue in the device, or if that is “normal” behavior… but regardless, it acts like it has no clue how to find it

10

Interesting… I think a restart of the matter server app will remount the same volume so the files would be retained, but by full reboot, I presume you mean the HA VM… at which point the volume may be mounted on something else??? Still seems like the file used to store the node data is disappearing on a HAOS. I guess my suspicion starts from the need for you to change the file permissions… that shouldn’t be necessary. So kind of wondering if the storage mount you had to give permission to is still a problem.

11

So that is likely a possibility, but the only files I am aware of that it’s using were the chip.json and chip_*.ini files in that folder. If there is a different location for the network location information that relates to the Matter Server config (since it apparently uses some form of docker container within the VM) then I would need more info about what to look at

What is really strange is that you’re right, I shouldn’t have to manage the permissions on it. The ONLY thing I can come up with that caused that, was a recent change on the TrueNAS 25.4.10 version that did something with permissions displaying etc, and I had to migrate the VM over because of them shifting VMs to using a different underlying architecture. I may have to redo the VM entirely, but I really am trying to avoid that if possible.

12

I think the pertinent files are in the “data” directory. I don’t use the Python based Matter Server anymore so I can’t check.

13

Does that mean that the alternative “beta” version is better in some regard either for this situation or something else? I know it’s there, but I honestly am fairly new to Linux based operating systems, so I don’t truly understand what half of this all will do to impact this… and what’s odd is that even HomeKit worked a year or so ago before I changed my router over to my new custom router, but I cannot recall when it stopped working for sure. I just know it was all around the time I migrated TrueNAS to 25.4.10 with that change, and the new router setup.

I really do not want to rebuild the VM… but you’re making me second guess that

14

I kinda doubt Beta will make a difference, but not much harm in trying it. Just flip the Beta switch in the config of the Matter Server App and restart it. It keeps the python code; just migrates the data and uses the js code; You can unflip the switch (restart) and go back to the python version too.

15

Hrmmm… so I just poked around in the /mnt/data folder and found in the internal docker folder for the HAOS VM that it’s docker.json file reads out:

 cat docker.json
{
  "registries": {},
  "enable_ipv6": false,
  "mtu": null

I don’t know if that’s JUST for Docker itself, or if it relates or not though

16

Well… I rebuilt the VM, and imported my backup and it has the same issue. I guess the next thing I have to do is NOT import my backup to find out if the whole thing got messed up

EDIT: Redid the VM yet again, paired the Matter device directly on first start with a brand new installation and brand new Matter Server config, as soon as I reboot, it drops it.

So something is going on with the Aqara Thermostat W200 device, it’s GOT to be firmware related unless the VM in TrueNAS is not receiving proper permissions to write something, somewhere… Or there is a software conflict in the Matter Server config for users that do not have a Thread radio attached to the Matter Server.

17

So it turns out this file seems to have been the root cause of the IPv6 stuff not working, and now with that turned to "true" I can ping the IPv6 addresses in my router's DHCPv6 settings, but still trying to figure out how to make that work inside of the TrueNAS VM since it aparently uses the TrueNAS Docker network that is shared with native Docker apps ...
18

That’s not accurate. I mean, maybe you can configure it that way, but that’s certainly not the default behavior.

I don’t have any Matter-over-Wi-Fi devices to test, so I can’t really offer any specific help. But out of curiosity, have you created a bridge on TrueNAS and used that bridge as the network device for your VM? If not, that may be the missing piece to your puzzle.

19

Well, my lingo may not be “accurate”, however I can assure that prior to making that change, I was not able to ping ANY of the devices from the Home Assistant OS VM (host terminal or not) on the IPv6 (which I guess even Matter over WiFi requires, at least with the Aqara W200)



I have always had the bridge running on TrueNAS ever since 25.4 was released, and have not had ANY issues with any of my other stuff, excluding "Matter over WiFi" and Apple HomeKit Bridge from HAOS not pairing with my Apple Home since upgrading to the custom router and TrueNAS OS to 25.4.10.

I couldn’t ping in / out of the HAOS terminal app on the IPv6 network AT ALL until I turned that to “true”.

 cat docker.json
{
  "registries": {},
  "enable_ipv6": false,
  "mtu": null

Now I can ping the devices on the IPv6 address I assigned in the fd00 range on my Router, from within the HAOS terminal app, as well as from the serial shell in the TrueNAS host, but I still cannot pair the HomeKit Bridge (and temporarily took the thermostat off the wall, because it was driving me insane unpairing as weather heats up)

20

Well… I’m at my witts end here…

I temporarily reverted to trying to remedy the Apple Home / HomeKit integration with the HomeKit Bridge in my Home Assistant OS VM, and I am able to ping the fd00::/64 network and all devices that are receiving IPv6 addresses i’ve statically assigned on it, and ensured it is not leaking external IPv6 DNS traffic, but IS broadcasting mDNS (confirmed with more and more AI use to troubleshoot) and the ONLY thing I can’t figure out is why I can ping everything and mDNS is working on the router / network… but cannot pair the HomeKit Bridge to the phone app either.

The part that seems to baffle the AI (and myself) is that the default behavior of Home Assistant’s internal docker network is that it is ONLY getting a 172 / 173 network and does not broadcast using the network bridge that it pulls (as evidenced in the TrueNAS VM serial shell / console.

If I attempt to add the mDNS broadcast of that interface, it does not appear to work either… and… it just resets and reverts to default the minute you reboot since it is supervised and a limited permission environment with the HAOS VM.

…

I’m at a loss here. I’m about to completely throw my Apple stuff out the window because it’s pointless when it straight functions in and of itself on the network, can interact with all of it via the Apple Home app, play music on HomePods etc, I could even pair the Aqara Thermostat W200 Hub to it as well… but the moment I attempt to pair the Home Assistant HomeKit Bridge with it, forget about it… it doesn’t work.

Since I enabled IPv6 on the router now and all, I am tempted to attempt to reinstall the Thermostat on the wall and see if Matter works now, but I’m feeling buried here and failing to understand what in the heck is going on with my network setup.

If anybody has ideas and patient enough to try to work through some of this, I could surely use the help!