OZMO 950: cleanstatus="unknown" (#32 aus Adapter)

[mrbungle64]

@boriswerner Issue aus ioBroker Adapter

In der ecovacsMQTT_JSON wird der Eventname CleanState ansatt CleanReport verwendet:

            case "cleaninfo":
                this.bot._handle_clean_info(event);
                this.emit("CleanState", this.bot.clean_status);
                break;

[mrbungle64]

In der vacBot_950type funktioniert die _handle_clean_info() auch ein bisschen anders als die _handle_clean_report() aus vacBot_non950type. Da wird vacuum_status bzw. clean_status das zugewiesen, was im Adapter in "info.deviceStatus" geschrieben wird.

 _handle_clean_info(event) {
    this.vacuum_status = 'unknown';
    tools.envLog("[VacBot] _handle_clean_info");

    if (event['resultCode'] == '0') {
      if (event['resultData']['state'] === 'clean') {
        if (event['resultData']['trigger'] === 'app') {
          if (event['resultData']['cleanState']['motionState'] === 'working') {
            this.vacuum_status = 'cleaning';
          } else if (event['resultData']['cleanState']['motionState'] === 'pause') {
            this.vacuum_status = 'paused';
          } else {
            this.vacuum_status = 'returning';
          }
        } else if (event['resultData']['trigger'] === 'alert') {
          this.vacuum_status = 'alert';
        }
      } else if (event['resultData']['state'] === 'idle') {
        this.vacuum_status = 'idle';
      }
    } else {
      this.vacuum_status = 'error';
    }
    this.clean_status = this.vacuum_status;
    return;
}

In "info.cleanStatus" vom ioBroker Adapter sollte der CLEAN_MODE landen:

exports.CLEAN_MODE_TO_ECOVACS = {
    'auto': 'auto',
    'edge': 'edge',
    'spot': 'spot',
    'spotArea': 'spotArea',
    //'single_room': 'singleroom', //REM
    'stop': 'stop',
    'customArea': 'customArea'
};

Ein weiteres Problem in der _handle_clean_info() bzw. _handle_clean_report() ist, dass ich aus dem Python Projekt noch den vacuum_status übernommen hatte. Der macht aber eigentlich keinen Sinn - den sollten wir erst mal streichen.

[mrbungle64]

@boriswerner Ich würde das jetzt mal aufräumen (inkl. 950er Code), wenn das für Dich ok ist.

Auch die angefangene Doku werde ich mal erweitern.

[boriswerner]

Gerne. Den und den Charge State hatte ich auch noch auf meiner Liste und wollte erstmal verstehen, wie die genutzt werden sollten. Ich hatte ja letztens schonmal nach dem device Status gefragt ;-) Clean Info hatte ich erstmal nur um funktionieren gebracht.

Ich hoffe du findest dich in den 950er Skripten noch zurecht. Ich hab da viel aufgeräumt und behandle nun auch die commandResponses auf gleichem Wege wie die incoming Messages. Bei den handle Methoden orientierte ich mich auch am Wording des 950 um das möglichst verständlich zu haben.

[boriswerner]

Hier noch einige Beispiel Antworten. Folgende Messages kamen als der Bot "Bereich ist blockiert, kehre zur Ladestation zurück" gemeldet hat: data:{"trigger":"workInterrupt","state":"idle"} data:{"trigger":"workInterrupt","state":"goCharging"}

Hier noch eine "normale" Reinigungsantwort: data:{"trigger":"app","state":"clean","cleanState":{"id":"122","router":"plan","type":"customArea","content":"-291.000000,111.000000,-250.000000,150.000000","count":1,"motionState":"pause"}}}

Und der idle state data:{"trigger":"app","state":"idle"}

Da wollte ich demnächst nochmal alle states durchtesten

[mrbungle64]

@boriswerner

ok, danke :+1: Ich mache mich da jetzt mal ran

[mrbungle64]

@boriswerner

Commits Library:

• Set event name CleanState to CleanReport because ...
• Remove vacuum_status property

Commit Adapter:

• Handle cleanstatus and deviceStatus of Ozmo 950 devices

Ich würde für die Library mal einen Release auf npm bauen und damit dann einen Release für den Adapter, da ich mit den Änderungen nur den aktuellen Stand zum Laufen gebracht habe (bzw. haben sollte) und dabei darauf geachtet habe, dass alles andere noch wie vorher funktioniert.

[boriswerner]

siehe meinen Kommentar im Adapter Issue... ist jetzt erstmal im Pull Request so wie dort angegeben.