@hayvan96 I think we can do it automatically from the camera, working on this implementation:
If all goes well this should simplify a lot the implementation and there should be no need to create an automation.
@hayvan96 the beta 2024.10.0b2 is now available, in theory this should automate and trigger the camera reset_trim as soon the vacuum get the start command.
I’ve tried it, it seems to work. I have to test on bigger areas, but it seems that it works as intended. Thank you!
Perfect thanks for trying it 
Hello Everyone
The vacuums Rand256 are not providing sensors data to home assistant, so in the release 2024.10.0 will introduce the sensors for Rand256 users. The camera startup was refactored and a beta 2024.10.0b3 have been release today.
This update also improved the code for the function introduced thanks @hayvan96 suggestion.
I would be testing this 2024.10.0b3 and report any unexpected behaviour would be really appreciated. Thanks as alway for the cooperation 
Hi, testing b3 here. Curiously, when I launch the robot in a closed room, it maps correctly but the framing is a bit weird.
Interesting… is it different from b2? I mean did it show before the closet without the empty space around? I think and repeat (as I see no dock there) it’s a really particular case of use, will have look at it but… I guess is normal as there is a min image size and the robot is changing orientation of the map.
Working fine here with my two S5 vacuums (Hypfer).
@tom_l thanks for confirming it this is super appreciated
You’re probably right, it’s very niche even for me, and it was similar with b2.
So it works perfectly!
build_full_topic_set for constructing MQTT topic sets.DECODED_TOPICS and NON_DECODED_TOPICS for MQTT topic management.sensor.py for improved measurement reporting.connector.py.strings.json and translations/en.json.camera.py and manifest.json.coordinator.py for broader error management.Side note: As always, would appreciate, when you like it please star it and feel free to contribute reporting issues or possible improvements 
This release goes out a little earlier as per I’m personally quite busy in the next days.
Just tested in my test environment, for the users of Pkoehlers maploader, on 2024.11.0 the integration will work with it. We did get the maploader status and when it will go from loading_map to idle the camera will automatically reset the images trims
This means that there will be no need to call the “action “ reset_trims anymore, as per it will run automatically each time the maploader changes the maps.
Some of you already probably download 2024.11.0, if so please re-download it as I made a small mistake corrected few minutes ago (sorry for that).
added vacuum Actions go_to, clean_zones and celan_segments (save an load maps for Rand256) and added also support for MapLoader, in order to simplify the scripts in Home Assistant. Each time the maps are re-load in the vacuums the camera reset_trims will be automatically triggered.
Thanks also to @Minims did add a temporary fix for the reported #263
As a side note, there could be some fix for this new function within the next week.
Dear All,
MQTT Vacuum Camera - Release 2024.12.0 is now available.
Local controlling the vacuums from Home Assistant is mainly our target, therefore thanks also to the hard and fantastic work of the creators of “Valetudo” as per was introduced already a couple of month ago the ObstacleImages, we did finally made possible to display the images directly in Home Assistant.
In this version we have a new service obstacle_view that using the Vacuum Api download the selected obstacle images… how it works is explained in the details in here
Did also somehow improve the Vacuum Error state “graphically” the vacuums will change colour to “Red” when in State error… here I would highlight also that once the vacuum is in error, idle or docked the camera entity can also acquire automatically snapshots (that honestly will improve later on with custom files save location and name). Anyhow to facilitate more the creation of new automation a “valetudo_error” event will be fired in the HA buss when there is a problem with the vacuums.
The next year to be honest I think would work mainly on maintaining this project meanwhile cleaning/refactoring the code.
This might result in releasing new version mainly to maintain compatibility with Home Assistant, there are a couple of “deprecated” python functions coming soon and some warnings (that you should see with 2024.11.1) will be, as are addressed too in this new release.
We are close to 1000 downloads and I would thanks all of you for the great communication and support also this year… your reports, proposals and why not stars… are really much appreciated.
Today released 2024.12.1 with some fix for:
In the last Released 2024.12.2:
With the above corrections, the Obstacles are now visible either when the vacuum is docked or while the vacuum is cleaning (would anyhow do not advice to render the obstacles while cleaning on <4gb systems). Later on will also remove from the state attributes the links to the obstacles images so please be aware of this in case you relay on it.
This would be all for this year, with the festivity coming soon and also some other staff to do, I will work out only future updates in case of possible braking out due to updates in Home Assistant / reported bugs / improvements. Mainly I will focus on refactoring the code in future, and close the open items.
I’ve been reported that the Obstacle View current implementation isn’t working in the case you use the basic auth valetudo offers… will dig on it, as this is a valid point. Meanwhile please do not hesitate to report any issues or advices will be more than happy to work with you and improve this custom component.
Dear All,
Happy New Year! 
Here’s a quick update on what’s happening behind the scenes:
We’re focusing on refining features to make the integration even more friendly:
In February, we plan to introduce:
In the future will try to found a way also to match the area name (in HA) with the room name (in the Vacuum), so that assist know better what we mean with “clean Nataly Room” or “this room” (the actual room where we are).
There will be less releases in 2025 but at each one will deliver some relevant change.. and as usual.. any “request” or “improvement” needed (bug report or real improvement) will be addressed timely, we are building this as community thanks to your inspired Contributions.
Latest update has introduced this error:
Logger: homeassistant.util.logging
Source: util/logging.py:95
First occurred: 09:37:25 (2 occurrences)
Last logged: 09:37:25
Exception in async_message_received when handling msg on 'valetudo/roborock_upstairs/MapData/segments': '{"16":"Laundry","17":"Dining","18":"Master Bedroom","19":"Wardrobe","20":"Hallway","21":"Bathroom","22":"Toilet","23":"Kitchen","24":"Lounge","25":"Ensuite","26":"Spare Bedroom","27":"Study"}' Traceback (most recent call last): File "/config/custom_components/mqtt_vacuum_camera/utils/MQTT/connector.py", line 398, in async_message_received await self.hypfer_handle_map_segments(msg) File "/config/custom_components/mqtt_vacuum_camera/utils/MQTT/connector.py", line 254, in hypfer_handle_map_segments await self._room_store.set_rooms( self._mqtt_segments ) TypeError: object NoneType can't be used in 'await' expression
Exception in async_message_received when handling msg on 'valetudo/roborock_downstairs/MapData/segments': '{"16":"Toilet","17":"Mech WS","18":"Elect WS","19":"Cinema","20":"Hall","21":"Landing"}' Traceback (most recent call last): File "/config/custom_components/mqtt_vacuum_camera/utils/MQTT/connector.py", line 398, in async_message_received await self.hypfer_handle_map_segments(msg) File "/config/custom_components/mqtt_vacuum_camera/utils/MQTT/connector.py", line 254, in hypfer_handle_map_segments await self._room_store.set_rooms( self._mqtt_segments ) TypeError: object NoneType can't be used in 'await' expression
I’m travelling and it’s a bit difficult to open an issue right now.
I think it was fixed a couple of days ago anyhow when the issue is still there please let me know. There was an “await” in a line that actually didn’t needed. Bad me …
HI Sandro, no I have not seen the issue since updating. Thanks.