Adafruit_NeoPixel | Arduino library

I won't go into too much details here. Please do a beginners tutorial on C++ befor you continue. You don't need to go into advanced topics like templates or polymorphims yet but at least you should know the basic syntax.

Your code does not make any sense.

What is #define MULTISEK supposed to do?

Especially followed by static int MULTISEK = 0;

Why do you use preprocessor directives if you don't know what they do?

So I've fixed this issue by swapping out the adafruit liabery with fastled no more crashing or abnormal behaviour.

You describe that for the shown output you sent via mobile "0,19,255".
Yet in the shown output that obviously is only the second part of a longer sequence of numbers sent, which starts with "0,21".

Assuming that what you send is always of the format you have described, i.e. three numbers, separated by two ",", the shown output is most likely the result of you sending first "0,21,255" and then another triplet "0,19,255".

These two messages together would end up in an input buffer "0,21,2550,19,255".

Now I have to do some speculation. Most parsers, when told to look for numbers within the buffer, will look for digits followed by non-digits. They would end up yielding "0,21,2550".

Without knowing details of the parsers working it is hard to say how to fix your problem.
I would however definitly experiment with sending triplets which end in a non-digit.

For example:

"0,21,255,"
or
"0,21,255 "
or
"0,21,255;"

If none of them work you might need to explicitly expect the non-digit, i.e. between triplets of numbers read a character and either ignore it or compare it to " ,", " " or ";" for additional self-checking features.

(Writing this I rely on user zdf not intending to make an answer, because while I did spot the "2550" as "255""0", zdf spotted the only two "," inside the question body in sample input, which I missed. I will of course adapt my answer to one created by zdf, to not use their contribution without their consent.)

To call a constructor from an other constructor use the syntax:

I'm bored and feeling generous so here you go. See if you can follow this. It's uncompiled and untested so I can't guarantee it does exactly what you want, but see if you can understand what I'm trying to do here. Nothing ever stops and waits for anything to happen. There are no delay calls. There is no waiting. Just cycling through and see if it is time to do something.

One change I made that doesn't affect this, just makes typing easier was to take all your goLED variables and make an array out of them. Anytime you catch yourself putting numbers on variable names, use an array instead so the compiler has access to those numbers and you don't have to repeat yourself. See how much simpler the checkLedData function got.

Then I made the colorWipe functions so that they will return a boolean, true if they've completed and false if they haven't. Then the runLED function can just check that to see if it is time to move on to the next step. For the first case it is easy, just set the goLED variable to whatever the colorWipe returns. As long as it is still working it returns true and goLED[1] stays true and you keep calling the same colorWipe function. For the others we have to make them state machines, so I added a state variable. When any of them get finished they set their goLED variable back to false. When all of those are false, meaning there's no effect currently running, then runLED will fall all the way through to the last else statement and go to see if there is another command.

Like I said, there may be a mistake or two in there. But see if you can understand how I am writing a checklist to see what needs to happen instead of a story to tell one thing right after another.

Simply implement the same functionality in your sketch using read().

readString blocks for a set amount of time. It freezes your sketch waiting on the transmission to complete for 1 second. This isn't great for most sketches. Most of the time it would be better to implement a non-blocking read. There are also big issues with using the String class on smaller microcontrollers like the UNO and especially the tiny85 in the digiSpark. It would be best on that platform to stick to c-style strings. But here's how to mimic readString if that's really what you want to do.

The writers of that class made a grade-school C++ mistake and didn't correctly observe the Rule of Three. This means an Adafruit_NeoPixel object can be copied when it is not safe to do so.

The on_message callback is run on the MQTT client's network thread, if you block that thread you will not be able to send or receive any more messages.

You should NOT be doing any blocking or long running actions in this (or any of the client callbacks), you should be setting flags in a state machine and using those changes to control other threads.

This is a wild guess, but these strips work in a serial way: the first LED is taking the first 24bits, ditch them and pass the remaining to the following LED and so on. That does mean the message you are sending is increasing with the number of the LEDs you are currently addressing.

These LEDs IC also need some time to reset before the next message is received, it is possible that there is a data conflict as the strip cannot catch up with an increasing signal length at full speed of you ESP.

Your second example contains some tests, which might slow down the transfer enough to avoid the conflict.

So, you might just need to add a small delay in your first example, from the documentation something as small as 50 microsecs might be enough. You can use delayMicrosecond() for that.