Crash using i3

[CaporalDead]

Describe the bug

The app crashes immediately after configuration when getting Unsupported desktop/window environment.

To Reproduce

Steps to reproduce the behavior:

1. Use i3 along with Arch
2. Launch go-hass-agent binary (v4.1.1)

Expected behavior

It should not crash, at least, it should skip to the next part.

Logs

go-hass-agent --debug
2:13AM DBG Debug logging enabled.
2:13AM DBG Setting language to [fr-FR].
2:13AM DBG Registration status is true
2:13AM WRN Unsupported desktop/window environment.
2:13AM DBG ../runner/work/go-hass-agent/go-hass-agent/internal/linux/appSensor.go:128 > Unsupported or unknown portal
2:13AM WRN Unable to execute org.freedesktop.problems.GetProblems on org.freedesktop.problems (args: []) error="The name org.freedesktop.problems was not provided by any .service files"
2:13AM WRN Unable to retrieve property net.hadess.PowerProfiles.ActiveProfile (net.hadess.PowerProfiles) error="The name net.hadess.PowerProfiles was not provided by any .service files"
2:13AM DBG Cannot retrieve a power profile from DBus. error="The name net.hadess.PowerProfiles was not provided by any .service files"
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x876552]

goroutine 84 [running]:
github.com/joshuar/go-hass-agent/internal/hass/api.StartWebsocket.func1()
	/home/runner/work/go-hass-agent/go-hass-agent/internal/hass/api/websocket.go:65 +0x112
github.com/cenkalti/backoff/v4.RetryNotifyWithTimer.func1()
	/home/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.2.1/retry.go:18 +0x1b
github.com/cenkalti/backoff/v4.doRetryNotify[...](0xc0005b1e58?, {0x7fd4ecbbb008, 0xc00068e320}, 0x0, {0x0, 0x0?})
	/home/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.2.1/retry.go:88 +0x152
github.com/cenkalti/backoff/v4.RetryNotifyWithTimer(0x0?, {0x7fd4ecbbb008?, 0xc00068e320?}, 0xdbbcc0?, {0x0?, 0x0?})
	/home/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.2.1/retry.go:61 +0x65
github.com/cenkalti/backoff/v4.RetryNotify(...)
	/home/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.2.1/retry.go:49
github.com/cenkalti/backoff/v4.Retry(...)
	/home/runner/go/pkg/mod/github.com/cenkalti/backoff/v4@v4.2.1/retry.go:38
github.com/joshuar/go-hass-agent/internal/hass/api.StartWebsocket({0x10b6328?, 0xc000122050}, {0x10aec40, 0xc0002fbcc0}, 0xc0006aa0c0, 0xc0006aa120)
	/home/runner/work/go-hass-agent/go-hass-agent/internal/hass/api/websocket.go:73 +0x27c
github.com/joshuar/go-hass-agent/internal/agent.(*Agent).runNotificationsWorker.func2()
	/home/runner/work/go-hass-agent/go-hass-agent/internal/agent/notifications.go:43 +0xad
created by github.com/joshuar/go-hass-agent/internal/agent.(*Agent).runNotificationsWorker
	/home/runner/work/go-hass-agent/go-hass-agent/internal/agent/notifications.go:40 +0x1ea

Desktop (please complete the following information):

• OS: Arch
• Version: 4.1.1
• Desktop env: i3 version 4.22 (2023-01-02)

Thanks for your work 🙏

[CaporalDead]

Sorry for the bad title. I updated it. Let me know if I can help you running some tests !

[joshuar]

Ugh, that's an ugly way for the program to crash :( I can reproduce a similar crash in an Arch toolbox on my Fedora machine.

Would you be able to do some digging for me and:

• look in the file ~/.config/fyne/com.github.joshuar.go-hass-agent/preferences.json and let me know what the value of the WebSocketURL is (I don't need the exact hostname, just the sheme and path, so please obscure it for privacy if needed).
• if you were using a previous version without this issue, what version was that? In that case I can diff the changes in the source between that version and 4.1.1 to do some sleuthing.

Thanks for trying out go-hass-agent!

[joshuar]

I believe that the issue is fixed with commit 6603e06. Can you try out the attached version that has this commit backported on top of the 4.1.1 version?

go-hass-agent-4.1.1SNAPSHOT_32ac45e-1-x86_64.pkg.tar.zst.gz

The commit will also be in the next major version of go-hass-agent, but that will also have a major breaking change to the config, so I want to avoid trying both that change and this fix at the same time.

[CaporalDead]

Hi @joshuar,

Sorry for the delay. I tried the snapshot you gave me and, indeed, it seems to work well.

However, I still have an error :

Could not connect to websocket. error="tls: either ServerName or InsecureSkipVerify must be specified in the tls.Config"

It does not seems to prevent it from working.

The hass.websocketurl and WebSocketURL looks like this :

wss://HOST:PORT/api/websocket

My certificate is generated with letsencrypt and is currently valid.

Let me know if you want me to create a new issue about that.

Thanks !

[CaporalDead]

Fun fact, using the snapshot you gave me, I can't register my computer if I'm starting from scratch. I had to re-install the latest stable release, then re-install your snapshot to get it to work.

Here is the result of the register command with the debug flag on the snapshot you gave me :

8:55AM DBG Debug logging enabled.
8:55AM DBG Setting language to [fr-FR].
8:55AM FTL Could not export apiURL. error="key hass.apiurl not set"

[CaporalDead]

Another strange behavior, the GUI seems to ignore the --token and --server input from the command line

[joshuar]

Hi @joshuar,

Sorry for the delay. I tried the snapshot you gave me and, indeed, it seems to work well.

Brilliant!

However, I still have an error :

Could not connect to websocket. error="tls: either ServerName or InsecureSkipVerify must be specified in the tls.Config"

I've been struggling to either understand and replicate the cert issue. I think this might be an underlying library issue, but I'll have to spend more time trying to recreate and then fix.

It does not seems to prevent it from working.

Most likely this issue will block notifications from Home Assistant to the agent working for you unfortunately.

The hass.websocketurl and WebSocketURL looks like this :

wss://HOST:PORT/api/websocket

My certificate is generated with letsencrypt and is currently valid.

Let me know if you want me to create a new issue about that.

No need, I'll keep digging on this.

Fun fact, using the snapshot you gave me, I can't register my computer if I'm starting from scratch. I had to re-install the latest stable release, then re-install your snapshot to get it to work.

Here is the result of the register command with the debug flag on the snapshot you gave me :

8:55AM DBG Debug logging enabled.
8:55AM DBG Setting language to [fr-FR].
8:55AM FTL Could not export apiURL. error="key hass.apiurl not set"

Yes! I discovered a bug with the command-line registration flow. The issues should be fixed in the next major version.

Another strange behavior, the GUI seems to ignore the --token and --server input from the command line

This is expected :) The way I had planned registration was that the GUI registration process was:

1. Open go-hass-agent via your desktop application menu.
2. It opens a window asking you for all the details.

The --token and --server options were instead intended for a non-GUI registration flow in combination with the --terminal option (i.e., go-hass-agent --terminal register --server foo --token bar). For example, on a server.

I didn't envision people starting a graphical registration flow from the command-line and specifying the --token and --server options. Though I can see that is a possible way with the command-line options parsing. I can change the code to support this though, I'll add it in.

Thanks again for trying go-hass-agent. I hope despite these issues it is providing some usefulness!

[CaporalDead]

Oh ok, sorry, from my understanding, the documentation does not explicitly says that the --terminal flag is mandatory with the --token and --server flags :

As alternative, you can register Go Hass Agent on the command-line with by running:

go-hass-agent register --token TOKEN --server URL
You will need to provide a long-lived token TOKEN and the URL of your Home Assistant instance, URL.

But indeed there is a section about running the binary headless wich make sense. Sorry about that :)

Thanks for the detailed answer !

[joshuar]

Hey no problem and no need to apologise! I can always improve the documentation :) I'll release v5.0.0 shortly that will have the fix for the websocket (to at least not crash) and command-line registration. I'm still working on the cert issue you are facing, any fix will be in a patch release. Fingers crossed I can work out some kind of fix.

[joshuar]

Closing this issue as I believe we worked it out 🎉 If this is still an issue, lets re-open.