It's not clear to me how to actually get the required plist file to make this library work. Neither of the scripts in this issue seem to work: https://github.com/malmeloo/FindMy.py/issues/31
Is the syntax to run them just `swift <filename.swift>`?
Swift/ErrorType.swift:253: Fatal error: Error raised at top level: main.MyError.noPassword
Which version of MacOS are you using? I believe Apple has made changes to the keychain in the latest version which prevents the scripts from working properly.
The only Apple "device" I have regular access to is a hackintosh, so this stuff is frustratingly hard to debug. So far I've been relying on efforts from the community, but the scripts appear to be somewhat flaky and don't always work for everyone unfortunately.
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.
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.
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).
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
They also refuse to do installs in new builds in many neighborhoods. I have lived sandwiched between two addresses that have Google Fiber, and they have refused to come out to install the last 25 feet of cable to my house for 5 years. So I'm paying $100/mo for crappy Spectrum internet that goes down all the time.
I've reached out to them several times to come out or do a survey, or run the existing fiber through already existing conduit and they just refuse.
Also, sometimes logs stretch across multiple lines, and the other lines won't have the identifier you are searching for. For example, Java stack traces. In that case if you are stuck parsing unstructured logs, the simplest thing to do is to look at the entire file and search for the timestamp that found the first line.
This is not being done by ERCOT that manages power distribution in Texas. Your friend had a local power failure, probably caused by a downed power line.
In my house at least I have a UV light in my central HVAC that is supposed to be replaced every five years. Maybe it is different for commercial buildings, but commercial buildings also tend to have professional maintenance.
