E1.31 with Hyperion NG not working properly after the first universe

[perebusquets]

The problem

According to the documentation, the recommendation (and I think the only one for now) to use HyperionNG with addressable lights is to use the E1.31 protocol.

In my case, when using said protocol with HyperionNG with a 480 RGB LED strip and setting a static color, the LED strips change color every 170 LEDs (IE: first 170 in green, next 170 in blue, next 170 in red,...).

This make me suspicious that for some reason the data for one color gets skipped between universes, making the next set of 170 LEDs grab the wrong color, but I'm not an expert on that matter so please don't get fixated on that.

Example picture, the color is supposed to be all red:

Which version of ESPHome has the issue?

2022.9.2

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP32

Board

nodemcu

Component causing the issue

e131

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[rspenc29]

I'm experiencing this issue as well. I did some further testing and it seems to be a problem with how hyperion implements the udpe131 controller rather than esphome. I also installed wled and using the same udpe131 controller, it was doing the same thing. I also had some issues where purple was blue and orange was red using e131 with both esphome and wled, but setting the colors with hyperion disabled they all worked fine.

For now, I guess I'll have to stick with wled on the esp and the wled controller in hyperion. It's unfortunate though because the esp was being used for other tasks when it wasn't controlling leds and I'd like to get those back soon. But the leds are working good now. Hopefully hyperion will fix their udpe131 controller or esphome will fix their wled integration or add other network controller options that are supported by hyperion project.

[contagon]

Just hit this same problem and agree I would love to stick with esphome for this rather than be forced to use WLED. Was this an issue ever opened on Hyperion.NG to notify them of this issue? Also just attempted with HyperHDR and it has the same bug

[contagon]

Upon some further digging, it appears the E1.31 protocol can only function with a maximum of 170 LEDs per universe. Per the WLED docs:

170 LEDs (510 DMX channels) are supported per universe.

As a workaround, I've partitioned my LED into multiple entities each with a different universe, and then input each into Hyperion as a different instance. Here's an example:

e131:
  method: multicast

light:
  - platform: neopixelbus
    id: main_led
    type: GRB
    variant: WS2812
    pin: GPIO16
    num_leds: 231
    internal: True

  - platform: partition
    name: Top
    segments:
      - id: main_led
        from: 224
        to: 230
      - id: main_led
        from: 0
        to: 151
    effects:
      - e131:
          name: Hyperion
          universe: 1

  - platform: partition
    name: Bottom
    segments:
      - id: main_led
        from: 152
        to: 223
    effects:
      - e131:
          name: Hyperion
          universe: 2

B/c of this, I don't actually think there's a bug in esphome or Hyperion, and this issue can probably be closed.

[perebusquets]

Hi! Didn't know you could partition them like this, what confuses me though is that in the ESPHome docs it states the following:

If there’s more LEDs than allowed per-universe, additional universe will be used. In the above example of 189 LEDs, first 170 LEDs will be assigned to 1 universe, the rest of 19 LEDs will be automatically assigned to 2 universe.

That's why, since it skips 1 color when it uses the following universe after the 170th LED, I assumed this to be a bug...

I believe what's happening (based on @rspenc29 's comment, that says that the same happens with WLED) is that Hyperion may be sending extra data at the end, hence the change of color for the next universe. IE: 1 universe = 512 channels 170 LED (RGB) = 170 * 3 = 510 channels 512-510 = 2 extra channels in the universe Probably what's happening is EspHome/WLED discards the 2 extra channels and start anew in the next universe, Hyperion uses those 2 extra channels plus channel 1 of universe 2 for the next LED. That would explain why the color changes midway.

Since @contagon partitioned it as different light strips and are seen as different light outputs in Hyperion, probably this issue doesn't happen as Hyperion just sends the correct data as it considers it the first universe (and doesn't use up the extra 2 channels at the end).

The thing is that I don't know if there's a convention in the E1.31 protocol that specifies how extending by using the next universe should be implemented, because that would determine if the bug is in ESPHome side (if the 2 remaining channels should be used) or in Hyperion (if the 2 remaining channels should be discarded).

From my limited experience doing live light shows in venues a while back, the extra channels were used when using e1.31 through ethernet/network, but weren't used when using old-school DMX cables...