YA-WAMF

YA-WAMF

Docker app from Jellman86's Repository

Overview

YA-WAMF (Yet Another WhosAtMyFeeder) identifies birds at your feeder from Frigate NVR events using local machine-learning models. It shows a real-time dashboard, correlates visual detections with BirdNET-Go audio, enriches species with taxonomy, and can send notifications. This template starts the full compatibility image and leaves inference on Auto. Optional CPU, Intel, and NVIDIA image tags are documented in the Unraid setup guide. Connect Frigate and MQTT in the first-run wizard or Settings → Connection. Provider selection stays in Settings → Detection so settings remain editable and persistent.

Unraid

Install YA-WAMF on Unraid from a Docker template, so the container, ports, and paths are filled in for you and the web UI is one click away.

Outcome

YA-WAMF runs as a single Unraid Docker container, its config and data on persistent appdata paths, reachable at http://<your-unraid-ip>:9852/.

Prerequisites

  • A reachable Frigate instance publishing events over MQTT — YA-WAMF is driven by Frigate events and does nothing useful without them. See Frigate and MQTT Broker.
  • Somewhere to store appdata (the default is /mnt/user/appdata/ya-wamf).

YA-WAMF's UI and API are administrative surfaces. If you expose them outside your LAN, put them behind an authenticated reverse proxy — see Reverse Proxy and Authentication & Access.

Install with the template

Community Applications

In Apps, search for YA-WAMF, confirm that the repository is ghcr.io/jellman86/yawamf-monalithic, and select Install. The listing provides the template, app icon and project/support links.

Manual template import

If the listing is unavailable, save the published template locally. The Docker → Add Container → Template control selects local templates; it does not accept a remote URL. From the Unraid terminal:

install -d /boot/config/plugins/dockerMan/templates-user
template=/boot/config/plugins/dockerMan/templates-user/my-YA-WAMF.xml
test ! -e "$template" &&
  curl -fL --output /tmp/yawamf-template.xml \
    https://raw.githubusercontent.com/Jellman86/YetAnother-WhosAtMyFeeder/main/unraid/yawamf.xml &&
  install -m 0644 /tmp/yawamf-template.xml "$template"

Use this command for a new installation. For an existing installation, keep its saved template and edit that container so your paths, ports and device settings are retained.

  1. Go to Docker → Add Container.
  2. In Template, select YA-WAMF under User templates.
  3. Review these fields:
    • WebUI Port: host port for the UI (default 9852; the container listens on 8080).
    • Config: /config mapped to /mnt/user/appdata/ya-wamf/config (settings, credentials and the default media-cache directory).
    • Data: /data mapped to /mnt/user/appdata/ya-wamf/data (SQLite history, species catalogue, models, manual uploads and migration backups). Keep both mounts on fast storage.
  4. Click Apply.

The template runs as user ID (UID) 99 / group ID (GID) 100 (nobody:users) via --user 99:100. Unraid creates missing mapped directories with this ownership. Existing directories must already permit this user to write; importing a template does not repair their permissions. If needed, stop YA-WAMF and correct ownership on only its Config and Data directories. The image does not honour PUID/PGID variables.

Expected result

Unraid pulls ghcr.io/jellman86/yawamf-monalithic:latest and starts the full compatibility container. First startup can take several minutes while the database and species catalogue are prepared. Open WebUI or http://<your-unraid-ip>:9852/, then complete the first-run wizard.

In Frigate & MQTT connection, enter the Frigate API URL and MQTT broker address, port and credentials, then test both connections. Use LAN addresses, for example http://192.168.1.10:5000, or hostnames reachable from the container. The default Docker bridge network does not resolve container names such as frigate or mqtt; those names require a shared user-defined network. For a Frigate API that requires authentication, provide its URL and token together (see Frigate). Later changes belong in Settings → Connection.

The current template leaves connection settings in the app. Older installs may still have FRIGATE__FRIGATE_URL in their saved Unraid template; it overrides the saved Frigate URL on restart. To move an existing install to in-app settings, first note that URL, remove the variable from the container's edit form, apply the change, and save the URL in Settings → Connection. Keep intentional environment overrides if you manage configuration externally.

Authentication is disabled initially. Set an admin password during setup or under Settings → Security before exposing the service beyond a trusted network. See Authentication & Access.

Optional: hardware acceleration

The template deliberately starts with the full compatibility image and does not pin an inference provider. Four separate controls are involved:

Control Where to set it in Unraid What it means
Image family Repository tag Which inference runtimes are installed
Device/runtime access Advanced container settings Which host accelerator the container can see
Selected provider Settings → Detection inside YA-WAMF The user's preferred provider, normally Auto
Active provider YA-WAMF runtime diagnostics What actually ran after model, packaging, and hardware checks

The available stable Repository tags are:

Repository tag Packaged providers Intended host
latest CPU, CUDA, Intel CPU/GPU/NPU Compatibility and initial setup
latest-cpu CPU Hosts without an accelerator
latest-intel CPU and Intel OpenVINO Intel GPU or NPU hosts
latest-cuda CPU and NVIDIA CUDA NVIDIA hosts

Start with latest. Once the installation is healthy, edit only the tag portion of Repository if you want a smaller image; keep the same /config and /data paths. Pinned releases use the same suffix, such as v2.21.1-intel.

Do not add YAWAMF_IMAGE_FLAVOR to the template. It is read-only identity baked into each image, and overriding it does not install a runtime. Also avoid adding CLASSIFICATION__INFERENCE_PROVIDER for an ordinary interactive installation: that environment variable overrides the in-app value on every container start, so a provider changed in Settings would appear to save but revert after a restart. Use it only when you intentionally manage immutable settings outside the application.

See Hardware Acceleration for the complete provider contract, diagnostics, and rollback path.

Intel GPU or NPU

To run inference on an Intel GPU or NPU, add the device yourself (the template does not add one, so it never passes an empty --device to Docker). In the container's edit view, switch to Advanced view, click Add another Path, Port, Variable, Label or Device, and add:

  • Config Type Device, Value /dev/dri — Intel integrated GPU (intel_gpu), or
  • Config Type Device, Value /dev/accel/accel0 — Intel Core Ultra "AI Boost" NPU (intel_npu).

Add only the device you actually have. Run the model compatibility check, then pick a validated provider under Settings → Detection → Inference Provider, or keep Auto. GPU/NPU access can also require supplementary host groups. Look up the numeric group owning the render or accelerator device, then append --group-add <gid> to Extra Parameters, preserving --user 99:100. See Hardware Acceleration for the full detail and fallback behaviour.

NVIDIA CUDA

  1. Install Unraid's NVIDIA Driver plugin and confirm nvidia-smi works in an Unraid terminal. Keep the GPU available to the host rather than binding it exclusively to VFIO.
  2. Keep the full latest Repository tag for compatibility testing, or change it to latest-cuda for the smaller CUDA image.
  3. Follow the NVIDIA Driver plugin's current container-runtime instructions for your Unraid release. The established Docker-runtime path is to enable Advanced view, append --runtime=nvidia to Extra Parameters, keeping the existing --user 99:100, and add:
    • NVIDIA_VISIBLE_DEVICES with the GPU UUID shown by the plugin (or all when deliberately exposing every GPU), and
    • NVIDIA_DRIVER_CAPABILITIES=compute,utility. Newer Unraid/NVIDIA toolkit releases may offer CDI device selection instead; use one exposure method, not both.
  4. Start the container, leave the in-app provider on Auto initially, and check Settings → Detection → Runtime diagnostics. It must show a full or cuda image, CUDA under Packaged, the GPU as available, and CUDA as Active during supported-model inference.

The NVIDIA runtime variables expose hardware; they do not select YA-WAMF's inference provider. If CUDA cannot initialize or the active model does not support it, YA-WAMF retains the provider preference and falls back to CPU with a diagnostic reason.

Update and verify

Back up the mapped Config and Data directories consistently before updating, then update the existing container through Unraid so its mappings and device access are retained. Wait for the container to become healthy, confirm recent photographs and history, then check Settings → Detection → Runtime diagnostics. New model assets need an application build with their integration; a rolling model-catalogue release does not update an older application. See the upgrade guide for retention-switch migration and rollback precautions.

If it fails

  • Blank page or connection refused: the container may still be starting or applying model changes — wait a moment and retry. Check the container log in Unraid.
  • No detections: confirm the Frigate URL is reachable from the container and that Frigate is publishing to MQTT. See Diagnostics.

For all settings once you are in, see the Configuration Guide.

Media gallery

Requirements

A reachable Frigate instance and MQTT broker. The default latest tag is the full compatibility image; optional latest-cpu, latest-intel, and latest-cuda tags use the same persistent data. Configure Frigate and MQTT in the web UI using addresses reachable from this bridge-network container. Add only the hardware device/runtime your host provides, then select Auto or a provider under Settings → Detection. Do not override the image-flavor identity.

Related apps

Explore more like this

Explore all

Details

Repository
ghcr.io/jellman86/yawamf-monalithic:latest
Last Updated2026-10-15
First Seen2026-07-13

Runtime arguments

Web UI
http://[IP]:[PORT:8080]/
Network
bridge
Shell
sh
Privileged
false
Extra Params
--user 99:100

Template configuration

WebUI PortPorttcp

Host port for the YA-WAMF web interface (container listens on 8080).

Target
8080
Default
9852
Value
9852
ConfigPathrw

Persistent application configuration (config.json, keys).

Target
/config
Default
/mnt/user/appdata/ya-wamf/config
Value
/mnt/user/appdata/ya-wamf/config
DataPathrw

Detections database (SQLite) and cached media. Can grow with retention; keep on fast storage.

Target
/data
Default
/mnt/user/appdata/ya-wamf/data
Value
/mnt/user/appdata/ya-wamf/data
Timezone (TZ)Variable

Container timezone, e.g. Europe/London. Leave blank for UTC.

Target
TZ