Rebuild in Go

[timmo001]

Background

The app became way too large and disconnected, having multiple different codebases, multiple languages etc.

The aim of this is to consolidate as much as possible and make the app as performant using a purely compiled language, which is very familiar.

I recently built go-automate which is very simple and allows a simple way to interface with home assistant or notifications in linux using a CLI tool. I also internally made another tool called go-reminders which I call go-automate to send myself reminders on a CRON like schedule to my desktop. This is where the inspiration came from for rebuilding the app.

Moving away from rust

The rust system was purely an interface between a frontend and a python backend previously. The main goal now is to not do that and keep the app simple and easy to maintain.

Goals

The final goal will be to iterate and make changes fast using go and interfacing with system commands or other tools

The first step is to get Home Assistant to connect and control the system using the current features

I am also introducing MacOS support here which previously I didn't. I don't have any apple devices so these will be untested, so any community contributions will be the driving forces here.

Linux and Windows will be the supported systems, where mac will become a "You can compile and try it" platform. If the community supports the mac side, we can release and unofficially support it.

This is not a like-for-like replacement. There will be some missing features. These parts should be left as stubs or set to the default, what home assistant expects, so there are no added errors day 0.

Personally I have not been using the app, mainly due to CPU/Memory usage, so this is a personal goal to make the app run as a small service which keeps low on system usage.

TODO

• Rebuild core systems
• Home Assistant testing
• Build installer / packages
• Use additional windows sensors (optional)
  • Build windows sensors and upload to github release
  • Download latest release windows sensors to lib/sensors/windows/bin/ via GH workflows
• Add service documentation. Add to installer
• Web client #3399
  • Bundle web client with binary #3411
  • Fix settings update
• Add missing data for all plaforms - See TODOs, focus on Home Assistant entities
• Hide windows terminal from link - Potential fix in https://github.com/timmo001/go-commands/blob/a2224d4f7397abf3faa1076121a9a16eb0769a05/setup-startup.ps1
• Hide sensors window popup
• Show web client on desktop launch shortcut
• Add arch linux package (PKGBUILD) to upload
• Go Rebuild - System Tray? #3412
• Test binaries / packages
• Fix CI release drafting - https://github.com/timmo001/system-bridge/actions/runs/14550202679/job/40820535311

Continued in #3475

Confirmed supported working packages

• Appimage
• Flatpak
• DEB
• RPM
• PKGBUILD (Arch Linux)
• Windows (Setup)

Notes

There are a lot of TODOs left after this refactor. The plan is not to build a like for like replacement. The main goal is to create something that works with the Home Assistant integration without any changes and from there we iterate for 5.x.x changes

These repositories are now archived:

• https://github.com/timmo001/system-bridge-backend
• https://github.com/timmo001/system-bridge-cli
• https://github.com/timmo001/system-bridge-shared
• https://github.com/timmo001/system-bridge-frontend

[kevinschweikert]

For self hosting you could alternatively embed the contents directly in the Go binary and serve them with the existing web server

//go:embed web_server/build/*
var content embed.FS

http.Handle("/static/", http.StripPrefix("/static/", http.FileServer(http.FS(content))))

[kevinschweikert]

Hey @timmo001,

thank you so much, for all you work you put in! We are actively using the new Go build and i would like to propose some architectural changes, but i wanted to run them by you if you feel the same or have another structure in mind.

Interfaces

Currently there is code like this:

Example 1

func (m *Module) updateModule() (any, error) {
	switch m.Module {
	case types.ModuleBattery:
		return m.UpdateBatteryModule()
	case types.ModuleCPU:
		return m.UpdateCPUModule()
	case types.ModuleDisks:
		return m.UpdateDisksModule()
	case types.ModuleDisplays:
		return m.UpdateDisplaysModule()
	case types.ModuleGPUs:
		return m.UpdateGPUsModule()
	case types.ModuleMedia:
		return m.UpdateMediaModule()
	case types.ModuleMemory:
		return m.UpdateMemoryModule()
	case types.ModuleNetworks:
		return m.UpdateNetworksModule()
	case types.ModuleProcesses:
		return m.UpdateProcessesModule()
	case types.ModuleSensors:
		return m.UpdateSensorsModule()
	case types.ModuleSystem:
		return m.UpdateSystemModule()
	default:
		return nil, fmt.Errorf("module not found: %s", m.Module)
	}
}

and

Example 2

	switch module {
	case types.ModuleBattery:
		m = &d.Battery
	case types.ModuleCPU:
		m = &d.CPU
	case types.ModuleDisks:
		m = &d.Disks
	case types.ModuleDisplays:
		m = &d.Displays
	case types.ModuleGPUs:
		m = &d.GPUs
	case types.ModuleMedia:
		m = &d.Media
	case types.ModuleMemory:
		m = &d.Memory
	case types.ModuleNetworks:
		m = &d.Networks
	case types.ModuleProcesses:
		m = &d.Processes
	case types.ModuleSensors:
		m = &d.Sensors
	case types.ModuleSystem:
		m = &d.System
	default:
		log.Error("Module not found", "module", module)
		empty := data_module.Module{}
		return &empty
	}

This makes it hard to add new modules, because we have to differentiate them in every loop. What about coupling the data and with an interface and skip the modules altogether? Something like:

type Updater interface {
    Name() types.ModuleName
    Collect(ctx context.Context) (any, error)
}

type System struct {
	Hostname              string
}

func (s System) Name() types.ModuleName {
     return types.ModuleName.System
}

func (s *System) Collect() Collectable {
       s.Hostname  = os.Hostname()
       return s, nil
}

Then we would only need to register this struct once and can access the module name for the subscribers and have a common interface to update the data. This would make the above example to something like this:

type ModuleMeta struct {
    Updater Updater
    Data    any
    Updated time.Time
}

type DataStore struct {
    mu      sync.RWMutex
    modules map[types.ModuleName]*ModuleMeta
}

func (ds *DataStore) Register(u Updater) {
    ds.mu.Lock(); defer ds.mu.Unlock()
    ds.modules[u.Name()] = &ModuleMeta{Updater: u}
}

Hope my ideas and thoughts are clear and if there are any questions i am happy to answer! I would be interested in you opinion on these concepts, if there are reasons against it or personal preferences are different and if you would like to see them implemented. I can cut out some time to work on this.