Send notifications via Activities possible?

@sm2117, then UseReactorScenes is definitely the way to go for you. It lets you keep your groups, and the notifications via your Vera scenes, both.

If a change UseReactorScenes in my RS to 0 how can I then create a notification for a specific condition in the RS? I have 4 subgroups that should generate notifications when the condition is met.
Should I manually create a vera scene for each condition?
This situation was handled when using PLEG like this:
image
Maybe a similar implementation could be implemented in Reactor?

Vera does not provide a Luup API for generating a notification, but there are ways. You can either use one of the common external notification interfaces (Prowl, etc.), or you can use the Vera-native notifications (hidden scenes automatically created by Vera) triggered by a ReactorSensor’s overall tripped state by going to the “Notifications” tab of a ReactorSensor (this only works for overall tripped state, you cannot do it per condition group).

I’m using VeraAlerts, so I now created Vera scenes for each notification and just run the scenes from the specific condition in the Reactor sensor. It is not as elegant as the PLEG solution but it works.

I’ve been able to run VeraAlerts directly from the Reactor Activities as a Device Action.

I now have a development version of Reactor that has the ability to send notifications natively (on Vera, without additional plugins). Although Vera doesn’t have an API to initiate a notification, I figured something out that can work, I think, and you can even send multiple notifications per activity/group, each with different messages–much better than the single scene triggering.

If you would like to test this version, install the stable branch release of Reactor on Github:

  1. Go to the “Backup and Restore” tab on your current Reactor master device and take a backup! I also recommend that you download the backup file (link on that page) for safe keeping. Just in case.
  2. Go here for the Github stable branch: GitHub - toggledbits/Reactor at stable
  3. Click the green “Clone or download” button and choose “Download ZIP”
  4. Unzip the file.
  5. Open the Vera uploader at Apps > Develop apps > Luup files.
  6. Drag all of the unzipped files except the .md files to the “Upload” button/area. This will upload the files and then reload Luup.
  7. Do a hard refresh of your browser. Do not skip this step.

You will then find the “notify” action in the Activities of your ReactorSensors. If you don’t see it, either you didn’t install the correct version, or you didn’t hard refresh (the version number shown in the footer should be “3.4develop-19222”).

The first notification after configuration sometimes doesn’t make it out (Luup notices there’s been a reconfiguration of user_data–part of the setup for notifications–and sometimes does a restart, and this interrupts the first send before it completes. But after that, things seem to go pretty well so far in my testing. I’ll be curious to see what you all might come up with.

There are some other fixes and new features in this version. See the CHANGELOG.md file for more information.

1 Like

don know why vera just doesnt hire you

2 Likes

@rigpapa you are awesome! Thanks for this!!

hey in vera alerts is shows this

Well what do you know, that is right :smiley: This simplifies it a great deal. Thanks for the hint!
The only downside to this is that the notifications cannot be managed from VeraAlerts itself.

They may be. VeraAlerts extends the standard Vera notifications mechanism that uses hidden scenes; this is the same mechanism Reactor must use. VA’s extension is to add scene Lua that calls a VA action to do the notification its way.

Without going into a lot of technical detail, if you override the message in VA, that should work fine. The message in the ReactorSensor will not be used, because VA will always prefer its override, but if you are consistent and always edit your messages in VA, you should have no problems. I also may be able to detect VA and back-port any override message into the ReactorSensor.

VA also appears to keep its own list of recipients and does not use the fields provided on the hidden scene for that purpose. So if you change the recipients on the ReactorSensor, I’m not sure if VA picks that up without going into its editor with refreshed data, and if you change the recipients in VA, I can tell you for sure the ReactorSensor has no idea about that change. I can address the latter issue in the same way as the override message. It remains to be seen (via testing) what the impact of the former may be, and it could be that it will simply be an issue VA users will need to be aware of.

But it certainly appears that, right now today without any changes whatsoever, edits to recipients and messages done in VA should work perfectly fine, they just won’t be visible in your ReactorSensor, so you’ll see different data there. I’ll tinker with that, and make the RS messages appear as something other than “_notify” so you can tell what you’re actually looking at.

OK. I now have a version of the ReactorSensor activity editor that’s “VeraAlerts-aware”. It’s up in the stable branch on Github, and the install instructions are the same as in the previous instructions post. If you’re into the whole brevity thing, the only file you need to upload is J_ReactorSensor_UI7.js (but it doesn’t hurt to upload everything). Don’t forget to hard-refresh those browsers, folks!

IMPORTANT: For everyone who installed yestreday’s stable release whether you use VeraAlerts or not, please update to this newer release. I found a nasty little bug in the UI that will not cause any problems for your Vera, but may cause the activity editing UI some serious heartburn to your browser.

When everything is correctly installed, the version displayed in config editing footers is “3.4develop-19224”.

1 Like

Great stuff. Works a treat. Is there a way to send a value from a multistring or an expression within Reactor? I would like to send a daily message with my previous day’s power consumption. Also is there a message length limit?

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.

@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.

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

1 Like

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

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

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/

@rigpapa how do i get rid of image

_nootify _Notify

EDiT: Fixed