Got error when receiving timed out

In template:
Use miiocli device --ip <ip address> --token <token>.

But it’s gives an error:
Error: Missing command.

Correct comand:
Use miiocli device --ip <ip address> --token <token> info.

This issue is translated by DeepL from Chinese.

Describe the bug

When I try to control cuco.plug.v3 using this project, the following error is thrown:

pydantic.error_wrappers.ValidationError: 5 validation errors for DeviceModel
services -> 3 -> properties -> 0 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 3 -> properties -> 1 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 12 -> properties -> 0 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 12 -> properties -> 1 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 13 -> properties -> 0 -> gatt-access
  extra fields not permitted (type=value_error.extra)

I’ve never used pydantic, so I googled and found that this thing seems to include the ability to validate schema, so I tried removing all the gatt-access fields from the cache and after that it was back to normal and I could control my device normally.

Version information (please complete the following information):

• OS: Windows 11 22H2 and Rocky Linux 8.7
• python-miio: 0.6.0.dev0

Device information:

• Model: cuco.plug.v3
• Hardware version: ESP32C3
• Firmware version: 1.0.6

To Reproduce

Steps to reproduce the behavior:

All commands and api that use genericmiot.

Expected behavior

No exception are thrown.

Console output

ERROR:miio.click_common:Exception: 5 validation errors for DeviceModel
services -> 3 -> properties -> 0 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 3 -> properties -> 1 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 12 -> properties -> 0 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 12 -> properties -> 1 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 13 -> properties -> 0 -> gatt-access
  extra fields not permitted (type=value_error.extra)
Traceback (most recent call last):
  File "D:projectsremote-boot.venvLibsite-packagesmiioclick_common.py", line 54, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:projectsremote-boot.venvLibsite-packagesclickcore.py", line 1055, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "D:projectsremote-boot.venvLibsite-packagesclickcore.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:projectsremote-boot.venvLibsite-packagesclickcore.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:projectsremote-boot.venvLibsite-packagesclickcore.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:projectsremote-boot.venvLibsite-packagesclickcore.py", line 760, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:projectsremote-boot.venvLibsite-packagesmiioclick_common.py", line 314, in wrap
    result_msg = result_msg_fmt(**kwargs)
                 ^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:projectsremote-boot.venvLibsite-packagesmiiodevice.py", line 45, in _info_output
    dev = DeviceFactory.create(result.ip_address, result.token, force_generic_miot=True)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:projectsremote-boot.venvLibsite-packagesmiiodevicefactory.py", line 101, in create
    dev.info()
  File "D:projectsremote-boot.venvLibsite-packagesmiioclick_common.py", line 184, in _wrap
    self._fetch_info()
  File "D:projectsremote-boot.venvLibsite-packagesmiiointegrationsgenericmiotgenericmiot.py", line 344, in _fetch_info
    self.initialize_model()
  File "D:projectsremote-boot.venvLibsite-packagesmiiointegrationsgenericmiotgenericmiot.py", line 206, in initialize_model
    self._miot_model = miotcloud.get_device_model(self.model)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:projectsremote-boot.venvLibsite-packagesmiiomiot_cloud.py", line 66, in get_device_model
    return DeviceModel.parse_obj(spec)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "pydanticmain.py", line 527, in pydantic.main.BaseModel.parse_obj
  File "D:projectsremote-boot.venvLibsite-packagesmiiomiot_models.py", line 436, in __init__
    super().__init__(*args, **kwargs)
  File "pydanticmain.py", line 342, in pydantic.main.BaseModel.__init__
pydantic.error_wrappers.ValidationError: 5 validation errors for DeviceModel
services -> 3 -> properties -> 0 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 3 -> properties -> 1 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 12 -> properties -> 0 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 12 -> properties -> 1 -> gatt-access
  extra fields not permitted (type=value_error.extra)
services -> 13 -> properties -> 0 -> gatt-access
  extra fields not permitted (type=value_error.extra)

Is your feature request related to a problem? Please describe.
It is possible to have some type of release schedule for minor updates like bug fixes and new simple devices?

Describe the solution you’d like
A once in month minor release would be nice to have.
But I don’t trying to push you, and life sometimes hits hard, take your time.

Additional context
it’s 5 months from last public release. And there was same type of a problem already #1463

Hi,
I’ve got a couple of Xiaomi G1 vacuums, which I can connect to via the python-miio CLI, but I can’t figure out how to use the API.
Even a basic bit of code from the docs:

from miio import DeviceFactory

dev = DeviceFactory.create("192.168.x.xxx", "my-token-here")
print(f"Status: {dev.status()}")

Returns the following:

Traceback (most recent call last):
  File "c:pythontestxiaomitest.py", line 2, in <module>
    from miio import DeviceFactory
  File "C:UsersUserAppDataRoamingPythonPython311site-packagesmiio__init__.py", line 12, in <module>
    from miio.device import Device, DeviceStatus  # isort: skip
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:UsersUserAppDataRoamingPythonPython311site-packagesmiiodevice.py", line 8, in <module>
    import click
ModuleNotFoundError: No module named 'click'

I’ve also had a look at #817, but that seems to be designed for HomeAssistant, so package names/locations don’t match up.

UPDATE:
Actually persevered and can get the model returned with this:

from miio.device import Device 
dev = Device("192.168.x.xxx", "my-token-here")
print(f"Status: {dev.model}")

Although that is on linux, Windows seems to still generate the errors above.
So, probably still need help/advice, but will also keep on prodding the code

Thanks,
Richie

It would be useful to allow creating device instances directly from the cloudinfo objects to make the onboarding simpler.
This could be done either by adding a new method to the cloudinfo class, or alternatively allow passing a cloudinfo object to devicefactory.

Spotted in #1717 (comment)

Device information:

• Name(s) of the device: Dreame D10Plus
• Link: https://www.amazon.fr/gp/product/B09TWBQH53

Use miiocli device --ip <ip address> --token <token> info.

• Model: dreame.vacuum.r2205
• Hardware version: Linux
• Firmware version: 4.1.8_1078

Additional context

• In full charge and no activity:
  miiocli dreamevacuum —ip —token status

  WARNING:miio.device:Found an unsupported model ‘dreame.vacuum.r2205’ for class ‘DreameVacuum’. If this is working for you, please open an issue at https://github.com/rytilahti/python-miio/
  WARNING:miio.miot_device:Unable to find mapping for dreame.vacuum.r2205, falling back to dreame.vacuum.mc1808
  ERROR:miio.integrations.vacuum.dreame.dreamevacuum_miot:Unknown ChargingStats (0)
  ERROR:miio.integrations.vacuum.dreame.dreamevacuum_miot:Unknown model for cleaning mode (dreame.vacuum.r2205)
  ERROR:miio.integrations.vacuum.dreame.dreamevacuum_miot:Unknown FaultStatus (100)
  ERROR:miio.integrations.vacuum.dreame.dreamevacuum_miot:Unknown OperatingMode (None)
  Battery level: 13
  Brush life level: None
  Brush left time: None
  Charging state: None
  Cleaning mode: None
  Device fault: None
  Device status: Sweeping
  Filter left level: None
  Filter life level: None
  Life brush main: None
  Life brush side: None
  Life sieve: None
  Map view: None
  Operating mode: None
  Side cleaning brush left time: None
  Side cleaning brush life level: None
  Time zone: None
  Timer enabled: None
  Timer start time: None
  Timer stop time: None
  Voice package: None
  Volume: None
  Water flow: None
  Water box attached: None
  Cleaning time: None
  Cleaning area: None
  First clean time: None
  Total clean time: None
  Total clean times: None
  Total clean area: None

• At 92% of charge and in cleaning mode:
  miiocli dreamevacuum —ip —token status

  WARNING:miio.device:Found an unsupported model ‘dreame.vacuum.r2205’ for class ‘DreameVacuum’. If this is working for you, please open an issue at https://github.com/rytilahti/python-miio/
  WARNING:miio.miot_device:Unable to find mapping for dreame.vacuum.r2205, falling back to dreame.vacuum.mc1808
  ERROR:miio.integrations.vacuum.dreame.dreamevacuum_miot:Unknown ChargingStats (0)
  ERROR:miio.integrations.vacuum.dreame.dreamevacuum_miot:Unknown model for cleaning mode (dreame.vacuum.r2205)
  ERROR:miio.integrations.vacuum.dreame.dreamevacuum_miot:Unknown FaultStatus (92)
  ERROR:miio.integrations.vacuum.dreame.dreamevacuum_miot:Unknown OperatingMode (None)
  Battery level: 1
  Brush life level: None
  Brush left time: None
  Charging state: None
  Cleaning mode: None
  Device fault: None
  Device status: Idle
  Filter left level: None
  Filter life level: None
  Life brush main: None
  Life brush side: None
  Life sieve: None
  Map view: None
  Operating mode: None
  Side cleaning brush left time: None
  Side cleaning brush life level: None
  Time zone: None
  Timer enabled: None
  Timer start time: None
  Timer stop time: None
  Voice package: None
  Volume: None
  Water flow: None
  Water box attached: None
  Cleaning time: None
  Cleaning area: None
  First clean time: None
  Total clean time: None
  Total clean times: None
  Total clean area: None

Device information:

• Name(s) of the device: Xiaomi WalkingPad A1 Pro
• Link:

Use miiocli device --ip <ip address> --token <token>.

• Model: ksmb.walkingpad.v1
• Hardware version: MTK7697
• Firmware version: 2.0.5

Additional context

Expose DeviceInfoUnavailableException directly through miio module, and check also that other exceptions are exposed properly.

Model: yeelink.light.colorb
Hardware version: esp8266
Firmware version: 2.0.8_0010

All features work correctly

Hi guys, I’m new at this smart home world.

I would like to know how can I update my home assistant to use the git master from this repo instead of the last version 0.5.12?

Currently I’m getting on Home Assistant:

2023-02-01 01:32:52.825 WARNING (SyncWorker_1) [miio.device] Found an unsupported model 'dreame.vacuum.mc1808' for class 'RoborockVacuum'. If this is working for you, please open an issue at https://github.com/rytilahti/python-miio/
2023-02-01 01:33:08.875 ERROR (SyncWorker_1) [miio.miioprotocol] Got error when receiving: {'code': -9999, 'message': 'user ack timeout'}

I saw this issue which seems like the same problem.
I’m using this HA integration and I don’t know how can I update to master branch and see if it works.

Found an unsupported model ‘roborock.vacuum.a01’ for class ‘RoborockVacuum’. If this is working for you, please open an issue.

This is the Roborock E4. Not sure if there’s any other information you’d like.

Device information:

• Name(s) of the device: Xiaomi Smart Air Purifier 4

• Model: zhimi.airp.mp4

• Hardware version: esp32

• Firmware version: 2.2.1

Could not be used due to error:
Found an unsupported model ‘zhimi.airp.mp4’ for class ‘AirPurifierMiot’

Accessing choices_attribute of the enumsettingdescriptor may cause an exception.

DEBUG:miio.miioprotocol:192.168x.x:54321 >>: {'id': 207, 'method': 'get_multi_maps_list', 'params': []}
DEBUG:miio.miioprotocol:192.168x.x:54321 (ts: 2023-01-30 13:09:12, id: 207) << {'id': 207, 'result': 'unknown_method'}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/tpr/code/python-miio/miio/device.py", line 349, in sensors
    self._initialize_descriptors()
  File "/home/tpr/code/python-miio/miio/device.py", line 236, in _initialize_descriptors
    self._settings = self._setting_descriptors_from_status(status)
  File "/home/tpr/code/python-miio/miio/device.py", line 201, in _setting_descriptors_from_status
    setting.choices = retrieve_choices_function()
  File "/home/tpr/code/python-miio/miio/integrations/roborock/vacuum/vacuum.py", line 388, in _map_enum
    maps = self.get_maps()
  File "/home/tpr/code/python-miio/miio/click_common.py", line 185, in _wrap
    return func(self, *args, **kwargs)
  File "/home/tpr/code/python-miio/miio/integrations/roborock/vacuum/vacuum.py", line 380, in get_maps
    self._maps = MapList(self.send("get_multi_maps_list")[0])
  File "/home/tpr/code/python-miio/miio/integrations/roborock/vacuum/vacuumcontainers.py", line 112, in __init__
    for map in self.data["map_info"]:
TypeError: string indices must be integers

Originally posted by @rytilahti in #1701 (comment)

Before submitting a new request, use the search to see if there is an existing issue for the device.

Device information:

• Name(s) of the device: Mi Smart LED Ceiling Light 350mm
• Link:

Use miiocli device --ip <ip address> --token <token> info.

• Model: yeelink.light.ceil34
• Hardware version: esp32
• Firmware version: 2.1.7_0023

Additional context
If you know already about potential commands or any other useful information to add support for the device, please add that information here.

what must be done to reactivate this device?

#832

Write-only settings generate also setting descriptors with property names.
This is confusing as the property is not really available in the status container, causing KeyError on access.

Potential solutions:

• Add access information to the settings descriptor
• Set property to None and leave it for downstreams to check for that

This meta task will track the progress and tasks to do for the next major release, which aims to simplify the use of the library for downstream users and reorganize the organically grown code base to be more maintainable.

This issue will give an overview of the planned changes, which are discussed more in-depth under their corresponding issues linked below as they get written. This meta issue shall serve as a checklist for the changelog, and is open for discussions.

Repository structure

• Motivation: all source files are currently stored in the main miio directory for historical reasons, making it messy.
• Goal: by splitting each individual implementation (integration?) and files related to it (e.g., tests and some data files) will clean up the code base.

Tasks

• Separate integrations and their tests to their own directories under miio/integrations/<name> or miio/integrations/<type of device>/<name>. #1115
• #1696

«Device factory»

• Motivation: there is currently no way to construct device instances just by knowing their host and the token, making it necessary for downstreams to import the classes implementing the support and initializing it separately based on model information (or simply supporting a single implementation, like done by homeassistant’s vacuum platform).
• Goal: allow initializing device-derived objects by simply knowing their host and the token which simplifies downstream implementations.

Tasks

• Add manifest files to integrations that describe supported models (miIO.info-based and mDNS entries) #1116
• Add facilities to access information about supported devices, and initialize implementations by using only the host and the token #1117

Common APIs

• Motivation: adding support for devices of the same device class (e.g., vacuums) is cumbersome as there is no well-defined API among the different implementations.
• Goal: provide device-type based base classes to make adding support for new device integrations on downstream just a matter of upgrading the python-miio.

Tasks

• Create base classes for individual device types where it makes sense to make it easier for downstreams to add support for a class of devices.
  • Need replaced partially with introspectable interfaces: #1495
• Add model detection based on miIO.info to consolidate handling of device-specific differences inside a single integration. #1038
• Add supported_features or similar feature flags to allow integrations specify which features is supported by the device model. This will allow moving these checks from downstream (homeassistant most prominently) to where this information belongs.
  • Need replaced partially with introspectable interfaces: #1495
• Make available sensors introspectable (status class properties could be extended to allow defining metadata for available sensors). #1495
• Make available actions introspectable by exposing @commands.

MiOT support

• Motivation: all new devices are using miot instead of custom protocols to control devices, so it makes sense to add first class support to the library.
• Goal: all miot supporting devices can be controlled as long as internet-connectivity is available to fetch the required schema file.

Tasks

• Create generic miot integration #1581
• Provide consolidated information (including descriptions, icons, etc.) for standard settings and actions using a yaml metadata file: #1618
• Add support for actions with multiple input parameters (exposed as custom services in homeassistant?): #1663
• Add support for write-only properties (exposed as custom services in homeassistant?): #1662
• Clean up and deprecate old miot integrations that do not provide extra functionality compared to the generic interface

Other changes

• Clean-up constructors to use an «options» container instead of relying on separate kwarg arguments for special cases. #1156
• #1683
• Consolidate out-of-range input values to raise standard exceptions (e.g., ValueError instead of custom exception types) #1558
• Modify miiocli to save the «options» object much like mirobo does for sequence ids. This would fix the long-standing problems some users are having caused by the id reuse.

Move each integration to their own directory, containing the integration-specific implementation, data and test files.

This allows separate integrations to have their own data files stored without poluting the main package (see, e.g., #1094 for yeelight spec files), and make the integrations partially self-contained.
This also allows adding integration-specific, discoverable manifest files whose pros are discussed in another issue to be linked here.

Each integration should be stored under miio/integrations/<name> which can contain several source files including unit tests and any other data.

Status

• Yeelight (#1160)