Troubleshooting ASUS AI Mesh Router Problems [Support]

[Marfre888]

Describe your problem

Hi, I have recently upgraded my networking setup from ASUS AC (1x AC5300 + 2x AC86u) line of routers to ASUS AX routers (1x AX11000 + 3x AX6100). They work flawlessly together, and it goes to show how far they've come since releasing their AC routers. In fact, I think ASUS is the best company in term of AX routers, as Unifi seem to be a bit slow updating their line of products,

ASUS is well-loved for its networking products. However as great as they are, and as happy as I am to be one of their customers for the past 10years, one problem has continued to plague it. I am of course referring to the inability of this plugin to fully function with this network configuration. I want to try and understand as specifically as possible what is causing this problem in the hopes that ASUS will address the problem, or at least provide us with a solution.

So here goes;

Describe what you have tried so far

So firstly it is important to note that all my nodes use ethernet backhaul, and are connected via AiMesh 2.0

I am able to make use of this plugin as long as the devices I want to use are connected to the main router, however, the second devices move to a mesh node I am unable to control them using this plugin. They obviously still respond via WebUi

I have a test shelly setup, and I want to try and understand what is causing this.

Firstly I downloaded an iPhone app called 'Discovery- dns-sd browser' which is meant to discover bonjour/mdns devices. This app is able to discover the Shelly devices on all the nodes I am connected to on the network under '_http._tcp.' protocol'.

Secondly, I installed 'npm install -g shellies', and discovered that the test shelly connected to the mesh node is indeed discoverable, and restarting the homebridge-shelly plugin adds the test shelly into Homekit. What I've observed under the homebridge-shelly GUI is that despite it appearing as Online, the refresh timer does not update when connected to a mesh node. Ok, so does that mean multicast mdns is not a problem?

I then proceeded the run 'netcat' as instructed by the wiki. The two devices connected to the main router would periodically send commands, however, in over 30minutes, the test shelly connected to a mesh node did not. I also tried several LAN/Wifi configurations but this did not change the problem.

So my question is, is that a CoAP issue? Is there any way to fix it using a routing table? and can I provide ASUS with any data that could help them get to the issue and fix it once and for all?

Environment:

• Shelly device(s): Shelly 2.5s, Shelly 1PMs, Shelly Dim2, Shelly RGBW2
• Plugin version: 0.18.0
• Device running homebridge: Raspberry Pi (Managed switch (w/ all IoT hubs connected to router)

[Nisse57]

it might be worth trying turning off IGMP snooping in the switch #279

[Marfre888]

it might be worth trying turning off IGMP snooping in the switch #279

With IGMP snooping disabled on the switch 'shellies listen' fails to see it

However the nodes are connected to the router, not to the switch, the router also have the option to enable/disable IGMP snooping, will try this an revert back

[Marfre888]

it might be worth trying turning off IGMP snooping in the switch #279

With IGMP snooping disabled on the switch 'shellies listen' fails to see it

However the nodes are connected to the router, not to the switch, the router also have the option to enable/disable IGMP snooping, will try this an revert back

Disabling IGMP snooping in the wifi settings on the router makes no noticeable change. When disabling multicast routing in the LAN settings, this prevented all shellies devices connected to the mesh nodes to reconnect automatically

[try-and-error-and-repeat]

Make sure your Shelly has the latest firmware (v1.10.1), go to the Internet & Security --> Advanced Developer Setting --> Enable CoIoT --> change the CoIoT peer: from mdns to the IP of your Homebridge (port is automaticly set) . Restart Your Shelly and after that restart your HB and your Shelly should be discovered

[Marfre888]

Make sure your Shelly has the latest firmware (v1.10.1), go to the Internet & Security --> Advanced Developer Setting --> Enable CoIoT --> change the CoIoT peer: from mdns to the IP of your Homebridge (port is automaticly set) . Restart Your Shelly and after that restart your HB and your Shelly should be discovered

@try-and-error-and-repeat

YES!! That did it. I can now control it within the plugin, but it still does not appear in 'nc -kluw 0 224.0.1.187 5683'

Would you say that's a problem on Shelly's side or a router issue? I'm asking as I don't only want to fix the issue for shelly, I want to try and fix it on the router so anything that uses CoAP and doesn't have an advanced UI as shelly will still work

[try-and-error-and-repeat]

I think the Problem is that a Shelly uses multicast and not all mesh components are able to route / handle this. With the Newest Firmware it's possible to change from multicast to Unicast wich is much more compatible with the most routers. And you enabled with CoIot a better CoAP - because CoIoT is the next step of CoAP for Shelly devices.

I think the Problem is on both sides. But Shelly now offers a solution because companies like ASUS and others still haven't figured out a way to handle multicast correct in more complex networks.

[Marfre888]

I think the Problem is that a Shelly uses multicast and not all mesh components are able to route / handle this. With the Newest Firmware it's possible to change from multicast to Unicast wich is much more compatible with the most routers. And you enabled with CoIot a better CoAP - because CoIoT is the next step of CoAP for Shelly devices.

I think the Problem is on both sides. But Shelly now offers a solution because companies like ASUS and others still haven't figured out a way to handle multicast correct in more complex networks.

@try-and-error-and-repeat, Interesting, so when I changed the IP in the advanced internet & security menu to the Homebridge IP I'm effectively changing it from multi-cast to uni-cast correct?

But CoAP itself has nothing to do with multi-cast? So at this point is it safe to say that ASUS needs to work on their multi-cast between meshes or is it just CoAP they need to implement.

[try-and-error-and-repeat]

That's right if you enter the IP of your HB in this field you change from Multicast (mdns) to unicast.

CoIoT is basically CoAP, CoIoT is an extension of CoAP https://www.shelly-support.eu/index.php?attachment/1658-coiot-for-shelly-devices-rev-1-0-pdf/. So if CoIoT works CoAP works to. The Problem is multicast in mesh networks.

In my opinion Asus and others should work on multicast in mesh networks.

[Nisse57]

@try-and-error-and-repeat many thanks for the information and explanation. Very helpful!

[Marfre888]

That's right if you enter the IP of your HB in this field you change from Multicast (mdns) to unicast.

CoIoT is basically CoAP, CoIoT is an extension of CoAP https://www.shelly-support.eu/index.php?attachment/1658-coiot-for-shelly-devices-rev-1-0-pdf/. So if CoIoT works CoAP works to. The Problem is multicast in mesh networks.

In my opinion Asus and others should work on multicast in mesh networks.

@try-and-error-and-repeat Thanks for that.. that was incredibly helpful. So we've concluded the problem has to be multicast in mesh networks. As otherwise ColoT/CoAP wouldn't work in unicast is that was the problem.

I'll speak to ASUS about it, and maybe they will connect me to their technical team.

Now to figure out why 20% of my devices won't reconnect when I restart my router lol

[try-and-error-and-repeat]

There is a setting in the Shelly devices that is called SOFT REBOOT WHEN WIFI CONNECTION IS LOST. If you enable this this problem should also be solved

[Marfre888]

There is a setting in the Shelly devices that is called SOFT REBOOT WHEN WIFI CONNECTION IS LOST. If you enable this this problem should also be solved

@try-and-error-and-repeat Yes I saw that.. a very handy feature. Although my Shelly 1PM and 2.5s don't experience any problems, and that feature isn't available on the Dim2 and RGBW.

It is the Shelly Dimmer 2 that most often exhibits these problems for me, and other IoTs from Netatmo, Ring, and McClimate. So it's definitely a router issue, I just don't understand why it would refuse to allow these devices to connect.

[vskal]

I also have communication problems with my Shellies. They are caused by upgrading my ISP's modem/router to an Asus ax-56u. Not using Mesh.

The Shelly 2.5 works fine under all settings but the Plug S and the Bulb Duo are problematic.

From trial and error, the only setting that made a change was Airtime Fairness in the Proffesional WiFi settings.

When enabled, both the above problematic devices can turn on but not off. When disabled, I can do exactly the opposite, turn both off but not on !

If I interpret the author's notes correctly (Shelly,-CoAP-and-multicast), in the first setting I have HTTP communication but no CoAP messages while when Airtime Fairness is disabled I loose HTTP?

The state of the devices is not listened to by homekit. However, I can normally change the colour and brightness of the Shelly bulb.

[Marfre888]

I also have communication problems with my Shellies. They are caused by upgrading my ISP's modem/router to an Asus ax-56u. Not using Mesh.

The Shelly 2.5 works fine under all settings but the Plug S and the Bulb Duo are problematic.

From trial and error, the only setting that made a change was Airtime Fairness in the Proffesional WiFi settings.

When enabled, both the above problematic devices can turn on but not off. When disabled, I can do exactly the opposite, turn both off but not on !

The state of the devices is not listened to by homekit. However, I can normally change the colour and brightness of the Shelly bulb.

I've always had that disabled. What I discovered that really helped me with Shelly devices was to disable 'AMPDU RTS' and 'WMM APSD' on 2.4Ghz.

Now I'm thinking playing with the Multicast rate because I feel it's something related to that, because the devices seem to connect fine, but the router doesn't seem to grant them an IP so they do not connect. As IoTs tend to have low transmittion rates, I feel multicast rate might have something to do with it.

[vskal]

Thx ! Disabling WMM no Acknowledgment and AMPDU RTS fixed the plug not going to off , however WMM APSD and Airtime Fairness are still enabled.

I have also tried some Multicast rates but I did not notice any change.

[Marfre888]

Thx ! Disabling WMM no Acknowledgment and AMPDU RTS fixed the plug not going to off , however WMM APSD and Airtime Fairness are still enabled.

I have also tried some Multicast rates but I did not notice any change.

AMPDU RTS is the biggest offender. I've found that occasionally with WMM APSD enabled a couple of my shellies would not connect. So I just have all WMM disabled tbh as I don't need it.

Today I experimented with multicast rate; It seems in my case CCK5.5 on 2.4Ghz makes all devices happy with the Netatmo weather station being the fussiest of all. . I'm not too bothered with that as I don't have any non IoT devices making use of 2.4Ghz. I will continue to experiment further to see if I experience any problems, but so far it looks positive.

[qubiack]

I have another problem with the mesh network and shelly plugin.

In my case I have one main router and 2 mesh points - all of them RT-AX55 with the latest firmware. The issue I have had only with Shelly - I can turn the light on but I can't turn it off if the device is connected to the mesh node (from the Home app or Homebridge interface). If the device is connected to the root node the issue doesn't exist. Shelly's native app doesn't have a problem and I can turn it on and off without any issues if it is connected to the node as well as to the root router.

My Homebridge is connected to the mesh node by ethernet cable.

I disabled the "AMPDU RTS" and "WMM APSD" options - but it doesn't change anything. I changed the "CoIoT peer:" too direct IP but it doesn't change anything.

Right now I disabled 2.4Ghz on my node router to solve the issue temporarily but I have some connection issues with some Shelly devices far away from the root route so I need this mesh network.

---

I solved my issue - I use wrong IP. Why? In my router dashboard I notice I have two different IPs:

• Rasberry Pi Trading Ltd with 192.168.50.68 (wire)
• Homebridge with 192.168.50.69 (wifi 5Ghz)

When I use Homebridge IP the message wasn't delivered, but when I switch into Rasberry Pi it's work as expected.