Lots of suggestions, from changing the data rate, through trying different library versions, to applying voodoo. But not a SINGLE mention that on all of the photos the led chips have 6 pins! Which of course means that these are certainly not WS2812(B) pixels, but most probably WS2813. So changing the LED type in your code & properly connecting the data lines should make them work as intended 
/facepalm
@Testi_Cuss Good eye!
@Testi_Cuss Did not even consider this, thanks! I only see 4, same as the old Adafruit neopixels. Can you point me where the 6 pins are located? And does Fast/LED supports the SW2813 chipset?
I also read this article today which states that WS2813 use 2000hz refresh rate, can anyone guide me how would I change this on the library files? Could that also be affecting the results? It looks like the WS2813 chip is supported, but maintained most of the WS2812B settings?
https://blog.particle.io/2017/05/11/ws2812b-neopixels-are-about-to-change/
@JP_Hidalgo Although there’s 4 pins on the PCB, there’s actually 6 pins on the LED chip itself.
@Andrew_Tuline Can those even be soldered?
The “non B” version of the WS2812 also had six pins, so six pins does not immediately mean it is a WS2813. Although if it was the WS2812 it should work, so I guess it is possible they used the wrong batch of LEDs and didn’t test the finished boards. A close up photo of the silicon die in the LED might help confirm which type it is.
Ok, that looks more like a WS2812, but the die appears to have shrunk (yet again, see below). The WS2813, WS2822, etc that I’ve seen had some extra components visible near the die (apart from the LED dies themselves). Mind you I haven’t bought any new stock of WorldSemi LEDs in some time.
So either WorldSemi shrunk the die again (eg by reducing ESD protection area and thus making them very easy to damage) or they are fakes/clones. The series resistor often suggested (eg by Adafruit) only really became necessary after a previous die shrink that dramatically reduced ESD protection. At the time that meant an urgent trip to China for me, and a meeting with WorldSemi management.
@Kean_Maizels Thanks. Lots of information I don’t know much about, but I can forward this to the seller and maybe (they are damaged since you mention that’s is a possibility) I can receive new ones.
Hmmm… have you tried these in 400kHz data rate mode? Seems unlikely, but with the smaller die who knows if these are some new variant/clone made for a specific application that ended up in “the wrong hands”. Just a thought…
+Kean I tried with all the different chip sets that were available on the original code I posted. I believe that WS2811 was on 400khz (based on the library info); same results though. Is there another way to change the data rate that I may be missing?
It’s a long shot re 400kHz, but see https://github.com/FastLED/FastLED/issues/459#issuecomment-305559653
For info https://www.element14.com/community/servlet/JiveServlet/downloadBody/82240-102-1-346305/WS2813.pdf
@Kean_Maizels Okay so I tried with Neopixel library and the “simple” example code, changed the 800Khz to 400Khz as suggested from that link and these are the results:
NEO_KHZ800, pixels.setPixelColor(i, pixels.Color(0,255,0)) = received green.
NEO_KHZ800, pixels.setPixelColor(i, pixels.Color(255,255,255)) = received red (should be white).
NEO_KHZ400, pixels.setPixelColor(i, pixels.Color(0,255,0)) = received red. (should be green).
NEO_KHZ400, pixels.setPixelColor(i, pixels.Color(255,255,255)) = receive red (should be white).
I also tried changing NEO_KHZ400 for NEO_KHZ2000 (since data sheet above says WS2813 run on 2KHz), but it gave me an error, because it doesn’t exist/not declared on the library file. I don’t know how to add it, anyone here knows how to either on the Neopixel library or preferably the FastLed one?
@JP_Hidalgo hello
the 2kHZ is to PWm speed not the max speed to send data to the chip according to the datasheet
proposed modification
in chipset.h
replace
class WS2813Controller : public ClocklessController<DATA_PIN, NS(320), NS(320), NS(640), RGB_ORDER> {};
by
class WS2813Controller : public ClocklessController<DATA_PIN, NS(220), NS(500), NS(270), RGB_ORDER> {};
and replace
class WS2813Controller : public ClocklessController<DATA_PIN, 3 * FMUL, 4 * FMUL, 3 * FMUL, RGB_ORDER> {};
by
class WS2813Controller : public ClocklessController<DATA_PIN, 2 * FMUL, 5* FMUL, 2 * FMUL, RGB_ORDER> {};
or
class WS2813Controller : public ClocklessController<DATA_PIN, 2 * FMUL, 4* FMUL,3 * FMUL, RGB_ORDER> {};
for this try please light up the led in the setup function and not the loop function
and select WS2813 as led type
@Yves_BAZIN Tested with the replacements you suggested on the chipset.h (both options), same results; I get full RGB but when I mix values all I get is red. I am testing with one pixel only. Here’s my code in case I may be missing something: https://gist.github.com/fireworks-fan/4a79e7051aba8162f0290bc416b1188b
Thanks!
@JP_Hidalgo then I don’t know really these new values are the one according to the datasheet. Something is strange as you are able to display each prime color the timing is correct have you tried with an esp32 or 8266 if you have one. I will order ws2813 to test
By the die it looks like a WS2812S. Probably some more recent die-shrinked version (like already mentioned by Kean Maizels), to save on materials/production costs. According to the 2018-released datasheet they are 800kHz & the timing is slightly tighter than for the WS2813’s. I suggest using 300ns/900ns pulse pairs, with a 300µs+ reset period. That is, if the correct pins are even properly broken out to the pad contacts, which at this point I would consider to be rather doubtful.
https://plus.google.com/communities/109127054924227823508
In my pont of view, regarding the fact that @JP_Hidalgo can display the primary colors means that the chip understands correctly the timing of the pulses. Indeed FF0000 00FF00 0000FF if it would not have been the case then arbitrary Colors would have been shown.
Which makes it even stranger 