This string appears to be to my untrained eye a WS2801 5050. It looks like it would take regular I2C, with SCL and SDA, But I can't find a library that makes even one of these lights light up.
Would appreciate anybody either identifying the string, or guiding me toward the correct library. It looks like FastLED is only for three wire.
TIA
No it is not I2C.
It is the type of LED that Adafruit calls a DotStar, all the main libraries will drive these.
Not being an expert on LED strips I would say this strip is not an I2C version. I think of CI as Clock Input and DI as Data Input.
This, being quite ignorant on details, makes me think of something like SPI.
Have You checked the other side of the strip? Usually there's some significant printing somewhere...
What do You say?
@ Grumpy_Mike
Writing at the same time. You conduct the orchestra..
Well just about to go to bed here.
You can use them by employing a library, but that still requires the interrupts to be off when you drive them.
You can also bit bang the data at them, this will be slower but will allow interrupts to be on for things like serial data, and servos, which don’t work when the interrupts are off. Use port addressing rather than digitalWrite for the maximum speed.
It is an RGBW strip with a clock pin. The FastLED.h library can work with strings with a clock line. Every 28XX prototype in the library allows for a clock:
case WS2801: { static WS2801Controller<DATA_PIN, CLOCK_PIN> c; return addLeds(&c, data, nLedsOrOffset, nLedsIfOffset); }
case WS2803: { static WS2803Controller<DATA_PIN, CLOCK_PIN> c; return addLeds(&c, data, nLedsOrOffset, nLedsIfOffset); }
I've just never used one nor seen any used by anyone in these forums.
There is an "LEDs and Multiplexing" forum on this site where your question may get answered.
The same here, most every late evening....
No it is a DotStar otherwise know as an APA102.
RGBW strips have every other LED as a white one and they look different. You can see that all the LEDs look the same.
This is an closeup of the two sorts of addressable LED.
Here is me attaching the wires:-
Actually no! 
You are referring to the 12 or 24 V strips. The 5 V ones use individual LEDs.
Also available in single mounts.
Ok but you can still see the phosphor portion of the LED and that is not seen in the OP’s original picture.
Hi, @HolesFlow
Where did you purchase them?
Can you please post a link to the seller?
Thanks.. Tom.. 
Always a good idea. 
I wasn't suggesting they were RGBW in the OP. It was SteveMann who for whatever reason, interjected that. Merely commenting on the actual nature of the RGBW LEDs.
These clocked LEDs have no relation whatsoever to I²C (other than the synchronisation step), but I wonder why the libraries would have a problem with interrupts? Clearly the NeoPixel library must turn off interrupts for that sort (WS2812), but why would it not recognise that is not at all appropriate for the clocked LEDs?
Hi @TomGeorge
These are from a broken "Dragon Staff". Yeah, I know. I had no clue, either.
These are 'wheels' with LEDs in them, connected by a 'staff', so they end up looking like dumbbells or an axle with 2 wheels. The vendor link is here. They use these, flaming ones, and POV ones at raves & parties (I guess).
Each 'spoke' has 13 of these LEDs, in 60/m density), hooked up in parallel. That is, all 4 contacts
of each string are wired together. Sorry the seller link doesn't help. 
From experimentation, I have figured out that it must be SPI, with the DI on the first LED on each strip being connected to MOSI, but there is no MISO, CS. Not that it matters, but the μC is STM8 here.
The best I have been able to do from trying all kinds of libraries on FastLED is the first LED, is to make the first LED on the first string flash. The on-LED controller isn't passing information on. I have a lot of awesome ideas from the posters here.
Sorry, @SteveMann for posting.
I have seen bit-banging (shifting), but was unaware of addressing ports directly being a faster alternative to digitalWrite().
I like those those tiny grippers! Hemostats?
No Tweezers
Tweezer
About 64 times faster. Makes a big difference in a loop.
Hi,
Have you still got the rest of the broken bits?
Have you got the controller it went to?
Thanks.. Tom...
Well, I didn't get a chance to test a library, but I did find the problem(s)... Each 'wheel' had it's first LED (3 strings in parallel) on each of the 3 strings blown. They would not pass data.
Here is the weird part. on one 'hub' or wheel, it was visually obvious the IC was blown (tiny as it is), BUT the other 3 on the other wheel (also first in strip on all 3) showed no visible sign of damage-but were.
These were no doubt APA102Cs (or equiv). What we did was cut out these 6 LEDs, resolder wires connecting them in parallel, and made each 12 LEDs long. I ordered a few meters of replacements for stock, and when they come in from Digikey we'll take the customer unit back in and add the LED to the end.
Thanks everybody! I learned a lot.
When ever anyone says something is weird here, the overwhelmingly odds are that it is perfectly normal, as it the case here.
Parts do not have to show physical damage when they break. You only get physical damage when you greatly abuse them. So not all damage is visible it is the way electronics works.
