This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
## Repository Overview
This is a Home Assistant add-on repository containing 120+ Docker-based add-ons for the Home Assistant Supervisor. Each add-on is a self-contained directory with a Dockerfile, config schema, and S6-overlay init scripts. The repository uses GitHub Actions for CI/CD, linting, and automated upstream version tracking.
## Add-On Directory Structure
Most add-ons follow this common layout, though exceptions exist (e.g. some archived add-ons use `config.json` instead of `config.yaml`, some add-ons have `build.yaml` instead of `build.json` or no build file at all, and not every add-on includes a `rootfs/` tree):
```
addon_name/
├── config.yaml # HA add-on metadata, schema, ports, maps
├── build.json # Base Docker images per architecture (may be build.yaml, or absent)
├── CHANGELOG.md # Required; must be updated on every PR
└── rootfs/ # Optional; absent in some add-ons
└── etc/
├── cont-init.d/ # S6-overlay init scripts (numbered, run in order)
└── services.d/ # S6-overlay supervised services (some add-ons use
# s6-overlay v3 layout at etc/s6-overlay/s6-rc.d/ instead)
```
## Dockerfile Convention
Most Dockerfiles follow this 6-section pattern (some add-ons deviate slightly, e.g. using a pinned upstream image directly instead of `ARG BUILD_FROM`):
4.**Entrypoint**– Set `S6_STAGE2_HOOK=/ha_entrypoint.sh`
5.**Labels**– Standard OCI + HA labels from build args
6.**Healthcheck**– curl-based check suppressed from nginx/apache logs
Shared build-time scripts are pulled from `.templates/` at build time:
-`ha_automodules.sh`– Downloads module scripts listed in `ARG MODULES=`
-`ha_autoapps.sh`– Installs packages listed in `ENV PACKAGES=`
-`ha_entrypoint.sh`– S6 stage-2 hook; launches the cont-init stack at container start
-`ha_lsio.sh`– Patches LinuxServer.io base images for HA compatibility
-`bashio-standalone.sh`– Bashio library for scripts outside Supervisor context
The `ARG MODULES=` line lists template scripts to download at build time (e.g., `00-banner.sh 01-custom_script.sh 00-smb_mounts.sh`). Commonly-used modules in `.templates/` (not exhaustive):
-`00-global_var.sh`– Initialize global env vars from HA options
-`00-local_mounts.sh`– Mount local disks (localdisks option)
-`00-smb_mounts.sh`– SMB/CIFS network mount support
-`01-config_yaml.sh`– Map HA options → app's `config.yaml`
-`01-custom_script.sh`– Run user-provided custom scripts
-`90-disable_ingress.sh`– Allow disabling HA ingress
version:"X.Y.Z"# upstream version (format varies; see Versioning section)
ingress:true/false
ingress_port:8000
map:
- addon_config:rw # /addon_configs/<hostname>/
- share:rw
- media:rw
- ssl
schema:
env_vars:# Allows arbitrary env var passthrough
- name:match(^[A-Za-z0-9_]+$)
value:str?
PUID:int
PGID:int
TZ:str?
networkdisks:str? # SMB mounts
localdisks:str? # Local disk mounts
```
The `env_vars` schema key enables the env-var passthrough mechanism. At runtime the `00-global_var.sh` cont-init module reads `/data/options.json` and exports each key as an environment variable (writing to `/.env` and `/etc/environment`). `ha_entrypoint.sh` is the S6 stage-2 hook that launches the cont-init stack but does not itself perform the JSON-to-env conversion.
## Versioning
Add-on versions in `config.yaml` closely follow the upstream release tag and do not conform to a single fixed format. Common patterns include:
-`X.Y.Z`– plain upstream semver (e.g. `0.137.0`)
-`X.Y.Z-N`– upstream version with a local patch counter (e.g. `0.6.26-2`)
When an upstream version is bumped, update `version` in `config.yaml`. If the add-on's `Dockerfile` contains an `ARG BUILD_UPSTREAM` line, update that value too — it is the canonical place that records the upstream version at build time (it is **not** stored in `build.json`/`build.yaml`). Some add-ons do not use `BUILD_UPSTREAM` at all. The `updater.json` file tracks which upstream source/repo to monitor and records the last seen version.
- Fix 502 Bad Gateway on ingress: nginx now waits for the API server (port 5002) to be ready before starting. Previously, nginx started immediately while the ML model was still loading, causing all API calls to fail with 502 until the model finished loading.
- Update to latest version from Suncuss/BirdNET-PiPy (changelog : https://github.com/Suncuss/BirdNET-PiPy/releases)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.