SpotArea with an optional runtime in minutes

[bmartin5692]

I'm looking for a way to specify the SpotArea adding an Option for the runtime. e.g. area 1 --15min
I tried the following with OZMO930: sucks area 1 clean 15 but it seems to result in two commands executed one after the other.

Originally posted by @niveksan in #64 (comment)

[bmartin5692]

@niveksan - See commit in my fork of sucks.

I believe this addresses what you are after.

[niveksan]

@bmartin5692
Thanks for your quick response - I tried that fork, but Ozmo doesn't seem to recognize option -m itself.

This is the output of the command line:
sucks DEBUG ----------------- starting session ----------------
sucks DEBUG event = {}
performing spotarea command
sucks DEBUG Sending command <iq to="..." from="c..." id="..." type="set"><query xmlns="com:ctl"><ctl td="Clean" id="..."><clean type="SpotArea" act="s" speed="standard" mid="4" /></ctl></query></iq>
waiting for 900.0s
sucks DEBUG *** charge_status = idle
sucks DEBUG *** clean_status = spot_area fan_speed = normal
sucks DEBUG *** sending ping ***
``
Ozmo is going to the correct room, doing his job for about 3 minutes (1 time, which is the normal clean time for this small room) and then going back to the charger. Sucks is still wating for -m 15 to finally send the charge comand but the machine is still back in the charger.

I would expect the command to be something like: <clean type="SpotArea" act="s" speed="standard" mid="4" minutes="15" />

fyi:
My goal is sending Ozmo930 to the bathroom, cleaning (mopping) the area for 15 min, resp. 5 times. I did try without the mopping unit, but this shouldn't impact the result.

I also did find somewhat related discussions:
#59 (comment)
#37 (comment)
Also in test_commands.py I spotted deep="2" in relation to SpotArea but I don't get this working in the CLI

[bmartin5692]

I was curious why you would need the runtime for SpotArea, my guess was you wanted to cut the cleaning time short for a large area.

For these bots the SpotArea will clean the specified area until complete, then return to the charger automatically. The area command in the sucks cli will wait for the bot to enter a charge_status = returning before issuing the next command.

So, I believe you don't need the -m option I added at all in this case.

Without testing myself yet, I think from the CLI this is as easy as:
Update: I tested and this does work.
sucks area 4 area 4 area 4 area 4 area 4

This should tell it to clean area 4, wait for returning to charger, clean area 4, wait for returning to charger.... repeat...

[niveksan]

too bad. still waiting for the bot to enter a charge_status = returning for 10 mins now, still sending ping, but the bot is already back in the charger

update: when I'm doing sucks clean 1 clean 1 it's working, when issuing sucks area 4 area 4 it's not.

[bmartin5692]

It sounds like sucks is not picking up the charge_status for your bot. What fork/branch are you using? This sounds similar to #66.

The changes I made in my add-fixStatus branch haven't been merged into sucks/master yet.

Can you try the branch above, and also the commands Nama did in 66 to see the output:
Adding something like the below to cli:

vacbot.run(GetChargeState())
print(vacbot.charge_status)

When I tested with my bot it would complete the area, stop briefly as it changed tasks to return to charger, then sucks would issue the next area command and it would begin cleaning again.

[niveksan]

Branch add-fixStatus is also not giving back the charge status. So I moved back to your latest branch with:
sucks --debug area -m 1 4 area -m 1 4
sucks DEBUG ----------------- starting session ---------------- sucks DEBUG event = {} performing spotarea command sucks DEBUG Sending command `<iq to="..." from=".." type="set"><query xmlns="com:ctl"><clean act="s" type="SpotArea" speed="standard" mid="4" />``</ctl></query>``</iq>
waiting for 60.0s
sucks DEBUG *** clean_status = spot_area fan_speed = normal
sucks DEBUG *** sending ping ***
sucks DEBUG *** sending ping ***
performing spotarea command
sucks DEBUG Sending command <iq to=".." id="..." from="..." type="set">``<query xmlns="com:ctl">``<ctl td="Clean" id="...">``<clean act="s" type="SpotArea" speed="standard" mid="4" />``</ctl>``</query>``</iq>
waiting for 60.0s
sucks DEBUG *** clean_status = spot_area fan_speed = normal
sucks DEBUG *** sending ping ***
sucks DEBUG *** battery_status = 75%
sucks DEBUG *** sending ping ***
performing charge command
sucks DEBUG Sending command <iq to="..." id="..." from="..." type="set"><query xmlns="com:ctl"><ctl td="Charge" id="..."><charge type="go" /></ctl></query></iq>
sucks.cli DEBUG waiting on charge_status for value charging
sucks DEBUG *** charge_status = returning
sucks DEBUG *** charge_status = returning
sucks DEBUG *** sending ping ***
sucks DEBUG *** charge_status = charging
sucks.cli DEBUG wait complete; charge_status is now charging

So in some way the bot is returning status it seems

[niveksan]

No idea how to get these working on CLI
vacbot.run(GetChargeState())
print(vacbot.charge_status)

[niveksan]

@bmartin5692 @Nama Could you pls Point me to the right direction how and where to place this peace of code.

[bmartin5692]

Hi @niveksan -
I created a gist with an example that may provide the output required.
See gist.

[niveksan]

Hi @bmartin5692

I did try to get status several times and with several commands but I'm still struggling to get charge_status=returning from the the ozmo itsef. I'm wondeing why I can see status like *** charge_status = idle when the robot is starting triggered through sucks. If ozmo gets the charge command from the ios app I can see charge_status=returning in the command line.

Also ozmo is not receiving/executing the stop command initiated through sucks.

I have some workflows in mind which would depend on getting back status from the robot. One was, as discussed, cleaning/mobbing a room more than one time. Another is starting the robot and directly issuing the stop command once charge_status = idle changes to clean_status = whatever.

Even without workflows, just cleaning the whole floor, sucks never finishes without getting charge status as is will be *** sending ping *** forever, but the bot is still back in the charger.

[niveksan]

@bmartin5692 would you mind merging fork add-area-minutes-#70 into master?

[Nama]

I don't think that will be possible.
You can see here how the raw commands are sent. The app doesn't decides the running time, on no command. The bot decides how long he'll sucks.

The best you could do is, installing the add-fixStatus branch and check for the status every minute or something and send the spot clean command again if the status is not "spot", till x minutes are reached.

[niveksan]

Hi @Nama
You are rights and this was already conirmed by @bmartin5692
This was the solution provided: #70 (comment) , but the remaining problem I have with the 930 is that the bot itself will not reply the charge_status =returning once finished the area the first time. So sucks is not able to execute it more than once.

Which bot do you have? Are you able to get the status once returning to the charger?

[Nama]

Also ozmo is not receiving/executing the stop command initiated through sucks.

You sure are using bmartin's fork?

I am still using the add-fixStatus branch and using it with OZMO 610.
Running

vacbot.run(Charge())
vacbot.run(GetChargeState())
print(vacbot.charge_status)

returned

DEBUG:sucks:*** charge_status = returning
returning

I can't seem to test "area", since this is not the "spot" command (and this lacks completely in sucks it seems, although, something is called "spot" in the library). My bot doesn't have a map. But it can clean a radius from it's current spot.

[niveksan]

@Nama
Yes, you are right. If you initiate the the command (whether through sucks or the iOS app) the status will be returned. but when letting the bot decide that the task is finished (area as well as auto cleaning) the bot doesn't return that status, which prevents sucks from initiating the next task. sucks is just sending/requesting ping forever.

so, for me, @bmartin5692's fork with adding a minutes option is just a workaround until a solution may be available.

[bmartin5692]

Just a side note I merged the add-fixStatus branch into my master some time back. My master should be the most up-to-date.

It seems sucks isn't picking up status 'returning' when @niveksan 's bot reports it (if it reports it at all). I don't have a 930 to test against, but will try to do some additional testing against my 901. It won't be a 1:1 comparison since the 901 uses MQTT vs the 930 using XMPP.

Another option to try is modifying the wait for the area command to 'charging' instead of 'returning'. This isn't ideal as sucks would wait until the bot is charging again before issuing the next CLI command, but may be worth testing.

Modify lines 189 & 191:
https://github.com/bmartin5692/sucks/blob/eafccb64e667b17a3f06afbaa7ae822ae96e4dce/sucks/cli.py#L188-L191

Otherwise I think you'll need to use Sucks as a library in your own code, the CLI is meant to be basic and won't provide the low-level watches you may want.

[Nama]

I let my script log all status changes, as I let it clean in auto-mode without stopping it manually. The bot will clean tomorrow again.

Just a side note I merged the add-fixStatus branch into my master some time back. My master should be the most up-to-date.

Oh nice, last time I checked it wasn't. Will update someday. Thanks!

[niveksan]

Thanks @Nama, @bmartin5692

It seems sucks isn't picking up status 'returning' when @niveksan 's bot reports it (if it reports it at all).

In some way it must report the status, at least to the ios app.

Another option to try is modifying the wait for the area command to 'charging' instead of 'returning'.

For me this wouldn't be the optimal solution, as I just want to mop the bathroom 3 times in a row whithout mopping the way back to charger ;) Also even in this case (back in the charger) sucks don't get back a status from the bot. As i said - sucks is sending ping forever.

It just gets the different status changes only when sucks is initiating the command (e.g. charge). But that's the curious point in my opinion: when sucks is requesting the bot to charge, the bot will return the appropriate status (e.g. returning to charger and charging)

[Nama]

Another ugly workaround could be, if you send wait=False and look for yourself how long the bot takes to finish and send another area clean command after that time.

[niveksan]

I'm already able to do exactly that with the fork https://github.com/bmartin5692/sucks/tree/add-area-minutes-%2370

[niveksan]

that's the curious point in my opinion: when sucks is requesting the bot to charge, the bot will return the appropriate status (e.g. returning to charger and charging)

`sucks DEBUG ----------------- starting session ----------------,
sucks DEBUG event = {},
performing charge command,
sucks DEBUG Sending command ,

sucks.cli DEBUG waiting on charge_status for value charging,
sucks DEBUG *** charge_status = returning,
sucks DEBUG *** battery_status = 98%,
sucks DEBUG *** battery_status = 97%,
sucks DEBUG *** charge_status = charging,
sucks.cli DEBUG wait complete; charge_status is now charging,
done`

[Nama]

So, I did Clean() and disconnect(), these are the statuses I got, in the correct order:
(I am still on the add-fixStatus branch, not master)
charging
auto
auto
auto
stop
returning
stop (would be last one if it can't find the dock)
charging