Snapcast Binding

Add-ons Bindings
,
1

Hey Guys

I have been working on a binding for Snapcast https://github.com/badaix/snapcast if anyone finds this interesting please check it out and leave a comment on how to improve it.

Features:

  • Manually add the Snapcast server using Paper UI
  • Discover all Snapcast clients
  • Control volume, stream, mute and name

available channels are:

items.conf example:

Switch mute { channel="snapcast:snapclient:0242ac110003:mute" }
Number volume { channel="snapcast:snapclient:0242ac110003:volume" }
String stream { channel="snapcast:snapclient:0242ac110003:stream" }

Binding can be downloaded here: https://github.com/ssoerensen/openhab2-addons/releases/tag/2.1.0

UPDATED:
volume channel is no longer a number, this have been changed to a Dimmer
Dimmer volume { channel=“snapcast:snapclient:0242ac110003:volume” }

3 Likes
2

I’ll try this, this weekend!

I’m using snapcast/mopidy pi-clients since 3,4 months…

very cool!

th@nx

3

Hi Steffen,

thanks for the snapcast binding. It sounds very promissing and I’m really looking forward seing it in action.

Since today I have a working snapcast setup, which I can control via its Android app. Unfortunately when trying to us your binding I manage to configure a snapserver but it stays offline. I see the following in openhab logs:

2017-04-17 14:09:36.489 [INFO ] [.JsonRpcEventClient$ConnectionThread] - Connecting to control server localhost:1705…
2017-04-17 14:09:36.495 [INFO ] [.JsonRpcEventClient$ConnectionThread] - Connected to control server localhost:1705
2017-04-17 14:09:43.590 [INFO ] [cast.internal.rpc.JsonRpcEventClient] - Send request to server: {“id”:590261825,“method”:“Server.GetStatus”,“jsonrpc”:“2.0”}
2017-04-17 14:09:43.877 [INFO ] [.JsonRpcEventClient$ConnectionThread] - Received message: {“id”:590261825,“jsonrpc”:“2.0”,“result”:{“server”:{“groups”:[{“clients”:[{“config”:{“instance”:1,“latency”:0,“name”:"",“volume”:{“muted”:false,“percent”:16}},“connected”:true,“host”:{“arch”:“x86_64”,“ip”:“192.168.1.182”,“mac”:“14:da:e9:68:57:ab”,“name”:“htpc”,“os”:“Ubuntu 14.04.5 LTS”},“id”:“14:da:e9:68:57:ab”,“lastSeen”:{“sec”:1492430983,“usec”:575907},“snapclient”:{“name”:“Snapclient”,“protocolVersion”:2,“version”:“0.11.1”}},{“config”:{“instance”:1,“latency”:0,“name”:"",“volume”:{“muted”:false,“percent”:26}},“connected”:true,“host”:{“arch”:“armv6l”,“ip”:“192.168.1.199”,“mac”:“80:1f:02:a1:8e:61”,“name”:“PlayerBad”,“os”:“Raspbian GNU/Linux 8.0 (jessie)”},“id”:“80:1f:02:a1:8e:61”,“lastSeen”:{“sec”:1492430983,“usec”:656243},“snapclient”:{“name”:“Snapclient”,“protocolVersion”:2,“version”:“0.11.1”}}],“id”:“85f6e13f-af92-3e32-8fd1-2e298831b675”,“muted”:false,“name”:"",“stream_id”:“default”}],“server”:{“host”:{“arch”:“armv7l”,“ip”:"",“mac”:"",“name”:“doorpi”,“os”:“Raspbian GNU/Linux 8.0 (jessie)”},“snapserver”:{“controlProtocolVersion”:1,“name”:“Snapserver”,“protocolVersion”:1,“version”:“0.11.1”}},“streams”:[{“id”:“default”,“status”:“playing”,“uri”:{“fragment”:"",“host”:"",“path”:"/tmp/snapfifo",“query”:{“buffer_ms”:“20”,“codec”:“flac”,“name”:“default”,“sampleformat”:“48000:16:2”},“raw”:“pipe:///tmp/snapfifo?name=default”,“scheme”:“pipe”}}]}}}

Am I missing a maybe manual step or should the Thing for snapserver just become online, like I’m expecting?

Thanks in advance!
Tom

4

Hi

First i am very glad to get feedback on the binding.

I’m not sure what could be causing this problem. The Snapserver should come online after you have added it as a Thing. I will look into the problem later today.

5

Ok, i have looked into the issue, it appears that you are using a never version then I. I will install the never version at test it out.

6

Thanks for having a look. Let me know if I can help you with testing a new version or anything else.

7

So i have fixed the json protocol compatibility. How ever the new protocol is what i think, a bit of a mess:

The old protocol had the following important elements:

  • Streams
  • Clients
    • Client.setVolume
    • Client.setMute
    • Client.setStream

However the new new version implements groups. This means the following:

Client.setMute have been removed and is now Group.setMute, and a single stream is assigned to a group, not a client. I Hope you guys could give me some feedback on this issue. the way i see it is simply ignore the client and look at a group as a client. meaning setting volume on a group will also change volume on all clients in that group. To me it makes no sense to have groups of clients in OpenHAB. If you guys have any suggesting i would like to hear about them.
.

8

It’s nice to hear that you are working on groups support. As far as I understood you are planning to allow volume changes of groups only, right? However, 80% of the time I’m opening up SnapClient on my phone is to change the volume of a single client. I think that this is a very important use-case and should also be possible with the OpenHAB binding.

9

Yes, i’m working on getting the group support going. However I am a little puzzled on how to proceed. the way i see it, is two ways of doing it:

  1. Simply do a 1 to 1 one mapping of the json api, and let each user deal with
  2. Try to make it more “OpenHAB” compatible.

There are pros and cons with each method:

  • PRO: it will follow the Snapcast development.
  • CON: To me the group thing doesn’t really make any sense in a OpenHAB environment
  • CON: It does not follow then Snapcast development
  • PRO: It will create some consequences and weird behavior if used with the Snapcast Android App

However the more i think about, I’m learning towards option one, implementing the following channels and settings

Client:

  • channel: Type: Text - Name
  • channel: Type: Dimmer - Volume
  • channel: Type: String - Group

Group:

  • channel: Type: Dimmer - Volume (Affects the whole group)
  • channel: Type: Signed Integer - Relative Volume (Affects the whole group)
  • channel: Type: String - Stream
  • channel: Type: String - Clients, comma separated list of clients ids (mac addresses)

Even though the rule and sitemap setup would be more advanced with real group management, i guess this could be helped with some great examples

10

I’m also a fan of option one. The mapping you suggest is totally reasonable. I think that makes sense. The clients string of a group is read-only I guess and for information purposes only, right?

11

The Group client String will be writable, this will make it a lot easier, if someone would prefer to use a multi select box for assigning clients to a group

12

Any progress ? Thank you for your job.

13

Hi @ssoerensen,
I came across your snapcast binding yesterday. I think it‘s a great idea and start and would like to add to it in the next few days. Are you still actively working on it?

Kind regards,
Simon

14

Hi @SymanK

I would like to start working on it again. however it is stranded for now. But feel free to fork or submit a pull request. When i get some time my plan is start replacing the protocol code, in order to support complete able futures instead of the current way of communicating.

15

Unfortunally the binding is not working for me. I added the Snapserver as a thing and I also see that it is working somehow, but I do not see any Snapclients in the Inbox, also I see the Snapserver thing as OFFLINE - HANDLER_REGISTERING_ERROR.

2018-01-24 16:01:47.752 [INFO ] [.JsonRpcEventClient$ConnectionThread] - Connecting to control server 192.168.0.3:1705...
2018-01-24 16:01:47.754 [INFO ] [.JsonRpcEventClient$ConnectionThread] - Connected to control server 192.168.0.3:1705

Is the binding working at all or are there just some problems? At least I did not find this problem in the thread, so I am posting it anyway. :wink:

16

Good morning,

I’m interested in a snapcast binding and also in development for openhab in general. So I decide to try writing an binding.

The result can be found here: https://github.com/StbX/openhab2-addons/releases/tag/snapcast-20181031
More infos are available in the README

I’ve mostly ignored the snapcast groups. If I want to change the stream of an client, which is in a group with other clients, the other clients are removed from the group. So I have only a server and a client thing.

Special thanks to @ssoerensen for the inspiration :slight_smile:

17

@StbX That is awesome, however i tried it out and got the following warning in the logs:

2019-02-09 14:12:04.780 [WARN ] [re.thing.internal.ThingFactoryHelper] - Could not create channel 'volume' for thing type 'snapcast:client:Snapcast:1e1fdb08-6f00-4663-a78c-2498f26693ff', because channel type 'system:volume' could not be fo
und.
2019-02-09 14:12:04.789 [WARN ] [re.thing.internal.ThingFactoryHelper] - Could not create channel 'mute' for thing type 'snapcast:client:Snapcast:1e1fdb08-6f00-4663-a78c-2498f26693ff', because channel type 'system:mute' could not be found.

Is it a old version of Openhab or is there something that i’m missing?

18

Are you already using OpenHAB 2.4?
afaik the system channel types for volume and mute are new in this Version.

19

yeah, but clearing cache and manually configuring the things solved the problem. it all works as described :slight_smile:

20

Hi all,

i’ve updated the binding for the new release 2.5.0.

The result is available at: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.snapcast/2.5.0-SNAPSHOT/

And there is also a pull-request: https://github.com/openhab/openhab2-addons/pull/4189