Publica 4 widgets (el robot con el mapa de la vivienda, una limpieza express, un ajuste en botones, el mantenimiento) y la capacidad funciona muy bien, gracias . Tres temas:
1. Error: en modo oscuro, un botón de widget destacado ya no se distingue
Causa, en front/src/components/boxs/external-widget/style.css: la regla :global(.dark-mode) .button (dos clases) prevalece sobre .buttonPrimary, y no existe ninguna regla oscura para este estilo, aunque el tema Horizon tiene las suyas (:global(.glass-theme) .buttonPrimary…). Por la misma lógica, el estado activo de los botones device_feature (.buttonActive) y .buttonDanger también deberían verse afectados (deducido del CSS, no observado).
Corrección propuesta: reglas :global(.dark-mode) .buttonPrimary, .buttonActive y .buttonDanger (y su .buttonIcon), colocadas después de la de .button. Puedo hacer la PR.
2. Las configuraciones, y la idea de una tarjeta « aspiradora » en el núcleo
He tomado nota de que las listas y los controles deslizantes están excluidos de los widgets, por elección (« Fuera del alcance » de dashboard-widgets.md). Para ver, he hecho un widget que expone una configuración en fila de botones. El veredicto de Chris75 es claro: la caja Dispositivos, con sus listas y controles deslizantes, es más completa y compacta. Esto confirma la elección de la especificación.
Sin embargo, él reclama lo que realmente falta: una tarjeta completa por robot, « útil para todos los robots ». Hoy necesita el widget de la integración (mapa, estado) más una caja de Dispositivos de 8 a 19 líneas (modo, aspiración, ruta, humedad, frecuencia de lavado, selección de habitaciones…).
Propuesta, en el espíritu de la agrupación de las luces (buildDeviceRows, device-features/light/): en la caja de Dispositivos, agrupar las funcionalidades vacuum-cleaner de un mismo dispositivo en una sola línea. Tendríamos un icono teñido según el estado, el nombre, el estado en tiempo real, los botones de inicio/pausa y base, y un panel que abre las otras funcionalidades elegidas del dispositivo con sus controles nativos. Sería genérico: la categoría ya sirve a Matter (#2516) y las integraciones externas Roborock y Dreame.
Otra pista, si la prefieres: un componente de widget que muestra las líneas nativas del núcleo (DeviceRow) de las funcionalidades de la integración en sí. El widget del robot llevaría entonces sus configuraciones, siempre dibujadas por Gladys.
¿Cuál te parece la buena dirección? Prepararé la PR una vez validada la dirección.
3. Pequeños errores del núcleo encontrados en el camino (verificados en master el 02/10)
Campo secret en una acción: imposible de ingresar. ActionsCard.jsx pasa touchedSecrets={{}} a ConfigField, que muestra touchedSecrets[clave] ? valor : '': el ingreso se borra con cada tecla. Tuve que pasar la contraseña como string.
El default de los campos de acción nunca se aplica, ni en la visualización, ni en runAction del lado del servidor, aunque required se controla: se obtiene un 422 en un select que parece estar lleno.
Listas fijas de los aspiradores: VacuumCleanerCleanModeDeviceFeature siempre propone los 7 modos de limpieza, sin tener en cuenta los supported_options. Un robot con 4 niveles de aspiración muestra entonces opciones que no tiene, y tuve que publicar un text/select en su lugar. Lo mismo ocurre con el modo de funcionamiento, que siempre propone « Mapear ».
Etiqueta genérica: cuando una funcionalidad es la única de su tipo, getDeviceFeatureName muestra la etiqueta del tipo (« Doudou (Texto) », « Modo de funcionamiento ») en lugar del nombre publicado, excepto para MQTT (DISPLAY_FEATURE_NAME_FOR_THOSE_SERVICES). Las integraciones externas eligen sus nombres: ¿deberían añadirse a esta regla?
Puedo proponer rápidamente las PR del punto 1 y de los dos primeros errores del punto 3 si estás de acuerdo.
Gracias @pierre-gilles por la rapidez y los informes Creo la solicitud de funcionalidad para la tarjeta de la aspiradora y me pongo con la PR.
Una pregunta sobre el último punto, que no tuvo informe: cuando una funcionalidad es la única de su tipo, el panel de control muestra la etiqueta del tipo (« Doudou (Texto) ») en lugar del nombre publicado (« Doudou (Error) »). ¿Es intencionado? Para las integraciones externas, que eligen sus propios nombres, el nombre publicado sería más claro.
retomo el tema, está bien crear un widget especial para robots, pero ¿no podríamos dar acceso a las integraciones externas para crear widgets con más posibilidades como listas desplegables, selectores, controles deslizantes, más imágenes, más texto, más botones, etc.?
. Tres temas:
