Change Dimmer Brightness WITHOUT turning on our off

Feature Requests
, ,
1

I would love to see the ability to change a wifi dimmer’s brightness without actually sending the on command, specifically from automations.

For example. At 3 hours past sunset, I would like to command my bedroom, stairwell, hallway, and bathroom lights to be at 10% so if I get up in the night, I don’t get blinded when I turn them on.

Currently, automations only seem to be able to send a brightness pct with the “turn_on” command. This forces me to turn the lights on, set the dimming to 10 and then turn them back off. Not cool to have lights flashing on and off at night.

I understand some devices won’t work properly, but my tasmota flashed tuya dimmers do work if I send MQTT commands manually from MQTT Explorer. I can send the “/CMND/Dimmer” with payload “10” and the light will stay off, but will come on at 10% brightness the next time I press the switch or click the icon in HA. (Monitoring the device’s console shows the command received and dimmer level acknowledged)

Manually sending this command from HA automations, via MQTT service, still causes the light to turn on for some reason. :man_shrugging:. So I can’t even “work around” the problem of no native HA support.

2

Yes - I want to be able to do this with my Shelly Dimmer 2s

3

I made an automation that controls the default brightness. So when turning my light on at 10pm it my automation will only allow it to be 10% on start.
You can still change the brightness manually when the light is on but it will reset when turned off / on at this time again.

I also set one for the rest of the day having my lights on 69% brightness

4

How did you accomplish this? I don’t see a way for HA to send brightness commands without turning the light on.

5

I made two automations for my “Default” value

Default value 69%
(If the light turns on when its between 07:30am and 07:00pm it will make the light to 69% brightness)

id: '1642768476441'
alias: Lights - Set Default light level 69%
description: ''
trigger:
  - platform: device
    type: turned_on
    device_id: ad26bc419ea40aa4ffb47b219ff12179
    entity_id: light.zimmerlicht
    domain: light
condition:
  - condition: time
    after: input_datetime.time_0730
    before: input_datetime.time_1900
action:
  - service: light.turn_on
    target:
      device_id: ad26bc419ea40aa4ffb47b219ff12179
    data:
      brightness_pct: 69
mode: single

Default value 10%
(If the light turns on when its between 07:00pm and 07:30am it will turn the light to 10% brightness)

id: '1642768555438'
alias: Lights - Set Default light level 10%
description: ''
trigger:
  - platform: device
    type: turned_on
    device_id: ad26bc419ea40aa4ffb47b219ff12179
    entity_id: light.zimmerlicht
    domain: light
condition:
  - condition: time
    after: input_datetime.time_1900
    before: input_datetime.time_0730
action:
  - service: light.turn_on
    data:
      brightness_pct: 10
    target:
      device_id: ad26bc419ea40aa4ffb47b219ff12179
mode: single

In my conditions I used these

input_datetime.time_1900
input_datetime.time_0730

those are helpers (they function like variables and hold the time values so I don’t have to change every automation that uses these times one by one)

When the light turns on to 10% when the last state was 69% it will briefly still go to 69% but then returns to 10% (This can be removed when having the lights fade to turn on but you’d need to configure that on your light bulb I think)

6

I didn’t want the flash in the middle of the night when it comes on full bright and then dims.

But I like the helper idea you’re doing there. I’ve been trying to come up with ways to streamline the automations I have so I can make adjustments from a “config” page in my dashboard. I’ve started adding some helpers but not for times. Good idea.

7

I understand that.

Maybe you find some more interesting stuff here:

8

I’ve created a generic workaround as automation to set the brightness to 0 when the light turns off.
You can list all your problematic dimmable lights as a trigger:

alias: Brightness Fix
description: Generic brightness fix to pass light flash
trigger:
  - platform: state
    entity_id:
      - light.studio_leds
      - light.island
      - light.tv_lights
      - light.pc_lights
      - light.toshiba_leds
      - light.tripod_lamp
    from: "on"
    to: "off"
condition: []
action:
  - service: light.turn_on
    data_template:
      brightness: 0
      entity_id: "{{ trigger.to_state.entity_id }}"
mode: parallel
max: 10
9

How does that help your situation? Does the light just snap to the pre-set brightness and then immediately adjust to your automation’s set brightness percent? Is it fast enough you don’t notice?

For my original question i did find a solution in another thread.
“setOption20” in the tasmota documentation details it. It prevents the light dimmer from tuning on unless it explicitly receives a command to turn on. So, while still a bit painful to do the call_service/ & mqtt payload dance, it does work very well. And I’ve now integrated the ideas from CryptZar about using helpers. So I’ve actually got a config dashboard now, that lets me edit Day/Night times for each of my areas, as well as the default brightness levels for day/night. 30s after the lights are turned off, an automation fires and adjusts the default dimmer level so the next person to turn the lights on gets the default level again.

I’ve also started installing some HomeSeer Z-Wave dimmers that have a parameter exclusively for default dimming level, so the automations for those areas just issue a Z-Wave command at the Day/Night transition times set in the helpers. I don’t have to trigger automations for those ones every time the light is turned off.

10

It is a clever solution, and it works for me with some of my dumber smart switches (I’ve been spoiled by Inovelli, but don’t want to buy another 9 of them just for bathrooms).

The idea is you set the brightness to 0 (or maybe try 1, if this doesn’t work for you) upon turning them off. That way, when they are turned on: they aren’t visibly illuminated at first. Then: the automation kicks them to the desired level. The downside is, the switches “don’t work” if home-assistant, or Z-Wave, goes down. A non-privy user would tap the switch and see no light. They wouldn’t know to hold the paddle down, double tap, whatever…

This in contrast to the other two solutions I can think of:

  1. Simply set the desired brightness when turned on, but this would result in blinding light for a second between turn on and level correction.
  2. A scheduled automation that sets the brightness and immediately turn off (if currently off) when the time of day changes (say, at sundown). This has the downside of a quick strobe occasionally during the day, and the appearance that the house is haunted.

There is one more solution I’ve thought of, but I haven’t tested yet. A variation of #2 above. On schedule, set the dimming rate as long as it will go. Set the brightness, turn off, and set the dimming rate back. The idea is to eliminate the strobe as the light hopefully doesn’t approach visible light. But: it will depend on whether the switch turns back on to the previous set-point (ideal), or if it turns back on to where it happened to be during the dim `tweening (not ideal).