Skip to content

MQTT: fix float format #27046

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
premultiply wants to merge 1 commit into from
Closed

MQTT: fix float format #27046

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion server/mqtt.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,11 @@ func (m *MQTT) encode(v any) string {
case string:
return val
case float64:
return fmt.Sprintf("%.5g", val)
// format with up to 3 decimals, trim trailing zeros
Copy link
Member

@andig andig Jan 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is MQTT and not some kind of frontend display: why do we even need to trim trailing digits? Lets keep it simple.

s := fmt.Sprintf("%.3f", val)
s = strings.TrimRight(s, "0")
s = strings.TrimRight(s, ".")
return s
case time.Time:
if val.IsZero() {
return ""
Expand Down
11 changes: 11 additions & 0 deletions server/mqtt_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,17 @@ func TestMqttNaNInf(t *testing.T) {
assert.Equal(t, "+Inf", m.encode(math.Inf(0)), "Inf not encoded as string")
}

func TestMqttEncodeFloat(t *testing.T) {
m := &MQTT{}
assert.Equal(t, "12345.678", m.encode(12345.678), "large energy value with 3 decimals")
assert.Equal(t, "12345.6", m.encode(12345.6), "large energy value with 1 decimal")
assert.Equal(t, "12345", m.encode(12345.0), "large energy value without decimals")
assert.Equal(t, "0.123", m.encode(0.123456), "small value truncated to 3 decimals")
Copy link

Copilot AI Jan 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test description says "truncated to 3 decimals" but fmt.Sprintf with %.3f actually rounds to 3 decimal places, not truncates. Consider changing "truncated" to "rounded" in the test description for accuracy. For example, 0.1236 would become "0.124" (rounded up), demonstrating rounding behavior rather than truncation.

Suggested change
assert.Equal(t, "0.123", m.encode(0.123456), "small value truncated to 3 decimals")
assert.Equal(t, "0.123", m.encode(0.123456), "small value rounded to 3 decimals")

Copilot uses AI. Check for mistakes.
assert.Equal(t, "1.2", m.encode(1.2), "value with 1 decimal")
assert.Equal(t, "0", m.encode(0.0), "zero")
assert.Equal(t, "2500", m.encode(2500.0), "power value without decimals")
Comment on lines +21 to +29
Copy link
Contributor

@sourcery-ai sourcery-ai bot Jan 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (testing): Add tests that explicitly cover rounding at the 4th decimal place to ensure the behavior of the new format is locked in

Current tests only cover values that don’t stress rounding at the 4th decimal. Please add cases like 0.1239 → "0.124" and 1.9999 → "2" (or whatever is expected) to explicitly assert the rounding behavior of "%.3f" and guard against regressions from rounding to truncation.

}
Comment on lines +21 to +30
Copy link

Copilot AI Jan 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test coverage should include negative numbers to ensure the formatting works correctly for negative values (e.g., -12345.678, -0.123). While the implementation should handle them correctly, explicit test coverage would be valuable given that energy and power can be negative (e.g., during feed-in).

Copilot uses AI. Check for mistakes.
Comment on lines +21 to +30
Copy link

Copilot AI Jan 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding test coverage for very large numbers (e.g., values > 1e6) to verify that the formatting produces reasonable output. The old format used scientific notation for very large values, while the new format will produce fixed-point notation which could result in very long strings for extremely large values. However, this might be acceptable depending on the expected range of energy/power values in the application.

Copilot uses AI. Check for mistakes.

type measurement struct {
Power float64 `json:"power"`
Energy float64 `json:"energy,omitempty"`
Expand Down
Loading