Neighbour X is not in 'zigbee.db' warning.

[zha-ng]

Neighbour X is not in 'zigbee.db' warning.

[MattWestb]

Some Philips HUE is doing the same if deleting / moving devices from the mesh:

{
    "ieee": "00:17:88:01:02:c6:86:59",
    "nwk": "0x099f",
    "lqi": null,
    "device_type": "Router",
    "manufacturer": "Philips",
    "model": "LWB010",
    "offline": false,
    "neighbours": [
        {
            "ieee": "cc:cc:cc:ff:fe:b9:b3:19",
            "nwk": "0x0000",
            "lqi": 221,
            "pan_id": "cc:cc:cc:cc:b3:c2:dd:bc",
            "device_type": "Coordinator",
            "rx_on_when_idle": "On",
            "relation": "Parent",
            "new_joins_accepted": "Accepting",
            "depth": 0,
            "model": "EZSP",
            "manufacturer": "Silicon Labs",
            "offline": false,
            "supported": true
        },

some device entries have being cut away then not needed   . . .

        {
            "ieee": "90:fd:9f:ff:fe:2a:c8:a9",
            "nwk": "0xb309",
            "lqi": 89,
            "pan_id": "cc:cc:cc:cc:b3:c2:dd:bc",
            "device_type": "Router",
            "rx_on_when_idle": "On",
            "relation": "None_of_the_above",
            "new_joins_accepted": "Accepting",
            "depth": 1,
            "model": "TRADFRI control outlet",
            "manufacturer": "IKEA of Sweden",
            "offline": false,
            "supported": true
        },
        {
            "ieee": "00:0d:6f:ff:fe:03:5b:fd",
            "nwk": null,
            "lqi": 0,
            "pan_id": "cc:cc:cc:cc:b3:c2:dd:bc",
            "device_type": "Router",
            "rx_on_when_idle": "On",
            "relation": "None_of_the_above",
            "new_joins_accepted": "Accepting",
            "depth": 1,
            "model": null,
            "manufacturer": null,
            "offline": false,
            "supported": true
        }
    ]
}

The device 00:0d:6f:ff:fe:03:5b:fd is currently paired with deCONZ that have different CH, PAN, EPAN and network key so the HUE cant have "talking" with it for 3 weeks but still reporting it.

I think with HUEs is only way to resetting the bulb and rejoining it so it deleting its no existing neighbour (have doing that before in deCONZ).

[MattWestb]

@krasatos Your device have very low LIQ to all neighbours and probably have problem to talking with other devices if it always having that.
And one strange thing is that the lumi.plug is very far away "depth": 255, .
(255 jumps = on known ?)

[krasatos]

@krasatos Your device have very low LIQ to all neighbours and probably have problem to talking with other devices.
And one strange thing is that the lumi.plug is very far away "depth": 255, .
(255 jumps = on known ?)

That plug was probably unplugged at that point? (could that be the issue?)
Here is my current situation:

Most of the devices are in the livingroom, max 4 meters away from each other.
The rest are in the bedroom, next door, max 5 meters and one wall away from the gateway.

[MattWestb]

If its working then its OK but its little strange that the Xiaomi end devices have better LIQ then the SonOff Basic but it can being it have the old TI CC-2530 module then its having very low LIQ.
I have some HOMA dimmers (Chinese ZB3) that working OK but is very weak in the network (also IT CC-2530 modules).
Battery powered end device is normally using very low power mode for saving battery but can having very good amplifiers and antennas for compensating the low power output.

If working OK letting it and if getting problem with the bedroom putting one device with good radio in the bedroom as one router / amplifier.

I have one outlet downstairs and from the coordinator its 2 meter reinforced concrete (diagonal) and have one more outlet over it for relaying down and not need going in the diagonal and only having 30 cm concrete and its working great.

[krasatos]

I think the routing issues will be resolved overtime, as I add more devices to the mesh.
What about removing the device that registered and got wasted?

[MattWestb]

Normally ZHA is sending leave without rejoining command to the device and after that deleting it in the zigbee.db. Most devices is doing as they should but not all. Its no problem its only resetting the device and its deleting all the networks credentials and cant rejoining. The "not in zigbee.db" is bad behaving devices that not forgetting there numbers (should timing out if not "talking" with it and being deleted in the device in its tables).
The "not in zigbee.db" is more or less one cosmetics thing but it can being problem with devices that is moving around in the mesh.

If "losing" one device and was not resetting it you cant blocking it easy then its have all your network credentials but is not so easy taking the info from the device (must using J-Tag /SWD debugger).

Its god having some routers so the mesh can re/routing the traffic and self forming / healing and not only end devices that is talking to the coordinator. I using IKEAs control outlets as "backbone" for Xiaomi sensors all around and little between lights that is helping the mesh routing things around :-))
I only losing sensors then the battery is out and I have forcing them paired with one router that is near and have good LIQ back to the coordinator (thru the mesh) and the battery's is holding much longer 2.

[Adminiuga]

Zha_map queries each router on the network for its "neighbors". Zha_map has no control of what device reports back. But normally, it is expected that every neighbor to be known by the zigpy. And if a neighbor is being reported, which is not in zigbee.db than it is not necessarily a problem, just an indication to operator that he may want to check if that's expect or not expected.

Eg if you remove a device from the network, but device misses the request, then technically it would stay on the network but would be removed from zigbee.db. and in this cases you need to decide whether you want to reset this device so normal aging would age the neighbor out of the tablet or if you want to rejoin the device back.

In other words: just ignore it.

[MattWestb]

Very good described !!

If removing one device (some days travelling to italy) and then deleting it in ZHA (device is not resetted) and coming back some weeks later (the devie still having the network credentials) but ZHA dont having it in zigbee.db, the device can going in the network then its having the credenshial. Is ZHA rejoining it (without opening the network for rejoining) and adding it in zigbee.db or is TC refusing it and sending one leave without rejoining to it (and the device is leaving and resetting) and the bad behaving neighbor routers is reporting it as neighbor ?

We have finding two interesting devices (routers) that is NOT ageing out neighbors / childrens that is being out of range / not in the own network for long time (weeks and not minutes). Sonoff BASICZBR3 and Philips HUE LWB010.

And if dont like have "ghosts devices" in the log > reset the router that is sending the false information.

[Adminiuga]

Yeah, I do believe some devices are not aging out neighbors/children correctly. ATM there's no an easy fix for it. You could try sending the ZDO leave request to the device and see what happens. Or just rest the device and rejoin it. May have to re-add to the groups after that

[MattWestb]

Resetting and repairing is working with the Philips HUE only need adding it in the group so the remote is working. Have trying doing reconfig but its not clearing the tables and as you saying its normally one cosmetic thing but good to knowing then getting other problems in the mesh.

Was doing the last technik shopping before christmas then all is going in lockdown here in 45 minutes and need have some things to killing time with ;-)

[MattWestb]

Was doing one touchlink reset with the HUE dimmer switch and repairing the bulb and adding it in the remotes group and its working as expected (no ghosts warnings in the log) ;-)))