# View Assist: putting a face and a screen on the Home Assistant voice assistant

> View Assist is a set of Home Assistant customisations that give the Assist voice assistant visual feedback, using automations, custom sentences, scripts and dashboard views displayed on any Android device, with ESPHome satellites also supported. It suits a Home Assistant user who wants their voice assistant to show what it is doing, and the design choice to understand first is that the pieces are deliberately separable, so you can take only the parts you need.

**dinki/View-Assist** — View Assist provides visual feedback for the Home Assistant Assist Voice Assistant

- Repository: https://github.com/dinki/View-Assist
- Stars: 548 · Forks: 79
- Language: Python
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/dinki-view-assist

## What the project actually is

View Assist provides visual feedback for the Home Assistant Assist voice assistant using a collection of different automations, custom sentences, scripts, and extensions with the view being displayed on any Android device.

That is a description of a set of Home Assistant customisations rather than of an application, and the distinction matters for what you can expect from the repository. There is no installable app and no service to run. What there is are Home Assistant automations, a set of custom sentences for the voice pipeline, scripts, and dashboard views that render the assistant's state, and you assemble those into your own Home Assistant configuration.

The reason the project exists at all is worth putting first. The Assist voice assistant in Home Assistant works by listening, then acting, then answering. In a headless installation, which is the common case, the user gets no confirmation of what was heard and no indication of what the assistant is doing. A wall-mounted tablet that shows the transcript and the state of the automation closes that gap.

The project is by dinki, and it has a demo video linked from the README, which is the fastest way to see the result before reading any configuration. There is also a Buy Me a Coffee button, so this is a project maintained by one person in their own time.

The primary language is recorded as Python, the default branch is main, the last push was on 2026-09-10, and there are no GitHub releases, which is consistent with a repository of Home Assistant files rather than a distributed package.

## Several satellites, and not only Android

Two capabilities in the description are worth separating out, because they change what the project can be used for.

The first is that multiple devices can join the View Assist satellite network and interact. So this is not a single-screen affair where one tablet is the assistant's face. Several devices can each show the assistant, and a user in one room can talk to a device in another, or each device can respond to what the others did.

The second is that this is not limited to Android devices, as ESPHome satellites are also supported. ESPHome is the firmware framework for the small custom-built devices that have become common in Home Assistant installations, typically small screens on ESP32 boards. The support means the same View Assist concept, the same feedback, can run on a purpose-built satellite with a small display rather than requiring a tablet.

That combination is what makes the project more than a screen saver for a spare phone. A household with a tablet in the kitchen, a phone by the door and a small ESP32 display in the office can all be satellites of the same assistant, and the feedback follows the user around the house rather than staying on one screen.

The Android requirement is also worth noting in practice, because the wording says the view is displayed on any Android device. A tablet is the obvious target, and the README notes a specific recommendation: the Lenovo ThinkSmart device is a nice Android tablet with a nice sounding speaker at an unbelievably low price, around 40 US dollars, and the author has been working on getting it to work with View Assist. A cheap tablet with a usable speaker is exactly the hardware profile this project wants, since a satellite needs a screen to show the feedback and a speaker to hear you.

The ESPHome route changes that arithmetic, since a purpose-built device with an integrated display and speaker is the hardware the project is ultimately aimed at.

## Four directories, and why they are separate

The information in the repository is separated into different subdirectories, with the install information stored in the wiki. The top level listing makes the structure explicit.

There is a `View Assist dashboard and views/` directory, a `View_Assist_custom_sentences/` directory, a `View_Assist_scripts/` directory, and a `wiki/` directory. There is also a `package-lock.json` and a `package.json` at the root, a `.github/` directory and the licence file.

The four content directories map onto the four kinds of thing the project contains, and each is independently usable. The dashboard and views directory holds the Home Assistant dashboard views that display the feedback. The custom sentences directory holds the sentence definitions for the voice pipeline. The scripts directory holds the Python scripts that the automations call. The wiki holds the installation instructions.

The design intent is stated plainly: this project is designed so that you can pick and choose the parts that you want for your needs. The custom sentences can be modified for those who may only be interested in voice only. The dashboard views may be interesting to others who are writing their own custom sentences.

That last sentence is the important one. It describes two distinct user groups. One person wants the audio experience only and wants to change the wording the assistant recognises, without a screen anywhere in their setup. Another is writing their own custom sentences for a purpose they have in mind and wants the visual side that goes with it. The project supports both without either group having to adopt the other's concerns.

This is a deliberate choice about the shape of a Home Assistant integration. The Home Assistant model is that a user assembles their own configuration from parts, and the maintainers of a project like this are usually a single person who cannot support every possible combination. Making the parts separable means the project stays maintainable, and it means a user with an unusual setup can take one piece and leave the rest.

## The front-end tooling, and what the package manifest tells you

The package manifest in the repository is short, and it tells you what the visual side is built with.

```json
{
  "devDependencies": {
    "autoprefixer": "^10.4.19",
    "postcss": "^8.4.39",
    "tailwindcss": "^3.4.4"
  }
}
```

Three dev dependencies, all of them front-end build tooling and none of them a runtime library. Tailwind CSS is the styling layer, PostCSS is the processor that runs it, and Autoprefixer adds vendor prefixes. There is no framework in the list, which is worth noting: the dashboard views are styled with utility classes and assembled by Home Assistant's own dashboard system rather than by a JavaScript application framework.

That is consistent with how Home Assistant dashboards work. A view is a configuration of cards, and a custom view with custom styling is a matter of supplying CSS and some template content. The build tooling here exists to turn the project's styling source into CSS that the dashboard can use, and the dependency set is what a utility-first CSS pipeline needs.

There being only devDependencies and no dependencies or scripts section is also informative. The repository is not a published JavaScript package and does not have a build command you would run from the command line in the way an application project would. The package manifest exists to pin the versions of the styling tools used to produce the views, and the output of that process is committed.

The absence of a runtime dependency is the practical point. Nothing here needs to be installed into Home Assistant as a package, and nothing has to be kept in step with Home Assistant's own dependency versions, which is one of the reasons a project of this kind is delivered as a set of files rather than as an integration.

## The wiki carries the instructions, and the docs live elsewhere

Two facts about where the documentation lives are worth noting before anyone starts.

The first is that the install information is stored in the wiki rather than in the repository, and the README points at it in two forms. There is the GitHub wiki at github.com/dinki/View-Assist/wiki, and there is a separate site at dinki.github.io/View-Assist. The second link appears to be a rendered or published version of the same documentation, which is a common arrangement when the wiki is the working copy and the site is what people are pointed at.

The second is that the `wiki/` directory is nevertheless present in the repository listing alongside the content directories. So the documentation source is versioned with the code, which means a change to the instructions and a change to the views they describe land in the same commit rather than drifting apart across two systems.

The README itself is deliberately short. It states what the project does, links the demo video, describes the directory separation and the pick-and-choose intent, links the wiki, and then gets to the hardware recommendation. Everything procedural is in the wiki.

That division is common in Home Assistant projects and it makes sense for a different reason than in most repositories. A Home Assistant user setting this up is usually following a guide rather than reading a codebase, and the guide has to be readable on its own, with the steps in the order they must be performed. Embedding that in the repository README would mean the README was mostly a manual with a short project description at the top, and the description would get pushed further down every time the manual changed.

The demo video placement is deliberate too. It sits near the top, right after the opening description, before the directory discussion. For a project whose value is a visual effect, showing the effect first is the right order, and the README points out that it is a demo video on YouTube.

## What to expect from a work in progress

The project states its own status plainly: it is still a work in progress but is fully functional.

Both halves of that sentence carry information. The functional part means the pieces described are working and a user can install them and get a result, which is different from a prototype that demonstrates an idea. The work in progress part means the arrangement of the parts, the naming and the interfaces between them, are still likely to change.

For a Home Assistant user this combination is fairly ordinary, and the platform itself is built on the assumption that customisations evolve. A dashboard view, an automation and a script are configuration rather than compiled code, so a change to a file affects you the next time you pull, and there is no version pinning story for a project distributed this way.

The practical advice that follows from that is to read the wiki before you start rather than after. Because the parts are separable, a user who takes only the custom sentences is insulated from changes to the dashboard views, and a user who takes only the views is insulated from changes to the sentences. Someone taking both is exposed to more, and the wiki is where the current arrangement is described.

The licence is one GitHub cannot classify, with the terms in a LICENSE.md file at the root, so that is the thing to read if you intend to redistribute or adapt the work.

The name and the shape of the project place it in a wider trend in Home Assistant, where the voice assistant has become a common target for small custom-built display devices. View Assist is one of the more complete attempts at making that display good, and its contribution to the ecosystem is as much the working example as the code itself.

## Conclusion

Adopt View Assist if you run Home Assistant and want your Assist voice assistant to display what it hears and does, since the dashboard views give the assistant a face on any spare tablet. Do not adopt it expecting a finished product, because the project describes itself as a work in progress that is nonetheless functional, and check first which parts you want, because the repository is deliberately organised so that the voice-only custom sentences and the visual dashboard are independent pieces.

## FAQ

### What is View Assist?

It is a set of Home Assistant customisations that provide visual feedback for the Home Assistant Assist voice assistant, using automations, custom sentences, scripts and extensions, with the view displayed on any Android device. Multiple devices can join the View Assist satellite network and interact, and ESPHome satellites are also supported.

### How is the View Assist project organised?

The information is separated into different subdirectories with install information stored in the wiki. There is a directory for the dashboard and views, one for the custom sentences, one for the scripts, and a wiki directory. The design intent is that you can pick and choose the parts you want, with the custom sentences useful on their own for voice only and the dashboard views useful to anyone writing their own custom sentences.

### What can I run View Assist on?

Any Android device, with multiple devices able to join the satellite network and interact, and ESPHome satellites are supported too, so small purpose-built displays work as well as tablets. The README specifically recommends the Lenovo ThinkSmart Android tablet as a cheap option with a good speaker.

### What frontend tooling does View Assist use?

The package manifest lists only three dev dependencies, all front-end build tools: autoprefixer at 10.4.19, postcss at 8.4.39 and tailwindcss at 3.4.4. There is no runtime dependency, so nothing needs to be installed into Home Assistant as a package.

### Where are the View Assist installation instructions?

In the wiki, which is linked from the README in two forms, the GitHub wiki at github.com/dinki/View-Assist/wiki and a published site at dinki.github.io/View-Assist. A wiki directory is also present in the repository, so the documentation source is versioned alongside the code.

### Is View Assist still being developed?

The repository is not archived and the last push was on 2026-09-10, with no GitHub releases. The project describes itself as still a work in progress but fully functional, and the licence is a custom one GitHub cannot classify with the terms in LICENSE.md at the root.

## Sources

- [dinki/View-Assist on GitHub](https://github.com/dinki/View-Assist)
- [Issues](https://github.com/dinki/View-Assist/issues)
- [README](https://github.com/dinki/View-Assist/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dinki-view-assist