Gestión nativa de las tarjetas de limpieza de los robots aspiradores

Solicitud de función
1

Objetivo

Permitir que Gladys gestione nativamente las zonas/estancias de un robot aspirador, para lanzar una limpieza dirigida por estancia desde la interfaz y las escenas — sin depender de un widget específico ni de la aplicación del fabricante.

Tras la conversación con @pierre-gilles, la solicitud se reformula: en lugar de un simple componente de widget « zonas clicables », se trata de añadir la noción de superficie de servicio (Service Area) en el corazón de Gladys, alineándose con el estándar Matter – Service Area cluster. El widget solo expondrá esta funcionalidad existente.

La necesidad

Hoy, la integración Roborock puede mostrar el mapa (a través de onWidgetGetImage), pero:

  • el mapa es una imagen fija: no hay forma de detectar un clic en una estancia;
  • no existe ninguna noción de estancia/zona en el núcleo de Gladys;
  • por lo tanto, es imposible lanzar un app_segment_clean dirigido desde Gladys, ni usarlo en una escena.

Propuesta (enfoque central, alineado con Matter)

1. Modelo de datos central

  • Un dispositivo aspirador puede declarar una lista de zonas de servicio (estancias), cada una con:
    • un identificador estable (segment_id / area_id),
    • un nombre (« Cocina », « Salón »…),
    • opcionalmente un mapa/planta de referencia (soporte para múltiples mapas / múltiples plantas).
  • Estas zonas son reportadas por la integración (Roborock, Dreame…) y almacenadas en Gladys, siguiendo el modelo del cluster Matter Service Area (SupportedAreas, SelectedAreas, CurrentArea).

2. Selección y comando

  • Desde el panel del aspirador: selección de una o varias estancias, luego « Lanzar la limpieza ».
  • La integración traduce la selección en un comando nativo (app_segment_clean para Roborock, equivalente de Dreame…).

3. Escenas

  • Una acción de escena « Limpiar la/las estancia(s) X » utilizando las zonas declaradas (ej. « limpiar la cocina a las 9h »).

4. Widget

  • El widget del mapa muestra las zonas declaradas y relaya la selección (ej. a través de onWidgetAction) hacia esta funcionalidad central — ya no lleva la lógica de negocio.

Puntos a especificar / preguntas abiertas

  • Múltiples mapas / múltiples plantas: cómo modelar varios mapas por dispositivo.
  • Sincronización de los segmentos: los identificadores de las estancias pueden evolucionar en el lado del fabricante (re-mapeo) → estrategia de actualización/reconciliación.
  • Nombrado: nombres importados de la nube del fabricante vs nombres definidos en Gladys.
  • Interfaz de mapa: mostrar las zonas sobre la imagen decodificada, o conformarse con una lista de casillas de verificación en un primer momento (MVP).
  • Mapeo Matter: qué atributos/comandos del cluster Service Area se exponen exactamente.

Propuesta de alcance MVP

  1. Reportar la lista de estancias por la integración Roborock.
  2. Almacenamiento central de las zonas + selección múltiple en el panel del aspirador.
  3. Comando app_segment_clean en la selección.
  4. Acción de escena equivalente.

(El mapa interactivo y las múltiples plantas vendrían en una segunda fase.)

Mockup (casa genérica) de la experiencia objetivo:

mcp-Claude_Browser-blob-1791199649869-71lc41
mcp-Claude_Browser-blob-1791199649869-71lc41800×1013 55.4 KB

2

Hola @spenceur,

¡Gracias por la solicitud y el boceto! La necesidad es real y coincide con lo que está pasando en Dreame: Robots aspiradores: una línea de control completa en la caja Appareils.

En lugar de zonas clicables genéricas en los widgets, propongo:

  1. La selección de habitaciones se convierte en una funcionalidad central del aspirador, alineada con el clúster Matter Service Area: las habitaciones se declaran por dispositivo, se seleccionan varias, y « Iniciar » lanza la limpieza. Funciona para Roborock, Dreame y Matter, en el panel del aspirador y en las escenas.
  2. Tu widget simplemente muestra esta funcionalidad: la refieres como una baldosa value hoy, y Gladys dibuja las pastillas de habitaciones. La selección se comparte en todas las pantallas.
  3. El mapa sigue siendo una image: como tu integración recibe la selección, puedes dibujar las habitaciones seleccionadas encima.

Esto afecta al modelo de datos, por lo que habrá que empezar haciendo una especificación limpia :slight_smile:

3

¡Vaya un tema MUY interesante!!! :grinning_face:

4

Eso sería genial. ¿Dónde puedo votar? Estoy a favor…

5

aquí a nivel del título :wink:

image
image130×112 1.89 KB

6

:slight_smile: lo tenéis muy bien escondido… gracias

7

@spenceur he actualizado el título de la solicitud, ¿te parece bien? ¿Podrías modificar el contenido de la solicitud? :slight_smile:

8

Estoy un poco liado con un proyecto de un cliente, pero lo miro en cuanto tengo 10 minutos.

9

@pierre-gilles he actualizado el contenido de la solicitud según tus comentarios: la propuesta ahora se centra en una gestión nativa de las zonas/estancias en el corazón de Gladys, alineada con el clúster Matter Service Area, con el widget que solo expone la funcionalidad. He añadido una sección «Puntos a especificar / preguntas abiertas» y una propuesta de alcance MVP. Dime si te parece bien, o si prefieres que vaya hasta una verdadera especificación detallada.