Add mop mode path width adjustment for Hypfer vacuums

[sca075]

• Path width adjusts to robot_size - 2 when mop_mode=True (default: 5px)
• Cache robot_size in ImageDraw for performance
• Update handler to use cached robot_size
• Test with mop_mode enabled in test.py

When mop mode is active, path width visually represents mop coverage area.

Summary by CodeRabbit

• New Features

  • Added wood and tile material colors to map visualization.
  • Introduced a mop mode toggle that adjusts path rendering width; path/robot rendering now respects reported robot size.
  • Map element colors now use a consistent, deterministic ordering for predictable visuals.

• Refactor

  • Removed a redundant image overlay routine to streamline rendering.

• Documentation

  • Project version and requirements updated in docs.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds named color indices and a curated public color array, extends COLORS with material entries (wood, tile), removes a material overlay helper, moves material overlay usage into drawing code, adds CameraShared.mop_mode, and makes path width and robot radius use image-provided robot_size.

Changes

Cohort / File(s)	Summary
Colors & Constants SCR/valetudo_map_parser/config/colors.py, SCR/valetudo_map_parser/const.py	Introduces ColorIndex(IntEnum) and public color_array; appends material_wood and material_tile to COLORS. Ensure enum order aligns with base_color_keys and consumers relying on numeric indices.
Material rendering SCR/valetudo_map_parser/config/material.py	Removed MaterialTileRenderer.apply_overlay_on_region. Confirm callers now use the updated overlay flow (tile_block usage) in drawing code.
Drawing & Image handling SCR/valetudo_map_parser/hypfer_draw.py, SCR/valetudo_map_parser/hypfer_handler.py, SCR/valetudo_map_parser/reimg_draw.py, SCR/valetudo_map_parser/rand256_handler.py	hypfer_draw uses ColorIndex for material colors and caches robot_size; path width calculation now depends on mop_mode. Several modules lowered info logs to debug. Verify path sizing, robot radius source (imd.robot_size) and material overlay invocation.
Shared config & utils SCR/valetudo_map_parser/config/shared.py, SCR/valetudo_map_parser/config/utils.py, SCR/valetudo_map_parser/config/drawable_elements.py	Added CameraShared.mop_mode: bool (default False); status text color selection switched to ColorIndex.TEXT; several toggling/info logs reduced to debug. Check propagation of mop_mode and updated color index usage.
Packaging & Docs README.md, pyproject.toml, SCR/valetudo_map_parser/__init__.py	Bumped package version and README requirements (Python 3.13, updated deps). Module version docstring updated. No functional code changes.

Sequence Diagram(s)

sequenceDiagram
    participant Caller as Caller
    participant Draw as HypferDraw
    participant Colors as ColorIndex/Colors
    participant Mat as MaterialTileRenderer
    participant Image as Image Pixels

    Caller->>Draw: request map render (segments, paths)
    Draw->>Colors: lookup material colors (MATERIAL_WOOD/TILE)
    Draw->>Mat: call tile_block() to generate material texture
    Mat-->>Draw: return material texture array
    Draw->>Draw: compute path width (robot_size, mop_mode)
    Draw->>Image: blend material texture into segment pixels (alpha)
    Draw->>Image: draw paths with computed width
    Image-->>Caller: rendered image

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• shared updated #21: Modifies CameraShared (adds battery state/is_streaming); related to mop_mode addition and shared-state changes.
• Implementing Materials detected from the Vacuums #41: Changes material/color handling and overlay implementation; directly related to ColorIndex and material overlay movement.
• rand256_fixes #26: Updates color/constants usage and initialization; overlaps with COLORS and color ordering changes.

Poem

🐰
I hop and paint the map anew,
Wood and tile now join the view.
Paths grow thin when mop’s in play,
Robot size leads the way.
Tiny paws, a brighter day.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Add mop mode path width adjustment for Hypfer vacuums' directly describes a key functional change in the PR—mop mode path width adjustment—which is implemented in hypfer_draw.py and shared.py with the addition of mop_mode attribute and dynamic path width computation.
Docstring Coverage	✅ Passed	Docstring coverage is 86.36% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

SCR/valetudo_map_parser/hypfer_handler.py (1)

262-273: Inconsistent robot_size patterns between handlers.
hypfer_draw caches robot_size at initialization (line 27), while reimg_draw reads directly from self.img_h.shared.robot_size on each use (line 343). If robot_size is updated dynamically via batch_update, the Hypfer handler won't reflect the change. Consider reading directly from shared like reimg_draw does, or adding a fallback:

Suggested fallback

                 radius=self.imd.robot_size or self.shared.robot_size or 25,

SCR/valetudo_map_parser/map_data.py (1)

878-890: Missing "materials" in update_from_dict allowed set.

The materials field was added to HyperMapData (line 805) and is handled in from_dict (line 869), but it's missing from the allowed set in update_from_dict. This prevents updating the materials field via this method.

🐛 Proposed fix

         allowed = {
             "json_data",
             "json_id",
             "obstacles",
             "paths",
             "image_size",
             "areas",
             "pixel_size",
             "entity_dict",
             "layers",
             "active_zones",
             "virtual_walls",
+            "materials",
         }

🤖 Fix all issues with AI agents

In `@SCR/valetudo_map_parser/config/material.py`:
- Around line 210-223: Remove the dead static method apply_overlay_on_region
from the Material class: it is unused and duplicates blending behavior
implemented in _apply_material_overlay in hypfer_draw.py; delete the entire
method definition (including its reference to MaterialTileRenderer.tile_block
and the mask-based assignment) to eliminate unused code and rely on the existing
alpha blending implementation instead.

🧹 Nitpick comments (2)

SCR/valetudo_map_parser/hypfer_draw.py (2)

136-139: Magic numbers for color array indices reduce maintainability.

Hardcoding indices 10 and 11 for wood and tile colors creates a fragile coupling. If base_colors_array order changes in colors.py, this code will silently use wrong colors.

Consider defining named constants (e.g., COLOR_INDEX_WOOD = 10, COLOR_INDEX_TILE = 11) in a shared location, or accessing colors by a more explicit mechanism.

♻️ Suggested improvement

+# At module level or in a constants file
+COLOR_INDEX_WOOD = 10
+COLOR_INDEX_TILE = 11
+
 # In _process_room_layer:
                         material_colors = MaterialColors(
-                            wood_rgba=self.img_h.shared.user_colors[10],
-                            tile_rgba=self.img_h.shared.user_colors[11]
+                            wood_rgba=self.img_h.shared.user_colors[COLOR_INDEX_WOOD],
+                            tile_rgba=self.img_h.shared.user_colors[COLOR_INDEX_TILE]
                         )

---

172-183: Potential out-of-bounds array access relies on exception handling.

The slice at line 181 (img_np_array[row : row + pixel_size, c_start:c_end]) may exceed image dimensions if pixels are near edges. While the except block catches this gracefully, it may degrade performance due to repeated exception throwing for edge pixels.

Consider adding explicit bounds checking before the inner loop:

♻️ Optional bounds check

             for x, y, count in pixels:
                 row = y * pixel_size
                 col = x * pixel_size
+                img_h, img_w = img_np_array.shape[:2]
                 for i in range(count):
                     c_start = col + i * pixel_size
                     c_end = c_start + pixel_size
+                    # Skip pixels that would exceed image bounds
+                    if row + pixel_size > img_h or c_end > img_w:
+                        continue
                     overlay = MaterialTileRenderer.tile_block(
                         tile, row, row + pixel_size, c_start, c_end
                     )

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

SCR/valetudo_map_parser/hypfer_draw.py (1)

419-433: Guard robot_size against None in mop-mode path width calculation.

If robot_size is None (when shared data is not initialized), self.robot_size - 2 will raise a TypeError. Consider a safe fallback to ensure path width is always valid.

🛠️ Suggested guard

-            if self.img_h.shared.mop_mode:
-                path_width = max(1, self.robot_size - 2)
-            else:
-                path_width = 5  # Default width
+            size = self.robot_size or 5
+            if self.img_h.shared.mop_mode:
+                path_width = max(1, size - 2)
+            else:
+                path_width = 5  # Default width

🤖 Fix all issues with AI agents

In `@SCR/valetudo_map_parser/config/colors.py`:
- Around line 5-6: ColorIndex values currently don't match the order that
initialize_user_colors() populates user_colors, causing misindexed colors; fix
by making initialize_user_colors() construct the user_colors list in the same
order as set_initial_colours() / base_color_keys: iterate base_color_keys (not
SupportedColor) and for each key look up the corresponding
SupportedColor/default value to append to user_colors so indices align with
ColorIndex, or alternatively remove usage of ColorIndex and switch all lookups
to enum-based access using SupportedColor; update references to user_colors,
ColorIndex and initialize_user_colors() accordingly to keep a single canonical
ordering.

♻️ Duplicate comments (2)

SCR/valetudo_map_parser/hypfer_draw.py (1)

135-139: ColorIndex ordering dependency (see colors.py comment).

This block relies on shared.user_colors matching ColorIndex. If that ordering diverges, material overlays will pick the wrong colors.

SCR/valetudo_map_parser/config/utils.py (1)

16-16: ColorIndex ordering dependency (see colors.py comment).

Status text color indexing will be wrong if shared.user_colors ordering doesn’t match ColorIndex.

Also applies to: 206-210