Send notifications via Activities possible?

Plugins & Plugin Development Reactor
#21

The big problem with notifications on Vera is that they are scene-based, and changes generally require reloading of Luup. That kind of goofs up making on-the-fly changes like adding values from other sources in runtime. So, unless you use VeraAlerts, no dynamic messages.

With VeraAlerts may be another matter. There’s another step I can take in the integration, but that will take me a bit more time, so probably not a today thing, but pretty likely early tomorrow.

Message length… I have no idea. I haven’t even worried about that yet.–it remains to be tested/discovered. If you figure it out first, please let me know. I expect it to be different for Vera-native vs VeraAlerts.

#22

@rigpapa I love how you implementing the notify capability in the RS activities! Thanks!

What I did not like is that if I add a message override in VA it will change the name of the notification.
Because of this I can not have several notifications with different names send the same message.
So at least I do now want the VA message overrides to be back-ported to the ReactorSensor.

Another situation where back-porting might become a problem is when I send notifications that includes a snapshot from a camera. In this case the message override in VA can look like this:

Någon i Förrådet {Picture(http://192.168.1.16:3480/data_request?id=lr_SurveillanceStationRemote_43&command=getSnapshot&cameraId=4)}

Not sure how the RS reacts to this text being back-ported.

#23

I’ve completely reworked this already. New stuff coming out later today.

1 Like
#24

This thread is discussing pre-release software.

OK. New stable development release is up. I think overkill mode has been engaged. Here’s what’s changed with respect to notifications:

  1. Multiple new notification methods have been added and are supported internally (without additional plugins). These include: Vera-native (where all this started), Prowl, Syslog, and User URL.
  2. VeraAlerts is now optionally supported as a separate notification method. Obviously, this requires installation of the VeraAlerts plugin on the system. When the plugin is detected, the method will be selectable on the menu. The full detail of this is discussed below.
  3. The new Prowl notification method sends a notification via the Prowl API. Message and priority are configurable, and the message will accept in-line references to ReactorSensor expression variables, such as The temperature is now {TempF}F and exceeds the threshold. Currently, the Prowl API key must be set manually by editing the ProwlAPIKey state variable on the Reactor master device.
  4. The new Syslog notification method sends a Syslog UDP datagram to a syslog server. The facility and severity are configurable on a per-message basis. Expression variable references can be used in the message text.
  5. The new User URL notification method pushes a notification to a user-supplied URL. The magic string {message} will be replaced in the URL with the URL-encoded form of the message. The message may contain expression variable references.

There are special considerations for VeraAlerts.

When the Notify action uses the VeraAlerts Direct notification method (available only when VA is installed and running), the message is sent using VA’s SendAlert action. The message text may contain expression variable references. Since the Reactor syntax for variable references and VA’s syntax for substitutions is the same ({something}), any name Reactor doesn’t recognize is left intact and the entire reference is passed on to VA for it to handle.

It is possible to use the Vera-native notification method when VeraAlerts is installed. In this case, one of two things will happen:

  1. If the “Process Notifications” setting in VA is off, then Vera’s built-in notification system will handle the message with delivery through Vera’s servers.
  2. If the “Process Notifications” setting in VA is on, then this causes VA to override Vera’s notification system and use its own mechanisms. Part of the effect of this is that VA modifies the hidden notification scenes that Vera uses. Some of the modifications are not done on the scene data directly, but are done within Lua added to the scene, including the “message override”. As a result, it is possible for the scene data and the embedded Lua parameters to diverge, and more importantly, Reactor’s stored notification data to diverge. Rather than try to keep three data sources in sync when we don’t control two of them, Reactor now detects when its notification scenes are modified by VeraAlerts and will display a message advising you that the notification should henceforth be edited in VA only. Reactor will also lock out the fields and not allow you to edit the notification message or recipients in the Activities tab (you can still delete or move it, however).

Also note that although VeraAlerts may be handling the messages when “Process Notifications” is on, this does not change the fact that Vera’s hidden-scene-based notification mechanism is at work, which precludes any dynamic values from appearing in the ReactorSensor’s notification message–that is, you can’t use expression variable references when the Vera-native method is used, ever, whether VA is installed and overriding or not. If you need to have expression variable value substitution in the message, use the VeraAlerts Direct method, or any method other than Vera-native.

New code is in Github stable branch. Install as before as previously posted.

1 Like
#25

Am I right in thinking that VeraAlert plugin only works with Android phones?

#26

There is an Android app for VeraAlerts, but VA supports several notification methods, some of which have iOS apps. For iOS, there’s an app for Prowl, a mechanism that’s supported by both VeraAlerts and natively by Reactor without VeraAlerts.

http://www.prowlapp.com/

#27

@rigpapa how do i get rid of image

_nootify _Notify

EDiT: Fixed

#28

For VeraAlerts, I chose the pushover app because it has a client for both iOS and Android. In a home with a mixture of Android & iOS devices, one only has to learn 1 API
Chris

1 Like
#29

Stable branch on Github now updated to 3.4develop-19227. Changes since 19225 are principally:

  1. Add SMTP as a built-in notification method (this is the last one I really wanted to get);
  2. A lot of code cleanup and tweaks as part of ongoing effort to make the openLuup/ALTUI version look a bit cleaner (the difference between the Bootstrap versions causes differences in field alignment, etc.). There’s still work to do, but it’s getting better.

I’ve also gotten my automated testing running with openLuup, and put this version through several cycles successfully.

I am likely going to release version 3.4 on Sunday/Monday.

As usual, installation instructions for Github stable are the same as previously posted.

4 Likes
#30

A post was split to a new topic: Wanted: activity log (persistent)

#31

I decided to hold off. I need to spend a little more time with this. I like to have at least a week of testing after making big changes, and my schedule is a bit thin these days with a number of projects, and an all-important birthday milestone this week for Mrs. Rigpapa and my boys resuming school. And I really have to get the docs (wiki) updated so I can release everything together.

If you’re clamoring for this feature, the stable Github branch version is your go-to. It is, in fact, the current release candidate, and I do not expect any further changes before release (now shooting for Sunday/Monday August 25/26). As I said elsewhere this morning, I’d rather do good than fast (you already know I work cheap).

2 Likes
#32

works great

#33

Any plans on allowing MQTT for notification? I would like to send status for my 20+ doors (open/close) to a ThingsBoard server running on my NAS.

#34

The thought crossed my mind. There’s an MQTT plugin… I don’t know if that would do the job…

#35

Thanks - I couldn’t find the MQTT plug-in using official Vera App Store (Install Apps) . But I see that I could manually install one. I will try it out.

#36
#37

Has anyone successfully used this feature in a GMail / Port 465 (SSL) / 2-Factor Authentication / App Password setup?

I’ve been testing a simple trigger (e.g. when light goes on, Notify) with vanilla settings (i.e. my own GMail address, a Google-issued app password, sending to myself, etc.) and so far no results. No messages received.

Was VERY reluctant to post this, as it smacks of the verboten “It doesn’t work” but hope someone will suggest a Reactor or Vera setting that I may have overlooked.

THANKS!

  • Libra
#38

Gmail works. Can you post a logic summary (Tools tab)

#39

SOLVED!

UPDATE: My problem lay with SMTPProtocol, which is normally blank (=‘any’). Changing that variable to ‘tlsv1’ per the Reactor WIKI solved the problem, and messages send OK now. I had not fully realized my Vera Plus was running ‘pre-7.30’ firmware specifically mentioned in the WIKI, so that was the last box I ticked!

Happy to delete this series of posts upon request, but will leave up for now in case it helps any other n00bs like me.

=====

Pasting ‘Logic Summary’ below, which exemplifies every attempt thus far. Specifically, I want to send a message in response to a particular light being turned on, and despite that condition going TRUE reliably, the process fails with a “Failed SSL Wrap” warning (see log) every time.

During several hours of troubleshooting, I tried the following steps to cure, without any luck:

  • Created a new Reactor device to house this logic exclusively (was in subgroup before);
  • Renewed (i.e. removed and regenerated) Google-issued App Password for this project;
  • Scrutinized (agonizingly) relevant SMTP entries in main Reactor’s Advanced > Variables
  • Populated the normally blank variables below, then modified ‘Options’ per documentation for fw > 7.30 (will try < 7.30 alternatives momentarily):
  1. SMTPSSLProtocol = any
  2. SMTPSSLMode = client
  3. SMTPSSLVerify = none
  4. SMTPSSLOptions = all,no_sslv3
  • Double-checked that GMail messages weren’t hiding in ‘Spam’ folder or ‘All Mail’ (due to aliasing);
  • Tried ports 465 and 587 (but never 25) (then reverted to 465), and also actual GMail password (then reverted back to 16-character App pw);

Am plum out of ideas now. :wink: - Libra

NOTE: Am intentionally redacting email address below, with my assurance that it’s the same in all three fields (Sender, Recipient and Username);

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.5 config 20017 cdata 20045 ui 20045 pluginDevice 175 LuaXP not loaded
    System: Vera version 1.7.4453 (pre-7.30) on Sercomm G450 ID nil (unknown); loadtime 1582032627; systemReady 1582032644; Lua 5.1; JSON dkjson 1.2; UnsafeLua=1
Local time: 2020-02-18T07:37:50-0600; DST=0; New Orleans, Louisiana United States; formats %Y-%m-%d %H:%M:%S
House mode: plugin 1; system 1; tracking on
  Sun data: { "source": "int", "civdawn": 1582028027, "nautdawn": 1582026346, "sunset": 1582069856, "nautdusk": 1582072999, "stamp": 2020049, "latitude": 29.9657, "astrodusk": 1582074668, "longitude": -90.1064, "civdusk": 1582071319, "astrodawn": 1582024677, "sunrise": 1582029489 }
  Geofence: not running
************************************************************************************************************************************
Reactor (Messaging) (#191)
    Version 20045.4 02/18/20 07:35:55
    Message/status: Not tripped
    Condition group "Notify User" (AND)  false as of 07:37:10 <root>
      &-?-comment "Testing GMail 2-Factor Authentication Method" <cond0>
      &-F-service Fireplace Light (110) urn:upnp-org:serviceId:SwitchPower1/Status = 1 [1 => 0 at 07:37:10; F/F as of 07:37:10/07:37:10] <condo84xbot>
    Activity root.true
        Notify method SM nid 1: users  message "This message is to notify you about something."; SMTPServer="smtp.gmail.com"; SMTPPort="465"; SMTPSender="t+++s@gmail.com"; SMTPDefaultRecipient="t+++s@gmail.com"; SMTPDefaultSubject="Alert from Vera Plus"; SMTPUsername="t+++s@gmail.com"; SMTPPassword="****"; SSL opt { "verify": "none", "mode": "client", "protocol": "any", "options": [ "all", "no_sslv3" ] }
    Events
        2020-02-18 07:30:39: Reactor startup (Luup reload)
        2020-02-18 07:30:39: Starting (Luup Startup/Reload)
        2020-02-18 07:34:47: Configuration changed!
        2020-02-18 07:34:47: Condition condo84xbot test state changed from (nil) to false
        2020-02-18 07:34:47: Condition condo84xbot evaluation state changed from (nil) to false
        2020-02-18 07:34:47: Group Notify User test state changed from (nil) to false
        2020-02-18 07:34:47: Group Notify User evaluation state changed from (nil) to false
        2020-02-18 07:34:47: Changing RS tripped state to false
        2020-02-18 07:35:40: Configuration changed!
        2020-02-18 07:35:55: Configuration changed!
        2020-02-18 07:36:42: Device Fireplace Light (#110) urn:upnp-org:serviceId:SwitchPower1/Status changed from "0" to "1"
        2020-02-18 07:36:42: Condition condo84xbot test state changed from false to true
        2020-02-18 07:36:42: Condition condo84xbot evaluation state changed from false to true
        2020-02-18 07:36:42: Group Notify User test state changed from false to true
        2020-02-18 07:36:42: Group Notify User evaluation state changed from false to true
        2020-02-18 07:36:42: Launching Notify User.true activity
        2020-02-18 07:36:42: Launching scene/activity root.true
        2020-02-18 07:36:42: Starting "root.true" group 1
        2020-02-18 07:36:42: { dev=191, warning="[string \"--[[...\"]:2218: Failed SSL wrap", scene="root.true", sceneName="root.true", index=1, event="runscene", group=1 }
        2020-02-18 07:36:42: Activity "root.true" finished
        2020-02-18 07:36:42: Changing RS tripped state to true
        2020-02-18 07:37:10: Device Fireplace Light (#110) urn:upnp-org:serviceId:SwitchPower1/Status changed from "1" to "0"
        2020-02-18 07:37:10: Condition condo84xbot test state changed from true to false
        2020-02-18 07:37:10: Condition condo84xbot evaluation state changed from true to false
        2020-02-18 07:37:10: Group Notify User test state changed from true to false
        2020-02-18 07:37:10: Group Notify User evaluation state changed from true to false
        2020-02-18 07:37:10: Changing RS tripped state to false
    Devices
        Fireplace Light (110) urn:schemas-micasaverde-com:device:PhilipsHueLamp:1 (2/-1); parent 94; plugin -; mfg  model ; dev D_PhilipsHueLamp2.xml impl 
        Hue Lights (94) urn:schemas-micasaverde-com:device:PhilipsHue:1 (26/-1); parent 0; plugin 8162; mfg Philips model hue; dev D_PhilipsHue2.xml impl I_PhilipsHue2.xml
    Watches
        Device #110 Fireplace Light service urn:upnp-org:serviceId:SwitchPower1 variable Status
        Device #191 Reactor (Messaging) service urn:toggledbits-com:serviceId:ReactorSensor variable TestHouseMode
        Device #191 Reactor (Messaging) service urn:toggledbits-com:serviceId:ReactorSensor variable TestTime
        Device #191 Reactor (Messaging) service urn:toggledbits-com:serviceId:ReactorSensor variable cdata
    Special Configuration
        UseReactorScenes = 1
        LogEventsToFile = 0
        Retrigger = 0
        FailOnTrouble = 0
        ContinuousTimer = 0
#40

Since you’re on firmware < 7.30, try changing SMTPSSLProtocol to tlsv1_2 and SMTPSSLOptions to any.

This also may not work, as Google has upgraded their server security, placing new demands on clients that the ancient version of LuaSec in older Vera firmware cannot meet. If the above fails, I would suggest restoring the settings to default (SMTPSSLProtocol=any, SMTPSSLOptions=all,no_sslv3) and upgrading to the 7.31 beta (or waiting for its general release).

1 Like