I made a small pull request (PR) to add integration of the notification system named nfty (https://ntfy.sh/)
It’s a small free pub-sub service (which I use at work). It allows sending notifications directly to a mobile (iOS or Android) and even to a computer.
This is a first version. It can be improved.
The first avenues are:
Install/use a Docker image locally rather than the public service
Install/use a Docker image on the Gladys Plus servers (reserved for Gladys Plus users) for more security.
At the risk of being a killjoy, I’m having a hard time seeing the benefit for Gladys and I don’t feel it’s very aligned with the project’s philosophy?
Technically, for me Gladys is already a Pub/Sub server (both locally and via Gladys Plus), because we already have a bidirectional WebSockets API that already lets you do all that (subscribe to a topic, publish to a topic). It’s a bit of a shame to go through an external service to do something we’ve already implemented locally.
Functionally, I imagine you want to use this service for the « push notification » part; several things bother me about that part:
It’s one-way communication, and it’s redundant with the messaging API we currently have in Gladys, which is bidirectional (Gladys talks to you and you can reply to Gladys). I find it odd to have a second channel, « notification », when we already have a two-way messaging channel.
It’s very geek/dev — basically we’re promoting a tool that’s not very family-friendly.
I think it’s a shame to rely on a third-party service that’s provided free of charge, and about which we know nothing regarding funding or longevity. I imagine the guy is paying for the servers out of his own pocket + the Apple subscription; at some point he’ll get tired of spending every year on this service… For topics like weather, we have no choice but to use APIs (and recent events show that being free is a big problem — we’re dependent on any changes these third parties make), but for notifications this is something that’s very easy to implement ourselves, so it’s a shame to go through a third party… We’re adding a huge dependency for something very simple we can do ourselves.
Sorry, I know I’m playing the killjoy a bit, it’s really not against your PR which seems very high quality like your previous PRs
What do you think?
To use it anyway
That said, if you want to use this service in Gladys, it’s already possible and it’s very simple!
Simpler than Telegram, I think we should also stop assuming that it’s grandma who will throw a fit. Simple for everyone ok but not at the expense of the choice of integrations. Maybe we should add a difficulty level in the docs? A badge or something?
So it’s very geek/dev too
I don’t really understand the argument, it seems to be a super simple and lightweight messaging system.
Yes exactly, since it’s a product that in any case is aimed at tech people and won’t be used by a family audience, I propose this solution rather than making Ntfy the main implementation of push notifications in Gladys.
I see the idea! In that case, if we want push notifications in Gladys, why not, but:
The question of redundancy with the bi-directional message API is central; if we want push notifications in Gladys, then it must serve a different need than the message API otherwise it’s just redundant… If it’s the same thing, it means coding/maintaining the same thing twice.
It needs thinking: storage of push notifications? translations? icons? Who receives a push notification (everyone? only one user?).
I argue for doing it natively; why use an external service for something so « fundamental » in an application. When you use any tech product, it has its own push notifications; it doesn’t go through an external service.
Sorry if I’m asking the painful questions, but it seems important to think about these points, otherwise it quickly becomes the Wild West… It’s never pleasant for me to play the role of someone who opposes many things (even though the subject is exciting, I admit!), but if we want a product that keeps the same philosophy in the long term, it’s necessary, isn’t it?
As long as we’re asking awkward questions, I have one (a bit related)
To find a middle-ground solution, couldn’t we offer an option « add a service » where you’d provide a GitHub link to the service?
Pro
Anyone could develop a slightly geeky service that isn’t intended to be integrated into Gladys for the average user
It would make it easier to test new services in beta (for example), to reach more testers
Cons
It’s clearly against the philosophy of this v4, since some services wouldn’t be integrated by default in Gladys
We could quickly have users posting on the forum complaining about bugs or errors related to services not provided by Gladys + all the associated fallout
That’s what I liked about v3 but it would be a big step backwards for @pierre-gilles
And I think he doesn’t want to move closer to a tech product but rather toward a more user-friendly product
What I was suggesting wasn’t exactly a step backwards, because the goal is to have everything integrated into Gladys.
But indeed, having the ability to add from the UI services that aren’t integrated by default does kind of give off that vibe
Personally, I don’t use Telegram. I already have plenty of other instant messaging apps. I never understood the idea of « talking » by writing to gladys (and I can’t at all sell it to my family). We all use the mobile app to perform actions or via Google Home.
We agree Ntfy isn’t sexy at all but it’s a great tool for sending notifications (At my company we have a saying: if it’s already coded, it’s time saved.)
What I wanted was notifications on my phone when, for example, the door or the shutters open during hours when nobody should be at home or when a light has been on for too long.
For me I saw things differently. Messaging was a way to interact with gladys, to make it perform actions, … Whereas a notification system was there to warn, but it’s true that the messaging system can do both, though I find that counterintuitive.
That’s why I went with an external system. Storage is handled by ntfy. I hadn’t really considered translation. I don’t really get the icons. For reception, like a standard pub/sub if you’re subscribed you receive, otherwise you receive nothing
Well, why not. But that would mean changes in the apps (iOS, Android and web). I’m up for it if needed. As for tech products, I don’t agree with you. Push notification systems are nothing new, and personally in my company we only use external services to do it — it’s cheaper and more efficient to maintain.
I completely agree with you. We must ask the questions and be aligned with the product vision. I tend to jump in very quickly — it’s my strength and my weakness.
That’s really another topic I think it’s a shame to talk about that directly here; it’s a bit the easy way out when we could very well find a compromise that would allow integrating this service into Gladys.
It’s normal that there are debates, I purposely re-challenge certain developments so we ask the right questions. Don’t see it as a « confrontation » or something negative; I do this every day of the week, at Gladys or at work. Nothing personal with anyone
Ok interesting! So you are putting Telegram in competition with your other communication apps, and not with Ntfy.
I understand your use case better. In fact what you describe the whole community already does on Telegram haha
Just watch the video « Gladys Assistant at your home » with @lmilcent; he sets Telegram alerts for each action to follow what happens in the scenes (This video)
Would it bother you for this development to test Telegram in Gladys so that you understand the dual use I’m talking about? (Also you’ll see Telegram’s UX is crazy, WhatsApp by comparison is horrible to use; I think Telegram is one of the products with the best UX that I know)
So now that I understand the use case better, if you use Ntfy like we use Telegram, why not use the same mechanism in Gladys, that is the scene action « send a message »?
That way everything is already handled (persistence, etc..), and we just add the Ntfy layer as the message sending layer? Admittedly it’s not bi-directional, but well that’s how it is if it’s truly an app you like… ^^
So we’d have a configuration interface for Ntfy, where the user would enter the Ntfy topic where they want to send notifications, and then in a scene they’d use the standard « send a message » action
Would that do the job for you? Knowing that the topic would then be fixed per user.
Just one detail though: does Ntfy support images? Because Gladys sends camera images by message ^^
If we go with the solution « Ntfy = Telegram », no need then.
Actually what shocked me in the code of your PR is that you created a native notification API in Gladys, separate from messaging, and that is based exclusively on Ntfy.
Except that after talking with you, I realize that’s not what you ultimately want; you just wanted to have the same usage that the community currently does with Telegram!
Setting up Telegram is far from simple (with the whole bot thing and the API key) and personally Telegram wouldn’t be useful to me except for Gladys, especially since if I want to « chat » with Gladys there’s the integrated chat, so I never installed and configured Telegram out of laziness at having yet another app to manage a feature that should be native to this kind of system.
At the moment the Telegram integration is completely unnecessary for me.
So the Ntfy integration is a much lighter option (and much easier to sell to family members) even though I agree, it would have been better if it were native and we avoided going through a third-party service.
Again I don’t agree with that assumption. In the end we’re diverting the use of Telegram, we end up installing/configuring a messaging app just to get notifications every now and then. (And we’re still going through a third-party service)
