Allow Selected MQTT topics to trigger local (iPhone) Notifications

[camphamp]

I would like to have urgent notifications sent to myself via my iPhone Notifications using MQTT topic subscriptions.

I use Node-Red and ESP32 devices, but there are many possible MQTT sources for others.

Structurally, you would need to allow for background fetching (perhaps this is just a user-defined setting) and have the app request notification permission from the user.

The UI could be a check box to enable notifications and the snooze time in hrs : minutes between repeat notifications (when it is a duplicated message within a topic). For example, the topic: alerts/freeze and message: "Basement is below freezing!" could be sent every 10 seconds but the user should be able to quiet iPhone notifications to a desired frequency, like every 6 hours.

Let me know if I can help test or answer/research any questions. Thanks!

[philipparndt]

Hi @camphamp,

I don't think this is the right architecture for doing push messages. For reliable urgent notifications you will always need a server component that uses the Apple Push Notifications Service (https://developer.apple.com/notifications/).

A good architecture would be:

• iOS app to register the notification channel
• Microservice that listens to MQTT messages (maybe on a "notification" topic) and sends push notifications

I see only two ways how this can be done:

• lot of effort necessary together with some costs for developer certificates for each user
• providing this as a service which would cost maintenance time, hosting costs and carful security considerations.

[camphamp]

Hi Philip. Thanks for the quick response to this proposal. I understand that a central service design would offer a more reliable solution (with HA and DR) for delivering iPhone notifications. A central service is also a better design for reliably receiving MQTT messages than an iPhone client, too, but that didn't stop you! : ) I would ask you to consider, (1) how hard would it be to extend your app in this way?, (2) is there any value in users being able to tick a box next to topics of interest that they would want to be notified using your app's native notification options? and (3) what other tweaks might be required (like filtering based on frequency, maybe content matching, perhaps an email channel)? Your app currently requires quite a bit of navigation to find content. I expect the best client solutions will allow for widgets/reporting screens to view and publish data as well as this type of notification/filtering. That is just my hunch. Thanks for listening. Wishing you good luck with this project! P.S. My work-around: Email desired messages to an address that converts to my SMS inbox (e.g. an email to ***@***.*** will come to my Message app and give a notification). It requires a protocol conversion/gateway, but offers reliability due to industrial system design and message queuing through the chain. On Sunday, November 19, 2023 at 10:43:54 AM EST, Philipp Arndt ***@***.***> wrote: Hi @camphamp, I don't think this is the right architecture for doing push messages. For reliable urgent notifications you will always need a server component that uses the Apple Push Notifications Service (https://developer.apple.com/notifications/). A good architecture would be: - iOS app to register the notification channel - Microservice that listens to MQTT messages (maybe on a "notification" topic) and sends push notifications I see only two ways how this can be done: - lot of effort necessary together with some costs for developer certificates for each user - providing this as a service which would cost maintenance time, hosting costs and carful security considerations. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>