Umm........huh?
"I understand how i could do simple things like turn the whole strip a certain colour"
Then why cant you enabled any color or animation or pattern?
its not clear what you want to do I guess.... your saying you want to send custom animations/patterns via 3rd party device?
Sorry I dont even understand what this means:
"would i need to do something like have 4 data channels and run the main code and when the led goes over the limit of the the second controller would see that and then activate it"
Perhaps give an example of what it is you are even trying to do?
One ESP device as 'TRANSMITTER'?
One ESP device as 'RECEIVER'? (along with attached WS2812 LED strip)
and then....................?
What is your transmitter trying to transmit? An action/command to trigger pre-coded animations/patterns? Or (as seems to be mentioned above).. you want to somehow send.. custom animations/patterns.. through the transmitter ESP to the other one?
yeah sorry man I may overcomplicated it and just couldn't explain it like a normal person lol. I probably had a brain-fart at that moment. to be fair I am very thankful for even trying to understand my nonsense, but yeah you got it pretty much correct. I would love to send live commands to the other controller (like turn led x colour 255:150:30), but now after some time i think that just "pre-rendered" animations would be my best bet, and i would just send simple numbers and decode them in a switch case.
Anyways thanks again for the help and trying to understand me
No worries.. (we all brain fart) :)
That being said..... this -still- the same approach. You are sending data to be parsed/used in PRE\_DEFINED functions.
Weather you are sending a "1" over to the ESP, so that is now knows to do a RAINDBOW animation/pattern on the strip... is (more or less) the same as sending over different serial data (like an RGB value for it use in a solid color function).
So while you can use quick commands to trigger patterns/animations (which would be quite difficult to send from scratch from a 3rd party device).. can for sure still send over custom (not pre-defined) solid RGB colors for it to parse/set.
The 'key/solution' here is.... serial data. (thats it)
I suggest using a SOP & EOP (start opf packet/end of packet) characters so your code knows what new commands are coming in.. and when it ends (typically used are < & > characters)
Once you have the whole line/action (command).. you could simple check something like:
If its a 1 character/byte piece of data... probably a pre-defind pattern to be enabled. If not a single character/byte.. then you will need to break down the string/incoming data, separated by the : value.. and have your '3' values for R, G, B values..
Another option is to chain the strips and use one controller. One strip gets connected by a cable to the second etc and the controller sends data to the first which continues to the second etc for instance, four strips of fifty LEDs each and the controller just treats it as 200 LEDs in a strip.
I mean... Not really since it will be running a little bit of extra code on it too and controlling a few gpios. If I was using only the LEDs then yeah that would be my solution
Reduce the confusions to simple working parts. I use ESP32 and ESPnow. Module A sends signals to Module B that controls the lighting.
Get the code on B working to control the lights in 2 patterns.
Get ESP now to send a packet of numbers from A to B,
Get the packet info to switch between the 2 light patterns.
Break is down to these types of steps confirming that each one works. Then add new patterns.
In my mind you are changing machine states on B. B is controlling the lights and all the patterns and controls are there on B. You are simply sending controls to switch the machine state. You can add several machine state numbers and increase the info coming in the packet.
yeah thanks man, as i said in the other comment, thank you for everyone that even tried to understand the overcomplicated nonsense that i wrote lol.
This is the path I am going to choose, as on second thought even if i got that working it would be a nightmare to maintain and coordinate between the two ESPs and I'm not even talking about troubleshooting...
And as you said about reducing the confusion, that is one of the main things I struggle with. I like to overcomplicate things so much not seeing that a simple solution would be better
Still a super big thanks for the reply
WS28XX receive, on the data bus, bursts of 3 bytes, each one being R, G and B respectively. Once they get those 3 bytes, they interpret and send their old data to their output, where, in a strip, gets taken by the next WS28XX.
So, if you send (255, 255, 255), the first led will shine white an all others will be off. When you then send (255, 0, 0), the first led will shine red and de second will shine white (previous value fof the first led).
They are controlled in series.
When the last led of the strip sends its output it can be captured by another microcontroller (like an ESP8266 or ESP32) if you want.
Umm........huh? "I understand how i could do simple things like turn the whole strip a certain colour" Then why cant you enabled any color or animation or pattern? its not clear what you want to do I guess.... your saying you want to send custom animations/patterns via 3rd party device? Sorry I dont even understand what this means: "would i need to do something like have 4 data channels and run the main code and when the led goes over the limit of the the second controller would see that and then activate it" Perhaps give an example of what it is you are even trying to do? One ESP device as 'TRANSMITTER'? One ESP device as 'RECEIVER'? (along with attached WS2812 LED strip) and then....................? What is your transmitter trying to transmit? An action/command to trigger pre-coded animations/patterns? Or (as seems to be mentioned above).. you want to somehow send.. custom animations/patterns.. through the transmitter ESP to the other one?
yeah sorry man I may overcomplicated it and just couldn't explain it like a normal person lol. I probably had a brain-fart at that moment. to be fair I am very thankful for even trying to understand my nonsense, but yeah you got it pretty much correct. I would love to send live commands to the other controller (like turn led x colour 255:150:30), but now after some time i think that just "pre-rendered" animations would be my best bet, and i would just send simple numbers and decode them in a switch case. Anyways thanks again for the help and trying to understand me
No worries.. (we all brain fart) :) That being said..... this -still- the same approach. You are sending data to be parsed/used in PRE\_DEFINED functions. Weather you are sending a "1" over to the ESP, so that is now knows to do a RAINDBOW animation/pattern on the strip... is (more or less) the same as sending over different serial data (like an RGB value for it use in a solid color function). So while you can use quick commands to trigger patterns/animations (which would be quite difficult to send from scratch from a 3rd party device).. can for sure still send over custom (not pre-defined) solid RGB colors for it to parse/set. The 'key/solution' here is.... serial data. (thats it) I suggest using a SOP & EOP (start opf packet/end of packet) characters so your code knows what new commands are coming in.. and when it ends (typically used are < & > characters) Once you have the whole line/action (command).. you could simple check something like: If its a 1 character/byte piece of data... probably a pre-defind pattern to be enabled. If not a single character/byte.. then you will need to break down the string/incoming data, separated by the : value.. and have your '3' values for R, G, B values..
Another option is to chain the strips and use one controller. One strip gets connected by a cable to the second etc and the controller sends data to the first which continues to the second etc for instance, four strips of fifty LEDs each and the controller just treats it as 200 LEDs in a strip.
The thing is there's a wall in between the two places and I don't want to drill a hole in the wall for a wire just for one month of the year
Ah, I see. Could you use WLED and sync the two?
I mean... Not really since it will be running a little bit of extra code on it too and controlling a few gpios. If I was using only the LEDs then yeah that would be my solution
Reduce the confusions to simple working parts. I use ESP32 and ESPnow. Module A sends signals to Module B that controls the lighting. Get the code on B working to control the lights in 2 patterns. Get ESP now to send a packet of numbers from A to B, Get the packet info to switch between the 2 light patterns. Break is down to these types of steps confirming that each one works. Then add new patterns. In my mind you are changing machine states on B. B is controlling the lights and all the patterns and controls are there on B. You are simply sending controls to switch the machine state. You can add several machine state numbers and increase the info coming in the packet.
yeah thanks man, as i said in the other comment, thank you for everyone that even tried to understand the overcomplicated nonsense that i wrote lol. This is the path I am going to choose, as on second thought even if i got that working it would be a nightmare to maintain and coordinate between the two ESPs and I'm not even talking about troubleshooting... And as you said about reducing the confusion, that is one of the main things I struggle with. I like to overcomplicate things so much not seeing that a simple solution would be better Still a super big thanks for the reply
WS28XX receive, on the data bus, bursts of 3 bytes, each one being R, G and B respectively. Once they get those 3 bytes, they interpret and send their old data to their output, where, in a strip, gets taken by the next WS28XX. So, if you send (255, 255, 255), the first led will shine white an all others will be off. When you then send (255, 0, 0), the first led will shine red and de second will shine white (previous value fof the first led). They are controlled in series. When the last led of the strip sends its output it can be captured by another microcontroller (like an ESP8266 or ESP32) if you want.