Configure Smart Bulb as Nightlight Using Dumb Switch

I’m attempting to use my zigbee bulb as a nightlight but it’s connected to a dumb switch. I would like to have it turn on with certain settings during the night and different settings during the day. However, I will not have my phone so will rely on the dumb switch to turn it on. The problem is, the light still shows state “on” when the switch is off because it never has a chance to update. I changed the unavailable limit for mains devices but am not sure if there is a better way to detect it as available/unavailable. Maybe a custom sensor of some sort?

Anyway, here is what I came up with so far but it seems like it may be more complicated than necessary

 alias: Nightlght
  description: ''
  trigger:
  - platform: time
    at: '21:00:00'
    id: Night
  - platform: time
    at: 06:00:00
    id: Morning
  - platform: state
    entity_id:
    - light.master_light_level_light_color_on_off
    from: unavailable
    to: 'on'
    id: Activated
  condition: []
  action:
  - choose:
    - conditions:
      - condition: trigger
        id: Morning
      sequence:
      - service: input_number.set_value
        data:
          value: 1
        target:
          entity_id: input_number.light_mode
    - conditions:
      - condition: trigger
        id: Night
      sequence:
      - service: input_number.set_value
        data:
          value: 2
        target:
          entity_id: input_number.light_mode
    - conditions:
      - condition: trigger
        id: Activated
      sequence:
      - choose:
        - conditions:
          - condition: state
            entity_id: input_number.light_mode
            state: '1'
          sequence:
          - service: light.turn_on
            data:
              kelvin: 3000
              brightness_pct: 100
            target:
              entity_id: light.master_light_level_light_color_on_off
          - service: input_number.set_value
            data:
              value: 0
            target:
              entity_id: input_number.light_mode
        - conditions:
          - condition: state
            entity_id: input_number.light_mode
            state: '2'
          sequence:
          - service: light.turn_on
            data:
              brightness_pct: 10
              color_name: darkred
            target:
              entity_id: light.master_light_level_light_color_on_off
          - service: input_number.set_value
            data:
              value: 0
            target:
              entity_id: input_number.light_mode
        default: []
    default: []
  mode: single

I attempted to use an input number to determine which light template to use and set it back to 0 so it only activates the first instance after the trigger times. How can I make this work when the dumb switch is used (i.e. the bulb becomes available again)?

Put a remote on the wall instead and everything just works

Yeah, was trying to avoid having to use a remote or a smart switch. This actually works pretty well. When I was testing, I think the bulb was having connection problems so wasn’t going from unavailable to on in a timely manner. It now only has a couple second delay. I may just move up the Night trigger so that it changes the settings the last time I use it before bed and primes it for the night. Doesn’t matter if there is a few second delay in the morning since it’s going from dim to bright so won’t mess up night vision. I’ll probably set a transition to make it a little less stark.

I think I found a better way to do this. Less code, no helper, and doesn’t trigger every time the dumb switch is turned on.

 alias: Nightlight
  description: ''
  trigger:
  - platform: time
    at: '20:40:00'
    id: Night
  - platform: time
    at: 06:00:00
    id: Morning
  condition: []
  action:
  - wait_for_trigger:
    - platform: state
      entity_id:
      - light.master_light_level_light_color_on_off
      from: unavailable
      to: 'on'
  - choose:
    - conditions:
      - condition: trigger
        id: Morning
      sequence:
      - service: light.turn_on
        data:
          kelvin: 3000
          brightness_pct: 100
          transition: 10
        target:
          entity_id: light.master_light_level_light_color_on_off
    - conditions:
      - condition: trigger
        id: Night
      sequence:
      - service: light.turn_on
        data:
          brightness_pct: 10
          transition: 10
          color_name: darkred
        target:
          entity_id: light.master_light_level_light_color_on_off
    default: []
  mode: single

Two other suggestions:

  • Set ZHA to mark bulbs as ‘unavailable’ sooner in its preferences
  • If you trigger on the times and the bulb turning on, then conditionally set the brightness based on the time, you don’t have to have the automation wait. (this should only help if you restart HA sometime when the bulb is off, then it will forget to change brightness until the next day.)

-David

Thanks, David. I did change the timeout preferences on the ZHA integration. I don’t think I understand your second point. The problem here is that the dumb switch is off at the time based triggers. The bulb is unavailable so nothing can be sent to it until it comes back online. That’s why I have the wait in there. To your point on interruption to ZHA, I did think about that but it’s such a fringe case and not critical enough of an impact to worry about. That persistence was the one benefit to my first code that used the helper.

What I meant was that your integration now triggers on the time and then waits for the light to go on. I have similar automations where I trigger on the light and the do something based on the time. I prefer this because it means the result of the trigger happens right away, rather than the automation waiting (potentially 12 hours) to finish. I don’t know that it matters, but I would certainly find it easier to debug. :slight_smile:

Got it. I thought this was a little more system friendly since it only triggers 2 times a day and will always end in an action rather than triggering every time the switch is activated, and often doing nothing. I also thought this would be easier to debug because you would only have the 2 events per day rather than trying to go through 10+ to see which ones SHOULD have actually ended in an action. Like you said, probably doesn’t matter either way. I’ve been happy with how it’s working so far!