Ich schaue mir das bei Gelegenheit mal an.
Grüße,
Kai
Ich schaue mir das bei Gelegenheit mal an.
Grüße,
Kai
Hallo paresy,
ich lausche hier weiterhin mit, da ich ja das gleiche Problem mit dem Homekit habe wie DrFrank. Mein IPS läuft auf einem Raspberry - ich habe mal auf meine anderen Pi’s (die noch nie einen IPS gesehen haben) geschaut: auf allen läuft der avahi-Daemon, so dass ich annehme, dass dieser per default mitinstalliert wird. Würde es helfen, bei erneutem Auftreten des Fehlers einfach mal den avahi-daemon auf dem IPS-Server abzuschießen, um zu schauen, ob der Fehler dann weg ist?
Gruß
Peter
Definitiv würde dies helfen
paesy
Ich denke ich bin ein Stück weitergekommen:
Bei mir ist das Problem gerade wieder aufgetreten. Was dabei aufgefallen ist war das auf dem iPhone meiner Frau die Geräte schon einen Tag vorher nicht mehr erreichbar waren, wogegen es bei meinen Devices einen Tag länger gedauert hat, bis auch bei mir die Geräte „keine Antwort“ anzeigten. Das könnte daran liegen, dass das iPhone meine Frau das heimische WLAN davor mal verlassen hat und meine Geräte nicht.
So sieht es aus, wenn der Fehler besteht. Man beachte die „-2“ im Domain-Namen.
root@mini:/home/stefan# ps -ef | grep avahi
avahi 736 1 0 Jul02 ? 00:17:00 avahi-daemon: running [mini[b]-2[/b].local]
avahi 747 736 0 Jul02 ? 00:00:00 avahi-daemon: chroot helper
root 32383 32322 0 09:39 pts/0 00:00:00 grep --color=auto avahi
root@mini:/home/stefan#
nach kill 736 startet der Deamon sofort neu und es sieht so aus (ohne die „-2“):
root@mini:/home/stefan# ps -ef | grep avahi
avahi 32673 1 2 09:44 ? 00:00:00 avahi-daemon: running [mini.local]
avahi 32674 32673 0 09:44 ? 00:00:00 avahi-daemon: chroot helper
root 32681 32322 0 09:44 pts/0 00:00:00 grep --color=auto avahi
root@mini:/home/stefan#
…und das Problem ist verschwunden. Die Geräte sind wieder erreichbar!!!
Jemand eine Idee wie man das zukünftig verhindert?
Bitte keine Vorschläge ala „schreib doch einfach einen Cromjob und schieße den Deamon 1x am Tag ab“
Ich vermute stark, dass das Problem weg wäre, wenn du avahi deinstallieren würdest. Ich weiß nicht wie viel du Ubuntu noch zusätzlich nutzt, aber du könntest die Server Variante installieren (die sollte by Default keinerlei Avahi Abhängigkeiten haben) und nur IP-Symcon installieren. Wir haben ja unseren eigenen DNS-SD Daemon und der kommt sich wohl mit dem avahi auf dem OS in die Quere
paresy
Das ist ein Out-Of-the-Box Ubuntu auf dem eigentlich nur Symcon läuft. Die Daemon wird also installiert, wenn man eure Installationsanweisung folgt. Im Prinzip könnte ich eine Deinstallation versuchen. Mir wäre es aber lieber ihr würdet herausfinden, was die Ursache ist, denn das entfernen eines Standardpakets ist eigentlich nur ein Workaround und kein Fix. Andere User haben das Problem ja offensichtlich auch.
Noch eine Beobachtung von eben:
zum Test der Theorie, dass man rausfliegt, wenn der Daemon „verbogen“ ist und man das LAN verlässt:
Dann:
Du sagst es könnte sein, dass ihr den Daemon früher mal verwendet habt. Dann such doch bitte mal, ob es noch Codefragmente gibt, die die Konfig des Daemons ändern.
Bei nächsten Mal, werde ich vor den Neustart mal folgendes prüfen:
systemd-resolve --status
cat /etc/avahi/avahi-daemon.conf
cat /etc/avahi/hosts
cat /etc/resolv.conf
ls /etc/avahi/services/
Wir haben bei Avahi nie Config-Files angepasst, sondern dies immer nur als Bibliothek verwendet. Bei dir wirkt es übrigens eher so, als wenn du Ubuntu als Desktop Variante nutzt und diese scheint Avahi direkt mit zu installieren. Somit kann es gut sein, dass du diese gar nicht deinstallieren kannst.
Ich bin ganz deiner Meinung, dass wir das Problem ordentlich fixen sollten - aktuell sind es aber immer noch Vermutungen, ob es daran liegt. Falls du also einen Moment hättest ein Ubuntu Server ohne Avahi aufzusetzen, würde uns das in der Suche sehr weiterhelfen.
paresy
Hmm, ich dachte eigentlich ich hätte die Server-Variante Installiert. Wie kann man das im nachhinein sehen?
root@mini:/home/stefan# systemd-resolve --status
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 2 (enp3s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.178.1
fd00::e228:6dff:fe76:1c8c
DNS Domain: ~.
root@mini:/home/stefan# cat /etc/avahi/avahi-daemon.conf
# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.
# See avahi-daemon.conf(5) for more information on this configuration
# file!
[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000
[wide-area]
enable-wide-area=yes
[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
publish-hinfo=no
publish-workstation=no
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no
[reflector]
#enable-reflector=no
#reflect-ipv=no
[rlimits]
#rlimit-as=
#rlimit-core=0
#rlimit-data=8388608
#rlimit-fsize=0
#rlimit-nofile=768
#rlimit-stack=8388608
#rlimit-nproc=3
root@mini:/home/stefan#
root@mini:/home/stefan# cat /etc/avahi/hosts
# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.
# This file contains static ip address <-> host name mappings. These
# can be useful to publish services on behalf of a non-avahi enabled
# device. Please bear in mind that host names are expected to be
# fully qualified domain names, i.e. ending in .local!
# See avahi.hosts(5) for more information on this configuration file!
# Examples:
# 192.168.0.1 router.local
# 2001::81:1 test.local
root@mini:/home/stefan#
root@mini:/home/stefan# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
DeInstall sollte möglich sein, ich habe nur noch nicht auf „YES“ gedrückt.
Ich denke die Infos oben helfen uns nicht wirklich weiter, oder?
Leider nein.
paresy
Alles klar.
Ich habe jetzt mal den avahi-deamon deinstalliert.
Jetzt heisst es wieder warten, ob das Problem noch auftritt.
Hallo Paresy,
Das Problem ist wieder da, trotzt deinstallierten avahi.
Jetzt weiss ich noch nicht mal, was ist Troubleshooten soll. Ich lass den Zustand jetzt erstmal und warte auf deine Vorschläge.
Fall dir nicht besseres einfällt werde ich den avahi dann wieder installieren, dann kann ich die Situation wenigstens mit einem einfache kill-Befehl bereinigen.
-Stefan
Habe eben den avahi wieder installiert, danach hat es sofort wieder funktioniert.
Ich wollte hier mal ein DANKE da lassen. Das Modul funktioniert einwandfrei. Ich nutze es seit Monaten ohne große Probleme. Hab ettliches zum laufen bekommen können! Vielen Dank.
Ich habe paresy mal einen PR (Lampe (Experte)) zukommen lassen.
Dort kann man die Status- und die Helligkeitsvariable angeben.
Somit benötigt man für einen Shelly Dimmer zum Beispiel keine Hilfsvariable mehr.
Grüße,
Kai
Hallo zusammen,
ich bekomme die Bridge auf dem RasPi (neu aufgesetzt) nicht zum Laufen. Sie wird auf dem iPhone einfach nicht angezeigt.
Gerade setze ich auf einem RasPi 4 alles neu auf. Connect Dienst läuft auf dem Neuen und Homebridge ist auf dem Alten beendet. Alexa klappt problemlos.
Ich habe die Kopplung zum iPhone mit und ohne Geräte versucht. Ich habe IPS mehrfach gestoppt und gestartet und auch den RasP neu gestartet.
Im Debugfenster vom Serversocket passiert nichts. Im Debug-Fenster der HomeKit Bridge kommt Clearing parings und getting current setup code …
Was müsste/ könnte ich an einer Firewall am Raspi einstellen bzw prüfen? Ich hab sonst keine Idee mehr…
Grüße
papaschlumpf
-------------- EDIT ------------
–> ggf. war die Lösung den alten RasPi vom Netz zu nehmen. Zugleich habe ich aber unter Experteneinstellungen den Port um eins erhöht. Zack ist die Bridge auf dem iPhone aufgetaucht. Den Port habe ich dann auf die Standardeinstellung wieder zurück gesetzt und danach erst die Verbindung hergestellt. Läuft!
Hi zusammen,
Gibt es aktuell eine Lösung, welche dauerhaft funktioniert?
Also das die IPS als Bridge erkannt wird…
VG
Eigentlich funktioniert dies hier für fast alle. In der Vergangenheit hatten wir ein paar Sonderfälle:
a) DrFrank hat welche dokumentiert
b) Ihr habt zwei mal IP-Symcon am Laufen und somit gibt es zwei gleiche Bridges und die Apple Geräte kommen durcheinander
c) Docker muss als Host Networking laufen
paresy
Hatte Homebridge erfolgreich am Laufen. Nach dem letzten Major Update ging es nicht mehr.
Nun kann ich Symcon nicht mehr an Homekit anlernen. System wird erkannt. Code zum Koppeln kann ich auch eingeben.
Dann rödelt das Apple Device bis es mit der Meldung dass, das Verbinden mit der Bridge fehlgeschlagen ist abbricht.
Modul hat neueste Version. Symcon auch. Bridge ID und Name habe ich bereits geändert. Ohne Erfolg.
LÖSUNG: AVAHI auf raspbian deaktiviert ( systemctl disable avahi-daemon ) und symcon neu gestartet
Bei mir funktioniert die Einrichtung leider auch nicht…
Reines Ubuntu-System ohne Desktop… Kein Avahi installiert
Ich hab in der Bridge eine Lampe hinzugefügt um das ganze mal zu testen.
Wenn ich in Homekit das „Symcon-Gerät“ hinzufüge, wird noch die Nummer abgefragt und dann kommt für ne Minute die Verbindungsanzeige und dann der Hinweis, dass das Gerät nicht hinzugefügt werden kann, da das Gerät nicht erreichbar ist…
Bei mir lief Homekit sehr lange Zeit auf Ubuntu 18.04 als Virtuelle Maschine auf dem Synology NAS ohne Probleme.
Nach einem Update ging aber nichts mehr.
Leider bekomme ich es nun auch nicht mehr ans laufen.
Habe Symcon komplett neu unter Ubuntu 20.04 Server aufgesetzt.
Zum neu einrichten in der Home App habe ich nur 1 Lampe hinzugefügt.
Ich bekomme Symcon als Gerät angezeigt und kann auch noch den Code eingeben.
Danach rödelt das iPhone vor sich hin und bricht dann mit: Vorgang hat Zeitlimit überschritten ab.
Im Debug wird noch vor „Zeitlimit überschritten“ ein Disconnect angezeigt.
Wenn ich es erneut hinzufügen will, wird Symcon nicht mehr angezeigt.
Sobald ich den Symcon Dienst neu starte könnte ich Symcon wieder hinzufügen, aber es wird wieder abgebrochen wg. Zeitlimit.
Auf der Synology habe ich die Firewall komplett deaktiviert, keine Änderung.
AFP Dateidienst ist auf der Synology auch Deaktiviert
Gibt es irgendetwas das man noch probieren kann?