domgarguilo / ledmatrix Goto Github PK

The main file is getting too big. need to figure out some good categories or ways to break the code up into multiple files.

If we want the matrices to pull the current data from the server we need to figure out how often that should happen. Don't want too frequently or too infrequently.

push all the current files to legacy branch and just have one main ino file

Maybe every like 10 minutes or something we can try to reconnect to wifi if it initially failed. Might be a bit tricky if we want to put this into the async loop but should be feasible.

Would be nice to be able to have other animation types displayed e.g. the xy test for fast LED is cool. Wouldn't be too hard to hardcore these (probably) but would be difficult to get working with the server.

SPIFFS is deprecated

Convert the main loop to a non-blocking loop. Check for elapsed time of events.

The only way to tell whats going on in the code is to have the serial monitor up. It would be nice to have a way to tell what part of the script is running without that.

One idea is to have the matrix light up different colors depending on whats going on. For example, blue when connecting to wifi, red when wifi fails, orange when setting up SPIFFS, etc.

This is to reduce what's in memory at once. A whole file is read at once so if the file is too big, there is a cap to the number of animations we can have total. Either need to have each animation in its own file which is read just before it is displayed, or find a way to just read in part of a file at a time so only part of it is in memory.

When the system is powered on, would be nice to have a loading bar of sorts where a bit completes at each stage like connecting to wifi, pinging the server etc.

Could check if there is enough space to write new frame data files. There is probably enough space to write a bunch but if it eventually fills up, we dont want things crashing or only working with new code that deletes old files.

Simple solution:

1. check if wifi successfully connects
2. if it does, wipe all files and write new data files

Better but more complex solution:

1. maybe on automatic update, check how much file storage is left
2. if space is running out, delete all files that are not present in the metadata.

Chunking can improve file io performance. see:

https://arduinojson.org/v7/api/json/serializejson/#improve-file-write-performance
https://arduinojson.org/v7/api/json/deserializejson/#improve-read-performance

If the device has failed to connect to wifi, we dont want to check for updates to the server until that is resolved.

To handle this lets skip checking for updates if currently offline, and handle trying to reconnect to wifi as a separate task (#22).

Make the server have a way to check firmware version and pull new firmware if out of date.

Since the filenames have a max length that is less than the length of the UUIDs for the frame IDs, we need to truncate the IDs in order to use it for the filename. Create a method so we don't duplicate the code for read and write.

Right now, if we cant get the metadata from the server (either cause offline or request failure), the program stalls. We want to make sure that things still work offline or if we cant get the new metadata.