joshuar-go-hass-agent/docs/development.md

go-hass-agent Development

Build Requirements

go-hass-agent has a number of build requirements external to go.mod that need to be installed:

• stringer.
  • Typically installed with go install golang.org/x/tools/cmd/stringer@latest.
• fyne-cross.
  • Typically installed with go install github.com/fyne-io/fyne-cross@latest
• gotext
  • Typically installed with go install golang.org/x/text/cmd/gotext@latest
• goreleaser.

Building

go-hass-agent makes use of go generate to generate some of the code. A typical build process would be:

go generate ./...
go build

Packaging

go-hass-agent uses Goreleaser to create packages for Fedora, Arch and Ubuntu and fyne-cross to create packages for Debian.

To build a "local-only" package with Goreleaser:

goreleaser release --snapshot --clean

Packages will be available under the dist/ folder.

See the Goreleaser docs for more commands and information.

To build a package for Debian with fyne-cross:

fyne-cross linux -icon assets/trayicon/logo-pretty.png -release

The .tar.xz will be available under fyne-cross/dist/linux-amd64/.

Extending the Agent

Adding OS support

The intention of the agent design is to make it OS-agnostic.

Most OS specific code for fetching sensor data should likely be part of a GOARCH package and using filename suffixes such as filename_GOOS_GOARCH.go. See the files under linux/ as examples.

For some OSes, you might need some code to initialise or create some data source or API that the individual sensor fetching code uses. This code should be placed in device/, using filename suffixes such as filename_GOOS_GOARCH.go

For example, on Linux, a DBus connection is used for a lot of the sensor data gathering.

In such cases, you should pass this through as a value in a context. You can create the following function for your platform:

SetupContext(ctx context.Context) context.Context

It should accept a context.Context and derive its own context from this base that contains the necessary values for the platform. It will be propagated throughout the code wherever a context is passed and available for retrieval and use.

An example can be found in device/device_linux.go.

Adding sensors

See device/sensors.md.

Committing Code

This repository is using conventional commit messages. This provides the ability to automatically include relevant notes in the changelog. The TL;DR is when writing commit messages, add a prefix:

• feat: for a new feature, like a new sensor.
• fix: when fixing an issue.
• refactor: when making non-visible but useful code changes.
• …and so on. See the link above or see the existing commit messages for examples.