Since updating an eInk screen is relatively expensive, I suspect this system could be made more efficient by issuing conditional HTTP requests (last-modified or eTag) and only refreshing the screen when the dashboard image changes. This assumes both the ht client and dashboard server support conditional requests.
The system consists of a set of shell scripts that run on a jailbroken Kindle. It includes ht, an HTTPie clone written in Rust that makes requests to a dashboard server using software like Dashbling.
The ht program doesn't appear to support conditional downloads. It also doesn't support a HEAD request, which is odd, as it supports GET, POST, PUT, PATH, DELETE. With a HEAD request, you could do the Etag or Last-Modified comparison yourself.
I suppose you could just download the image and do a "diff -q" or compare an MD5 checksum, or even just file size.
Edit: Appears that ht may be able to get response headers. It's sort of a documentation bug. It has a -p/--print option, but the README doesn't document what the arguments are.
Found it.. "ht -p h https://google.com" returns the headers, so you could extract the Etag or Last-Modified header.
I could replace ht with another HTTP client. I just picked it because it was the easiest way I knew to compile an HTTP client with statically linking openssl.
If anyone knows an easy way to compile curl with statically linked openssl, let me know!
It would also not be difficult to build a small custom client based on Hyper or Reqwest.
Though I'm not sure if it would actually make a large difference with only 20 screen refreshes per day.
I wrote something like this using reqwest for a Waveshare 7.5inch display. Also includes a dithering step so all that is needed is a web server serving an image. No conditional requests though but should be easy to add. It is fully statically compiled (even uses musl and rustls), runs on a very bare-bones Linux environment on a Raspberry.
If it's really just the screen refresh that's to be avoided, I think just comparing old download /new download with "diff -q" would be a reasonable solution. Of course, perhaps the Kindle doesn't have a diff binary. But maybe it has "sum" or "md5sum" or something else in that space.
HTTPie supports headers using header-name:value CLI parameters; I didn't check whether ht supports these. You would have to save the proper response header between requests. The question then turns to how the 304 Not Modified response is handled.
That's an interesting idea! It depends a bit on the data that is shown on the dashboard, but I guess in many cases the data is quite static. The data on my dashboard can change at any time in theory, but there are many times where the data remains the same for 2-3 hours.
Comments
Since updating an eInk screen is relatively expensive, I suspect this system could be made more efficient by issuing conditional HTTP requests (last-modified or eTag) and only refreshing the screen when the dashboard image changes. This assumes both the ht client and dashboard server support conditional requests.
The system consists of a set of shell scripts that run on a jailbroken Kindle. It includes ht, an HTTPie clone written in Rust that makes requests to a dashboard server using software like Dashbling.
The ht program doesn't appear to support conditional downloads. It also doesn't support a HEAD request, which is odd, as it supports GET, POST, PUT, PATH, DELETE. With a HEAD request, you could do the Etag or Last-Modified comparison yourself.
I suppose you could just download the image and do a "diff -q" or compare an MD5 checksum, or even just file size.
Or use a different tool maybe? I see that rural supports head requests. https://crates.io/crates/rural
Edit: Appears that ht may be able to get response headers. It's sort of a documentation bug. It has a -p/--print option, but the README doesn't document what the arguments are.
Found it.. "ht -p h https://google.com" returns the headers, so you could extract the Etag or Last-Modified header.
I could replace ht with another HTTP client. I just picked it because it was the easiest way I knew to compile an HTTP client with statically linking openssl.
If anyone knows an easy way to compile curl with statically linked openssl, let me know!
It would also not be difficult to build a small custom client based on Hyper or Reqwest.
Though I'm not sure if it would actually make a large difference with only 20 screen refreshes per day.
I wrote something like this using reqwest for a Waveshare 7.5inch display. Also includes a dithering step so all that is needed is a web server serving an image. No conditional requests though but should be easy to add. It is fully statically compiled (even uses musl and rustls), runs on a very bare-bones Linux environment on a Raspberry.
https://git.pixelspark.nl/pixelspark/sparkboard
Nice work!
If it's really just the screen refresh that's to be avoided, I think just comparing old download /new download with "diff -q" would be a reasonable solution. Of course, perhaps the Kindle doesn't have a diff binary. But maybe it has "sum" or "md5sum" or something else in that space.
HTTPie supports headers using header-name:value CLI parameters; I didn't check whether ht supports these. You would have to save the proper response header between requests. The question then turns to how the 304 Not Modified response is handled.
That's an interesting idea! It depends a bit on the data that is shown on the dashboard, but I guess in many cases the data is quite static. The data on my dashboard can change at any time in theory, but there are many times where the data remains the same for 2-3 hours.