Heya. Have you added both drivers from the folder in git?
Yeah I have.
Do I need to make Virtual Devices with them ?
Edit: I deleted both drivers and copied them again from GitHub and Iām not seeing the error now 
Nope the app creates the devices. That error is because the connect app cannot find the Squeezebox Player driver it needs to create the players. If you look at the "Drivers Code" page on your hub which drivers do you see in the "xap" namespace?
1 Like
Good stuff. 
1 Like
Yeah, all working now.
Many thanks 
1 Like
I've made a minor update to the app and driver. The HTTP request timeout is now 60 seconds. I had noticed that sometimes my LMS service doesn't respond within the default timeout so this change reduces the number of associated errors.
1 Like
Any chance of adding this to HPM? Thanks for the great work nevertheless!
Done 
Squeezebox Connect is now available in Hubitat Package Manager
You can find it by searching for "Squeezebox" (current version is 1.0)
1 Like
I am happy to announce version 2.0 of Squeezebox Connect. I have rewritten the player communication to use the the CLI interface (over Telnet). The main advantage of this is no more polling.
There is a new device (Squeezebox Server) which is managed by the app and maintains a Telnet connection to the server over which it can send commands but also receive updates on changes. This should have a far lower requirement on hub resources whilst at the same time giving immediate updates on player status changes.
The players now report the track information using the correct trackData JSON attribute. This should mean that dashboard support for things like album art works properly (I've confirmed this works with SharpTools.io)
The Squeezebox Server device should automatically reconnect if there are issues with communication to the service. I have exposed the Initialize and Send Msg commands on the device. It's an advanced use case but, if you want to, you can use these to force a reconnect or to send your own CLI commands to the service via this device. Be wary of sending messages that can change the subscription, it will probably stop the integration from getting the updates it needs. However, you can always re-Initialize if that happens. For documentation on the things you can do via the CLI interface check out the help on your Squeezebox Server web app (help -> Technical Information -> The Logitech Media Server Command Line Interface)
I have tested it but please let me know if there are any bugs and I'll stomp them as quick as I can.
4 Likes
I strongly recommend using Hubitat Package Manager to install this update. Although if you want to manually update the app and drivers you can. Just make sure you install all three drivers (Squeezebox Server, Squeezebox Player and Squeezebox Player Child Switch).
Thank-you for this wonderful integration, I use it extensively. You mention that version 2.0 will install a new device, I have a ton of RM rules that involve initiating a custom action with the player (mostly play fav1, setlevel, playtrackatvolume, etc...), should these all still work after updating to 2.0?
Yup, all the commands are there except for the speakArtistAlbums action which was a bit of a gimmick and is gone.
EDIT: Just to clarify, all the player devices are still there and should still work fine with existing automations, the new device driver is just to allow Telnet communication with the LMS server.
I've made a couple of other minor updates. You can now switch the Squeezebox Server device on/off. This is useful if you want to shut down your LMS server and don't want the device to be trying to reconnect.
I've done a couple more fixes. Please update to latest if you've already updated to v2.
Latest version now handles notifications of track changes whilst listening to a radio stream.
1 Like
@xap, bringing this back to the main thread... the whole on/off thing is still unclear to me. I simply turn off the squeeze player device in rules, etc. Not had a need for the child device to do so. I understand your useage case, which is different, using voice commands. However, mostly what I'm trying to cut down on is unnecessary 'poling' given the new CLI integration. I've got rules turning off the client devices, but wonder if that's changing the HE's need to hear back from the LMS? I also see a on/off for the squeezebox server new device, can you speak to what that's for?, doesnt' seem to change anything other than the "connected" status on the squeeze server device. Is that what I should be turning on/off instead of each device for my purpose? i.e. when I shut down the LMS every night, should I turn off the squeezebox server device as a "good housekeeping" activity or am I... confused?
No probs. I'll try to explain better:
The integration has an app and three device types:
Squeezebox Server Device - The app creates exactly one of these. It is responsible for connecting to the LMS server. It maintains a single lightweight connection which is used to send player commands and subscribe to status change updates from LMS. There is no longer any polling in the integration. If the connection drops (e.g. you update the plugins on LMS and it restarts) then the Squeezebox Server device will automatically try to reconnect, if that fails it will carry on trying to reconnect every minute until it succeeds. If you're just using LMS normally then you should be able to pretty much ignore this device. But, if you are shutting down LMS deliberately, then you can switch this device off to stop it trying to reconnect whilst LMS is shutdown. Then after starting LMS again you can switch the Squeezebox Server device back on so that it reconnects.
Squeezebox Player Device - The app creates one of these for each player. You can fully control the player (including switching it on/off) using this device. You don't need to disable or switch off these devices to reduce polling any more. There is only network traffic if something changes (e.g. a new track starts playing).
Squeezebox Player Child Switch Device - Each player can create up to two of these (you configure this when setting the players up in the app). If you want to be able to control the player alarms with automations (e.g. switch off your morning alarm clock when you're on holiday) then it can create an All Alarms switch to allow you to do that. The other switch a player can create is basically a copy of the player's on/off function. The only reason you might need this is if you want to add the player to Google Home and you want it just to be a switch instead of how Google Home normally sees a music player which is as a light (I guess because the music player properties include 'level' so Google thinks it's a dimmable light). In this case you add the child switch to Google Home instead of the player itself.
Does that help?
1 Like
yup, even I understand now! Appreciate the explanation... I guess LMS users are generally getting a little long in the tooth, can't be many survivors left... Speaking for this old brain, three versions of on/off got the better of me. I'm all set now. 
2 Likes
I still use squeeze box a lot. I love it!
I've just released a new version (v2.1) of the Player device driver. I've added support for the AudioVolume capability. This makes it easier to control the volume up or down from automations.
