Feature request [ want to be able to run the page from script or command or api so we can do moving pixel art or gifs ]
Opened this issue · 7 comments
Hi , I could not open Feature request .
Basically the aim is to run the same page multiple times to get something like moving pixel art or gifs .
A command line or url that would accept the wled ip , image . and then send the api would be nice ,
One other option is to be able to save the api directly from the page to preset or a file under wled-ip/edit .
Again this is a feature request but over all great tool , i wish to see you more on wled discord as this tool is used by a lot of people and you are the hidden soldier in that. . Thank you
I agree... That is the next natural evolution, isn't it 😁
There are quite a few snags to get that working though and the most user friendly way to implement it is perhaps not clear to me, yet. Lots of thoughts and tests done allready though. I would presume it would be preffered to have an arcitechture discoussion within the WLED dev forum.
Adding the functionality to POC is not a big issue, once a way to implement it into WLED effectively.
I'll leave this FR here and hit you up on Discord instead
Check new beta
I did not want to open a new issue but i will if you think it is a good idea here or in AC ( which will be forgotten ) .We are seeing limitation when trying to use MQTT to send the api from any MQTT client , HA , Node red ..etc This is wled limitation and not your tool nor MQTT protocol. When sending an api for 16x16 only about half of the pic is displayed . I have tried with Blaz and got only a reference to adjust -DMQTT_MAX_PACKET_SIZE=1024 but we tried and it did not work . Having MQTT working for pixel art would simplify a lot of other ideas after . Other wise I hope you are doing well . I think you keep working around limitation in wled and I am starting to think that a firmware tailored to pixel art might not be a bad idea .
My guess is that the JSON library/handling/format is the issue. In new PAC much larger images is uploaded and run and JSON is bypassed alltogether. I would guess the limit here would be the compute of the ESP32 and then 64x64 should at least be possible (4X32X32 on four separate pins f.ex.) Goal is to make the animations/pixel art completetely self sufficient on the WLED device so you can simply call a preset over the API. I have that working on my DEV ESP32 just fine. Need to find the time to stitch it together into some sort of beta. I'd be happy if you would be able to test it and contribute feedback then.
I think as is at the moment we have a working pixel art so you could take your time with enhancement . Still I will test anything you have in mind
Hi werkstrom,
Jumping into the discussion, is there somewhere I could read what you've done for animations? like a branch or something?
You mentionned you did it directly on the ESP32 so I guess it's part of the WLED repository on one of your branch?
I'm very interested into implementing this as well, also willing to work on some POV display options but wondering which way is the one to go.
I was thinking of using your very nice Flow editor and add another option to "Matrix/Serpentine/POV" with some options.
Best,
@Liliputech Due to lifes unexpected (or expected) turns, I have quite litterally zero time to put nto this at the moment. Which is a bit unfortunate really, since the code actually works really vell apart from a "bug" where the reading of the data from file on the ESP32 some how stops for a fraction of a second. Some sort of issue with that piece of code nog getting priority on the ESP32 is my guess. UI is updated to use encoding of animated gifs with super-minimal footprint on the ESP32 device. So if that issue could be figured out, I would guess you would have what you need. What we probably would need is someone who knows the C-part of this and the more inner workings of the ESP32. I've managed to get the logic correct and (IMHO) rather efficient, but I know way to little about the ESP32 to troubleshoot the stuttering efficiently.