Skip to content

Conversation

@TimoPtr
Copy link
Member

@TimoPtr TimoPtr commented Aug 5, 2025

Summary

We want to make the native features of the companion apps more accessible to the user. When the user is going to click on Add to from the frontend it will display within the more info dialog the list of potential actions. This PR covers the needed change to react to this click on a action but also sending the list of potential actions, inform the frontend that we support this feature and expose a way to add an Android Auto favorite or a widget depending on the domain of the entity. Follow-up PRs are going to add shortcut, tile and watch favorite support.

Checklist

  • New or updated tests have been added to cover the changes following the testing guidelines.
  • The code follows the project's code style and best_practices.
  • The changes have been thoroughly tested, and edge cases have been considered.
  • Changes are backward compatible whenever feasible. Any breaking changes are documented in the changelog for users and/or in the code for developers depending on the relevance.

Screenshots

see home-assistant/frontend#26346

Link to pull request in documentation repositories

User Documentation: home-assistant/companion.home-assistant#1232

Any other notes

This features depends on the frontend, it will only work when this home-assistant/frontend#26346 is going to be merged.

Only the relevant actions based on the entity, are sent to the frontend.

@github-actions
Copy link
Contributor

github-actions bot commented Aug 5, 2025

Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 6354781.

♻️ This comment has been updated with latest results.

@TimoPtr
Copy link
Member Author

TimoPtr commented Aug 5, 2025

Screenshot are failing most probably because I've generated them on macOS and the verification runs on linux. You can see the diff
image

Once this PR have been reviewed I will either generate the image on linux or I will update the threshold to make the tests pass.

@TimoPtr TimoPtr marked this pull request as ready for review August 5, 2025 14:28
Copy link
Member

@jpelgrom jpelgrom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO you're trying to do a bit too much in one go here. The screenshot test is telling - it includes options that are not implemented - and there are actions with todo's in them.

@TimoPtr
Copy link
Member Author

TimoPtr commented Aug 6, 2025

This PR will be reworked since we are most probably move the UI on the frontend side. All the logic of this PR will be kept except that the frontend will send us an event with the entity_id to get the list of potential actions. Then the frontend will send us the action to execute (like we are doing in the dialog in the current state of this PR).

@jpelgrom
Copy link
Member

jpelgrom commented Aug 6, 2025

This PR will be reworked since we are most probably move the UI on the frontend side. All the logic of this PR will be kept except that the frontend will send us an event with the entity_id to get the list of potential actions. Then the frontend will send us the action to execute (like we are doing in the dialog in the current state of this PR).

OK, until that is decided (not sure where) and implemented this PR can be drafted then?

@TimoPtr
Copy link
Member Author

TimoPtr commented Aug 6, 2025

This PR will be reworked since we are most probably move the UI on the frontend side. All the logic of this PR will be kept except that the frontend will send us an event with the entity_id to get the list of potential actions. Then the frontend will send us the action to execute (like we are doing in the dialog in the current state of this PR).

OK, until that is decided (not sure where) and implemented this PR can be drafted then?

Yes indeed I can't do it on my phone but you can or I'll do it tomorrow.

@dshokouhi
Copy link
Member

All the logic of this PR will be kept except that the frontend will send us an event with the entity_id to get the list of potential actions. Then the frontend will send us the action to execute (like we are doing in the dialog in the current state of this PR).

This is out of scope for this PR but I always wondered if it was the correct approach for the app and frontend to communicate like so for every action. Open app and it says what can and cannot be supported, then now it looks like even further communication is requested for whats supported at different actions. Would it make more sense for the app to first register with the server what it can and cannot support like in some JSON format so we rely a bit less on external bus for whats supported and keep it strictly for actions (i.e. opening settings, triggering dialogs etc....). The features that are supported are on a per device and app version level so the initial communication when we do (re)registration should contain everything needed up until needing to send an action to the app or vice versa. For example if a device doesnt have NFC then it will never have it, so why ask every time. Unless its a user facing setting some of these things will change very little or only on app update.

@jpelgrom jpelgrom marked this pull request as draft August 6, 2025 17:41
@jpelgrom
Copy link
Member

jpelgrom commented Aug 6, 2025

Yes indeed I can't do it on my phone but you can or I'll do it tomorrow.

Use a browser on your phone 😉 Changed

@TimoPtr TimoPtr force-pushed the feature/add_to_external_event branch from 3d0650c to 6354781 Compare October 30, 2025 17:11
@TimoPtr TimoPtr marked this pull request as ready for review November 4, 2025 12:20
@TimoPtr TimoPtr requested a review from jpelgrom November 4, 2025 12:20
@TimoPtr
Copy link
Member Author

TimoPtr commented Nov 4, 2025

@jpelgrom I've addressed your comments and the frontend has been updated.

Copy link
Member

@jpelgrom jpelgrom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the frontend has been updated

Frontend PR is still pending review, no?

I'm also still seeing commented out code/unimplemented actions. Let's remove that, there's a lot going on. You already have issues to track them.

* or on a phone.
*/
@Serializable
data object AndroidAutoFavorite : EntityAddToAction {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit weird to me to have these inside the interface

Copy link
Member Author

@TimoPtr TimoPtr Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a sealed class, I'm used to writing it like this but we could put it outside 👍. It just needs to be in the same package.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a dealbreaker and may just be personal preference, my (limited) experience with sealed classes put it outside like in the official docs. Inside makes me think of enums ;)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've used sealed class when they first introduced it and it was mostly to "replace" enums. That should be why I'm used to do that 👍🏻 but fine for me, one less indentation.

Copy link
Member Author

@TimoPtr TimoPtr Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait no, it has a reason ^^ if we don't put it in the sealed class the usage is going to be

val action = Tile

where if it is inside

val action = EntityAddToAction.Tile

I think it's better for context while working with an action, don't you think?
(even if we could make an import that removes the first part)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now it's a naming question. Changing them so you have TileAddToAction, CameraWidgetAddToAction, etc. would also work in my opinion.

For now fine either way, let's not have the PR get stuck on this discussion.

@TimoPtr
Copy link
Member Author

TimoPtr commented Nov 4, 2025

the frontend has been updated

Frontend PR is still pending review, no?

I'm also still seeing commented out code/unimplemented actions. Let's remove that, there's a lot going on. You already have issues to track them.

It should be merged after the release of Wednesday. I meant that the PR on the frontend has been updated not the frontend itself.

I'll remove the todos.

@TimoPtr TimoPtr requested a review from jpelgrom November 5, 2025 15:53
Copy link
Member

@jpelgrom jpelgrom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes now look good to me, also tested with yesterday's frontend branch which looks like it is close enough to final.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants