RCT: improve battery control

[Maschga]

Ref #25243 (reply in thread)

\cc @andig

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• Consider explaining or replacing the magic values 0, 1032, and 2048 with named constants to make the valid battery operating modes self-documenting and easier to maintain.
• Now that batStatus is queried unconditionally, double-check that the extra request for api.BatteryNormal mode is intentional and acceptable from a performance/latency perspective.
• The new TRACE log for every batteryMode call may be quite chatty; you might want to log only on state changes or unexpected statuses to keep trace output manageable.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider explaining or replacing the magic values `0`, `1032`, and `2048` with named constants to make the valid battery operating modes self-documenting and easier to maintain.
- Now that `batStatus` is queried unconditionally, double-check that the extra request for `api.BatteryNormal` mode is intentional and acceptable from a performance/latency perspective.
- The new TRACE log for every `batteryMode` call may be quite chatty; you might want to log only on state changes or unexpected statuses to keep trace output manageable.

## Individual Comments

### Comment 1
<location> `meter/rct.go:143` </location>
<code_context>
+			if mode != api.BatteryNormal {
 				// check for normal operating mode
-				if batStatus != 0 && batStatus != 1032 {
+				if batStatus != 0 && batStatus != 1032 && batStatus != 2048 {
 					return fmt.Errorf("invalid battery operating mode: %d", batStatus)
 				}
</code_context>

<issue_to_address>
**suggestion:** Replace magic numeric battery status values with named constants or enums for clarity and maintainability.

These literal values (`0`, `1032`, `2048`) are non-obvious and make the condition harder to read and maintain. If the rct package (or a related module) doesn’t provide symbolic values for these statuses, consider introducing named constants (e.g. `BatteryStatusNormal`, `BatteryStatusX`, `BatteryStatusY`) so the intent is clear and the values can be safely reused or updated in one place.

Suggested implementation:

```golang
package meter

const (
	batteryStatusNormal      = 0
	batteryStatusCharging    = 1032
	batteryStatusDischarging = 2048
)

```

```golang
				// check for normal operating mode
				if batStatus != batteryStatusNormal &&
					batStatus != batteryStatusCharging &&
					batStatus != batteryStatusDischarging {
					return fmt.Errorf("invalid battery operating mode: %d", batStatus)

```

1. Adjust the constant names (`batteryStatusNormal`, `batteryStatusCharging`, `batteryStatusDischarging`) if you have domain-specific terminology for these status codes (e.g. “float”, “bulk”, etc.), or if there are existing naming conventions/constants in this package.
2. If these status values are used elsewhere in the codebase, update those usages to reference the new constants for consistency.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}