Hello all, since I’ve updated to 0.87.0 I have a problem with my MQTT Lights. It keeps saying “brightness” is an invalid option for mqtt.light. But in the documentation it is exactly as my configuration.yaml.
Invalid config for [light.mqtt]: [brightness] is an invalid option for [light.mqtt]. Check: light.mqtt->brightness. (See ?, line ?). Please check the docs at https://home-assistant.io/components/light.mqtt/
Is this just a bug or do I need to change something? Thanks a lot!
I’m running into a similar issue, but with the transition and color_temp_value_template settings. It looks like v0.87 made some changes to JSON lights, so some properties are now invalid. However, I’m stuck at how to fix it without just removing the property altogether.
Here’s a sample of some of my yaml that’s causing problems:
I believe a change is required, but I’m not sure what that change needs to be. Little documentation to help us manage the changes introduced. Would love to see some better documentation around these breaking changes (e.g. a migration guide would help for sure).
MQTT platforms will now flag mistyped configs from configuration.yaml correctly as invalid, instead of just ignoring them. (@emontnemery - #20562) (mqtt docs) (breaking change)
It looks like the documentation is now wrong, as the default schema (the one which I’m using) doesn’t contain the brightness/rgb/color temp/ boolean options, but the json schema does. If you’re using schema:json and it’s still rejecting the brightness, then that’s a documentation issue
Thanks for the clarification. You’re right, the documentation for an MQTT Light using JSON schema does indicate that brightnessis a valid option. So either the documentation is incorrect or there’s a bug in 0.87 that fails to consider this is the json schema version and wrongly flags the brightness option as an error.
Is it solved in 0.87.1(nothing said on the release notes)?? I’m having the same issue, my mqtt driven lights don’t work with brightness option but if I delete it, my lights won’t work properly either.