domgarguilo / ledserver Goto Github PK

Right now the frameIDs are used in the metadata to pull each frames data. After that, a frames frame ID is not kept in association with the other metadata. I think first, a frame ID array could be added to each animation object, then to clean it up, we could find some other way to store the data in the client instead of one big json containing everything.

This seems like a good idea so that if several get requests are made for the data, we don't have to re-read the file and can just have the JSON in memory ready to send.

If there are no animations to be displayed, display a message saying such.

It would be better to use a local mongo instance instead of relying on the online atlas service.

The matrix will ping the server to see if it needs new data. Could be cool to have a display of each matrix that connects to the server and the last time it was heard from

Currently if there are no animations, the app will crash here:

The app should just display no animations and possibly a message saying that there are none.

Follow on of #21

#21 made it so that we can drag and drop to rearrange the order of animations, now we need to make it so the order of the animations will persist between reloads. To do this we need a way to track the order of the animations in the list and then have a way to save it. Maybe a save button should be added.

A way that might make this more efficient could be to add an array to hold the order of the animations so that rather than adjusting the order in which the animations appear in the actual json file just an array of IDs is adjusted. This array may need its own file.

There is a lot of conversion and intermediary objects that get created when upload of an image takes place. There should be an attempt to make this process more efficient. One way this could happen is make the helper methods more modular so they can be used in more cases so that an image does not have to be converted into something that a method accepts then converted back afterwards.

There are probably several ways to automatically switch the URL for the server when in development vs. in production. For now, one has to manually switch to localhost when developing and then make sure it is switched back before pushing upstream:

Not all animations have to be sent every time. The client (ESP32) could tell the server which animations it already has (maybe a list of animation IDs) and then the server will check its master list of animations and just send the difference.

Might be a nice swap to react. Not a priority but might make development easier. Maybe once the core functionality of this app is in place we can move things to react and further development there.

At first this can be a textbox where the user can just paste in the json containing the animation data. Later on we can work on uploading images or sets of images.

When a new animation if inserted into the queue, the Animation component does not always work.

In the example in the screenshot, the bottom WholeBox is correctly created except for the animation portion. Not sure whats causing this maybe some sort of timing issue. Seems to happen about half the time?

Now that the db is local, no need for a password to be stored which is the only thing the dot env file was being used for. Replace needed areas with hardcoded string.

For development, I want to have the server running on http://localhost:5000 and the react app on http://localhost:3000. For this I think a proxy needs to be configured so that when the react app makes a request, the request is redirected through the proxy to the server on port 5000 (e.g. a get request from the react app on /data will pull from http://localhost:5000/data rather than http://localhost:3000/data). I tried to do this following these instructions, but it doesn't seem like its correctly redirecting the request to port 5000.

To work around this issue I have just been hardcoding port 5000 for development and then using window.location.href for production, but shouldn't have to do this.

We could optimize the animations by removing some of the values. This is possible because of the way the led matrix works. Each LED will remain the same color until it is set to a new one. This means if we have an animation where an LED has the same color value in two consecutive frames, we can remove the entries that would just set it to the color that it already is. e.g.

Frame 1: LED [1] = '#555555'
Frame 2: LED [1] = '#333333'
Frame 3: LED [1] = '#333333'
Frame 4: LED [1] = '#333333'

could be reduced to:

Frame 1: LED [1] = '#555555'
Frame 2: LED [1] = '#333333'
Frame 3: LED [1] = ''
Frame 4: LED [1] = ''

This would reduce the amount of data sent to the client (ESP32)

Seems hard to describe but all we gotta do is iterate through the frames in an animation and remove all values where the previous arrays' color value is the same as the current.

would be nice to have a button that removes images from the queue

maybe at somepoint we can make it so there is a stored bank of animations that we can choose to add to the animation queue or not.

Add the amount of time per frame in the animation previews. Probably needs to happen in generateCssDetails()

Instead of having the header and edit modal separate, we can just make an empty modal open up when creating a new animation. That way we can just have a single spot to edit frames and metadata.

Add a way for the LED matrix (client) to do a get request. The response to the get request should be the json files containing each animations' data.

When an animation is pulled from the server, first a small json containing the metadata is pulled and then using that, each frames data is pulled in order.

It would be nice to populate the page with skeletons of the animation boxes and then fill in the frames as data is received and once all frames have been received, play the animation preview.

Would be good to know when there is data that can/should be pushed to the server. Right now there is no indication whether there are any updates that can be sent or if anything has already been sent.

Maybe some save icon can be displayed normally when there is no updates to be saved/sent and the icon can change to indicate there are changes that will be lost if not saved.

At different zoom levels the previews can become messed up like this:

with lines in between the rows/columns of pixels. The previews should look the same at any zoom level.

When attempting to start the server for development on a clean install of the project, it will error out when looking for the favicon that does not exist where it is looking for it.

node:internal/fs/utils:345
    throw err;
    ^

Error: ENOENT: no such file or directory, stat '/home/dgarguilo/github/samples/LEDserver/server/build/favicon.ico'
    at Object.statSync (node:fs:1551:3)
    at resolveSync (/home/dgarguilo/github/samples/LEDserver/server/node_modules/serve-favicon/index.js:187:17)
    at favicon (/home/dgarguilo/github/samples/LEDserver/server/node_modules/serve-favicon/index.js:61:12)
    at Object.<anonymous> (/home/dgarguilo/github/samples/LEDserver/server/server.js:106:9)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
    at node:internal/main/run_main_module:17:47 {
  errno: -2,
  syscall: 'stat',
  code: 'ENOENT',
  path: '/home/dgarguilo/github/samples/LEDserver/server/build/favicon.ico'
}

This happens because during production, there will always be /build, the production build created by npm run build of the react app, in /server.

To mitigate this error you just need to run npm run build within /client then copy/move the build dir into /server. But the project should be resilient to this and at least catch the error and tell the user whats wrong. Better yet, somehow don't require the favicon to be present.

It would be cool to have a catalog of all animations that have been uploaded to the server. That way, it would be easy to take animations off and on the current queue.

Might not be too hard to create. Here are my initial thoughts:

• we have a separate document in mongo for the list of the current animations and their order. This is a reference to which animation are currently in the queue and in what order which would be used to populate the page and is what would be sent to the LED matrix.
• When an animation is removed, it is just removed from the order list instead of deleted entirely from mongo. Then there could be an option to view the animation catalog which holds all animations ever uploaded to the server. This could also be deleted from and maybe added to.
• When uploading a new animation, there can be an optional field for the name of the animation which potentially could be used by a user to search for an animation in the catalog i.e. "christmas"

In order to add more control over the frame duration and repeat count, I think we need more space to put these fields instead of within the same box as the frames.

One idea is to have an edit button that when clicked will bring that WholeBox component front and center and disable interaction with the other ones until it is closed. In this state, the user can change the frame duration, repeat count and order.

Currently, when you press upload without first selecting an image to upload, a plain black square will be uploaded instead of nothing. We should make it so that nothing is uploaded to the server in this case.

Currently we can only upload still images. We need to figure out a way to upload animations. I think the easiest approach may be to upload multiple images which are displayed to the user in a draggable queue which has CRUD capabilities similar to the animation queue. Maybe while the user is doing this, they cant interact with the other parts of the page until they save the current image. I'll draw up some sketches for how I see it in my head.

It would be nice to have each frame in an animation listed out next to the animation itself. This could be the same queue of frames that will be interacted with when editing an animation (whose changes will come with #26)

Would be super nice to be able to upload an image file and have it converted to the json document.

Could loop through the pixels to determine their color value and populate the json array that the matrix uses.

Current behavior:
If two users are adding/changing animations at the same time, only the most recent update sent to the server will take affect overriding any previous changes.

Expected behavior:
If two users are making changes at the same time, their changes should somehow be merged instead of only one set of changes taking affect. For example if two users each add a new animation, we would want both of them to be inserted instead of one just not appearing. If a user deletes an animation while another user is making changes that should be fine.

Currently, the uploaded animations are hard-coded at a set duration and repeat count. We need to be able to change those.

To do this we could add additional fields to the HTML form for entering duration and repeat count which would be inserted and sent along with the new animation data to the server.

Add ability for the client to check their firmware version and pull the new one if out of date.

Could have a directory to store the firmware file(s) and have the server read the filename on boot in order to get the current up to date firmware version. then, the server can answer requests that contain the clients current version with a status code of 200 for OK, no update needed and 204 to indicate that the clients firmware does not match and along with that, the firmware stream.

router.get('/firmware/:clientVersion', (req, res) => {
  const clientVersion = req.params.clientVersion;
  const serverVersion = getCurrentFirmwareVersion();

  if (clientVersion === serverVersion) {
    res.status(200).end(); // 200 OK, firmware matches
  } else {
    const firmwarePath = path.join(__dirname, 'firmware', `firmware-${serverVersion}.bin`);

    fs.stat(firmwarePath, (err, stats) => {
      if (err) {
        res.status(500).json({ error: 'Error reading firmware file' });
      } else {
        res.setHeader('Content-Length', stats.size);
        res.setHeader('Content-Type', 'application/octet-stream');
        res.setHeader('Content-Disposition', `attachment; filename=firmware-${serverVersion}.bin`);
        res.status(204).end(); // 204 No Content, firmware doesn't match
        fs.createReadStream(firmwarePath).pipe(res);
      }
    });
  }
});

Add accounts so that only authorized users can login and edit animation queues that they are authorized to edit. We don't want to have the main queue open so that anyone can go to the website and edit the main queue that the matrices pull from.

I think the order of features should be:

1. add demo page that resets its queue every hour or so
2. add accounts so that only accounts can access the actual queue
3. add the ability to create new queues and dictate which accounts have access

We should be able to have a visual representation of each image/animation in the queue. I was thinking either the images could be dynamically generated from the json files that they are associate with, or just saved image files (png/jpg/etc.)

If we do the dynamic image generation from the json files, might be easy to just fill a 16x16 html grid with the color values, similar to how the LED matrix populates its colors.

Currently, the whole build folder is sent as part of express.static. That doesn't need to happen. Might not need to use express.static at all. Needs triage

To get this working, we need to have the data persist between sessions. As of now, heroku will not save the changed data in between sessions. It seems like there are a few options:

1. Use some other version of heroku that will persist
2. Use a database i.e. firbase or mongo
3. Selfhost the app and just keep the storage text based. This would require figuring out how to safely self host and stuff.

The image queue is sloppily put together and breaks if the size if messed with. We need to make it more robust. Maybe adding the html elements in a smarter way.

Sending frame data as a string is a lot less efficient and can lead to data too large errors when sending multiple frames (right now about 16 frames causes this.

Currently its just the default:

and should be changed

When you send the state to the server, the frameIDs get overwritten. We need to make sure that a frames ID stays with that frame even on the client.

Would be nice to use the same preview type for both displaying the animation queue and preview of the image upload. Would be better to use the CSS display so that we know for sure how it looks - the current image upload preview blurs to fit into a larger size.