I’ve got a home server set up that could listen for requests on the LAN. After a listener in a program receives a piece of data sent from SGP (to a specific IP/port/domain), the program could then evaluate how to handle the data. A program like this would have to be user-written, but it could potentially play a sound to wake you up, activate floodlights outside, or pretty much anything else that can be controlled by your computer.
Actually sending the data to the arbitrary endpoint is a really simple task that can be accomplished by using some library. For the user input, they could either type an actual URL or just specify the IP/domain and port. This would allow users to send data to something like http://192.168.1.45:8000/sgp/notifications or even just http://mydomain.com/sgp/notifications
Just make a post request to that address and have the payload be some JSON data that has details about the notification. Constructing a JSON object like that shouldn’t be difficult at all.
I think adding a feature like this could only take a small amount of time to get it running and it would provide a great bit of flexibility to the notification system.
Just thought I’d add that this would be a main selling point for me. Really it’s the only think stopping me from buying a license along with the notification system.
If something like this could be implemented, it would be wonderful. It’d give a whole extra layer of flexibility. I don’t like the GNS system - it’s never worked well for me, and getting a ton of emails isn’t my idea of a good notification system. Especially when I have do not disturb enabled. If I turn it off, I’ll get every ding from emails including those I don’t want to be woken up by.
I suggest a simple interface where the user can enter the endpoint and the JSON payload for an event. I use pushover.net and it works very well for my other notifications I have setup that are not astro related. You can also select the alertness level to require your interaction if a severe error occurs. It uses an POST request to an https endpoint and JSON.
Yeah I definitely agree with the GNS thing. Something like a little “bleep” email notification won’t wake me up if something is going wrong, so I want to be able to write a program that listens and handles notifications based on their contents and then plays loud music to wake me up or something like that. There is already data being posted when things go wrong, so implementing something like this shouldn’t be hard. Just need a way to serialize the error data and then post it to the user’s endpoint, which is pretty trivial with .NET
This would be useful if I were awake and had my phone nearby, but my phone only allows for me to select a short ring (like a single ding) and it won’t work when I have my Do Not Disturb on, which I do when I sleep so I don’t get notifications for stuff that isn’t urgent. The real flexibility and functionality I’m looking for can only really be provided by a custom-written program that is able to do whatever I want it to do. That’s why I suggested having SGP post some error messages in JSON to anywhere the user wants so they can do whatever they want with it.
I seem to recall you saying something about expanding the API? If that’s something you’re doing, then maybe a request for recent errors or other issues would be useful. I still think it’s better to post the error data to some place though; that sounds easier to do because you just post the data and that’s all SGP does. It doesn’t have to manage remembering errors for a certain period of time or anything like that. Instead of posting data to GNS, it posts data to the user’s endpoint.
Yes, that’s true but I found that there was a few minutes delay before getting notified this way. If guiding goes south, I want to know about it right away. GNS is at least faster although it seems to have it’s own issues.
Another option would be to open up the status as a JSON reply to a query to the machine that’s running SGP. This wouldn’t be a true push notification, but a watcher program could poll SGP every 30s or so for status including what progress the sequence has and any errors/warnings. The polling program (third party) could then parse the status to whatever endpoint it wants.