Same error here as well.
See attached pics.
Thanks, that's one issue for sure. The other is how the whole library/bundle thing works in Hubitat. I'd been reusing the same library, since that's what makes sense, but you can't put a library on HPM... you have to use a "bundle". The issue with that is if you have the library already installed, the the bundle install silently fails and just does nothing. It won't update the library contained within the bundle as far as I can see.
Hubitat REALLY needs to have the ability to directly update a library file, just like apps and drivers do, so HPM can use that rather than this bundle nonsense.
There is another way to "publish" files on Hubitat, and you can use it to update libraries directly, however it requires knowing the "id" for the library (it's in the URL when you're viewing the library file on your Hubitat).
I'm looking at the various options to avoid more issues with HPM, but I think it's mostly down to "can't update bundle if the library within is already installed and used by other apps/drivers".
3 Likes
Welcome back to development... 
Mostly in a good way,,,
Alright, I've got a working self-update feature that I can release. However, it requires opening the 2 libraries to note the "id" for each (from the URL).
There doesn't seem to be any way around having to manually ask the end-user for the 2 IDs, as I don't see these exposed programmatically anywhere. However, by adding the 2 IDs to the Sonos Advanced app 'main page', it allows the app to "publish" the updates to the libraries directly, bypassing the whole "bundle" thing, using the same method the VS Code "Hubitat Developer" add-on uses to publish libraries.
For the app/driver, it doesn't need this and can self-update using the same method HPM does.
So far I've got this working:
What does everyone here think? Would needing to snag the 2 IDs for the 2 libraries be too much?
Testing this on my end seems to work pretty well. It'll schedule daily/weekly update checks, allow for scheduling auto-updates to occur at a specific time (and day of week, if weekly). It checks that the versions installed are correct, and allows updating them if they're out of sync, and it even checks the libraries versions directly and "publishes" them to update them as well.
It does entirely go around the whole HPM thing, but, well, that's sorta the point, since HPM stumbles on updating this app.
1 Like
Does @csteele have a view on this?
Another option I'm considering is just dropping the bundle and the library, and updating the GitHub Action pipelines to instead just concatenate the existing library straight to the end of each file, right before putting it into the "release". This way there's no libraries at all anymore, no bundles. I can still use "libraries" on my end, and they just get concatenated straight to the end of the files, which is as best I can tell, what happens internally on Hubitat when you put the
#include dwinks.UtilitiesAndLoggingLibrary line in the file
Seems that HPM rarely has trouble on the plain app and driver files. The concern I have with this would be more around the migration from one version that includes the bundle (with separate libraries) to the next version that has them appended to the end of each file on the GHA pipeline. I'd obviously need to strip out all the header bits on the library as well, but that's just library( a bunch of text here... ) so it would be trivial to have it pull out the "library definition block" during the pipeline run.
I have my old C7 set up for doing some testing on, but testing "will this break updating via HPM" pretty much requires publishing said version to HPM.
1 Like
Still interested in @csteele 's input, but interesting findings...
I think I'm joining this at the aft end and don't understand... sorry. 
HPM doesn't do anything with Bundles other than push them to a Hub. How the zip is handled is entirely Platform dependent. It the Libraries are not getting updated then that's a Platform question, I presume. 
On the other hand, I do have a poor reaction to Libraries. I have yet to see their value in a product. I see plenty of value in the development of a product via libraries. I just don't see the advantage of pushing the managing of Libraries onto users. I have one library myself, one that contains a fist full of Debug options that simplifies some of my development. However, it's not included in any of my Packages, and won't ever be included.
In the short term (since a Platform update is weeks into the future, at best) merging Libraries onto the end of an app or driver seems a solid path to explore. OR... a PR to add a Library option to HPM.
1 Like
Yeah, I think I'll just update my GitHub Actions pipeline to merge the library code in before it's sent to the release, then remove the bundle from the manifest.
As for the value, it lets me put a bunch of reusable stuff into the library that I can then use elsewhere, and only have to maintain it once. If I make an improvement to the library code, it improves it on everything that uses it. I've got a bunch of "helpers" in my library that lets me work around the @CompileStatic limitations in regard to things like accessing state, calling stuff like runIn() etc. Yes, the little helper/wrappers themselves lack @CompileStatic, and using them means the functions with @CompileStatic that include them don't have true static compilation validation, but it does let me force the rest of that function to properly compile at publish-time, which catches quite a few errors that would otherwise be occurring at run-time.
That said, the present state of how Hubitat handles Libraries (and the lack of being able to update them via stuff like HPM), makes it onerous to use for sure.
1 Like
That's exactly why I say Libraries are ideal for Developers, not users. And it's not just Hubitat's libraries. I'd say every OS that has Libraries suffer. Be it Windows or Linux, Libraries are too often NOT able to be updated and a system will end up with 27 vintages of a Library. The oldest used by treasured software that will never be updated to the newest, released hours ago.
2 Likes
0.7.14 Updated without issue.
1 Like
Me too
OK, posted 0.7.16 here:
Should install without issues on HPM, had to fix some bundle related stuff, and make sure I had the right library included on the GHA pipeline.
For anyone not using HPM, or having issues with HPM, there's also some auto-update/self-update stuff added to the App. It may require manually updating the app code at the very least, and possible the 'utilitiesAndLoggingLibrary' to get the self-update to work, assuming you can't use HPM.
6 Likes
Good to see you working on this again.
I use this app daily on Hubitat, and I appreciate you going through my GitHub issues and knocking out the fixes. Also cool to see you using AI to streamline things.
I just installed it and look forward to giving it a spin. Thanks for all your hard work you put into this.
5 Likes
Added mDNS discovery (in parallel with the original SSDP) to the Sonos Advanced App when doing device discovery. Put a few extra checks in place to hopefully reduce the occurrence of duplicates showing up in "Discovery" for the same speaker.
Also added small, medium, and large album art URLs to the "player" device attributes, for use in dashboards. Similarly added 'audioSource'.
7 Likes
Welcome back @daniel.winks l Is there a list of what is working and what is not?
Also, not having much luck with playing local media connected to my Sonos.
Thanks
Ken
Hi @KenJohnston. I tasked AI with making a 'list of issues' based off this post, and it did a quite solid job. Last weekend I was able to work through most of them, so at this point most of the issues should hopefully be resolved/better.
What's the specific issue you're having with local media? First, I'd check to make sure that there's not an issue playing it when using the Sonos app on your phone/computer, to rule out it being a Sonos issue. I don't have a lot of local media, but I haven't run into any issues with it myself. My local media is set to scan for updates every day at 2AM:
That's from the MacOS app... I can't find this setting on the iOS app.
My local folder is also on a little mini "server" running TrueNAS.
Assuming there's no issues playing it via the Sonos app, then see if you can get some more info on the exact issue you're having. It's a lot easier narrowing things down the more detailed and precise the info I get is.
Various 'sources' for Sonos content have some extra album art URLs. This update covers a wonky "let's concatenate 3 or 4 URLS together" format that JRiver uses. Apple Music and a few others just seem to send 1 bigger version, which is handled here too.
If anyone has a music provider that has some unique album art URL format that isn't getting picked up and processed into the "album art small/medium/large" URLs properly, feel free to let me know and I can add a few lines in the driver to handle that format too.
The other change on this release compared to previous are some improvements on the TTS queuing feature.
Previously it would just queue normal messages and a high priority 'audioClip' (whether that's TTS or just some other file) would dump the queue and play. This update adds 2 more 'queues' in the driver, one for high priority messages, so sending multiple in a row will also queue now, and a second new queue for "saved queue state" for the normal priority. Now when a high priority audioClip arrives, it saves the queue state, plays the high priority one, and restores the normal queue after.
If there's any further tweaks or fixes that could be made to the normal/high audioClip (TTS) handling, please let me know. That said, I've noted a (likely un-fixable) issue where, sometimes, rarely, if you send some audioClips to multiple speakers that one of the speakers will just fail to "wake up" and do anything with it, and then possibly hours later it "wakes up" and processes its queue, spitting out 1 or more queued audioClips.
I think this is a Hubitat platform issue, because as best I've been able to tell, it's just what it seems, the driver isn't 'waking up' when it should, and what controls that is outside of what I can control. It's being told to 'wake up', and most of the time it does. If the issue were on my end and I wasn't waking the driver properly, it would just never work. That's not the case, it usually (like 99% or more) of the time does wake the driver, the driver processes the audioClip queue, and that's that. So I don't think I can fix that issue, sadly.
5 Likes
OK, first "big" release in a long time:
The "group devices" are now full-fledged "music players" in Hubitat. They have all the same commands, attributes, etc that the 'coordinator' speaker does. So you can add the group device to dashboards and it works like any other "music player", with play/pause, skip, volume, etc.
You can 'loadFavorite' on a group device and it'll start up playing on whatever coordinator you have set for that group (and all the members, if they're joined).
Also adds "nextTrackAlbumArtURI" which displays the album art for the next track in queue (for music providers that provide it, of course). This does the same thing that "albumArtURI" does presently, but for the next track rather than current. It's available on both the "player" and "group" devices.
10 Likes
This would make sense with what I have witnessed as well. It random when it happens but you get them all at once.
