[Error] Timout when querying for status #1
Comments
|
Are you sure the IP belongs to the robot? Does the IP answer to pings? If you try nmap against it, do you see open ports? Considering that you tried increasing the timeout, this sounds odd. |
|
The Ip belongs to the robot.. But the only open port is an ssh port? I pressed the reset button on the robot itself, and got when discovering: After setting up the wifi inside the original app, I get this: Which FW version are you running? Did you bind the robot to your wifi using the original app? |
|
The nmap results look similar to mine, so the network connectivity doesn't seem to be the problem. For discovery it's not using the token at all, it's just ignored. My robot is bound with the original app yes, the FW version is 3.3.6_003047. Maybe cou could try to use tcpdump or wireshark to see if the robot is answering anything? I'm running python 3.4 here, but that shouldn't be a problem. edit: you could also try if calling "mirobo consumables" yields a timeout too? It's a bit odd that discover (even when connected) will respond just fine... |
|
I have the same FW version. tcpdump results doesn't look promising.. Original app turning on cleaning: So we get an answer when using discover bit, but not on the functions.. |
|
Those messages you see for original app turning it on are not related to control, but discovery (through mdns), confirms that the IP is correct though. Do you have a different firmware version then? Mine says that it's already up to date, and I doubt they would have changed it so suddenly, but it's possible. |
|
same issue here everything falls into timeout. By the way i compiled un exe for discovering. As it can be easier for some people to connect to the vacuum wifi via a laptop to get the token I was going to integrate the air purifier, but with the timeout issue happening every where it's weird |
|
The timeout (also) happens when an incorrect message is sent to the device, e.g. when the token is invalid. I just commited a couple of changes, one allowing using -d multiple times, and made it print out more information when invoked with '-dd'. @georg90 could you do a discovery (it doesn't require specifying token & ip anymore) with -dd and paste the contents its printing? @sarakha63 nice to hear about air purifier. Those timeouts are weird, but indicate most likely that there's a problem with the token or with the checksum. You could also try with -dd to see if the returned messages do look fine. |
|
i also have the humidificator and lots of other device that do follow the same process |
|
here it is |
|
That's what is being sent, try the discovery to see what is being returned to you. Could you remove the comment on this line: https://github.com/rytilahti/python-mirobo/blob/master/mirobo/vacuum.py#L45 Maybe it's about the one hardcoded "serial" value which is causing it. In my robot it is 41997, but maybe it differs for you and that causes the problem. Maybe there are different revisions of the software, or that this value is somehow based on hardware and you happen to have a different revision? That is, assuming that this is working for someone else besides me at all :-) |
|
i nice guess i'm checking that |
|
mine is not 41997 it is 55069 |
|
Also the type id is not the same mine is 0x034c |
|
Ok, then that's not really a type, but something else. It was just a guess from my part (after reading some forums etc.). Or maybe it is a type, but your hardware/software is different.. |
|
[2017-03-31 20:34:34][DEBUG] : Got a response: Container: |
|
Ah this is not the good one sorry |
|
In the bottom of the robot there are some serial numbers etc, maybe we can pinpoint those to the required values. The purifier is detected correctly, right? If so, we are on the correct track with devid being a devid of some sort :) Please try to change https://github.com/rytilahti/python-mirobo/blob/master/mirobo/protocol.py#L140 accordingly. edit: for comparison, here's output from my (already connected) discover: |
|
Oh yes i have lots of device detected. No i added manualy the type with the code i had with discover, so the name is because i followed the same idea as you and added it to the dict |
|
i don't get it even if i change the serial in the message struct in protocol file i alaways see 41997 for the serial |
|
Those are currently hardcoded in vacuum.py it seems, my bad. Check out lines 66-68. It's all in a bit "proof-of-concept" state currently. The structure is being used (mostly) for reading. |
|
ahhh ok |
|
Ok great needed to change both of them serial and type and i get my status ;) nice |
|
so in my integration just have to add the devtype and the serial on the json result on discover and save it in the system. will investigate the purifier this week end |
|
Fo info the purifier keeps giving its real token even after being connected |
|
That's great to hear that it works! Could you please check what it says underneath your robot for CMIIT ID and the second one? In my case they are SDJQR01RR (device id I assume) and CMIIT 2016DP3912. |
|
SDJQR01RR and 2016DP3912. So i really thing the dict for devtype won't be usefull for now, and the vacuum class should just have serial and devtype to be added as argument, and the samething displayed upon disover and the lib will be just fine. Maybe we will find that there are only 2 or 3 devtypes and the dict can come back. But for now im not sure it has sense. AS we don't know yet if there are 2 3 or 10 devtypes for the same device family. But great i will come back on my attempts on Purifier Humidifcator and else |
|
Yeah, that's true. I think the best solution for this would be to send a discovery message to the given device before sending any more messages. It would induce a small delay, but it'd make it easy to extract the required values and use them directly. Let's see what values @georg90 has and see how to proceed. |
|
the dev type for @georg90 is 844 (decimal) the same as mine, lets see for the serial if it is the same |
|
Great job guys. That fixed it for me! So using discover I get (first removing comment from L45): Now I can get information from the robot: What I did was using So I guess, when initially setting up the script, we need two more variables "serial" and "devid" to get it working correctly? |
|
Yep and as i can see the devid and the serial seems really not the same so hard to deduct a logic to map it to a dev type. I guess we should really consider serial and devid as a totally dynamic value for now |
|
@rytilahti do you know how was found the cmds app_start app_stop and so on. I have succesfully gotten so datas sent with mihome for the purifier. I used the code to unpack it
but i would like to get the equivalent of app_start app_stop. To try generating it trough the lib and see if it succeeds Here is what i caught from mihome 213100600000000002d1d71d0001b401296bd8ff968cebf68e4588d39eab346691ca787891f3c8b94f748ce185ff6f2b66f6cfccbc5f105db0d573f40fbff68464ab41ed40ebc4644051e94c642bea78ff551e9dfab891045128d59da5111389 It seems to be parsed as a valid message by the lib. Just needs to get the equivalent of app_start and so on |
|
Ok managed to make the purifier work, the only thing is that the timestamp inside the purifeir can be not set and is 1970 ..... So the idea is to query the device before to fullfill the ts field on the sent data with a date expected by the purifier And i think this can be used for every device even the robot so we will be sure that a robot whose date can be wrong will still be controlable by the lib |
|
Ok just managed to make the humidificator work too |
|
Looks like you found my source for those commands too, great. Good to hear that you got your devices working too 👍 From https://github.com/OpenMiHome/mihome-binary-protocol/blob/master/doc/PROTOCOL.md : If that's true, it's been just lucky to have similar MAC addresses for same line of devices. This and the timestamp issue you encountered mean that it'll be the best when we just send an unicast discovery, as the client should return to that accordingly with all required fields filled in. The only problem I see with this is that we can't differentiate between devices (if not having a dictionary for common values). |
|
Great work with this bit of software - I'm excited to get this working! I installed the package with: "pip3 install python-mirobo" on a RPi3 running raspbian. I connected to MiRobot's WiFi and had wlan0 IP of 192.168.8.72. When entering command "mirobo discover" the following message is returned:
I then tried "mirobo --ip 192.168.8.1 --token ffff discover" and received:
Having then setup WiFi in the original app I was getting the same timeout issues as described in the first message in this thread. I followed the instructions above and un-commented line 45 and was able to get the device ID and serial and replace these in line 66 with the binary numbers (devtype = 845 & serial = 25325). Now it all works :-) |
|
Nice to hear that it's working for you! This needs to be fixed by either allowing defining this "device id" (which includes both devtype and serial) or by sending a discovery packet on every connection try to the robot to gather this information. |
|
The newest version (0.0.5) now sends multiple discovery packets during the discovery process for new robots to avoid dropped packets (the robot seem not to answer for every request). It also send a hello to the given IP and fetches the "serial" and "devtype" for each separate request, so this should now work generally on all robots. @sarakha63 your work on supporting other devices can be done in separate reports & pull requests, so I'm closing this one related to the vacuum now :-) |
Hi!
Thank you for this great plugin! Exactly what I was looking for!
I am having trouble using it with my vacuum. I discover my vacuum just fine:
But when trying to query the status, I get this error:
Steps I took:
miroboPS: I already increased the timout 15s inside the
vacuum.pyThe text was updated successfully, but these errors were encountered: