Send Pushover notifications with pictures and hyperlinks

jrbeddow said:
Out of curiosity, and it might be too early to tell, but have you gotten any sense that using this might cut back on the number of "empty" (missing attachment) Pushover messages? I haven't implemented this just yet (and will probably have more questions later when I do), but this would be my primary motivation (along with the potential 1-2 second gain in notification speed).
Click to expand...
Can't really say. I get so few empty alert notifications,

Until today, I've tested the script on only one camera (my busiest driveway cam) on 2 profiles. So far I've not noticed a single empty notification.

This morning I migrated 4 more cameras to the script (on two profiles each). I'll let you know if I I get any empty alert notifications.

EDIT: I should have mentioned also that while testing, I sent a notification on every trigger, not just alerts. And probably 100+ more test notifications from the command line while developing/debugging the script.
 
Last edited:
  • Like
Reactions: jrbeddow
Updated Powershell script 'pushover_resize.ps1' (post #347)
Script updated to V1.5
  • added named commandline arguments: -Msg, -Priority, -AttachFile, -Quality, Width, -TargetKB -Quiet
    using any of the last five will override the defaults in the USER SETTINGS section
  • changed user setting '$img_size' to '$img_width' (for clarity)
  • fixed potential memory leak opportunity in function ResizeImage()
  • added a background message that summarizes attachment resize results and script performance
  • added 'WxHBefore' and 'WxHAfter' columns to CSV log (must rename existing CSV file before they will appear)
KEY POINT: If you are already using V1.4 or lower in Blue Iris actions, then you must edit those actions.
  • Please note that the Pushover notification attachment now needs to be the 3rd position argument (unless you are using the -AttachFile named argument, then it can be located anywhere).
  • The 2nd position argument is now the Pushover notification priority. Use an asterisk to use the script’s default priority (unless you are using the -Priority named argument, then it can be located anywhere).

The most significant benefits of these changes are:
1. The Blue Iris 'run a program' action can now be customized per camera (e.g., normal vs emergency notification; amount of attachment compression).
2. You can now observe performance results in real-time (vs viewing the CSV log file after the fact), which may aid in optimizing the parameters.
 
Last edited:
  • Like
Reactions: jrbeddow
jaydeel said:
Updated Powershell script 'pushover_resize.ps1' (post #342)
Script updated to V1.5
  • added named commandline arguments: -Msg, -Priority, -AttachFile, -Quality, Width, -TargetKB -Quiet
    using any of the last five will override the defaults in the USER SETTINGS section
  • changed user setting '$img_size' to '$img_width' (for clarity)
  • fixed potential memory leak opportunity in function ResizeImage()
  • added a background message that summarizes attachment resize results and script performance
  • added 'WxHBefore' and 'WxHAfter' columns to CSV log (must rename existing CSV file before they will appear)

The most significant benefits of these changes are:
1. The Blue Iris 'run a program' action can now be customized per camera (e.g., normal vs emergency notification; amount of attachment compression).
2. You can now observe performance results in real-time (vs viewing the CSV log file after the fact), which may aid in optimizing the parameters.
Click to expand...
HELP! I had this working well under yesterday's script version (1.4), but suddenly when I switched over to the new (as of a few hours ago) version 1.5 script, my attachment photos are no longer being sent. I saw that that was (in theory) the changeover to Optional attachments under 1.4, but it was the first time I set it up, and it worked right away. I didn't change anything else, I just copied over my Pushover User API key and Application keys. I have not experimented with adding arguments to the Parameters line, and in fact am using the Macro method mentioned by another user (which worked fine under script version 1.4)

Any ideas on where to look to fix this?
 
jrbeddow said:
HELP! I had this working well under yesterday's script version (1.4), but suddenly when I switched over to the new (as of a few hours ago) version 1.5 script, my attachment photos are no longer being sent. I saw that that was (in theory) the changeover to Optional attachments under 1.4, but it was the first time I set it up, and it worked right away. I didn't change anything else, I just copied over my Pushover User API key and Application keys. I have not experimented with adding arguments to the Parameters line, and in fact am using the Macro method mentioned by another user (which worked fine under script version 1.4)

Any ideas on where to look to fix this?
Click to expand...
Sorry about that.

The reason why is that the Pushover notification attachment is now the 3rd positional argument. Pushover priority is now the 2nd argument.

Please see the updated Parameters field entry in Post #347.
-File "C:\ps_scripts\pushover_resize.ps1" -Msg "<b>&CAM</b> &MEMO <a href='&WAN/alerts/&ALERT_DB?fulljpeg'>Hi-Res</a> <a href='&WAN/ui3.htm?rec=&ALERT_DB'>UI3</a>" -Priority 2 -AttachFile "D:\Blue Iris\Alerts\&ALERT_PATH"

If you really don't want to use the named arguments, then insert an asterisk between the message and attachment. This will use the default priority in the USER SETTINGS section.
-File "C:\ps_scripts\pushover_resize.ps1" "<b>&CAM</b> &MEMO <a href='&WAN/alerts/&ALERT_DB?fulljpeg'>Hi-Res</a> <a href='&WAN/ui3.htm?rec=&ALERT_DB'>UI3</a>" * "D:\Blue Iris\Alerts\&ALERT_PATH"
This is the equivalent of
-File "C:\ps_scripts\pushover_resize.ps1" -Msg "<b>&CAM</b> &MEMO <a href='&WAN/alerts/&ALERT_DB?fulljpeg'>Hi-Res</a> <a href='&WAN/ui3.htm?rec=&ALERT_DB'>UI3</a>" -AttachFile "D:\Blue Iris\Alerts\&ALERT_PATH"

Named arguments can be used in any order.

For more examples, take a quick look at README.txt in the zip file. Or the comments at the top of the script file.
 
  • Like
Reactions: jrbeddow
jaydeel said:
Sorry about that.

The reason why is that the Pushover notification attachment is now the 3rd positional argument. Pushover priority is now the 2nd argument.

Please see the updated Parameters field entry in Post #347.
-File "C:\ps_scripts\pushover_resize.ps1" -Msg "<b>&CAM</b> &MEMO <a href='&WAN/alerts/&ALERT_DB?fulljpeg'>Hi-Res</a> <a href='&WAN/ui3.htm?rec=&ALERT_DB'>UI3</a>" -Priority 2 -AttachFile "D:\Blue Iris\Alerts\&ALERT_PATH"

If you really don't want to use the named arguments, then insert an asterisk between the message and attachment. This will use the default priority in the USER SETTINGS section.
-File "C:\ps_scripts\pushover_resize.ps1" "<b>&CAM</b> &MEMO <a href='&WAN/alerts/&ALERT_DB?fulljpeg'>Hi-Res</a> <a href='&WAN/ui3.htm?rec=&ALERT_DB'>UI3</a>" * "D:\Blue Iris\Alerts\&ALERT_PATH"
This is the equivalent of
-File "C:\ps_scripts\pushover_resize.ps1" -Msg "<b>&CAM</b> &MEMO <a href='&WAN/alerts/&ALERT_DB?fulljpeg'>Hi-Res</a> <a href='&WAN/ui3.htm?rec=&ALERT_DB'>UI3</a>" -AttachFile "D:\Blue Iris\Alerts\&ALERT_PATH"

Named arguments can be used in any order.

For more examples, take a quick look at README.txt in the zip file. Or the comments at the top of the script file.
Click to expand...
Awesome, that of course did the trick.

I hadn't noticed the modifications that you had done to the Parameters line (perhaps you could consider more explicitly pointing those out if those change again, it should cut done on support requests....no guarantees naturally ;) ) .

Many thanks again for all the work on making Pushover the premium choice for notifications.

Edit and P.S.- I like the 30 second "background messages" for now, they are helpful for performance tuning,...but I may eventually tire of them: is it easy to shut those off?
 
jrbeddow said:
I like the 30 second "background messages" for now, they are helpful for performance tuning,...but I may eventually tire of them: is it easy to shut those off?
Click to expand...
Yes. Two ways:
1. Globally via a setting in the script’s USER SETTINGS section $bg_msgs_flg = $false
2. On demand via a command line argument (parameter) -Quiet Y
 
Last edited:
  • Like
Reactions: jrbeddow
Unless anyone finds a bug in 'pushover_resize.ps1', I'll be posting a final update today. V1.6 will add support for using the Blue Iris logfile to post error conditions (default), and data (optional) for each event (similar to the logfile's AI entries).

My next project is see if I can figure out how to create GIF attachments on-the-fly for Pushover notifications.
 
Last edited:
  • Like
Reactions: jrbeddow and scoob8000
jaydeel said:
Unless anyone finds a bug in 'pushover_resize.ps1', I'll be posting a final update today. V1.6 will add support for using the Blue Iris logfile to post error conditions (default), and data (optional) for each event (similar to the logfile's AI entries).

My next project is see if I can figure out how to create GIF attachments for Pushover notifications.
Click to expand...

Just a thought. I don't know if it's possible, or makes things too complex. But can powershell read variables and settings from an .ini file of sorts? If so then users can upgrade the script without editing their settings.

Keep up the good work! Cheers!
 
Currently, I'm using the Title parameter with Pushover in format like "... --form-string "title=Blue Iris alert - &CAM ...". Would it possible to add this as an Argument in your upcoming version similar to how you have -Msg argument parameter?

Also, I was wondering if you have considered using launching powershell script as "job" that queues up behind the scene and clears out as each job processes one after another or concurrently up to number of concurrent jobs. I'd think that would be more efficient and seamless, but just curious if you have thought about using it in this manner with Powershell.
 
cybernetics1d said:
Currently, I'm using the Title parameter with Pushover in format like "... --form-string "title=Blue Iris alert - &CAM ...". Would it possible to add this as an Argument in your upcoming version similar to how you have -Msg argument parameter?

Also, I was wondering if you have considered using launching powershell script as "job" that queues up behind the scene and clears out as each job processes one after another or concurrently up to number of concurrent jobs. I'd think that would be more efficient and seamless, but just curious if you have thought about using it in this manner with Powershell.
Click to expand...
1. Yes, I can easily add a named argument like '-Title'.
2. I have not considered launching powershell script as "job". I'll look into this.
 
Last edited:
  • Like
Reactions: cybernetics1d
Updated Powershell script 'pushover_resize.ps1' (post #347)
Script updated to V1.6
  • moved USER SETTINGS code to a separate configuration file (pushover_resize_user_settings.ps1)
  • added named argument '-Title' (for custom notification titles)
  • added 5 user settings to support posting error messages to the Blue Iris logfile (use setting '$post_to_BI_logfile_flg' to enable/disable this feature)
  • added a user setting to post ALL resize event messages to the Blue Iris logfile ($post_all_events)
  • improved background messaging toggling
The most significant benefits of these changes are:
1. User settings can be more easily migrated to an updated script
2. You can now use Blue Iris logfile to be notified of issues, event if backgroudn messaging is disabled
 
Last edited:
  • Like
Reactions: scoob8000 and jrbeddow
jaydeel said:
Updated Powershell script 'pushover_resize.ps1' (post #347)
Script updated to V1.6
  • moved USER SETTINGS code to a separate configuration file (pushover_resize_user_settings.ps1)
  • added named argument '-Title' (for custom notification titles)
  • added 5 user settings to support posting error messages to the Blue Iris logfile (use setting '$post_to_BI_logfile_flg' to enable/disable this feature)
  • added a user setting to post ALL resize event messages to the Blue Iris logfile ($post_all_events)
  • improved background messaging toggling
The most significant benefits of these changes are:
1. User settings can be more easily migrated to an updated script
2. You can now use Blue Iris logfile to be notified of issues, event if backgroudn messaging is disabled
Click to expand...
Could you clarify one detail related to the new (optional) posting to the BI logfile feature?

Is it mandatory to set this (...to use credentials, be sure to uncheck 'Use secure session keys and login page' in Blue Iris settings: click Settings > Web server > Advanced)
to the unchecked/insecure setting in BI if we choose to set the next setting (OPT-IN TO USE CREDENTIALS FOR POSTING TO BLUE IRIS LOGFILE) to false?

It would seem unnecessary, but I don't fully follow the logic here, as your help comments in the README/script seem slightly misaligned with regards to what section they apply to.
 
jaydeel said:
Updated Powershell script 'pushover_resize.ps1' (post #347)
Script updated to V1.6
Click to expand...
I just installed and set this up. It's working, but I can't seem to get the BI logging to inject anything into the logs. Here's how I have it set. I made a new Admin user and put those credentials in the config, and made sure use secure session is off. I can login to ui3 with that un/pw using 127.0.0.1:81 from a browser on my BI machine.

Code: 
# OPT-IN TO POST CUSTOM MESSAGE TO BLUE IRIS LOG
# ... expecting $false or $true (default = $false)
#$post_to_BI_logfile_flg = $false
$post_to_BI_logfile_flg = $true

    # THE FOLLOWING ARE [REQUIRED] IF OPTING IN...

    # ENTER BLUE WEBSERVER ADDRESS & PORT
    # ... to use credentials, be sure to uncheck 'Use secure session keys and login page'
    #     in Blue Iris settings: click Settings > Web server > Advanced
    $bi_webserver = "127.0.0.1:81"

    # OPT-IN TO USE CREDENTIALS FOR POSTING TO BLUE IRIS LOGFILE
    # ... expecting $false or $true
    #$post_w_creds_flg = $false
    $post_w_creds_flg = $true

    # [OPTIONAL] ENTER BLUE IRIS WEBSERVER USERNAME & PASSWORD
    # ... NOTE: USERNAME MUST BE ADMIN
    $bi_user_name = "XXX"
    $bi_user_pw = "XXX"

    # OPT IN TO LOGGING ALL EVENTS (NOT JUST ERRORS)
    # ... [boolean]
    # ... Default is $FALSE
    #$post_all_events = $false
    $post_all_events = $true
 
scoob8000 said:
I just installed and set this up. It's working, but I can't seem to get the BI logging to inject anything into the logs. Here's how I have it set. I made a new Admin user and put those credentials in the config, and made sure use secure session is off. I can login to ui3 with that un/pw using 127.0.0.1:81 from a browser on my BI machine.

Code: 
# OPT-IN TO POST CUSTOM MESSAGE TO BLUE IRIS LOG
# ... expecting $false or $true (default = $false)
#$post_to_BI_logfile_flg = $false
$post_to_BI_logfile_flg = $true

    # THE FOLLOWING ARE [REQUIRED] IF OPTING IN...

    # ENTER BLUE WEBSERVER ADDRESS & PORT
    # ... to use credentials, be sure to uncheck 'Use secure session keys and login page'
    #     in Blue Iris settings: click Settings > Web server > Advanced
    $bi_webserver = "127.0.0.1:81"

    # OPT-IN TO USE CREDENTIALS FOR POSTING TO BLUE IRIS LOGFILE
    # ... expecting $false or $true
    #$post_w_creds_flg = $false
    $post_w_creds_flg = $true

    # [OPTIONAL] ENTER BLUE IRIS WEBSERVER USERNAME & PASSWORD
    # ... NOTE: USERNAME MUST BE ADMIN
    $bi_user_name = "XXX"
    $bi_user_pw = "XXX"

    # OPT IN TO LOGGING ALL EVENTS (NOT JUST ERRORS)
    # ... [boolean]
    # ... Default is $FALSE
    #$post_all_events = $false
    $post_all_events = $true
Click to expand...

EDIT #2: Never mind. While answering @jrbeddow 's question below I spotted a bug. I'll post a new *.zip file soon.

Sorry it's not working.

The log entries should look like this:
1. Status > Messages log ... (Note: the 'Message' entries get truncated by Blue Iris; you must inspect the *.txt logfile.txt for the full entry)
bi_status_messages.png


2. Via the *.txt logfile (complete versions of the same entries highlighted above, but in reverser order)
bi_logfile_excerpt.png



Are you sure the user is an administrator? Like this...
bi_settings_webserver_advanced.png

The script uses the following HTTP Interface command. Try using it directly from your browser using the same credentials in the configuration *.ps1 file.

bi_help_http_log_cmd.png

bi_help_basic_auth_url.png


EDIT: I should have noted that 'message' in the URL must not contain spaces (use %20 instead). I just realized that V1.6 failed to ensure this. While it worked on my machine, perhaps this is causing an issue on your machine. I'll post an updated zip file soon.
 
Last edited:
jrbeddow said:
Could you clarify one detail related to the new (optional) posting to the BI logfile feature?

Is it mandatory to set this (...to use credentials, be sure to uncheck 'Use secure session keys and login page' in Blue Iris settings: click Settings > Web server > Advanced)
to the unchecked/insecure setting in BI if we choose to set the next setting (OPT-IN TO USE CREDENTIALS FOR POSTING TO BLUE IRIS LOGFILE) to false?

It would seem unnecessary, but I don't fully follow the logic here, as your help comments in the README/script seem slightly misaligned with regards to what section they apply to.
Click to expand...
Sorry for being unclear.

All settings/requirements below the $post_to_BI_logfile_flg = line are moot if the line is $post_to_BI_logfile_flg = $false

I've attempted to signal this by indenting the code under this line. For clarity, I'll edit the comments to make this more explicit in the next version.

By the way, here's the code that uses the above mentioned settings. Maybe this will clarify the logic.
Code: 
    # Remove incompatible substrings from $MsgStr
    $MsgStr = $MsgStr -Replace "`n", "" -Replace "\\r", "" -Replace "\\n", ""
 
    $bi_address = $script:bi_webserver
    if ($script:post_w_creds_flg) {
        $uri = "http://$bi_address/admin?log=$MsgStr&level=$Level&user=$script:bi_user_name&pw=$script:bi_user_pw"
    } else {
        $uri = "http://$bi_address/admin?log=$MsgStr&level=$Level"
    }
    $result = Invoke-WebRequest -Uri $uri

Does this to address your question?
 
Last edited:
jaydeel said:
Sorry for being unclear.

All settings/requirements below the $post_to_BI_logfile_flg = line are moot if the line is $post_to_BI_logfile_flg = $false

I've attempted to signal this by indenting the code under this line. For clarity, I'll edit the comments to make this more explicit in the next version.

By the way, here's the code that uses the above mentioned settings. Maybe this will clarify the logic.
Code: 
    # Remove incompatible substrings from $MsgStr
    $MsgStr = $MsgStr -Replace "`n", "" -Replace "\\r", "" -Replace "\\n", ""

    $bi_address = $script:bi_webserver
    if ($script:post_w_creds_flg) {
        $uri = "http://$bi_address/admin?log=$MsgStr&level=$Level&user=$script:bi_user_name&pw=$script:bi_user_pw"
    } else {
        $uri = "http://$bi_address/admin?log=$MsgStr&level=$Level"
    }
    $result = Invoke-WebRequest -Uri $uri

Does this to address your question?
Click to expand...
I'm not sure that I asked the question clearly: is it a must to disable the secure webserver option when enabling the BI Pushover logging function (in all cases)?
 
You must log in or register to reply here.
Top Bottom