I think the Kindle browser runs at least basic JS. In any case it refreshes maybe every half hour or so, which is plenty for weather.
Come to think of it I think the Kindle browser is based on WebKit, so it probably runs any JS that the version of WebKit supports, but given the low-power processor and the 0.5 FPS display, you probably won't get anything too crazy to work.
> Once the ink is there, it won't go way by itself.
It occurs to me that an interesting low-power extension could be to have the device turn itself off after refreshing the display and then plug it in via a timer switch.
If the dashboard only needed hourly or daily updates and the previously rendered dashboard stays visible, there's no need to leave the Raspberry Pi running all the time.
This is how I've done it with some of my eink projects.
The downside is that powering down loses the display buffer needed to correctly do partial updates, do you have to refresh the display every time - which is actually very distracting if it's sitting on your desk.
Is that built in to the display unit? It can't be loaded (from your own non-volatile(/battery or cap backed) memory) prior to triggering display update? (I've never used one.)
That's why I'm doing this with an ESP32 instead of an RPi.
The ESP32 has the builtin capability to deep sleep and only draw a few uA of current. In addition, WaveShare offers existing micropython libraries, so it's easy to just flash an ESP32 board with micropython, get your data from an API, format it and go to sleep after displaying it. There are lots of boards with onboard LiIon management, this this setup is very easy to do.
The Raspberry Pi Pico W might be an alternative these days. Of course with only a couple Cortex M0 cores and 264KB RAM running JavaScript would be less than feasible, but rendering a pure black and white framebuffer for a e-ink screen should work OK.
Running a lot of javascript with npm and pupeteer just to render a small picture on a monochrome eink display seems extremely wasteful to me.
You might as well have a ftp site (or equivalent) where you would just dump a YYYYMMDDHHMMSS.png (or jpg or whatever) and a script that just sends the latest to the display.
That would also let you run everything from initrd, so you can follow by a poweroff (and schedule a RTC wake in say 20 minutes)
Using a Raspberry Pi is very wasteful in the first place.
If it's powered from USB, it doesn't really matter, but if you want to power it from batteries (especially something like AAA NiMH batteries) so that you can easily hang it on a wall somewhere and make it last a month or so (refresh every 10-15 minutes maybe), you pretty much have to use something much more low power (like an ESP8266, ESP32, etc.).
Having pre-stored pictures is also unnecessary, just generate them on the fly. Unless generating the picture takes a long time (e.g. having to contact a lot of slow external services), you can just draw it on the server in memory with each request.
In the same request, the device can also send its battery voltage to the server, where you can collect it as metrics.
I was just suggesting a slightly more efficient way that would not require the author to buy new hardware, but I agree: an ESP with direct IO to the "framebuffer" is better.
Anyone interested in trying this should check out the Inkplate. They’re recycled kindle screens that have a built-in microcontroller and Wi-Fi. All you need to add is a memory card flashed with the an OS image, no soldering or other parts needed.
For awareness, I shared this here after I read about it on the 'side projects making more that $500 a month' thread (older thread that was linked to after it was asked again this morning.)
Nice. I'm doing something similar with a BOOX Mira 13.3" touch screen, Raspberry Pi Zero and a Gioui app for the user interface.
I'm building an expedition vehicle on the back of a Mercedes Actros 6x6 semi-truck. I'm using M5Stack ESP32 devices (flashed with esphome) to read all the sensors and control everything. I'm using a MQTT server as the messaging hub: the UI will read/write from that, and the ESP32 devices will subscribe to that for controls.
Here's my notes on getting the e-ink screen working full-screen with a Gioui app (without a desktop linux environment): https://github.com/dave/iot/tree/main/ui
It would be great to find a cheaper alternative (the BOOX Mira is $800 ouch!)
21 comments
[ 3.5 ms ] story [ 53.4 ms ] threadhttps://github.com/matopeto/kindle-weather-dashboard
If you want to display something more, you could just self-host a page.
Come to think of it I think the Kindle browser is based on WebKit, so it probably runs any JS that the version of WebKit supports, but given the low-power processor and the 0.5 FPS display, you probably won't get anything too crazy to work.
It occurs to me that an interesting low-power extension could be to have the device turn itself off after refreshing the display and then plug it in via a timer switch.
If the dashboard only needed hourly or daily updates and the previously rendered dashboard stays visible, there's no need to leave the Raspberry Pi running all the time.
The downside is that powering down loses the display buffer needed to correctly do partial updates, do you have to refresh the display every time - which is actually very distracting if it's sitting on your desk.
The ESP32 has the builtin capability to deep sleep and only draw a few uA of current. In addition, WaveShare offers existing micropython libraries, so it's easy to just flash an ESP32 board with micropython, get your data from an API, format it and go to sleep after displaying it. There are lots of boards with onboard LiIon management, this this setup is very easy to do.
You might as well have a ftp site (or equivalent) where you would just dump a YYYYMMDDHHMMSS.png (or jpg or whatever) and a script that just sends the latest to the display.
That would also let you run everything from initrd, so you can follow by a poweroff (and schedule a RTC wake in say 20 minutes)
If it's powered from USB, it doesn't really matter, but if you want to power it from batteries (especially something like AAA NiMH batteries) so that you can easily hang it on a wall somewhere and make it last a month or so (refresh every 10-15 minutes maybe), you pretty much have to use something much more low power (like an ESP8266, ESP32, etc.).
Having pre-stored pictures is also unnecessary, just generate them on the fly. Unless generating the picture takes a long time (e.g. having to contact a lot of slow external services), you can just draw it on the server in memory with each request.
In the same request, the device can also send its battery voltage to the server, where you can collect it as metrics.
I was just suggesting a slightly more efficient way that would not require the author to buy new hardware, but I agree: an ESP with direct IO to the "framebuffer" is better.
https://inkplate.io/
They also have a 9.7” version: https://www.crowdsupply.com/soldered/inkplate-10
Thanks to jlengrand https://news.ycombinator.com/user?id=jlengrand for sharing this!
This link was posted as an alternative to someone's paid project https://news.ycombinator.com/item?id=30002491
I love it, really want to make something similar, just need the time/focus!
One nitpick: It seems odd that, if I understand correctly, the data being served is from Netlify. Why not serve it locally on the device?
I'm building an expedition vehicle on the back of a Mercedes Actros 6x6 semi-truck. I'm using M5Stack ESP32 devices (flashed with esphome) to read all the sensors and control everything. I'm using a MQTT server as the messaging hub: the UI will read/write from that, and the ESP32 devices will subscribe to that for controls.
Here's my notes on getting the e-ink screen working full-screen with a Gioui app (without a desktop linux environment): https://github.com/dave/iot/tree/main/ui
It would be great to find a cheaper alternative (the BOOX Mira is $800 ouch!)