Gradually turn on lights.

[Alan_F]

I am running Gotify in a Docker container on my RPi4 and using the Gotify Android app for self-hosted notifications.

I can send notifications from MSR using an http POST, but I'd like to be able to use the Notify action in MSR as it would be cleaner. I looked at the notifications.yaml file but I don't understand enough to know if it's possible to set up Gotify there or if it requires integration to MSR first.

To notify using Gotify, I send a http POST with a header of "Content-Type: application/json"

The request URL is: http://GotifyIP:port/message?token=TokEnStRinGfRomGoTiFy

The request body is:
{ "title":"Alert Title Here", "message": "Message Here", "priority": priority_integer }

(valid priorities are 0 to 9)

So the variables for Gotify are:
Server IP:port
Token
Title
Message
Priority

Is it possible to set this up through the Notify action via notifications.yaml?

[toggledbits]

Since that's not an officially-supported notifier, you'd have to use an HTTP Request action. If you'd like to write the Notify subclass as a third-party plugin, I can help you do that, if you're pretty fluent in JavaScript.

[Alan_F]

I'm not sure that I qualify as 'pretty fluent' in JavaScript. I use a little of it in Node-Red functions, but I often have to search for examples and use them as a template rather than being able to write JavaScript from a blank sheet. I'm willing to give it a shot if pointing me in the right direction won't use up too much of your time.

[therealdb]

@toggledbits said in Is it possible to send notification via Gotify from "Notify" action?:

can help you do that, if you're pretty fluent in JavaScript.

I'm interested, for my own notification subsystem, running via HTTP/MQTT.

To be honest, I'll probably write a very generic system, to programmatically call a configurable endpoint, specified in the configuration. Something like (pseudo-config):

- Url: http://localhost:5000/notification/toast
- Method: GET
- Params:
  - text
  - silent
  - chatid

and just substitute them in the notify action, as you'll already doing - I guess - with the different notification systems.

[toggledbits]

Yeah, that seems an obvious alternative to doing subclass after subclass for a bunch of less-used methods that run on web endpoints. The big issue is always doing an adequate job of the UI, which may not be an issue you have, but it reliably ends up being a large percentage of my time on almost everything. The config and the entire handling are complicated a bit more by simple things like "priority", where there's now a type to be honored in the payload JSON (POST body), and a range of numeric values that correspond to some human/text form (low, medium, high, junk, urgent, etc.). These are details that end up soaking time, and while the Engine's notification class already has a way of managing and exchanging this data with the UI, that format is not meant for end-user configuration/entry.

[therealdb]

@toggledbits yeah, accounting the different kind of styles is hard, but I think this is a specific use case for advanced scenarios, so I’ll trade it for a less advanced ui.