Multi-action grid widget implementation

[mrdanielps]

Summary

Adds a new widget that allows the user to configure multiple actions in a grid. It's somewhat based on the existing ButtonWidget.

The widget is responsive, adjusting the number of columns based on size, and becomes scrollable when it doesn't fit all the actions.

Fixes #1193, #4549

Screenshots

Dynamic colors - light

Dynamic colors - dark

API <31

Configuration and resizing

Screen_recording_20241102_185549.mp4

Link to pull request in Documentation repository

Documentation: home-assistant/companion.home-assistant#1132

Any other notes

I've limited the scope of this PR for easier review, hence the draft status, but I will update it based on feedback.
The main features I think are necessary before merging are auto-completion for icons and action data, feedback when the button is pressed, and maybe entity states.

Additionally, the existing button widget could be updated to reflect the UI changes and share some of their code. However, I didn't want to change too much considering a proposal exists to refactor this code (#4640).

[home-assistant]

Hi @mrdanielps

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[bgoncal]

Looking great! Will the state of each item reflect in realtime? for example if the light is ON

[mrdanielps]

Looking great! Will the state of each item reflect in realtime? for example if the light is ON

Not yet. As mentioned in the additional notes, I limited the scope of this PR for the initial review, just to get some feedback. Although looking at the entity widget implementation, I see it should be pretty straightforward to add, so I'll look into as soon as I can.

[bgoncal]

How often can a widget update in Android? In iOS the minimum auto-refresh is 15 minutes (besides other techniques like updating through push notification trigger)

[mrdanielps]

It's actually quite similar on Android. The fastest auto-refresh is 30 minutes, but AFAIK anything that wakes up the app can manually trigger an update, like broadcasts or push notifications. Widget interactions can also update it, so pressing the button will allow for the state to be updated immediately.

[dshokouhi]

The template widget updates instantly for me, there is no delay there. Our Template widget and entity state widget use a websocket subscription to update instantly.

[bgoncal]

@dshokouhi so you keep a websocket connection all the time for the widget? 🪫😭
(We do that in iOS for local push too hahaha)

[dshokouhi]

so you keep a websocket connection all the time for the widget? 🪫😭

For widgets only when the screen turns on, then we stop the connection when the screen turns off. Its our best effort to keep them as up to as possible while not draining too much battery

(We do that in iOS for local push too hahaha)

yup same for local push we never stop the connection and also send a ping to the server every 30 seconds to ensure its active and current.

[mrdanielps]

Looking great! Will the state of each item reflect in realtime? for example if the light is ON

Done!

Screen_recording_20241111_005218.webm

[dshokouhi]

does this need to be included in the common module? I dont seem to see it used in any common module files

[mrdanielps]

You're right, it's only actually needed in :app and :automotive. I've now moved the declaration to each module.

[dshokouhi]

Gave this PR a quick test run. I think you have captured the obvious missing features like auto complete, ideally the behavior for each action should mimic the existing button widget with how fields are populated. I think that will match general user expectation. For example that widget handles when a custom integration provides incomplete action data and also when a user provides invalid action data. Looking forward to seeing this PR progress!

[mrdanielps]

ideally the behavior for each action should mimic the existing button widget with how fields are populated. I think that will match general user expectation. For example that widget handles when a custom integration provides incomplete action data and also when a user provides invalid action data.

I see, I was thinking of implementing it like the entity widget, which only takes an ID, but I'll certainly take that into account.