I just upgraded my OH installation to the release build of 2.1.
After the upgrade I noticed two errors in the log file. One had to do with album art, the other with line in.
After a bit of research I found post that suggest to remove the SONOS things and to re-add them to remove the covert art errors as there had been updates made to the binding. I deleted and re-added the things and the cover art errors disappeared. I am still getting the following errors in regards to LINE IN.
2017-10-10 18:24:26.114 [ERROR] [.io.transport.upnp.UpnpIOServiceImpl] - Participant threw an exception onValueReceived
java.lang.IllegalArgumentException: Channel with ID 'linein' does not exists.
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.isLinked(BaseThingHandler.java:573)[110:org.eclipse.smarthome.core.thing:0.9.0.b5]
at org.eclipse.smarthome.binding.sonos.handler.ZonePlayerHandler.updateChannel(ZonePlayerHandler.java:547)[191:org.eclipse.smarthome.binding.sonos:0.9.0.b5]
at org.eclipse.smarthome.binding.sonos.handler.ZonePlayerHandler.onValueReceived(ZonePlayerHandler.java:450)[191:org.eclipse.smarthome.binding.sonos:0.9.0.b5]
at org.eclipse.smarthome.io.transport.upnp.UpnpIOServiceImpl$UpnpSubscriptionCallback.eventReceived(UpnpIOServiceImpl.java:144)[192:org.eclipse.smarthome.io.transport.upnp:0.9.0.b5]
at org.jupnp.controlpoint.SubscriptionCallback$2.eventReceived(SubscriptionCallback.java:222)[167:org.jupnp:2.2.0]
at org.jupnp.model.gena.RemoteGENASubscription.receive(RemoteGENASubscription.java:114)[167:org.jupnp:2.2.0]
at org.jupnp.protocol.sync.ReceivingEvent$2.run(ReceivingEvent.java:130)[167:org.jupnp:2.2.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)[:1.8.0_144]
at java.lang.Thread.run(Unknown Source)[:1.8.0_144]
No, not all boxes have a line in. It us only one type that has that feature and a special connection box.
In that case the binding youhave used must have had the channel. The actual binding is missing the channel, hence the error.
Another thing to look for, there might be different things for boxes with line in, are you boxes discovered to the type or only just Sonos boxes? I’m away from my system and can’t.
You could try with channel ID “playlinein” instead of “linein” as stated in the doc (http://docs.openhab.org/addons/bindings/sonos/readme.html ). It works for me.
“linein” was the name of the status variable in the old OpenHAB 1 binding.
What’s weird is that all of my boxes (connect,playbar, play, zp80, zp100) all have line in…and the channels have all been built automagically when I installed the binding. I had no issues until I upgraded to OH 2.1 and then began to notice this error and the album art error. The album art error was simple to resolve. Delete all of the things and then let PaperUI discover and add back in.
I never manually created any items or channels/things…so this had to come from the discovery of the things.
My boxes are all discovered as the particular items that they are.
The channel linein exists but only for Sonos things that have a physical line-in. The strange thing is your things Sonos Media Room and Sonos Office which are linked to the unknown Sonos thing type. What are your Sonos model behind these things ? Were they discovered with this thing type by the binding or is it an error when you declared your thing in a config file ?
The Zone Player thing type has mo linein channel. So the problem is cerainly with your old ZP100.
A solution would be to define your things for ZP80 and ZP100 in a config file with right thing types.
At the same time, we should try to find what’s wrong in our discovery code leading to the use of the default thing type.
2017-10-07 09:30:06.490 [ERROR] [.io.transport.upnp.UpnpIOServiceImpl] - Participant threw an exception onValueReceived
java.lang.IllegalArgumentException: Channel with ID 'tuneinstationid' does not exists.
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.isLinked(BaseThingHandler.java:571) [108:org.eclipse.smarthome.core.thing:0.9.0.201709260841]
at org.eclipse.smarthome.binding.sonos.internal.handler.ZonePlayerHandler.updateChannel(ZonePlayerHandler.java:574) [186:org.eclipse.smarthome.binding.sonos:0.9.0.201709260841]
at org.eclipse.smarthome.binding.sonos.internal.handler.ZonePlayerHandler.onValueReceived(ZonePlayerHandler.java:525) [186:org.eclipse.smarthome.binding.sonos:0.9.0.201709260841]
at org.eclipse.smarthome.binding.sonos.internal.handler.ZonePlayerHandler.updateMediaInformation(ZonePlayerHandler.java:1063) [186:org.eclipse.smarthome.binding.sonos:0.9.0.201709260841]
at org.eclipse.smarthome.binding.sonos.internal.handler.ZonePlayerHandler.onValueReceived(ZonePlayerHandler.java:410) [186:org.eclipse.smarthome.binding.sonos:0.9.0.201709260841]
at org.eclipse.smarthome.io.transport.upnp.UpnpIOServiceImpl$UpnpSubscriptionCallback.eventReceived(UpnpIOServiceImpl.java:144) [188:org.eclipse.smarthome.io.transport.upnp:0.9.0.201709260841]
at org.jupnp.controlpoint.SubscriptionCallback$2.eventReceived(SubscriptionCallback.java:222) [164:org.jupnp:2.2.0]
at org.jupnp.model.gena.RemoteGENASubscription.receive(RemoteGENASubscription.java:114) [164:org.jupnp:2.2.0]
at org.jupnp.protocol.sync.ReceivingEvent$2.run(ReceivingEvent.java:130) [164:org.jupnp:2.2.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Extract from device_description.xml of my two Sonos devices:
