Problem with ZHA network visualization

I have a lot of Aqara devices and use conbee2. I use Aqara plugs working as repeaters and as plugs at the same time, providing a good mesh. Read somewhere that Aqara devices work best with Aqara repeaters (the plugs) . Not sure it is true, works for me

I’m using option 3, mainly do to the missing upgrade in ZHA of hue bulbs. Further, I started with using hue before my HA setup. The hue integration in HA is working well, so I’m not removing it.

Main drawback is the missing bulbs from the ZHA zigbee mesh, hence I have some additional plugs used as repeaters in ZHA. In the basement I even put the hue bulbs on ZHA.

I do not plan to move the rest of the hue bulbs, as they work very well on the hue bridge.

I guys, not sure this is 100% the right spot to ask but you all seem very knowledgeable. I have a tonne of Hue and Zwave in the house. Recently I got a Sonoff USB 3.0 dongle so I can add some Aqara sensors as they are much cheaper than Zwave.

This works ok, but some devices don’t get picked up if too far from the hub.

So the question(s) are:

  1. How do I add HUE to the mesh to help overcome this
  2. I’ve read some posts of people suggesting to flash the Sonoff, I am unsure of the benefit?


I’ve waited patiently for a week now :slight_smile: and the graph is still incomplete:

Screen Shot 2022-02-27 at 1.14.07 AM

It’s always the two Aqara nodes that fail to show an edge to any other node. The Sonoff and Jasco nodes appear correctly.

Despite this, the Aqara do have normal function in HA.

However, I’d really like to know where in the graph the Aqara are connected, especially whether either is connected via one of the relays, or directly with the controller.

How can I find that out, with or without the network graph?

You have several options:

  1. If you want to get a list of devices, you can use the ZHA network card:
    This card will display a lot of ZHA network information. As you are interested in displaying the neighbor’s information, you should use a configuration that contains the undocumented “neighbors” attribute see the example below taken from my Lovelace configuration:
- title: ZHA
    path: zha
    panel: true
    icon: mdi:zigbee
    badges: []
      - clickable: true
          - name: Name
            prop: name
          - attr: available
            id: available
            modify: x || "false"
            name: Online
          - attr: rssi
            name: RSSI
          - attr: lqi
            name: LQI
          - attr: last_seen
            name: Last Seen
          - attr: manufacturer
            name: Manufacturer
          - attr: model
            name: Model
          - attr: device_type
            name: Type
          - attr: ieee
            name: IEEE
          - name: NWK
            prop: nwk
          - attr: power_source
            name: Power Source
          - attr: quirk_class
            name: Quirk
          - name: Neighbours
            attr: neighbors
            modify: >-
    , idx) => { let s = ""; if (idx > 0) s = "<br />"; s = s+
              n.relationship + " " +; return s; })
        sort_by: name
        type: custom:zha-network-card

This will give you this kind of output:

  1. if you want a nice graphic representation, you should use the ZigZag custom panel. It gives you a much much nicer representation of your network. You can find the instruction here:
    Just follow the instructions and you will get a graph like this:

All these solutions use the same information accessed from ZHA database and therefore if one fail most probably all will fail in other words if the neighbors don’t show in one display, they probably won’t show in all of them.
If you are using a ConBee II I have found that this coordinator seems to not always return the right information to ZHA or at least can get desynchronized with ZHA. You have to know that even if you restart from scratch a new network, the ConBee II keeps a lot f information in its cache from previous configuration and sometimes that confuses the overall system because the ConBee knows about some devices from a previous configuration but ZHA are not aware of them. One way to overcome this problem is to flush the ConBee II caches. For that matter I think that you only have to change the network id. I did that long ago and I do not remember exactly how to do that but someone can probably explain better than me. For me resetting the caches in the ConBee II and rebuilding the network from scratch solved the problem and now all my devices are shown correctly.
One thing to know about the Aqara devices is that once they are connected to a parent they almost never change even if the quality of the communication becomes bad. For example, I have a router very close to an Aqara device but originally it connected to the coordinator with a relatively bad signal and the Aqara device never changed to this close router. Therefore, the procedure I recommend is the following: When you add an Aqara device (actually I recommend doing this for any passive device) DO NOT add the component using the “add device” from the integration unless you want to connect it to the coordinator. Instead, you should use the “add device via this device” command. For that you have to go to the device description of the router close to the device you want to add and use the command mentioned above. Note that if you see that a device is not connected to the closest router what you can do is “forget” the device and add it again following the described procedure.

I hope this help

I have found the information about resetting ConBee II internal tables:

There’s no specific command in the protocol. You could change the PanID, Extended PanID and the network key, that would equate to a brand-new network.

To get a better view of what is going on you should turn on the debug flags. I recommend the following in the configuration.yaml:

  default: info
    homeassistant.core: debug
    homeassistant.components.zha: debug
    zigpy: debug
    zigpy_cc: debug
    zigpy_deconz.zigbee.application: debug
    zigpy_deconz.api: debug
    zigpy_xbee.zigbee.application: debug
    zigpy_xbee.api: debug
    zigpy_zigate: debug
    zigpy_znp: debug
    zhaquirks: debug

Not all of them are necessary but …
In the debug log you should look for zdo requrest sent to 0x0000 NWK address with Mgmt_lqi_req commands and you should see in response the neighbors for each router (including coordinator). Something like this:

2021-01-08 18:51:59 DEBUG (MainThread) [**zigpy.neighbor**] [0xabdc] request status: Status.SUCCESS. response: Neighbors(entries=3, start_index=0, neighbor_table_list=[Neighbor(extended_pan_id=00:21:2e:ff:ff:06:19:bc, ieee=00:21:2e:ff:ff:06:19:bc, nwk=0x0000, packed=36, permit_joining=<PermitJoins.Unknown: 2>, depth=0, lqi=184), Neighbor(extended_pan_id=00:21:2e:ff:ff:06:19:bc, ieee=00:15:8d:00:04:50:6c:e9, nwk=0x6C5B, packed=18, permit_joining=<PermitJoins.NotAccepting: 0>, depth=2, lqi=48), Neighbor(extended_pan_id=00:21:2e:ff:ff:06:19:bc, ieee=00:15:8d:00:05:6a:18:9d, nwk=0x7317, packed=18, permit_joining=<PermitJoins.NotAccepting: 0>, depth=2, lqi=159)])
2021-01-08 18:51:59 DEBUG (MainThread) [zigpy.neighbor] [0xabdc] Done scanning. Total 3 neighbours

Remember that:

ConBee does not retain children information (like a regular Zigbee device should do) on a power cycle. If the child was joined directly to ConBee, prior the version when zigpy-deconz was storing that information, then it won’t be reported in the topology, because ConBee does not report it.

For the topology map, zha gets information from zigpy, zigpy gets the information by querying each router in the network.

So if you do not see the children after about 3 to 4 hours in the log file again I would suggest you reset the ConBee II

1 Like

Thanks! First things first, I installed the zha-network-card and the ZigZag panel, and they both confirm what you predicted: the missing links appear to be missing in the ZHA database. All visualizations show the same thing.

I am indeed using the ConBee II, so next I’m going to try looking at the debug logs.

What does “resetting” the ConBee II mean? And does that imply reattaching (and renaming??) every entity from scratch? Some of these devices are in very inaccessible places, so I’d rather not!

BTW, thanks for the advice about the “add device via this device” – I may need to re-add the Aqara devices, just as soon as I figure out where they are currently attached.

Resetting as I mentioned means changing the the PanID, Extended PanID and the network key.
Unfortunately reseting the ConBee means that you need to start from scratch as all the devices will be “forgotten” in the operation.
It took me some time and effort to get everything right but I do not remember all details.
Have you done some tests before building the final network? Because I believe that your problem comes from the fact that the ConBee knows about some devices that zigpy-deconz do not know.

Even though your devices are not showing in the graphs are they visible in the device list? If that the case then you can try to “forget” them and “add them again”. The goal is to resynchronize what are stored in the devices internat tables and zigpy-deconz. This may work without the need to rebuild from scratch.

You would want to add a ZigBee wall plug in that area which may help you with this.

These IKEA ZigBee repeaters work well and have been very reliable for me.

Thanks for taking the time to answer @dexstar , I take it then that there is no way to integrate all my HUE bulbs, PIR and switches to the current Zigbee mesh to aid in this?

I don’t see why not, have you not tried already? Hue bulbs, or any wall plug should act as routers and help with your Zigbee mesh.

I don’t have any Hue devices in my setup so cannot say how well the work. The IKEA repeaters I linked work really well in my setup, plus you can’t beat the price.

Where do you have that device plugged in? It is also recommended to use one of these in your setup to minimise on interference.

Also, if you can, try have your Sonoff dongle centrally located.

The device you have seems quite powerful.

There’s a thread here with more information which may be of assistance to you.

I have several Hue bulbs and they are excellent routers.

A bit late, but when I’ve had problems with connections not showing in the graph, re-pairing the device often fixes this - can’t remember if you need to delete and re-pair, or just re-pair.

1 Like

Update: I followed Jon’s suggestion and repaired the three devices that were not showing their neighbors in the graph:

  1. The three devices’ neighbor edges now show up, attached to the routers I connected them through. :+1:
  2. I gave the repaired devices the same names they had before I deleted them, so the delete-repair cycle was seamless in Home Assistant, with dashboards and automations using the repaired devices working as they did before.

oh great - glad it worked!

Thanks for that, how did you integrate them though? Currently mine runs via the HUE Hub as the wife and kids use the Hue app and Homekit… do you have to decouple from the HUE hub or can you use it as is somehow? Thanks

@dexstar Thanks for your reply! I am not 100% sure on how to get the HUE into my SONOF mesh, I will work through your link. I have the SONOF on an extension USB cable thanks :slight_smile: - Do you need to remove your HUE equipment from the HUE hub to integrate them, do you know?

Thanks again

The Hue hub creates a zigbee mesh. A device can only belong to one zigbee mesh.

To get the hue bulbs into you sonoff zigbee mesh, you have to delete them from the hue app and pair tjen into tour HA zigbee setup.

If removed from hue hub, then you can not control them t from the hue app.

@khvej8 Thank you for clarifying! That’s kind of what I expected but still held out hope that there might be a way to piggy back. I guess I will find another way! Thanks again!

I moved away from both HUE and Smartthings to HA after a while. My wife was used to the Hue app too but soon adapted to HA, just have to make the main interface easy enough for the missus to follow :smiley:

I have now close to 97 devices on ZHA, mostly routers as they are mains powered, it is rock solid but with the usual pitfalls with ZHA ie slow startup time. I have an issue with ZHA groups but other than that no complaints. Close to 4 months now, no complaints yet.

1 Like