Hacker News Reader

Comment by inanutshellus | Hacker News Reader

assuming your eink display would be on the same LAN as some always-on PC...

  1. install python
  2. make a file named `index.html` somewhere. 
  2a. put this in the "head" tag, so it'll refresh hourly: `<meta http-equiv="refresh" content="3600">`.
  3. run `python -m http.server` from the same folder
     This will start a single-threaded web server on 8000
  4. On another machine on your network verify you can pull up http://firstmachine:8000/. 
  5. having proven it works, go buy an e-ink display and point it to http://firstmachine:8000/, make it the default homepage.

Voila.

Any time you have anything to say, just edit the `index.html` file and the eink display will update.

No need for fancy subscription services or kickstarter projects or crowdfunding... just... batteries included python.

View on HN

Thanks for the inspiration. I did essentially this as a project with the kids today, though I used js to allow updating by anyone in the family.

https://github.com/TrisSherliker/FridgeChalkboard/tree/main

Heyyy I'm internet famous! :blush: Thanks for mentioning me, hope it works well for you.

I'm developing something so that everyone can do this easily[0]. It's a plugin based presentation software. Real time connection through websocket.

So all you need to do is create a project and use a plugin(existing or your own) to generate your view. The plugin is flexible, so it could be a custom UI or uploading a HTML file for example.

Then, you can open a link on any machine like the e-ink display.

Open-source and self-hostable. But you can also use the online version I'm hosting.

It's still very new so things will break but I'm already using it in church and other meetings.

[0] https://theopenpresenter.com

Having done this, you will also most likely want to setup a javascript timer that also triggers a refresh in case the meta refresh fails. And a weekly reboot of the machine in case there is a memory leak or some other issue.

The primary issue I would imagine, would be not that a meta refresh fails to happen, rather, that any type of full refresh is attempted during a momentary 'blip' of the local network, leaving it showing a "cannot find server" type of error. To achieve the safest persistence of the refresh loop, it would probably make more sense to have the refresh function via

1. AJAX request for itself, with a timed retry in the case of any failure (optional: During this time, add a visible indicator that you're having connectivity issue) 2. Extract the contents of the <body> tag of the fetched HTML 3. Set the innerHTML of the <body> tag of the DOM to the fetched body.

To avoid memory leaks I'd still be tempted to also try to implement a "safe-ish refresh" that checks for a successful response and quickly fires off a location.reload() on like a daily basis.

Yep, exactly r:refreshing failing. If you are using a full featured browser you can also use a browser extension that forces the refresh.

Additionally for a raspberry pi, you can use a watchdog timer service that checks to see if the rpi has frozen, and reboots it.

That sounds like defensive programming; what makes you think meta refresh will not trigger always? If you can demonstrate it, it'd be worth filing a bug report with the respective browser(s). Same with the reboot, although the user does not control every software in the e-reader. That said, e-readers and tablets are designed to be always-on, so memory leaks should be rare nowadays.

I have setup a raspberry PI dashboard before and run into these exact issues. They are not defensive or pre-emptive. An e-reader will probably not have the same issues, just sharing my experience.

* Browser runs out of memory or has other issue and stops refreshing.

* Wifi connection drops and browser displays an error page and stops executing your refreshes. The power-saving options on the RPIs wifi caused me quite a bit of grief before I disabled them.

* Raspberry Pi crashes with kernel errors due to cheap SD card, underpowered USB power supply, or something else.

I ran into these issues one by one over a few months and fixed each one as I ran into it. What I ended up with was:

* Browser set to run at OS startup displaying my page.

* That page having a meta refresh tag, and javascript code to reload the page periodically.

* A browser extension to automatically reload the page as well if both of those failed.

* A watchdog daemon that detects when the RPI has frozen and reboots it.

* A cron job that reboots periodically.

With all of those my dashboard would run for months without any issues or interruptions. Just sharing so others can be aware of potential issues.

There's nothing wrong with defensive programming, especially if it is supposed to run on a device where you don't have easy and/or immidiate access in case something stops working.

We had to configure a daily reboot for a raspberry PI that just displayed a web page with the current status of emergency calls for local first responders on a mounted TV screen.

Purpose: if you come into the building to fetch the car with the medical equipment, you could see at a glance how many people acknowledged the alert and would arrive shortly etc. Sadly, the system tended to loose its WIFI connection and then the reloaded web page would display a network error. And since the web page was a 3rd party product, we could not hack the Javascript.

I tried to do pretty much this on a Kobo reader and discovered the Kobo browser doesn't support javascript. :|

It sounds like there’s a lot more edge case complexity to this than the GP originally thought.

Like most DIY tinkerer solutions, unfortunately, which is why people like paying money for productised solutions - the time it takes to debug and troubleshoot home made solutions is often prohibitive for a lot of people who aren’t techheads.

This is both fair and obvious... but at the same time, the nits folk are bringing up are not fleshed out.

  "I had to reboot my raspberry pi"

and

  "whoops rando eInk display doesn't do javascript"

are both super weird and frankly unfair to consider as criticisms of the original solution.

... In short - if our parish priest above sees the original post, I'd suggest he give it a go. It's an hour to set up and won't cost him or his parish anything (aside from buying the eink display ofc).

If it turns out that the DIY solution is insufficient, or his parish is wealthy enough to spend money on a thing like this, great, then upgrade to that.

Kobo readers are fairly non-rando, they're the second most popular eInk readers after the Kindle I think. I agree that lack of Javascript support is not a blocking issue on the use case though (although it does make it a little more annoying).

Luckily the original solution doesn't involve javascript...

Would an old rooted Nook Simple Touch suffice for your use case? They're very cheap these days and you've direct access to some early version of Android on them

Reply on news.ycombinator.com