Does this work (or can this work) if valetudo is installed?

[nakermann1973]

This integration has far more features than Valetudo, but requires cloud access for the map data, and API access (which is only available when it is connected to Mi Home cloud).

Would it be possible to enable the relevant API since the robot is rooted? And could the map data be accessed through valetudo?

[Tasshack]

Valetudo stores map data in different format also has an mqtt api so your answer is no.

[nakermann1973]

Thanks for the quick reply. I suppose my question was more about API access than map access. Valetudo has a limited mqtt api, while you rely on the local api which seems to expose far more information. I am thinking that I should be able to get that running on my robot (since I already have access to it).

I will investigate a bit to see if I can find which process on the robot would run to expose that API - if I ever get time :)

[Zirafarafa]

Is valetudo stores map the data as is or its own format?

The map data I am referring to is the built-in robot map data. Valetudo reads this data to create its own map (as you say, every second)

App uses cloud as storage to access previously parsed partial frames to create a final map and thats why app and the integration cannot work without the cloud
I understand now. It looks like your code only reads the partial map data. I will look a bit at the format stored on disk to see if I can make sense of it..

[Tasshack]

This is where it gets the map data
https://github.com/Hypfer/Valetudo/blob/9662243d3884ad962a2b572996111aefb5f15dd1/backend/lib/robots/dreame/DreameGen2ValetudoRobot.js#L291

And this is where it parses the map data
https://github.com/Hypfer/Valetudo/blob/9662243d3884ad962a2b572996111aefb5f15dd1/backend/lib/robots/dreame/DreameMapParser.js#L36

But it does not store the original incoming data as is, which my integration actually needs.

If you can find a way to direct the incoming map data message to this integration then everyhing should work including P frame parsing.
I don't think the data is stored in this format anywhere else in the robot and can only be accessed through properties_changed event because data is stored in the device is different from the data has been sent to the cloud.

[Tasshack]

I was actually willing to add P frame support to the Valetudo but P frame parsing works by adding new integer values to the current pixel integers values for finding the latest value therefore it requires the latest raw byte pixel data to be stored which Valetudo does not do.

[Zirafarafa]

Ok thanks. I assume that the builtin dreame code is generating the map, emitting P and I frames to its cloud connection (which for me is valetudo), and writing the map data to disk (/data/map, /data/ri, etc). Valetudo is ignoring the P frames, parsing the I frames and generating its own map format.

I have just found https://github.com/sca075/mqtt_vacuum_camera which can create a "camera" entity in HA and thus allows https://github.com/PiotrMachowski/lovelace-xiaomi-vacuum-map-card to create a map from the Valetudo mqtt data.

This is missing all the interesting map data like detected objects/etc though. I will continue looking at the local map data on the robot to see what is being stored.

[Tasshack]

I think the only way for this integration to be working cloudless on a rooted device is to create a dummy miio server (like the valetudo does) on a machine other than the vacuum and redirecting all requests from vacuum to that local miio instead of cloud miio (like the valetudo does).
If someone creates a project that does that, I will be happily making changes to the integration for supporting it but I don't want to involve anything regarding Valetudo because I don't like its community and supporters.

[Zirafarafa]

Just a quick follow-up here.

I successfully set up the component in Manual mode against a Valetudo vacuum, using the IP and the token taken off the vacuum. For now the lack of map is not an issue, as I can access that via Valetudo

To get the token, I did the following:

$ ssh [email protected]
Enter passphrase for key '/home/chris/.ssh/id_rsa':
--------------------------------------------------------------
    _   _   _                        _     _
   / \ | |_| |__   ___ _ __   __ _  | |   (_)_ __  _   ___  __
  / _ \| __| '_ \ / _ \ '_ \ / _` | | |   | | '_ \| | | \ \/ /
 / ___ \ |_| | | |  __/ | | | (_| | | |___| | | | | |_| |>  <
/_/   \_\__|_| |_|\___|_| |_|\__,_| |_____|_|_| |_|\__,_/_/\_\

--------------------------------------------------------------
 Athena Linux (p2029_release)
--------------------------------------------------------------

built with dustbuilder (https://builder.dontvacuum.me)
2023-09-04T06:16:04Z
1138
[root@p2029_release:~]# cat /etc/miio/device.token | tr -d '\n' | xxd -p
5859584f<snip>275567a

[Tasshack]

Lack of map may not be issue for you but lots of functionality in the integration requires it.
I am not sure how usefull the integration will be without the map support.

[Tasshack]

Entities that are exposed are exactly same with the ones that Valetudo exposes. So i cannot understand what to gain here by doing all this.

[Zirafarafa]

Your integration exposes far more than Valetudo does, and does it in a much better way. For example, you use homeassistant notification for robot events (like stuck/wheels lifted/etc), and you expose all the vacuum-specific features, especially for the more advanced robots. Valetudo only exposes a small subset of vacuum features (* see below).

I am looking for a way to configure some of the advanced settings on my new vacuum. Thanks for the link to the xiaomi_miot addon - I have gotten it to connect to the devices - I will see what it exposes.

(*) Here are some example screenshots:

Valetudo:

dreame_vacuum:

[Zirafarafa]

Another thing which your integration seems far more likely to support is local access to the device camera. There is no way I would expose that to the cloud..

[Zirafarafa]

A further follow-up on my partial success:

Addon version 1.0.4

• L10 Pro (p2029) - successfully added.
• X40 Ultra (r2416) - "device not supported"

Addon version v2.0.0b15

• L10 Pro (p2029) - "failed to connect"
• X40 Ultra (r2416) - "failed to connect"

How can I help debug why the beta addon is unable to connect to the p2029 while v1.0.4 of the addon could?

[Tasshack]

Robot acts differently when it is installed to the Dreamehome app rather than Mi Home and newer vacuums cannot be installed to the Mi Home.

[Zirafarafa]

It sounds like when connected to the Dreamehome app, the robots disable the local miot connectivity.

If it is possible to reliably allow all three options (Mi Home, Dreamehome, local miot) for connectivity, that will at least allow me to create automations on various robot events that the valetudo integration is missing.

[Zirafarafa]

It looks like the code to add dreame cloud had an effect on local connection. With a bit of local hacking, I have it at a state where I am able to now also connect locally to my X40 Ultra (r2416/r2449a), and send commands to it.

[Tasshack]

If you are planning to use this integration just to send commands to the device, you should have a look at Miot Auto instead.

[Tasshack]

https://github.com/riboyama/dreame-vacuum/tree/valetudo-support