Dynamic Target List

[ImagineZA]

Hi,

I'm looking to try and create some sort of Dynamic Target List, where the target can almost be changed on the fly.

To explain it a bit better:
I'm pushing alerts to Telegram, and I can get that going fine with the default configs, however I have a user database, in the case of testing I am using a text file, where the Chat IDs are stored, I'm looking to have the IDs collected and then used as targets for the push alerts, this text file can be changed at any time as users decide to subscribe or unsubscribe from push alerts, so it can't be a static load on the config:telegram as I would need to stop the service and add/remove the user each time, anyone fiddled around with something like this?

[jpmens]

This seems as though it might be possible with a lot of fiddling with custom functions, but what you describe sounds to me to be easier to implement with a custom program which uses a simple data store (Redis, SQLite, ..).

From what you write, I don't see how mqttwarn is of benefit.

[ImagineZA]

How would I get the config:telegram to load the targets dynamically though?

[jpmens]

You wouldn't use mqttwarn at all but instead incorporate what the telegram service does into your code. Might be more effort than you're willing to invest, though.

[ImagineZA]

Hmmm, possibly.
What about a method of loading the targets from a file on startup?

[amotl]

Dear @ImagineZA,

your request is very much appreciated. The feature for being able to use "dynamic topic targets" was one of the first contributions @einsiedlerkrebs and I have been able to bring to mqttwarn the other day, got implemented through #162, #169 and #170 and has been documented at Incorporate topic names into topic targets.

While @jpmens is right that this could be achieved by writing a custom program, we nevertheless have been very eager on bringing those features to mqttwarn the other day and were reasonably satisfied with the outcome after quite some investment on our side. In fact, mqttwarn already provides lots of the baseline infrastructure needed for such a program and it would have been a bummer for us if we wouldn't have been able to add those improvements to the code base. Actually, that was part of our journey where we got involved into the code base that much that we have been able to spend some additional cycles on modernizing and modularizing it on behalf of a31548b and 745174f a while ago.

Now, the last remaining bit is how to tell mqttwarn to reload its configuration at runtime, if that is actually what you are looking into. If you are fine with sending it a systemctrl restart mqttwarn signal, we would be done. However, that is not really "runtime configuration".

On the other hand, from your initial post, you are also looking at having an out-of-band configuration file describing the part where the dynamic topic targets will get resolved from.

Those two additional options might well be considered if @jpmens doesn't have any general objections. How both of them will eventually overlap and how they may be implemented might be part of the discussion we are having here.

So, to summarize it:

• Dynamic topic targets are possible right now.
• When the lookup table at the targets attribute within the service's configuration section (let's call it "addressbook"?) can be manipulated within the main mqttwarn.ini, a simple restart of the service is sufficient to activate the new configuration. That detail might be improved by sending a special signal at runtime by means of a more highlevel mechanism like a message to a specific /admin/reload MQTT topic.
• In order to be able to load the addressbook from a different file, we might think about adding an appropriate feature to mqttwarn's configuration syntax.

Let me know what you think about it.

With kind regards,
Andreas.

[amotl]

In order to be able to load the addressbook from a different file, we might think about adding an appropriate feature to mqttwarn's configuration syntax.

We would not even have to implement it into mqttwarn itself. According to the documentation about custom functions:

A topic section in the INI file can have properties set as per the table at the bottom of this section. The targets, topic and qos properties can not be defined with a function.

When we would be able to extend the list of configuration properties to be defined by custom functions to also include the targets property, we would be all set. By doing it that way, one will be able to load custom addressbooks in whatever format through a custom function and will also be able to implement refresh policies however it would be appropriate for their specific use case.

The devil is in the details, though. So, while such a plan is easily written down in prose, we will have to check whether it will be feasible to implement based on the current architecture of mqttwarn.