With brightness slider, it wasn’t me. I don’t think its good UX. For example when it would be dark and you miss slider ( set 10% instead of 9), you suddenly got very bright light, because of change between moonlight and daylight mode.
With main light being off, when nightlight is enabled, you loose ability to turn off ceiling light with the same switch, for example when light will be exported to Alexa / GA etc, you could expect by saying turn off ceiling to turn off ceiling, but it would be already off. It could be some config option to have main light entity on or off, when in nightlight mode.
I wouldn’t say its bad. Maybe in context of voice assistants. But it could be configured to make main entity to be on, when moonlight is on, so you could turn off ceiling, with any of the 2 lights ( main / moon ). If anyone wants to play with it, I will have some experimental code, with major refactor ready to play with this 2 light entities approach, 3 for 650 light
EDIT: Just tested it and its possible to double turn off device via Google Home and HA.
@Michal_Ciemiega I don’t think the brightness difference between 100% moonlight and 1% normal is such a bad jump, or at least not on our ceiling lights. But if that is a concern, it’s still easy to implement a let say, 5% dead-band. Like map 1%-15% to 1%-100% moonlight and 20%-100% to 1%-100% normal, while leaving it at the same state as it was between 15% and 20%.
Maybe not, probably it could be handled nice somehow. I’ve tried to change brightness via few % on android and for me it seems kind hard. I think its possible to provide some nightlight_change_type with possible options like brightness/double_lights/extra_switch/something/etc ? Like in mqtt https://www.home-assistant.io/components/light.mqtt/#on_command_type
It might be my personal preference, but I’d rather not have two different modes for the same thing. IMHO there really should be a seamless transition all the way from dim moonlight to full power; I don’t care what mode, I’m only interested in the actual brightness.
I think Michal is right - a smooth or seamless transition between moon mode and daylight mode will probably not be possible because in my experience, there is a significant jump between the brightest moonlight and the darkest daylight. Furthermore, the light temperature may also change…
I would prefer a switch between daylight and moonlight mode because it is more intuitive and closer to the actual light architecture. For those interested in the brightness transition, a template_light pointing its set_level to a script that provides this transition feature could probably be sufficient to achieve the desired behavior.
The specifications/features (color support, temperature range, brightness setting/range) of a light entity shouldn’t change over time if we want proper Alexa / Google Home support.
Please no moonlight on main light brightness slider, that will create more problems in the long run, specially when you try to match brightness over differentl light entities.
Two lights isn’t an ideal solution but it was what I was doing for months. If you can tie behaviour so that the yeelight is off when moonlight is on and vice versa would be great.
Its possible to do whatever we want. We could make one on when other is off. Or mainlight on when moonlight is on. Or make it as switch. Or do something different ?
What would be ideal solution ?
Two light solution, what should happen when main light is off ( from moonlight mode ) and you turn it on ? Default would be to use previous power mode, so still moonlight. It could be forced to turn on in normal mode always, but then what about other lights, like bulb ? Should it always turn on in normal mode ? Even it was in flow mode before ?
Now yeelight turn in last mode. So another config option, per light for default turn on power mode ? I’ve been thinking about this for some time and can’t come up with solution that, in my opinion seems good. All ideas welcome
I think @syssi has good point, about not changing light specification. In current version, when you change light to moonlight, it still gives temperature range slider. Thats wrong, because changing it, will turn on normal mode. I’ve fixed that to only allow brightness in moonlight mode. That would point more into solution with 2 light ( 2 different supported features set ).
I think two lights with independent brightness controls but interlocked (when one is on the other is off and vice versa) give the most space to integrate and manage without future issues
When the ambilight is turned on through the HA, it is impossible to turn on the main light through the remote controller. Looks like internal lamp logic issue.
I am using Xiaomi Yeelights (auto discovery), after upgrading to 0.91, my lights are renamed: light.yeelight_ceiling_7c49ebb38056 to light.yeelight_ceiling1_7c49ebb38056 . It is possible to delete all entities and re-discover them? So I don’t need to rename all my scripts/automations.
If you add the device to the configuration you are able to choose the entity name. The names of the auto-discovery has changed because some legacy code was dropped.
Thanks syssi for the fast reply. I’ll do this ASAP.
One more question:
More Yeelights are being released with more features and this will make if possible to support them. Examples would be adding sensors for a ceiling light, getting the current power mode (daylight/nightlight), or supporting switches to turn moonlight on or off without having to use a service call.
