Effect structure and direct addressing mode

[HiranChaudhuri]

Hi there.

While still playing around with McLighing I see that my living room rarely needs fancy disco effects but more ambient lights. So I'm thinking to use the fine effects in WS2812fx non-repetitive, like an entry and exit animation for a color. However once the entry animation is finished the stip should remain stable. With such a possibility, entry and exit are probably the same (exit is the entry for the next color or just black). One example would be to fade the lights from off to white, keep them there until I decide to turn off the lights, which could either be a fade or a chase to black.

Another thing is I might want to set some LEDs to white while others should remain dark or other color. How about a direct addressing mode? Something like this might already exist through DMX (I have not tested E1.31 in detail) but I'd like to set it from HomeAssistant. Maybe a separate functionn consistently available across all APIs would be good?

There is yet another API that might be more efficient than DMX to control long strips: https://www.ledstyles.de/index.php?thread/18969-tpm2-protokoll-zur-matrix-lichtsteuerung/ https://gist.github.com/jblang/89e24e2655be6c463c56

Hiran

PS: Actually I am missing some chat or mailing list to discuss such stuff...

[debsahu]

Refer WS2812FX to do the fading between colors: https://github.com/kitesurfer1404/WS2812FX/issues/124 I made a video on E1.31 mode: https://www.youtube.com/watch?v=lZ09GlO2_8s hope it helps you get an idea on how to do real-time animations using E1.31.

[HiranChaudhuri]

I've seen that video, and yes it allows fancy animations. However the protocol is quite lowlevel, as even simple fading would have to be calculated on a controller sent via the network, rather than one request to fade and let the strip controller (McLighting) be smart enough to animate it itself.

Let alone this, E1.31 can solve my use case. So how would I use HomeAssistant to send E1.31 data? In the video only the usage of Jinx! is shown which is a Java gui application on its own, and even closed source.

Finally: I hope the RGBW branch is merged soon. Would E1.31 require much change to work with 4 byte per pixel strips?

[debsahu]

One can record/capture E1.31 data and transmit it using variety of softwares (eg. falconplayer). In that video I demonstrate sending data using 3 softwares: Jinx!, ledfx and xLights. xLights can also do capturing and rebroadcasting. You can do it on a microcontroller as well, limited by space. For RGBW, you send 32 bit value instead of 24. As far as I know Home Assistant is to interface devices with smartness and there are no DMX/Artnet/E1.31 rebroadcaster. I'm happy to learn of you find any or that comes up in the future.

[HiranChaudhuri]

You did indeed describe more software to send data. I will try out how to control it from HomeAssistant (as said I do not need fancy animations, just some entry and exit effects that I can trigger from HA).

https://www.openlighting.org/ola/ This would be another option. But yes, it seems there are numerous.

[HiranChaudhuri]

So now I am trying to control McLighting via E1.31 from xLights, and after some playing around the strip shows a reaction. However both the colors and the pixel count are still confusing. Even when I switch the effect sometimes it feels I still see the previous effect for some time. Is it the sender or the receiver? I am missing some insight here.

Do you have an idea of how to verify the different steps? Like first check IP, check whether to use unicast or multicast, check RGB sequence, ... I believe I need to figure out something on that path.

[HiranChaudhuri]

I played a lot with E1.31 and xLights. Whatever I did, my best result was to get only a part of the strip react as expected. Finally I figured out that the E131 receiver function only handles the default 24 leds although I have 119 on that strip. So I was searching the problem on xLights but it comes from McLighting.

I fixed it by modifying request_handlers.h like so:

diff --git a/Arduino/McLighting/request_handlers.h b/Arduino/McLighting/request_handlers.h
index a840162..974410d 100644
--- a/Arduino/McLighting/request_handlers.h
+++ b/Arduino/McLighting/request_handlers.h
@@ -12,6 +12,7 @@ void handleE131(){

     uint16_t universe = htons(packet.universe);
     uint8_t *data = packet.property_values + 1;
+    uint16_t numleds = strip->getLength();

     if (universe < START_UNIVERSE || universe > END_UNIVERSE) return; //async will take care about filling the buffer

@@ -23,8 +24,8 @@ void handleE131(){
     //               packet.property_values[1]);             // Dimmer data for Channel 1

     uint16_t multipacketOffset = (universe - START_UNIVERSE) * 170; //if more than 170 LEDs (510 channels), client will send in next higher universe
-    if (NUMLEDS <= multipacketOffset) return;
-    uint16_t len = (170 + multipacketOffset > NUMLEDS) ? (NUMLEDS - multipacketOffset) : 170;
+    if (numleds <= multipacketOffset) return;
+    uint16_t len = (170 + multipacketOffset > numleds) ? (numleds - multipacketOffset) : 170;
     for (uint16_t i = 0; i < len; i++){
       uint16_t j = i * 3;
       strip->setPixelColor(i + multipacketOffset, data[j], data[j + 1], data[j + 2]);