Handy notification script for those with an MQTT broker...mqttwarn

3,231 views
Skip to first unread message

Ben Jones

unread,
Feb 16, 2014, 3:26:23 AM2/16/14
to ope...@googlegroups.com
Definitely worth checking this out if you have an MQTT broker, or are thinking of installing/using one! A big pat on the shoulder to JP Mens for his fantastic work getting this off the ground and out the door!


Using this you can effectively decouple all notifications from within openHAB. This means you no longer need to load the Mail, Twitter, Prowl, NMA, or XBMC action bundles, and you can replace all your notification rules with very simple one-line statements.

For example, in your .items file you just need a set of virtual items, one for each type of notification you will need to send;

String    Notify_Info            (Notification)    { mqtt=">[mosquitto:/openhab/notification/info:state:*:default]" }
String    Notify_Alert          (Notification)    { mqtt=">[mosquitto:/openhab/notification/alert:state:*:default]" }
String    Notify_Warn         (Notification)    { mqtt=">[mosquitto:/openhab/notification/warn:state:*:default]" }
String    Notify_Alarm        (Notification)    { mqtt=">[mosquitto:/openhab/notification/alarm:state:*:default]" }

Then whenever you want to raise a notification in one of your rules, all you do is post an update to the notification item, with the notification text;

Notify_Info.postUpdate("This is a information notification")
Notify_Alert.postUpdate("This is an alert notification")
etc...

That is it as far as openHAB is concerned. Everything else is configured in the mqttwarn configuration file. 

What this means is it is very easy to add/remove targets from certain types of notifications (i.e. add a new Prowl user), without having to search ALL your rules and update each one. You can add/remove notification types as well (i.e. add twitter notifications). Check out the mqttwarn readme for details on how to configure the script.

This is a great example of how flexible and powerful MQTT can be, and is a great way to simplify your openHAB rules so they just focus on the automation side of things, rather than all the different notifications you want to support!

Romain Bourdy

unread,
Feb 16, 2014, 5:23:42 AM2/16/14
to ope...@googlegroups.com
Hey !

Nice catch ! Definetly worth a try, did you see a CPU/Mem usage improvement using this ?

Rgds,
-Romain B.

Jan-Piet Mens

unread,
Feb 16, 2014, 6:05:59 AM2/16/14
to ope...@googlegroups.com
> This is a great example of how flexible and powerful MQTT can be, and is a
> great way to simplify your openHAB rules so they just focus on the
> automation side of things, rather than all the different notifications you
> want to support!

All credit goes to you Ben, for inspiration, code, and ideas, and for
the excellent explanation/documentation above. I also feel that using
MQTT to communicate into/out of openHAB is ideal.

-JP

Jan-Piet Mens

unread,
Feb 16, 2014, 6:09:19 AM2/16/14
to ope...@googlegroups.com
> did you see a CPU/Mem usage improvement using this ?

Versus individual notification bundles in openHAB? I haven't measured,
and won't. What I'd _expect_ to see is a lower memory footprint (one
MQTT binding vs. several others)

The main point Ben is making (and I agree 109%) is that it's a single
point of entry/exit to/from openHAB, which makes for a homogenous
configuration/setup and eases our lives when we want to add/remove
notifications.

-JP

Ben Jones

unread,
Feb 16, 2014, 2:51:28 PM2/16/14
to ope...@googlegroups.com
Yep - the big benefit is simplified rules and easy config/changes to notification recipients and methods. I like the fact openHAB is now left to worry about automation rules and all the notification stuff is handled elsewhere.

Thomas Eichstädt-Engelen

unread,
Feb 16, 2014, 2:59:20 PM2/16/14
to ope...@googlegroups.com
we have this notification issue on our long feature list to implement … thanks to Ben and Jan for providing such a handy solution. We'll see how to merge this approach with the one to come up with in ESH.

Thanks,

Thomas E.-E.



On 16 Feb 2014, at 20:51, Ben Jones <ben.j...@gmail.com> wrote:

Yep - the big benefit is simplified rules and easy config/changes to notification recipients and methods. I like the fact openHAB is now left to worry about automation rules and all the notification stuff is handled elsewhere.

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/groups/opt_out.

Chris Jackson

unread,
Feb 16, 2014, 3:11:13 PM2/16/14
to ope...@googlegroups.com

> we have this notification issue on our long feature list to implement …

Hi Thomas - is this “long feature list” visible somewhere? I’d really be interested in seeing a roadmap, and I think it would be useful for everyone, but as far as I know there’s nothing published other than the issues list?

Cheers
Chris

Thomas Eichstädt-Engelen

unread,
Feb 16, 2014, 3:17:36 PM2/16/14
to ope...@googlegroups.com
Hi,

yes, you're right, there is nothing else than the issue list … indeed a roadmap would be helpful and i think there will be such a roadmap for the Eclipse SmartHome project (where this notification issue would belong to). Here in openHAB we are very much "controlled" by the contributions of the community which are not schedule able at all …

Cheers, Thomas E.-E.


On 16 Feb 2014, at 21:11, Chris Jackson <ch...@cd-jackson.com> wrote:

>
>> we have this notification issue on our long feature list to implement ...
>
> Hi Thomas - is this "long feature list" visible somewhere? I'd really be interested in seeing a roadmap, and I think it would be useful for everyone, but as far as I know there's nothing published other than the issues list?
>
> Cheers
> Chris
>

Ben Jones

unread,
Feb 17, 2014, 2:32:02 PM2/17/14
to ope...@googlegroups.com
Here is a blog post about this great little script, written by JP...


Check it out, and also the very detailed README on his Github repo...


Ben Jones

unread,
Feb 20, 2014, 4:25:18 AM2/20/14
to ope...@googlegroups.com
For those who are interested, there are now a heap more services supported by mqttwarn, check it out. PushBullet was just added this evening, and JP has been busy adding NotifyMyAndroid, Twilio, Redis.PUB and SqlLite3.

This is really a great way to handle openHAB notifications - so simple to add another target or new service type, without touching a single openHAB rule.

Doug Meredith

unread,
Jan 13, 2015, 7:50:32 AM1/13/15
to ope...@googlegroups.com
Now *this* is how I want to do my notifications! I've just discovered this and will definitely be giving it a try.

Gandalph

unread,
Apr 30, 2015, 4:17:28 PM4/30/15
to ope...@googlegroups.com
This is great stuff! I just succeeded in getting Twilio to work with MQTTwarn and thought I'd share the config :) (below a tip for the items file, make sure you have the brokers name right...)

add to the mqttwarn.ini the following, after installing twilio python stuff, as per https://github.com/jpmens/mqttwarn#twilio

[config:twilio]
targets = {
   'warn'  : [ 'ACblahblah', 'secretkey', "+from phone nr, enabled in twilio to send text msg",  "+TO phone nr" ],
   'ALARM'  : [ 'ACblahblah', 'secretkey', "+from phone nr, enabled in twilio to send text msg",  "+TO phone nr" ],
   }

[openhab/notification/warn]
topic = /openhab/notification/warn
targets = twilio:warn

[openhab/notification/alarm]
topic = /openhab/notification/alarm
targets = twilio:ALARM

now need to figure out how I can get a phonecall, so pointers are appreciated, cheers!



For example, in your .items file you just need a set of virtual items, one for each type of notification you will need to send;

String    Notify_Info            (Notification)    { mqtt=">[mosquitto:/openhab/notification/info:state:*:default]" }    <---- make sure you get the broker name right, mine was called mymosquitto ...

Ben Jones

unread,
Apr 30, 2015, 4:19:51 PM4/30/15
to ope...@googlegroups.com
Do you have Freeswitch or Asterisk running as your VOIP server?

If so just configure it as another mqttwarn target and you are pretty
much done!

Gandalph

unread,
Apr 30, 2015, 4:45:26 PM4/30/15
to ope...@googlegroups.com
Hi Ben, thanks for the tip. No asterisk or Freeswitch (yet?) here. I thought I could have twilio call me, instead of sending me a text, that would require some tinkering on twilio.py I assume. Not much of a coder though I do have some experience setting up twimls etc for twilio.

Greg EVA

unread,
May 1, 2015, 6:48:11 AM5/1/15
to ope...@googlegroups.com
I don't know Twilio, but these engines with a web API to send texts are very different than something which places calls.  If you are thinking that there will be a voice which would speak to you when you answer, this is a whole other domain.  Asterisk programmers could set this up for you... but you are probably better off forgetting about this idea unless you are ready to spend a lot of time and/or money on the alarm phone call.

Ben Jones

unread,
May 1, 2015, 7:12:02 AM5/1/15
to ope...@googlegroups.com

I have it working with Freeswitch. Relatively easy really, just sends the message to the Google TTS service and saves to an mp3 locally. Then initiate a VOIP call and play the mp3. Works very well although I only use it for critical warnings so it is not required very often thankfully!

This is all handled by mqttwarn. Pretty cool IMO!

Greg EVA

unread,
May 1, 2015, 7:55:29 AM5/1/15
to ope...@googlegroups.com
Not much to say to that other than, You are the man Ben!

Jan-Piet Mens

unread,
May 1, 2015, 3:47:22 PM5/1/15
to ope...@googlegroups.com
> Not much to say to that other than, You are the man Ben!

He certainly is!

-JP

Gandalph

unread,
Jun 19, 2015, 8:39:09 AM6/19/15
to ope...@googlegroups.com
Just got back to this and with Twilio it's really easy to have mqttwarn call you and TTS. Since Twilio has a built in TTS capability basically all I had to do is change the current Twilio addon to address the client.calls.create via the TwilioRestClient and supply the URL with xml, like so: http://twimlets.com/echo?Twiml=%3C%3Fxml%20version%3D%221.0%22%20encoding%3D%22UTF-8%22%3F%3E%0A%3CResponse%3E%0A%20%20%20%20%3CSay%20voice%3D%22man%22%3EAlarm!%20Sensor%20detected%20presence%20in%20the%20garden%20room.%3C%2FSay%3E%0A%3CHangup%2F%3E%0A%3C%2FResponse%3E&

and voila, now I get calls from my PIR! :)

Op vrijdag 1 mei 2015 13:12:02 UTC+2 schreef Ben Jones:

Marcel Verpaalen

unread,
Aug 13, 2015, 9:28:20 AM8/13/15
to openhab
Hallo Gandalph,

Trying to do the same and struggling a bit. 
Could you share the code change you did in twillo.py?  


Op vrijdag 19 juni 2015 14:39:09 UTC+2 schreef Gandalph:

Gisbert Oskam

unread,
Aug 17, 2015, 3:50:31 PM8/17/15
to ope...@googlegroups.com
Hi Marcel
PFA (zie bijgaand). Variables of API secret etc are in mqttwarn config file. I changed the function call to "call" and make sure to paste some correct xml in there (see twilio's documentation)

cheers!


--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/HyRhF5xLZXs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
twiliocall.py
twiliotext.py
Reply all
Reply to author
Forward
0 new messages