Skip to content

Send power to Wavelog as int - #8

Closed
mattmelling wants to merge 1 commit into
johnsonm:mainfrom
mattmelling:int-power
Closed

mattmelling wants to merge 1 commit into
johnsonm:mainfrom
mattmelling:int-power

Conversation

@mattmelling

Copy link
Copy Markdown
Contributor

In Wavelog 3.2.0 onwards Power must be an int. We've always sent a scaled float64, however I noticed that this broke after upgrading recently.

Specifically they do this check (modified for clarity) in application/models/Cat.php:

if (!is_numeric($power) || (int) $result[$power] != $result[$power]) {
    // flag as invalid field
}

That means that if we send 50W as 50.0 it effectively checks if str(50.0) == int(50.0) or "50.0" == 50, which fails and result in:

Sep 06 10:43:03 mars waveloggoat[374598]: time="2026-09-06T10:43:03+01:00" level=error msg="Error posting to Wavelog: wavelog API returned non-200 status code: 400. Body: {\"error\":{\"code\":\"validation_error\",\"message\":\"Invalid field(s): power\",\"details\":{\"invalid\":[\"power\"]}}}"

I will also raise an issue with Wavelog side as this seems like a regression on their side (I want to log my 0.5W QRPP QSOS?!), but in the meantime this gets the Goat working with 3.2.0 :)

In Wavelog 3.2.0 onwards Power must be an int.
@johnsonm

johnsonm commented Sep 7, 2026

Copy link
Copy Markdown
Owner

Huh. I'm still running 3.1.0 locally, and clipping power to an int feels like an upstream regression, because QRPp exactly. I don't run QRPp much myself, but I'd like to be able to log it.

I don't see that you've filed a bug upstream, but when you do please link it here.

@johnsonm

johnsonm commented Sep 7, 2026

Copy link
Copy Markdown
Owner

I'll look at using the version API to encode the power differently depending on what wavelog is upstream.

@mattmelling

Copy link
Copy Markdown
Contributor Author

Roger. I're reported to Wavelog here.

I agree that truncating to an int feels a bit ropey, I would prefer the upstream behaviour to revet back to how it worked in earlier versions.

Will raise a PR with them later on. Hopefully we can close this PR unmerged but I wanted to share in case anyone else spent a few minutes scratching their heads over this!

@johnsonm

johnsonm commented Sep 7, 2026

Copy link
Copy Markdown
Owner

Apparently there is no way to get the version info from the v2 API, so to do this requires adding a v1 API key AND a v2 API key. I had hoped the status endpoint might give version information, but no such luck.

https://docs.wavelog.org/developer/api-v2/

And of course I had transitioned to the v2 API and put in explicit migration to make the key be a wl2_ key.

I like the idea of logging version, so I'm going to at least do that, including the configuration to add another key because API v2 doesn't support it.

@johnsonm

johnsonm commented Sep 7, 2026

Copy link
Copy Markdown
Owner

Commit d5aa85f adds configuring a v1 API key and fetching the version at start. Not yet released.

@johnsonm

johnsonm commented Sep 7, 2026

Copy link
Copy Markdown
Owner

Commit 957a842 adds sending integer power to 3.2.0 or higher. When it's fixed upstream, we can add a new upper bound as well. This only works with a v1 api key.

Not yet released. Please test against 3.2.0 before I release, since I'm still running 3.1.0 🤣

@johnsonm

johnsonm commented Sep 7, 2026

Copy link
Copy Markdown
Owner

OK, if you provide a v1 API key, then WaveLogGoat v0.4.0, just now released, or later will send power as int to wavelog only if the version information (which requires v1 API key authentication) indicates exactly 3.2.0. Before or after that it will send a float.

I'll count that as closing this PR.

@johnsonm johnsonm closed this Sep 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants