Decoupling notification service

Setup, Configuration and Use Scripts & Rules
,
1

Hi all,
I’m quite new to rules in OpenHAB. I implemented my first rules last weekend and this weekend I added some more, including sending of some notifications. Since my wife and I both use Telegram on our phones, I set up a bot and use the Telegram service for that.

However, I can imagine that in a few months I will have a bunch of rules sending notifications, so different rules files will be filled with sendTelegram actions. And who knows, maybe next year we won’t be using Telegram anymore so I’d want to switch to another notification service. I’d like to avoid having to replace all sendTelegram calls in all files with something else.

What is the best way to decouple the notification service in my rules? I was thinking about defining a string item, posting updates to it whenever I need to send a notification, and creating a single rule that calls the notification service when the item state has changed.
Is this the way to go? Anyone doing it like this already? Could it be useful to create multiple notification items for various purposes?

Thanks for thinking with me!

2

Maybe look at pushing alerts through mqttwarn. https://github.com/jpmens/mqttwarn For a single interface in (mqtt) if can then push out to a number of notifications services. And while it may not have telegram, you could get it added (or add it yourself).

Then if needs change you could switch all to pushover or something else, without having to change your rules.

I have a bunch of items with varying levels that are picked up by mqtt warn. So in a rule I can just same sendcommand(notify_info,“message”) to send to mqttwarn.

3

Another approach would be to define a string item for the message.
Whenever the item gets updated, a rule will trigger and do the sendmessage.
You will only need to update this rule when changing from one service to another.

4

You are right on the money IMO - I have the following;

String      VT_Notify_Trace                     { mqtt=">[mosquitto:/openhab/notification/trace:state:*:default]" }
String      VT_Notify_Info                      { mqtt=">[mosquitto:/openhab/notification/info:state:*:default]" }
String      VT_Notify_Alert                     { mqtt=">[mosquitto:/openhab/notification/alert:state:*:default]" }
String      VT_Notify_Warn                      { mqtt=">[mosquitto:/openhab/notification/warn:state:*:default]" }
String      VT_Notify_Alarm                     { mqtt=">[mosquitto:/openhab/notification/alarm:state:*:default]" }

which when updated publish the messages to an MQTT topic. Then as suggested by @psyciknz I run mqttwarn which monitors those topics and forwards the messages to any number of delivery endpoint.

Has simplified my OH config immeasurably so would highly recommend!

5

I wrote Design Pattern: Separation of Behaviors to cover just this situation. It uses alerting as the example but can be used to centralize lots of things. It is basically a more detailed description of what Udo describes.

This approach is also handy to add some logic around alerts. For example, after dark only send alerts to one of the devices. During the day use a different service than at night. Send them using yet a different service if no one is home. Stuff like that.

And this does not preclude the use of MQTTWarn which is also a great service.

EDIT: somehow the link didn’t work to the DP.

6

Thanks all for the good tips. Mqttwarn looks interesting, but it’s a little overkill maybe for now. I try to avoid adding extra services as much as possible.
I hadn’t thought of using different priorities yet, that’s a very good idea. Does anyone use other possible schemes that relate more to the home automation context?

7

I have for a long time been looking for a better handling of Notification, I have always had more important things to deal with, so until now my notification flow in openHAB is quite ugly.So I was happy to read the above discussion. I decided to spent the evening with this little project - thanks to @ben_jones12 and @rlkoshak for making it easy :slight_smile:
There is a problem. It seems that mqttwarn doesn’t like special characters like our danish characters :cry: - Since some of you users live in countries with similar specialities (like Germany). I would like to hear if any of you have had similar problems and eventually have solved it?

I have tried to change a few linies in mqttwarn to address the issue, and it certainly solves the problem, but it seems that it just fails elsewhere in the code.

Another thing that I really doesn’t like is that it seems like mqttwarn disconnects whenevere an error occurs (it simply just stops broadcasting). Have anybody seen this behavoiur?

It really looks as exctly the tool I need for the task. So I would like to hear what others have seen :slight_smile:

8

It seems that node-red can handle the danish characters, so I have decided to continue with node-red as my notification bridge. I guess Í will have to do a little more “coding” in node-red, but it seems quite straight forward. Again, thanks for sharing the cookbook for notification decoupling :slight_smile: