homebridge/homekit

Begonnen von justme1968, 01 Februar 2016, 16:16:37

Vorheriges Thema - Nächstes Thema

hoppel118

#2985
OK, zu früh gefreut. Hatte gerade wieder "keine Antwort" in der Home-App und das Ausrufezeichen in der Eve-App. Ein paar Minuten später geht nun wieder alles. Jetzt gehen mir wirklich langsam die Ideen aus. Ich werde mich nun nochmal meinem IoT-VLAN (LAN und WLAN) widmen. Vielleicht läuft da irgendwas schief. Mein FHEM-Server hat Zugriff auf das IoT-VLAN in dem sich meine HUEBridge und mein Xiaomi Roborock (Saugroboter) befinden. Aus dem IoT-VLAN heraus können keine Verbindung zu meinem FHEM-Server bzw. meiner Homebridge aufgebaut werden.

Testweise werde ich gleich mal die Hue- und Xiaomi-Homebridge-Instanzen deaktivieren. Mal sehen, ob ich das Problem dann mit der Homematic-Instanz, die keinen Zugriff auf das IoT-VLAN benötigt, auch habe.

Hat hier noch jemand sowas in Betrieb und eine Idee wo man schauen könnte?

Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

stratege-0815

Deine Infrastruktur scheint erheblich komplexer zu sein.
Ich habe nur ein Netz an einer fritzbox 7490 und trotzdem diese Probleme.
Auch nicht immer, geschätzt >20% oder weniger.
Ich versuche es einmal mit logging reduzieren und Neustart von fhem und Homebridge per chrontab.
Wenn sich das über vier Wochen bewährt kann ich damit leben.

hoppel118

Moinsen,

jo, stimmt, ganz anderer Komplexitätsgrad! ;)

Ich habe mich auch gerade nochmal ein Bisschen mit der Problematik beschäftigt. Mittlerweile habe ich meine drei Homebridge Instanzen alle mal einzeln gestartet. Erkenntnis: Das Problem tritt bei allen Instanzen auf und kann nicht auf eine bestimmte Homebridge Instanz bzw. einen Hersteller zurückgeführt werden. Insbesondere wenn ich das WLAN mit meinem iPhone verlasse, dauert es gefühlt ewig bis meine Homebridge Instanzen in der Home bzw. Eve App verfügbar sind bzw. erkannt werden.

Ich habe mich dann ein Bisschen mit dem Bonjour Service beschäftigt und festgestellt, dass ich in einem Bonjour Browser (ich nutze dafür die App "iNet Pro", hatte ich sowieso schon auf meinem iPhone installiert) nach Deaktivieren und erneutem Aktivieren meines WLANs am iPhone dort nichts finde. Erst wenn die Home bzw. Eve App auch meine Homebridge wieder erreicht, sehe ich dort verschiedene Einträge/Services.

Über ein wenig Googeln bin ich dann auf folgenden Beitrag gestoßen:

https://help.ubnt.com/hc/en-us/articles/360001004034-UniFi-Best-Practices-for-Managing-Chromecast-Google-Home-on-UniFi-Network

In diesem Beitrag geht es zwar Chromecast und Google Home in einem Unifi Netzwerk, aber es kommt meiner Umgebung sonst sehr nahe (verschiedene VLANs für Private und IoT, etc.). Demnach habe ich nun folgendes über meinen Unifi Controller konfiguriert:


  • In all meinen LANs: "IGMP Snooping aktivieren"
  • In all meinen WLANs: "Erweiterung für Multicast (IGMPv3) aktivieren"
  • Unter "Dienste - MDNS": "Multicast DNS aktivieren"

Alle Optionen waren bei mir bisher deaktiviert oder nicht konsistent in den verschiedenen VLANs konfiguriert. Insbesondere die MDNS Option lässt mich hoffen, da MDNS ja auch für die Homebridge benötigt wird. Das coole ist, dass ich mich nun vom WLAN trennen und neu verbinden kann und die Homebridge danach sofort von Home bzw. EVE gefunden wird. Das ist schonmal ein großer Fortschritt, wenn nicht sogar "der Fortschritt". Momentan sieht es vielversprechend aus. Drück mir die Daumen. ;)

Beim Googlen bin ich noch auf ein paar weitere Dinge gestoßen, die evtl. bei der Fehlersuche helfen können.

Mit "netstat -na | grep <homebridge port>" kann man beispielsweise prüfen, ob ein Client und wenn welcher mit der Homebridge verbunden ist. Bei mir sieht das für meine 3 Instanzen bspw. wie folgt aus:

root@omv4:~# netstat -na | grep 51821
tcp6       0      0 :::51821                :::*                    LISTEN
tcp6       0      0 10.100.100.11:51821       10.100.100.104:49484      VERBUNDEN
tcp6       0      0 10.100.100.11:51821       10.100.100.161:49792      VERBUNDEN
root@omv4:~# netstat -na | grep 51822
tcp6       0      0 :::51822                :::*                    LISTEN
tcp6       0    232 10.100.100.11:51822       10.100.100.101:50262      VERBUNDEN
tcp6       0      0 10.100.100.11:51822       10.100.100.104:49481      VERBUNDEN
tcp6       0      0 10.100.100.11:51822       10.100.100.161:49789      VERBUNDEN
root@omv4:~# netstat -na | grep 51823
tcp6       0      0 :::51823                :::*                    LISTEN
tcp6       0      0 10.100.100.11:51823       10.100.100.161:49787      VERBUNDEN
tcp6       0      0 10.100.100.11:51823       10.100.100.104:49485      VERBUNDEN
tcp6       0    232 10.100.100.11:51823       10.100.100.101:50261      VERBUNDEN


Auf der 10.100.100.11 läuft meine Homebridge. Die ...101, ...104 und ...161 sind unsere iPhones und ein iPad. Das ist sicherlich mal gut, um zu schauen, was da überhaupt auf dem Homebridge Port passiert.

Auf Port 5353 läuft mdns. netstat sieht da bei mir wie folgt aus:

root@omv4:~# netstat -an | grep 5353
udp        0      0 0.0.0.0:5353            0.0.0.0:*
udp        0      0 0.0.0.0:5353            0.0.0.0:*
udp        0      0 0.0.0.0:5353            0.0.0.0:*
udp        0      0 0.0.0.0:5353            0.0.0.0:*
udp6       0      0 :::5353                 :::*


In dem Zusammenhang kann auch noch das mdns.interface interessant sein: https://github.com/nfarina/homebridge/issues/1957

Bei einigen anderen Leuten hat es etwas gebracht in der Datei "/etc/avahi/avahi-daemon.conf" den Parameter "use-ipv6" auf "no" zu setzen, auch wenn das eigentlich kein Problem darstellen sollte. Bei mir steht es momentan noch auf "yes", auch wenn ich ipv6 disabled habe.

Evtl. bringen dich diese Informationen irgendwie weiter.

Ich bin gespannt, ob ich meinen Fehler nun gefunden habe. Ich habe gerade so viele Tests gemacht, die alle erfolgreich waren. Es würde mich sehr wundern, wenn es nicht an dieser/meiner fehlerhaften/unvollständigen Netzwerk-Konfiguration lag. ;)

Viele Grüße Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

hoppel118

#2988
Leider war die zuvor beschriebene Konfiguration meines Unifi-Netzwerk-Controllers doch nicht das Heilmittel.

Ich habe mich heute morgen nochmal intensiv mit bonjour, avahi und mdns auseinandergesetzt. Mittlerweile läuft es seit ca. 8 Stunden ohne Probleme. Bisher war die Funktion meiner Homebridge meistens bereits nach 1 bis 3 Stunden nicht mehr oder nur eingeschränkt gegeben. Wenn ich nun das WLAN an meinem iPhone deaktiviere und wieder aktiviere, ist die Homebridge quasi sofort wieder erreichbar. Auch dafür musste ich vor der jetzigen Konfiguration teilweise ganz schön lange warten. Für mich war es nicht nachvollziehbar, wann es sofort ging und wann ich warten musste.

Was habe ich nun getan?

1. Ergänzen des mdns Interface in der json.conf bei jeder Homebridge Instanz

Die Konfiguration für meine drei Homebridge Instanzen sieht nun am Beispiel meiner Homematic Instanz wie folgt aus:

{
    "mdns": {
        "interface": "10.100.100.11"
    },
    "bridge": {
        "name": "Homebridge Homematic",
        "username": "CC:22:3D:E3:CE:21",
        "port": 51821,
        "pin": "821-51-821"
    },

    "platforms": [
        {
            "platform": "FHEM",
            "name": "FHEM",
            "server": "127.0.0.1",
            "port": "8083",
            "ssl": true,
            "auth": {"user": "xxxxx", "pass": "xxxxx"},
            "filter": "room=Homebridge-Homematic"
        }
     ],

    "accessories": []
}


Die 10.100.100.11 gehört meinem Server auf dem auch die Homebridge läuft. Leider hat diese mdns interface Konfiguration mein Problem auch nicht gelöst. Nach einer Stunde oder so gab es wieder die Meldung "keine Antwort" in der Home App. Neustart des gesamten Servers wurde durchgeführt. Ich habe die Konfiguration aber so gelassen, da einige Leute bei Github dies als Lösung bestätigt hatten.

2. Weitere Analyse von Avahi

Mir ist aufgefallen, dass mir bei dem Befehl "avahi-browse -a" zwei Netzwerk Interfaces ("eno1" und "docker0") angezeigt werden, auf denen kommuniziert wird. Im Zusammenhang mit dem Raspberry Pi habe ich öfters davon gelesen, dass Leute damit Probleme hatten, wenn avahi sowohl auf dem eth als auch auf dem wlan Interface kommuniziert. Bei mir wird also nicht nur über mein Ethernet Interface "eno1" kommuniziert, sondern auch über mein Docker Interface "docker0".

Ich habe dann in der Datei "/etc/avahi/avahi-daemon.conf" im Bereich [server] folgende Änderungen vorgenommen:

[server]
host-name=omv4
domain-name=local
use-ipv6=no
allow-interfaces=eno1


Erläuterung:


  • "host-name" und "domain-name" muss nur angepasst werden, wenn das abweicht. Sicherheitshalber habe ich es eingetragen. Eigentlich hieß meine Domain vorher "localdomain". Da ich im avahi-browser aber schon öfters die Domain "local" gesehen habe, hatte ich zuvor bereits die Domain in meinem Netzwerk von "localdomain" zu "local" umgestellt. So viel Aufwand war das nicht. ;)
  • "use-ipv6" habe ich hier auch mal deaktiviert, da ich es nicht brauche und momentan auch noch nicht nutze. Ob es wirklich zur Lösung beiträgt weiß ich noch nicht. Im Internet gibt es aber einige Rückmeldungen, dass es funktioniert hat.
  • "allow-interfaces" hier habe ich mein Netzwerk-Interface "eno1" ergänzt.

Hier werden alle Parameter der "avahi-daemon.conf" beschrieben: https://www.systutorials.com/docs/linux/man/5-avahi-daemon.conf/

3. Neustart des Servers

Anschließend habe ich dann meinen Server komplett neu gestartet. avahi-browse zeigt mir nun tatsächlich an, dass ausschließlich das Netzwerk Interface "eno1" für die Kommunikation verwendet wird. Vom Docker Interface keine Spur mehr. Sehr gut!

root@omv4:~# avahi-browse -a
+   eno1 IPv4 omv4 - SSH                                    SSH-Fernzugriff      local
+   eno1 IPv4 omv4 - SSH                                    SFTP File Transfer   local
+   eno1 IPv4 omv4 - Web control panel                      Web-Angebot          local
+   eno1 IPv4 omv4 - SMB/CIFS                               Microsoft Windows Network local
+   eno1 IPv4 roborock-vacuum-s5_miio117994230              _miio._udp           local


Wenn ich nun mit "avahi-browse" auf meinem Server nach dem hap Service suche, sehe ich die HueBridge und meine 3 Homebridge Instanzen.

root@omv4:~# avahi-browse -t _hap._tcp
+   eno1 IPv4 Philips hue - A6F8C6                          _hap._tcp            local
+   eno1 IPv4 Homebridge Hue-C750                           _hap._tcp            local
+   eno1 IPv4 Homebridge Homematic-6279                     _hap._tcp            local
+   eno1 IPv4 Homebridge Xiaomi-CC07                        _hap._tcp            local


Auch das gefällt mir sehr gut! Wie gesagt, mittlerweile läuft es seit ca. 8 Stunden ohne Probleme. So lange lief es schon lange nicht mehr am Stück. ;)

By the way... Mit dem Befehl "tcpdump -n udp dst port 5353 -i eno1" (eno1 -> durch das eigene Netzwerk Interface ersetzen) kann man sehr schön auswerten, auf welchem Interface der Homebridge (mdns) Traffic läuft.

Ob das nun alles in Summe die Lösung für mein Problem ist oder sein wird, weiß ich (noch) nicht. Falls es nun noch nicht gelöst wäre, wüsste ich aber wahrscheinlich nicht mehr weiter, da ich wirklich jedem noch so kleinen Hinweis zu dieser Problematilk nachgegangen bin, recherchiert/analysiert, umkonfiguriert und dann getestet habe.


Wie dem auch sei. Ich habe viel gelernt und in meiner Gesamt-Konfiguration ordentlichen aufgeräumt. ;)

Ich halte euch auf dem Laufenden.


Viele Grüße Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

hoppel118

#2989
Hallo Leute,

kurze Rückmeldung meinerseits nochmal. Ich nähere mich dem Ziel. Meine Homebridge läuft stabil und ist seit gestern erreichbar. Allerdings ist mir aufgefallen, dass sie nur auf einem meiner beiden Access Points erreichbar ist. Das hat also definitiv nichts mehr mit der Homebridge selbst zu tun. Nachdem ich die Option "Erweiterung für Multicast (IGMPv3) aktivieren" in der Konfiguration für meine verschiedenen WLANs (Private und IoT) deaktiviert habe, war die Homebridge sofort auch über den anderen Access Point erreichbar. IGMP Snooping und MDNS sind aber weiterhin konfiguriert.

Ich werde das weiter beobachten und melde mich in einer Woche oder so nochmal.

Besteht Interesse, dass ich meine Erkenntnisse nochmal zusammenfasse und diese im Wiki hier (https://wiki.fhem.de/wiki/Homebridge_einrichten) in Kapitel 7 oder einem neuen "Kapitel 8 - Fehleranalyse" ergänze?

Wenn ja, wie bekomme ich Schreibzugriff auf das Wiki?


Viele Grüße Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

hoppel118

#2991
Top, danke dir! Account ist bestellt. ;)

Wenn ich nächste/übernächste Woche dazu komme, beschäftige ich mich mit der Ergänzung im Wiki.

Viele Grüße
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

Loki

Hallo,

in meiner homebridge.err habe ich massenhaft folgende Einträge:

[2019-1-11 08:02:52] [FHEM] BAD.dimmer-state not a number: chn:off phys:100
[2019-1-11 08:02:58] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 08:50:48] [FHEM] BAD.dimmer-state not a number: chn:99.5 phys:0
[2019-1-11 08:51:27] [FHEM] BAD.dimmer-state not a number: chn:99 phys:80
[2019-1-11 08:51:49] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 08:54:00] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 08:54:45] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 08:54:46] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 08:55:10] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 08:55:49] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 08:58:17] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:00:26] [FHEM] BAD.dimmer-state not a number: chn:off phys:100
[2019-1-11 09:00:28] [FHEM] BAD.dimmer-state not a number: chn:off phys:100
[2019-1-11 09:00:33] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 09:00:47] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:01:04] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:01:32] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:03:03] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:03:37] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:03:49] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:04:02] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:06:04] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 09:06:36] [FHEM] BAD.dimmer-state not a number: chn:99.5 phys:0
[2019-1-11 09:07:14] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 09:09:03] [FHEM] BAD.dimmer-state not a number: chn:99.5 phys:0
[2019-1-11 09:20:54] [FHEM] BAD.dimmer-state not a number: chn:off phys:80
[2019-1-11 09:21:00] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 09:59:40] [FHEM] BAD.dimmer-state not a number: on


Hier das device:
Internals:
   CFGFN      FHEM/fhem_BAD_DUSCHE.cfg
   DEF        5E717E01
   NAME       BAD.dimmer
   NOTIFYDEV  global
   NR         333
   NTFY_ORDER 50-BAD.dimmer
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     BAD.licht
   READINGS:
     2019-01-13 22:06:04   R-fuseDelay     1 s
     2019-01-13 22:06:04   R-logicCombination or
     2019-01-13 22:06:04   R-ovrTempLvl    80 C
     2019-01-13 22:06:04   R-powerUpAction off
     2019-01-13 22:06:04   R-redLvl        40 %
     2019-01-13 22:06:04   R-redTempLvl    75 C
     2019-01-13 22:06:04   R-sign          off
     2019-01-13 22:06:04   R-statusInfoMinDly 2 s
     2019-01-13 22:06:04   R-statusInfoRandom 1 s
     2019-01-13 22:06:04   R-transmitTryMax 6
     2019-01-13 22:05:40   deviceMsg       off (to HMLAN1)
     2019-01-13 22:05:40   dim             stop:off
     2019-01-13 22:05:40   level           0
     2019-01-13 22:05:40   overheat        off
     2019-01-13 22:05:40   overload        off
     2019-01-13 22:05:40   pct             0
     2019-01-13 22:05:40   phyLevel        0
     2019-01-13 22:05:40   recentStateType info
     2019-01-13 22:05:40   reduced         off
     2019-01-13 22:05:40   state           off
     2019-01-13 22:05:40   timedOn         off
   helper:
     peerIDsRaw ,00000000
     regLst     ,1,3p
     dir:
       cur        stop
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     regCollect:
     role:
       chn        1
     shadowReg:
     tmpl:
     vDim:
       idPhy      5E717E01
       idV2       5E717E
       idV3       5E717E
Attributes:
   DbLogExclude .*
   alexaName  Licht
   alexaRoom  Badezimmer
   genericDeviceType light
   group      Licht
   homebridgeMapping Brightness=state
   model      HM-LC-Dim1TPBU-FM
   peerIDs    00000000,
   room       06_Bad,10_Schalter,Alexa,Homekit
   subType    dimmer
   webCmd     on:off


Wo liegt der eigentliche Fehler? Ist etwas falsch definiert?

Loredo

Hi André,


ich vermute stark, dass sich homebirgde-fhem wieder an fhem-alexa annähern wird, nachdem sich der Staub um die ganzen Verbesserungen um alexa-fhem gelegt hat.
Vor allem was das starten aus FHEM heraus angeht ist das ja sicherlich hilfreich, ebenso das config.json Handling.


Daher hier der Hinweis, dass ich im aktuellen FHEM Docker DEV Image die Homebridge-fhem Komponenten bereits hinzugefügt habe (für den Fall, dass man eine einfache Test Umgebung für sowas braucht).




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

ja. es soll wieder vereinheitlicht werden.

wie ganz genau steht aber noch nicht fest. eventuell wird es sogar nur einen einzigen alexa-homebridge-fhem mit einem einzigen config file geben.

das weiß ich aber noch nicht.

zumindest wird aber homebridge den gleichen start und config weg bekommen.


google home auch
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

hoppel118

Das hört sich super an Jungs! Auch wenn ich Alexa (noch) nicht nutze, verfolge ich die entsprechende Entwicklung, die da gerade vorangetrieben wird.

FHEM-Docker inkl. Homebridge oder FHEM-Docker und extra Homebridge-Docker sind beides interessante Themen für mich. Momentan schraube ich aber so viel an meiner Umgebung herum, dass FHEM erstmal noch direkt unter Debian läuft. Ziel ist aber, alle meine Services zu dockerisieren. FHEM, HMLAN und Homebridge sind die einzigen Services, die noch fehlen. Wie ich mit HMLAN umgehe, muss ich mir auch noch überlegen.

Aber jetzt werde ich sehr offtopic... ;)

Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

Loredo

SUPER !


Apropos Google: Auch das nodejs Paket von Dominik habe ich mal ins Dev Image gepackt. Ich vermute der Name "fhemconnector" für das Binary wird sich da noch wieder ändern/angleichen, sofern es nicht ohnehin eine große "suite" wird.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

döner123

Guten Abend in die Runde.

Jetzt muss ich mich doch mal an das Forum wenden, nachdem ich heute den ganzen Tag schon versucht habe, meine Homekit-Integration wieder zum Laufen zu bringen.
Meine Homekit Geräte wurden nicht mehr als aktiv in der App angezeigt, ich weiß aber nicht genau, wie lange das Problem schon besteht. Ich vermute aber, dass es mit der Installation von MQTT und Xiaomi begann, da ich da auch mit node rumhantieren musste.
Nachdem ich die Homebridge in der Home-App am IPhone neu eingelesen habe und diese auch kurzzeitig funktioniert, kam der Fehler wieder, dass die einzelnen Geräte nicht mehr erreichbar waren.

Ich habe Homebridge komplett neu aufgesetzt, kann es manuell starten, ohne Fehlermeldungen und auch die Geräte, welche im Homekit-Raum sind werden aufgeführt und auch aktualisiert (per ssh)

Versuche ich nun die Homebridge im IPhone zu aktivieren, wird sie mir angezeigt und wenn ich auf verbinden gehen, kommt nach ca. 4 s die Meldung "Homebridge konnte nicht hinzugefügt werden Home konnte keine Verbindung zu diesem Gerät herstellen.

Danach ist die Bridge weg, wenn ich erneut über den QR-Code gehe, kommt die Meldung "Gerät bereits hinzugefügt"
Lösche ich dann die Ordner "persist" und "accessories", geht das ganze Spiel von vorne los.

Kennt eventuell jemand dieses Phänomen und kann mich in die richtige Richtung schieben?

homebridge API version: 2.2
this is homebridge-fhem 0.4.5

Vielen Dank

döner123

Hm, habe es soeben selber rausgefunden. Irgendein Gerät hat das Ganze wohl blockiert, eventuell ein Homematic-Thermostat, der Xiaomisauger, LaCross-Thermometer oder das Velux-Rollo. Die waren nämlich während meiner Versuche mit im Homekit-Raum, jetzt hatte ich nur noch eine Hue-Lampe und die Bridge läuft.....

Dankeschön ;)

Loki

Hallo Andre,

kannst du noch mal einen Blick hierauf werfen:

Zitat von: Loki am 13 Januar 2019, 22:23:05
Hallo,

in meiner homebridge.err habe ich massenhaft folgende Einträge:

[2019-1-11 08:02:52] [FHEM] BAD.dimmer-state not a number: chn:off phys:100
[2019-1-11 08:02:58] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 08:50:48] [FHEM] BAD.dimmer-state not a number: chn:99.5 phys:0
[2019-1-11 08:51:27] [FHEM] BAD.dimmer-state not a number: chn:99 phys:80
[2019-1-11 08:51:49] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 08:54:00] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 08:54:45] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 08:54:46] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 08:55:10] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 08:55:49] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 08:58:17] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:00:26] [FHEM] BAD.dimmer-state not a number: chn:off phys:100
[2019-1-11 09:00:28] [FHEM] BAD.dimmer-state not a number: chn:off phys:100
[2019-1-11 09:00:33] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 09:00:47] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:01:04] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:01:32] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:03:03] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:03:37] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:03:49] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:04:02] [FHEM] BAD.dimmer-state not a number: on
[2019-1-11 09:06:04] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 09:06:36] [FHEM] BAD.dimmer-state not a number: chn:99.5 phys:0
[2019-1-11 09:07:14] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 09:09:03] [FHEM] BAD.dimmer-state not a number: chn:99.5 phys:0
[2019-1-11 09:20:54] [FHEM] BAD.dimmer-state not a number: chn:off phys:80
[2019-1-11 09:21:00] [FHEM] BAD.dimmer-state not a number: off
[2019-1-11 09:59:40] [FHEM] BAD.dimmer-state not a number: on


Hier das device:
Internals:
   CFGFN      FHEM/fhem_BAD_DUSCHE.cfg
   DEF        5E717E01
   NAME       BAD.dimmer
   NOTIFYDEV  global
   NR         333
   NTFY_ORDER 50-BAD.dimmer
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     BAD.licht
   READINGS:
     2019-01-13 22:06:04   R-fuseDelay     1 s
     2019-01-13 22:06:04   R-logicCombination or
     2019-01-13 22:06:04   R-ovrTempLvl    80 C
     2019-01-13 22:06:04   R-powerUpAction off
     2019-01-13 22:06:04   R-redLvl        40 %
     2019-01-13 22:06:04   R-redTempLvl    75 C
     2019-01-13 22:06:04   R-sign          off
     2019-01-13 22:06:04   R-statusInfoMinDly 2 s
     2019-01-13 22:06:04   R-statusInfoRandom 1 s
     2019-01-13 22:06:04   R-transmitTryMax 6
     2019-01-13 22:05:40   deviceMsg       off (to HMLAN1)
     2019-01-13 22:05:40   dim             stop:off
     2019-01-13 22:05:40   level           0
     2019-01-13 22:05:40   overheat        off
     2019-01-13 22:05:40   overload        off
     2019-01-13 22:05:40   pct             0
     2019-01-13 22:05:40   phyLevel        0
     2019-01-13 22:05:40   recentStateType info
     2019-01-13 22:05:40   reduced         off
     2019-01-13 22:05:40   state           off
     2019-01-13 22:05:40   timedOn         off
   helper:
     peerIDsRaw ,00000000
     regLst     ,1,3p
     dir:
       cur        stop
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     regCollect:
     role:
       chn        1
     shadowReg:
     tmpl:
     vDim:
       idPhy      5E717E01
       idV2       5E717E
       idV3       5E717E
Attributes:
   DbLogExclude .*
   alexaName  Licht
   alexaRoom  Badezimmer
   genericDeviceType light
   group      Licht
   homebridgeMapping Brightness=state
   model      HM-LC-Dim1TPBU-FM
   peerIDs    00000000,
   room       06_Bad,10_Schalter,Alexa,Homekit
   subType    dimmer
   webCmd     on:off


Wo liegt der eigentliche Fehler? Ist etwas falsch definiert?