I actually meant had I not been able to set up my phone as a device on the hub at all. As I've not used pushover, and it looks like a cloud dependent service, I wondered if it was on the cloud account that you set up your phone details rather than on the reluctant hub. Though now I have finally got my phone onto the hub, the question is not so pressing.
I think I understand what you mean, but I may not have explained what I was trying to clearly enough.
The way to "setup your phone" so that the hub knows you have the mobile app downloaded onto it (and could use it for presence sensing and notifications if you choose), and the way to "setup your phone" so that that pushover messages from the hub, are completely unrelated. You could use one, the other, or both depending on your needs.
Not sure if this helps, and perhaps it's moot at this point, but here's a screenshot from my hub's device list. I have one iPhone XS but it's two different virtual devices on the hub. One was created by the hub for the mobile app, the other was created by the hub for the pushover notification. Ignore that sleep sensor in between the two 
.
Ok I see what you mean... but... if the hub didn't want to set up my phone for presence sensing, would it also have the same disinterest in setting up my phone for a Pushover device? Or is there some stage in setting up Pushover that I can force the phone onto it? 
1 Like
Yeah I think I see what you’re asking, although the short answer is probably “I’m not sure,” or “it depends.”
My guess is if the hub has never been registered with portal.hubitat.com (as I believe you said yours was not initially?), then neither the mobile app nor pushover will work as intended?
Yes I realised that once I was knowingly adding cloud-based features I'd obviously have to register the hub for the cloud. Just wanted to make sure things were not unexpectedly using the cloud when they had no need
to, like some systems 
1 Like
Makes sense!
It’s been a while since I’ve looked at some of these topics, but people have noticed in the past the hub appears to be hard-coded to check an NTP server in the cloud. There’s a couple ways to work around that though.
1 Like
Interesting! Thank you!
1 Like
@TMLeafs: Steven, am I missing something obvious. I switched my Pushover device from the Hubitat standard version to yours above in the hope of using parameterized sounds. When I go into the device details page of my TMLeafs-modified pushover device, and type the above into "Device Notification", I receive the title, the message and the prioritization, per usual, but still no sound. I've been sitting here playing with options on the pushover app, but no joy. My volume is up on my iOS device, and volume works on other apps.
I'm stumped--any suggestions?
What priority are you using?
I’ve tried [H], [E], and nothing. No joy.
Can you post an example of your message so I can test it myself
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...
2 Likes
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
