Ist bereits erledigt 
Prima.
Was verwendet Dein RPi4 bzw. 3B denn als interen DNS-Server?
Das findet sich in:
cat /etc/resolv.conf
Da wird mir ausschließlich dieser Inhalt angezeigt.
In der Vergangenheit habe ich da nichts editiert.
nameserver 9.9.9.9
nameserver 149.112.112.112
Gilt oder galt das auch für den 3B (wenn der noch verfügbar ist)?
Das kann ich jetzt leider nicht mehr nachschauen, habe den 3B bereits für einen Kollegen vorbereitet.
Ich kann nur so viel sagen, da ich Pihole auf dem 3B noch nicht installiert habe, dass mir dort die FritzBox als DNS-Server angezeigt wird.
Hab dieses gerade in meinem Gastnetzwerk verbunden.
nameserver 192.168.179.1
Offensichtlich kennt nur Pi-hole die Namensauflösung für homebridge.
Die Beobachtung des Ausfalls von homebridge könnte zwei drei Ursachen haben:
1.) Der Homebridge-Server versucht die Namensauflösung über die in /etc/resolv.conf angegebenen DNS-Server, und diese kennen homebridge natürlich nicht.
Hier sollte Abhilfe zu schaffen sein, wenn Du den Server auf die Fritzbox oder Pi-hole änderst.
Im Falle einer statischen IP-Adressdefinition erledigst Du das auf Deinem RPi über
sudo nano /etc/dhcpcd.conf
Dort änderst Du die DNS-Server auf
domain_name_servers=127.0.0.1 192.168.200.1
Anschliessend solltest Du einen Reboot durchführen.
Da Pi-hole 4 noch standardmässig 127.0.0.1 konfiguriert hat, passt das zu Deiner Aussage, dass es früher funktionierte.
Seit Pi-hole 5 wird resolv.conf nicht mehr angepasst, da dies öfters zu Problemen bei Updates geführt hat und für Pi-hole auch nicht erforderlich ist, siehe Release Notes.
Offen ist dabei die Frage, woher die Einträge für nameserver 9.9.9.9 und 149.112.112.112 kommen.
Pi-hole tut diesbezüglich nichts, und die FB verteilt bei Dir über DHCP ihre eigene IP. Sofern Dein RPI ein (fixes) DHCP-Lease der FB bezieht, würde ich daher 192.168.200.1 in resolv.conf erwarten.
2.) Der DNS-Rebind-Schutz Deiner FB unterbindet die DNS-Antworten für homebridge.
Generell würde sie das für alle DNS-Antworten tun, die eine lokale IP-Adresse enthalten (bei Dir also aus dem Bereich 192.168.200.0/24).
In diesem Fall sollte Pi-hole in der FB als Ausnahme vom DNS-Rebind eingetragen werden.
Diesen Fall halte ich allerdings für wenig wahrscheinlich, da http://pi.hole bei Dir keine Probleme bereitet.
EDIT:
3.) Die Fritzbox kennt eine veraltete IP-Adresse für homebridge
Das haben wir bislang noch nicht geprüft:
nslookup homebridge 192.168.200.1
Da die FB in der Verarbeitungskette zuerst befragt wird, könnte es hier zu Fehlern kommen,.wenn die FB sich aus einer früheren Verwendung (z.B. Deinem 3B?) eine andere IP-Adresse für homebridge gemerkt hat.
Ich weiss für diesen Fall leider nicht, wie man die FB dazu bringen kann, das zu vergessen. 
Eine Möglichkeit zur Vermeidung wäre dann, Pi-hole als lokalen DNS-Server in der FB zu konfigurieren, damit Pi-hole die Anfragen als erster sieht (siehe z.B. Fritz!Box (DE) - Pi-hole documentation).
Ich würde die Fehlerbehebung also zunächst mit 1) versuchen.
Danke dir schon mal für deine hilfreiche und vor allem schnelle Fehleranalyse 
Was mir in der dhcpcd.conf auffällt, dass die Adresse für den wlan0 adapter als statisch eingetragen ist.
Das sollte nicht notwendig sein, da meine FritzBox ja den DHCP-Server bereitstellt und ich dort auch anhand der MAC-Adresse dem Pi die IP zuweise.
Kannst du mir vielleicht einen Hinweis geben, wie ich das wieder auf DHCP umstelle? Vielleicht erledigt sich das Problem dann von allein. Ganz unten ist der statische Eintrag. Reicht hier ein einfaches auskommentieren?
Hier mal meine dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1
# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
interface wlan0
static ip_address=192.168.200.54/24
static routers=192.168.200.1
static domain_name_servers=9.9.9.9 149.112.112.112
Die vier Zeilen löschen oder für eine spätere Wiederverwendung auskommentieren (# voranstellen). Im letzteren Fall würde ich trotzdem die Anpassung der DNS-Server wie von mir vorgeschlagen vornehmen.
Nach einem Neustart sollte der RPi dann seine Adresse von der FB beziehen, wo hoffentlich eine fixe Adresse eingestellt ist ("Diesem Gerät stets dieselbe Adresse zuweisen" o.ä.).
Danke, das werde ich auf jeden Fall mal auskommentieren und den nameserver wie von dir erwähnt abändern.
Du hast eben erwähnt, dass du dich fragst, woher die Einträge kommen.
Die frische Installation des Pi aus meinem Gastnetzwerk ergibt genau die gleichen Einträge, daher muss das scheinbar durch die Installation kommen oder ich habe beim Setup einen Fehler gemacht, was ich natürlich nicht ausschließen will, nur viel falsch machen kann man ja jetzt nicht 
dhcpcd.conf aus dem Gastnetzwerk
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1
# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
interface wlan0
static ip_address=192.168.179.10/24
static routers=192.168.179.1
static domain_name_servers=9.9.9.9 149.112.112.112
Danke dir. Ich habe übrigens Variante 1 schon ausprobiert, das hat leider nicht zum Erfolg geführt.
Deine Idee mit der reservierten IP-Adresse in der FritzBox ist schon nicht schlecht. Ich habe früher dem Pi3B die 192.168.200.54 fest zugewiesen, als ich den dann mit dem 4B abgelöst habe, habe ich natürlich die MAC-Adresse in der Reservierung geändert und als ich dann komische Effekte hatte, habe ich die FritzBox auch mal neugestartet, nachdem die Reservierung des 3B aufgelöst wurde, damit ich sie wieder für den 4B verwenden kann. Das hat schon geholfen.
Die IP hat sich also nicht geändert, nur die MAC.
Folgendes ist auf deinen Punkt 3 herausgekommen.
Server: 192.168.200.1
Address: 192.168.200.1#53
Name: homebridge.fritz.box
Address: 192.168.200.54
Name: homebridge.fritz.box
Address: 192.168.200.28
Das ist definitiv der Grund für Deine Probleme.
Der Zugriff auf http:/homebridge funktioniert nur, wenn der Client zufällig die richtige der beiden IP-Adressen verwendet.
Hm, die 192.168.200.28 ist die LAN-Schnittstelle, die ich eigentlich gar nicht verwende.
Kann ich die denn irgendwie da raus löschen oder wie bekomme ich den Eintrag weg?
Tut mir leid:
Alle meine diesbezüglichen Versuche mit meiner FB sind gescheitert.
Einzig den Weg über eine im Abschnitt landevices manipulierte Fritzbox-Export-Datei habe ich noch nicht versucht.
Ich bin jetzt aber erst einmal off.
Danke dir! Ich hab es zumindest geschafft den Eintrag zu löschen
Ich habe in der FritzBox unter Netzwerk den Eintrag mit der 192.168.200.28 gesucht und dann hinten auf das "X" für löschen geklickt.
Einen Neustart der FritzBox habe ich nicht durchführen müssen.
Mal schauen, wie sich die WebUi nun verhält.
Server: 192.168.200.1
Address: 192.168.200.1#53
Name: homebridge.fritz.box
Address: 192.168.200.54
Alles gut, vielen Dank schon mal für deinen super Support!
Ich werde das dann mal beobachten und mich nochmal melden, ob positiv oder negativ, wird sich dann zeigen
Also das war es scheinbar nicht.
FritzBox und Pi neugestartet. Fehler besteht weiterhin.
Kann das denn etwas mit dem DNS-Dienst auf dem Pi zutun haben?
Ich habe viel gelesen, dass Pihole "dnsmasq" verwendet, die "dnsmasq.conf" existiert auch, aber das Paket ist gar nicht installiert.
Hier mal die "01-pihole.conf". Die Zeile mit "log-queries" habe ich irgendwo gelesen, sollte man auskommentieren, dann hätte sich das Problem erledigt, hat es aber leider nicht.
addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list
localise-queries
no-resolv
cache-size=10000
#log-queries
log-facility=/var/log/pihole.log
local-ttl=2
log-async
server=9.9.9.9
server=149.112.112.112
domain-needed
expand-hosts
bogus-priv
except-interface=nonexisting
server=/use-application-dns.net/
Im Rahmen der Homebridge habe ich folgendes Paket "Avahi" installiert, was ja scheinbar auch ein DNS-Dienst ist.
Linux ist jetzt nicht so mein daily business, daher bin ich hier unsicher, ob das denn so richtig ist.
sudo apt-get install -y libavahi-compat-libdnssd-dev
Vielen Dank!
Heisenberg
Ich werde mich wohl dazu entscheiden den Pi neu zu installieren.
Im Grunde habe ich keine Einschränkung, aber es nervt mich einfach.
Dann habe ich halt noch ein bisschen Übung.
Trotzdem vielen Dank für deinen Einsatz!
Gruß
Heisenberg
Also ich weiß nicht was schief läuft, aber selbst nach einer Neuinstallation des gesamten Pi kommt das Problem erst auf, nachdem ich Pihole installiert habe.
Da muss irgendwo der Hase im Pfeffer sitzen.
Ich habe gerade etwas interessantes festgestellt.
Der Aufruf funktioniert nicht.
http://homebridge.fritz.box/admin
http://homebridge.fritz.box:8080
Der Aufruf funktionert
In der Vergangenheit hat der Aufruf mit fritz.box aber immer bestens funktioniert.
Wo wird denn wohl auf dem Pi die local "domain" eingetragen?
