Vacuum 1C STYTJ01ZHM (dreame.vacuum.mc1808) - Many retries (and a potential fix)...

[anonymous-one]

Before I begin, I am not very well versed in Python or the miio protocol... But here goes:

When ever I would try to execute any commands / pull any info from my STYTJ01ZHM, miiocli would take quite some time to execute the request... 10-15 seconds, and sometimes, it would even fail out right.

When using the -d flag I noticed that there was quite a few retries:

DEBUG:miio.miioprotocol:Retrying with incremented id, retries left: 1

To fix this I modified miioprotocol.py with the following change:

self.__id += 1

to

self.__id += random.randint(1,100)

With this I am able to avoid retries and the replies to the commands happen on first request. Obviously with a range of 1 - 100 there is a chance that a recently used id will be selected again... But I am unsure what the range for the ids is and 1 - 100 works for the 1 / 60 second status polling I do and whatever actions I send to the vacuum.

Not sure if this breaks things... But in my case it works. Big guess here, but I am guessing that the fairly consistent list of ids that miiocli uses (1, 102, 203, etc...) are occupied / locked, and the vacuum refuses to answer on these recently used ids? Guessing here...

[StarterCraft]

This helped me to solve my connection problem, when the robot failed to answer 90% of the commands I sent him. Thank you!

[rytilahti]

I just noticed this issue thanks to @StarterCraft's mention.

So, the id sequence behavior may differ between devices and maybe even whether you also use the official app or some other software to control the device simultaneously. That is also why the ID gets increment by 100 for retries (https://github.com/rytilahti/python-miio/blob/master/miio/miioprotocol.py#L231).

However, as you are not using the library (but the miiocli tool), this won't be saved anywhere so what happens is the following:
A: first miiocli execution (id=1)
B: second miiocli execution (id=1), gets ignored by the device as 1<2
B: automatic retry (id=101), this should work now
C: third miiocli execution (id=1), ignored again
C: miiocli retry (id=101), ignored again as the device now awaits >101 for the id
C: miiocli retry (id=201), this should work again
D: fourth miiocli execution (more retries needed now until the device resets its internal id counter)

The proper fix here is to modify miiocli to save the previously used sequence much like mirobo (for rockrobo only) does.

[StarterCraft]

Suggested PR #1092 to resolve this issue as @anonymous-one did.