Hmm, of course it’s possible, but when I tested I had the impression 1 did turn on the first LED.
If it doesn’t on your strips, you can always adapt the code that does the parsing.
e.g. like this
if (sscanf(arg, "%d,%d,%d,%d,%d", &px, &r, &g, &b, &br) >= 4)
{
if (px > 0) // set LED with number px
px_ = px--;
else if (px < 0) // set LEDs 1 .. px
{
px_ = abs(px);
px = 0;
}
}
Thanks again for the tip!
On the road till sunday evening…
I’ll try as soon as I’m back in town…
Hi @ScruffR, here we are again under a clear sky full of great DOTSTARs…
Starting from your above sketch, remotely controlling DOTSTARS with a Particle function, I modified it to set the colour and brightness of individual LEDs for my “status panel” (to be connected to a Raspberry Pi)
Below sketch “kinda works”, but not fully yet:
Colour and intensity of the leds is OK, but not the correct pixel Nr. is transmitted to the strip.
( See my comment in the loop() )
const int LEDCOUNT = 70;
uint32_t pxBuffer[1 + LEDCOUNT + LEDCOUNT/16 + 1];
uint32_t setAPA102Color(int px, uint8_t r, uint8_t g, uint8_t b, uint8_t brightness = 31);
void setup()
{
SPI.begin();
SPI.setClockSpeed(8, MHZ);
SPI.setBitOrder(MSBFIRST);
for (int px = 0; px < LEDCOUNT; px++)
pxBuffer[px] = 0x000000E0;
setAPA102Color(-1,0,0,0,31); // Initializing the strip...
void loop()
{
// TEST: Alternate the colours for 3 LEDs to RED and BLUE...
// ATTENTION: I expect #40,41 & 41 to respond, but instead, #0,1,2 respond... Troubleshoot!
setAPA102Color(40,0,0,30,5); delay(1000);
setAPA102Color(41,0,0,30,5); delay(1000);
setAPA102Color(42,0,0,30,5); delay(1000);
setAPA102Color(40,30,0,0,5); delay(1000);
setAPA102Color(41,30,0,0,5); delay(1000);
setAPA102Color(42,30,0,0,5); delay(1000);
}
uint32_t setAPA102Color(int px, uint8_t r, uint8_t g, uint8_t b, uint8_t brightness)
{
uint32_t color = 0;
color |= (brightness << 0) | 0xE0;
color |= (b << 8);
color |= (g << 16);
color |= (r << 24);
pxBuffer[px] = color;
SPI.transfer(pxBuffer, NULL, sizeof(pxBuffer), NULL);
return color;
}
Thanks for any tip which can point me in the right direction again…
BTW: Sorry for the blocking “delay()” commands again… 
You need to first “initialise” the pxBuffer.
For each LED in the strip you need to pre-set the 0xE0.
This is what setLEDs() (in my original code) would do when you send a negative px number or pass invalid parameters.
So calling setLEDs("-1,0,0,0,31") in setup() should do the trick.
Or what I actually already had written in my original code …
… that wasn’t there for decorational purposes but had functional siginificance
OK, thanks for your reply, but I am not using the setleds() particle function in this sketch…
I’d like to use the setAPA102Color() function directly to control each individual strip from within the loop() or from another function.
I added this line to setup() in my sketch above, but the behaviour is still the same:
The sketch sets the colour and intensity but for the wrong pixel #…
In order to mimik the wanted initialisation that setLEDs(-1) (or any equivalent call) performs you need to do this at least once
for (int px = 0; px < LEDCOUNT; px++)
pxBuffer[px] = 0x000000E0;
setLEDs() had this for() loop inside its belly, setAPA102Color() is not featuring any loop hence, calling it for one pixel will always only set one pixel.
Also since you added the SPI.transfer() call to your setAPA102Color() you are sacrificing performance whenever you want to set multiple pixels before actually needing to show them.
Hence I had the separation between updating the pixel buffer (pxBuffer[]) and the actual transfer.
I rather tend to not provide ready-meal answers but rather want my code to be understandable and hence understood
It’s much more rewarding for me when I know I was able to explain a concept than just provide a solution.
With the for() loop in place that setAPA102Color(-1,0,0,0,31) call is superfluous as it wouldn’t anyway do what setLEDs(-1,0,0,0,31) would have done if it were still there 
OK, I can now test this on a Photon.
Next step is to use it on the RPi…
=> Can you maybe give me a tip also how to modify this sketch to use software SPI with any 2 pins as CLK & MOSI?
(In case hardware SPI does not work for RPi …)
As you know, the DOTSTARs work without a library in this case.
Do you mean a library which does just that: Replace the SPI pins with two other pins?
I searched in the Web-IDE for SPI libraries and could not find this… Any tips?
Yup, that’s what I meant.
But it doesn’t need to be SPI at all. That’s just the most convenient and fastest way for hundreds or even thousands of pixels that can be controlled via DMA without too much impact on the foreground logic.
All you need is one pin that goes hi/lo for each bit to transfer and another to actually transmit the state of the data bit. Timing is completely irrelevant which makes things quite simple.
OK, currently, the setup() looks like this with hardware SPI:
void setup()
{
SPI.begin();
SPI.setClockSpeed(8, MHZ);
SPI.setBitOrder(MSBFIRST);
// All DOTSTARs must be pre-set to "0xE0" once:
for (int px = 0; px < LEDCOUNT; px++)
pxBuffer[px] = 0x000000E0;
}
So, I will search for an existing library for software SPI…
I’ll be back! 
I found a few libraries and will try them out.
Do you believe this one may work also on Particle devices?
I’ll try it out tomorrow when I can make some more time…
Originally when you asked …
… I got the impression you already had a SW SPI library in mind and hence I suggested you can use that as is.
But if you aren’t already using one, there is little use in getting one just for that.
The reason being
Any SW SPI library will probably have just as much (potentially even more) performance impact on the rest of your code as doing it without all the extra SPI kerfuffle any library needs to bring along to implement proper SPI.
The simplest approach I’d think of would be shiftOut()
DotStars don’t need anymore than that.