"err_state"documentation?

[INPoppoRTUNE]

Is there any sheet to document the "err_state" status codes? I'd like to automatically dock and restart cleaning when the vacuum cleaner get lost, but apparently no other value seems to change other than "err_state".

Also, I'd like to know if, as asked in #18, those additional attributes are now reachable or it will still crash?

Thank you so much for this integration, I'm really enjoying it.

[jeremysherriff]

I've mapped out the err_state values to the English app wording here: https://gist.github.com/jeremysherriff/786457fd0bdbadf0a43d564889c17900

I define a Home Assistant command_line sensor that takes the err_state value as a parameter and gives a text return value like this:

sensor:
  - platform: command_line
    name: Bert Error Text
    command: /config/scripts/viomi_error_translation.sh {{ state_attr('vacuum.bert','err_state') }}
    scan_interval:
      hours: 1

Then I have an automation that calls the service homeassistant.update_entity whenever the err_state attribute value changes:

alias: Translate Bert error code into text
description: ''
trigger:
  - platform: state
    entity_id: vacuum.bert
    attribute: err_state
condition: []
action:
  - service: homeassistant.update_entity
    data: {}
    entity_id: sensor.bert_error_text
mode: single

(my vacuum is called Bert 🙂 )

Edit: Updated code link to a gist rather than my private repo

[INPoppoRTUNE]

Thank you so much Jeremy, that's an incredible valuable info to have!

Any news about those additional attributes?

[jeremysherriff]

Those additional attributes are not available on my vacuum, because mine is the Europe model that this repo was specifically designed for. I've never been fully satisfied that the models with these attributes are the same model.

Unless someone raises a Pull Request with complete and tested code, I doubt that the OP dev will have much interest in expanding the code to use attributes that his vacuum does not expose, and that he cannot test code against.

[INPoppoRTUNE]

I'll try dig a bit into this rabbit hole then. Thanks again for this porting, it's working wonderfully!

[jeremysherriff]

Hopefully exposing some new attributes will be simple enough, from my knowledge of the miiocli tools I think you will just need some if/then or error handling for the situation where the attributes are not available (like on my model).

If there is anything I can do to help, like providing specifics about model numbers or other attributes to help you with handling the different models, I'm happy to help. I'm also quite happy to test any code, either as part of a PR or before you raise a PR if you want some certainty that things are working OK.

It looks like the newer python-miio has broken compatibility with this vacuum, some commands work:

jeremy@tvbox:~$ miiocli viomivacuum --ip=192.168.220.133 --token=4c4d5a376f4f756953726dxxxxxxxxxx info
Model: viomi.vacuum.v8
Hardware version: Linux
Firmware version: 3.5.8_0017

and others do not:

jeremy@tvbox:~$ miiocli viomivacuum --ip=192.168.220.133 --token=4c4d5a376f4f756953726dxxxxxxxxxx status

Traceback (most recent call last):
  File "/usr/local/bin/miiocli", line 8, in <module>
    sys.exit(create_cli())
  File "/usr/local/lib/python3.8/dist-packages/miio/cli.py", line 63, in create_cli
    return cli(auto_envvar_prefix="MIIO")
  File "/usr/local/lib/python3.8/dist-packages/miio/click_common.py", line 51, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/miio/click_common.py", line 305, in wrap
    result_msg = result_msg_fmt.format(**kwargs)
  File "/usr/local/lib/python3.8/dist-packages/miio/integrations/vacuum/viomi/viomivacuum.py", line 338, in fanspeed
    return ViomiVacuumSpeed(self.data["suction_grade"])
  File "/usr/lib/python3.8/enum.py", line 339, in __call__
    return cls.__new__(cls, value)
  File "/usr/lib/python3.8/enum.py", line 663, in __new__
    raise ve_exc
ValueError: None is not a valid ViomiVacuumSpeed

[INPoppoRTUNE]

While digging I found out a possible missing piece:

• for the fan speed it expose suction_grade, settable through vacuum.set_fan_speed
• for the water dispensed it expose water_grade, but no service seems to be present to manually set this value.

I was playing with the Lovelace Vacuum Map card as I'd like to add a custom water icon, but without service I don't think it would be able to do anything.

Reference.

[INPoppoRTUNE]

It looks like the newer python-miio has broken compatibility with this vacuum, some commands work:
and others do not:

As promised I tried to dig the rabbit hole as soon as some free time showed up. I built a custom container to run some environmentally independent tests, and as you wrote some commands work and others do not.

In any case it seems that consumable_status works correctly with my build and returns the desired values:

Running command consumable_status
<ViomiConsumableStatus filter=3 days, 11:00:00 filter_left=4 days, 1:00:00 main_brush=3 days, 11:00:00 main_brush_left=11 days, 13:00:00 mop=1 day, 11:00:00 mop_left=6 days, 1:00:00 sensor_dirty=0:00:00 sensor_dirty_left=0:00:00 side_brush=3 days, 11:00:00 side_brush_left=4 days, 1:00:00>

Full test log

Now I'd like to know what output will this command produce on your build (as you're on a newer firmware, not available for me atm):
miiocli viomivacuum --ip=192.168.XXX.XXX --token=YYY consumable_status

If you want to also try the docker build I'll send you the Dockerfile and the script.

[INPoppoRTUNE]

* for the water dispensed it expose `water_grade`, but no service seems to be present to manually set this value.

Also, regarding this issue, it seems to be possible to set the water grade through set_water_grade, that is not exposed on the Home Assistant end.

Edit: I can confirm that miiocli viomivacuum --ip=192.168.XXX.XXX --token=YYY set_water_grade [low, medium, high] is able to set the water level.

[jeremysherriff]

Yes I get data, but it's useless data that has no bearing on reality:

Running command consumable_status
<ViomiConsumableStatus filter=9 days, 0:00:00 filter_left=-2 days, 12:00:00 main_brush=9 days, 0:00:00 main_brush_left=6 days, 0:00:00 mop=0:00:00 mop_left=7 days, 12:00:00 sensor_dirty=0:00:00 sensor_dirty_left=0:00:00 side_brush=9 days, 0:00:00 side_brush_left=-2 days, 12:00:00>

My Mi Home app offers no data to compare, nor is there a way to reset a consumable when it has been changed.

Also, if you look at the python_miio code, you see that these attributes are just numbers that someone has decided to convert into days/hours (probably based on what their Mi Home app shows, but I am unable to confirm due to no such data exposed in the app). I've tracked these values in Home Assistant and for me they make no sense in a day/hour context, rather the raw values (raw_command get_consumables) seem to be a percentage that tracks downwards from 100 towards zero in a consistent manner based on vacuum run time:

Edit: Sorry, that graph is tracking a made-up value decrementing from an approximation, based on a friend's Xiaomi vacuum that uses the same consumables and does expose the consumables' life values.

I was tracking the raw consumables data, but stopped when it proved to show nothing useful - the data should still be in influxdb though, if I can find what I called it!

Edit2: Found it, and it's tracking in a similar way to what I described:

Since I changed HA integrations to an MioT-based one (something broke with this one), they natively expose the attributes as % based on the MioT spec, which aligns with my experiences:

However given that I don't have a way to reset the values when i change the brushes or filter, they are pointless for me.

[INPoppoRTUNE]

I've mapped out the err_state values to the English app wording here: https://gist.github.com/jeremysherriff/786457fd0bdbadf0a43d564889c17900

I define a Home Assistant command_line sensor that takes the err_state value as a parameter and gives a text return value like this:

sensor:
  - platform: command_line
    name: Bert Error Text
    command: /config/scripts/viomi_error_translation.sh {{ state_attr('vacuum.bert','err_state') }}
    scan_interval:
      hours: 1

Then I have an automation that calls the service homeassistant.update_entity whenever the err_state attribute value changes:

alias: Translate Bert error code into text
description: ''
trigger:
  - platform: state
    entity_id: vacuum.bert
    attribute: err_state
condition: []
action:
  - service: homeassistant.update_entity
    data: {}
    entity_id: sensor.bert_error_text
mode: single

(my vacuum is called Bert 🙂 )

Edit: Updated code link to a gist rather than my private repo

Hi Jeremy,
sorry to bother you again on this issue: I recently swapped my host machine, and this script seems not to be working anymore for me.

• /config/viomi_error_translation.sh is a copy-paste of your Git link;
• in my /config/sensors.yaml I pasted this code from the old configuration:

- platform: command_line
  name: alfred_error_text
  command: /config/viomi_error_translation.sh {{ state_attr( 'vacuum.alfred', 'err_state' ) }}
  scan_interval:
    hours: 1

• in my automations I pasted the old code:

alias: Alfred text error
description: ""
trigger:
  - platform: state
    entity_id:
      - vacuum.alfred
    attribute: err_state
condition: []
action:
  - service: homeassistant.update_entity
    data: {}
    entity_id: sensor.alfred_error_text
mode: single

Anything obviously wrong to your eyes or did this automation broke with updates?
Thanks for your time.

[jeremysherriff]

Hiya. There should be something in the System -> Logs (check both the Core and Supervisor logs, I can't recall which).
You should also be able to run the command yourself if you ssh into your HA instance, just provide some different numbers for the err_state parameter and see what happens.

[INPoppoRTUNE]

Hiya. There should be something in the System -> Logs (check both the Core and Supervisor logs, I can't recall which). You should also be able to run the command yourself if you ssh into your HA instance, just provide some different numbers for the err_state parameter and see what happens.

Nice suggestion the SSH one, didn't think about that.
The .sh file was missing execution permission, a simple chmod solved the problem. Thanks!