Das sind sie! Und wenn die Moderatoren sich nicht darum kümmern, dann werden die wohl irgendwann wach. Meistens sind es IPs aus China und meistens ist das ein schlechtes Zeichen.
Wäre schade, wenn sich das Forum hier jetzt einfach so zersetzt. Solche Plätze sind irgendwie wie alte Schuhe. Die wechselt man halt nicht so schnell, mit denen hat man viel erlebt …
Kannst Du die Regionen der IP-Adressen der Neuanmeldungen feststellen? Wahrscheinlich Spam, der dann schlagartig in derart großen Mengen auftaucht, dass dem kaum mehr Herr zu werden ist. Da will jemand fluten.
Einfach nach dem Update/Upgrade alle Apple TVs und HomePods neu starten, ansonsten erscheint die Option wohl erst am Sankt-Nimmerleinstag. Von mitternächtlichen Messen und allem, was zu deren vorzeitigem Ableben führen könnte, raten mir meine beiden Kater (nach durchzechter Nacht auch drei oder mehr) eher ab.
Hauptsache es funktioniert. Yep, gleichfalls frohes Fest! Jetzt kann der Weihnachtsmann ja wieder zeitgemäß klingeln …
Nein, das muss aber nichts heißen, da es bei diesem höllischen System ja oft mehrere Herangehensweisen gibt, die allesamt komplett verwirrend und vor allem brutal unzuverlässig sind (eine kleine Änderung reicht da schon).
Was ich gemacht habe, ist das da:
a) „Admin Menu“ der Moronix 
aufrufen
b) Unter „Übertragungsprofile“ das Untermenü „Profile für Netzwerkmeldungen“ aufrufen
c) Dann ganz unten auf der Seite ein neues Profil mit „Neues Profil hinzufügen“ erstellen und z. B. Homebridge nennen
d) Im Pulldown-Menü „Benutzerdefinierte Konfiguration“ auswählen
e) Als Zieladresse die Homebridge-IP samt Port für camera-ffmpeg (Beispiel oben: 6412) eintragen: ww.xx.yy.zz:6412
f) Im Pulldown-Menü darunter „Bei Fehler weiter“ wählen
g) Unter Datenprotokoll im Pulldown-Menü HTTP/1.0-Request auswählen
h) Im Textfeld darunter Deine URL gemäß Deines Wunschnamens aus camera-ffmpeg angeben: /doorbell?Wunschname
i) Unter Datentyp im Pulldown-Menü Nur Text wählen
j) Auf Setzen klicken, dann zurück ins „Admin Menu“
k) Unter der Rubrik Video-Türstation auf Klingelverhalten und Video-Mailbox klicken
l) dort kannst Du dann unter Adressat-spezifische Einstellungen für jeden Klingeltaster (= Adressat) per cmd-Klick die Option Homebridge (Netzwerkmeldung) ergänzen
m) Dann Setzen und Schließen klicken und gegebenenfalls testen (besser ist es allemal)
Es funktioniert hier. Aber wie schon erwähnt, reicht eine kleine Veränderung und neues Testen ist angesagt …
Viel Glück!
Ich verwende mittlerweile wieder das camera-ffmpeg-Plug-In und binde den Türöffner separat per http-switch ein. Der Rest sieht so aus:
{
"platform": "Camera-ffmpeg",
"porthttp": 6412,
"cameras": [
{
"name": "Wunschname",
"manufacturer": "Moronix",
"model": "T25",
"serialNumber": "xx.xx.xx.yyy",
"firmwareRevision": "MX-V4.7.3.11",
"doorbell": true,
"switches": true,
"unbridge": true,
"videoConfig": {
"source": "-f mxg -i http://login:password@IP-Adresse/control/faststream.jpg?stream=MxPEG",
"stillImageSource": "-i http://login:password@IP-Adresse/cgi-bin/image.jpg?size=1280x960&display_mode=simple",
"maxWidth": 1280,
"maxHeight": 960,
"maxStreams": 10,
"maxFPS": 30,
"videoFilter": "crop=in_w-450:in_h-490",
"audio": true
}
}
]
},Natürlich musst Du Deiner Mobotix-Türstation dazu auch den Port beibringen (in meinem Fall Port 6412). Das musst Du dann unter Profile für Netzwerkmeldungen mitsamt der IP Deines Homebridge-Gerätes im Feld Zieladresse eintragen und außerdem unter Datenprotokoll die Option HTTP/1.0-Request auswählen, dann unter CGI-Pfad den entsprechenden Pfad, /doorbell?Wunschname gemäß obigem Beispiel also und schließlich als Datentyp die Option Nur Text wählen. Ja ja, ich weiß, kompliziert, nervtötend. Aber so sind die Produkte dieses Herstellers (von dem ich garantiert niemals wieder etwas kaufen werde) ja leider.
Ach ja, die sehr spezifischen ffmpeg-Filter in obigem Beispiel geschehen dem HomeKit zuliebe und wurden durch lästiges Ausprobieren ermittelt, damit das Kamerabild nicht rund oder verzerrt ist.
Hoffe, dass Dir das irgendwie hilft.
Gibt es Einschränkungen? meine Steuerzentrale (iPad Air 1) läuft noch mit iOS 12. mein iPhone mit iOS 13, das keiner Frau mit iOS 14. zumindest auf dem 14er sollte es sich doch einstellen lassen oder?
Ohne es genau zu wissen, gehe ich mal davon aus, dass auch Deine Steuerzentrale auf einem Stand sein sollte, der Adaptive Lighting unterstützt. Ich hatte ähnliche Fälle in der Vergangenheit u. a. mit dem Läuten der HomePods, so jemand an der Tür klingelt. Erst wenn die Steuerzentrale das unterstützt, machen auch die Endgeräte mit. Es reicht also nicht, wenn nur ein Endgerät auf dem aktuellem Software-Stand ist.
Habe im Changelog gesehen, dass nun adaptive lightning unterstützt wird. Ich habe dies allerdings nicht bei mir zur Auswahl.
Es erscheint de facto nach der Aktualisierung von homebridge-hue auf v0.12.2 in der Home-App (iOS, iPadOS usw.) die Adaptive-Lighting-Option, so man diese verwenden will. Dies geht sowohl mit einer Phoscon- als auch mit der Hue-Bridge (ich lasse beide unter homebridge-hue laufen).
Wenn man die Adaptive Lighting nicht aktiviert, dann verschwindet auch der Hinweis kurz später. Es bleibt jedoch weiterhin möglich, Adaptive Lighting in den Einstellungen des jeweiligen Leuchtmittels zu aktivieren – das ist die Taste mit der stilisierten Sonne innerhalb der Farbauswahl (siehe Bildschirmfoto) und klappt natürlich nur mit Leuchtmitteln, die über die Möglichkeit zur Veränderung der Farbtemperatur verfügen.
Also wie jetzt updaten?
Sorry für die späte Antwort. Ich wollte nicht sagen, dass n generell nicht funktioniert, nur dass das Homebridge-Team es bei einer Installation nach deren Anleitung nicht empfiehlt. Bei mir kam es mit n konkret bei einer meiner mittlerweile drei Homebridge-Installationen (zweimal 3B+, einmal 4B) zu einem Pfad-Wirrwarr, weshalb ich auf den beiden anderen Installationen anstelle von n eben den Befehl sudo hb-service update-node verwendet habe, der völlig problemlos verlief. Da ich homebridge nun auch schon wieder seit gut vier Jahren einsetze (zuerst noch auf dem Mac Pro, da darauf sowieso das gute alte macOS Server lief), weiß ich nur zu gut, dass ein Pfad-Durcheinander zu starkem Kopfweh führen kann, daher ist es für manchen vielleicht besser, strikt nach Homebridge-Anleitung vorzugehen, vor allem dann, wenn man sich selbst später nicht zu helfen weiß und bei smartapfel.de gerade mal keiner wach ist.
Na schön, du weist dir ja zu helfen, und danke für den Tipp. Verstehen tue ich das alles aber nicht.
Es ehrt Dich, das zumindest zu wollen (ich nicht mehr). Mir ist übrigens zum ersten Mal aufgefallen, dass es einen Verweis zum Update-Prozedere von Node.js auch via homebridge-config-ui-x gibt, wenn man mit dem Mauszeiger über die Versionsnummer fährt. Dann öffnet sich eine Seite mit weiteren Infos, so auch der Hinweis, dass man n nicht verwenden sollte (sorry!).
n hat mit homebridge nichts zu tun.
War ein Missverständnis, siehe oben:
1) Installation von n und Update auf Node.js-Version 14.15.0
2) homebridge startete nicht mehr, Verzeichnis /home/pi/.homebridge/ wurde angelegt
3) Logs wiesen auf Inkompatibilität mit homebridge-config-ui-x hin
Auf den beiden anderen homebridge-Installationen habe ich daher kein n installiert und wie gehabt mit hb-service update-node aktualisiert. Dort traten keine Inkompatibilitäten mit homebridge-config-ui-x auf.
Auf einem Raspi ist eigentlich /usr/local/lib/node_modules der richtige Pfad.
Bin verwirrt, da es das Verzeichnis /usr/local/lib/node_modules auf keinem meiner Raspis gibt, nie gab. Erst die Installation von n und die anschließend fehlgeschlagene Update-Prozedur führten scheinbar dazu, dass dieses Verzeichnis angelegt wurde.
Davon abgesehen keine weiteren Probleme mit Node.js-Version 14.15.0 sowie homebridge-camera-ffmpeg, homebridge-fritz, homebridge-harmony, homebridge-http-switch und homebridge-hue.
Meine Hue Umgebung ist sehr einfach.
Wieso überrascht mich das nicht? Dann dürfte ja erst recht kein HomeKit-Fehler auftreten!
Das könnte sein. An meiner Hue-Bridge hängt eine reine Hue-Umgebung plus zwei Paulmann-Zigbee-Controller. Bei mir treten keine Probleme auf. Es wäre sicherlich gut, wenn diejenigen, deren Konfiguration ständig gestört wird, mal die angeschlossenen Geräte benennen. Vielleicht kann man so den Fehler eingrenzen.
Beim Thread-Ersteller mag es andere Ursachen gegeben haben, hier ging der Stress mit den LivingWhites los. Philips lagerte seine Lichtabteilung aus und Signify ist generell unlustig, was Altlasten anbetrifft. Die LivingWhites wurden kurzerhand in einen nicht existierenden HomeKit-Raum umsortiert – mit jedem Update erneut. Ich hatte daher testweise auch einen Paulmann-Dimmer erworben, nur ist dessen elektrische Installation weit entfernt vom Komfort der alten Philips-Dimmer.
sschuste: n scheint homebridge im Verzeichnis /home/pi/.homebridge/zu erwarten, wohingegen die Installation nach der Anleitung auf der offiziellen Homebridge-Seite von GitHub in /var/lib/homebridge stattfindet. Wie löst man diesen Konflikt?
Ergänzung nach weiterer Analyse:
Aktualisiere ich auf node 14.15.0 mittels sudo hb-service update-node, läuft alles einwandfrei und meine drei homebridge-Installationen arbeiten nach Neustart freundlich weiter. Verwende ich allerdings n, beschwert sich homebridge:
Error: The module '/usr/lib/node_modules/homebridge-config-ui-x/node_modules/node-pty-prebuilt-multiarch/build/Release/pty.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 72. This version of Node.js requires
NODE_MODULE_VERSION 83. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).Daraufhin startet homebridge nicht mehr, sucht nach Konfigurationdateien und legt das Verzeichnis /home/pi/.homebridge/ an, was zu weiterer Verwirrung führt. Erst wenn ich homebridge-config-ui-x deinstalliere und wieder installiere, klappt wieder alles:
# cleanup
sudo npm uninstall -g homebridge-config-ui-x
# reinstall
sudo npm install -g --unsafe-perm homebridge-config-ui-xAuch merkwürdig: nach der Installation von n hatte sich der npm-Pfad geändert:
npm -g root
/usr/local/lib/node_modulesDas kann man so ändern:
sudo npm -g config set prefix /usrIrgendwie habe ich mit n Pech. Dies daher als kleiner Hinweis an diejenigen, denen es vielleicht ähnlich geht …
Dem schließe ich mich an, aber ich drücke auch nie wieder auf "Hue - Siri" synchronisieren.
Hielt ich auch so, ungewollte Veränderungen fanden trotzdem statt. Konfigurationen sind aber auch selten so ähnlich, dass alle Ergebnisse und Fehlverhalten von allen reproduzierbar wären. In meinem Fall hatte ich die von Signify ungeliebten LivingWhites in Verdacht, deren Hersteller-ID Signify zwar umbenannt, sie dann aber nur sehr halbherzig wieder integriert hat.
Sehr nervtötend, weshalb ich die Anwendung schon seit längerem nicht mehr einsetze und alles per homebridge-hue ansteuere. Bin gerade außerdem im Begriff, den ganzen Signify-Mist auszulagern und auf den Rasbee II umzusteigen. Die Hue-Basis habe ich damit zum ausschließlichen Steuern meiner alten LivingWhites-Dimmer verdammt, da dies der einzige Weg ist, sie in den HomeKit zu integrieren. Philips/Signify bastelt nun seit über einem Jahr auf Kosten seiner Kunden vor sich hin, nein danke.
Spy: Schön für Dich!
Eine Frage noch mal an alle Betroffenen. Nutzt ihr eine FRITZ!Box?
Sehr berechtigte Frage!
Hier kam es zu diversen HomeKit-Statusproblemen nach dem Update der 7590 auf FRITZ!OS 7.20/7.21. Diese verschwanden erst nach dem Trennen der FRITZ!Box vom Netz und anschließendem Neustart (so mehrfach empfohlen unter ip-phone-forum.de). Gleiches habe ich dann sicherheitshalber auch mit den beiden 1750-Repeatern getan. Seither alles wieder im grünen Bereich!
HTH,
D.
[...] aber das Plugin übermittelt die credentials nicht mit irgendwie....
Yep, Credentials in URLs mag Apple (WebKit? HomeKit?) generell nicht. Das konnte ich aber umgehen, da ich einen lokalen Webserver betreibe, auf dem der „Link Shortener“ YOURLS läuft. Ich habe die entsprechende URL mit Login und Passwort somit in eine sehr komplizierte Zahlen-/Buchstabenfolge gewandelt. Sobald ich diese dann aufrufe, klappt es perfekt.
als buttenSid habe ich die aus dem Plugin stehen lassen, glaube "158d00029088e3"
Alles klar, habe ich dann ebenso gehandhabt.
Zitatbei axis kann man unter Ereignisse auch "Empfänger" anlegen, hier habe ich die IP der Homebridge-Instanz mit zugehörigem Port eingetragen (http://192.168.1.X:4343) als "Klingel Homekit" und als Event "wenn Anruf / Call > ringing" dann "Klingel Homekit"
Hier muss ich in meinem Fall leider noch experimentieren, da Mobotix bekanntermaßen mit großer Hingabe das schlimmste Interface aller Zeiten pflegt …
Zitatedit: der türöffner geht nur, wenn ich die sicherheitseinstellungen der kamera runter nehme...
dann gibt es aber einen fehler in der app des herstellers...da bin ich noch am tüfteln.
Auch nicht schön. Bei der Mobotix läuft das relativ leicht über eine URL, die Login und Passwort enthält (natürlich nicht, wenn man das irgendwo außerhalb des eigenen Netzwerkes anwendet).
Danke jedenfalls für die Rückmeldung – so hat man jedes Wochenende (oder bei jedem neuen Virus 
) was zum Experimentieren …
Code"event": { "buttonSid": "XXXXXXXXXXXXX", "motion": false, "switch": { "name": "Klingelsensor"
Kannst Du mir eventuell mal detaillierter erklären, was es genau damit auf sich hat und was unter „buttonSid“ konkret einzutragen wäre?
Und welches Event von Deiner Axis sendest Du genau an Deinen Homebridge-Server? Soweit ich verstehe muss es Port 6412 sein, korrekt?
Als Event meiner Türstation (Mobotix T25) stehen mir beispielsweise folgende Optionen zur Verfügung:
- Nur TCP/IP
- HTTP/1.0-Request
- HTTP/1.0-Request mit Bestätigung
Ich habe mich für die erste Option entschieden und zusätzlich als Datentyp „Live- oder Alarmbild“ ausgewählt. Den HTTP-Trigger für den Türöffner meiner Türstation konnte ich übrigens finden. Jeder Hersteller kocht da natürlich sein eigenes Süppchen … Wie aber sieht das bei Dir aus? Immerhin läuft es ja scheinbar.
Danke!
