On the other hand, if anyone in Canada wants to send me their Hue Hub I’ll pay for the postage. I’m serious. 
I’m surprised I read through this whole thread and although I understand the thought of privacy and not having accounts, we all have them and we all use them. In any case I don’t have any issues with accounts although am generally trying to move local.
As a companies who delivers services in Europe they need to be gdpr compliant.
And who exactly ever said anything else? Obviously companies need stick to the laws 
I really don’t get the intention from your posts and I really do hope you are not an employee from Philips/Signify 
I already complained about this 4 months ago, as I was already forced to use an account for Matter.
After getting lied to multiple times (like “for security reasons”), our conversation ended with “bullshit”. And I’m usually a very polite person.
I would move away from they hub instantly, unfortunately I still have the very oldschool round touchlink remotes, which don’t work with other zigbee controllers.
I now regret introducing my partner to the Hue ecosystem a year ago. I’ve had a complete change of heart, going from recommending it to avoid it at all costs.
And btw, how can an approx 40 page terms of use be legal?
My Pi-Hole indicates that my Philips Hue Bridge contacts diag.meethue.com every minute.
If I blacklist diag.meethue.com, Pi-Hole’s log indicates the frequency of requests increases dramatically from once a minute to every 2 to 5 seconds. As a result, the Hue Bridge floods Pi-Hole’s log and skews the daily statistics.
I then tried this trick to direct the Bridge’s DNS requests back to itself.
I added file /etc/dnsmasq.d/99-bypass.conf containing:
# Self DNS, silences DNS requests
dhcp-option=tag:selfDNS,6,127.0.0.1
# Silence DNS requests from Philips Hue Bridge
dhcp-host=XX:XX:XX:XX:XX:XX,set:selfDNS
Unfortunately, that failed to work. Pi-Hole’s log still shows once per minute requests from the Bridge to diag.meethue.com and it’s using my external DNS provider (OpenDNS) to perform name resolution.
So blocking diag.meethue.com results in a substantial increase in network traffic (i.e. blocked DNS requests) and my attempt to redirect its DNS requests to itself didn’t work. Does anyone have any other ideas for blocking the Bridge without increasing the frequency of its requests?
FWIW, the Hue Bridge’s behavior when blocked (increased requests) is not unique. I’ve seen the same behavior when Nanoleaf Canvas is blocked.
Can’t you simply block all traffic between the hub and the Internet directly on your firewall or router to make life easier? I do that instead of changing Pi-Hole since while the majority of calls will use Pi-Hole because it’s calling a host name, some (like a handful of Chinese devices I have) call direct IP addresses.
I’ve seen similar results as you, you try to block something and suddenly it loses it’s mind and starts calling constantly, it’s very frustrating how many devices feel the need to talk to the Internet constantly. Granted, some of these are simple NTP requests but most are not and why I default to blocking any device that doesn’t absolutely require the Internet to work.
I just checked Pi-Hole’s log and it now shows just 30 minutes worth of DNS requests by the Hue Bridge and then nothing.
Seems like it takes some time for the DNS redirection to take effect? 
Do you know if that prevent its DNS requests from appearing in Pi-Hole’s log? If so, then I’ll scrap the DNS redirection and simply do that.
Ikea’s Styrbar and Tradfri remotes are inexpensive, and work nicely with ZHA. If remotes are the only reason to hold onto the Hue hub, I’d definitely look at the Ikea remotes as a replacement.
Pi-Hole will still register because it’s your default DNS, the firewall solution just keeps it from ever connecting even if it resolves. You can fix that, though, by editing the hub and setting the IP manually and set the DNS to a non-existent server. Alternatively you could also edit the routing tables of the Pi-Hole computer to actively reject all traffic from the hubs IP address with something like this:
# iptables -A INPUT -s 192.168.1.1 -j DROP
# service iptables save
And replace the 192.168.1.1 with the hub address.
Redirecting its DNS server address to itself seems to be having the desired effect (blocked and silent). However if I discover any drawbacks then I will use your suggestion.
You need a way to reach your HA installation, nabu casa is only more convenient, but totally optional if you know what to do (or have time to secure access to your HA)
Again, it’s convenience, until now the hub has been a fast way to configure lights, zones and scenes and then access your full lights configuration from HA using a local API
It’s privacy, it’s ease of access, it’s control, I know we have to deal with shitty cloud accounts, but in most cases you know it from the start and decide if you need that kind of device, here we have devices that we bought because of local access that are forced to move to a cloud account and this is not acceptable
Zigbee2mqtt has some support of touchlink, depending on the coordinator you use
I don’t know your zigbee setup but it’s worth a look
That probably still causes (useless) network traffic
Probably also causes network traffic as the dns requests most likely are send to LAN before they “bounce” back to the who hue. Like the device is spamming itself - but still utilizing your network.
And all people - including the ones that don’t use the cloud but stay local are forced to fulfill the data lust of Philips / signify (that are not even embarrassed to spreading lies about “security”)…
I was making an observation and sharing my experience. You can direct your outrage elsewhere. Thanks.
To make migrating away from the hue bridge to an open alternative a bit easier, here’s the full list of all scenes in the hue app scene gallery with their respective 5 x,y color values:
I’m looking forward to seeing a custom_component providing a service that takes a group of lights and applies a scene to those 
I have a slightly different perspective. I’ve used Hue lights for many years in a few different houses and during that time I received the dreaded ‘Your Hue Account had a problem and has been reset’ email. This basically meant that the hue hub was factory reset and no backup exists! In the past 18 months this happened three times in two different properties with different hub hardware.
I really complained to support that a product like this must include backup and recovery options. After the last time this happened I was just starting to implement HA and now have 80% of my Hue bulbs on ZHA where I manage and have verified the backup works.
If Hue putting data in the cloud means they can offer recovery, then that is at least progress - but too late for me.
it’s no outrage, I was simply stating a fact, a lot of people use the hue hub because is convenient, it’s easier to use, and local (until now, and still they didn’t remove the local API), so only few people bother to move lights under zha or z2m.
uhmm that sparks my interest, I will add the lights to my coordinator anyway, but I will try to integrate diyhue to use that app or anything that rely on hue (for example entertainment are using ambilight tv)
Through the power granted to me by chatGPT I now bring you: The thing I suggested 4 hours ago.
Nice @Hypfer, I saw that list you posted and thought “if nobody builds an extension for that then perhaps I will”. I have a suggestion for future improvement: changing scenes like Hue. I rarely use a static scene where the lights are set to specific colors/levels and stay there, generally I use the Hue’s various automated scenes that are constantly changing colors gradually.
I’m sure getting at those auto scene settings might be challenging given what it took to get the original static scene list, but it would be a cool addition!