Also es gibt den Service Valve:
Required Characteristics:
[ul]
[li]Active[/li][li]In Use[/li][li]Valve Type[/li][/ul]
Ich schaue mir das mal in Ruhe an.
Grüße,
Kai
Cool, vielen Dank für deine Mühe vorab.
Der Fehler ist jetzt wieder aufgetreten. Mit den vier Schritten von DrFrank kann ich es dann wieder zum Laufen bringen. Bei Schritt 2 muss ich auf jeden Fall einen Reboot durchführen, ein Restart alleine von IPS half nicht weiter.
Ich habe für die Ereignisse
- Aufruf der Homekit-App (mit den Meldungen „keine Antwort“)
- Dummy-Änderung der DNS-SD Instanz (mit der IPS-Fehlermeldung „Server Collision“)
- und dem erneuten Aufruf der Homekit-App nach Durchführung der vier Schritte von DrFrank (dann läuft es wieder)
tcpdumps auf dem Interface des IPS-Servers gemacht. Ic sehe in den Traces einige MDNS.-Pakete von der IPv6.Adresse des IPS-Servers zu ff02::fb, welche mir aber auch nichts weiter sagen. @paresy: hilft das evtl. weiter?
Gruß
Peter
Eben gerade wieder alle Geräte Offline. Nach meinen 4 Steps geht es wieder.
Keine Ahnung warum das auftritt, wäre aber nett, wenn Paresy und der Autor des Modules sich das mal gemeinsam ansehen könnten 
Auch wenn sich der Fehler bei ihnen vielleicht nicht nachstellen lässt, kann man doch aus der Art der Behebung ein paar Schlüsse ziehen, denke ich.
Das spannende ist, dass es eine Server Kollision gibt. Das bedeutet, dass bei euch im Netzwerk eigentlich eine zweite HomeKit Bridge aus IP-Symcon heraus aktiv ist.
paresy
Hallo Paresy,
Ich hatte Symcon ganz am Anfang mal festweise auf dem PC installiert. Ist aber deinstalliert. Es gibt definitiv nur 1 Symcon im Netz.
Eine Besonderheit die ich sehe ist Dual-Stack Betrieb im LAN&WAN.
Verbindung war heute wieder weg. So sah das von einem anderem Linux Rechner im Netz aus:
root@cubietruck:/home/stefan# avahi-browse -a | grep Symcon
+ wlan0 IPv6 Symcon _hap._tcp local
+ wlan0 IPv4 Symcon _hap._tcp local
Si sieht es aus, wenn man den Eintrag im DNS-SD löscht:
root@cubietruck:/home/stefan# avahi-browse -a | grep Symcon
^X^CGot SIGINT, quitting.
Und so, nachdem er automatisch bei Neustart wieder angelegt wurde:
root@cubietruck:/home/stefan# avahi-browse -a | grep Symcon
+ wlan0 IPv6 Symcon _hap._tcp local
+ wlan0 IPv4 Symcon _hap._tcp local
Mit Resolve (Zustand: funktioniert):
root@cubietruck:/home/stefan# avahi-browse -ar | grep Symcon
+ wlan0 IPv6 Symcon _hap._tcp local
+ wlan0 IPv4 Symcon _hap._tcp local
= wlan0 IPv6 Symcon _hap._tcp local
txt = ["sf=0" "ci=2" "ff=0" "s#=1" "c#=51" "id=F3:F3:5F:4D:01:5F" "pv=1.0" "md=Symcon"]
= wlan0 IPv4 Symcon _hap._tcp local
txt = ["sf=0" "ci=2" "ff=0" "s#=1" "c#=51" "id=F3:F3:5F:4D:01:5F" "pv=1.0" "md=Symcon"]
Das ist wohlgemerkt nicht der Rechner auf dem Symcon (unter Linux) selbst läuft.
Dort sieht es so aus solange es funktioniert:
root@mini:/home/stefan# avahi-browse -a |grep Symcon
+ enp3s0 IPv6 Symcon _hap._tcp local
+ enp3s0 IPv4 Symcon _hap._tcp local
^CGot SIGINT, quitting.
Hilft das?
Weiss jemand wie ich prüfen kann wie Symcon aufgelöst wird?
„whois Symcon“ funktioniert schon mal nicht…
Das hilft sehr und könnte sehr viel erklären. Denn: Wenn DNS-SD IPv6 anbietet, dann geht das in die Hose, sobald dein Gerät darauf zugreifen will. Der Server Socket in IP-Symcon lauscht aktuell nur auf IPv4. Auf die schnelle habe ich mal geschaut, ob man das „anbieten“ auf IPv6 deaktivieren kann - leider nein. Somit muss IP-Symcon auf kurz oder lang IPv6 im Server Socket anbieten.
Testweise könntest du mal IPv6 auf dem IP-Symcon Server deaktivieren. Damit könnten wir verifizieren, ob das wirklich das Problem ist. Aktuell klingt das aber sehr sehr plausibel.
Vielen Dank für die Analyse!
paresy
Liebe Community,
Ich habe zwei Instanzen von IPS, beide laufen mit der Homekit-Bridge einwandfrei. Tolle Sache, ich binde hauptsächlich LCN Komponenten ein.
In Homekit Bridge ist allerdings
a) Kein Windsensor in m/s
b) und als Regensensor habe ich den Leckagesensor genommen. Geht Prima, aber bei Regen kommt die Warnung „Leckage im Garten“
Wird das irgendwann noch erweitert?
Grüße, Ralf
Hi Paresy,
Das kann es nicht allein sein. Hier noch der fehlende Zustand „geht nicht“ mit avahi-browse von einem anderen Linux Rechner. Er löst weder IPv4 noch IPv6 auf in diesem Zustand:
stefan@cubietruck:~$ avahi-browse -ar | grep Symcon
+ wlan0 IPv6 Symcon _hap._tcp local
+ wlan0 IPv4 Symcon _hap._tcp local
Failed to resolve service 'Symcon' of type '_hap._tcp' in domain 'local': Timeout reached
Failed to resolve service 'Symcon' of type '_hap._tcp' in domain 'local': Timeout reached
^CGot SIGINT, quitting.
Nach Reboot des Symcon Servers:
stefan@cubietruck:~$ avahi-browse -ar | grep Symcon
+ wlan0 IPv6 Symcon _hap._tcp local
+ wlan0 IPv4 Symcon _hap._tcp local
= wlan0 IPv6 Symcon _hap._tcp local
txt = ["sf=0" "ci=2" "ff=0" "s#=1" "c#=51" "id=F3:F3:5F:4D:01:5F" "pv=1.0" "md=Symcon"]
= wlan0 IPv4 Symcon _hap._tcp local
txt = ["sf=0" "ci=2" "ff=0" "s#=1" "c#=51" "id=F3:F3:5F:4D:01:5F" "pv=1.0" "md=Symcon"]
Das löschen/neu anlegen des Eintrags kann man sich wohl komplett sparen. Es reicht ein Neustart. Werde das nächste Mal noch testen, ob ein Neustart von Symcon allein reicht…
Für mich sieht es so aus, als ob sich da nach eine Weile einfach was aufhängt…
Kann es sein, dass der DHCP eine andere IP-Adresse deinem Gerät zuweist?
paresy
PING!
Hallo Paresy.
Bitte kommentiere das doch mal bitte
PONG. Habe ich. Bitte beantworte doch mal meine Frage bitte 
paresy
Na, das hat ja zeitlich gut gepasst mit dem PING
Natürlich hat der Symcon Server eine fixe IP.
Der Cubietruck von dem aus ich getestet habe hat eine DHCP Adresse, die aber per Fritzbox festgenagelt ist. Die hat sich auch nie geändert, dass hätte ich beim SSH Zugriff jeweils sofort gemerkt. Dito für das iPad, welches als Gateway funktioniert.
-Stefan
Bei mir besteht das Problem momentan wieder. Du kannst dich ja mal melden, wenn du Zeit hast oder mir sagen, was ich noch checken kann/soll.
Ansonsten starte ich den Symcon Dienst heute Nachmittag mal neu und berichte was passiert.
-Stefan
Da ist heute zeitlich etwas knapp dran bin, würde ich vorschlagen du startest erstmal neu und berichtest.
paresy
Okay.
Ich habe restart und stop/start getestet: Löst das Problem nicht
Ein Reboot des Ubuntu Rechers dagegen hilft und die Geräte sind wieder erreichbar.
Auf dem Ubuntu Rechner läuft nur Symcon, sonst nichts.
Was ich diesmal nicht getestet habe war die Kombination „Eintrag im DNS-SD löschen und dann restart von Symcon“.
Wenn ein IP-Symcon neustart nicht hilft, dann wird aber die Fehlersuche doch komplizierter. Denn im Prinzip ist ja alles, was wir beeinflussen können, innerhalb der Software. Wir liefern ja auch den DNS-SD Stack komplett selber mit aus.
Magst du mal schauen ob evtl. irgendein avahi Paket installiert ist? Vielleicht stören die sich gegenseitig.
paresy
Hi Paresy
Die avahi-utils sind natürlich installiert.
Es läuft auch der Daemon:
root@mini:/home/stefan# ps -ef | grep ava
avahi 780 1 0 15:35 ? 00:00:07 avahi-daemon: running [mini.local]
avahi 794 780 0 15:35 ? 00:00:00 avahi-daemon: chroot helper
root 11129 10953 0 18:33 pts/0 00:00:00 grep --color=auto ava
Das ist aber nichts was ich gegenüber der Standardinstallation von Ubuntu geändert hätte. Wie gesagt es ist ein reines Symcon Gerät.
Das File /etc/resolv.conf ist jedenfalls leer/auskommentiert. Das Verzeichnis /etc/avahi/services/ ist leer. File /etc/avahi/hosts ist leer.
Noch irgendwelche Anfragen, die ich machen soll?
Ich kenne mich mit den avahi-Zeugs leider auch nicht aus.
Es kann sein dass alte IPS Versionen den installiert haben. Magst du versuchen den Deamon zu deinstallieren?
paresy
Soll ich wirklich. Die Abhängigkeiten scheinen mir doch recht umfangreich…
root@mini:/home/stefan# apt remove avahi-daemon
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
apache2-bin libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap
Verwenden Sie »apt autoremove«, um sie zu entfernen.
Die folgenden Pakete werden ENTFERNT:
avahi-daemon avahi-utils gnome-user-share libapache2-mod-dnssd libnss-mdns
0 aktualisiert, 0 neu installiert, 5 zu entfernen und 0 nicht aktualisiert.
Nach dieser Operation werden 1.137 kB Plattenplatz freigegeben.
Das ist ein Produktiv-System. Ich will mir das nicht zerlegen. Versuche doch erstmal auf deinem Testrechner den Daemon zu installieren und schaue mal, ob du dann das Problem nachvollziehen kannst…
Ich werde erstmal den Daemon abschießen beim nächsten Mal. Mal sehen ob das hilft.
-Stefan