Templates: pass bool params as real booleans

[ickeundso]

Follow-up to the discussion in #32219.

Bool params reached the template render as strings, so templates had to compare eq .param "true" and a plain {{ if .param }} was always true — the non-empty string "false" is truthy. Bool params are now real booleans, every comparison uses the boolean form, and a bool default is validated to be true/false.

This fixes six toggles that never had an effect, because their template used truthiness:

template	param	effect until now
meter/openems-modbus	battery	batterymode block always rendered
messenger/homeassistant	critical	ttl: 0 / priority: high always sent
meter/demo-battery	controllable	batterymode block always rendered
meter/demo-meter	curtailable	curtail block always rendered
meter/deye-hybrid-3p	includegenport	gen port always summed into pv
charger/vehicle-api	geofence_enabled	geofence keys always emitted (harmless, the block carries the flag itself)

Every template was rendered with each of its bool params unset, true and false before and after the change and the outputs diffed — the table is the result of that comparison.

Note for existing installations: openems-modbus users relying on the unintended always-on battery control, and HA-messenger users relying on unconditional ttl: 0/priority: high, have to enable the respective toggle now.

Otherwise backward compatible. String "true"/"false" from stored configs keeps working, and an unset bool renders as false instead of empty, which decodes to the same zero value — verified that no affected Go struct pre-sets those fields. Two templates needed an explicit default to pin current behaviour: meter/batterx externalpv (unset previously matched ne "false") and vehicle/flobz wakeup_alt, which was used as a bool but declared untyped.

The config UI seeded bool defaults as strings, which made its "field is empty" checks see a filled field; defaults are booleans there as well now.

TestAllTemplatesRenderWithBoolParams renders every template across all classes with each bool param set both ways in every usage, so a reintroduced string comparison fails the build. It earned its keep during the rebase: demo-meter curtailable, deye-hybrid-3p includegenport and firmware1098 had picked up the string form in the meantime and were caught immediately.

Not covered: util/templates/modbus.tpl uses the same truthiness pattern on .tcpip / .udp / .rs485serial / .rs485tcpip. Those are predefinedTemplateProperties rather than declared params, so this change does not reach them and a config with tcpip: false still selects the wrong branch. Same bug class, but it needs its own fix.

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="util/templates/template.go" line_range="431-439" />
<code_context>
 		}
 	}

+	// bool params are rendered as real booleans so templates can use
+	// `{{ if .param }}` instead of comparing against "true"/"false"
+	for _, p := range t.Params {
+		if p.Type == TypeBool {
+			if s, ok := res[p.Name].(string); ok {
+				res[p.Name] = s == "true"
+			}
+		}
+	}
+
 	// class-local includes take precedence over the global ones
</code_context>
<issue_to_address>
**issue (broader_impact):** Boolean conversion is limited to declared `t.Params`, so predefined boolean-like properties such as `tcpip`, `udp`, `rs485serial`, and `rs485tcpip` remain strings in the render context. The `modbus.tpl` truthiness checks therefore still treat the stored string "false" as true and select the wrong Modbus branch.

**Triggers:** When a Modbus configuration contains one of the predefined interface properties explicitly set to the string "false".

**Suggested fix:** Convert the predefined boolean properties before rendering as well, or update `modbus.tpl` to compare their values using the same normalized boolean representation.
</issue_to_address>

Sourcery assessment

Needs a human reviewer. 1 finding to address first, and this changes boolean parameter semantics in the shared renderer and across many device templates, so an incorrect conversion or migrated condition could produce a wrong device configuration or feature set. Reverting prevents future incorrect renders, but configurations already generated or applied would need to be regenerated or repaired.

Blocking findings: util/templates/template.go:439

---

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.}

[andig]

Great PR, thanks for drilling into this one.