[Frage] Xiaomi Vacuum cleaner
-
Ich habe hier ein ähnliches Phänomen.
Heute den Robbie in Betrieb genommen , IOS-App installiert und eingerichtet.
Backup gezogen, Key rausoperiert und in den Adapter eingetragen.
Adapter wird grün, aber die Datenpunkte unter "Info" füllen sich nicht. Auf das Absetzen eines der Commands führt zu keinem Ergebnis.
Adapterversion ist die 0.5.9 vom Git.
Log (Debug) sieht ähnlich aus, wie bei mehrwiedu:
! ````
mihome-vacuum.0 2017-11-07 22:14:09.852 debug sendMsgRaw >>> 2131005000000000046bcd155a0222202e682aa553371d2fb77fb2360507e2dfb480ea6adf1e1eee99620281654a820db4e84ec7590d40dada2f59f4b854adedf8c07a1afb6922417b377dd2b5729a73
mihome-vacuum.0 2017-11-07 22:14:09.852 debug sendMsg >>> {'id':1002,'method':'get_clean_summary'}
mihome-vacuum.0 2017-11-07 22:14:09.852 debug Timestamp: 5a022220
mihome-vacuum.0 2017-11-07 22:14:09.852 debug lastid{'get_status':1000,'get_consumable':1001,'get_clean_summary':1002,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-07 22:14:08.848 debug sendMsgRaw >>> 2131005000000000046bcd155a02221ff7e2dc7352be4fa98f3f88f3207290261eae1587b7b751694c92d7220b5c51b7b4162b22409df6af71f7a9512fdbdc8569f154d495fb53c110645fdb9a27c92e
mihome-vacuum.0 2017-11-07 22:14:08.848 debug sendMsg >>> {'id':1001,'method':'get_consumable'}
mihome-vacuum.0 2017-11-07 22:14:08.848 debug Timestamp: 5a02221f
mihome-vacuum.0 2017-11-07 22:14:08.847 debug lastid{'get_status':1000,'get_consumable':1001,'get_clean_summary':0,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-07 22:14:08.169 debug Receive <<< Helo <<< 2131002000000000046bcd155a02221fffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-07 22:14:07.852 debug sendMsgRaw >>> 2131005000000000046bcd155a02221ef9fcbda08f5ee1f2e217e266becdb5f6c6cc011af8e5227a315422e9c06fc4920e54b688077c9fb3b3ddacf28b0e694ec627b1a5578d40c0132ce76059187eb0
mihome-vacuum.0 2017-11-07 22:14:07.852 debug sendMsg >>> {'id':1000,'method':'get_status'}
mihome-vacuum.0 2017-11-07 22:14:07.851 debug Timestamp: 5a02221e
mihome-vacuum.0 2017-11-07 22:14:07.851 debug lastid{'get_status':1000,'get_consumable':0,'get_clean_summary':0,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-07 22:14:07.850 debug requesting params every: 60 Sec
mihome-vacuum.0 2017-11-07 22:13:47.916 debug Receive <<< Helo <<< 2131002000000000046bcd155a02220bffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-07 22:13:27.946 debug Receive <<< Helo <<< 2131002000000000046bcd155a0221f7ffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-07 22:13:07.897 debug Connected
mihome-vacuum.0 2017-11-07 22:13:07.896 warn Time difference between Mihome Vacuum and ioBroker: -1 sec
mihome-vacuum.0 2017-11-07 22:13:07.895 debug Receive <<< Helo <<< 2131002000000000046bcd155a0221e3ffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-07 22:13:07.840 debug server started on 0.0.0.0:53421
mihome-vacuum.0 2017-11-07 22:13:07.827 debug Ios Token decrypted to: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mihome-vacuum.0 2017-11-07 22:13:07.824 debug Ios Token detected: 48
mihome-vacuum.0 2017-11-07 22:13:07.818 info Create state clean_home for controlling by cloud adapter
mihome-vacuum.0 2017-11-07 22:13:07.817 info Expert mode enabled, states created
mihome-vacuum.0 2017-11-07 22:13:07.808 info starting. Version 0.5.9 in /opt/iobroker/node_modules/iobroker.mihome-vacuum, node: v6.11.4
mihome-vacuum.0 2017-11-07 22:13:07.762 debug statesDB connected
mihome-vacuum.0 2017-11-07 22:13:07.720 debug objectDB connectedGruß, Eric -
Meistertr, was mich auch irritiert ist dies Information, dass zwei verschiedenes Geräte mit unterschiedlichen Token in den Apps auf den Sauger zugreifen. Hast Du dafür eine Erklärung?
-
Moin,
habe heute früh extra nochmal ein IOS-Backup gezogen und der Token neu ausgelesen.
Und den Adapter (0.5.9) mal auf Debugging "Silly" gestellt.
Hier das Log:
! ````
mihome-vacuum.0 2017-11-08 06:08:42.658 debug Receive <<< Helo <<< 2131002000000000046bcd155a02915affffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:08:23.240 debug Receive <<< Helo <<< 2131002000000000046bcd155a029147ffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:08:04.638 debug sendMsgRaw >>> 2131005000000000046bcd155a029133dad90a7cc0522e3f03190c81769c0e1de09b97299b35f3dbc98125a35be7ceca0338feae516038abb5b71bfd3899201828749c786557adde8117981b6f044091
mihome-vacuum.0 2017-11-08 06:08:04.638 debug sendMsg >>> {'id':1008,'method':'get_clean_summary'}
mihome-vacuum.0 2017-11-08 06:08:04.638 debug Timestamp: 5a029133
mihome-vacuum.0 2017-11-08 06:08:04.638 debug lastid{'get_status':1006,'get_consumable':1007,'get_clean_summary':1008,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-08 06:08:03.638 debug sendMsgRaw >>> 2131005000000000046bcd155a0291328cc9d05440ce53623f86aa83e06fa191aae6ddcae96438af5530392cf711fef6102f3a4d02a4713176d3a3559124ba4bbf6ad5deaf7a8a940302786785224b2b
mihome-vacuum.0 2017-11-08 06:08:03.638 debug sendMsg >>> {'id':1007,'method':'get_consumable'}
mihome-vacuum.0 2017-11-08 06:08:03.638 debug Timestamp: 5a029132
mihome-vacuum.0 2017-11-08 06:08:03.637 debug lastid{'get_status':1006,'get_consumable':1007,'get_clean_summary':1005,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-08 06:08:02.717 debug Receive <<< Helo <<< 2131002000000000046bcd155a029132ffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:08:02.637 debug sendMsgRaw >>> 2131005000000000046bcd155a029131fa95f165cd2c1fd2040ce35ece6c81340bf1dcca780dfc7c9a478ea4896c6d77236887dc9a8e221b5485ca15df923868685c7fd27a1d5abd3850185f42b9ad9b
mihome-vacuum.0 2017-11-08 06:08:02.637 debug sendMsg >>> {'id':1006,'method':'get_status'}
mihome-vacuum.0 2017-11-08 06:08:02.637 debug Timestamp: 5a029131
mihome-vacuum.0 2017-11-08 06:08:02.637 debug lastid{'get_status':1006,'get_consumable':1004,'get_clean_summary':1005,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-08 06:08:02.636 debug requesting params every: 60 Sec
mihome-vacuum.0 2017-11-08 06:07:42.773 silly inMem message mihome-vacuum.0.* mihome-vacuum.0.info.connection
mihome-vacuum.0 2017-11-08 06:07:42.768 debug Connected
mihome-vacuum.0 2017-11-08 06:07:42.768 debug Receive <<< Helo <<< 2131002000000000046bcd155a02911effffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:07:25.651 silly inMem message mihome-vacuum.0.* mihome-vacuum.0.info.connection
mihome-vacuum.0 2017-11-08 06:07:25.638 debug Disconnect
mihome-vacuum.0 2017-11-08 06:07:04.639 debug sendMsgRaw >>> 2131005000000000046bcd155a0290f7fd1984cb1313f48faa34495e728aea509696c10cdd72a7ce27e6e98bd2c4c1ba87363b8c4b9084fe9fbf5409867ec761cd24f60be3cfd2f919ac4f906afcf0fa
mihome-vacuum.0 2017-11-08 06:07:04.634 debug sendMsg >>> {'id':1005,'method':'get_clean_summary'}
mihome-vacuum.0 2017-11-08 06:07:04.634 debug Timestamp: 5a0290f7
mihome-vacuum.0 2017-11-08 06:07:04.633 debug lastid{'get_status':1003,'get_consumable':1004,'get_clean_summary':1005,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-08 06:07:03.633 debug sendMsgRaw >>> 2131005000000000046bcd155a0290f6c742a1b9d0140d8481840be05e038a511c2a34b3acf149f9d5a2cd493a7b56786c44ecdcdb102fa9a78ae0e69862fe89bfb9e832b01a9b0be337fcb6946fdf7a
mihome-vacuum.0 2017-11-08 06:07:03.633 debug sendMsg >>> {'id':1004,'method':'get_consumable'}
mihome-vacuum.0 2017-11-08 06:07:03.633 debug Timestamp: 5a0290f6
mihome-vacuum.0 2017-11-08 06:07:03.633 debug lastid{'get_status':1003,'get_consumable':1004,'get_clean_summary':1002,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-08 06:07:02.641 debug Receive <<< Helo <<< 2131002000000000046bcd155a0290f6ffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:07:02.630 debug sendMsgRaw >>> 2131005000000000046bcd155a0290f568739b393d14e0870037b27bf4b41a1ead10cce7514767ddd2431581c7e7595983f5b927fc9e10dc3901fee66a8f0a70a7cacc22edf999293effb9db933e58e8
mihome-vacuum.0 2017-11-08 06:07:02.630 debug sendMsg >>> {'id':1003,'method':'get_status'}
mihome-vacuum.0 2017-11-08 06:07:02.630 debug Timestamp: 5a0290f5
mihome-vacuum.0 2017-11-08 06:07:02.630 debug lastid{'get_status':1003,'get_consumable':1001,'get_clean_summary':1002,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-08 06:07:02.630 debug requesting params every: 60 Sec
mihome-vacuum.0 2017-11-08 06:06:42.632 debug Receive <<< Helo <<< 2131002000000000046bcd155a0290e2ffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:06:22.742 debug Receive <<< Helo <<< 2131002000000000046bcd155a0290ceffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:06:04.616 debug sendMsgRaw >>> 2131005000000000046bcd155a0290bbfcb9f1f001f56e6dac7bb7d4d11058f8b480ea6adf1e1eee99620281654a820db4e84ec7590d40dada2f59f4b854adedf8c07a1afb6922417b377dd2b5729a73
mihome-vacuum.0 2017-11-08 06:06:04.616 debug sendMsg >>> {'id':1002,'method':'get_clean_summary'}
mihome-vacuum.0 2017-11-08 06:06:04.616 debug Timestamp: 5a0290bb
mihome-vacuum.0 2017-11-08 06:06:04.616 debug lastid{'get_status':1000,'get_consumable':1001,'get_clean_summary':1002,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-08 06:06:03.617 debug sendMsgRaw >>> 2131005000000000046bcd155a0290ba5f4ccc9755f8b00636c232a5566bd17d1eae1587b7b751694c92d7220b5c51b7b4162b22409df6af71f7a9512fdbdc8569f154d495fb53c110645fdb9a27c92e
mihome-vacuum.0 2017-11-08 06:06:03.617 debug sendMsg >>> {'id':1001,'method':'get_consumable'}
mihome-vacuum.0 2017-11-08 06:06:03.617 debug Timestamp: 5a0290ba
mihome-vacuum.0 2017-11-08 06:06:03.617 debug lastid{'get_status':1000,'get_consumable':1001,'get_clean_summary':0,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-08 06:06:02.627 debug Receive <<< Helo <<< 2131002000000000046bcd155a0290baffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:06:02.615 debug sendMsgRaw >>> 2131005000000000046bcd155a0290b9e528976d87e6eeba941c7087653fe80bc6cc011af8e5227a315422e9c06fc4920e54b688077c9fb3b3ddacf28b0e694ec627b1a5578d40c0132ce76059187eb0
mihome-vacuum.0 2017-11-08 06:06:02.615 debug sendMsg >>> {'id':1000,'method':'get_status'}
mihome-vacuum.0 2017-11-08 06:06:02.615 debug Timestamp: 5a0290b9
mihome-vacuum.0 2017-11-08 06:06:02.615 debug lastid{'get_status':1000,'get_consumable':0,'get_clean_summary':0,'get_clean_record':0,'X_send_command':0}
mihome-vacuum.0 2017-11-08 06:06:02.614 debug requesting params every: 60 Sec
mihome-vacuum.0 2017-11-08 06:05:42.622 debug Receive <<< Helo <<< 2131002000000000046bcd155a0290a6ffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:05:22.619 debug Receive <<< Helo <<< 2131002000000000046bcd155a029092ffffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:05:02.780 silly inMem message mihome-vacuum.0.* mihome-vacuum.0.info.connection val=true, ack=true, ts=1510117502778, q=0, from=system.adapter.mihome-vacuum.0, lc=1510117502778
mihome-vacuum.0 2017-11-08 06:05:02.624 debug Connected
mihome-vacuum.0 2017-11-08 06:05:02.624 warn Time difference between Mihome Vacuum and ioBroker: -1 sec
mihome-vacuum.0 2017-11-08 06:05:02.622 debug Receive <<< Helo <<< 2131002000000000046bcd155a02907effffffffffffffffffffffffffffffff
mihome-vacuum.0 2017-11-08 06:05:02.612 debug server started on 0.0.0.0:53421
mihome-vacuum.0 2017-11-08 06:05:02.602 debug Ios Token decrypted to: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mihome-vacuum.0 2017-11-08 06:05:02.601 debug Ios Token detected: 48
mihome-vacuum.0 2017-11-08 06:05:02.599 info Create state clean_home for controlling by cloud adapter
mihome-vacuum.0 2017-11-08 06:05:02.598 info Expert mode enabled, states created
mihome-vacuum.0 2017-11-08 06:05:02.576 info starting. Version 0.5.9 in /opt/iobroker/node_modules/iobroker.mihome-vacuum, node: v6.11.4Die Datenpunkte bleiben alle leer, nur der Datenpunkt "Connection" unter "info" ist auf true (und wird mit grün immer wieder bestätigt). Vielleicht kannst Du damit was anfangen. Gruß, Eric -
Meistertr, was mich auch irritiert ist dies Information, dass zwei verschiedenes Geräte mit unterschiedlichen Token in den Apps auf den Sauger zugreifen. Hast Du dafür eine Erklärung? `
Wenn einer dies Problem hat, kann es Zufall sein, bei zweien sieht das schon anders aus!! Ja ich habe eine Erklärung, die gefällt mir jedoch überhaupt nicht. Der Token wird nur für die Interne Kommunikation benötigt also im Heimnetz. Ich habe gestern mal wieder den Traffic der app geloggt und konnte keine internen Nachrichten mehr finden. Früher hat die App nur über die cloud kommuniziert, wenn sie den Sauger nicht im Wlan finden konnte, das scheinen die jetzt geändert zu haben. Für die Cloud Kommunikation ist kein token nötig, da hier alles über eine SSL Verschlüsselung läuft.
@eric welche SW version hat der Roboter? mit ein bisschen knowhow vieleicht mal das: https://github.com/rytilahti/python-miio probieren obs hiermit läuft, dann kann man iobroker/adaptrer ausschließen.
Wenn app und adaper gleichzeitig laufen, kann es sein dass der Roboter mehrere Minuten keine daten sendet, also App mal ganz schließen und den Adapter 10 Minuten laufen lassen
Edit: ist aber bis lang nur eine Theorie
-
Firmware auf dem Robot ist die 3.3.9_003077
App-Version ist 4.1.1 (wurde gestern noch im App-Store aktualisiert).
Der Robot läuft, alle Apps sind beendet (nicht nur geschlossen).
Adapter steht auf Debug und wurde neu gestartet.
Mal abwarten und sehen.
Gruß,
Eric
-
Also meiner hat die gleiche Firmwareversion: 3.3.9_003077
Die App hat die Version 4.1.0
Und der Adapter die Version 0.5.8
Den Token habe ich auch aus dem iOS Backup!
Und bei mir funktioniert alles wunderbar, seit ich es vor paar Monaten eingerichtet habe
Wenn ich mit irgendwas helfen kann, sagt Bescheid!
Gruß
Adrian
Gesendet von iPhone mit Tapatalk Pro
-
Nachtrag:
Bisher sehe ich im Log verschiedene send-commands, aber immer mal wieder nur diesen einen Receive …
mihome-vacuum.0 2017-11-08 06:57:34.257 debug Receive <<< Helo <<< 2131002000000000046bcd155a029cceffffffffffffffffffffffffffffffffEs scheint also eine Antwort zu kommen, oder?
Gruß,
Eric
Von unterwegs getippert
-
Meistertr,
das würde bedeuten, dass man nun gar keinen Token mit der aktuellen App mehr auslesen kann…? Also auch nicht über das Backup? Weil er nicht mehr benötigt wird. Das könnte ich nachher mal testen und sehen, ob der Token noch zu finden ist und ob er identisch mit meinem alten Token ist...
Das heißt aber im Umkehrschluß, daß man ihn mit alten App Versionen noch auslesen können müsste?
Edit: was mir bei weiteren Nachdenken eingefallen ist - unplausibel ist, dass ich beim gleichen Firmwarestand des Saugers mit meinem alten Token zugreifen kann... oder habe ich einen Denkfehler?
-
unplausibel ist, dass ich beim gleichen Firmwarestand des Saugers mit meinem alten Token zugreifen kann… oder habe ich einen Denkfehler? `
Diese alte Token, neue Token Geschichte habe ich ja mit reingebracht.Oft ist es, wenn einer sich gar nicht auskennt und da rumfuhrwerkt, dass man auf Kombinationen trifft, die man so gar nicht bedacht hat.
Warum sollte auch einer von Euch einen einmal ausgelesenen Token ändern? Es funktioniert ja. Und ob dieser Token dann bei der App je wieder benötigt wird, fällt bei Euch ja auch gar nicht auf. Egal wie viele Devices Ihr nutzt um den Sauger zu steuern.
Ich bin da ja eh nur zufällig drauf gestoßen, dass sich bei einer Neueinbindung des Saugers in die App, der Token am iPhone geändert hat und ich diese Änderung am iPad eigentlich nur kontrollieren wollte. Und weil es so schön war, hab ich das einfach am iPhone nochmal gemacht und hatte dann wiederum einen neuen Token, der es aber auch nicht bis in die iPad App geschafft hat.
Dass nun beide Apps funktionieren, kann ja dann tatsächlich nur bedeuten, dass die Token für die Kommunikation zwischen Sauger und App nicht mehr benötigt werden, sondern den Sauger wahrscheinlich nur noch in der Cloud definieren. Und dabei ist es dann egal, ob die App einen alten hat, oder nicht. Irgendwie so wird es sein.
Was mich eben nur wundert, wenn das eine Änderung ist, und die App gar nicht mehr im Heimnetz kommuniziert, sondern immer über die Cloud geht, warum laufen Eure Sauger noch über ioBroker? Müssten die nicht dann direkt nach "Protokoll-Änderung" im Heimnetz still gelegt worden sein?
Wer weiß, die Version 4.1.0 ist erst vor 6 Tagen bei mir angekommen. Die Version 4.1.1 erst gestern.
Möglich, dass die aus der Cloud heraus erst schubweise ausrollen, so dass diese Änderung jetzt nach und nach bei allen anderen ankommt? Nächste Woche funktioniert dann gar kein Sauger mehr, oder was?
-
Wie gesagt nur eine Theorie. Das mit dem fw stand ist der Knackpunkt wo ich auch hänge. Da alles identisch ist kann ich mir das auch nicht anders erklären. Der Stau der Sauger in England kommt nun erst hier an also noch mal etwas abwarten ob sich das häuft. Ich sitze auch immer mal wider an der cloud verbindung aber bis lang ohne Erfolg. Damit wären die Probleme alle gelöst..
@markus- bei fhem schon welche der aktuellsten Sauger angebunden?
@etic das ist die unverschlüsselte Anwesenheitsmitteilung des Roboters, sobald verschlüsselte Nachrichten gesendet werden kommt keine Antwort.
Leider weiß ich im Moment nicht weiter woran es liegen kann. Habe in den nächsten Wochen auch wenig Zeit mich dem intensiv zu widmen werde es aber versuchen heraus zu finden.
Gesendet von meinem Handy
-
Bei mir auch App Stand 4.1.1. und FW Stand wie oben. Bisher keine Probleme.
-
Ich schließe mich hier an,
mit der gleichen Problermstellung.
Wenn ich etwas beisteuern kann zur Problemlösung, last es mich wissen.
Viele Grüße
Thomas
-
Ich bin da ja eh nur zufällig drauf gestoßen, dass sich bei einer Neueinbindung des Saugers in die App, der Token am iPhone geändert hat `
Ich meine, das war schon immer so. Oder? Bei jeder Neueinbindung ändert sich der Token.
Mehrwiedu, wenn beide Apps auf iPhone und iPad funktionieren, könntest Du SICHERHEITSHALBER noch einmal von beiden Geräten über das Backup die Token auslesen? Eigentlich müssten die dann gleich sein.
-
Mehrwiedu, wenn beide Apps auf iPhone und iPad funktionieren, könntest Du SICHERHEITSHALBER noch einmal von beiden Geräten über das Backup die Token auslesen? Eigentlich müssten die dann gleich sein. `
Ich meinte damit, dass ICH nur zufällig darauf gestoßen bin.
Das Backup von iPad und iPhone habe ich jetzt gefühlt schon 20 mal gemacht und ebenso oft den Sauger am iPhone aus der App gelöscht und wieder neu hinzugefügt.
Der Token ändert sich nur am iPhone. Am iPad bleibt er über alle Versuche, Neueinbindungen und ähnliches immer identisch. Und zwar ist es genau der Token, den ich ganz am Anfang als allererstes aus meinem iPhone 6s Backup ausgelesen habe, um den Adapter überhaupt erst einzurichten. Da waren also die Token auf iPad und iPhone noch identisch. Jetzt sind sie es nicht mehr.
Ich weiß das, weil ich gestern Abend Deinem Rat gefolgt bin und ioBroker einmal komplett neu aufgesetzt habe. Allerdings habe ich dafür einfach eine zweite SD-Karte benutzt. Das erschien mir schneller und einfacher, als ein Backup hin und her zu kopieren. Dabei habe ich dann an einem anderen Rechner und einer anderen iTunes-Instanz die beiden Backups zuletzt ausgelesen.
Allerdings ergab das auch keine Lösung.
Ebenso wie die Portänderung, die Meistertr vorgeschlagen hat. Da blieb der Adapter sogar gelb und hat den Sauger gar nicht gefunden.
Ich habe auch den PI direkt an die Fritzbox an einen LAN gehangen und testweise nur über WLAN mit der Fritzbox verbunden.
An alledem liegt es also nicht.
-
Mehrwiedu, wenn beide Apps auf iPhone und iPad funktionieren, könntest Du SICHERHEITSHALBER noch einmal von beiden Geräten über das Backup die Token auslesen? Eigentlich müssten die dann gleich sein. `
Ich meinte damit, dass ICH nur zufällig darauf gestoßen bin.
Das Backup von iPad und iPhone habe ich jetzt gefühlt schon 20 mal gemacht und ebenso oft den Sauger am iPhone aus der App gelöscht und wieder neu hinzugefügt.
Der Token ändert sich nur am iPhone. Am iPad bleibt er über alle Versuche, Neueinbindungen und ähnliches immer identisch. Und zwar ist es genau der Token, den ich ganz am Anfang als allererstes aus meinem iPhone 6s Backup ausgelesen habe, um den Adapter überhaupt erst einzurichten. Da waren also die Token auf iPad und iPhone noch identisch. Jetzt sind sie es nicht mehr.
Ich weiß das, weil ich gestern Abend Deinem Rat gefolgt bin und ioBroker einmal komplett neu aufgesetzt habe. Allerdings habe ich dafür einfach eine zweite SD-Karte benutzt. Das erschien mir schneller und einfacher, als ein Backup hin und her zu kopieren. Dabei habe ich dann an einem anderen Rechner und einer anderen iTunes-Instanz die beiden Backups zuletzt ausgelesen.
Allerdings ergab das auch keine Lösung.
Ebenso wie die Portänderung, die Meistertr vorgeschlagen hat. Da blieb der Adapter sogar gelb und hat den Sauger gar nicht gefunden.
Ich habe auch den PI direkt an die Fritzbox an einen LAN gehangen und testweise nur über WLAN mit der Fritzbox verbunden.
An alledem liegt es also nicht. `
Danke für Deine Arbeit. Auch wenn Du damit leider nicht zum Ziel gekommen bist, ist das für die Analyse sehr wichtig!
-
Mehrwiedu, wenn beide Apps auf iPhone und iPad funktionieren, könntest Du SICHERHEITSHALBER noch einmal von beiden Geräten über das Backup die Token auslesen? Eigentlich müssten die dann gleich sein. `
Ich meinte damit, dass ICH nur zufällig darauf gestoßen bin.
Das Backup von iPad und iPhone habe ich jetzt gefühlt schon 20 mal gemacht und ebenso oft den Sauger am iPhone aus der App gelöscht und wieder neu hinzugefügt
. `
Nur noch mal zu meinem Verständnis: Sauger am iPhone gelöscht und hinzugefügt. Am iPad auch?
Frage an die Experten, Meistertr u.a.: kann es sein, dass der ausgelesene Token falsch ist? Irgendetwas mit der neuen Verschlüsselung? Entschlüsselungssoftware? Ich habe ja mit der neuen noch nicht gearbeitet…
-
Nur noch mal zu meinem Verständnis: Sauger am iPhone gelöscht und hinzugefügt. Am iPad auch? `
Nur am iPhone. Am iPad habe ich das "noch" nicht gemacht, gehe aber davon aus, dass ich dann auch hier einen neuen Token bekomme, der dann wiederum zum iPhone Token unterschiedlich ist.Aber das probiere ich auch gerne nochmal.
-
Ich habe ein iPhone 7 und einen iPad Air in betrieb. Ich werde jetzt gleich mal von beiden Geräten Backups erstellen und schauen, was für Token ich da auslese.
Ich melde mich mit den Resultaten.
-
Ich werde jetzt gleich mal von beiden Geräten Backups erstellen und schauen, was für Token ich da auslese.
Ich melde mich mit den Resultaten. `
Ich gehe davon aus, dass Deine beiden Token identisch sind.Du müsstest den Sauger an einem iDevice mal aus der App schmeißen und neu einbinden. Dann sind die sicher unterschiedlich.
Ich hab ihn ja aus der App gelöscht, dann am Sauger Home und Start gleichzeitig gedrückt und somit WLAN ganz neu eingerichtet am Sauger.
Wobei ich das Risiko momentan nicht eingehen würde, hinterher bekommst Du den auch nicht mehr in den Adapter eingebunden.
-
mehrwiedu,
wie Du schon vermutet hast: keine Unterschiede. Da ich ZWEI Sauger habe, habe ich je zwei Token (iPad u. iPhone). Und die sind jeweils identisch.
Was mir aber jetzt noch durch den Kopf geht:
Ich arbeite im iobroker mit der Adapterversion 0.5.5 (ich hatte früher fälschlicherweise 0.5.9 angegeben). Und da sind noch die kürzeren 32er Token drin. Und das funktioniert.
Also schließe ich mal daraus, wenn es mit den 96-character Token in der 0.5.9 NICHT klappt, daß da der Fehler zu suchen ist.
Meistertr, gerne stelle ich Dir meine 32er und 96 Token per PN zur Verfügung. Vielleicht kannst Du damit was anfangen.
(und ja, ich traue mich nicht, auf die Version 0.5.9 zu updaten und es dann mit den neuen Token zu testen. Never Change a running System…)
