AI Blade lights (BLE-only, no Thread mesh address) can't be reached as relayed devices

marine-ecologist commented

2026-09-29 00:10:49 +01:00

I have one tank with 2x AI Blade, 1x Nero 3 and 1x Axis 40, all advertising the same pan_id. The two pumps are on the Thread mesh. The Blades are not: they share the pan_id in their advertisement but have no mesh-local address, so they cannot be reached through a gateway with RelayedMobiusDevice.

If the integration groups by pan_id and reads every non-gateway member through the relay, the Blades would presumably never become readable (unless one of them is the gateway itself, and then the pumps are the ones left out). I haven't yet run this integration against the tank, so this is based on reading the code and on python-mobius results below, not on a failing HA install.

Hardware and what python-mobius reports (python-mobius 0.9.0)

Device	Model (raw)	Primitive type	On Thread mesh
Axis40	Axis40 (262)	TurtleV1	yes
Nero3	Nero3 (257)	PumpV1	yes
BladeCoralGlow	361	VisualV1	no
BladeCoralGrow	362	VisualV1	no

Blade firmware: Radio Firmware 1.2.8; hardware ProductType: AI Light, RadioType: ESP32C3.
Blade group_mask is 2305843009213693955 (bits 0, 1 and 61 set); pumps report 3. Both resolve to tank group 2 via tank_group().

All four devices read, and schedules dump, correctly over direct BLE (Blades) or gateway relay (pumps).

Evidence the Blades can't be relayed
mobius-scan --by-serial <gateway> --relay-target <blade serial>:

The gateway's NetworkedThreadDevices lists only the two pumps.
"Not reported by ... mesh peer list -- trying a brief direct connection ... to learn its address..."
"didn't report a valid mesh address -- cannot relay to it."
The same command relays to the Nero without problems.

Suggested behaviour
When a device has the same pan_id but no valid mesh address (or fails relay after discovery), poll it over its own direct BLE connection instead of treating it as a relay member, and don't count it as a gateway candidate for mesh-only peers.

Other findings that may be useful
start_scene() broadcasts to the tank group by default. With Blades and pumps sharing group 2, a Feed Mode started with the default would reach both types. broadcast=False affects only the target device (verified on the Axis and the Nero over direct BLE).

start_scene(FeedMode, 20) still reported timeout_seconds=3600 on both pumps, so the duration argument did not shorten the scene as expected.

I'm happy to test a branch against this tank, and thanks again for all your work!

I have one tank with 2x AI Blade, 1x Nero 3 and 1x Axis 40, all advertising the same pan_id. The two pumps are on the Thread mesh. **The Blades are not**: they share the pan_id in their advertisement but have no mesh-local address, so they cannot be reached through a gateway with RelayedMobiusDevice. If the integration groups by pan_id and reads every non-gateway member through the relay, the Blades would presumably never become readable (unless one of them is the gateway itself, and then the pumps are the ones left out). I haven't yet run this integration against the tank, so this is based on reading the code and on python-mobius results below, not on a failing HA install. **Hardware and what python-mobius reports (python-mobius 0.9.0)** | Device | Model (raw) | Primitive type | On Thread mesh | |:---------------|:--------------|:---------------|:---------------| | Axis40 | Axis40 (262) | TurtleV1 | yes | | Nero3 | Nero3 (257) | PumpV1 | yes | | BladeCoralGlow | 361 | VisualV1 | no | | BladeCoralGrow | 362 | VisualV1 | no | Blade firmware: Radio Firmware 1.2.8; hardware ProductType: AI Light, RadioType: ESP32C3. Blade group_mask is 2305843009213693955 (bits 0, 1 and 61 set); pumps report 3. Both resolve to tank group 2 via tank_group(). All four devices read, and schedules dump, correctly over direct BLE (Blades) or gateway relay (pumps). **Evidence the Blades can't be relayed** `mobius-scan --by-serial <gateway> --relay-target <blade serial>:` The gateway's NetworkedThreadDevices lists only the two pumps. `"Not reported by ... mesh peer list -- trying a brief direct connection ... to learn its address..."` `"didn't report a valid mesh address -- cannot relay to it."` The same command relays to the Nero without problems. **Suggested behaviour** When a device has the same pan_id but no valid mesh address (or fails relay after discovery), poll it over its own direct BLE connection instead of treating it as a relay member, and don't count it as a gateway candidate for mesh-only peers. **Other findings that may be useful** `start_scene()` broadcasts to the tank group by default. With Blades and pumps sharing group 2, a Feed Mode started with the default would reach both types. `broadcast=False` affects only the target device (verified on the Axis and the Nero over direct BLE). `start_scene(FeedMode, 20)` still reported `timeout_seconds=3600` on both pumps, so the duration argument did not shorten the scene as expected. I'm happy to test a branch against this tank, and thanks again for all your work!

r3pek commented

2026-09-29 17:22:09 +01:00

Owner

wanna try the latest code on https://code.r3pek.org/r3pek/python-mobius ? Should have the fix for everything. didn't release any ha-mobius version yet, but if it's easier I can do a beta version...

wanna try the latest code on https://code.r3pek.org/r3pek/python-mobius ? Should have the fix for everything. didn't release any `ha-mobius` version yet, but if it's easier I can do a beta version...

marine-ecologist commented

2026-09-30 00:12:40 +01:00

Author

I tried the latest python-mobius from your repo. On my tank (2x AI Blade, an Axis40 and a Nero3, all on one pan_id), mobius-scan --by-serial <Axis> --relay-target <Blade> now says the Blade is Bluetooth-only and connects to it directly.

It read the BladeCoralGlow correctly: VisualV1, no errors, schedule and channel intensities all present. I got the same result on repeated runs, and ran your test suite (625 passing).

Amazing.

I'm installing HA on a spare pi now, let me know when the beta is up and I'll test it against the Blades!

I tried the latest python-mobius from your repo. On my tank (2x AI Blade, an Axis40 and a Nero3, all on one pan_id), `mobius-scan --by-serial <Axis> --relay-target <Blade>` now says the Blade is Bluetooth-only and connects to it directly. It read the BladeCoralGlow correctly: VisualV1, no errors, schedule and channel intensities all present. I got the same result on repeated runs, and ran your test suite (625 passing). Amazing. I'm installing HA on a spare pi now, let me know when the beta is up and I'll test it against the Blades!

r3pek commented

2026-09-30 00:49:21 +01:00

Owner

Glad it's fixed 😉 I'll probably release it tomorrow.

Anything else just report back.

Glad it's fixed 😉 I'll probably release it tomorrow. Anything else just report back.

r3pek closed this issue

2026-09-30 00:49:22 +01:00

r3pek commented

2026-09-30 00:57:12 +01:00

Owner

just to try and confirm available features on the AI stuff (i don't have any of it, so all AI pumps/lights are done kinda "blind"), can you run --dump-attributes on them and attach them here?

just to try and confirm available features on the AI stuff (i don't have any of it, so all AI pumps/lights are done kinda "blind"), can you run `--dump-attributes` on them and attach them here?

Rows
Columns

AI Blade lights (BLE-only, no Thread mesh address) can't be reached as relayed devices #4