e-paper display with PaperTTY

[philbertw4]

I would like to eventually manifest this as a pull request. However, it is still a hodgepodge of trial and error right now, so starting it off as an issue. Nevertheless, I managed to get a 2.7inch waveshare e-paper hat working on my pi4. All in all, it turned out to be relatively straight forward.

When logged into my Raspiblitz as user admin, I cloned https://github.com/joukos/PaperTTY and followed the install instructions (way down towards the bottom of the readme).

After install, I have been able to do things like (as admin user):
echo "Hello World" | sudo papertty.py --driver epd2in7 stdin --nofold --size 14

or, to get a full blown terminal, I can:

1. start a screen session and run sudo ~/.virtualenvs/papertty/bin/python3 ./papertty.py --driver epd2in7 terminal --vcsa /dev/vcsa2
2. in another screen session run sudo openvt -fc 2 -- sudo -u admin screen followed by screen -x <name> to attach to the screen.

At that point, both the e-paper display and my ssh console are shown the raspiblitz menu. Just a plain terminal itself would probably be preferred, but I'm not sure how to proceed from where I am. This level of shell scripting and "ttys" is quite new to me.

If, for example, I wanted the e-paper display to simply show the bestblock hash and it's height, I probably do not need a full terminal and something similar to the first command above would do. However, it seems that updating the display needs to be done by the admin user since sudo is required.

If there is a particular thing I need help with next, it is this:
What is the easiest/recommended/idiomatic way in the context of a Raspiblitz for me to have a little script run by the admin user every time, for example, a new block arrives?

My original thought was to utilize the blocknotify=<your shell command> bitcoin.conf feature. However, since the Raspiblitz runs bitcoind as user bitcoin and that user does not have sudo privileges, then if the shell command passed in required sudo, it would fail. Additionally, it seems that ZMQ is probably the preferred method in bitcoin core these days.

So, this then leads me to think that a better method might be to:

1. create a small service (probably written in python or something) which subscribes to any of bitcoind's ZMQ messages it might need to update the display.
2. then, since the service would be run by the admin user, it could execute the sudo papertty.py ... command(s) necessary to update the display.

Is this the general method that you would recommend? Thanks in advance for any pointers.

Misc Details:
The particular model I tried is https://www.amazon.com/gp/product/B07PKSZ3XK, but the foregoing seems applicable to most any other model. A model that supports partial-refresh is probably preferred for most use-cases that require a more snappy response time.

[rootzoll]

Hi. Thats a cool project. We had also in mind to provide at one point a e-paper option for the RaspiBlitz. Thanks for sharing.

@frennkie did the graphical touch display for the RaspiBlitz and there would be many details that would be best to coordinate on.

I will take a look at this once the start diving deeper into the next release - so I will mark this for milestone 1.7 - to maybe have a minimal first implementaion of a e-Paper display possible.

[philbertw4]

Great! As a first pass, it should be pretty easy to at least get the existing status display (what is currently shown on the non-touch-enabled LCDs) to display on an e-paper display if that is the goal.

At least for me, there are two primary reasons why I am interested in an e-paper display:

1. such a display, because it produces no backlight, is more amenable to being located in places where an LCD might be a nuisance, especially at night time
2. as a step towards an a low-powered/solar-powered Raspiblitz.

[rootzoll]

@philbertw4 the "4 buttons on the left side of the ePaper" you mentioned make it easier to keep have a similar interaction like the LCD-Touchscreen that also uses 4 virtual buttons on the left side .. I thin functionality will be different, but there is some consistency in there I like.

To give you a start take a look at the 00infoBlitz.shscript around line 378 ... it produces /var/cache/raspiblitz/info.json file that contains all the basic data needed to display and will be updated on the regular.

Also the file /home/admin/raspiblitz.info is a source of state during setup. For a first prototype you can display the "state/message" and the SSH login info as long as the `state!=ready.

[philbertw4]

Ok, thank you for the pointers. I'll try to put some time into this for us over the next week. Also, good idea regarding the 4 buttons on the side of the e-paper display -- I actually hadn't even noticed those buttons existed yet! I think that PaperTTY library I found and tested has no real notion of buttons though, so, while I like the idea of incorporating the buttons, that may be a next-iteration detail. As a first pass I will just start on getting the basic display showing and updating on a regular basis as you suggested.

[philbertw4]

Adding some notes here as we start digging into this:

• This Article seems to have a good amount of info about how to interact with the e-paper display from scratch. It also includes some code showing how to use the buttons. Of note is the comment at the end of the article where the author recommends spending the extra $5 for the 2.9-inch e-paper display so as to be able to take advantage of partial-refresh. Sadly, the 2.9-inch does not also have any buttons.
• I think having buttons would be nice, so I lean towards continuing with the 2.7-inch. However, it is important to remember that it takes multiple seconds for the display to refresh.

[rootzoll]

I think a slow display is not the problem for it to show status information. Having at least "a button" for Shutdown for the RaspiBlitz was always an important need - so "Hooray for Buttons" 👍

[rootzoll]

I like to cross-link this research - just as a keep in mind: #1265

For better UX during SetUp it would be helpfull to detect if and what display is connected to the RaspiBlitz automatically.

[philbertw4]

Ok, thanks. Also, one more question as I get started here. I can't seem to find in the documentation the best practices for actually patching together changes like this. I have one live (mainnet) Raspiblitz node that I will be primarily doing both the development and testing on. Is the best method to use XXsyncScripts.sh pointed at my own fork? Sorry if this is already obvious to many of the other contributors.

[rootzoll]

Take a look here and let me know if there is anything missing:
https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#how-can-i-sync-a-branch-of-my-forked-github-with-my-local-raspiblitz

[philbertw4]

Started work here based off v1.6 branch: https://github.com/philbertw4/raspiblitz/tree/feature-blitzpaperui/home.admin/BlitzPaperUI Will open a pull request once I'm further along.