blitzpaper - 2.7in e-paper utility scripts

[philbertw4]

The good

This pull request contains some marginal progress towards making a 2.7in e-paper display (one with 4 buttons) useful for the Raspiblitz, per discussions in #1394 It does not do much, but it at least has some python scripts that allow you to:

• sudo python3 epapersay.py "Reckless Raspiblitz!!!" and such text will be displayed on the e-paper screen.
• sudo python3 paperblitz.py "<cmd1>" "<cmd2>" "<cmd3>" "<cmd4>" will execute <cmd1> when button 1 is pressed, <cmd2> when button 2 is pressed, and so on.
• The commands above could be anything, including calls to sudo python3 epapersay.py
  See the README in the BlitzPaperUI directory for more.

The bad

This by no means is in a read-to-merge state yet. There are a lot of things to fix. For example, right now text is printed to the display in some (arbitrary?) default font at a hard-coded coordinate on the screen. So this needs to be cleaned up considerably.

The ugly

Never developed in python before. At the moment these lines of code barely pass as "software development," but had to start somewhere. Recommendations on the "idiomatic" way to do this both with regard to the python and shell scripts, and also with regard to the Raspiblitz itself are most welcome.

The goal

In the end, the goal is to have a nice clean API that others can use to customize their blitz or, more likely, that apps or the blitz itself could use to provide a nice sat stacking user experience!

[philbertw4]

Before I continue too much more on this, when you have a chance (@rootzoll, @openoms, @frennkie ) will you let me know whether this level abstraction is the right amount for the project in your opinion? Essentially, I am trying to figure out whether this should end up Raspiblitz/specific in a very opinionated way such that the buttons are essentially hard-coded to specific Raspiblitz functionality, or whether we want to keep it general (how it is now) so that anybody (or blitz software/apps) can interact with it from the CLI, set the buttons up to do specific things, etc.

Regardless, the code will of course need to be cleaned up, but just trying to gauge whether I am headed in the right direction.

Thanks in advance for your feedback.

[rootzoll]

I think this is a good start :) Making some smaller scripts to try out basics like out putting texts or using the buttons.

I dont think you need an API - but putting all needed functions into a python module (subfolder) can make sense so later the background running script can put it all easy together.

[philbertw4]

Ok, great. Thanks for the feedback. I will put some more work into it this coming week. So far, all of this has not been using the PaperTTY library. I lean towards pulling in the PaperTTY library to handle the displaying/printing of things on the e-paper display. The advantage of this is primarily two-fold:

1. Customization - It will allow for easy accommodation of any e-paper display which is supported by PaperTTY (there are quite a few). It also uses the same underlying drivers that I was playing with, so there is no real downside risk here I can think of.
2. Maturity - PaperTTY is a much more mature library, with more contributors, etc, yet still just a light weight tool/service

What PaperTTY does not do, from what I can tell, is anything whatsoever with the buttons on the left. That functionality is something unique to the 2.7inch display itself. So, next week, I will try to primarily focus my efforts on:

1. switching to PaperTTY so as to not re-invent the wheel on the printing/display side
2. creating a decent utility script(s)/service for reacting to the buttons

All in all though, I am definitely enjoying having a little e-paper display. The buttons are a nice addition since they could be programmed to send arbitrary commands. For example, coding one of the buttons to trigger a graceful reboot of the blitz might be nice (for those times when logging in via SSH is not working, networking issues, etc).

[philbertw4]

Just a quick note/update here: unfortunately I have not had the time to dedicate to this particular e-paper feature and I am not sure when I will have the time, so it is doubtful that it will be ready in time for any 1.7 release.

[rootzoll]

@philbertw4 thats absolutly fair to mention, thanks - I will leave the issue as a reminder within the v1.7 milestone so that the refactoring that is planed for v1.7 will be done with the ePaper "in-mind" even if we might push it then later into the future-release collector.

[rootzoll]

The UI refactors are shiftet to 1.8 .. good things take time

[rootzoll]

Good news - with the v1.7.2 release all system information that is displayed on the LCD comes now from a cache system that can be called with /home/admin/_cache.sh .. so that way an ePaper Display script can import those values also very easy with example source <(/home/admin/_cache.sh get hddGotMigrationData hddBlocksBitcoin hddBlocksLitecoin hddCandidate). What values are available can be seen if you call on terminal cache export. This cache is managed by a redis in the background - a python script might directly connect with redis to get this values.

With v1.8 now BlitzAPI & WebUI are the focus. New TouchUI for the LCD for v1.8.1 which would also a got slot to add an ePaper option with the v1.8.1.