Playing around with my new waveshare 7in3g e-paper screen, going to try and render a calendar
There's something a bit screwy around "burn in" I've read both that it occurs and also that it doesn't occur. Try to avoid leaving the screen with stuff on it for more than a day, if you want it always on, do the clear thing at least daily so it jiggles all those pixels around.
TODO: add venv instructions
Keep the python peas from touching the other python carrots
create a venv using:
python -m venv .venv
put powershell into venv mode using:
.\venv\Scripts\activate.ps1
put powershell into venv mode using:
source ./venv/Scripts/activate
The thing requires a few system dependencies.
This is really only relevant on the pi itself, which is running a debian thingy, so apt-get with:
TODO: add system dependencies
python dependencies are managed in requirements.txt
when in venv mode install using:
pip install -r requirements.txt
TODO: add waveshare dependencies to requirements.txt
git clone or copy this repo to the rasberry pi. I keep mine in /home/thetrav/calendar
install dependencies with:
pip install -r requirements.txt
Schedule the main screen update for hourly with:
crontab -e
0 * * * * cd /home/thetrav/calendar && /usr/bin/python /home/thetrav/calendar/main.py >> /home/thetrav/calendar/log.txt
I use nginx for https and python web server
sudo apt install nginx
Next I generated a self signed cert following the guide here: https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-nginx-in-ubuntu-16-04
I hit enter for all params except common name, where I enter the rasberry pi's ipv4 address (I have the DHCP lease statically asigned by my router)
The server invokes a locally running cherryPi app which needs to be set up as service with:
sudo vi /lib/systemd/system/epcal.service
enter contents of epcal.service then reload with:
sudo systemctl daemon-reload
The app will require client_secret.json in the project root.
You can download that file from google.
They have a tutorial here: https://developers.google.com/identity/protocols/oauth2/web-server
getting the API set up is part of the pre-requisites.
In order for it to work you need a public DNS entry (google doesn't trust ip's or local DNS names). My solution was to set a subdomain to resolve to a private network IP which I've told my router to always assign to the calendar rasberry pi.
While developing I run things locally, main.py contains a local and hardware rendering function, you can just switch which one you pass into the run function and everything else should work fine.
I've also got a testData function for when I don't want to wait for a round trip from google or in case I want to test a hard-to-recreate data scenario.