Go Hass Agent

A Home Assistant, native app integration for desktop/laptop devices.

Documentation · Report Bug · Request Feature

📔 Table of Contents

• 📔 Table of Contents
• 🌟 About the Project
  • 🎯 Features
  • 🤔 Use-cases
  • 📈/🕹️ List of Sensors/Controls (by Operating System)
  • 🐧 Linux
  • 🗒️ Versioning
• 🧰 Getting Started
  • 🤝 Compatibility
  • 🔽 Installation
  • 📦 Packages
  • 🚢 Container
• 🕹️ Usage
  • 🔛 First-run
  • 👻 Running “Headless”
  • 🐳 Running in a container
  • ♻️ Regular Usage
  • 📌 Configuration Location
  • Script Sensors
  • Requirements
  • Supported Scripting Languages
  • Output Format
    • Examples
    • JSON
    • YAML
    • TOML
  • Schedule
  • Security Implications
  • MQTT Sensors and Controls
  • Configuration
  • Custom D-BUS Controls
  • Other Custom Commands
  • Security Implications
• ⚙️ Building/Compiling Manually
  • Build Requirements
  • Compiling
  • Cross Compilation
  • Packages
  • Container Images
• :wave: Contributing
  • 💾 Committing Code
  • 📜 Code of Conduct
• 🧭 Roadmap
• ❔ FAQ
  • Can I change the units of the sensor?
  • Can I disable some sensors?
  • The GUI windows are too small/too big. How can I change the size?
  • What is the resource (CPU, memory) usage of the agent?
  • I've updated the agent and now I've got a bunch of duplicate/removed/disabled sensors?
  • Can I reset the agent (start from new)?
  • I want to run the agent on a server, as a service, without a GUI. Can I do this?
  • Can (or does) the agent run as root or with privileges?
• 🤝 Acknowledgements
• 🧑‍⚖️ License

🌟 About the Project

Go Hass Agent is an application to expose sensors and controls from a device to Home Assistant. You can think of it as something similar to the Home Assistant companion app for mobile devices, but for your desktop, server, Raspberry Pi, Arduino, toaster, whatever. If it can run Go and Linux, it can run Go Hass Agent!

Out of the box, Go Hass Agent will report lots of details about the system it is running on. You can extend it with additional sensors and controls by hooking it up to MQTT. You can extend it even further with your own custom sensors and controls with scripts/programs.

You can then use these sensors/controls in any automations and dashboards, just like the companion app or any other "thing" you've added into Home Assistant.

🎯 Features

• Sensors: Expose a number of sensor entities to Home Assistant, which can then be used in dashboards, automations and other aspects your Home Assistant platform.
  • By default, Go Hass Agent ships with up around 100 sensors (on Linux), depending on the system it runs on.
• Custom Sensors via Scripts: All platforms can also utilise scripts/executables to create custom sensors. See Script Sensors.
• Controls and additional sensors via MQTT: Where Home Assistant is connected to MQTT, Go Hass Agent can add some additional sensors/controls for various system features. A selection of device controls are provided by default, and you can configure additional controls to execute D-Bus commands or scripts/executables. See Control via MQTT.

⬆️ Back to Top

🤔 Use-cases

As examples of some of the things that can be done with the data published by this app:

• Change your lighting depending on:
  • What active/running apps are on your laptop/desktop. For example, you could set your lights dim or activate a scene when you are gaming.
  • Whether your screen is locked or the device is shutdown/suspended.
• With your laptop plugged into a smart plug that is also controlled by Home Assistant, turn the smart plug on/off based on the battery charge. This can force a full charge/discharge cycle of the battery, extending its life over leaving it constantly charged.
• Like on mobile devices, create automations based on the location of your laptop running this app.
• Monitor network the data transfer amount from the device, useful where network data might be capped.
• Monitor CPU load, disk usage and any temperature sensors emitted from the device.
• Receive notifications from Home Assistant on your desktop/laptop. Potentially based on or utilising any of the data above.

⬆️ Back to Top

📈/🕹️ List of Sensors/Controls (by Operating System)

[!NOTE] The following list shows all potential sensors the agent can report. In some cases, the actual sensors reported may be less due to lack of support in the system configuration or missing hardware.

🐧 Linux

• Go Hass Agent Version. Updated on agent start.
• App Details:
  • Active App (currently active (focused) application) and Running Apps (count of all running applications). Updated when active app or number of apps changes.
  • Via D-Bus (requires XDG Desktop Portal Support support).
• Desktop Settings:
  • Accent Colour (the hex code representing the accent colour of the desktop environment in use) and Theme Type (whether a dark or light desktop theme is detected). Updated when theme or colour changes.
  • Via D-Bus (requires XDG Desktop Portal Support support).
• Media Controls (when configured with MQTT):
  • Volume Control Adjust the volume on the default audio output device.
  • Volume Mute Mute/Unmute the default audio output device.
  • MPRIS Player State Show the current state of any MPRIS compatible player.
  • Requires a player with MPRIS support.
  • Webcam Control Start/stop a webcam and view the video in Home Assistant.
  • Requires a webcam that is exposed via V4L2 (VideoForLinux2).
• Connected Battery Details:
  • Battery Type (the type of battery, e.g., UPS, line power). Updated on battery add/remove.
  • Battery Temp (battery temperature). Updated when the temperature changes.
  • Battery Power (the battery current power draw, in W). Attributes: Voltage (V), Energy consumption (kWh). Updated when power draw changes.
  • Battery Level/Percentage (either a textual representation of the level or a percentage, depending on battery support). Updated when level changes.
  • Battery State (the current battery state, e.g., charging/discharging). Updated When state changes.
  • All battery sensors require D-Bus and Upower support.
• Memory Stats:
  • Memory Total (total memory on the system, in B).
  • Memory Available (current memory available/free, in B).
  • Memory Used (current memory usage, both in B and %).
  • If swap is enabled, there will be similar sensors for swap.
  • Sourced via ProcFS. Updated ~every minute.
• Disk:
  • Disk Usage (in %) per disk/mount.
  • Attributes: File system type, bytes/inode total/free/used.
  • Sourced via ProcFS. Updated ~every minute.
  • Total Read/Writes (count) per disk.
  • Attributes include total milliseconds/sectors spent.
  • Read/Write Rate (in KB/s) per disk.
  • Both sourced via SysFS. Updated ~every 5 seconds.
• Networking:
  • Connection State (connected/disconnected/activating/deactivating) per connection. Updated when state changes. Requires D-Bus and NetworkManager.
  • Attributes: IP addresses and networks.
  • Connected Wi-Fi Network Details (requires D-Bus and NetworkManager.):
  • SSID (the SSID of the Wi-Fi network). Updated when SSID changes.
  • Frequency (the frequency band of the Wi-Fi network, in Hz). Updated when frequency changes.
  • Speed (the network speed of the Wi-Fi network, in Mbps). Updated when speed changes.
  • Strength (the strength of the signal of the Wi-Fi network, in dB). Updated when strength changes.
  • BSSID (the BSSID of the Wi-Fi network). Updated when BSSID changes.
  • Bytes Received/Sent (in B). Updated ~every 5s.
  • Attributes: packet count, drops, errors. Via ProcFS.
  • Bytes Received/Sent Rate (transfer rate, in B/s). Updated ~every 5 seconds. Via ProcFS.
• CPU:
  • Load Average (1/5/15 min). Updated ~every 1 minute. Via ProcFS.
  • CPU Usage (in %). Both total (all-cores) and per-core. Updated ~every 10 seconds. Via ProcFS.
  • Attributes include breakdown of CPU time per state (i.e., user, idle, servicing interrupts, etc.).
  • CPU Core Frequency (in Hz). Per-core. Updated ~every 10 seconds. Via ProcFS.
  • Attributes include current driver and governor in use.
• Power Related Details:
  • Power Profile (the current power profile as set by the power-profiles-daemon). Updated when profile changes.
  • Via D-Bus (requires power-profiles-daemon).
  • Screen Lock State (current state of screen lock). Updated when screen lock changes.
  • Via D-Bus. Requires xscreensaver or systemd-logind support.
  • Power State (power state of device, e.g., suspended, powered on/off). Updated when power state changes.
  • Via D-Bus. Requires systemd-logind.
• Power Controls (when configured with MQTT):
  • Lock/Unlock Screen/Screensaver Locks/unlocks the session for the user running Go Hass Agent.
  • Suspend Will (instantly) suspend (the system state is saved to RAM and the CPU is turned off) the device running Go Hass Agent.
  • Hibernate Will (instantly) hibernate (the system state is saved to disk and the machine is powered down) the device running Go Hass Agent.
  • Power Off Will (instantly) power off the device running Go Hass Agent.
  • Reboot Will (instantly) reboot the device running Go Hass Agent.
  • Power controls require a system configured with systemd-logind (and D-Bus) support.
• Various System Details:
  • Boot Time (date/Time of last system boot). Via ProcFS.
  • Uptime. Updated ~every 15 minutes. Via ProcFS.
  • Kernel Version (version of the currently running kernel). Updated on agent start. Via ProcFS.
  • Distribution Details:
  • Distribution Name (name of the running distribution, e.g., Fedora, Ubuntu).
  • Distribution Version (version of the running distribution).
  • Both updated on agent start. Via ProcFS.
  • Current Users (count of users with active sessions on the system). Updated when any session changes.
  • Attributes: List of usernames | When user count changes.
  • Via D-Bus. Requires systemd-logind.
  • ABRT Problems (count of any problems logged to the ABRT daemon). Updated ~every 15 minutes.
  • Attributes: extracted problem details.
  • Requires ABRT.
  • Hardware Sensors:
  • Any temp, fan, power and other hardware sensors, including associated alarms. Updated ~every 1 minute.
  • Extracted from the /sys/class/hwmon file system.

⬆️ Back to Top

🗒️ Versioning

This project follows semantic versioning. Given a version number MAJOR.MINOR.PATCH, the gist of it is:

• A MAJOR number change means there breaking changes from the previous release that may require manual intervention before/after upgrading.
• A MINOR number change means significant changes and new features have been added, but not breaking changes.
• A PATCH number change indicate minor changes and bug fixes.

⬆️ Back to Top

🧰 Getting Started

🤝 Compatibility

Currently, only Linux is supported. Though the code is designed to be extensible to other operating systems. See development information in the docs for details on how to extend for other operating systems.

🔽 Installation

📦 Packages

Head over to the releases page and download the appropriate package for your operating system and/or distribution:

• Fedora: use the .rpm.
• Ubuntu/Debian: use the .deb.
• Arch: use the .tar.zst.

Packages (and binaries) are available for amd64, arm (v7) and arm64 architectures.

For distributions not listed above, you can try the binary, or build it yourself from source (see development docs). Note that while Go is known for statically compiled binaries that “run anywhere”, the Fyne UI toolkit used by Go Hass Agent makes use of shared libraries that may need to be installed as well.

Package signatures can be verified with cosign. To verify a package, you'll need to download cosign.pub public key and the .sig file (downloaded from releases) that matches the package you want to verify. To verify a package, a command similar to the following for the rpm package can be used:

cosign verify-blob --key cosign.pub --signature go-hass-agent-*.rpm.sig go-hass-agent-*.rpm

🚢 Container

Container images are available on ghcr.io. Note that it is recommended to use an image tagged with the latest release version over the latest container image, which might be unstable.

⬆️ Back to Top

🕹️ Usage

Go Hass Agent runs as a tray icon by default. It is operating system, distribution and desktop-environment agnostic and should manifest itself in any tray of any desktop environment.

🔛 First-run

On first-run, Go Hass Agent will display a window where you will need to enter some details, so it can register itself with a Home Assistant instance to be able to report sensors and receive notifications.

You will need:

• A long-lived access token. You can generate one on your account profile page.
• The web address (URL) on which a Home Assistant instance can be found.
  • Go Hass Agent will try to auto-detect this for you, and you can select it in the Auto-discovered servers list. Otherwise, you will need to select Use Custom Server?, and enter the details manually in Manual Server Entry.

When you have entered all the details, click Submit and the agent should start running and reporting sensors to the Home Assistant instance.

👻 Running “Headless”

Go Hass Agent will automatically detect if there is no GUI available and run in a “headless” mode with no UI. Registration will need to be completed manually as a first step in such environments.

You can register Go Hass Agent on the command-line with by running:

go-hass-agent --terminal register --token _TOKEN_ --server _URL_

You will need to provide a long-lived token _TOKEN_ and the URL of your Home Assistant instance, _URL_.

Once registered, running Go Hass Agent again with no options should start tracking and sending sensor data to Home Assistant.

If desired, headless mode can be forced, even in graphical environments, by specifying the --terminal command-line option.

If you want to run Go Hass Agent as a service on a headless machine, see the FAQ.

🐳 Running in a container

There is rough support for running Go Hass Agent within a container. Pre-built images are available.

To register the agent running in a container, run the following:

podman run --rm --hostname go-hass-agent-container \
  --network host \
  --volume go-hass-agent:/home/ubuntu \
  ghcr.io/joshuar/go-hass-agent register \
  --server https://some.server:port \
  --token longlivedtoken

Adjust the --server and --token values as appropriate.

Once registered, run the agent with:

podman run --hostname go-hass-agent-container --name my-go-hass-agent \
  --network host \
  --volume go-hass-agent:/home/ubuntu \
  --volume /proc:/host/proc:ro --volume /sys:/host/sys:ro \
  --volume /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket:ro \
  --volume /run/user/1000/bus:/run/user/1000/bus:ro \
  --device /dev/video0:/dev/video0
  ghcr.io/joshuar/go-hass-agent # any additional options

Change the value passed to --name to a unique name for your running container and --hostname for the hostname that will be presented to Home Assistant during registration.

All the other volume mounts are optional, but functionality and the sensors reported will be severely limited without them:

• --volume /proc:/host/proc:ro --volume /sys:/host/sys:ro:
  • Enables various hardware and system monitoring sensors.
• --volume /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket:ro
• --volume /run/user/1000/bus:/run/user/1000/bus:ro
  • Enables sensors that are gathered via D-Bus.
• --device /dev/video0:/dev/video0
  • Allows webcam control (when configured with MQTT).

♻️ Regular Usage

When running, Go Hass Agent will appear as a device under the Mobile App integration in your Home Assistant instance. It should also report a list of sensors/entities you can use in any automations, scripts, dashboards and other parts of Home Assistant.

📌 Configuration Location

The configuration is located in a file called preferences.toml in CONFIG_HOME/go-hass-agent/ where CONFIG_HOME will OS-dependent:

• Linux: ~/.config.
• OSX: ~/Library/Application Support.
• Windows: LocalAppData.

While the configuration can be edited manually, it is recommended to let the agent manage this file.

Script Sensors

Go Hass Agent supports utilising scripts to create sensors. In this way, you can extend the sensors presented to Home Assistant by the agent. Note that as the agent is a “mobile app” in Home Assistant, any script sensors will be associated with the Go Hass Agent device in Home Assistant.

Each script run by the agent can create one or more sensors and each script can run on its own schedule, specified using a Cron syntax.

Requirements

• Scripts need to be put in a scripts folder under the configuration directory (see Configuration Location for the full path).
• You can use symlinks, if supported by your Operating System.
• Script files need to be executable by the user running Go Hass Agent.
• Scripts need to run without any user interaction.
• Scripts need to output either valid JSON, YAML or TOML. See Output Format for details.
• Commands do not invoke the system shell and does not support expansion/glob patterns or handle other expansions, pipelines, or redirections typically done by shells.

Supported Scripting Languages

Any typical scripting language that can be invoked with a shebang can be used for scripts. All scripts do not need to be written in the same language. So or the typical shells can be used such as Bash, Sh, Zsh, Fish, Elvish. Scripting languages such as Python, Perl, and Ruby can also be used.

Output Format

All scripts should produce output that is either valid JSON, YAML or TOML. Scripts do not need to use the same format; you can have one script that produces JSON and another that produces TOML. All scripts will need to output the following fields:

• A schedule field containing a cron-formatted schedule.
• A sensors field containing a list of sensors.

Sensors themselves need to be represented by the following fields:

• sensor_name: the friendly name of the sensor in Home Assistant (e.g., My Script Sensor).
• sensor_icon: a Material Design Icon representing the current state. It can be changed dynamically based on the current state or remain constant. Format is mdi:icon_name.
• sensor_state: the current value of the sensor. For numerical states, without the units. Otherwise, a string or boolean (for binary sensors).
  • Note: for a binary sensor, do not enclose the true/false in quotes.

The following optional fields can also be specified, which help control the display in Home Assistant.

• sensor_units: the units for the state value.
• sensor_type: the type of sensor. If this is a binary sensor with a boolean value, set this to “binary”. Else, do not set this field.
• sensor_device_class: a Home Assistant Device Class for the sensor, which will dictate how it will be displayed in Home Assistant. There are many, pick an appropriate one (see internal/hass/sensor/deviceClass.go). If setting sensor_device_class, it is likely required to set an appropriate unit in sensor_units as well.
• sensor_state_class: the Home Assistant State Class. Either measurement, total or total_increasing.
• sensor_attributes: any additional attributes to be displayed with the sensor. Note that the value is required to be valid JSON, regardless of the script output format.

Examples

The following examples show a script that produces two sensors, in different output formats.

JSON

JSON output can be either compressed:

{"schedule":"@every 5s","sensors":[{"sensor_name": "random 1","sensor_icon": "mdi:dice-1","sensor_state":1},{"sensor_name": "random 2","sensor_icon": "mdi:dice-2","sensor_state_class":"measurement","sensor_state":6}]}

Or pretty-printed:

{
  "schedule": "@every 5s",
  "sensors": [
    {
      "sensor_name": "random 1",
      "sensor_icon": "mdi:dice-1",
      "sensor_state": 2
    },
    {
      "sensor_name": "random 2",
      "sensor_icon": "mdi:dice-2",
      "sensor_state_class": "measurement",
      "sensor_state": 6
    }
  ]
}

YAML

schedule: '@every 5s'
sensors:
    - sensor_name: random 1
      sensor_icon: mdi:dice-1
      sensor_state: 8
    - sensor_name: random 2
      sensor_icon: mdi:dice-2
      sensor_state_class: measurement
      sensor_state: 9

TOML

schedule = '@every 5s'

[[sensors]]
sensor_icon = 'mdi:dice-1'
sensor_name = 'random 1'
sensor_state = 3

[[sensors]]
sensor_icon = 'mdi:dice-2'
sensor_name = 'random 2'
sensor_state = 3
sensor_state_class = 'measurement'

For a binary sensor, the output should have sensor_type set to “binary” and the sensor_state as true or false (without quotes). As an example in compressed JSON format:

{"schedule":"@every 10s","sensors":[{"sensor_name":"random 4","sensor_type":"binary","sensor_icon":"mdi:dice-3","sensor_state":false}]}

Schedule

The schedule field is used to specify the schedule or interval on which the script will be run by the agent. Each script is run on its own schedule. All sensors and their values should be returned each time the script is run. The format is documented by the cron Golang package. In most cases, it is presumed that the script needs to be run on some interval of time. In that case, the easiest way to specify that is with the `@every