State of Project and Merge Requests

[Brian Martin]

William et al,

What is the current state of the project?  There are two pull requests (#63 / #61) that have been waiting for months to be merged.  There is lots of activity around them as they add support for newer bots and work well with the other automation projects like Hassio.

Are there users on this list with authority to merge and push the project forward?  I would like William to weigh in, but as a community we may need to consider alternatives.

Thoughts?

[William Pietri]

Hi, all. Brian, sorry for the lack of action on this. For me, the TL;DR is that my dad got a brain tumor, had extensive treatment, and eventually died from it. And in the last month or so, I've been trying to start a company. This project has been unfortunately low on my priority list.

I did try looking at your pull request a couple of times. It's very large relative to the size of the project. The original code was 628 lines, while your pull request is 62 commits and ~1500 lines changed. That makes it hard to evaluate, especially since I can't actually run the code. Both times I gave up thinking I'd get to it later, but that obviously hasn't happened.

Greg mentioned he was going to look at it, and I'd be interested to hear his take. But I see from your comments on issue 80 that newer models may use yet another protocol. I'm wondering if it just makes sense to fork the library into different ones for different classes of machine. I'm perfectly happy to maintain a library that I use, but I'm not very excited about taking on responsibility for code I can't really verify. Especially since in some sense that would be free labor for Ecovacs, and I'm especially unexcited about helping out a for-profit company when I could be spending time on my own company.

Greg, what's your take?

Thanks,

William

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/sucks-users/dd43cc53-2641-43c8-b9f4-7a418bce91ea%40googlegroups.com.

[Greg Laabs]

I've got to say I feel exactly the same way. My biggest roadblock in reviewing the PRs for vacuums I don't have is that I'm really trying to review a black box.

In a perfect world I think we would change sucks to use a plugin architecture - sucks would provide the interface layer, and separately-developed and owned plugins could provide the support for the (now 3??) different communication protocols used across the different Ecovacs vacuums. The sucks code is actually already set up really well to make this possible with the way William separated the communication layer from the vacuum logic layer.

But the end result I'm looking for there is the same as William suggested: Splitting out to different repos so people with different vacuums can own and contribute wherever it makes sense.

Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/sucks-users/91ccc7d2-fd13-360f-7ddf-242336595784%40scissor.com.

[Brian Martin]

I like the idea of moving to a plugin architecture, I'm thinking about this for Bumper as well.  Are there any plugin frameworks you've worked with previously (pluggy / yapsy / etc)?

When I get some cycles I may do some research and mock this up for testing.  Maybe this becomes a Sucks2 project.

-Brian

On Tuesday, October 1, 2019 at 7:45:18 PM UTC-4, Greg Laabs wrote:

I've got to say I feel exactly the same way. My biggest roadblock in reviewing the PRs for vacuums I don't have is that I'm really trying to review a black box.

In a perfect world I think we would change sucks to use a plugin architecture - sucks would provide the interface layer, and separately-developed and owned plugins could provide the support for the (now 3??) different communication protocols used across the different Ecovacs vacuums. The sucks code is actually already set up really well to make this possible with the way William separated the communication layer from the vacuum logic layer.

But the end result I'm looking for there is the same as William suggested: Splitting out to different repos so people with different vacuums can own and contribute wherever it makes sense.

Greg

On Sun, Sep 29, 2019 at 10:30 PM William Pietri <wil...@scissor.com> wrote:

Hi, all. Brian, sorry for the lack of action on this. For me, the TL;DR is that my dad got a brain tumor, had extensive treatment, and eventually died from it. And in the last month or so, I've been trying to start a company. This project has been unfortunately low on my priority list.

I did try looking at your pull request a couple of times. It's very large relative to the size of the project. The original code was 628 lines, while your pull request is 62 commits and ~1500 lines changed. That makes it hard to evaluate, especially since I can't actually run the code. Both times I gave up thinking I'd get to it later, but that obviously hasn't happened.

Greg mentioned he was going to look at it, and I'd be interested to hear his take. But I see from your comments on issue 80 that newer models may use yet another protocol. I'm wondering if it just makes sense to fork the library into different ones for different classes of machine. I'm perfectly happy to maintain a library that I use, but I'm not very excited about taking on responsibility for code I can't really verify. Especially since in some sense that would be free labor for Ecovacs, and I'm especially unexcited about helping out a for-profit company when I could be spending time on my own company.

Greg, what's your take?

Thanks,

William



On 9/28/19 6:58 AM, Brian Martin wrote:

William et al,

What is the current state of the project?  There are two pull requests (#63 / #61) that have been waiting for months to be merged.  There is lots of activity around them as they add support for newer bots and work well with the other automation projects like Hassio.

Are there users on this list with authority to merge and push the project forward?  I would like William to weigh in, but as a community we may need to consider alternatives.

Thoughts?

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sucks-users/dd43cc53-2641-43c8-b9f4-7a418bce91ea%40googlegroups.com.

--
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...@googlegroups.com.

[William Pietri]

Sorry, I replied to just one person, not the list. Here's what I wrote on 10/5.

---

I hadn't thought about a plugin approach, Greg, but I'm amenable to it. Could you say more about how you think it would work?

It seems to me like we have three main classes of user:

• CLI users
• People who use the library code to build their own stuff
• People who need an adapter for home automation software

I'm not 100% sure, but I think most people get the code via PyPI install, with a few going as far as a Github checkout. For the PyPI folks, were you thinking that they'd install sucks and get it with whatever the current plugins are already integrated? Or that they'd install a more robot-specific library (say, sucks-ecovacs-d-series) which would have sucks as a dependency? Or maybe some more complicated option?

Thanks,

William

To unsubscribe from this group and stop receiving emails from it, send an email to sucks-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sucks-users/06098cf9-9383-483c-bacc-20cfb3c3f319%40googlegroups.com.

[Greg Laabs]

Wow, it took me a while to get around to replying here.

In my personal brainstorming, here's what I came up with for what I think makes the most sense:

The sucks library becomes responsible for defining and maintaining the interface layer to Ecovacs vacuums. It also handles the authentication, listing vacuums on the account, etc.

But the code that actually talks to the individual vacuums lives in separate PyPi projects. Each of these modules could support one or more (or all!) vacuums. The sucks library would know which of these external libraries to use for each vacuum model, and toss out "Not Supported" exceptions when someone tries to load a vacuum that doesn't have a defined module.

This does put the onus of maintaining the master mapping of vacuum models to Python packages, but every other way I thought of doing this just makes it way too hard for developers to use the project.

So with this plan, here's what we would need to do up front:

1. Move the current code that talks to supported vacuums (N79, M80, etc) to a separate module

2. Change sucks to import that separate module and use it for a static list of known supported vacuums

Then, other people would:

1. Create a new Python module that adds support for a new vacuum module, and publish it on PyPi

2. Submit a PR to sucks that adds the mapping for the new vacuum by importing their new module

So, that's the idea. This is mostly inspired by the way Home Assistant very successfully works.

To view this discussion on the web visit https://groups.google.com/d/msgid/sucks-users/06098cf9-9383-483c-bacc-20cfb3c3f319%40googlegroups.com.

[William Pietri]

This makes a lot of sense to me, Greg. Thanks for the write-up.

I'll add a few minor notions:

Some common code clearly belongs with sucks. I'm not sure where code specific to a subset of plugins will go. E.g., common protocols, or perhaps stuff related to a complex feature, like maps. Maybe it all ends up in sucks, but I could imagine other projects.


I think it's fine that sucks has the master mapping, as that's easiest for users. But I'm concerned about the case of plugins that haven't reached maturity yet. Some possible solutions:

• a non-terrible way to include a plugin that isn't supported yet (e.g., --load-plugin /tmp/my-new-model)
  
• a --beta mode that activates support for modules that aren't yet ready for prime time, so users know what they're getting into
• Most error messages should point users to the plugin-specific repo, so that model-specific bugs get reported to the right people
• Some sort of command like "sucks bugreport" that dumps all the versions, anonymized config info, and maybe a detailed record of logging in and probing the vacuum connection

Splitting things out might be a good time to move this to some other repo. My N79 has been in service for 2 years and it's starting to sound rough. When it fails, I may replace it with something from another vendor, which would mean I couldn't test new code. Perhaps the solution is to create an organization on Github?

William

To unsubscribe from this group and stop receiving emails from it, send an email to sucks-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sucks-users/8b72fb15-0e8e-45b1-90f6-7f3c55080f6f%40googlegroups.com.