Pushover Notifications Driver [Slightly Enhanced]

Seems to be working for me. I just switched from the standard to your driver. Did a test in webcore.

Sent "This is a test #bugle#" and I got the message with the bugle sound. I just setup a rule in RM to see if that worked, don't see why it wouldn't. Nice work thank you.

Didn't try any priority yet.

1 Like

I'm using literally "[H] ^My Title^ My Message #bike#", but without the double quotes of course in the Device Notification field on the device details page of my modified pushover device. One other thing I noticed today (which sorry I should have mentioned up-front): if I remove the DND setting and deactivate silent mode from my IOS phone, the sound comes through fine. But I have DND on or silent mode on, the message won't break through, even if [E]. Huh?

You have to enable the "Critical Alerts" feature within the Pushover Application's settings menu on your iPhone.

Update: Here are the details from Pushover...

https://blog.pushover.net/posts/2020/2/ios-critical-alerts

2 Likes

You are The Man. That was exactly my mistake. Thank you and @TMLeafs so much!!!

1 Like

Is it possible to embed a toggle switch inside of a pushover notification.

ie. "The alarm is triggered, select [disarm] or [dial 911]

Some talk of it in this thread.

Then my take on it using the join api driver.

@tmleafs - Thank you for your additions to this driver. I have incorporated your changes, along with another request from @jpoeppelman1 to allow for [HTML] formatted messages. I have updated the first post with additional instructions for the use of these features.

5 Likes

That's great will included driver be updated on next firmware change?

I don't work for Hubitat, and I am doubtful that anyone from the team is watching this thread. Hubitat did use my original driver as a starting point for their built-in version. I am not sure if they made other changes to it.

We could ask Hubitat to incorporate these additional features into the platform, however it would probably be wise to run them as-is for a while to make sure no issues are found after extended testing. Thoughts?

5 Likes

Have you thought about adding it to the Hubitat package manager? Makes it much easier to keep up with updates.

I really like the recent updates, the sounds especially. It's a great driver and I appreciate the work, but I don't imagine it's high on the HE team's list of things to keep updated.

1 Like

Interesting idea, however Hubitat Support already has their hands full enough... It might be quite confusing for them if a large number of users all of the sudden started having Pushover device issues, and it was caused by this custom driver instead of the built-in driver. For those who really want the extra functionality, it is trivial to add this driver to their system. It only recently received any updates, and I have no plans to change it again any time soon (except for bug fixes caused by this latest set of enhancements.) Personally, I use the built-in in Pushover Driver on my Production hub. :wink:

2 Likes

Just curious

I am using the Title and the notification sound and it is working very well.

Even with the different titles all notifications are still under the hubitat folder in pushover.

Is there anyway to separate the messages into different folders?

Sounds like a question for Pushover themselves, as I don't believe the message has any way to influence how the Pushover App on your phone sorts the messages.

1 Like

Thanks Dan,

I kind of assumed this but thought i would ask just to be sure.

1 Like

I just switched over from ST to HE this week. It's been pretty good, except for a few differences such as making scenes and groups. Otherwise a smooth transition.

My automations setup in WebCore for ST made use of SMS notification and by using a global variable and index, I could select which "phoneNumber" to send the message. So, in effect, if a presence device name 'myname' left, I could match 'myname' to @SMS_number and pick out say the 2nd in the list and the SMS would be sent to that phone only. I could then use general PUSH notifications to send to everyone. In addition, I would use Tasker's SMS read ability along with 'Say' task to have it speak the SMS messages from 'Smartthings' (in contacts) so that when whoever was driving it would go through the BT in vehicle and be read.

However, since HE no longer supports SMS, then I starting reaching out for solutions to mimic the method above. I did come to the same conclusion using Pushover, as suggested in this post: create multiple devices and put those device name is a Global variable that is indexed and pull out the matching on and then send notification to that device.

But then it effectively makes for poor automation to execute something like when you want to say {'Welcome Home'+@PO-myname} and also send a group notification to all members, such as, {@PO-myname left the house at $time} and so on. You have to create a virtual PO-device for each member and in preferences select the Device Name. Then make another virtual device say, PO-All, and select all devices or leave blank.

It would be super fantastic awesome if somehow the automation could pass the variable (device name) to HE hub app and have it select the 'Device Name' where the notification would be sent. Then you could have that variable indexed and the HE app would know which device to send it to 'automagically'.

Not sure how much would be involved in that from developer side, but I'd be willing to pay per device-name for such a feature.

** Note: I did find where PO-Tasker integration supports PO variables and can be filtered based on priority. So, I can have tasker 'say' [H] notifications only.

I was just looking over this post in more depth and seems like the adopted HE pushover driver has the Notification Sound as a drop-down selection that is fixed assigned to the virtual device. But the driver in this post shows it being utilized as a #sound# variable. So, wouldn't stand to reason that the device name drop-down could be addressed as such a variable, say %myphone%?

Ok, so its a hack, but I was just to curious. So, I looked at the driver in this post, added it to HE and saw where the #sound# is matched and piggy-backed on that existing variable changing the sound to deviceName:

if(customSound){ sound = customSound}
if(customSound){ deviceName = customSound}

So, in WebCore I can now address the device using a variable:

{"testing directed device notification"+ "#"+PO_device+"#"}

Now, I'm not really sure in the driver what other characters the 'if((matcher' routine will accept.

Cool..

"Its easy to be a hack, when someone smarter has developed the actual ground to plant new trees."

Driver mod:

    if((matcher = message =~ /\*(.*?)\*/)){               
        message = message.minus("*${matcher[0][1]}*")      
        message = message.trim() //trim any whitespace
        customDevice = matcher[0][1]
        customDevice = customDevice.toLowerCase()      
    }
    if(customDevice){ deviceName = customDevice}

Webcore:

define string PO_device = '*myphone*';
.
.
do 
      send device notification "{{"testing alert notification "+PO_device+" #bike#"}}";

This is working really nicely, thanks all! Tested and seems to send a message reliably, High priority also works well.

Question - I'm not sure I get the point of the ^title^ feature. Can anyone enlighten me?

When I send this

[H]^WARNING^ - Its %time% and the %device% has turned %value%

What I see on the SMS is a high priority like this

^WARNING^ - Its 11:29 AM and the Kitchen - Freezer has turned OFF

That's fine and all, but whats the point of the ^^?

Thanks for your contribution, @s1godfrey. I have added your addition to the version in my GitHub repository.

1 Like

Download the Hubitat app