Beiträge von Cohni

Es wird definitiv nicht langweilig…😊

---

Mit 16.1 kam nun die Fehlermeldung etwas seltener, als bisher.

Vor allem dann bei dem Versuch, im Multiroom-Modus die Lautstärke für die Minis im Nachhinein anzuheben, da ja Minis und die normalen HomePods unterschiedliche Level haben, was beim Starten der Wiedergabe aller HomePod-Quellen dazu führt, dass die Minis im Vergleich zu leise sind.

Die Wiedergabe starte ich immer per Kurzbefehl und hatte in diesem das gewünschte Lautstärke-Niveau angepasst. Zum Schluß des Befehles kam die Anpassung für die Minis.

Wenn einer davon nicht wollte, kam die bekannte Fehlermeldung.

Mit 16.2 scheint Apple endlich die Lautstärke zwischen Mini und dem großen Tod synchronisiert zu haben.

Einer meiner großen Pods hatte sich "heimlich" auf die Beta 16.2 aktualisiert, weil ich dooferweise vergessen hatte, dass Beta-Profil zu löschen. Ergebnis dessen war, dass dieser deutlich leiser als sein Stereopartner dröhnte.

Den habe ich nun auch auf 16.2 gebracht und siehe da, es braucht keine nachträgliche Lautstärke-Anpassung für die Mini mehr. Ich starte also im Kurzbefehl oder in der Automation alle Quellen (2 Mini-Stereo-Paare und ein großes Paar) und kann dies mit einer einheitlichen Lautstärke machen.

Zumindest eine Fehlerquelle für die Fehlermeldung ist damit verschwunden. Ich hoffe, das ist nicht nur ein Bug in 16.2

Moin,

sorry für die späte Antwort.

Eine richtige Lösung habe ich bisher noch nicht. Im Prinzip heißt es nach beinahe jedem iOS-Update zu beobachten, ob der Fehler nun häufiger auftritt oder alles beim Alten bleiben kann.

Auch bin ich weg von der Homebridge-Lösung, weil das Plugin irgendwann warum auch immer nicht mehr funktionierte.

Falls der Fehlerteufel häufiger auftritt, vor allem nach einem Update, wechsle ich in den Kurzbefehlen die Audioquelle zwischen ATV (das ja ohnehin mit den Boxen verbunden ist) und dem Stereopaar. Das heißt, mal ist in meinen Kurzbefehlen das ATV Quelle und mal das HomePod-Paar.

Beides zusammen zu aktivieren, was auch mal unter älteren iOS-Versionen eine Lösung war, führt indes unter iOS 16 zu einer deutlich erhöhten Fehlerquote.

Aktuell funktioniert es bei mir recht zuverlässig mittels ausgewähltem ATV im jeweiligen Kurzbefehl. Allerdings erst wieder seit iOS 16. Bei iOS 15 war zuletzt die Audio-Auswahl via HomePod-Paar zuverlässiger

Frag mich nicht nach einem Muster. Es ist reines Try&Error.

Was sich ebenfalls als stabiler herausgestellt hat ist, wenn ich Abends vor dem Schlafengehen das ATV über einen Kurzbefehl und nicht die Fernbedienung ausschalte. Dann funktioniert die automatische Radio-Wiedergabe morgens meist problemlos.

Unter iOS 16 kam die Fehlermeldung bisher relativ selten. Und wenn, dann half es einfach, den Kurzbefehl nochmals zu wiederholen.

Das Neuanlegen der Automationen hilft zwar in der Regel, aber kann natürlich besonders ärgerlich sein, wenn man viele davon nutzt.

Ich habe schon im Thread beschrieben, wo es um nicht funktionierende ortsbasierte Automationen geht, dass das relativ einfach mit der App "Controller" funktioniert. Mit dieser kann man Automationen duplizieren, die alte löschen und die "neue" aktivieren. Die längste Zeit dauert dabei, die Ziffer 2 beim neuen Namen zu löschen.

Ich hatte zwar nur 4 Automationen zu bearbeiten, aber das Ganze hat keine 2 Minuten gedauert.

Ich hatte mit dem Update auf iOS 16 überhaupt das allererste Mal Probleme mit den standortbasierten Automationen.

Bei mir hat geholfen, diese neu anzulegen.

Das ging relativ schnell und problemlos mit der Controller-App, mit der man Automationen duplizieren kann.

Also die "kaputte" Automation kopieren, die alte löschen, gegebenenfalls den Namen der Neuen anpassen und aktivieren.

So hat das zumindest bei meinen vier Automation (Licht+Sound+diversem Hombridge-Gedöns) geholfen.

Ich hatte bis iOS 15.4 glaube ich dieses Problem in meinem System auch, mal mehr oder weniger mit den entsprechenden Versionssprüngen.

Regelmäßig half nur, die Hue-Bridge für ein paar Sekunden vom Strom zu trennen.

Irgendwann und mehr so aus Verzweiflung habe ich das etwa 6 Jahre alte Gerät ausgetauscht. Seitdem tritt das Problem nicht mehr auf.

In einer Beta-Phase bleiben manche Dinge naturgemäß offen.

Insofern würde ich bei der iPad-Geschichte keine Entwarnung geben, sondern eher dazu tendieren mit einer Prognose abzuwarten, bis man sehen kann, was spätere bzw. das Final beinhalten.

Machmal agiert Apple bewusst und rational in den veröffentlichen Äußerungen. 😊

So kann es durchaus seinen Grund haben, dass sie das iPad als Hub nicht mehr erwähnen, weil sie dessen Nutzung "auschleichen" möchten.

Wäre auf jeden Fall ein bisschen schade. Auch wenn ich selber mein iPad dafür nicht verwende, kenne ich einige, die dadurch die Nutzungsdauer eines eigentlich ausrangierten Gerätes verlängert haben.

Nun, wir werden sehen. Mit der letzten Beta bzw. dem RC kann man sich dann wohl sicher sein, was diesbezüglich passiert oder nicht.

Das kann ich bestätigen, es würde tatsächlich keinen Sinn ergeben, wenn man sich selber wenn auch aus Versehen aussperren können.

Aber ich kann auch die Beobachtung des TE bestätigen. Wenn man dem Mitbewohner Gestaltungsrechte einräumt, steht bei jenem in Klammern Admin. Siehe Bild. Ohne Rechte verschwindet der Begriff Admin.

Scheiden lassen? 🤪

Nee, im Ernst. Ich habe das Phänomen auch seit der Einrichtung meines Sohnes als Mitbewohner.

Allerdings ist das nur ein Anzeige-Problem, denn ich kann all die Sachen machen, die eben als "Admin" bei HomeKit möglich sind. Es hat keinen Einfluß.

Das ist eine gute Nachricht, falls das tatsächlich funktionieren sollte. Ich hielt das eigentlich für ein grundsätzliches Hardware-Problem. Einen Tausch habe ich schon hinter mir, natürlich ohne Erfolg.

Insbesondere bei hellen Farben und ab ca. 50% Helligkeit wird es bei meinen Geräten unangenehm für empfindliche Ohren. Ganz zu schweigen vom Gefiepe, wenn die Dinger bei 100% leuchten.

Eine Weile konnte ich es erfolgreich ignorieren, aber wenn man einmal angefixt ist…

Na mal sehen bzw. besser hören. Ich wollte die Lampen eigentlich schon zurücksenden, aber warte erstmal das Update ab. Bin allerdings etwas skeptisch, muss ich zugeben.

Ich habe die Geschichte mit der für mich nervigen Bestätigung mittels eines Dummyschalter über die Homebridge gelöst.

Also der Dummyschalter schaltet mit zwei Automationen (auf und zu) das Schloss. So wird bei der Routine "Die letzte Person verlässt" nicht das Schloss direkt, sondern der Dummy eingebunden und jegliche Nachfrage unterbleibt beim Zuschließen. Ebenso das Aufschließen (nicht Öffnen) bei diversen von mir gewünschten Gelegenheiten, welche bisher eine Bestätigung benötigten.

Ich habe einen ATV (als Zentrale) und mehrere HomePods. Bisher konnte ich die Fehler in meiner Nutzung nicht feststellen.

Auch die Geofence-Funktionen meines Sohnes als Home-Mitglied funktionieren (bisher) zuverlässig.

Zitat von HolgerKR

Lösung 1: Weniger Caipi trinken.

Bitte? Das ist nichtredend inakzeptabel! In einer völlig verrückt gewordenen Welt sollte man wenigstens eine sinnvolle Angewohnheit beibehalten....

Danke für den Link, die Diskussion ist wirklich sehr interessant und erhellend. Als bequemste Lösung für mich persönlich scheint dann doch die Anschaffung einer Nuki-Bridge, um die Geschichte letztendlich per Homebridge automatisieren zu können.

Ein weiterer für mich nerviger HomeKit-Punkt ist, dass ich bei geo-basierten Automationen diese extra bestätigen muss. Also beim Verlassen der letzten Person z.B. soll abgeschlossen werden, nicht vorher. Automatisch und nicht mit Bestätigung und gerade dann nicht, wenn ich z.B. in diesem Moment mittels Auto den Geofence nach außen überschreite. Da bin ich schon genug mit meinem Caipi-Schleier beschäftigt.... Nur ein doofer Scherz natürlich, denn auch nüchtern möchte ich nicht während der Fahrt am iPhone oder der Watch herumfummeln.

Für mein persönlich Anwendungsprofil ist die native HomeKit-Einbindung wenig hilfreich bis sogar nicht unbedenklich. Siehe Caipi-Problematik und Patschefingerchen in der Home-App.

Da komme ich unter ganz wenigen Abstrichen mit der reinen Nuki-Anwendung besser zurecht. Aber es fehlen auch ein paar Kleinigkeiten.

Eines der Homebridge-Plugins ist da für mich die Lösung. Wie schon erwähnt.

Und das erklärt wahrscheinlich tatsächlich das Problem des TE, wenn er quasi für HomeKit sprachlich korrekt die Mehrzahl der Türen anspricht. Dann ist es dem System wurscht, wie er die einzelnen Türen benennt.

Per Siri schon, aber was ist, wenn ich caipitrunken in der App herumtapse und auf den Nuki-Button per Finger drücke? Dann geht die Tür auf oder gibt es dann auch per Fingerauslösung noch einmal eine Nachfrage?

Das Problem im HomeKit ist, dass das Schloss nur verschlossen oder geöffnet werden kann. Es fehlt der Zwischenschritt "Aufschließen", ohne die Tür gleich zu öffnen.

Es gibt dafür eine Lösung via Homebridge-Plugin, jedoch braucht man dazu die Nuki-Bridge, wenn ich es richtig gelesen habe. Mein 3.0 werkelt allein.

Ich habe seit gestern das Nuki 3.0 und festgestellt, dass der vergebene Name keine Rolle spielt.

Ich kann also die Tür "Hubsti Dubsti" nennen und Siri reagiert trotzdem ganz normal auf "Hey Siri Tür aufmachen"..."öffnen".

Nein, auch mit der Personenerkennung funktioniert es nicht. Gerade probiert.

Ich finde allgemein die Einbindung des Nuki in HomeKit ein bisschen problematisch, da es den Befehl im Sinne Tür aufschließen nicht gibt und ein öffnen der Tür diese auch komplett öffnet. Es werden in HomeKit nicht alle möglichen Schlosssteuerungen und Zustände. angeboten.

Wenn ich also in Australien am Strand sitzend caipirinhabedingt aus Versehen den einen Knopf in der Home-App drücke, dann steht die Tür erstmal offen...

Aber sorry, das ist ein anderes Thema.

Danke Euch Beiden!

Ein schönes neues Projekt! 😊

Und den Hinweis mit der Forensuche nehme ich demütig entgegen…das hatte ich tatsächlich schlicht vergessen. 😆

Hallo in die Runde!

Nachdem mir meine durch einen Helligskeitssensor zentral gesteuerte Lampenwelt in meiner Wohnung zu ungenau arbeitet, möchte ich diese jetzt durch eine dem jeweiligen Raum angepasste Steuerung ersetzen. Da jeder Raum ohnehin über einen Hue-Bewegungsmelder verfügt, ist dies kein Problem.

Ja okay, ich gebe zu, ich bin auf der Suche nach einem neuen Projekt. Wenn alles funktioniert wie es soll, ist es auch langweilig...

Jeder Raum hat je nach Nutzung entsprechende Ansprüche an eine helligkeitsgesteuerte Beleuchtung.

Nun kann ich immer mal auf die Werte schauen und dementsprechend nach und nach die Einstellungen vornehmen. Jedoch ist dies sehr zeitaufwendig.

So habe ich die etwas nerdige Idee entwickelt, die im Titel beschrieben ist. Nur fehlt mir irgendwie die Idee der praktischen Umsetzung und ich hoffe, Ihr könnt mich irgendwie in einer Richtung stupsen.

Es sollen über den Tag die Daten von vier Bewegungsmeldern gesammelt, gespeichert und vergleichend auswertend erhoben werden.

Anhand dieser Vergleichswerte kann ich dann zu jeder Zeit die Werte in die Werte in die Automationen eintragen, ohne dauern darauf schauen zu müssen.

Details kann ich mir selber erarbeiten, aber irgendwie fehlen mir gerade die handwerklichen Mittel. Selbstverständlich lassen sich die Daten auslesen, speichern und auswerten. Aber wie?

Kleines Update. Die Anwesenheit meines Sohnes hat zur Lösung geführt. Kann auch Zufall mit einem zeitgleichen Fix durch Apple sein.

Mein Sohn ist als Mitglied in meinem Home eingetragen, ebenso die Stimmenerkennung auf den Pods. Auch ist er Familienmitglied in der Cloud und ich der (vermeintliche) Boss.

Er erzählte mir, dass er seit drei bis vier Tagen ähnliche Probleme mit seiner iPhone-Siri, wie meine HomePods hat.

Also Siri funktionierte grundsätzlich, aber sie hatte Schwierigkeiten mit den Apps, die eine iCloud-Verbindung haben. Erinnerungen, Kalender etc. Erinnerungen z.B. wollte Siri nicht mehr eintragen und es kamen dieselben Sprüche, wie auf den Pods seit zwei Tagen.

Folgende Schritte, die ich mehr aus Probiergründen unternahm, weniger aus Fachkenntnis, haben beide Siri-Probleme gelöst:

1. Deaktivierung der Stimmenerkennung für meinen Sohn in meinem Home.

Siri funktioniert seitdem ohne Probleme auf den HomePods. Ob dies tatsächlich kausal zusammenhängt, weiß ich nicht, zumindest gibt es eine zeitliche Korrelation. Gerade noch ein paar Sekunden vorher an HomePod-Siri verzweifelt, Stimmenerkennung des Sohnes deaktiviert und prompt funktioniert die Dame auf den Brüllwürfeln.

2. An-und Abmeldung der iCloud auf dem iPhone meines Sohnes

Nachdem Neustart, Siri deaktivieren, wieder aktvieren, Sprache umstellen usw. auf dem iPhone nichts geholfen hatten, meldete ich das Gerät von der iCloud meines Sohne ab und wieder an.

Daraufhin funktionierte die Dame auf dem Phone des Juniors wieder einwandfrei. Wie auch auf den HomePods.

Möglicherweise gab es im Zusammenhang mit Familienfreigaben, der neuen Stimmenerkennung auf den HomePods, eines Mondstaubsturmes...what ever, irgendeinen Server-Fehler bei Apple der genau bei bestimmten Konstellationen das Durcheinander ausgelöst hat.

Ich kenne nämlich zumindest zwei Menschen, die keine derartigen Probleme mit ihren Pods hatten/haben.

Ein interessantes und auf allen meinen HomePod zu reproduzierendes Problem ist nach wie vor, dass Siri offenbar ein Verbindungsprobleme in die Cloud hat.

Wenn ich nur „Hey Siri“ ohne irgendein weiteres Kommando sage, kommen die allseits bekannten Ansagen…“einen Moment“….“Sekunde“ usw.

Wenn sie fertig damit ist und ich sage wieder nur „Hey Siri“ passiert erstmal gar nichts und sie wartet auf meine weitere Ansage, die, wenn ich was weiteres sage, auch prompt und ohne Verzögerung ausgeführt wird. Die Verbindung zur Cloud ist offenbar hergestellt. Leider nur ein paar Sekunden, dann geht das Spielchen von vorn los.

Diese Geschichte ist bei meinen Pödsen beinahe zu 100% reproduzierbar.

Ich weiß, wir können hier nichts ändern und müssen auf Apple warten. Ist mehr so detektivisches Interesse, ob ich den Fehler von hier aus noch ein bisschen eingrenzen kann.