Most active commenters
  • inanutshellus(4)
  • trashcan(3)

←back to thread

MomBoard: E-ink display for a parent with amnesia

(jan.miksovsky.com)
2093 points pabs3 | 18 comments | 14 Nov 24 12:20 UTC | HN request time: 1.837s | source | bottom
Show context
angrygoat ◴[14 Nov 24 12:36 UTC] No.42135621[source]▶
What a beautiful use of technology to uphold someone's personhood, and let them know they are loved, despite (and with regard to) a profound injury.

This reminds me of a desire I've had for a long time: a simple, wall-mountable eInk device that could be configured with a URL (+wifi creds) and render a markdown file, refreshing once every hour or so. It would be so useful for so many applications – I'm a parish priest and so I could use it to let people know what events are on, if a service is cancelled, the current prayer list, ... the applications would be endless. I'd definitely pay a couple of hundred dollars per device for a solid version of such a thing, if it could be mounted and then recharged every month or two.

replies(11): >>42135791 #>>42135902 #>>42136090 #>>42136946 #>>42137028 #>>42137259 #>>42138858 #>>42138987 #>>42139034 #>>42144836 #>>42145380 #
1. inanutshellus ◴[14 Nov 24 17:58 UTC] No.42139034[source]▶
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.

replies(4): >>42141558 #>>42150269 #>>42150336 #>>42153168 #
2. trashcan ◴[14 Nov 24 21:44 UTC] No.42141558[source]▶
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.
replies(4): >>42141824 #>>42145119 #>>42145521 #>>42150315 #
3. Nition ◴[14 Nov 24 22:20 UTC] No.42141824[source]▶
I tried to do pretty much this on a Kobo reader and discovered the Kobo browser doesn't support javascript. :|
replies(2): >>42144446 #>>42145231 #
4. oarsinsync ◴[15 Nov 24 06:44 UTC] No.42144446{3}[source]▶
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.

replies(1): >>42147911 #
5. Cthulhu_ ◴[15 Nov 24 09:02 UTC] No.42145119[source]▶
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.
replies(2): >>42147640 #>>42152846 #
6. forgotacc240419 ◴[15 Nov 24 09:24 UTC] No.42145231{3}[source]▶
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
7. chokma ◴[15 Nov 24 10:16 UTC] No.42145521[source]▶
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.

8. GTP ◴[15 Nov 24 15:16 UTC] No.42147640{3}[source]▶
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.
9. inanutshellus ◴[15 Nov 24 15:46 UTC] No.42147911{4}[source]▶
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.

replies(1): >>42153734 #
10. ◴[15 Nov 24 19:54 UTC] No.42150269[source]▶
11. xp84 ◴[15 Nov 24 20:00 UTC] No.42150315[source]▶
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.

replies(1): >>42150350 #
12. speerer ◴[15 Nov 24 20:02 UTC] No.42150336[source]▶
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

replies(1): >>42172898 #
13. trashcan ◴[15 Nov 24 20:03 UTC] No.42150350{3}[source]▶
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.

14. trashcan ◴[16 Nov 24 00:10 UTC] No.42152846{3}[source]▶
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.

15. michaelsalim ◴[16 Nov 24 00:56 UTC] No.42153168[source]▶
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

16. Nition ◴[16 Nov 24 02:55 UTC] No.42153734{5}[source]▶
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).
replies(1): >>42172872 #
17. inanutshellus ◴[18 Nov 24 14:58 UTC] No.42172872{6}[source]▶
Luckily the original solution doesn't involve javascript...
18. inanutshellus ◴[18 Nov 24 15:01 UTC] No.42172898[source]▶
Heyyy I'm internet famous! :blush: Thanks for mentioning me, hope it works well for you.