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!

2

Thanks for the topic @guim31 :slight_smile:

I’m looking into all of this.

3

Thanks @guim31 for this very precise feedback: I checked each point in the code and your diagnostics are all correct :+1:

I opened an issue for each confirmed bug:

- Issues · GladysAssistant/Gladys · GitHub widget buttons in dark mode.

- Issues · GladysAssistant/Gladys · GitHub secret field in an action

- Issues · GladysAssistant/Gladys · GitHub default of action fields never applied

- Issues · GladysAssistant/Gladys · GitHub vacuum lists that ignore supported_options

Claude will propose a fix automatically tonight for each ticket so no need to make PRs :wink:

Great idea! I’d be happy if you created a specific feature request :slight_smile: And with pleasure if you want to make a PR :wink:

4

Thanks @pierre-gilles for the reactivity and the issues :folded_hands: I’m creating the feature request for the vacuum cleaner card, and I’m starting the PR.

A question about the last point, which had no issue: when a feature is the only one of its type, the dashboard displays the type label (« Doudou (Text) ») instead of the published name (« Doudou (Error) »). Is this intentional? For external integrations, which choose their own names, the published name would be more meaningful.

5

I’ll bounce back on the subject, it’s great to create a special robot widget, but couldn’t we give access to external integrations to create widgets with more possibilities such as dropdown lists, selectors, sliders, more images, more text, more buttons, etc.