5 ms·

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

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.

trashcan 2y ago
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.
- Nition 2y ago
  I tried to do pretty much this on a Kobo reader and discovered the Kobo browser doesn't support javascript. :|
  - oarsinsync 2y ago
    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.
    - inanutshellus 2y ago
      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.
      - Nition 2y ago
        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).
        inanutshellus 2y ago
        Luckily the original solution doesn't involve javascript...
  - forgotacc240419 2y ago
    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
- Cthulhu_ 2y ago
  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.
  - GTP 2y ago
    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.
  - trashcan 2y ago
    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.
- chokma 2y ago
  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.
- xp84 2y ago
  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.
  - trashcan 2y ago
    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.
deleted 2y ago
[deleted]
speerer 2y ago
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 https://github.com/TrisSherliker/FridgeChalkboard/tree/main
- inanutshellus 2y ago
  Heyyy I'm internet famous! :blush: Thanks for mentioning me, hope it works well for you.
michaelsalim 2y ago
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 https://theopenpresenter.com

trashcan 2y ago

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.

Nition 2y ago
I tried to do pretty much this on a Kobo reader and discovered the Kobo browser doesn't support javascript. :|
- oarsinsync 2y ago
  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.
  - inanutshellus 2y ago
    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.
    - Nition 2y ago
      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).
      - inanutshellus 2y ago
        Luckily the original solution doesn't involve javascript...
- forgotacc240419 2y ago
  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
Cthulhu_ 2y ago
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.
- GTP 2y ago
  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.
- trashcan 2y ago
  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.
chokma 2y ago
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.
xp84 2y ago
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.
- trashcan 2y ago
  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.

deleted 2y ago

[deleted]

speerer 2y ago

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 https://github.com/TrisSherliker/FridgeChalkboard/tree/main

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

michaelsalim 2y ago

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 https://theopenpresenter.com