Shelly IoT Devices (Switches) Drop off Network with kernel 'not mesh client, can't delete it' messages

[jksmurf]

Hi

I have 2 Shelly 1PM Gen3's switching on and off Hot Water in the Main and Annex HW Cupboards.
They are on the 2.4GHz Wifi. None of my other 20-odd Shelly's have this issue.

Annex DCA:0C:B1:0A:18
MainHWC DCA:0C:B1:00:2C

They keep dropping off the Wifi at (every time) almost the exact same time.
They mostly come back up after 12-15 hours or so, not always after a Router reboot either.

The Router Logs show this:

Jul  8 18:08:16 kernel: DC:DA:0C:B1:0A:18 not mesh client, can't delete it
Jul  8 18:08:16 kernel: DC:DA:0C:B1:00:2C not mesh client, can't delete it
Jul  8 18:08:27 kernel: DC:DA:0C:B1:0A:18 not mesh client, can't delete it
Jul  8 18:08:27 kernel: DC:DA:0C:B1:00:2C not mesh client, can't delete it

Forum Check:
Seems a few others have had this with "Ignore" and Bump" and "No Solution" being go-to responses.

• https://www.snbforums.com/threads/not-mesh-client-cant-update-its-ip.73002/
• https://www.snbforums.com/threads/not-mesh-client-cant-delete-it.78274/
• https://www.snbforums.com/threads/s...address-not-mesh-client-cant-delete-it.77909/
• https://www.snbforums.com/threads/asus-rt-ax92u-new-firmware-3-0-0-4-386_45898.75132/
• https://www.snbforums.com/threads/ai-mesh-keeps-dropping.85263/

I do not use scribe. I do have Traffic Analyzer Statistics turned on.

I am leaning towards me needing RC Snubbers wired to each HWC Switch device (see Voltage Spikes, not sure if that is an issue or not), but if it's a Router Issue that is easier to fix (remotely).

I am on Merlin 3006.102.4 on an RT-AX86U Pro with 3 Mesh Nodes.

Would really appreciate any advice, it is driving us bonkers.
We changed the Shelly's from Shelly 1PM Gen 2 devices to Shelly 1PM Gen 3 a year ago thinking it fixed it, but it's happening again.

Thanks!

 

[JGrana]

I have a few Rachio Watering hubs that also tend to drop out - then rarely recover.
Also get the “not mesh client” messages - although Im not sure if the Rachio are the source.
As @RMerlin said:

These are just debugging output, as I said earlier in this thread, simply ignore them.

Some of these low cost, small, underpowered IoT devices have pretty rough WiFi/TCP implementations…
My 2 Rachio hubs are pretty important.
I ended up using some TP-Link Tapo smart plugs (which are quite stable) and run a ping script from cron. If one of the Rachios goes off-line I power cycle it and send me an email. Seems to get them back on-line.
I get an email every few days ;-)

 

[Clark Griswald]

I have an Orbit B-hyve set to GNP IoT without any issues.

 

[jksmurf]

I have a few Rachio Watering hubs that also tend to drop out - then rarely recover.
Also get the “not mesh client” messages - although Im not sure if the Rachio are the source.
As @RMerlin said:

Some of these low cost, small, underpowered IoT devices have pretty rough WiFi/TCP implementations…
My 2 Rachio hubs are pretty important.
I ended up using some TP-Link Tapo smart plugs (which are quite stable) and run a ping script from cron. If one of the Rachios goes off-line I power cycle it and send me an email. Seems to get them back on-line.
I get an email every few days ;-)

Thanks for the feedback. It’s odd though, it’s just these two (I have other identical models that don’t budge off the WiFi); odder still that both always drop off at almost the exact same time.

 

[JGrana]

Thanks for the feedback. It’s odd though, it’s just these two (I have other identical models that don’t budge off the WiFi); odder still that both always drop off at almost the exact same time.

Are those two in roughly the same location - i.e. distance from the router. Maybe a radio issue?
The Rachio hubs are in 2 different locations. Their WiFi just isn't robust.
Most other "little clients" work fine, very stable - TP-Link smart outlets, ecobee thermostats, Blink hubs.

 

[jksmurf]

Are those two in roughly the same location - i.e. distance from the router. Maybe a radio issue?
The Rachio hubs are in 2 different locations. Their WiFi just isn't robust.
Most other "little clients" work fine, very stable - TP-Link smart outlets, ecobee thermostats, Blink hubs.

Nope, one is literally 3m (9') (max 4m or 12') from the Router, on the same floor; the second (Annex) about 10m (30'), on a higher floor.

 

[JGrana]

Hmm, I’m stumped. Both at the same time…could it be during a DHCP refresh cycle? Somewhat sounds like something the router does during some kind of interval.

 

[maxbraketorque]

If your satellite routers are etherneted to your main router, have you tried running the satellite routers in AP mode rather than AI mesh mode?

I'm tossing that out there because I've got two locations running satellites in AP mode, and its been 100% stable at both locations.

 

[jksmurf]

Hmm, I’m stumped. Both at the same time…could it be during a DHCP refresh cycle? Somewhat sounds like something the router does during some kind of interval.

I really don’t know, I’m not familiar with exactly what happens during such a a refresh cycle.

If your satellite routers are etherneted to your main router, have you tried running the satellite routers in AP mode rather than AI mesh mode?

No, I haven’t TBH; but the reason is (and I just re-checked AIMesh tab), the devices are on the IoT SSIS but on the primary router. My wired nodes are great for 5GHz for Guests and Primary SSIDs, but the GNP limitations on numbers if interfaces means IoT does not stretch to the nodes.

This might mean weak Wi-Fi to the IoT device in the Annex HWC but the Main HWC is very close to the main router, as above. Plus I also have the Shelly’s on a fallback Wi-Fi to the Main SSID, same subnet though. I purposely kept the IoT devices on the same subnet as primary although it’s a different LAN in GNP. The reason for this is access to the devices and Shelly scripting that refers to fixed IP addresses.

I'm tossing that out there because I've got two locations running satellites in AP mode, and it’s been 100% stable at both locations.

Ok

 

[maxbraketorque]

The error message gives the impression that there is some attempt by the mesh system or the devices to switch to a node, so I wonder if the issue would occur if you turned off the nodes.

That aside, I didn't realize there was a limit on the number of SDNs that could be created. At my cabin, I have a guest network and an IOT network on my main/AP AX86U-Pro setup running under 102.5 alpha. I guess I'll have to read the GNP limitations thread sometime.

 

[jksmurf]

The error message gives the impression that there is some attempt by the mesh system or the devices to switch to a node, so I wonder if the issue would occur if you turned off the nodes.

Unfortunately I am unable (too scared in case they stay off) to test that atm, it's over 9k kms away .

That aside, I didn't realize there was a limit on the number of SDNs that could be created. At my cabin, I have a guest network and an IOT network on my main/AP AX86U-Pro setup running under 102.5 alpha. I guess I'll have to read the GNP limitations thread sometime.

There are a few things that are limited (a) numbers of SDNs under GNP, IIRC @bennor checked out the limit at one stage and it may be 6# and (b) Wifi Interfaces that can propagate to each Node, which is a function of the Codebase you have on the Nodes.

For Interface Limitations with GNP have a look here:

This feature can only be configured on the AiMesh router. Guest network is currently designed to allow the first set of each band (2.4G, 5G, 5G-1) available to the AiMesh node. Only one set is available for each band.

• https://www.asus.com/support/faq/1045327/
• https://www.snbforums.com/threads/a...to-broadcast-a-certain-ssid.95117/post-960873
• https://www.snbforums.com/threads/yazfi-lite-with-router-in-ap-mode.75121/post-948076
• https://www.snbforums.com/threads/c...owing-static-device-as-dhcp.94209/post-948847

For the Switch Capabilities of Ethernet Nodes using (associated with) GNP for VLANs, this is a (now long) good thread:

• https://www.snbforums.com/threads/switch-capabilities-of-aimesh-nodes.94562/

If short on time start at this post:

• https://www.snbforums.com/threads/switch-capabilities-of-aimesh-nodes.94562/post-955536

 

[maxbraketorque]

So, for my AX86U Pro main/AP combo, both of the isolated SDNs are on 2.4 GHz, and I have both SDNs setup on the main and AP routers. Each SDN is on its own subnet, and is deselected from communicating other networks. I also have the AP Isolated option selected. These two options only exist on the main router. I assumed the options only existed on the main router because the AP would read these directives from the main router.

I have assumed that both are working as intended on the AP, and for sure my IoT devices are populating both routers, but I have yet to verify that both SDNs are isolated when connected via the AP. I guess I'll be checking that this weekend. I must admit, I'll be a bit annoyed if both networks are not isolated because I expected that the new SDN system would have this feature.