Paulus Schoutsen balloob

Home Assistant Sandbox — Architecture

This document describes the final, current architecture of the Home Assistant sandbox: how an integration runs in an isolated subprocess while the main instance keeps a single unified view of devices, entities, services, and events. It is a state-of-the-system reference, not a history. A condensed changelog of the work that produced this state is at the bottom.

Deeper, source-linked detail lives in OVERVIEW.md; the design rationale for individual decisions is in docs/.

OpenDisplay on a 42" E-Ink Android Screen

I got my hands on an AValue EPD-42S — a 42-inch e-ink display running Android 5.1 on an NXP i.MX 7Dual. The display is 2880x2160, 16-level grayscale, no backlight, and holds its image at zero power. Perfect for a wall-mounted dashboard or photo frame.

I wanted to use the OpenDisplay protocol to push images to it over WiFi from any server on my network. OpenDisplay had a Python library for BLE communication, but no WiFi support. And there was no Android client at all.

So I built both.

What I built

Media player volume control analysis

Analysis of all integrations providing media player entities, focused on volume control behavior.

Base class behavior

The default async_volume_up/async_volume_down in MediaPlayerEntity (__init__.py:1036-1070):

If the entity defines a sync volume_up/volume_down method, calls it via executor
Otherwise, if volume_level is known and VOLUME_SET is supported, calls set_volume_level(volume_level +/- volume_step) where volume_step defaults to 0.1 (10%)

Open Home Assistant Architecture Discussions

Source: https://github.com/home-assistant/architecture/discussions

Summary

Total Open Discussions: 144
Entity Models: 109 (76%)
General: 33 (23%)
Documentation: 2 (1%)

I have an ask for the AI community: can someone create a standard for interacting with LLMs.

There is a whole category of new apps and features ready to be made on top of LLMs. But to get these in the hands of users is hard. Apps will need to have subscriptions, ask the user to add their OpenAI API key or include and ship their own LLMs. It’s time to add a fourth option: create a standardized API that allows interacting with LLMs that cloud and local services can implement to put the user in control.

There are new LLM models and tuned variations popping up all the time, and most of these models end up implementing some part of the Chat Completions endpoint of the OpenAI Rest API. The recommendation is for users to use the OpenAI SDK and override the endpoint (even Google is doing this now!). The OpenAI API is tailored to the needs of OpenAI, which means it’s set up to interact with their cloud-based LLM mode

	/*

	Copy file to <config>/www/user-agent-card.js

	Restart Home Assitant if www folder didn't exist.

	In Home Assistant:
	- Profile -> Enable advanced mode
	- Config -> Dashboards -> Resources
	- New resource. `/local/user-agent-card.js`. Type: JS Module

	/*
	Battery strategy that shows your battery entities grouped by area.

	To use:
	- store this file in `<config>/www/balloob-battery-strategy.js`
	- Add lovelace resource: `/local/balloob-battery-strategy.js`, type JavaScript Module
	- Create a new Lovelace dashboard and set as content:

	views:
	- title: Batteries

	/*
	Demo strategy that shows each area as a tab. Each tab shows the area entities.

	To use:
	- store this file in `<config>/www/demo-strategy.js`
	- Add lovelace resource: `/local/demo-strategy.js`, type JavaScript Module
	- Create a new Lovelace dashboard and set as content:

	strategy:
	name: 'custom:balloob-demo'

	/*

	To use in Home Assistant, configure card:

	type: 'custom:example-card'
	entities:
	- switch.wemo_insight
	- light.bed_light
	- light.ceiling_lights
	- light.kitchen_lights

	/*
	Created by @jh3yy
	Adapted for Home Assistant by @balloob

	Original: https://twitter.com/jh3yy/status/1327686213432717313

	Only works on localhost because of restrictions MorphSVGPlugin3

	Card config for usage in Home Assistant: