I can see one use case: on most modern Android devices you can't change the hostname without root access. But they usually contain android. One could group all android devices easily with wildcard hostnames.
I know. I only need the default group myself but I can see the need for fine-grained group assignments in some cases.
I may go very far but I assume the number of Android devices in the household should be fairly manageable. Especially is their host names stay constant over the life-time of these devices.
One question: Why would you black- or whitelist something exclusively for all Android devices? Whay is this a thing that should not apply to all other devices in the network as well? I do see reasons for per-device settings (like parents/kids) but defining rules for an entire range of devices still feels strange.
As you see, I'm just collecting ideas here, trying to get justifications for adding something as we should not do it for the sole reason of that we're able to do it (if that's the question we could even have fully fledged regex support here!...).
.....
NO, just joking!
I have no good reason. I don't need that feature but tried to imagine what others might want to use it for. Just wanted to bring it up so it is discussed now before the whole branch gets public one day and users might want to see this (they might then provide a good reason).
I can't even see the need for per interface grouping in a small network environment.
... what-so-ever is a good reason, right? 
Just noticed today
Empty IP address?
EDIT
And a client in GM with no corresponding entry in network table.
It was removed after 24 hours. I meanwhile figured this is an too aggressive cleaning mechanism and disabled auto-cleaning a few days ago:
However, data already wiped out at this point obviously stays lost.
Yes, this will very likely be the device with no IP address in your network table. The IP address of devices not on the local network is coded into the MAC address so it can be regenerated for the client suggestion. However, as it is less meaningful for users, the network table just shows N/A as hardware address for these devices. When you're already running the latest version (I assume so) no IP addresses should get lost any longer.
Ok, flushed the network table and will report if something like this will reappear.
I still run it untouched for maybe 10 days now and have no complaints whatsoever. It works amazingly well. Thank you very much for it.
Reading this topic and seeing the huge benefit for MAC based group association with IPv6 I thought about the possibility to add/substitute the client IP in the dashboard/query log/stats with MACs if configured in GM/clients (sum up all queries by device rather than IP). I guess most users would like to see the stats for their device rather than stats split by all IPs that device might have.
I'm not sure how to handle all the possibilities if a device has multiple IPs and/or multiple hostnames and which option should take priority in the dashboard.
But you don't suggest to actually show a MAC as a replacement for IP addresses, right? I would not know that A3:3E:33:59:F3:11 is my printer, however, the hostname printer-upperfloor is clearer to me.
I think this is an entirely different question you're rising here and should be looked into separately. There needs to be stuff for v5.3 (assuming dark mode is v5.1, per-MAC is v5.2) 
Of course I do. It shoud go along with the hostname (which, if multiple exist?) or IP (which, if multiple exist?).
I think it is connected. If you add such a high demanded feature users will start using it. And soon they will raise they questions why top clients consists only of multiple IPs of only one or two devices which they have configured as one device by MAC. I think it is legit to bring it up here - the devs will decide if/how/when they might implement this.
Even with all the flexibility we added in this branch, you should not forget that clients are still identified by their IP addresses inside the DNS server. This entire modification changes only one thing, that is finding the suitable group for a client. We look up if the IP address is associated with a MAC address. If so, we check if this MAC address has a group definition.
Inside FTL, twenty IP addresses are still twenty devices. Changing this would require a massive rewrite and is something I would not like to do with dnsmasq. Don't get me wrong, I'm also fairly familiar with unbound, bind9 and know some of the internals in PowerDNS Recursor and also a few Go DNS servers and neither of them work with "devices" as clients. They all identify their clients by IP addresses. This is only natural from the technical side of things.
This is not a general "no" from me, it is more a "not now" but also a "maybe never". It all depends on a clear concept of how the internal structure would need to get changed and it is definitely nothing that could go in here.
You have seen how many changes were needed to get this bit of extra functionality into the DNS server. Unfortunately, we cannot really reuse much of it for an architectural change.
Just noticed vendor is not displayed anymore.
macvendor.db is used.
[2020-05-31 18:16:46.927 24926] MACVENDORDB: Using /etc/pihole/macvendor.db
So, in a situation, where there are IPv6 clients in the network that configure their selves via SLAAC with privacy extension, their IPv6 address does change randomly. IMHO all Android smartphones with a recent version of Android will do so. I know, that RFC7217 doesn't require to use random IP addresses, but some devices obviously just do it..
My assumption now was, that identification of such autonomously configuring devices with random IPv6 addresses is only possible on layer 2 with the MAC address (provided, that this is not randomized too, which you can configure in Android 10 for example).
But following your explanation I would understand, this pi-hole would still not be able to identify the device after it randomly changed its IPv6 address, because the "lookup process" is always started by using the requests IP address, right?
I'm quite lost actually, because in such situation network client identification for whatever purpose seems to be impossible at all (which is actually, what is intended)?
It will work, It will not always be in real time though. You have to give it a minute for setup to realize there has been an address change aside from that, once it updates the address there should be no issues. In my testing, the additional feature functions as it should.
MAC address blocking is essential in dual-stack networks where IPv6 and IPv4 are configured. Clients get a new IPv6 address often, thus making exclude or blocklists unusable if pihole handles giving out IP addresses as it does for me.
I just pushed another small update to this branch implementing group membership re-checking about three minutes after a client has first been seen. This should suffice to pick up information only becoming available later (interface, MAC address, hostnames). Some things like selective per-client regex group reloading wasn't possible before so even if this sounds like a rather simple change again testing on this will be needed.
I also merged the latest development changes into this branch so you stay up-to-date.
Hi all,
just checkout the branch with ftl and web an saw the following in the log:
2020-06-05 21:26:07.647 3987] Querying gravity database for client with IP 10.4.0.99...
[2020-06-05 21:26:07.647 3987] SQL: Comparing 10.4.0.99 vs. 10.0.4.32/27 (subnet 255.255.255.224) - NO MATCH
[2020-06-05 21:26:07.647 3987] SQL: Comparing 10.4.0.99 vs. 10.0.4.64/26 (subnet 255.255.255.192) - NO MATCH
[2020-06-05 21:26:07.647 3987] SQL: Comparing 10.4.0.99 vs. 10.4.0.0/24 (subnet 255.255.255.0) - !! MATCH !!
[2020-06-05 21:26:07.647 3987] SQL: Comparing 10.4.0.99 vs. 10.4.0.0/24 (subnet 255.255.255.0) - !! MATCH !!
[2020-06-05 21:26:07.648 3987] SQL: Comparing 10.4.0.99 vs. 10.4.0.128/25 (subnet 255.255.255.128) - NO MATCH
[2020-06-05 21:26:07.648 3987] SQL: Comparing 10.4.0.99 vs. 10.4.0.16/28 (subnet 255.255.255.240) - NO MATCH
[2020-06-05 21:26:07.648 3987] SQL: Comparing 10.4.0.99 vs. 10.4.0.3 (subnet 255.255.255.255) - NO MATCH
[2020-06-05 21:26:07.648 3987] SQL: Comparing 10.4.0.99 vs. 10.4.0.0/24 (subnet 255.255.255.0) - !! MATCH !!
[2020-06-05 21:26:07.648 3987] --> Found record for 10.4.0.99 in the client (ID 22)
In my opinion the entry /26 should also match and be selected.
The second thing where I am not sure if I had done everything correct is I don‘t see the statistics on the dashboard for
Edited your reply to improve readability.
Hi, thanks
not very familar with the formatting