Yes, that's how my params function expects it. I just built a simplistic parser to allow setting more than one single param per API call (but as said, still limited as the string length that can be passed via the cloud API is limited to ~50 chars).
@Elijah: from a http POST point of view the request only has two paramters, one is called "access_token" and needs to carry a valid token, the other is called "args" and carries the MeesageTorch specific parameter string which ist of form param=value[[,param2=value2],param3=value3] etc.
There's no way to get rid of the "args=" prefix, that's how the Spark Cloud API works. In all your examples, you omitted the "args=", that's why they didn't work.
You seem to have found out that the prefix can be anything in the form of "yyy=". However, that's probably more of an accident in spark's current cloud code, so I'd recommend to stick with "args=" because that's what the specs say.
FWIW, I found that your average Parmesan Cheese container is just about the right size to hold 2m of LED strip, with about 10 rows at 12 LEDs per row (for a 60/m strip). I just peeled off the label, then used some solvent to clean off any remaining adhesive (I used OOPS spray).
I like that version - the larger diameter makes the text more readable!
BTW, you can easily shift the baseline of the text by changing the text_base_line variable (or same named parameter via the cloud)
@Hootie81, each 5m length has 300 LEDS which requires a display buffer of 900 bytes. My guess is that with the latest RAM optimization, you should be able to do 10m length.
The buffer for the driver is only 2 bytes per LED (I squeezed 3*5bit brightness value into 2 buffer bytes, and expand these on the fly into 3 byte RGB PWM values).
However, the flame animation calculation also needs 2 extra buffer bytes per LED, so the total bytes is 4*(number of LEDs). With this and disabling cheerlights, I got it running with 240 LEDs on FW v2.3.
I think it was still v2.2 when I did those optimisations in my code. Probably v2.3 has already some more memory free than v2.2 had.
I havenāt pushed beyond 240 LEDs so far (as I donāt have more than these 240 right now). Iām eager to hear how it goes with @Hootie81 connecting 12 meters ā¦
Another thought: the fact that omitting cheerlight or digitalstrom options made so much difference in RAM usage canāt be the code itself (itās a few lines, almost no RAM used). So it was probably because both features defined their own spark cloud function handler, which apparently was quite RAM consuming in the spark core fw. Maybe v2.3 had some fixes in this regard as well.
@luz, there were MAJOR RAM optimizations done in v2.3. The v2.2 TCP and UDP clients had large buffers allocated to them (which is now reduced) and I believe in future versions, this allocation will be done dynamically instead of statically as is done now. Thatās why I believe doing 12 meters is feasible now
@peekay123, I already tried that, but if you set ārandom_spark_probabilityā to zero, there are no flames anymore, but only the two first row are glowing.
