Dreame integration feedback: dark mode widgets, vacuum map, minor core bugs

Development
1

Hello @pierre-gilles,

Since the topic about integration widgets (Permettre aux intégrations de déclarer leurs propres widgets de dashboard (schéma JSON)) is closed, I’m grouping here some feedback and a few issues encountered while developing the external Dreame integration (vacuum cleaner robots). It is being tested in real life by @Chris75 on a dreame.vacuum.r2449a (Demande d'intégration externe pour robot aspirateur/laveur DREAME).

It publishes 4 widgets (the robot with the home map, a quick clean, a button setting, and maintenance) and the feature works very well, thank you :folded_hands:. Three topics:

1. Bug: In dark mode, a highlighted widget button is no longer distinguishable

  • Observation: In dark mode, a button with style: "primary" is painted like the others, its icon disappears, and the highlighted choice becomes invisible (screenshots from Chris75: Demande d'intégration externe pour robot aspirateur/laveur DREAME - #32 par Chris75).
  • Cause, in front/src/components/boxs/external-widget/style.css: the rule :global(.dark-mode) .button (two classes) overrides .buttonPrimary, and no dark mode rule exists for this style, although the Horizon theme has its own (:global(.glass-theme) .buttonPrimary…). By the same logic, the active state of device_feature buttons (.buttonActive) and .buttonDanger should also be affected (deduced from the CSS, not observed).
  • Proposed fix: Rules :global(.dark-mode) .buttonPrimary, .buttonActive, and .buttonDanger (and their .buttonIcon), placed after the .button rule. I can create the PR.

2. Settings, and the idea of a « vacuum » card in the core

  • I noted that lists and sliders are excluded from widgets, by design (« Out of scope » of dashboard-widgets.md). For testing, I created a widget that exposes a setting as a row of buttons. Chris75’s verdict is clear: the Devices box, with its lists and sliders, is more complete and more compact. This confirms the spec’s choice.
  • However, he requests what is really missing: a complete card per robot, « useful for all robots ». Today, he needs the integration widget (map, status) plus a Devices box of 8 to 19 lines (mode, suction, route, humidity, washing frequency, room selection…).
  • Proposal, in the spirit of grouping lights (buildDeviceRows, device-features/light/): in the Devices box, group the vacuum-cleaner features of the same device into a single line. We would have an icon tinted according to the status, the name, the live status, the start/pause and base buttons, and a panel opening the other chosen features of the device with their native controls. This would be generic: the category already serves Matter (#2516) and the external integrations Roborock and Dreame.
  • Another option, if you prefer: a widget component that displays the native core lines (DeviceRow) of the integration’s features. The robot widget would then carry its settings, always drawn by Gladys.
  • Which direction seems the right one to you? I will prepare the PR once the direction is validated.

3. Small core bugs encountered along the way (verified on master as of 02/10)

  • secret field in an action: impossible to enter. ActionsCard.jsx passes touchedSecrets={{}} to ConfigField, which displays touchedSecrets[key] ? value : '': the input is erased with each keystroke. I had to pass the password as a string.
  • The default of action fields is never applied, neither in display nor in runAction on the server side, although required is checked: a 422 is obtained on a select that seems to be filled.
  • Fixed lists of vacuum cleaners: VacuumCleanerCleanModeDeviceFeature always offers the 7 cleaning modes, without taking into account the supported_options. A robot with 4 suction levels therefore displays choices it doesn’t have, and I had to publish a text/select instead. The same goes for the operating mode, which always offers « Map ».
  • Generic label: when a feature is the only one of its type, getDeviceFeatureName displays the type label (« Teddy (Text) », « Operating Mode ») instead of the published name, except for MQTT (DISPLAY_FEATURE_NAME_FOR_THOSE_SERVICES). External integrations choose their names: should they be added to this rule?

I can quickly propose the PR for point 1 and the first two bugs of point 3 if you agree.

Thanks!