mirror of
https://github.com/esphome/esphome.git
synced 2026-07-10 08:55:36 +00:00
J. Nick Koston
15cb2c0580
The min_power / max_power / zero_means_zero scaling support on FloatOutput costs 12 bytes per instance (max_power_, min_power_, zero_means_zero_ + alignment padding) on every PWM channel, DAC channel, LEDC output, and dimmer-chip channel — even on configs that never touch the feature. Repo-wide usage is ~17 YAML lines, mostly in test fixtures and a couple of LED-driver chip tests; the runtime set_min_power / set_max_power actions added in #8934 have no usage outside the action's own test. Add USE_OUTPUT_FLOAT_POWER_SCALING and gate the fields and scaling math in FloatOutput::set_level() behind it, mirroring the USE_POWER_SUPPLY pattern already used in BinaryOutput. Python codegen flips the define on whenever: - a min_power / max_power / zero_means_zero key is set on any output, or - a non-default zero_means_zero value is provided, or - an output.set_min_power / output.set_max_power action is registered The action class templates (SetMinPowerAction, SetMaxPowerAction) are also gated on the same define so their non-dependent member access on FloatOutput::set_min_power doesn't fail to parse when the methods aren't compiled in. zero_means_zero_ now has a default initializer (was UB before — it was always written from setup, but only because the schema default forced it). For configs without scaling: 12 B .bss saved per FloatOutput instance, plus a small flash saving from the elided multiply/subtract in set_level(). For configs with scaling: behavior is unchanged. Verified on tests/components/esp8266_pwm (no scaling): pstorage 0x28 → 0x1c per output (40 B → 28 B). Verified on tests/components/output (uses set_min_power/set_max_power actions): builds correctly with the define on.
