Comments (43)
@syssi @rytilahti I finally found the problem, change https://github.com/rytilahti/python-mirobo/blob/adfa737579f75fb09446a99a6e43775bca293358/mirobo/device.py#L140 range(3)
to range(1)
solve the problem, seems device doesn't like flood discovery.
To work with water purifier: 1, send a broadcast first; 2, then the IP of request machine free to send any raw command(I still don't know is it forever)
P.S. Another issue, when I send raw_command like get_prop '["mode","press"]'
, it returns ['idle', 'error']
, no matter how much params sent, only the first value is OK, JS miio works fine.
from python-miio.
A pity. It doesn't help.
from python-miio.
Your provided commands are doing different things. The first one (miio) sends the command "get_prop" to the device. The second command (via mirobo) sends the command "miIO.info". It looks like your device doesn't support the command. Could you try the same via miio?
miio --control 10.0.1.8 --token a3d7f95***3 --method miIO.info
Do you get a response?
from python-miio.
@syssi thanks for the quick response :)
Yes, it has resp.
INFO Got result:
{
"life": 40681,
"token": "a3d7f95***3",
"mac": "28:6C:07:xx:xx:xx",
"fw_ver": "1.2.8",
"hw_ver": "ESP8266",
"uid": 166*****,
"model": "yunmi.waterpuri.v2",
"mcu_fw_ver": "0019",
"wifi_fw_ver": "1.4.0(30e0bd0)",
"ap": {
"rssi": -56,
"ssid": "myssid",
"bssid": "00:A2:EE:xx:xx:xx"
},
"netif": {
"localIp": "10.0.1.8",
"mask": "255.255.0.0",
"gw": "10.0.0.1"
},
"mmfree": 10976
}
from python-miio.
Cool. This response is good! I'm a bit confused now. ;-) I will read the code again.
from python-miio.
Got it. The CLI tool calls vac.info(). Before DeviceInfo(self.send("miIO.info", [])) can be processed we must discover the device. The discovery fails because the device doesn't respond to the helobytes on port 54321 oddly enough. Hmm.. the discover method of miio and mirobo is equal.
from python-miio.
It looks like a timeout. This is the method call which returns None and raises the Exception:
https://github.com/rytilahti/python-mirobo/blob/master/mirobo/device.py#L58
The called method L77 should output additional debug messages most of the time. There is just one code path which doesn't produce additional outputs: If "is_broadcast" is false and we hit the except block for a socket.timeout. The method will return None now.
Could you execute
mirobo --ip 10.0.1.8 --token a3d7f95***3 -d info
a few times? You can also increase the timeout at L79.
from python-miio.
hmm, tried both, but still failed Unable to discover the device
P.S. miio exec time about 5s, increased device.py's timeout to 15.
from python-miio.
I'm out of ideas. Do you have some Teemu? @rytilahti
from python-miio.
Alas not really. @nutinshell are you controlling the device with some other library/device at the same time you are trying to access it with mirobo, maybeb there is a problem with multiple concurrent connections? You could also use -d multiple times (or just do -dd) to get a bit more debug output.
from python-miio.
@rytilahti tried many times, no one worked. -dd like:
ERROR:mirobo.vacuum_cli:Unable to read the stored msgid: [Errno 2] No such file or directory: '/tmp/python-mirobo.seq'
DEBUG:mirobo.vacuum_cli:Connecting to 10.0.1.8 with token a3d7f95***3
ERROR:mirobo.device:Unable to discover a device at address 10.0.1.8
Traceback (most recent call last):
File "/usr/local/bin/mirobo", line 11, in <module>
sys.exit(cli())
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/click/decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/mirobo/vacuum_cli.py", line 339, in info
res = vac.info()
File "/usr/local/lib/python3.5/dist-packages/mirobo/device.py", line 183, in info
return DeviceInfo(self.send("miIO.info", []))
File "/usr/local/lib/python3.5/dist-packages/mirobo/device.py", line 120, in send
self.do_discover()
File "/usr/local/lib/python3.5/dist-packages/mirobo/device.py", line 72, in do_discover
raise DeviceException("Unable to discover the device %s" % self.ip)
mirobo.device.DeviceException: Unable to discover the device 10.0.1.8
It's not the concurrent connection issue, just want to make a hass custom sensor by using mirobo, but no luck, hass report the same error like mirobo cli. I found an interesting phenomenon, the hass custom script works one time only this afternoon, and then never works...
from python-miio.
Could you try the same from another host/system? Just for fun. ;-)
from python-miio.
@syssi yes, tried on mac, same :) miio worked, mirobo failed :(
from python-miio.
Got it. The CLI tool calls vac.info(). Before DeviceInfo(self.send("miIO.info", [])) can be processed we must discover the device. The discovery fails because the device doesn't respond to the helobytes on port 54321 oddly enough. Hmm.. the discover method of miio and mirobo is equal.
@syssi I had a look at https://github.com/aholstenson/miio/, seems quite different with mirobo (I am not very familiar with js or py)
from python-miio.
The question is: Why is miio working for you and mirobo is not? The executed code is the same.
from python-miio.
@syssi hmm, no idea, mirobo works with my air purifier but not water purifier, maybe some diffs in handle other devices like water purifier's data. Also, doesn't find mimo send helobytes, am I right?
from python-miio.
How about this: https://github.com/SchumyHao/python-miio/blob/master/miio/miio.py#L58 ;-)
from python-miio.
How about this: https://github.com/SchumyHao/python-miio/blob/master/miio/miio.py#L58 ;-)
No, it's https://github.com/aholstenson/miio/ of course :D
from python-miio.
@nutinshell you could try to capture the network traffic caused by miio(js) and see how it compares to python-mirobo. As far as I know miio also uses handshakes (and those are required for some devices like the vacuum to function, as it is the way to gain the timestamp of the device for further requests).
from python-miio.
Good suggestion. I would evalute the capture if you can provide one. Wireshark/tcpdump should be used.
from python-miio.
I compared the javascript implemention of the discovery. It's very similar. The important parts:
https://github.com/aholstenson/miio/blob/master/lib/discovery.js#L97-L108
https://github.com/aholstenson/miio/blob/master/lib/packet.js#L7-L16
There is just one funny thing: The helobytes are a bit different:
Mirobo: 21310020ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
MiioJs: 21310000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
from python-miio.
Hmmm, interesting. Now I'm curious what the official app does. That difference there could be explained by some sort of a flag, which used to work / works in some cases but not in others, iirc I extracted the handshake from the communication of my vacuum..
@nutinshell could you try changing the hello bytes to see if that helps? If yes, maybe we need to adjust that procedure.
from python-miio.
Good suggestion. I would evalute the capture if you can provide one. Wireshark/tcpdump should be used.
sure, should I email you directly? :)
from python-miio.
Yes! basti at linkt.de
from python-miio.
@nutinshell could you try changing the hello bytes to see if that helps? If yes, maybe we need to adjust that procedure.
change hello bytes not help, in wireshark, it seems miio seeds same hello bytes 21310020
from python-miio.
Yes! basti at linkt.de
Sent :D
from python-miio.
@nutinshell could you try to run mirobo discover --handshake 1
before the other commands?
from python-miio.
@nutinshell could you try to run mirobo discover --handshake 1 before the other commands?
OK
here is the result:
INFO:mirobo.device:Sending discovery to <broadcast> with timeout of 5s..
INFO:mirobo.device: IP 10.0.1.8: 758 - token: b'a3d7f9***3'
INFO:mirobo.device:Discovery done
from python-miio.
The request was something like this:
mirobo discover --handshake 1; mirobo --ip 10.0.1.8 --token a3d7f95***3 -d info
Could you give it a try?
from python-miio.
@syssi OK
root@hass ~ # ❯❯❯ mirobo discover --handshake 1;mirobo --ip 10.0.1.8 --token a3d7f95*****3 -d info ✘ 1
INFO:mirobo.device:Sending discovery to <broadcast> with timeout of 5s..
INFO:mirobo.device: IP 10.0.1.8: 758 - token: b'a3d7f95****3'
**my many other devices**
INFO:mirobo.device:Discovery done
INFO:mirobo.vacuum_cli:Debug mode active
DEBUG:mirobo.vacuum_cli:Read stored sequence ids: {'manual_seq': 0, 'seq': 6}
DEBUG:mirobo.vacuum_cli:Connecting to 10.0.1.8 with token a3d7****3
ERROR:mirobo.device:Unable to discover a device at address 10.0.1.8
Traceback (most recent call last):
File "/usr/local/bin/mirobo", line 11, in <module>
sys.exit(cli())
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/click/decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "/usr/local/lib/python3.5/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/mirobo/vacuum_cli.py", line 339, in info
res = vac.info()
File "/usr/local/lib/python3.5/dist-packages/mirobo/device.py", line 183, in info
return DeviceInfo(self.send("miIO.info", []))
File "/usr/local/lib/python3.5/dist-packages/mirobo/device.py", line 120, in send
self.do_discover()
File "/usr/local/lib/python3.5/dist-packages/mirobo/device.py", line 72, in do_discover
raise DeviceException("Unable to discover the device %s" % self.ip)
mirobo.device.DeviceException: Unable to discover the device 10.0.1.8
from python-miio.
Do you know which properties are supported?
from python-miio.
Do you know which properties are supported?
known currently: ["press","temperature","uv_state","filter_state","elecval_state","uv_life","mode"]
from python-miio.
@nutinshell awesome! So, a broadcast is necessary (and the default "handshake" only on that device is not enoguh) even after you modified the flooding of those requests, if I understood it correctly? IIRC there was no specific reason why I decided to make it send three packets, only "just to be sure they will go through". Maybe this also causes the problem some people are having with the vacuum not answering to discoveries always..
As a side note, different manufacturers have different kind of implementations. E.g. the vacuum cleaner does not advertise over mDNS if the device has no connectivity to the internet. @syssi I recall philips ones did not either, are yours connected to the internet?
from python-miio.
My philips light has internet access. It doesn't advertise over mDNS nevertheless.
from python-miio.
So, a broadcast is necessary (and the default "handshake" only on that device is not enoguh) even after you modified the flooding of those requests, if I understood it correctly?
It appears so, have to do mirobo discover --handshake 1
command first.
from python-miio.
I will try to write some proof of concept code tomorrow.
from python-miio.
@nutinshell Sorry I need to ask again: Are you sure about the need of mirobo discover --handshake 1
in front of every command? Just change the to range(1)
is not sufficient, right? Could you check it twice? It will involve some overhead per request.
from python-miio.
Sorry I need to ask again: Are you sure about the need of mirobo discover --handshake 1 in front of every command?
No, only need to do it one time for the new machine.
from python-miio.
Got it: If you "reboot" your water purifier and call mirobo --ip 10.0.1.8 --token a3d7f95***3 -d info
afterwards the device cannot be discovered? If you publish a multicast broadcast by mirobo discover --handshake 1
your host is well known afterwards and you can execute mirobo --ip 10.0.1.8 --token a3d7f95***3 -d info
multiple times with success? Could you wait 15 minutes and execute the command (mirobo --ip 10.0.1.8 --token a3d7f95***3 -d info
) again? I want to make sure the water purifier doesn't forget about your host.
from python-miio.
@syssi after reboot, it still works. I did lot of successful tests after a sleep :)
from python-miio.
Is this still an issue? If not, please close this.
from python-miio.
@rytilahti latest mirobo cli still failed, compare to JS miio working fine.
from python-miio.
Cp. #284. We should request all properties by get_prop []
. It looks like some firmware version doesn't respond properly to a list of requested properties.
from python-miio.
Related Issues (20)
- The response time to get the current power usage varies a lot HOT 5
- ERR: miiocli genericmiot --ip 192.168.5.x --token xxxx status HOT 10
- O puedo conectar al wi fi mi xiamo home
- Question about how to Set Voice dreame.vacuum.r2211o
- Unable to get status from fanp5 using the genericmiot command HOT 2
- Unsupported model 'roborock.vacuum.a62'
- get_properties of xiaomi.vacuum.c107 timeout falsely if max_properties >= 4 when get property `vacuum-map:clean-record`
- Found an unsupported model 'roborock.vacuum.a70'
- Roidmi Eva (roidmi.vacuum.v66) with genericmiot HOT 3
- Found an unsupported model 'lumi.acpartner.v2'
- suport xiaomi.controller.86v1
- I can't run set-voice command dreame.vacuum.p2041o HOT 6
- Xiaomi Smart Standing fan 2 Pro, model: dmaker.fan.p33 . HOT 3
- Unable to decode chuangmi.camera.ipc013d pcap file HOT 2
- Add suppport for viomi.vacuum.v13 HOT 1
- 小米 mini led s pro 75 HOT 1
- 小米 MINI LED S Pro 如何快速切换 HDMI HOT 1
- Roborock S7 Max Ultra (roborock.vacuum.a65)
- Roborock G20 ( roborock.vacuum.a69)
- Supporto for ijai.vacuum.v3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-miio.