WAMF v0.4.0 Released

WAMF v0.4.0 is now available.

This release has been less about adding another long list of features and more about making sure the features already in WAMF form a stable platform that can actually be installed, configured and run reliably.

That meant testing WAMF outside its development environment, finding hidden assumptions, improving first-run configuration, hardening service management, building a repeatable Docker deployment and validating the complete wildlife detection pipeline on different systems.

The result is the foundation that future versions of WAMF can now build on.

What WAMF does today

WAMF is a self-hosted wildlife monitoring platform.

In v0.4.0, Frigate provides camera ingestion and object detection. When Frigate detects a bird, the event is published over MQTT and received by WAMF.

WAMF then retrieves the associated media from Frigate, runs species classification and stores the resulting observation.

The basic pipeline is:

Camera → Frigate → MQTT → WAMF → Species Classification → Observation

From there, WAMF provides a wildlife-focused interface for browsing observations, species information and archived media.

Making installation repeatable

One of the biggest goals for v0.4.0 was proving that WAMF could be installed somewhere other than the machine it was developed on.

Testing on a clean second system exposed several assumptions that are easy to miss during development, including configuration paths, Python versions, network addresses, camera configuration and first-run administrator setup.

Those findings led to a much more robust bootstrap process.

A fresh WAMF installation can now create its initial configuration, generate administrator credentials and enter setup mode until the required Frigate and MQTT settings have been supplied.

The aim is simple: installing WAMF shouldn’t require manually constructing password hashes and editing a collection of files before the application will even start.

WAMF v0.4.0 has a tested Docker deployment and an official container image published through the GitHub Container Registry.

Configuration, observation data and archived media are stored using persistent mounts, allowing the WAMF container itself to be recreated or upgraded without losing its state.

Docker Compose and Portainer deployments are both supported by the documentation.

For normal installations, Docker is now the recommended way to run WAMF.

Testing the complete pipeline

Deployment testing wasn’t limited to checking whether a container started.

The complete path from a camera stream through Frigate and into WAMF was tested, including:

  • Frigate bird detection
  • MQTT event delivery
  • Event snapshot retrieval
  • Species classification
  • Observation storage
  • Media archiving
  • Web interface updates

A repeatable QA video feed was also used to generate controlled bird detections through Frigate, making it possible to test the same end-to-end path without waiting for a cooperative bird to arrive at exactly the right moment.

Real birds remain stubbornly unwilling to participate in release schedules.

Frigate compatibility

WAMF v0.4.0 has been validated against both Frigate 0.17.2 and Frigate 0.18.0.

The WAMF-facing event and media path worked with both versions without requiring compatibility changes.

WAMF does not depend on a particular Frigate detector. Frigate can use the detection hardware appropriate for its host while WAMF consumes the resulting events.

Reliability work

A significant amount of v0.4.0 development happened below the visible interface.

Shutdown and restart handling were improved so that WAMF can cleanly stop its workers and restart itself without relying on fragile process behaviour.

MQTT startup and subscription handling were also tightened, along with configuration validation, application paths and setup-mode behaviour.

These aren’t necessarily the features that make exciting screenshots, but they’re the pieces that make a self-hosted application much nicer to live with.

Documentation and deployment

The WAMF documentation has also been updated around the released software.

The installation, Docker deployment, quick-start, Frigate configuration, updating and backup guides now describe the v0.4.0 deployment rather than the earlier development workflow.

There is still plenty of documentation to expand and refine, but the core path from installation to first wildlife observation is now documented against a real tested deployment.

What comes next

With v0.4.0 released, development can move away from platform stabilisation.

The next step is v0.4.5, which will concentrate on usability, configuration, administration, integrations and interface improvements.

After that, v0.5 is where the larger architectural work begins.

The goal is to make Frigate one possible source rather than a permanent requirement. WAMF Core will eventually be able to receive wildlife events from Scouts using different cameras, detection hardware and inference backends through a common event model.

That opens the door to systems ranging from existing Frigate installations to dedicated edge devices and direct camera processing.

But that’s work for the next chapter.

For now, v0.4.0 gives WAMF something much more important: a stable place to build from.

Thanks for following the project.