Segment material and orientation does not persist

[bort9]

Are you already using Valetudo?

Yes, for a long time

Your questions

Love the floor material customisation introduced in 2026.01.0, works great on the Dreame L10s PUH with my semi-uneven wooden floor.

After making some adjustments to the material type and orientation via the Valetudo web GUI to reflect the material type and orientation, it seems this keeps reverting to the prior state after a vacuum and mop cycle.

I've since tried upgrading the robot firmware from v1574 to v1633, updating Valetudo to latest 2026.02.0, neither of which seems to helped.

Any suggestions to where I can look next to make this change more permanent?

[Hypfer]

Yeah that seems to be a thing on all Dreames so far. They just decide to change it.

I did some digging to see if I'm doing something wrong, but that doesn't seem to be the case. At least I did not find anything after a few hours, which was when I decided that it is enough.

FWIW, this seems to also be an issue when running stock?
https://www.reddit.com/r/Dreame_Tech/comments/1pl6qky/l50_ultra_keeps_changing_floor_material/

Unfortunately no comments there.

I also tried reaching out to the dreame support, but they wanted me to share a video of the issue, which doesn't make sense, so I lost motivation there. But maybe you have more energy to get an answer out of them. If there even is one that is

[mafredri]

I created a bit of a silly work-around for this, because floor materials seem to apply until they are reset upon docking/map update.

On the robot, create /data/hack_set_floor_material.sh (chmod +x):

#!/bin/sh

set -e

set_floor_material() {
	segment=$1
	material=$2

	curl -s -X PUT \
		-H 'Content-Type: application/json' \
		--data-raw '{"action":"set_material","segment_id":"'"$segment"'","material":"'"$material"'"}' \
		'http://localhost/api/v2/robot/capabilities/MapSegmentMaterialControlCapability' \
		| grep -q OK
}

# Ensure the robot is docked.
if curl -s 'http://localhost/api/v2/robot/state/attributes' | grep -q '"docked"'; then
	# If no floor type is wood_horizontal, then the floor type has reset.
	if ! curl -s http://localhost/api/v2/robot/state/map | grep -q '"wood_horizontal"'; then
		# Set all non-tile segments to wood_horizontal.
		for i in 1 2 4 5 8 9 10; do
			set_floor_material $i wood_horizontal
		done

		# Set tile segments.
		for i in 3 6 7; do
			set_floor_material $i tile
		done
	fi
fi

Add to crontab (runs every minute):

# crontab -e

* * * * * /data/hack_set_floor_material.sh

You'll probably want to apply the crontab edit on every boot via /data/_root_postboot.sh too (but I didn't do that yet.

EDIT: For persistence, create a second file:

echo "* * * * * /data/hack_set_floor_material.sh" > /data/hack_set_floor_material.crontab

And add this to /data/_root_postboot.sh:

if [[ -f /data/hack_set_floor_material.crontab ]]; then
        (crontab -l | grep -v hack_set_floor_material; cat /data/hack_set_floor_material.crontab) | crontab -
fi

[ChrM3r]

Hey,

Thanks for the info. And especially for the idea of an automated solution.

I tried to come up with a different approach—for anyone who doesn’t want to write scripts on the robot. I set it up as an automation in Home Assistant. That’s easier for me to maintain.
Since the robot always updates the map or floor material when it returns from a cleaning run, I respond specifically to that event.
When its status changes to “Docked,” I wait two minutes, let it apply the map changes, and then send the floor material change requests via REST.

alias: "Dreame X40: Fliesen in Küche, Diele, WC erzwingen"
description: >-
  Setzt die Räume 1, 2 und 4 nach dem Reinigen wieder fest auf Fliesen, da
  Dreame sie nach jedem Reinigungslauf überschreibt.

triggers:
  - entity_id:
      - vacuum.valetudo_robi
    to:
      - docked
    trigger: state
conditions: []
actions:
  - delay: "00:02:00"
  - repeat:
      for_each:
        - 1
        - 2
        - 4
      sequence:
        - action: rest_command.valetudo_set_floor_material
          data:
            segment_id: "{{ repeat.item }}"
            material: tile
        - delay: "00:00:01"

And in my configuration.yaml I've setup the following:

rest_command:
  valetudo_set_floor_material:
    url: "http://192.168.1.111/api/v2/robot/capabilities/MapSegmentMaterialControlCapability"
    method: put
    content_type: "application/json"
    payload: '{"action":"set_material","segment_id":"{{ segment_id }}","material":"{{ material }}"}'

[q-wertz]

I thought I already posted this but maybe forgot to click "Comment" 😅

In the Telegram channel dust_announce a new firmware (v1782) release was announced for the X40 Ultra (and some others).

They come with an update to the obstacle avoidance model as well as probably logic changes.
I'd be curious of now the selected floor material actually sticks.

After upgrading, configuring the floor levels and running a clean, the floor material still resetted after docking... 😿

[Hypfer]

Can you try the latest nightly? I I think I might've found something that might be the cause.

[q-wertz]

Thank's for looking into it again.
Cannot test it this week as I'm away from home. Gonna report next week.

[q-wertz]

As far as I understood the latest release notes, that fix is already in 2026.07.0?

1. I updated and adjusted the segment materials.
   Yesterday the robot was manually triggered to perform a full clean. Today I saw, that the segment materials was resetted.
2. Today I again adjusted the segment materials, started a single room clean and aborted it after ~1 minute. Until now, the segment material persisted.

Fingers crossed I just did a mistake in 1. and the segment material now stays as it is. Thanks for fixing 😊

[justin-sleep]

On my X40, I set the segment materials after updating to the latest firmware + 2026.07.0. I checked today, and it looks like they have reset again