How to access to .cfg defined vars?

Add-ons Other
, ,
#1

Hello,

I start with NMA and face a problem :

  • I would like to raise notifications from a lot of different places (rules, scripts…) with different priority levels
  • I willl eventually have several API keys

As there is no notifyMyAndroid method signature with priority level without API key, how can I :

  • Access to the one defined in nma.cfg?
  • Define other APIs keys elsewhere and access them from multiple places ?

Thanks for your replies !

#2

The doc appears to be incomplete! I count six method signatures for this action service. Would you consider fixing the documentation?

#3

Hello,
Thanks for pointing me the nma source file. PR on its way !

Furthermore, would you have an idea about my second question (global variables across openhab)?

Thank you again !

#4

I am not aware of an elegant solution for this in the context of openHAB, but I think adding such a thing would be great. A kind of “credentials wallet service” that any add-on code could read and write from, that lives on disk in encrypted form and could be unlocked at runtime. In the meantime, you would have to write your own in either the rule/script language, or in Java (where the classes are somewhere in the classpath or an OSGi bundle/service you create, bundle:install and bundle:start).

#5

Thank you. I’ll keep that in mind as an potentiel roadmap if I decide to go further.

1 Like
#6

I like @watou’s idea best of all. In the mean time I centralize all such activities into one place using the Separation of Behaviors Design Pattern.

The tl;dr is create an Item which you send a command to. This Item triggers a rule to do the action. So in this case I would have a Notification String Item and I’d sendCommand(Message) and centralize all my NMA triggers in the one rule that gets triggered by the Notification action.

This is a great way to centralize notification and alerting logic so you don’t have to spread API logic all over the place and it makes it easy to swap your alerting out if you decide to use other services. It also lets you set up logic so at certain time of day you can alert in one way and use an alternative at other times of day (e.g. use NMA during the day but sendMail at night).

#7

Thank you very much for sharing you approach, design patterns to use in order to provide scalability and maintainability was one of my next TODOs… here is a very good start.

Furthermore, as far NMA is concerned, in my case there will be more than one API key : your architecture principle let me define as much API keys as I need and use them in a centralized place.

Thanks again !

Nicolas

#8

@rlkoshak’s ideas about improving notifications from rules are spot on. Another approach along the same lines is to use mqttwarn for all notifications: just publish a message to a topic on an MQTT broker, and mqttwarn is configured to dispatch to the correct notification system.

1 Like