I'm doing something similar though I've opted specifically to _do_ use Kubernetes via k0s [0]. It works wonderfully well and allows me to use most things that are available in the k8s ecosystem like cert-manager [1] and external-dns [2]. All configuration is stored in Git and the server itself is basically disposable as it only runs k0s and some very basic stuff like iptables rules.
I see this sentiment quite a lot that k8s is too complex for small scale setups, but in my experience it scales down very well to small setups. Granted, you do have to know how to work with k8s, but once you learn that you can apply that knowledge to many different kinds of setups like k0s, bare metal, EKS/AKS etc.
Do you have any estimates how resource hungry k0s is? Ran few resource constrained k3s clusters, where 25% of cpu was always spent on running k3s itself.
Very similar. I guess it's really k8s (the control plane) itself that is so resource intensive. Looking with top right now kube-apiserver, kubelet, kube-controller, kine and k0s use 13.5, 12.5, 5.6, and 3.0 % CPU respectively. Obviously it fluctuates quite a bit, but seems to be around 25-30% of 1 CPU core too. Also uses about 500-600mb of memory.
So yes, it definitely takes quite a bit of resources. I'm running this on 4 CPU cores and 6 GB memory, so 25% of 1 core and some 600mb of memory still leaves plenty of resources for the services. On a more philosophical note (as was mentioned below in this thread), it is a bit wasteful perhaps.
Curious what makes you think k3s is the better choice? The only reason I ended up going with k0s was that I had problems getting k3s working well behind a locked down firewall. With k0s that was pretty easy.
Might be nice to deploy the Flutter app on the web too. Flutter web support is pretty decent now. SQLite on the web is probably going to be tricky though (sqflite doesn't support it).
Really cool what you did there! One idea that comes to mind: Would it be possible to implement wake-on-(W)Lan so that the image updating can be triggered by the device that generates the image? Or would that be too battery intense?
Yeah, I found so many cool projects that did not get any atention on Show HN because of hnrss.org. Definetely a feature Hacker News itself should add — they do have RSS for the front page[1], though, with a volume of about 3460 articles per month.
That's a good point. I'm using partial refresh for this reason, which works quite well because the screen is relatively static (I do a full refresh after 4 partial refreshes, to remove the minor ghosting that does occur). But if your dashboard shows a lot of different content you'll have to do full refreshes, which on the Kindle at least also cause a flash.
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.
Might be a nice fit indeed. I considered doing this on my Remarkable 2, but it's a bit tricky to combine a dashboard with actually using the product as it's intended (for note-taking, in this case).
The advantage of using a Kindle like this is that it's cheap enough that I don't have to use it for anything else. I bought the Kindle used for €25.
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.
I considered this as well but didn't really want to mess with the hardware. But if you're up for that you can buy the components yourself, or go for something like inkplate [1] which is an E-paper display + ESP microcontroller and battery in one package.
The Inkplate 10 is being crowdfunded right now for 129$ + shipping.[1] I hope it will be available directly on the website soon as well, as they get shipped from Croatia to the US to be shipped to customers, which would make it unnecessarily expensive to me in Sweden, as I'd have to pay customs duty.
$100? hmm this price may not be that bad though, considering the display seems to be the most expensive aspect and I'm not finding a similar price/size on Amazon.
One thing I want to learn/address personally is a charging circuit so I'd rather build it myself. Still it is nice to know this is out there ready to go.
Also I have to use these ESP01's I bought haha. The code itself I imagine wouldn't be difficult eg. an http get request firing at whatever interval to your own local/remote endpoint. Would have to see about the ESP driver part to display to eInk.
The price definitely seems great for the size of the display, but it might be worth looking at the Waveshare e-paper displays if you want to do something a bit more DIY.
I see this sentiment quite a lot that k8s is too complex for small scale setups, but in my experience it scales down very well to small setups. Granted, you do have to know how to work with k8s, but once you learn that you can apply that knowledge to many different kinds of setups like k0s, bare metal, EKS/AKS etc.
[0] https://k0sproject.io/
[1] https://cert-manager.io/
[2] https://github.com/kubernetes-sigs/external-dns