@Flodo1987 sorry for the late replay I was quite busy and board in the last days for work related issues. The error you describe is probably related to the migration from valetudo to mqtt vacuum camera I would need more details to help you out. I assume the issue you reported did actually occured because you might first install 2024.06.4 and then 2024.07.0… as here is already 11 days that you reported this, can you please report this kind of issues on the GitHub page of the project? I’m mainly checking regularly that… and sorry for the inconvenience I assumed that the release notes was clear enough but I guess… this wasn’t remarked.
Dear All,
We did release the 2024.07.1 that will mainly fix some warning coming from HA. There was a deprecation warning related to the usage of async_forward_entry_setup and an warning that the camera took more than 3 second at startup, for this last a huge modification on the auto cropping function was made, we will store the cropping data so that we can re-init the auto_crop data with the stored data. As result the camera startup improve and the warning is gone for good after the second restart once installed this update.
Hope you will enjoy it 
Hi Sandro, I just had to redraw my map because I move the dock.
It worked in Valetudo:
But I seem to be missing half the image in mqtt camera:
All of the rooms are listed in the camera attributes:
friendly_name: robovac-downstairs Camera
supported_features: 1
access_token: 5c2f4d7fad85b9a36a848332f2f9da1e982e01e7f84df7e52d7c3fecc8576f98
model_name: MQTT Vacuums
brand: MQTT Vacuum Camera
vacuum_battery: 63%
vacuum_topic: valetudo/roborock_downstairs
vacuum_status: docked
snapshot: true
snapshot_path: /local/snapshot_roborock_downstairs.png
entity_picture: /api/camera_proxy/camera.robovac_downstairs_camera?token=5c2f4d7fad85b9a36a848332f2f9da1e982e01e7f84df7e52d7c3fecc8576f98
vacuum_position:
x: 2555
'y': 2579
angle: 186
in_room: Elect WS
json_data: Success
vacuum_json_id: edc6fe66-2efa-46e4-8b25-8071ed9c863b
calibration_points:
- vacuum:
x: 2245
'y': 1990
map:
x: 0
'y': 0
- vacuum:
x: 3444
'y': 1990
map:
x: 1199
'y': 0
- vacuum:
x: 3444
'y': 2759
map:
x: 1199
'y': 769
- vacuum:
x: 2245
'y': 2759
map:
x: 0
'y': 769
rooms:
'16':
number: '16'
outline:
- - 2780
- 2135
- - 2925
- 2135
- - 2925
- 2345
- - 2780
- 2345
name: Toilet
x: 2852
'y': 2240
'17':
number: '17'
outline:
- - 2785
- 2130
- - 3245
- 2130
- - 3245
- 2535
- - 2785
- 2535
name: Mech WS
x: 3015
'y': 2332
'18':
number: '18'
outline:
- - 2390
- 2205
- - 2785
- 2205
- - 2785
- 2625
- - 2390
- 2625
name: Elect WS
x: 2587
'y': 2415
'19':
number: '19'
outline:
- - 3495
- 2115
- - 3855
- 2115
- - 3855
- 2610
- - 3495
- 2610
name: Cinema
x: 3675
'y': 2362
'20':
number: '20'
outline:
- - 3245
- 2130
- - 3495
- 2130
- - 3495
- 2535
- - 3245
- 2535
name: Hall
x: 3370
'y': 2332
'21':
number: '21'
outline:
- - 3550
- 2025
- - 3745
- 2025
- - 3745
- 2135
- - 3550
- 2135
name: Landing
x: 3647
'y': 2080
Wow, this is the 2024.07.1 right? I think the image was draw completely can you please try to change the aspect ratio or check if any trim is on on the advanced options please and let me know.
This normally happens if the trim of the image is exceeding the image size.
If it isn’t the case I will try to reproduce the phenomena deleting the map and rescanning my flat.
edit:
A work around might be downgrade the camera to 2024.07.0. I think I will improve this in the next days.
Opened also an issue on the repo for this.
Correct.
I tried changing the aspect ratio, crop settings and even deleted the camera and re-added it. No change to the image (other than the room colours).
EDIT: AH! The log says:
This error originated from a custom integration.
Logger: mqtt_vacuum_camera
Source: custom_components/mqtt_vacuum_camera/utils/users_data.py:38
integration: MQTT Vacuum Camera (documentation, issues)
First occurred: 00:09:46 (62 occurrences)
Last logged: 09:42:29
File not found: /config/.storage/valetudo_camera/room_data_roborock.json
1 Like
In order solve the issue when “redrawing my map” and maintain the star-up improvement done on 2024.07.1 it is now available in the “Advanced option’s” of the Camera "Reset Map Trims option.
Once the option is selected is necessary to reload the Camera
This option is available in the 2024.07.2 released yesterday, thanks @tom_l the error you reported should be gone too, if not I will be glad to work on it 
1 Like
All good now. Thank you.
1 Like
Well not really 
I missed to update two files… so 2024.07.3 now available.
Everything is working again; I must have overlooked something as you said. It’s not a problem that you didn’t respond, as I didn’t have time to address it afterward anyway.
Thank you very much for your excellent work.
1 Like
Thanks to great cooperation with @tom_l, finally we are confident that the configuration of the colours of the cameras will work as is intended. 2024.07.4 was just released implementing the fixes for those issues.
Hopefully on the next releases we will able to improve more and more the code and docs.
Thanks to all of you, and @Flodo1987 you are really welcome
1 Like
Are these warnings coming from valetudo or mqtt_vacuum_camera?
Logger: homeassistant.components.mqtt.sensor
Source: components/mqtt/sensor.py:241
integration: MQTT (documentation, issues)
First occurred: 23 July 2024 at 11:04:14 (83 occurrences)
Last logged: 23 July 2024 at 13:27:24
Invalid undecoded state message 'b'96'' received from 'valetudo/roborock_downstairs/BatteryStateAttribute/level'
Invalid undecoded state message 'b'97'' received from 'valetudo/roborock_downstairs/BatteryStateAttribute/level'
Invalid undecoded state message 'b'98'' received from 'valetudo/roborock_downstairs/BatteryStateAttribute/level'
Invalid undecoded state message 'b'99'' received from 'valetudo/roborock_downstairs/BatteryStateAttribute/level'
Invalid undecoded state message 'b'100'' received from 'valetudo/roborock_downstairs/BatteryStateAttribute/level'
Logger: homeassistant.components.mqtt.mixins
Source: components/mqtt/mixins.py:441
integration: MQTT (documentation, issues)
First occurred: 23 July 2024 at 11:56:08 (1 occurrences)
Last logged: 23 July 2024 at 11:56:08
Erroneous JSON: b'{"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"}'
I think it is actually the camera the issue, for instance I’m trying to fix this on the camera see issue (# 216)[MQTT battery level as binary data. · Issue #216 · sca075/mqtt_vacuum_camera · GitHub]. Although it is a kind of strange… because the Camera get the corrected decoding, while MQTT is still having issue to convert the payload. I will try to get in contact with the Core guys as well. Anyhow will followup and hopefully we will get it fixed on the next release.
Edit: I think the payload of the Vacuums isn’t actually UTF-8… for instance this was I experienced using PAOH really at the beging.
After all I guess the Camera isn’t guilty, I made some modification and added more logging and the result is Camera receive the payload constantly as it is from MQTT, for instance in the last runs, bytes all the time. Meaning MQTT received bytes from the vacuums (payload base format). Unfortunately also if reported at Valetudo… the issue I created was simply “deleted” there (so no trace at all of it). MQTT sensors receive bytes, the camera althought decoded the data correctly.
1 Like
Oh so that’s what happened to the issue I created in the Valetudo repository. How rude. Also:
I might switch to the other fork of Valetudo.
@tom_l The point is: “as standard MQTT payload is and must be binary” … So the problem is when the sensors are expecting an integer instead for the battery state… well HA MQTT.sensor should not decode the data in the proper way?.. or the integration must manage for it? As the sensors are defined in Vacuums firmwares… that provide a payload battery state… and a sensor for HA (that by the way MQTT Explorer plot as integer all the time also when occurs the warning).
A payload is just a payload = bytes… so HA MQTT should not be so sensible to that b’100, and MQTT.sensor should convert as we do in the Camera the b’100 in 100%… I could overwrite the sensors of the vacuums with the corrected values and solve this issue but publishing the value… well, we send binary data as it would be a payload.
I also considered and therefore opened an issue on my side… because as subscriber of those topics the Camera (normally) should not create the problem, but as python use pointers to location’s in memory I wanted to make sure that the data conversion done on the Camera had no influences. And now, I’m fully convinced, the Camera wasn’t and will never be the problem.
So it is a Home Assistant issue?
Could you please provide a link? I had my own experiences, similar to this, and would be great, if I could change! Thanks!
It’s here: GitHub - rand256/valetudo: Valetudo RE - experimental vacuum software, cloud free
Not recommended though. Last update was 10 months ago.
1 Like
Thanks, that’s the problem with these forks. 
Another problem, for another time… Valetudo is running, and I have more than enough things, I could make better in my installation. As long as it runs. But I won’t donate again! 
Me either.
1 Like