Obviously the trigger would fire too soon - as the Pi and (even more so) the webserver would still be coming up. So I want to build in a delay before the trigger posts the URL in the background. Say, 5 minutes.
Any thoughts on how to do this?
An alternative would be if Pushcut had a customisable timeout value. I’d set it to 15 seconds, if I could.
Thanks for these. I’m sure you realise these aren’t great workarounds…
The first one doesn’t look like a background task to me. It would need intervention.
The second one sort of defeats the point: Sometimes all I have is the phone and sometimes I have just the phone and the Pi. A third machine is unlikely to be up when the Pi is down.
It would need confirmation to run the shortcut, and after that it would need to be left to run. But there wasn’t anything I your original post about needing to be a zero touch background task.
I don’t think it does.
You haven’t actually said why the Pi would be down versus another machine also necessarily being down. Some people have machines located in a different room in the house, at a work location, or at a co-lo site. Therefore there is viability there.
I did also suggest the use of a web service on this one. After all, the cloud really just means someone else’s computer.
Let’s take Integromat as an accessible example web service.
This in turn triggers a 5 minute sleep in the scenario. As it happens a longer period would require a different approach, but can be achieved by storing the trigger temporarily, and using a periodic time stamp check to see if a further action needs to be taken.
I’m also wondering how to get a payload into a background request. For example, how to confect a query string on the fly.
If it can’t be done then I don’t need a background request; I just need the “connecting to the Pi” notification to allow me to kick off a shortcut that composes the URL.
And therefore I wouldn’t need the delay capability.
The process is being kicked off by your iBeacon, so what information do you want to pass to the Pi? Is it something you could build from another device/service and just trigger that from the iPhone?
Yes. Worst case. At 35,000 feet. When I want to, for example, work on a programming project. (Actually it would then be an iPad with a nice keyboard and Prompt SSH’ing in.
(And I don’t yet fancy paying for wifi on a plane. Partly because of the cost and partly because I want to disconnect for a few hours.)
In that case, your practically point to point with the device in all likelihood in reach seeing as you would be powering it up.
I’d be tempted to put something directly on the Pi itself as a visual indicator that the web server is up - an e-ink display or even just a single LED wired up to the GPIO would suffice. You could hack a little Python to run in the background and periodically poll your web server on device and give you your indication. An audible alert could also be an option, but my personal preference would be visual as it then has persistence and would be far less likely to disturb fellow passengers on a plane.
After that I’d then manually trigger my initial actions.
Now, if you really do want an iBeacon trigger, then there are some other possibilities.
A similar approach would be to try and manipulate the Bluetooth radios to act as an iBeacon. This might well mean messing around with your Bluetooth stack (which it sounds like you’ve already got configured for your networking and so may be a no go), and figuring out how to default it to off or a different UUID at start-up so that it isn’t instantly triggered once the BT stack is loaded and operation in the OS.
As your Pi can broadcast a WiFi signal it can presumably also broadcast an iBeacon signal. I’d recommend doing that instead of plugging an iBeacon into it, and I think that would solve all your problems?
Just to provide some additional clarity around that, the Raspberry Pi 3 onwards (thus RPI 4 is included) and the Zero W all have chipsets that provide wifi and Bluetooth communication on the same chip. It’s the Bluetooth that’s utilised for iBeacons rather than wifi.
Prior to v3, Bluetooth and WiFi USB dongles were often added to give the functionality, but due to encouraged cheapness, typically separately; leading to powered USB hubs being rather popular amongst early RPI enthusiasts.
just a bit of background on the “add interval in Pushcut for background actions”, because I really thought about adding this for a while. here is why I didn’t:
there is no way in iOS to reliably schedule “background work”. you can ask it to please run you in the background in X seconds, but it just might chose not to. it feels just impossible to explain to users that their stuff might just sometimes not work with no reason or explanation available.
of course I thought about doing this on my backend. but - while I could build a reliable scheduling service for web URLs and online actions - this would only work for “internet” URLs. again, hard to explain why local URLs (like your pi) will NOT work in this specific setting. even when notifying the iOS device via “silent notification”, iOS just will not guarantee running it. ultimately all options I could think of would be flakey and have hard to explain rough edges…
so, for now: either schedule a delayed notification (that is reliable on iOS) or have your own delay service (either online like described above, or your own thing on your local network…)
I think the “set up the Pi as an iBeacon - after eg Apache has started “ method is a good one. So long as it doesn’t stop TCP/IP over BlueTooth. (I doubt it would.)
Now to hunt for instructions on how to set the Pi up as an iBeacon.
I hadn’t recognised it as such. However, your other idea - not turning on the USB port until Apache is up - is probably more doable. (There are 4 USB ports on the Pi and I have stuff plugged into 3 (the other two being receivers for keyboard and mouse). So keeping a fourth spare is enough.)
(By the way the latest Pi seems to have a built in clock. One of the first tests of what I’m trying to do was to update the system clock on the Pi. But it currently appears to have it right already.)
Are you sure? There’s no RTC listed for any RPI and I don’t see an RTC or even a power cell on the hardware specs for RPI 4; though maybe I’ve overlooked it.
Usually the Pi will connect over wifi or ethernet at boot-up to an NTP server and set it’s date & time from that.
It seems to be showing current time. So maybe Raspbian got it from a time server. (I also didn’t see a line item for a RTC - and it’s something I would expect to be flagged.)
