Notifications

[twojciac]

First let me start by thanking everyone involved in this project, it has been great to be able to resurrect my feeder after having numerous problems. Recently I have experienced a few jams and was unaware there was a problem until looking at the log on the server. It would be nice if there was some way of getting notified. I'm a Python novice, so I wasn't quite sure where to start in looking at the code.

I assume there are two options in adding this functionality and I'd be glad to help if nudged in the right direction and if the developers would accept sloppy novice code. The first option would be to directly integrate notification support using a library such as notifiers which supports a plethora of services like Pushbullet and Pushover. The second option would be to leverage the MQTT message bus and have something else like mqttwarn or Homeassistant trigger notifications based upon specific messages on the bus. The issue I saw with the second option is that the MQTT credentials change each time the docker is restarted.

What is the best way to provide notifications?

[mbillow]

Hey there! Glad to see that Feedernet has been useful for you! 😄

I think there are actually two feature requests here, correct me if I am wrong:

1. Surfacing logs/errors in the front end.
2. Notifications for critical errors and feeder events.

The former shouldn't be all that difficult. At a minimum we could just add a FileStream logging handler set to logging.WARNING and then tail that in the front-end. We could also write logging.WARNING and above events to the database which would give us more opportunity to make it pretty/aggregate-able for the user.

The latter is what we started discussing in #62. I actually proposed using Notifiers and wrapping it with some kind of event handler that we could trigger based on MQTT events. We were definitely thinking in the same direction. 😛 It is also possible that this custom log handler I talked about above could send events to the event handler as well.

Personally, I see us adding a new model that looks something like:

• NotificationProvider
  • Stores and configuration necessary to initialize a notifiers provider. (We may just want to pickle a valid configurations object, since each provider requires different parameters.)
  • Fields:
    • ProviderId: INTEGER (AUTOINCREMENT)
    • FriendlyName: TEXT - "Marc's Pushbullet Account"
    • ProviderName: TEXT - "pushbullet"
    • ProviderConfiguration: BLOB -
    • LoggingLevel: INTEGER - Minimum log level to trigger event.

We could pretty easily add API endpoint for things like: GET /notifications/providers/available to return the list of available providers, GET /notifications/providers to list the configured providers, POST /notifications/providers to create a provider configuration, GET /notifications/providers/{id} to view a providers configuration, PUT /notifications/providers/{id} to update a provider, and POST /notifications/providers/{id/}test to allow users to send a test message.

The frontend will need to handle the logic of retrieving what fields are necessary for a provider from GET /notifications/providers/available to render the correct form fields.