No sure fire way -- they could be a number of things, but the general concensus is to leave them be. It seems many just drop off eventually.
One possibility is that if a device has multiple enpoints, the add'l endpoints may show up as unknown in the map.
Is there a way to hide a particular device on the map?
There is no way to hide a particular device on the map. You can only hide "Unknown" devices.
@dandanache I just wanted to give you a big Thank you for this app.
I also wanted to tell everyone how I just used this app (for a tremendous impact).
A beautiful picture is great, but when it really helps you, it's fabulous.
Like many others here, I've put in many zigbee plugins to assist in the "mesh" process as repeaters.
I've put them in, and promptly forgot about them, assuming that they were doing their job.
Recently, I had an issue where I lost many Zigbee devices from my mesh, and I had trouble re-joining some of them. I couldn't understand what was wrong, and why my stable Zigbee mesh was giving me such grief.
I ran the Zigbee Map app, and lo and behold some of my repeater devices were in magenta (interview failed). For example, I had an Ikea Repeater in that state. I rejoined each and every one of them and it made a huge difference. (You can tell if an Ikea Repeater has fallen off the mesh by checking the Zigbee Logs.)
Thank you again for a great app!
I't's been a few weeks since I used this app and it was working fine then. Now I get
When I click on any of
I have
I get the same thing with either Vivaldi or Chromium. I've cleared the cache and restarted the browsers.
I'm glad that the app was helpful for you and thank you the kind words!
Please enable debug logging in the app (lower in the page from your second screen-shot) and check if anything more useful is printed in the Live Logs.
Also please check that the 3 required html files are still present in Settings -> File Manager:
You can also run the "Repair" function in HPM, maybe this will sort things out.
Thanks, Dan, but that won't be necessary because I now realize that I had another dumbass attack when I deleted the files in File Manager which I errantly assumed were old reports. 
Sorry for the noise.
Released version 2.2.0 with the following small change:
This update has no change to the map functionality. It just adds the option to pair a joining device using a specific repeater that is already part of the Zigbee network. Usually you don't need this functionality; it is useful only when pairing IKEA battery-powered and some Aqara devices.
The same functionality was available using the Zigbee Pairing Helper driver, but now the journey is more like "stay back and enjoy the ride" 
Note: I used some JavaScript kung-fu that deviates from the standard apps development flow, so the functionality might break if elements in the UI are changed in next platform releases.
Howdy, I found your app recently and it’s rather handy, thank you. 
The CPU / RAM graph function is also quite neat, but I was wondering if you could explain the CPU scale please? Ie, does 1 = 100% or 10% or 1%?
I ask as I can’t reconcile what I’m seeing when I compare the data with Hub Info.
It's a little more complicated than this, but essentially a load value of 1 says that a cpu core has runnng or waiting threads that will account for 100% of the core's resources (a core can exceed 1 when there are more threads waiting than can run concurrently) . The HE hub is a 4 core device, so a value of 4 would mean that 100% of the hub's processing capacity is promised to either waiting or runnung threads.
I was aware of that, but wondered how that translated, cheers.
Do you have any insight into how multi-threaded HE is? The reason I ask is due to this discussion.
I too have isolated my cloud/LAN intergrations to their own hub as much as possible. Slow downs, from what I've seen, tend to occur primarily when drivers/apps don't use Async calls, and force a thread to pause while receiving a response (YMMV) - generate a high enough volume of these and you run out of threads to process the other traffic. There is a time/place for a non-async call, but if they can be minimized the hub is able to keep pace quite a bit easier.
Do you know if HE gives itself priority over a pair of cores, like say macOS has done since the introduction of Apple Silicon? This could prevent some of the slow downs and improve responsiveness overall.
Don't really know. IIRC the base OS was at one time, and may still be, BusyBox linux.
Could you expand on this maybe in another thread? Or, provide some links for more info for me. I like the idea of isolating my integrations. Thanks.
@Pantheon @thebearmay Thinking about this some more, do we have visibility of each core in that graph?
Is Hubitat really only running everything on a single core most of the time as the graph suggests?
If we look at traditional CPU graphs, we can see the individual core loads which is much more useful for understanding how hard a system is working. Eg
We don't have that level of visability not sure if HE staff do or not. I'd guess that the load is leveled across multiple cores though.
That’s a shame, discrete core info would make understanding the hub workloads a lot simpler.
You’d hope so, but these days there’s a lot more nuance to good multi-tasking than just load balancing. I would really like to understand this better, as a C8P running at 20% load should not become noticeably slower than at 10%.
Great update. By far the strongest repeaters here are Sinope line thermostats. Unfortunately they don't expose a Switch capability and are unavailable for selection. Not sure what to suggest.
Good catch 
That was a clumsy attempt to filter out battery-powered devices, I will do better in the next release. Meanwhile, you can edit the app source code:
Download the Hubitat app
