Individually addressable lights/sub-led-strips

[wolph]

Is your feature request related to a problem/use-case? Please describe.

I have a few large led strips that I would like to split up virtually so I can control parts of the led strips as different devices. I know that I could physicially split the strips and connect them to different digital ports, but that would require a lot of extra wiring and work and there really shouldn't be any need for that.

One actual use-case I have lined up already. I have a DreamScreen (philips ambilight like device) which controls a bunch of leds behind my TV directly. But it has the option of connecting "external" devices as well which would allow me to control the led strips I have near the ceiling in a few different parts.

Describe the solution you'd like
Right now we have mqtt commands like these:

device_name/light/light_name/command

I think there are a few different options for these. The simplest solution might be supporting something like this:

device_name/light/light_name/led_number/command

With the regular payload like this:

{"color": {"r": 1, "g": 1, "b": 0}}

Or perhaps keep the original command and simply allow for an array of values as payload:

{"color": [{"r": 1, "g": 0, "b": 0}, {"r": 0, "g": 1, "b": 0}, {"r": 0, "g": 0, "b": 1}]}

Another option could be to allow for sub-led strip assignments but I think that might be harder to code internally. The configuration would be rather simple, simply a regular addressable led strip config with an added led-offset parameter. For example:

light:
  - platform: fastled_clockless
    name: "Group 0"
    chipset: WS2811
    pin: D1
    offset: 0
    num_leds: 10
  - platform: fastled_clockless
    name: "Group 1"
    chipset: WS2811
    pin: D1
    offset: 10
    num_leds: 10
  - platform: fastled_clockless
    name: "Group 2"
    chipset: WS2811
    pin: D1
    offset: 20
    num_leds: 10

I personally think implementing an array of colors would be easiest for this use case without any backwards compatibility issues.

[OttoWinter]

Part of that can be seen here: #243 #147 (partionable lights).

As for your use case: I don't think you'll get something like that to work here unfortunately. The reason is that for ambilight you'd need to have a high update rate and lots of data to be sent per update. The WiFi/TCP stack on these ESPs is just to fragile to push all this data so quickly - and esphomelib is also not made for this kind of usage. If you'd create a separate light instance for each LED in the strip you'd quickly run out of RAM.

As for your MQTT schema proposition: No - the MQTT platform uses the exact format Home Assistant expects. Any deviation from that will just create tons of problems down the line. And it also won't work for another reason: If you have more than a few LEDs, the message payload since will be huge - and the MQTT client used here doesn't support such big packets.

[wolph]

Ah, those two pull requests could help a lot indeed :)

In a few small tests I didn't have any issues pushing about 20 updates per second, which is more than enough for this use-case. Not sure if it will keep working reliably though. I have written something similar (without MQTT) before which works without any issues though: https://github.com/ambilight-4-mediaportal/AtmoOrb/blob/master/ESP8266/ESP8266_H801/ESP8266_H801.ino

The amount of partitions would be limited in my case, probably about 4 to 6 in total.

Thanks for the help, I'll follow the two linked pull requests. Those will probably work fine for my goal.

PS: Excellent work on this project, I've been going through the code to see if I could create a hack using a fast led light effect and it looks really nice and clean :)