The PR fails in CI, and something a bit complicated is going on I am afraid.

test_vacuum_records_group and test_vacuum_records_list fail because the RV30(UN) lacks the clean_percent component. The tests assume all vacuums support it, but my RV30 doesn't.

Also, adding "RV30" to VACUUMS_SMART also triggers test_update_module_query_errors failures.

This would happen for other vacuum models though: mine is the first vacuum fixture whose model name actually matches the patterns in VACUUMS_SMART (existing fixtures for the RV20 Max Plus and RV30 Max don't match "RV20"/"RV30" due to how the model name is parsed in

RV20 Max Plus(EU)_1.0_1.0.7.json                    file_model='RV20 Max Plus'
RV30 Max(US)_1.0_1.2.0.json                         file_model='RV30 Max'

per the logic in

The same errors here would be seen for the other robovacuum fixtures, if they matched the set in VACUUMS_SMART.
I am not attempting fixes here, but this would require work in other modules I guess.

@davidefiocco It seems that the RV30 builds components differently and connects differently than the RV30 MAX or RV20 MAX PLUS, things that we use modules to read are there, just in a different place or component. So, we will need to look at how to handle the shifts in module linking for the different devices since this model is new and the encryption is different as well.

Has this device been set up with the Tapo App, configured with the Cloud and had a firmware update done on it at all?

Hello @ZeliardM, thanks!

Has this device been set up with the Tapo App, configured with the Cloud and had a firmware update done on it at all?

Yes, to all three. Before tinkering with python-kasa I setup and use the device via the Tapo app, connect it to the internet so that I can start cleaning job when I am not home and also yes, I updated the firmware, even though I haven't kept track of what it originally came with before 1.2.2. Does it answer your questions?

@davidefiocco Yep, ok, so the fixture looks very different from the other vacuums. I'll need to look closer into it and see what we can get going. I'll more than likely setup another PR for all those changes, then I'll need to to pull everything and test it out, if you're ok with that?

Sure, happy to help! I will keep an eye on your updates here about this to see if the new PR gets referenced, keep me posted!

I regenerated the fixture so that now it contains a map. Some other parts have been shortened.

@davidefiocco Did you manually change anything or just run the dump again?

Hey @ZeliardM yes, thanks, you made me realize I had inadvertently patched the dump with the map data.
I am currently having issues in dumping the fixture with the map data (similarly to #1516), and the version of the fixture I had committed was the result of an experiment, but not a vanilla dump. I have reverted my commit to restore the fixture as it was before that mistake. Apologies!

@davidefiocco Hmm, ok. Not sure about the map data piece, but I still need to go through your fixture and figure out the other differences.

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
If you are the author of this PR, please leave a comment if you want to keep it open. Also, please rebase your PR onto the latest dev branch to ensure that it's up to date with the latest changes.
Thank you for your contribution!

Reopened, as it is still useful to have it in the collection. I have a rv20 max plus, that also might have an incomplete dump (or at least it also cleared the map) when dumping the fixture, the dumper exited with Device 192.168.xx.xx received unknown error code: -3016.

Fixture in #1721.