#HA can no longer add NL bulbs (thread/matter)

1 messages · Page 1 of 1 (latest)

cinder crystal
#

Post your recent experiences here

#

HA can no longer add NL bulbs (thread/matter)

#

Context: 2 BRs were power cycled and about 7/15 bulbs did not recover. The usual process of power cycling and HA resets did not work. I tried repairing the bulbs and could not add them to HA, but could add them to GH and/or nanoleaf. I could not add them from GH to HA.

Error when commissioning via android companion app

2023-11-05 18:44:53 core-matter-server chip.CTL[126] ERROR Mdns discovery timed out
2023-11-05 18:44:53 core-matter-server matter_server.server.client_handler[126] ERROR [547389726352] Error handling message: CommandMessage(message_id='28a7ea72b17f4a4d87cafa592c669cde', command='commission_on_network', args={'setup_pin_code': 86370464})
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/matter_server/server/client_handler.py", line 188, in _run_handler
    result = await result
             ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/matter_server/server/device_controller.py", line 221, in commission_on_network
    raise NodeCommissionFailed(
matter_server.common.errors.NodeCommissionFailed: Commission on network failed for node 65

Error when sharing from GH to HA:

2023-11-05 18:49:03 core-matter-server chip.CTL[126] ERROR Commissioning discovery over BLE failed: src/platform/Linux/bluez/ChipDeviceScanner.cpp:173: CHIP Error 0x00000032: Timeout
2023-11-05 18:49:03 core-matter-server chip.-[126] ERROR src/platform/Linux/bluez/ChipDeviceScanner.cpp:173: CHIP Error 0x00000032: Timeout at src/controller/SetUpCodePairer.cpp:324
2023-11-05 18:49:03 core-matter-server chip.BLE[126] ERROR BLE scan error: src/platform/Linux/bluez/ChipDeviceScanner.cpp:173: CHIP Error 0x00000032: Timeout
#

Error also present in 4.10.1

young rampart
#

Adding a NL bulb to GH works without issue, and that is repeatable with several NL bulbs. Trying to share them to HA or add directly to HA results in a wacky series of results.

Example: Adding a light last night from GH to HA did actually work, however its been unavailable for the last 12 hours. GH can see and interact with the same light no problems, HA is complaining about timeouts (CHIP and mDNS):

2023-11-06 11:44:41 core-matter-server chip.CSM[126] DEBUG FindOrEstablishSession: PeerId = [1:0000000000000001]
2023-11-06 11:44:41 core-matter-server chip.CSM[126] DEBUG FindOrEstablishSession: No existing OperationalSessionSetup instance found
2023-11-06 11:44:41 core-matter-server chip.DIS[126] DEBUG OperationalSessionSetup[1:0000000000000001]: State change 1 --> 2
2023-11-06 11:44:41 core-matter-server chip.DIS[126] INFO Checking node lookup status after 200 ms
2023-11-06 11:45:12 core-matter-server chip.DIS[126] ERROR Timeout waiting for mDNS resolution.
2023-11-06 11:45:26 core-matter-server chip.DIS[126] INFO Checking node lookup status after 45002 ms
2023-11-06 11:45:26 core-matter-server chip.DIS[126] ERROR OperationalSessionSetup[1:0000000000000001]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout
2023-11-06 11:45:26 core-matter-server matter_server.server.device_controller[126] WARNING Unable to subscribe to Node 1 as it is unavailable, will retry later in the background.```
#

Sharing a working light from GH to HA presents CHIP and mDNS timeouts (mDNS works fine, and there are no custom settings in place to manipulate IGMP or mDNS as a whole):

2023-11-06 12:05:39 core-matter-server matter_server.server.client_handler[126] DEBUG [139937325145104] Received: {
  "message_id": "1d2bd773957c4cfbb3c0b0de471ed00c",
  "command": "commission_with_code",
  "args": {
    "code": "01730933899"
  }
}
2023-11-06 12:05:39 core-matter-server matter_server.server.client_handler[126] DEBUG [139937325145104] Received CommandMessage(message_id='1d2bd773957c4cfbb3c0b0de471ed00c', command='commission_with_code', args={'code': '01730933899'})
2023-11-06 12:05:39 core-matter-server matter_server.server.client_handler[126] DEBUG [139937325145104] Handling command commission_with_code

2023-11-06 12:05:51 core-matter-server chip.CTL[126] ERROR Commissioning discovery over BLE failed: src/platform/Linux/bluez/ChipDeviceScanner.cpp:173: CHIP Error 0x00000032: Timeout
2023-11-06 12:05:51 core-matter-server chip.-[126] ERROR src/platform/Linux/bluez/ChipDeviceScanner.cpp:173: CHIP Error 0x00000032: Timeout at src/controller/SetUpCodePairer.cpp:324
2023-11-06 12:05:51 core-matter-server chip.BLE[126] ERROR BLE scan error: src/platform/Linux/bluez/ChipDeviceScanner.cpp:173: CHIP Error 0x00000032: Timeout
2023-11-06 12:05:51 core-matter-server chip.BLE[126] INFO Scan complete. No matching device found.
2023-11-06 12:06:11 core-matter-server chip.CTL[126] ERROR Discovery timed out
2023-11-06 12:06:11 core-matter-server chip.CTL[126] DEBUG Stopping commissioning discovery over DNS-SD
2023-11-06 12:06:11 core-matter-server chip.ZCL[126] ERROR Secure Pairing Failed
2023-11-06 12:06:11 core-matter-server matter_server.server.client_handler[126] ERROR [139937325145104] Error handling message: CommandMessage(message_id='1d2bd773957c4cfbb3c0b0de471ed00c', command='commission_with_code', args={'code': '01730933899'})
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/matter_server/server/client_handler.py", line 188, in _run_handler
    result = await result
             ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/matter_server/server/device_controller.py", line 173, in commission_with_code
    raise NodeCommissionFailed(
matter_server.common.errors.NodeCommissionFailed: Commission with code failed for node 14
2023-11-06 12:06:12 core-matter-server chip.DIS[126] ERROR Timeout waiting for mDNS resolution.```
#

Matter server version is 4.10.2, non-beta

young rampart
#

FWIW, the light I shared to HA yesterday has finally recovered (16 hours later), however is in a constant 5-10 minute unavailable cycle. The same light in GH does not exhibit the same behaviour.

vestal owl
#

I wonder if there is different hardware revisions that they don’t state, it’s strange seeing such a high variance of a failure rate between the “same” device

young rampart
#

Not sure, though I'm not game enough to pull a couple apart and find out

#

you'd think FW updates should make up for some hardware variances though

#

That said, I've also bought one of these: https://www.gl-inet.com/products/gl-s200/ to act as the 'main' border router (HA can see it no problem). Really neat little unit. Added onto the existing home-assistant created network by the same Network Key the NL Android app provided, so they're all working together. It also shows a dynamic mesh image for each of the Thread Leader, Router and End Devices.

#

inb4 that unit causing the unavailability in HA; it's not as right now it is disconnected while I add the rest of my lights into GH and it's still experiencing the same problems.

bitter parrot
young rampart
bitter parrot
#

Oh yeah that is really nice. I hope that someday we could make a nice UI showing the entire mesh(es) with all border routers and routing devices and end devices.

young rampart
#

Example image of mine at the moment: https://i.imgur.com/5Ge4hHU.png

Doesn't identify devices per se (not by a friendly name) but I can work out which devices are router and end device.

vestal owl
#

Also. This just seems like the open thread add-on, with the skyconenct /external thread dongle

desert cargo
vestal owl
#

the gl-s200 just seems to be more dev orientated

young rampart
young rampart
#

the PSU that comes with doesn't have an AU plug, but it's only 5V 2A USB-C, so any decent phone charger can run it.

vestal owl
young rampart
vestal owl
#

prices in usd?

young rampart
#

$93US inc. $22 shipping (DHL for you 🤷‍♂️ )

#

yeah

vestal owl
#

not bad

#

the Dev Board looks interesting

young rampart
#

also PoE capable

vestal owl
#

now that is really good

young rampart
#

that one doesn't appear to have public pricing (yet)

vestal owl
#

no pricing on their store it seems, must just be announced, and shipping soon

#

yea

young rampart
#

couldn't imagine it would be more than $50USD

vestal owl
#

yeah, would be sick if it was on amazon soon

#

they seem to have an IOT section on their storefront

young rampart
#

yep, noticed that too

vestal owl
#

might just ask their sales team, no doubt they would be keen to get it out to the public

young rampart
#

for context, this is the level of info the GL-S200 is showing for my Thread network (redacted all the things 🤷‍♂️ ) - https://i.imgur.com/Rj3Vcij.png

young rampart
vestal owl
#

seems just like the OBTR add-on in HA, just its in a router.

#

the gui is nice tho

young rampart
#

I haven't found the OTBR addon give this level of info in this kind of format though

vestal owl
#

oh for sure, its alot more user friendly.

#

the obtr add-on is more orintated towards devs tho

young rampart
#

and in a world where NL and HA don't get along, this level of info is incredibly convenient rather than scour through all the logs.

vestal owl
#

ya

#

got there eventually 🤣

young rampart
#

3 goes, 2 letters

#

yeesh

#

🙂

bitter parrot
bitter parrot
vestal owl
#

there is, config > network > enable web port to 8080.

then you can just web connect to it

young rampart
#

ahhh yeah, fair point

desert cargo
desert cargo
turbid token
young rampart
desert cargo
young rampart
desert cargo
young rampart
desert cargo
#

But I would expect some hiccups since it’s running on FreeRtos

young rampart
#

the S200 is OpenWRT, the S20 is FreeRTOS

desert cargo
#

Most border routers right now are based on some sort of Linux kernel