Add support for set/getWashInfo commands and onWashInfo message

[lukakama]

On T20 Omni it is possible to control mops washing mode (with cold or hot water) and level (standard or deep washing).

These features are handled by getWashInfo and setWashInfo commands, with a push onWashInfo message which is sent when settings are changed.

The getWashInfo returns 3 different information:

• mode[int]: this is the wash mode; it corresponds to "hot water cleaning" setting in the app, which can be disabled (value 0) or enabled (value 1)
• hot_wash_amount[int]: this is the washing level of mops, as cycles of 3 water charges and discharges on the station; the app allows to select only 2 values, one for "standard" washing (value 1 - 3 water charges and discharges) and one for deep washing (value 3 - 9 water charges and discharges).
• interval[int]: this is the interval between two mop washings while mopping.

The app uses the setWashInfo command to distrincly set mops washing mode and level, passing only mode or hot_wash_amount with the desired value. The interval, instead, is set using a different command setWashInterval (handled in the PR #376).

Performing a setWashInfo command results in a onWashInfo message to be received from the MQTT server (with all the information of the getWashInfo command), regardless if setWashInfo is invoked passing only mode or only hot_wash_amount. The onWashInfo message is sent also when is performd a setWashInterval command.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 83.83%. Comparing base (e766567) to head (52f19e4). Report is 4 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #387      +/-   ##
==========================================
+ Coverage   83.30%   83.83%   +0.53%     
==========================================
  Files          74       78       +4     
  Lines        2977     3075      +98     
  Branches      531      541      +10     
==========================================
+ Hits         2480     2578      +98     
  Misses        443      443              
  Partials       54       54              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[lukakama]

Additionally, I used an Enum for mode, as, IMHO, the name seems much more related to a "washing mode" than to a "hot water washing on/off" option, where currently it is supported only "standard washing" and "hot water washing", and so, for future proof compatibility, an Enum allows to easily handle additional values. However, for the sake of simplicity, it can be changed to a bool "hot water on/off" value, but then, in case of future additional modes, a library (and library usages) refactor will be needed.

[lukakama]

UPDATE: I did some additional tests and I can tell that, when mode is set to 0, mops are always washed using a single wash cycle (3 charges and discharges of the station), regardless the value of hot_wash_amount, so it resemble even more that mode set to 0 correspond to a "Standard washing" (cold water with 1 cycle), and set to 1 correspond to a "Hot water washing" (Hot water with a configurable number of cycles).

[lukakama]

UPDATE: I just found that the library does not support multiple command classes mapped to the same MQTT command in p2p commands handling: https://github.com/DeebotUniverse/client.py/blob/bb19d12dcbff706985ac651787670b488d219435/deebot_client/mqtt_client.py#L259-L270

As it can be seen, the code look for a command class mapped to the MQTT command topic, but in the PR there are 2 classes, SetWashInfoMode and SetWashInfoHotWashAmount, mapped to the same setWashInfo MQTT command topic, and only one of them is added to the COMMANDS_WITH_MQTT_P2P_HANDLING mapping dictionary (I think that it depends on the order of class loading, where the last command loaded overwrite the previous and become the one used to handle p2p commands for that type). This then lead the code to raise an error when handling p2p setWashInfo commands when parameters does not match ones of the command class mapped into COMMANDS_WITH_MQTT_P2P_HANDLING in this method, as it would have only one of mode and hot_wash_amount parameters: https://github.com/DeebotUniverse/client.py/blob/bb19d12dcbff706985ac651787670b488d219435/deebot_client/command.py#L274-L284

@edenhaus I don't know how to proceed... It seems that to support this setWashInfo command with different parameters it is required some sort of refactor on other parts of the library which are currently quite complex for me to identify, and that will also depend on how this command handling will be implemented, between using two command classes vs using a single command class that, however, will have two mutually exclusive parameters... Maybe we should talk about it on discord to identify how this can be managed.

[edenhaus]

I think by merging both commands together I solved some issues you had. When executing the command the caller can decide to pass both or only one argument

[lukakama]

@edenhaus I refactored the code to work with a single command class, and thus I added a couple of tests for command execution, but it seems that the standard test assert_set_command does not handle well command with possible missing mqtt parameters (it rely on 1:1 relation between comand args and mqtt parameters). I don't know if it is just a test issue, or if it is something that could create issue at runtime. Do you have any hint on it? In case I could just change the test code in order to skip mqtt payload test.

[edenhaus]

I fixed it for you. First I added a default value to InitParam and afterwards I fixed the new command and the test for it