Different models have different features

[edenhaus]

Different models have different features and we want only activate features that the specified model supports.
On my knowledge there exist no way to ask the vacuum, which commands it supports. Correct me if I'm wrong :)

So we need to create our own knowledge-database. I was thinking of a json configuration file per model, so also other projects like https://github.com/mrbungle64/ecovacs-deebot.js can use these files.

But the big question is how we specify the layout.
@mrbungle64 @nickw444 and all others what do you think?

I would name the file on the device-class (e.g. yna5xi.json for the Deebot Ozmo 950)
Beside the more details in the comments below each file would contain the following:

• Name of model
• Protocol of the model:
  • MQTT/JSON
  • MQTT/XML
  • XMPP

[edenhaus]

Suggestion 1:
In addition to the general information I would add all supported commands in a dictionary:

{
  "name": "Deebot Ozmo 950",
  "protocol": "MQTT/JSON",
  "commands": [
    "getSpeed",
    "setSpeed": {
      "speed:": {
        "1000": "quiet",
        "0": "standard",
        "1": "max",
        "2": "max+"
      }
    }
  ]
}

The advantage is that we can specifies in detail, which command is supported and how the values map. E.g. there exists older models, which only support two fan speeds.
A disadvantage is that a user must know all available commands. Only advanced user can create/edit a model file

[mrbungle64]

Suggestion 1: In addition to the general information I would add all supported commands in a dictionary:

{
  "name": "Deebot Ozmo 950",
  "protocol": "MQTT/JSON",
  "commands": [
    "getSpeed",
    "setSpeed": {
      "speed:": {
        "1000": "quiet",
        "0": "standard",
        "1": "max",
        "2": "max+"
      }
    }
  ]
}

@edenhaus

I prefer this variant

The advantage is that we can specifies in detail, which command is supported and how the values map. E.g. there exists older models, which only support two fan speeds. A disadvantage is that a user must know all available commands. Only advanced user can create/edit a model file

I suspect that very few users would create such configuration files themselves.
For us, however, this variant would be the better choice, I think 😉

[nickw444]

Also prefer this variant as it creates less indirection/abstraction over the "features". One might argue defining "features" is a benefit, which it could be, but also introduces unnecessary complexity. I think this is a good starting point for supporting different models and doesn't differ all too much from what I would have expected if the supported commands per robot was written in Python rather than JSON.

[nickw444]

The question I do have though - if we anticipate these JSON definitions being used more broadly, then yes JSON SGTM, but in reality, if the sole consumer is this client library, then I think it might be unnecessary additional effort. @mrbungle64 are these something you'd definitely adopt in your library?

[mrbungle64]

The question I do have though - if we anticipate these JSON definitions being used more broadly, then yes JSON SGTM, but in reality, if the sole consumer is this client library, then I think it might be unnecessary additional effort. @mrbungle64 are these something you'd definitely adopt in your library?

@nickw444 @edenhaus

I cannot yet say whether I will adopt this.

I'm already using 2 different dictionaries in my projects.

The one in the library is more platform/hardware focused:
https://github.com/mrbungle64/ecovacs-deebot.js/blob/master/library/models.js
For example: does the model have mopping capabilities

In my ioBroker adapter project it is more (software) feature focused:
https://github.com/mrbungle64/ioBroker.ecovacs-deebot/blob/master/lib/deebotModel.js
For example: does the model have a specific function and is it implemented

The ioBroker adapter uses both dictionaries.
You can also explicitly enable or disable some of these features. Usually, however, this remains on the default setting which gets the info from the library. For example: clean speed (suction power) or does the model use V2 commands

This works quite well so far, but I'm open to start a new knowledge-database.
But it would definitely mean a lot of work 😉

[edenhaus]

Then I think we will start now with a library implementation for the models. Makes it easier to adopt it for changes in the early stages. When we have finalized the format, we can still think to export it as json and use it in all projects

[edenhaus]

Suggestion 2:
In addition to the general information we could add all supported features (like in the settings app):

{
  "name": "Deebot Ozmo 950",
  "protocol": "MQTT/JSON",
  "features": [
    "fan speed":[
      "quiet",
      "standard",
      "max",
      "max+"
    ],
    "water level": [
      "low",
      "medium",
      "high"
    ]
  ]
}

The advantage of this suggestion is that each user can with the help of the app create a model file.
Disadvantage is that we don't know exactly which commands are supported and how the attributes map. We need also to think that newer models support some _V2 commands and it's only a matter of time, that new models don't support anymore V1 commands.