I was hoping a “custom TCP endpoint” option can be added to the notification add-on that would just post a JSON object to whatever address/port is specified. Obviously this requires a port listening on the other end, which is something I’d write. (My initial thought is to post notifications to an Azure Mobile Services running node.)
Thanks for the feedback. To be perfectly honest this probably won’t happen though. SGPro is not a product for other software developers so, in terms of the list of things we have to do, this would be pretty low in priority.
I don’t mean this offensively, so please don’t take it that way. But, GNS, PHD2, your own SGP API, depend on software being able to interact. The difference here is that it’s a product not developed yet. Maybe I write a cool node.js backend that could either be given away, open sourced, or turned into a service like enabling other notifications methods like phone calls, send multiple alerts, etc. Or maybe a console app that does something else other than send an email or notify GNS. This allows the next GNS (I don’t know how GNS works, maybe I could shim in a listener that pretends to be GNS?)
Of course it’s your product, but just seems like a notification add-on has limited value if you don’t use GNS. Heck, send me the skeleton code for the email module of the notification system and I’ll give you an HTTP sender by the end of the day. I know there’s more to it, just sayin’.
I did not mean to imply that I thought your suggestion was a bad idea, merely that we have a list of features we prioritize by how useful we believe them to be to the entirety of our user base. I think the idea is actually pretty cool. It just means it steals time from something else is all.
That said, if we were to approach something like this, I think I would keep it away from the notifications endpoints dialog. I think that should remain user centric ans fairly simple to use. It seems to me that we could accomplish this in the same way that PHD2 does. You wouldn’t need to add an endpoint for notifications, you would just subscribe to them via SGPro existing API. That way engineers can get what they need and we can keep the super confusing stuff out of the UI. Do you think that would be sufficient?
No guarantees, but we will keep this in the feature request queue.
I see your point and agree, the existing API would be a good place for that. I guess I was thinking from a simplicity point of view, it would be easy to implement copying from the current email endpoint, but can understand the hesitancy.
Still, it’s kind of hard in this hobby to drift too far from scripting / dev-like features – looking at the GNS manual there’s a ton of scripting points for the various systems, ACP, CCD Commander, SGP all have script and occasionally endpoint options. Actually, GNS scripting could offer a way to send notifications to an endpoint…
As a side note, I like in theory how Nest (thermostat) has done its API with Firebase, but found the connection and callbacks often don’t work well for long running and background apps where occasional disconnects might happen.
just found this topic while I was myself going to post a feature request, and it’s pretty close to what I’d like to be able to use… Just started to use SGP at my very new observatory, which is remote (and very far from my home). And I was looking for a way to collect notifications and to get them in different ways (what’s app, messenger, sms, etc).
This is exactly what could help me achieving this integration. Are there any news about this possibility ?
Just also wonder if there was something like a “notification” standard interface in ASCOM, would it help to get that kind of feature ? Different implementations of this interface could lead, for exemple to use GNS, email, etc…