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.
Additionally for a raspberry pi, you can use a watchdog timer service that checks to see if the rpi has frozen, and reboots it.
* 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.
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.
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.
"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.