@daniel.winks Thanks for turning the manifest fix around so quickly. I can confirm `apps[0].name` is now "Shelly Bluetooth Helper" in the 2.17.6 manifest and matches the `definition()` ā but the HPM install still fails identically, and I think I've worked out why my original report pointed you at the wrong thing. Sorry about that. Same disclosures as before: I'm fairly new to Hubitat and had help from an AI assistant reading through the code, but everything below is from my own hub.
### 1. The real install failure is being hidden by an HPM bug (not yours)
The NPE isn't in your package ā it's in HPM's rollback, and it destroys the error message that would tell us what actually went wrong. In `Package_Manager.groovy`, the update path does this:
```groovy
for (bundle in manifest.bundles) {
def location = getItemDownloadLocation(bundle)
if (!installBundle(location)) { return rollback(...) }
else
completedActions\["bundleInstalls"\] << bundleToInstall // loop var is \`bundle\`
}
```
`bundleToInstall` belongs to the install/modify flows and is never assigned during an update, so a null is pushed. Then in `rollback()`:
```groovy
for (installedBundle in completedActions["bundleInstalls"])
uninstallBundle(installedBundle.name) // line 4325 -> NPE on null
```
So for any package that contains a bundle, if anything fails during an update, rollback dies on that null and the real reason is swallowed. That matches my log exactly ā "Upgrading Shelly Bluetooth Helper", then "Fatal error occurred, rolling back", then `NullPointerException: Cannot get property 'name' on null object on line 4325 (method performUpdates)`. The underlying `upgradeApp` returned false, but its message never surfaced. I'll report that one to the HPM maintainers separately; flagging it here mainly because it means neither of us can see the true failure until it's fixed.
For what it's worth I ruled out the usual suspects: Hub Login Security was off, 243 MB free memory, all 69 file URLs in the 2.17.6 manifest return 200, and the installed Bluetooth Helper (v2.17.4) differs from v2.17.6 by only the version comment line ā so there's nothing obviously wrong with the app being upgraded.
### 2. Library 2.17.6 needs a driver that isn't in the package
To get moving I imported the library bundle directly via Bundles ā Import ZIP, bypassing HPM. That leaves me in a split state ā library v2.17.6 with v2.17.4 drivers ā so please discount this if it doesn't reproduce on a clean install. But the manifest gap looks real regardless.
`ShellyUSA.ShellyUSA_Driver_Library.groovy` v2.17.6 line 5344, in `createChildVoltmeter()`:
```groovy
String driverName = "Shelly Autoconf Voltmeter"
```
v2.17.4 has no reference to that name. I searched all 67 drivers in the 2.17.6 Webhook/Websocket manifest and there's no Voltmeter driver in it, so nothing in the package can satisfy that lookup. My Shelly Plus Uni (which has an analog voltmeter input for a rainwater tank level sensor) logs `Rainwater Tank: Shelly Autoconf Voltmeter driver not found` on every attempt. The "Shelly Autoconf" prefix is Device Manager naming rather than this project's, which made me wonder whether some code moved across between the two projects.
### 3. NumberFormatException on the voltmeter value
Alongside the above, every reading throws:
```
java.lang.NumberFormatException: For input string: "0.68"
```
0.68 is the voltmeter reading in volts. Over a 4-minute log capture I get this every ~60s (my report interval), plus a burst every ~90s of seven "Preference retrieved from child device (counts / in_locked / freq_rep_thr / xcounts / count_rep_thr / freq_window / xfreq) does not have config available in device driver" warnings followed by the driver-not-found error and a "Connection reset" ā 28 error/warn lines in 240 seconds. Net effect is that the tank voltage never reaches Hubitat. It looks like the same class of problem as issue #98 (Shelly Flood Gen4 NumberFormatException), so possibly one shared fix.
### Environment
Hubitat C-7, platform 2.5.1.174. Shelly Plus Uni, `SNSN-0043X`, firmware 2.0.0, driver "Shelly Plus Uni (Websocket)" v2.17.4, library v2.17.6 (hand-imported). I'm rolling the library back to 2.17.4 for now to get a consistent install.
Happy to test any of this ā the device is easy for me to power off and on, so I can reproduce on demand. And thanks again for the quick fixes yesterday; the paginated webhook discovery sorted out my 2PM Gen4 nicely.
