linkquality is much more wilder than before flashing. seems there is a lot of reorganizing?
map show a lot of lost devices, but devise overview does not?
i´ll give it a try till tomorrow…
I don’t think they’re “lost”. Battery-powered end devices spend most of their time sleeping and only check in with a parent router periodically. At the time of your snapshot, that’s what they were doing. Wave at a motion sensor and generate another map, and it will be connected.
Did the devices come back over time?
With this huge number of end-devices compared to routers, have you considered implementing more routers? They do not need to be additional device just for routing. Like plugs or bulbs being part of automating your home. I think this will make it more stable in the long run.
1 Like
except of 5, they all came “back”.
5 of the devices i had to reconnect manually. (one is left, its the most worse accessable device i have, the rainsensor dyi made from here rain gauge)
but i recognized a very strange behavior of zigbee2mqtt MAP, what did not get better until yesterday… (the map is rebuilt badly every time)
many of the devices are “linked” to coord or routers (dashed line or solid lines), but some of them, do not “glide” and “reorientate” on the map automatically as usual. i recognized all of the “glued to the map”, do show a “0” on the connections lines, what means, linkquality = 0? But device page shows me real link qualities for all of them, and hassio recorder history stat do show me changing lqi stats regularly, but NOT “0”. so only the map in z2m does not work correct any longer?
i dont know if it´s due to the last update of z2m, or of the newly added routers (2 more since 2 weeks), or the 10 new devices since approx 1 week… or the fw-flashing of the 3 existing routers … if i move one of the router-bubbles all of the other bubbles do wobble around and glide to new positions, except the red marked… those are frozen…
what i also had recognized (in the past and todays much more): many of the devices do have an unstable linkquality (even i had just 40 devices). it seems only the ones connected to the coordinator are “stable” (see history graph “flatlines”) the others do vary very much… 80 to 7 lqi. especially the raingauge sensor had lost connection since the beginning, what decided me to reposition the raingauge first, but without any success, i added two more routers… but it does not became better… rain sensor regularyl lost connection (could be long term 50-80, then off instantly, could be good weather or raining…) i have an addittional temp (weather) sensor of aqara at the same spot, without any issue since ever? anoying… i cant access rain gauge, when its raining ort had rained…
i plan to use more routers, but honestly i dont now where to place and how to manage power source for them 
( i assmue it would not make sence to place two at the same place?)
but i wonder: one router should handle 50 devices as described here?
i have 5 routes + coord? i have “only” 75 devices? shouldn´t be enough? all devices are in range about 10 meters in the house, 3 floor-levels… brick walls
By model
lumi.weather: 56
lumi.airrtc.agl001: 12
lumi.sensor_magnet.aq2: 8
ti.router: 5
another thought: except of the coordinator, all 5 routers are connected to a plugin power usbsource directly to a wall socket. i plan to make extension cables for all of them. Maybe proximity to the electrical wiring does have any influcence?
but what bothers me a lot, the last 3 routers i had flashedrecently, do NOT show the firmware version in hasso i have flashed? could it be data in hassio (z2m) is outdated, and not beeing updated? i have rebooted, and i had shut off the system to unplug coord from rasp… and since then restartet z2m integration twice?
Zigbee power plugs might be a good option / good candidate.
2 Likes
You don’t have enough routers. If you have 75 devices, I’d suggest that as many as half of them need to be routers.
Your LQI numbers are very low. They should be in the 100-150 range at least, ideally higher. To achieve this, you need more routers - lightbulbs, smart plugs, wall sockets, whatever.
The optimum distance between devices is 10 feet, not 10 meters. Yes, the signal will travel much further in good conditions, but that’s not the point. The point is to build a robust mesh that will self-heal when there are problems. You need more routers.
Stop obsessing about the map. It’s a snapshot visualisation and it will be different every time you generate it.
YOU. NEED. MORE. ROUTERS. 
Edit: Have you read this?
2 Likes
He may need more, but a 50% is a crazy high ratio. I have 13 for a net of 90 devices total, and only 7 actually have end devices attached. Similar ratios at other installs, all solid.
Five could be fine for a 1500sf ranch, probably not for a 4500sf 3 story.
Were these upgraded from a previous router fw, or newly flashed? I’ve seen z2m not populate that correctly when updating router fw. Force remove, restart z2m, re-pair fixed it for me. Not sure if all that was really needed.
The requirement will be unique to each enviroment and specific devices uses. Some buildings have small rooms with dense wall/cealings/floor that kill Zigbee as its signals are low-power and the messages are very short (small frames). Then some Zigbee devices will have much worse antennas and antenna design than others, as well as have weaker Zigbee radios than others. So two similar setups can get very different results depending on which home they are installed and where exactly the devices are located.
But a the general rule can still be said to be; when in doubt, add more Zigbee Router devices. However, buying and adding a few great Zigbee Router devices will have a much greater impact compared to many poor Zigbee Router devices, so that is therefor what I recommend.
Again, strongly recommend follow the tips I collected here → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage
thank you guys for all the great input! i have realized that i have to upgrade my zigbeemesh anyhow…
i was always fixated on sonoff zigbee3.0 usb dongles as routers the whole time, but not on other powered zigbee devices. Only now i do understand some posts before (about powerplugs and bulbs) what i had missunderstood a long time…
to clear up a misunderstanding: ALL my devices (routers and devices) are within a range of 10-15m in the house. So distances between devices is mostly about 2-4 meters… but distance between routers might be more. I was of the opinion that the dongles distributed evenly around the house with their external antenna would be sufficient, but this is probably not the case.
i will try to upgrate my mesh and report the results in the next weeks…
@jerrm
yes upgraded from previous fw…
so i forced remove, restartet z2m, but it does NOT re-pair anymore! now i have just 4 routers .
any chance to get this router back to work in hassio without deinstalling z2m?
Re-flash it.
Maybe force remove was wrong. Its been a while.
force remove removes it from the database, but not from the network, that is the problem.
hi @francisp ,
aha network? what does it mean? where is the network information stored? in the router hardware or in zig2m integration files, or in hassio db?
before i reflash anything, any chance to remove from network?
edit files, or restore zig2m from backup?
from the documentation
Note that in Zigbee the coordinator can only request a device to remove itself from the network. Which means that in case a device refuses to respond to this request it is not removed from the network.
and
In case all of the above fails, you can force remove a device. Note that a force remove will only remove the device from the database. Until this device is factory reset, it will still hold the network encryption key and thus is still able to communicate over the network!
So maybe restore a backup
luckily i got back my removed router, but the way to get it back was not as as i expected.
partly restoring a backup zigbe2mqtt add-on alone, caused severe problems. mosquito broker dont wanted to start anymore
2023-11-18 11:35:02: Warning: Mosquitto should not be run as root/administrator.
mosquitto: persist_read.c:550: persist__restore_sub: Assertion `client_id' failed.
so it is nessessary to restore both zigbe2m and mosquito add-in. at same time, to get a “running” system…, but the missing router was not in the device list?
in the end i moved back to todays backup and manually copied the following files from backup… from/to folder
homeassistant\zigbee2mqtt\
- configuration.yaml
- coordinator_backup.json
- database.db
- state.json
now the missing router is back…
I realize disconnected objects spend most of their time sleeping and they only reconnect from time to time. For example motion detectors and/or smoke detectors. While they are asleep, the coordinator cannot contact them and there is no route to them. But if you enter a room or rotate the smoke detector, it works right away and reconnects.
When it comes to routers, they should always be available.
So clearly Zigbee2mqtt does not make a difference between them.
In the above example, only the ZBMINIZ2 is faulty. Other devices work very well.
Now for good coverage, I purchased 5 UZG Zigbee coordinators with Ethernet PoE/Wifi. I will probably use 3 indoors and 2 outdoors (with custom casing).
With latest beta firmware, you can monitor the coordinator from HA. Very cool.
Also, when migrating to a new coordinator, it is better IMHO to repair devices.
hi @francisp
thanx for your explanation. but i have a lot more questions, just so i understand: i wonder how to do correctly remove an device via z2m gui?
=> at device, use remove button, but NOT set force-remove, right?
=> should this request the coordinator to remove the device, as you descriped, correct?
how do is see if its removed succesfully? will it be removed from DB as well in this case? if the coordinator fails to remove it from network, “nothing” will happen? (so coordinator keeps it in network and it will stay in hassio/z2m db)?
so force_remove is only for devices to get rid off and not to be used anymore, correct? i wonder, what remove option “block from joining again” does when it is much easier the other way? 
will this set an extra flag?
another question: by re-pairing the same device with an new NetworkEnryptionKey (e.g. after reflashing it), will this create new entitiy_ids in hassio for the device too, when it was removed before? Or will all kept the same?
i wonder how the z2m “finds” the same router, after flashing, when not beeing removed before? it should have a new NetEncryptKey too? or is this irrelavent for identifaction of a specific device?
with my sonoff USB3 dongle, i would not have the problem to reflash, to get a new nework encryption key and possibly new entity_ids at the end… this special device do not have any…
but if i would have e.g. an powerplug or bulb used as an router, having a lot of entities_ids beeing used in automations etc. then it would be a prob.
so at the end i wonder, how to get z2m populate a device correctly after beeing fw updated?
@ffries interesting! but i do not unserstand the part with Ethernet PoE/Wifi on a zigbee coordinator? you mean you will split the same mesh into 5 pieces, or you will have 5 independent zigbee meshes? is it possible to use more than one coordinator in zigbee2mqtt?
The only reason to use PoE for a router is just as a convenient power source. From the zigbee perspective it is no different than a Sonoff dongle flashed with router firmware plugged into a usb charger.
There can only be one coordinator per z2m or zha instance. You can run multiple instances of z2m, but each is a separate, distinct zigbee net.
1 Like
Yes and No, the big advantage of the UZG01 is that it is a very small device which can communicate with Zigbee2mqtt over IP using Ethernet or Wifi (not both) and it can be installed everywhere in a building, It can be powered by USB or PoE. It is independent of HomeAssistant location.
You can achieve 1 HA : n coordinators connections very easily.
In my house, I plan to use 4 or 5 of them (currently only one) : one in each building and two outdoors. I already have two (version 01.1) and I purchased an additional three (version 01.2). They are very stable products running for more than a month now.
Flashing the UZG01 is easy and can be done Over The Air using a nice web interface. You can control and monitor the UZG01 within HomeAssistant (see screenshot up).
In a concrete building with different floors, you can imagine one coordinator per floor and then mesh network for each floor. The UZG01 communicates with Zigbee2mqqt using serial over IP. For example, if you are using 10 UZG01, you need 10 Zigbee2mqtt instances. But if you think of concrete and thick walls, this is the only way to achieve reliability. I also noticed in my summer house that in case of heavy rain falls, the outdoor network would go down. So better use a UZG01 in my second building.
PoE and ethernet are very interesting because it gives reliability and will work even in power outage (fgiven the PoE source is protected).
In my case, HomeAssistant is installed in one location and I query the UZG01 remotely using a VPN. This seems to work quite well and if this does not I will install local Z2Q instances. But currently I want to make it simple.
I am also working on a quite funny solution. As my PoE ethernet network is in triangle (= like in a company) with 3 switches, in case the UZG01 would go down I can start a secondary UZG01 hidden somewhere in the house with 4G connectivity. In case of rubbery, the attackers would need to disconnect all networks. And as this UZG01 would be located under the roof, good luck. This is just a thought, I never did any testing.
Yes, the UZG01 is a killer product: you can host your own HomeAssistant and connect everywhere on the planet (I am not related to this product, just a user).
The UZG01 is a lot of fun …
Kind regards,
FF