I do not have any plans to do so, as I do not use HPM for anything myself. I also prefer users make a truly informed decision when upgrading software, as breaking changes are sometimes necessary and they may require careful planning before just pressing an automatic upgrade button.
I’m not saying HPM is bad…just that it is not for me and thus not for my code. It only takes a few clicks inside the Hubitat code editor to pull in a new version automatically from GitHub, after reading through the release notes here in the forum.
Thank you for all your work on this driver. I hope you'll reconsider using HPM to distribute it though. There's so much information, news and noise in the forum that things can go unnoticed. HPM can notify when updates are available.
HPM has settings to disable automatic updates, and I'm pretty sure it defaults to off. Someone has to really want automatic updates (and accept the possible results) in order to pull new versions automatically.
If you do reconsider, I'm sure there are many people here who would set it up for you (including myself). The new features in HPM that make it easy to publish beta versions are really nice as well.
For those that operate a combination Hubitat-Home Assistant system, I've discovered that HA can utilize Pushover as well. I prefer it to HA's built in Notifications.
Many other IoT and monitoring services also have Pushover support, including: NodeRED, Uptime Kuma, Genmon, Frigate, Scrypted ….
It’s very convenient to create individual Notifiers for each of them.
I only wish that Pushover would either add support for Apple Carplay, or support for iOS widgets, which would make it possible to see notifications using Carplay.
Version 1.0.20260201 is now available via my GitHub repo (simply update the driver directly within the Hubitat Drivers IDE, using the three dot menu (top right) to IMPORT the latest code.)
This update comes complements of @hubitrep. The only change is the addition of the custom attribute "notificationText" which will show the last sent msg to the Pushover server. This matches the attribute used by the Hubitat Mobile Device driver for the Hubitat Mobile Phone app.
Version 1.0.20260202 is now available via my GitHub repo (simply update the driver directly within the Hubitat Drivers IDE, using the three dot menu (top right) to IMPORT the latest code.)
Minor code cleanup and some improved logic handling. No new features added. Please let me know if you have any issues.
Version 1.0.20260203 is now available via my GitHub repo (simply update the driver directly within the Hubitat Drivers IDE, using the three dot menu (top right) to IMPORT the latest code.)
Minor code cleanup and some improved logic handling. No new features added. Please let me know if you have any issues. Thank you @hubitrep for your contributions to this latest PR.
Version 1.0.20260207 is now available via my GitHub repo (simply update the driver directly within the Hubitat Drivers IDE, using the three dot menu (top right) to IMPORT the latest code.)
Decided to let Claude AI take a look at this driver code to see what bugs and or optimizations it would come up with. This latest version includes mostly code performance optimizations. There are no new features added. Please let me know if you have any issues.
A special "Thank You!" goes to @hubitrep for your contributions in testing this latest version. I really appreciate you catching an error in the caching logic that Claude suggested.
New feature available in the latest code (v1.0.20260304): emergency message acknowledgements.
There are two ways to leverage this feature:
by supplying a callback POST URL which the Pushover server calls when the emergency message is acknowledged. A default callback URL can be set in preferences or a specific one included in every message with [EM.CALLBACK=url]
by enabling emergency message acknowledgement polling (in preferences or with [EM.POLL=n]) and subscribing to the Pushover device's emergencyAck custom attribute.
A picture being worth a great many words, here is a sample RM rule leveraging the polling feature (the rule itself does nothing but log results):
The driver's polling feature is limited to a single emergency message; if a new emergency message is pushed while a previous one is still pending, the new message replaces it and its acknowledgement will be polled for instead.
The callback feature does not have this limitation as a specific callback can be specified for every message, should you need to do so, with [EM.CALLBACK=url]. The callback can be leveraged for automations to be triggered on emergency message acknowledgement, for example, by setting the URL to a MakerAPI endpoint or a Rule Machine cloud endpoint trigger.
Many thanks to @ogiewon for maintaining this driver and reviewing this PR.
Those warnings/errors appear to be related to the Emergency message enhancements added recently by @hubitrep. I have not used these features except for a few quick tests while reviewing his Pull Request. All worked well during those tests.
Hopefully @hubitrep will chime in to explain what’s happening. My guess is that the warnings are related to an unacknowledged Emergency message, after another Emergency message was sent? Just a guess…
Ok, maybe a few taps of the keyboard as well.... 
