Beiträge von Sebbo187

    Ich würde dringend davon abraten, beide Apps parallel zu nutzen. Entscheide dich für eine der beiden Apps, um ein zuverlässiges Setup zu erhalten.
    Ich empfehle Xiaomi Home aus zwei einfachen Gründen:

    Zum Einen hast du dort offenbar schon deinen Roborock angelernt (der unabhängig vom Hub funktioniert), zum Anderen funktionieren aufgrund von DSGVO Bestimmungen die Meisten mit Anmeldung verbundenen Funktionen in der Aqara App nicht mehr.


    Da du ja nur den Hub und einen Sensor hast, schlage ich folgende Marschroute vor (auf eigene Gefahr):


    1. Hub in HomeKit entfernen.

    2. Aqara App löschen

    3. Hub in Xiaomi Home löschen


    Jetzt bedarf es einiger Erklärung der weiteren Schritte:

    Der Hub hat in der China Variante auch nur auf dem China Server vollen Zugriff auf Alarm- und Automatisierungsoptionen.

    Der Roborock kann in der EU Variante nicht am China Server angemeldet werden.

    Wechselt man den Server in der Xiaomi Home App, bleiben bereits angelernte Geräte stets auf dem alten Server erhalten bzw. mit diesem verknüpft.


    Alles ab jetzt ist ein Vorschlag, basierend auf meinem Setup:


    4. Server in Xiaomi Home auf „China“ stellen (Roborock wird nicht mehr angezeigt)

    5. Knopf am Hub 10-15x drücken (bis er gelb blinkt) und neu in Xiaomi Home anlernen.

    6. Hub über Xiaomi Home Einstellungen oder Code in HomeKit bringen.

    7. Temperatursensor am Hub anlernen (Gerät hinzufügen, Knopf am Sensor bis zum blauen Blinken drücken)

    8. Setup testen und feststellen, ob Zufriedenheit eintritt

    9. Server in den Xiaomi Home Einstellungen auf „Deutschland“ stellen (Roborock erscheint in App, Hub wird nicht mehr angezeigt, dies funktioniert vice versa)


    Da HomeKit meine „Basis“ darstellt, wird die Xiaomi Home App nur für den Roborock gebraucht. Für Updates des Hub kann ich den Server einfach kurz wechseln. Der Roborock ist zwar über ein Homebridge Plugin auch in HomeKit, Home kennt aber leider keine Grundrisse/Karten..?

    Dann kannst du als Nächstes ja mal probieren, das „child-device“ (Temperatursensor) neu anzulernen. Dafür würde ich zuerst auf die Kachel „Mi Temperatur...“ klicken und das Gerät über das Kontextmenü (drei Punkte oben rechts) und einen Klick auf „Gerät entfernen“ aus der App löschen.


    Im Anschluss kannst du ein erneutes Pairing durchführen („+“ in der oberen rechten Ecke des Home Bildschirm, während des Vorgangs dann den Knopf am Sensor gedrückt halten, wenn man dazu aufgefordert wird).

    Kefkka


    Hast du schonmal versucht, den Hub zurückzusetzen und neu zu verbinden?


    Dafür gibt es zwei Wege:


    1. Den Knopf am Hub 10 Sekunden gedrückt halten, bis er gelb blinkt. Er wird nun zurückgesetzt, behält aber dabei die Zeiteinstellungen und verbundenen Accessories.


    2. Den Knopf am Hub ca. 10x hintereinander drücken, bis die gelbe Lampe blinkt (bei mir sind es 12x).
    Dies ist ein vollständiger Reset, Zeitzone und „sub-devices“ werden gelöscht und der Hub ist wieder im Auslieferungszustand.

    Ich habe in meinem HomeKit Setup zahlreiche Sonoff Basic Module verbaut und diese in der Vergangenheit über das homebridge-ewelink-max Plugin und einer Homebridge auf einem Raspberry in HomeKit gebracht.


    Nun bin ich durch einen Link, den @Typ1er vor einiger Zeit geteilt hat, auf eine andere Möglichkeit gestoßen, diese Zwischenstecker direkt, also ohne Bridge und damit quasi "nativ" in HomeKit zu bringen.


    Konkret geht es um RavenSystem, eine alternative Firmware für Geräte, die auf dem ESP8266 basieren, um diesen eine direkte Einbindung in HomeKit zu ermöglichen. Glücklicherweise nutzen die Sonoff Basic genau diesen Chip und sind daher bestens geeignet.


    Ich zeige in der folgenden Anleitung die nötigen Schritte, um einen Sonoff Basic zu einem HomeKit fähigen Zwischenstecker zu machen.


    Im Rahmen der Anleitung wird das aktuelle Repository "Home Accessory Architect" und nicht mehr "RavenCore" verwendet. Zitat Entwickler: "RavenCore development is dead. Long live the HAA!!"


    Genutzte Hardware:


    Raspberry 3B+ mit Raspbian Buster

    Sonoff Basic

    FT232RL FTDI TTL zu USB Adapter

    4x Jumper Kabel male<->female

    Mini USB Kabel


    Wichtig: Vor Punkt 3 keine Netzspannung auf den Sonoff geben!


    Zur Vorbereitung ermitteln wir einmal, welche Bezeichnung der Adapter in unserem System hat. Dazu schließen wir den FTDI Adapter mit dem Mini USB Kabel an unseren Raspberry an. Mit

    Code
    cd /dev && ls

    lassen wir uns unsere Schnittstellen anzeigen, hier kommt nach Anstöpseln des Adapters ein neuer Anschluss hinzu. Standardmäßig heißt dieser ttyUSB0 (Sollte er bei euch anders heißen, müssen die weiteren Befehle natürlich angepasst werden, ansonsten reicht copy&paste).


    Jetzt können wir mit den Vorbereitungen starten. Zuerst laden wir aus dem Wiki die Dateien otaboot.bin, root.bin &blank.config.bin herunter und legen sie auf unserem Raspberry im Standard-Nutzer Verzeichnis /home/pi ab.


    Als Nächstes verbinden wir den FTDI Adapter mit dem Sonoff Basic. Drehen wir die Platine des Sonoff um, sehen wir auf der Unterseite vier "Löcher", die der Einfachheit halber sogar beschriftet sind (GND, 3V3, RX, TX). Hier schließen wir nun unsere vier Jumper Kabel an, die männlichen Pins können einfach in die Löcher gesteckt werden. Da der Flashvorgang im Anschluss nur wenige Sekunden dauert, kann man hier darauf verzichten, die Kabel anzulöten.

    Den Jumper auf dem FTDI Adapter setzen wir auf die 3,3V Position (die rechte Position, wenn USB Anschluss oben) und schließen die weiblichen Enden der Jumper Kabel an unserem Adapter an. Das Mini USB Kabel schließen wir zu diesem Zeitpunkt noch nicht an.

    Beim Adapter wählen wir die gleiche Belegung wie auch beim Sonoff, müssen jedoch darauf achten, dass TX & RX vertauscht werden (Sendet der Eine, muss der Andere empfangen).


    Zur Übersicht wähle ich farbige Kabel, die Belegung sieht hier folgendermaßen aus:


    FTDI Adapter                 

    VCC  - weiß                    

    TX   - orange                

    RX   - gelb                      

    GND  - schwarz    

    Sonoff   

    3V3   - weiß

    RX    - orange  

    TX    - gelb      

    GND   - schwarz


    Ist der Adapter nun korrekt mit dem Sonoff verbunden, schließen wir das Mini USB Kabel am Adapter an und halten währenddessen für einige Sekunden den Reset-Knopf des Sonoff gedrückt. Dadurch startet der Sonoff im "Flash-Mode" und kann von uns angesprochen werden.


    Zuletzt benötigen wir noch das esptool auf unserem Raspberry und installieren dieses über:

    Code
    sudo pip install esptool


    Damit sind die Vorbereitungen abgeschlossen und wir können mit dem eigentlichen Vorgang beginnen. Der Sonoff ist nun über unseren Adapter im Flash-Mode mit dem Raspberry verbunden, das esptool ist installiert und die drei geladenen Dateien liegen unter /home/pi.


    Los gehts:


    1. Flash Speicher des Sonoff löschen

    Code
    esptool.py -p /dev/ttyUSB0 erase_flash


    2. Das Mini USB Kabel trennen und den Sonoff erneut im Flash-Mode verbinden. Nun die neue Firmware auf den Sonoff flashen (Den unteren Kasten komplett per copy & paste einfügen, es sind nicht zwei voneinander getrennte Befehle)

    Code
    esptool.py -p /dev/ttyUSB0 --baud 115200 write_flash -fs 1MB -fm dout -ff 40m \
    0x0 rboot.bin 0x1000 blank_config.bin 0x2000 otaboot.bin


    3. Adapter & Jumper Kabel entfernen und Sonoff an Netzspannung anschließen. Erst jetzt wird der Sonoff mit N & L verbunden und in die Steckdose gesteckt.

    Der Controller baut daraufhin einen eigenen Hotspot auf, mit dem wir uns von unserem iPhone aus verbinden ("LCM-...").


    4. Nach kurzer Wartezeit öffnet sich automatisch eine Weboberfläche, in die wir folgende Eintragungen machen:


    OTA repository

    RavenSystem/haa


    OTA binary file

    main.bin


    Stehen diese Einträge in den beiden Feldern, wählen wir danach unser WLAN aus dem Auswahlfenster, geben das Kennwort ein und klicken auf "speichern".


    5. Der Sonoff startet nun neu und baut erneut einen Hotspot auf, diesmal mit der Bezeichnung "HAA-...". Mit diesem verbinden wir uns abermals.

    (Bis der neue Hotspot erscheint, dauert es 5-10 Minuten, wir können uns also zwischenzeitlich einen Kaffee trinken.)


    6. In der, sich erneut öffnenden Weboberfläche tragen wir in das Feld "JSON Config" folgenden String ein:

    Code
    {"c":{"o":1,"l":13,"i":1},"a":[{"0":{"r":[{"g":12}]},"1":{"r":[{"g":12,"v":1}]},"b":[{"g":0},{"g":14},{"g":14,"t":0}]}]}

    und setzen den Haken bei "OTA Update". Ein erneutes Bestätigen des WLAN und anschließendes Speichern schließt den Vorgang ab.



    7. Der Sonoff ist nun nativ HomeKit-fähig und kann über den Code 021-82-017 in HomeKit hinzugefügt werden. ;):thumbup:

    0rangeX Cooler Ansatz, die ODER Verknüpfung mit MATHS zu lösen, das gefällt mir.


    Würde denn beim Beispiel darüber (UND) nicht einfach gar nichts passieren, wenn das Fenster im Wohnzimmer geschlossen, dafür aber das im Schlafzimmer offen ist?

    Die Automation startet ja nur, wenn der Sensor im Wohnzimmer „offen“ ist, ist dieser zu, wird der weitere Ablauf und damit die zweite Frage doch gar nicht abgearbeitet?

    giRaM Das Problem hatte ich auch seit Anfang des Jahres und konnte es immer ganz gut über das Homebridge Plugin lösen.

    Da dieses nun aber nicht mehr funktioniert, die API von Nello nicht mehr existiert und es aufgrund der Insolvenz überhaupt noch ein Wunder ist, dass offenbar noch ein Server für die automatische Öffnung nach dem 18.10.2019 (angepeiltes Funktionsende) weiter betrieben wird, würde ich hier an deiner Stelle nicht erwarten, dass sich dies irgendwann ändert..?


    Irgendwann stehen wir vermutlich einfach vor verschlossener Tür und wissen damit, dass der letzte Server nun auch eingespart wurde.

    Eine Alternative könnte der Nuki Opener werden, lässt sich größenbedingt aber leider nicht mehr in einer Gegensprechanlage verstecken..?

    Der Mi Flora Flower Care (oder wie auch immer?) wird vom Hub leider nicht an HomeKit weitergereicht..

    Hierfür gibt es Plugins, deren Inbetriebnahme aufgrund des bockigen Bluetooth beim Raspberry aber bisweilen leider abenteuerlich sein kann..

    Zitat von sschuste

    Das kannst du so nicht sagen, weil du dir nicht sicher sein kannst, ob der Traffic von der Koogeek-App kommt oder irgendein anderer Mechanismus greift, möglicherweise ausgelöst durch die EVE-Zeitpläne. Aber der Hinweis ist schon mal gut und klingt plausibel.


    Schonmal Danke für die Beteiligung. Um sicherzustellen, dass dies nicht der Fall ist, war der EVE Zeitplan beim zweiten Test natürlich deaktiviert.

    Generell hatte ich nie irgendwelche Zeitpläne aktiviert (und auch kein Problem mit hohem Verbrauch) und habe dies im Rahmen von „Edit:“ erstmalig eingerichtet.


    Ebenso habe ich den Zeitplan der Koogeek im Rahmen von „Edit2“ erstmalig aktiviert und zu diesem Zeitpunkt keinerlei andere Zeitpläne aktiv.


    Bei beiden Edits konnte ich einen Anstieg des Verbrauchs unter „Deinstallierte Apps“ feststellen, den ich ohne aktivierte Zeitpläne in den letzten 280 Tagen nicht hatte.


    Daher ist dies meine aktuelle Vermutung, jedoch (leider) auch nicht mehr als das.?


    Wäre es dir vielleicht möglich, mal deinen (letzten) Thermostat Zeitplan in der zugehörigen App zu deaktivieren, um zu schauen, ob dein (wenn auch geringer) täglicher Anstieg stoppt??

    Im Normalfall sollte unter „Deinstallierte Apps“ überhaupt nichts hinzukommen, solange man keine App entfernt, dies ist bei mir der Fall...

    Nastra Da das Zusammenspiel, wie ich weiter ausführen werde, völlig unabhängig von EVE Geräten geschieht und die Überschrift damit nicht passt, hätte ich gern einen eigenen Thread dafür gehabt...


    Mein Thema lautet sinngemäß '„Deinstallierte Apps“ und die Hintergründe'


    und ich hätte es schön gefunden, in einem eigenen Thread darüber sprechen zu können..


    Auch die Hintergrundinfos kommen so vielleicht besser an, als auf Seite 5 eines anderen Themas...


    Sobald hier Seite 7,8 & xy existiert, wird niemand mehr die Infos lesen und an anderer Stelle habe ich diese Erklärungen hier bislang nicht gefunden, dafür habe ich ja nicht gefühlte 10 Seiten verfasst...?

    Das sollte eigentlich nicht tragisch sein, zur Sicherheit kannst du ja alle vier Befehle von oben noch einmal nach einander eingeben (doppelt installiert wird im Zweifel nichts, keine Sorge).. ;)


    wie schaut denn dein Eintrag in der config.json aus?

    Erhöhter Datenverbrauch im mobilen Netz


    Wie auch hier im Forum bereits an anderer Stelle diskutiert, existieren unter iOS13, vereinzelt jedoch bereits unter iOS12, diverse Probleme mit erhöhtem mobilen Datenverbrauch, der sich in den Einstellungen unter "Deinstallierte Apps" zeigt.


    Dieses Problem betrifft bei Weitem nicht alle Nutzer und die Betroffenen sind sich uneinig, wo die Ursache für dieses Problem liegt. In den Apple Foren melden sich zahlreiche Nutzer und versuchen, einen gemeinsamen Nenner zu finden.


    Hier liegen aktuell die Produkte von EVE im Fokus, wobei der offizielle Support von EVE an Apple und ein mögliches HomeKit Fehlverhalten verweist. Der Apple Support wiederum kann zum jetzigen Zeitpunkt keine klare Ursache für das Problem nennen und schlägt die Deinstallation von bestimmten Apps oder das Zurücksetzen des iPhone vor.


    Generell besteht aber zuerst einmal offenbar eine allgemeine Unklarheit darüber, was "Deinstallierte Apps" denn überhaupt sind und weiter, warum deinstallierte Apps mobile Daten verbrauchen können, wenn sie dem Namen entsprechend doch gar nicht auf dem Gerät existieren.


    Hier möchte ich zuerst ansetzen und zum Einen ein paar Hintergrundinformationen zusammentragen, zum Anderen eigene Vermutungen anstellen, die sich nicht an den EVE Produkten als primäre Ursache orientieren, sondern lediglich eine Wechselwirkung vermuten lassen.


    Was sind "Deinstallierte Apps" ?

    Der Punkt "Deinstallierte Apps" innerhalb der Einstellungen "mobiles Netz" ist keinesfalls neu. Dieser wurde bereits unter iOS 7 gesichtet, jedoch von den Wenigsten bemerkt, da es keine Auffälligkeiten gab. Die Frage "Wie kann eine deinstallierte App Daten verbrauchen?" ist anhand der eigentlichen Funktionsweise leicht zu erklären:


    Eine App, die mobile Daten verbraucht, wird unter ihrem Namen in der Statistik angezeigt. Löscht man diese nun vom Gerät, ist der Datenverbrauch ja noch immer existent, da die Statistik nicht zurückgesetzt wurde. War eine App also seit dem letzten Zurücksetzen der Statistik auf dem Gerät installiert und wurde in der Zwischenzeit wieder gelöscht, wird ihr Datenverbrauch der aktuellen Periode unter den Punkt "Deinstallierte Apps" hinzugefügt. Setzt man die Statistik zurück, verschwindet der Punkt, da alle Apps, die ab jetzt noch Daten verbrauchen zum aktuellen Zeitpunkt auch installiert sind.


    Ich demonstriere die Funktion einmal anhand meines iPhone und der App "DB Navigator".


    Eckdaten:

    iPhone XS, iOS 13.1.3

    Letztes Zurücksetzen der mobilen Datenstatistik: 09.01.2019


    Zu Beginn ist die App auf dem Gerät installiert, man sieht also in meiner Statistik den Verbrauch der App seit Januar 2019.


    Datenverbrauch "Deinstallierte Apps": 472 MB

    Datenverbrauch "DB Navigator": 134 MB


    Als Nächstes lösche ich die App vom Gerät. Der Punkt "DB Navigator" verschwindet nun korrekterweise in der Statistik und ihr Datenverbrauch wird "Deinstallierte Apps" hinzugefügt.

    Datenverbrauch "Deinstallierte Apps": 606 MB

    kurz nachgerechnet, stimmt ;)


    Jetzt wird es spannend, denn iOS ist clever und vergisst nicht und die Periode läuft ja mangels Rücksetzung der Statistik weiter.

    Also lade ich die App wieder aus dem App Store herunter.


    Daraufhin wird das Volumen, was die App einst verbraucht hatte, wieder von "Deinstallierte Apps" abgezogen und erscheint, da die App ja wieder existiert, wieder als eigener Punkt.

    Datenverbrauch "Deinstallierte Apps": 472 MB

    Datenverbrauch "DB Navigator": 134 MB


    Man sieht also bei mir als nicht Betroffener, wie die Funktion eigentlich arbeiten soll und vor Allem dass das Ganze auch im Bezug auf die Bezeichnung Sinn macht.


    Woran liegt es aber nun, dass "Deinstallierte Apps" bei einigen Nutzer ausufern?


    Da beginnt auch bei mir das große Rätselraten und ich würde mich freuen, wenn wir dies in diesem Thread gemeinsam weiterführen.


    Ich selbst habe unter Anderem auch EVE Produkte in meinem Setup (EVE Thermo 2, EVE Door & Window) und halte EVE Produkte nicht für die primäre Ursache für das Problem.

    Jedoch besteht hier möglicherweise eine Wechselwirkung unter Einbeziehung der oben genannten Punkte.


    Welche Ursachen könnte es noch geben, dass der Verbrauch bei einigen Nutzern steigt, obwohl sie in der Zwischenzeit keine Apps vom iPhone gelöscht haben?


    Offenbar existieren sogenannte "silent push" Benachrichtigungen, also Mitteilungen, die das iPhone empfängt, jedoch dem Nutzer nicht auf dem Display anzeigt. Diese werden offenbar in einem Anwendungsfall von Apps genutzt, um den Nutzer nach deren Löschung dazu zu bringen, die App erneut zu installieren. Dafür wird die App quasi "angepingt". Antwortet sie nicht, wurde sie vermutlich deinstalliert und dem Nutzer wird zukünftig gezielt Werbung für die jeweilige App angezeigt.


    Tracking durch gelöschte Apps


    Für wie wahrscheinlich halte ich dies als Ursache? Nun, ehrlich gesagt gar nicht.


    Aber könnten "silent push" Benachrichtigung nicht auch genutzt werden, um nach Updates bereits gelöschter Apps zu suchen? Schließlich werden diese ja unter "Käufe" auch angezeigt. Auch dies halte ich für unwahrscheinlich.

    Warum?

    Hat man die Funktion "Apps auslagern" aktiviert, werden diese gelöscht, wenn sie länger nicht genutzt werden, das Logo wird jedoch weiterhin angezeigt. Dieses aktualisiert sich jedoch nicht, sondern sieht stets so aus, wie zum Zeitpunkt der Löschung. Lädt man sie nun über das "cloud" Symbol erneut herunter, ändert sich das Logo (sofern es sich In der Zwischenzeit geändert hat) nach der Installation zum aktuellen Look.


    Also liegt es an HomeKit?


    Das halte ich aktuell für am Wahrscheinlichsten, denn hier finden je nach Setup die meisten Abfragen nach Außen statt.

    Und hier kann es m.E. zu der von mir anfangs erwähnten Wechselwirkung kommen.


    Hat man ein Gerät mit integrierter Automation (nur wenn ich Zuhause bin) kann es ja sein, dass das Gerät minütlich den Standort des iPhone abfragt und dieses daraufhin dumpf jede Minute antwortet. Vielleicht wird aus irgendeinem Grund ja nicht nur der Standort, sondern auch die Zeitzone des iPhone für Automationen genutzt. Hat man also einen EVE Thermo mit Zeitplan, wird aus irgendeinem Grund vielleicht andauernd abgefragt, "wie spät es auf dem iPhone ist".


    Was spricht noch für HomeKit?


    Mein Datenverbrauch von HomeKit seit dem 09.01.2019 liegt bei 99 Byte, obwohl ich über 70 Geräte, gern auch aus der Ferne, steuere. Sage ich also in HomeKit meinem Fernseher im Wohnzimmer, er solle für ein Stündchen angehen (Anwesenheitssimulation während meines Urlaubs), verbraucht dieser Befehl logischerweise Daten, er muss ja in meinem Wohnzimmer ankommen. Da der Fernseher keine App hat, sondern einzig über die Homebridge in HomeKit eingebunden ist, müsste dieser Traffic unter HomeKit auftauchen. Das tut er aber nicht...


    Bei den Nutzern, die das Problem haben, muss ja irgendetwas senden/empfangen, was keinen eigenen Punkt unter "mobile Daten" hat oder aus einem anderen Grund dem falschen Punkt ("Deinstallierte Apps") hinzugefügt wird.


    Ich freue mich auf eure Ideen, Mutmaßungen und Meinungen. :)


    Edit:


    Ich habe nun im Anschluss an diesen Artikel etwas Neues probiert, um meine obigen Theorien der Wechselwirkung zu belegen:


    Ich habe über die EVE App erstmalig den Zeitplan für meinen EVE Thermo aktiviert und im Anschluss das WLAN meines iPhone getrennt.
    Das Ergebnis nach zwei Stunden:


    6 MB zusätzlich unter dem Punkt „Deinstallierte Apps“!


    Das klingt vielleicht nicht viel, aber das sind bereits 1,3% des bisherigen Verbrauchs in diesem Punkt (472 MB).

    Rechnet man einen täglichen Verbrauch von 6 MB auf die Dauer meiner Statistik von 281 Tagen, wäre das schon ein Gesamtverbrauch von 1,69 GB.

    Rechnet man den tatsächlichen Verlauf der zwei Stunden hoch auf diesen Zeitraum (2h=6MB), käme man auf 20,23 GB. Und das nur bei einem Thermo Zeitplan.


    Besitzt ihr also ein Thermo, versucht doch einmal den Zeitplan zu deaktivieren, um zu evaluieren, ob meine Beobachtung nur reiner Zufall ist.?



    Edit2:


    Auf meinen bisherigen Erkenntnissen aufbauend, habe ich mir überlegt, was denn noch Zeitpläne zulässt und mit EVE überhaupt nichts zu tun hat.


    Also habe ich gestern über die Koogeek App einen Zeitplan für einen Smart Plug erstellt und das WLAN über Nacht deaktiviert.

    Vorhin war ich zwar wieder mit dem WLAN verbunden (gab wohl irgendwann einen automatischen Reconnect), unter „Deinstallierte Apps“ sind jedoch 10 MB dazu gekommen. Dies ist, wie weiter oben aufgeführt, ein ungewöhnlich hoher Anstieg der Statistik und damit schließe ich meine Beobachtung mit folgender Vermutung:


    Die Ursache für das Problem sind hauptsächlich HomeKit Geräte mit aktivierten Zeitplänen!


    Demnach hätte der EVE Support völlig recht, an Apple zu verweisen, weil dies kein EVE-exklusives Problem darstellt.



    Edit3:


    Von den bisherigen Erkenntnissen angefixt, war der nächste logische Schritt nun, mal den gesamten Traffic im mobilen Netz meines iPhone mitzuschneiden und zu analysieren.


    Dazu habe ich zuerst geschaut, welche Server die EVE App bei der Nutzung kontaktiert.


    Beim Öffnen der App werden einige Requests an https://services.evehome.com gesendet, öffnet man innerhalb der EVE App die Einstellungen eines Gerätes kommt der Server https://eve-updates.evehome.com dazu, um nach Aktualisierungen für das jeweilige Gerät zu schauen.


    Koogeek kontaktiert beim Öffnen der App http//pingma.qq.com und https://ulogs.umeng.com.


    Nach diesen Servern, speziell nach den zuerst genannten, werde ich also Ausschau halten. Sollte tatsächlich EVE für das Problem verantwortlich sein, müsste das Gerät im Hintergrund Anfragen an einen dieser Server senden.


    Als Vorbereitung habe ich nun beide vorher getesteten Zeitpläne (Koogeek & EVE) gleichzeitig aktiviert und das WLAN des iPhone deaktiviert.


    Alle Apps auf dem iPhone wurden geschlossen und der Datenverbrauch zu Beginn des Tests unter dem Punkt "Deinstallierte Apps" beträgt 426 MB.


    Das iPhone wurde über den Zeitraum von vier Stunden unberührt liegen gelassen und der Traffic mitgeschnitten. Ich habe in der Zeit geschlafen, mein iPhone jedoch, wie der Morgen zeigte, ganz und gar nicht:


    In den vier Stunden wurden 14,6 MB an mobilen Daten verbraucht, bei dem Punkt "Deinstallierte Apps" kamen 10 MB hinzu. Also gingen 68,5% des Gesamtverbrauchs auf diese Kategorie, obwohl das Handy nicht berührt wurde.



    Jetzt wird es spannend: Welche Server wurden in der Zwischenzeit kontaktiert? War hier einer unserer "Favoriten" dabei?


    Kommen wir zur Auswertung:


    Es gab in dem Zeitraum von vier Stunden heute Nacht insgesamt 3325 Requests an 27 Hosts, übertragen wurden dabei 14,6 MB.


    Folgend die Auflistung der kontaktierten Server:


    Hierbei fallen einige Sachen auf:


    Alle Server mit Ausnahme von https://api.weather.com sind Apple-eigene Server. Es gibt keinerlei Anfragen an die Server von EVE oder Koogeek. Damit schließe ich an diesem Punkt schon einmal aus, dass EVE Produkte oder deren Server verantwortlich für den Anstieg um 10 MB bei "Deinstallierte Apps" in diesem Zeitraum sind.


    Außerdem ist die Anzahl der Anfragen im Zusammenhang mit iCloud beachtlich, so wurden 30 Requests an https://metrics.icloud.com und 3143 Requests an https://gateway.icloud.com gesendet. Genau hier sehe ich also nun die Ursache für das ganze Phänomen.


    Einen Zusammenhang mit HomeKit Zeitplänen bzw. eine Wechselwirkung wie weiter oben beschrieben, vermute ich weiterhin. Jedoch bin ich nun sicher, dass es sich um einen Fehler seitens Apple, vermutlich im Zusammenspiel mit der iCloud bzw. CloudKit, handelt und dieser somit auch nur von Apple beseitigt werden kann. Der Eve Support ist hier meiner Einschätzung nach, wie auch von deren Mitarbeitern offenbar in Anfragen bestätigt, völlig machtlos und die EVE Produkte nicht primär verantwortlich.

    Ich kopiere hier mal meinen Beitrag aus einem anderen Thread:


    Versuch es mit der Installation doch mal so:


    1. Abhängigkeit installieren

    Code
    sudo npm install -g miio

    2. Plugin global als Nutzer "root" installieren

    Code
    sudo su -
    npm install -g homebridge-xiaomi-roborock-vacuum@latest --unsafe-perm

    3. Homebridge neustarten

    Code
    sudo systemctl restart homebridge