VacBot vacuum_status when returning
67 views
Skip to first unread message
Guillermo Schimmel
Nov 26, 2018, 9:26:23 AM11/26/18
to sucks-users
As you know I'm actually doing a sort of sucks-mqtt gateway in order to integrate Ecovacs with OpenHAB.
The natural candidate for a quick vacuum status to show is vacbot.vacuum_status, of course.
But what I'm seeing is that when the vacuum cleaner it's actually returning, it first takes the value "returning" and then "stop".
As the robot sometimes takes a very long time to get back to the base, I was wondering if woudln't be better to keep the status at "returning". I think it would refflect better the real status of the machine. clean_status is "stop", that is right, but the robot is not stopped. It's returning.
Perhaps this was already discussed, in that case please disregard.
Thanks
William Pietri
Nov 26, 2018, 10:32:47 AM11/26/18
to sucks-users
On 11/26/18 6:26 AM, Guillermo Schimmel
wrote:
The natural candidate for a quick vacuum status to show is vacbot.vacuum_status, of course.
But what I'm seeing is that when the vacuum cleaner it's actually returning, it first takes the value "returning" and then "stop".
As the robot sometimes takes a very long time to get back to the base, I was wondering if woudln't be better to keep the status at "returning". I think it would refflect better the real status of the machine. clean_status is "stop", that is right, but the robot is not stopped. It's returning.
Ah, I see what you're saying. Excellent point, and hopefully Greg
will have time to weigh in here. When I look at my run from
yesterday, this is what I see:
You're right that while charge_status is returning, it does notify us of a clean_status that is stop. I'm not quite sure what the fix here is, though. Is it that clean statuses can't override charge statuses? Or just that certain clean statuses can't override charge statuses? Or is this more tied to what the most recent command is?
I suppose the other option is to get rid of vacuum_status, on the theory that this library should just be a pass-through to Ecovacs. But since you and Greg have both ended up needing a joint vacuum status, I think it makes sense to clean up the Ecovacs protocol's messy abstraction in this library.
William
sucks DEBUG ----------------- starting session ----------------
sucks DEBUG event = {}
performing clean command
sucks DEBUG Sending command <iq to="E000069381...@126.ecorobot.net/atom" from="2017102559...@ecouser.net/c2a1fbc3160282a18d818a2052e08649" id="f80700f0-4415-46dd-b25c-a0097fc0fc83-3" type="set"><query xmlns="com:ctl"><ctl td="Clean"><clean type="auto" speed="standard" /></ctl></query></iq>
waiting for 900.0s
sucks DEBUG *** clean_status = auto fan_speed = high
sucks DEBUG *** charge_status = idle
sucks DEBUG *** clean_status = auto fan_speed = None
sucks DEBUG *** battery_status = 99%
sucks DEBUG *** sending ping ***
sucks DEBUG *** battery_status = 98%
sucks DEBUG *** sending ping ***
sucks DEBUG *** battery_status = 97%
sucks DEBUG *** battery_status = 96%
[... boring part removed ...]
sucks DEBUG *** sending ping ***
sucks DEBUG *** sending ping ***
sucks DEBUG *** battery_status = 86%
sucks DEBUG *** sending ping ***
sucks DEBUG *** battery_status = 85%
sucks DEBUG *** sending ping ***
sucks DEBUG *** sending ping ***
performing charge command
sucks DEBUG Sending command <iq to="E000069381...@126.ecorobot.net/atom" from="2017102559...@ecouser.net/c2a1fbc3160282a18d818a2052e08649" id="f80700f0-4415-46dd-b25c-a0097fc0fc83-21" type="set"><query xmlns="com:ctl"><ctl td="Charge"><charge type="go" /></ctl></query></iq>
sucks.cli DEBUG waiting on charge_status for value charging
sucks DEBUG *** charge_status = returning
sucks DEBUG *** sending ping ***
sucks DEBUG *** charge_status = returning
sucks DEBUG *** clean_status = stop fan_speed = None
sucks DEBUG *** sending ping ***
sucks DEBUG *** charge_status = charging
sucks.cli DEBUG wait complete; charge_status is now charging
You're right that while charge_status is returning, it does notify us of a clean_status that is stop. I'm not quite sure what the fix here is, though. Is it that clean statuses can't override charge statuses? Or just that certain clean statuses can't override charge statuses? Or is this more tied to what the most recent command is?
I suppose the other option is to get rid of vacuum_status, on the theory that this library should just be a pass-through to Ecovacs. But since you and Greg have both ended up needing a joint vacuum status, I think it makes sense to clean up the Ecovacs protocol's messy abstraction in this library.
William
Guillermo Schimmel
Nov 26, 2018, 10:48:22 AM11/26/18
to William Pietri, sucks-users
No please! I like vacuum status. I think it's a good idea. I just think that returning should override stop until it gets to the base. Returning is always in a not-cleaning mode.
--
You received this message because you are subscribed to the Google Groups "sucks-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sucks-users...@googlegroups.com.
To post to this group, send email to sucks...@googlegroups.com.
Visit this group at https://groups.google.com/group/sucks-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sucks-users/a219294f-3128-9b14-ac42-25c3ca78b035%40scissor.com.
For more options, visit https://groups.google.com/d/optout.
Greg Laabs
Nov 26, 2018, 6:04:48 PM11/26/18
to sucks-users
Yeah, I feel strongly about keeping the vacuum_status in the lib, because otherwise we'd be asking every integrator to implement the exact same Ecovacs-specific logic to interpret the API responses.
I'll need to test the scenario you reported Guillermo and see how we can handle this properly. The lib already does do some special logic where certain reports are ignored for the sake of the vacuum_status, such as this one: https://github.com/wpietri/sucks/blob/master/sucks/__init__.py#L348-L353
Right now my Home Assistant integration is broken due to the bug reported here https://github.com/wpietri/sucks/issues/45 - I keep meaning to submit a PR that pins the sleekxmpp version to the non-breaking version so we can discuss it. I'll get to that sooner now so I can help out with this thread's issue.
On Monday, November 26, 2018 at 7:48:22 AM UTC-8, Guillermo Schimmel wrote:
No please! I like vacuum status. I think it's a good idea. I just think that returning should override stop until it gets to the base. Returning is always in a not-cleaning mode.
On Mon, 26 Nov 2018 at 12:32 William Pietri <wil...@scissor.com> wrote:
On 11/26/18 6:26 AM, Guillermo Schimmel wrote:
The natural candidate for a quick vacuum status to show is vacbot.vacuum_status, of course.
But what I'm seeing is that when the vacuum cleaner it's actually returning, it first takes the value "returning" and then "stop".
As the robot sometimes takes a very long time to get back to the base, I was wondering if woudln't be better to keep the status at "returning". I think it would refflect better the real status of the machine. clean_status is "stop", that is right, but the robot is not stopped. It's returning.
Ah, I see what you're saying. Excellent point, and hopefully Greg will have time to weigh in here. When I look at my run from yesterday, this is what I see:
sucks DEBUG ----------------- starting session ---------------- sucks DEBUG event = {} performing clean command sucks DEBUG Sending command <iq to="E00006938...@126.ecorobot.net/atom" from="2017102559...@ecouser.net/c2a1fbc3160282a18d818a2052e08649" id="f80700f0-4415-46dd-b25c-a0097fc0fc83-3" type="set"><query xmlns="com:ctl"><ctl td="Clean"><clean type="auto" speed="standard" /></ctl></query></iq> waiting for 900.0s sucks DEBUG *** clean_status = auto fan_speed = high sucks DEBUG *** charge_status = idle sucks DEBUG *** clean_status = auto fan_speed = None sucks DEBUG *** battery_status = 99% sucks DEBUG *** sending ping *** sucks DEBUG *** battery_status = 98% sucks DEBUG *** sending ping *** sucks DEBUG *** battery_status = 97% sucks DEBUG *** battery_status = 96% [... boring part removed ...] sucks DEBUG *** sending ping *** sucks DEBUG *** sending ping *** sucks DEBUG *** battery_status = 86% sucks DEBUG *** sending ping *** sucks DEBUG *** battery_status = 85% sucks DEBUG *** sending ping *** sucks DEBUG *** sending ping *** performing charge command sucks DEBUG Sending command <iq to="E00006938...@126.ecorobot.net/atom" from="2017102559...@ecouser.net/c2a1fbc3160282a18d818a2052e08649" id="f80700f0-4415-46dd-b25c-a0097fc0fc83-21" type="set"><query xmlns="com:ctl"><ctl td="Charge"><charge type="go" /></ctl></query></iq> sucks.cli DEBUG waiting on charge_status for value charging sucks DEBUG *** charge_status = returning sucks DEBUG *** sending ping *** sucks DEBUG *** charge_status = returning sucks DEBUG *** clean_status = stop fan_speed = None sucks DEBUG *** sending ping *** sucks DEBUG *** charge_status = charging sucks.cli DEBUG wait complete; charge_status is now charging
You're right that while charge_status is returning, it does notify us of a clean_status that is stop. I'm not quite sure what the fix here is, though. Is it that clean statuses can't override charge statuses? Or just that certain clean statuses can't override charge statuses? Or is this more tied to what the most recent command is?
I suppose the other option is to get rid of vacuum_status, on the theory that this library should just be a pass-through to Ecovacs. But since you and Greg have both ended up needing a joint vacuum status, I think it makes sense to clean up the Ecovacs protocol's messy abstraction in this library.
William
Guillermo Schimmel
Nov 26, 2018, 6:33:53 PM11/26/18
to overl...@gmail.com, sucks-users
I think we could try to draw a model of the ideal "state machine for status reporting" and that should be the response of vacuum_status.
Something in the lines of:
Charging - Cleaning - Stuck (or other error, I still haven't been able to go deep into errors) - Returning
That is what I would like to see at a first glance.
How do you guys feel about that?
To view this discussion on the web visit https://groups.google.com/d/msgid/sucks-users/6f087143-6bab-48ab-ace1-a92d2bc378a2%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages