Pinging the router would indeed be easier if you have access to public IP (static or dhcp with DDNS). Going the Pi route with WireGuard or another means of “checking in” would be the next best thing.
My comment RE the tunnelling likely doesn’t apply to your situation - was just context that using a Pi would open avenues to other things if you later needed them.
If you have a pi there, why not just just zero tier to that pi and monitor it's zero tier IP? You can do a very basic keep alive check with any monitoring system that can ping and then alert trough whatever script that monitoring system can call.
Or just have an old android phone running macrodoid and keeping that connected to usb power all the time.
If phone is no longer connected to power, send a text, call a number, write an email etc. You will need a sim card though. But one with very limited data can be had for very little money.
Simple solution would be a RPI or router that connects back to your home with wireguard/openvpn so you have a device that you can ping
Alternatively - if your hosting a public webpage - have a cronsctipt run every 2mins that curl PUSH's to your webpage as a check-in mechinisum. After 6mins - no checkin assume its offline?
We do something like this at scale (about 80k devices) and use a combination or reverse tunnel's and push notifications. These probes allow tunneling backwards (when enabled) and also do some other local device monitoring. All running on RPI type devices with local wan or 4g
edit: assuming your internet route has a public ip (not behind nat) you could whitelist your own IP and allow it to be pingable? That ofc depends on:
a) having a router that supports that level of custimization
b) having a public ip
Simple solution would be a RPI or router that connects back to your home with wireguard/openvpn so you have a device that you can ping
Thanks for your reply, this was my initial idea but then I thought it'd be a lot less moving parts to ping the router wan itself. However I realize if the router loses power that i.p could very well get served to someone else and then I'd just be pinging them instead lol.
Probably will end up doing this. In this case I would ping the wireguard i.p. of the device from another wireguard enabled device, correct?
These probes allow tunneling backwards (when enabled) and also do some other local device monitoring. All running on RPI type devices with local wan or 4g
Not sure what you mean exactly by tunneling backwards, could you elaborate?
Thanks again!