Limitless LED periodically push current settings

Feature Requests
1

I love the flexibility of LimitlessLED, but the way HASS handles the status of bulbs is a bit annoying:

  1. Bulbs are turned off every time HASS is restarted
  2. HASS assumes bulbs are all of the correct status at all times

The consequences of this are that the whole house can do dark when you restart HASS, and bulbs can be in a different state to that of HASS, especially if they’re switched off while a change is made in HASS.

I agree that some people like the current system. But I would like to suggest a different approach.

In your configuration.yaml, you have a new optional property called refresh_interval that can either reside under platform (universal across all bulbs) or under individual bridges. For example:

  - platform: limitlessled
    refresh_interval: 600
    bridges:
      - host: 192.168.1.10
        groups:
          - number: 1
            name: Bedroom lamp
            type: bridge-led
          - number: 1
            name: Bedroom ceiling
            type: rgbww
      - host: 192.168.1.11
        refresh_interval: 15
        groups:
          - number: 1
            name: Study ceiling
            type: rgbww   
          - number: 2
            name: Guest ceiling
            type: rgbww

In this example, HASS will by default send bridges the status of all bulbs every 10 minutes, but every 15 seconds to the bridge at 192.168.1.11.

2

I also don’t like the implementation of limitlessled component.
There is no way to change delay between commands. Because of this, you can not dim them in a linear fashion. If you set the brigtness in a linear fashion (from 255 to 0 in 10 steps every 50ms lets say, you have to wait for nearly 30 seconds for the light to finally settle)
There is no way to change the number of repetitions for each command.

I also don’t understand the need to “sync” the bulbs. All my automations set the brigthness and color every time they trigger. So the final state is irrelevant of the first state. I also don’t like the lamps turning of each time hass is restarted. This is widely unnecessary.

Thanks.

3

I think we can justify a PR to remove the initial light reset on startup. The intention was to start from a known baseline. Full disclosure: I authored that.

As we all know, keeping HASS’s internal state consistent with the physical state is impossible. Personally I feel like a refresh_interval would be just as annoying.

With respect to dim transition time, have you tried the transition_time attribute? That one “should” perform that for you, dynamically adjusting the number of steps based on the requested time and necessary number of repetitions.

4

I looked at the code and the default value of transition_time is 0. Nothig to improve there it seems.