theiding
commented
4 years ago I personally suggest to set the hard-coded default to false, as the state override intuitively appears to be a feature that the user needs to be aware of and as such should request. If not configured per item or system-wide it appears that no override is the ideal default. However, that of course breaks existing backwards compatibility, as state override is currently always on. If breaking that backwards compatibility is no longer viewed as an option then a hard-coded false default is not an option.
The implementation is of course trivial and I have the code based on a config option "brightness_override_by_state" available. Happy to submit the PR.
5iver
The current implementation of light_action offers a feature to exclude items from automation with state 99 or 100. This is a powerful feature, but doesn't apply to all situations, for example when a light at full intensity should remain under automation or if overrides are managed in a different fashion. The ask is to make the state based automation override configurable, so it can be turned off in cases where it doesn't apply. Consistent with already existing configuration options configuration should be available per item via the "area_triggers_and_actions" metadata configuration, and if not configured defaulting to system-wide configuration via the default_levels in area_triggers_and_actions_dict, and if that is not configured either then default to hard-coded on or off. An available workaround is to duplicate light_action and to remove the override support explicitly. However, this requires coding and duplication of code for a common use case and is therefore undesirable.