Skip to content

Conversation

@MidnightJava
Copy link

Added a button to export the current pattern on each matrix to a json file, and a button to import such a json file and apply it to either matrix.

@MidnightJava
Copy link
Author

Tested import and export round trip. Also tested that malformed json does not cause an error on import. Tested a file with > 39 values, < 39 values, and values > 255. Attempt to import an invalid json file will make no change to the matrix, and an error will be logged on the console.

@MidnightJava
Copy link
Author

Added a Persistence checkbox. When this is checked, the display will never sleep, as the app will send the wake command in the background periodically before the sleep timer fires.

@timoteuszelle
Copy link

Hi everyone,

Mark and I are working together on a LED matrix monitoring project that uses the Framework LED Matrix module as a status/indicator display. This PR (#11) is a great fit for the hardware side of that workflow, since it defines a clear import/export format for patterns that can be sent directly to the device.

To support the software side of the project (icon libraries, monitoring indicators, etc.), I’ve opened a follow-up PR #12:
#12

PR #12 is based on the current head of this PR and keeps all of the behavior here exactly as-is (39-byte hardware pattern format, UI, persist, wake loop). On top of that, it adds a separate “Export for Software” JSON export:

  • Binary or grayscale (0–255) values
  • Fixed column-major 9×34 layout that matches the LED matrix orientation and the icon format we use in the monitoring project

In practice, the workflow we’re aiming for is:

  1. Use this tool to design patterns/icons on the matrix.
  2. Use the existing import/export from Import and Export patterns #11 for hardware tests.
  3. Use the new JSON export from Feature/software icon export on pr11 #12 to feed those same icons into the monitoring software.

If you prefer to keep things focused on the hardware workflow, you can merge #11 on its own. If you’d like the software-oriented export alongside it, you can merge #12 instead as a superset of this work. I’m happy to adjust naming or wording in #12 based on your feedback.

Thanks again for putting together the original import/export implementation—it's been very straightforward to build on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants