Send Pushover notifications with pictures and hyperlinks

[sebastiantombs]

I've been running for a couple of days with the API, push and email notifications. The API has been consistently faster than push or email. I think that is a problem more related to the providers and what kind of load they may be seeing more than anything else. I just shut down push and email notifications and will rely on PushOver and the API script from now on. Much cleaner and simpler to me anyway. As with everything YMMV.

 

[jaydeel]

For some reason the UI3 portion doesn't work right for me and I tried changing WAN to LAN in both instances. How much of this would I need to eliminate to take that part out - is it this part:
<a href='&WAN/alerts/&ALERT_DB?fulljpeg'>Hi-Res</a> <a href='&WAN/ui3.htm?rec=&ALERT_DB'>UI3</a>"

Perhaps the &ALERT_DB macro is returning null... Suggesting confirming that it is returning a good value by using the msg.exe 'trick' described in post #10.

More to keep in mind ... per Ken
"... the @DB offset is a physical address in the file. If the file is compacted (which happens each night at 2am by default) this would invalidate the offset if anything in the DB file is moved. The software automatically adjusts stored DB locators throughout."

I asked him about this when I noticed that some of my PushOver UI3 links seemed to have a shelf-life.

Deleting hi-res images in the ALERTS folder may also cause this; I need to test this.
EDIT: Not the case. High-res *.jpgs are being deleted regularly because I've limited the size of this folder.
(This just happened while I was testing the UI3 link in a pushover message.)

 

[wittaj]

Yeah, I was shocked that the API was not faster than the generic pushover email.

I am going to test it some more as I haven't implemented this full scale yet, so maybe in the short time I was trying, their email system was just as quick. It just seems to me that the email adds another layer of delay.

The issue I had with the UI3 command was the UI3 would pull up in a web browser my WAN, which since I do not port forward, it wouldn't open. Even when I was on the home network it would show the WAN instead of LAN even when I changed it in this script.

I manually compact the DB as the system doesn't record when that is happening and I figured 2am is a good time for perps, so I will manually do it when I have the console open and can see what is going on.

When you tried to pull the high res jpgs from the Records tab, were you doing this with the &CAM.%Y%m%d_%H%M%S%t or the &ALERT_PATH

 

[jaydeel]

When you tried to pull the high res jpgs from the Records tab, were you doing this with the &CAM.%Y%m%d_%H%M%S%t or the &ALERT_PATH

If this question is for me, I've only used &ALERT_PATH.
I've not yet experimented with the Records tab *.jpgs.

I manually compact the DB as the system doesn't record when that is happening and I figured 2am is a good time for perps, so I will manually do it when I have the console open and can see what is going on.

You may find that 2AM is not a good time if you review your pushover messages in the morning and want to use their UI3 links to view events occurring before 2AM.

 

[wittaj]

OK, so either I have a syntax error somewhere or that script cannot read the long %string for pulling from the Record tab or the API tries to run before that file is generated.

To be clear, mine does not compact at 2am. I have it disabled because perps tend to come thru here around 2am and I don't want my system compacting and not recording. I manually compact it at some point during the day when I have the console open.

 

[jaydeel]

Wow, I zoned out on that one. We’re on the same page.

I’d like to experiment with the Record tab JPEGs.
Could you share a screenshot of your Record tab?
And from what Action set are you calling the API - Trigger tab Immediate action, Alert tab ‘On alert’ action set?

 

[jrbeddow]

Have we confirmed that the default 2AM database compaction will affect our abilty to pull up images and alert videos the next day? I will be testing that tonight, deliberately leaving some Pushover alerts from this evening as unviewed until the morning. If I understood correctly, that may have been a false impression, muddled by other interactions.

 

[jaydeel]

Have we confirmed that the default 2AM database compaction will affect our abilty to pull up images and alert videos the next day?

It affects anything that uses the &ALERT_DB macro
I've verified it and changed my compact/repair schedule as a result. I've not gone totally manual like @wittag; I do it at 5:30p every other day.

I don't think you need to leave the Pushover notifications unviewed to test this.
You can view them now, before a db compact/repair, and the links work. Then again after a manual compact/repair, and the links don't work.

 

[wittaj]

Wow, I zoned out on that one. We’re on the same page.

I’d like to experiment with the Record tab JPEGs.
Could you share a screenshot of your Record tab?
And from what Action set are you calling the API - Trigger tab Immediate action, Alert tab ‘On alert’ action set?

Yeah I would like to get the Records tab to work because then we could delete the images in a short time period without messing up the alert thumbnails.

I am triggering it on the On alert action set.

Here is my record tab (it is default except for the folder where they go):

 

[jaydeel]

Thx for the screenshot.

I think the problem is that %Y%m%d_%H%M%S%t is the system time. Using it again in the pushover API results in a later timestamp than when the .jpg file is created, and thus likely pointing the curl argument to a nonexistent filename. **

You might have better luck using %Y%m%d_%H%M in both the Record tab and the curl argument. Better, but not perfect, of course, for an event occurring at the boundary of minute M & M+1.

And don’t forget the extension ‘.jpg’ in the curl argument.

** I figured this using the ‘msg.exe’ trick.

 

[wittaj]

Thx for the screenshot.

I think the problem is that %Y%m%d_%H%M%S%t is the system time. Using it again in the pushover API results in a later timestamp than when the .jpg file is created, and thus likely pointing the curl argument to a nonexistent filename. **

You might have better luck using %Y%m%d_%H%M in both the Record tab and the curl argument. Better, but not perfect, of course, for an event occurring at the boundary of minute M & M+1.

And don’t forget the extension ‘.jpg’ in the curl argument.

** I figured this using the ‘msg.exe’ trick.

You are a genius - that was it! Now we can set it up so we don't get thousands of alert images in our alerts folder.

Do it as record and then in clips and archiving set it up to delete every 30 min or 1 hour so some short period.

Now if I can figure out why the UI3 doesn't work. If I type in WAN it gives me my WAN address in the browser. If I type in LAN it give me in the browser the camera LAN not my internet LAN.

The API and email still arrive at the same time, but I have to believe the API will be better over the long run as it takes another party out of the equation.

 

[jaydeel]

Just had another idea - haven't tested it yet.

On the Record tab, use JPEG 'When alerted' and make the file template &CAM.&ALERT_DB.

in the curl argument use &CAM.&ALERT_DB.jpg

 

[jaydeel]

Hmmm… just tried a quick test.
It made a filename named ‘FE.&ALERT_DB.jpg’

 

[wittaj]

OK I figured out the issue with UI3.

For those of us doing the dual NIC, in the main Blue Iris Settings section, go to the Web Server. Then down about halfway is the Local Internet Access. This shows both NICs. Change it to the NIC that has your internet. Then when you select UI3 from the push, it will then open up the browser with the IP address of the BI machine on the internet side of the computer.

 

[wittaj]

Thx for the screenshot.

I think the problem is that %Y%m%d_%H%M%S%t is the system time. Using it again in the pushover API results in a later timestamp than when the .jpg file is created, and thus likely pointing the curl argument to a nonexistent filename. **

You might have better luck using %Y%m%d_%H%M in both the Record tab and the curl argument. Better, but not perfect, of course, for an event occurring at the boundary of minute M & M+1.

And don’t forget the extension ‘.jpg’ in the curl argument.

** I figured this using the ‘msg.exe’ trick.

OK the drawback to this method is IF the trigger happens at 59ish seconds, there is a chance that the trigger happens at the minute with 59ish seconds, but the jpg is created at the next minute and then it won't trigger.

 

[jaydeel]

Said so much better than my "Better, but not perfect, of course, for an event occurring at the boundary of minute M & M+1."

 

[jaydeel]

I'll ask Ken if &ALERT_DB can be made to made to expand when used on JPEGs in the Record tab. That would provide a unique filename.

Before I do could someone else confirm my test in post #53?

 

[wittaj]

I just tested it and it created the same as you LPRCAM.&ALERT_DB.jpg

Yeah if it could be done in the record tab or give the option under the Alerts to keep the low rez thumbnail for alert images and allow to blow the hi rez out at a different frequency would work. That is the problem, if you have BI delete the hi rez images in alerts over half hour, then you only have a half hour worth of thumbnails.

I try to keep my clips low and each HiRez image counts as a clip. I once got over 200,000 clips and the system started crawling, so I cut back how many and for how long I keep hi rez snapshots, especially since I can pull them from the video.

 

[jrbeddow]

I try to keep my clips low and each HiRez image counts as a clip. I once got over 200,000 clips and the system started crawling, so I cut back how many and for how long I keep hi rez snapshots, especially since I can pull them from the video.

Thanks, I am still fairly new at this, and was wondering about the reasons for wanting to avoid having X number of clips growing per week/month. What are the general guidelines on that point? Up to 7 days, 14 days, 30 days? Obviously no hard and fast rule, as it will depend on individual installation circumstances.

 

[wittaj]

Once upon a time, an older version said that once you got over 200,000 clips you would get a warning notice.

So even though it doesn't say that in Version 5, I know that when I got to 200,000 it got slower and was always getting warning conditions.

So I cut back what I was recording. Did I really need hi-rez alert thumbnails and hi-rez images from the record tab on every camera. NOPE....you can always play the video and stop it and snapshot it.