v1.6.1 — Chromecast control inside the binding (no rules needed)

v1.6.1 — Chromecast control inside the binding

No rules, no proxy items and no JavaScript Scripting add-on needed any more.

Binding

• Chromecast routing built in: Pause / Play / Stop go through player#playback-state; the binding finds the items of the selected Chromecast through their channel links and controls it directly.
• New channels player#volume and player#mute: they control the selected Chromecast and mirror its real volume / mute back, including changes made in the Google Home app (about every 2 s).
• Reliable start: new tracks go straight to the Chromecast's playuri item. If the Chromecast first had to launch its cast app, the URL is resent after 5 s.
• Automatic thing update: existing things get the new channels on start-up (thing update instructions); the obsolete my-playlists channel is removed.
• playUriItem is now an advanced option and empty by default.

Widgets

• soundcloud_nowplaying uses volumeItem / muteItem and playback-state instead of the SC_CC_* proxy items.

Upgrade from v1.5.x

1. Remove the old JAR from addons/, copy in org.openhab.binding.soundcloud-1.6.1.jar. If a thing stays UNINITIALIZED, disable and re-enable it once.
2. Create and link items for player#volume and player#mute; set them as volumeItem / muteItem in the widget.
3. Clear the thing parameter playUriItem (advanced settings).
4. Re-import the widget from this release (soundcloud_search has been retired).
5. Disable the router rule and the auto-play rule. The SC_CC_* proxy items are no longer used.

Full setup: see the README.

v1.5.7 — Auto-play in binding, Stop keeps track, HLS seek fix, now-playing widget

v1.5.7

Binding

• Auto-play built in: every newly loaded track (search result, next / previous, playlist, repeat, auto-advance) is sent to the selected Chromecast by the binding itself. The auto-play rule is no longer needed — disable it, otherwise each track is sent twice.
• New thing parameter playUriItem (default SC_CC_PlayURI): the item that receives stream URLs for the selected Chromecast (new tracks and seek).
• Stop keeps the track: title, cover and queue stay; Play after Stop restarts the track with a fresh stream URL.
• Seek fixed for HLS streams: the seek proxy now sends CORS headers and serves application/vnd.apple.mpegurl under /soundcloud/seek/seek.m3u8. The Chromecast receiver rejected the playlist before, so seeking stayed silent.
• No hard-coded IP fallback any more — openHAB's own address is used if the redirect URI cannot be parsed.

Widgets & rules

• New widget soundcloud_nowplaying.yaml: background follows the cover colours, scrolling title, search panel (Enter searches, tap a result to play), seekable progress bar, queue position, Chromecast chips.
• Router rule (openhab-conf/rules/soundcloud_chromecast_router.js) finds the Chromecast items by itself — no per-device mapping. It also forwards SC_CC_PlayURI and resends the URL once after 5 s if the Chromecast only launched its cast app.

Upgrade

1. Remove the old org.openhab.binding.soundcloud-*.jar from addons/, then copy org.openhab.binding.soundcloud-1.5.7.jar in.
2. Create the proxy item String SC_CC_PlayURI if you don't have it, and add it as an Item Command trigger to the router rule.
3. Replace the router rule script with the new version and disable the auto-play rule.
4. If a thing stays UNINITIALIZED after swapping the JAR, disable and re-enable it once.

See the README for details.

v1.5.4

v1.5.4

• Removed experimental My Playlists browse feature (unreliable SoundCloud API endpoint)
• Removed Playlist URL input field from widget
• Playlist queue (load by numeric ID) remains fully functional
• Shuffle and Repeat modes unaffected

v1.5.3 - My Playlists fix

Fixes

• search#my-playlists channel is no longer read-only — REFRESH commands now reach the binding handler

efreshChannels() now also triggers loadMyPlaylistsAsync() so playlists reload on any REFRESH event (e.g. when a new item link is created)

• Playlist data is loaded on Thing ONLINE and on every REFRESH, ensuring the widget always shows up-to-date playlists

v1.5.2 - My Playlists

What's New

Widget

• My Playlists section: shows your SoundCloud playlists as a clickable list (visible when \myPlaylistsItem\ prop is configured)
• Tap a playlist to load it into the queue — cover art, title and track count shown
• Playlist URL input field retained for manual entry (visible when \playlistIdItem\ prop is set)

Binding

• New channel \search#my-playlists\ (String, read-only): JSON array of the authenticated user's playlists [{id, title, trackCount, artwork}, …]\
• Playlists are loaded automatically when the Thing goes ONLINE; send any command to \search#my-playlists\ to refresh
• \SoundCloudApiClient.getMyPlaylists(): fetches up to 50 playlists via \GET /me/playlists\
• \SoundCloudApiClient.resolveIdFromUrl(): resolves soundcloud.com playlist URLs to numeric IDs

Widget Setup

New prop	Item type	Channel
\myPlaylistsItem\	String	\search#my-playlists\
\playlistIdItem\	String	\player#playlist-id\

v1.5.1 - Playlist URL Input

What's New

Widget

• Added playlist input field below the search box (visible when \playlistIdItem\ prop is configured)
• Accepts full SoundCloud playlist URLs (e.g. \https://soundcloud.com/user/sets/my-playlist\) or numeric IDs

Binding

• \SoundCloudApiClient: new
  esolveIdFromUrl()\ method resolves SoundCloud URLs to numeric IDs via the api-v2 /resolve\ endpoint
• \SoundCloudHandler: URL detection in \playlist-id\ channel — URLs are resolved automatically before loading

Widget Setup

Set the new \playlistIdItem\ prop to a String Item linked to \player#playlist-id\ (e.g. \SoundCloud2_Playlist_ID).
Paste a SoundCloud playlist URL or numeric ID into the input field and press Send.

v1.5.0 — Playlist Queue, Repeat & Shuffle

What's New in v1.5.0

Playlist Queue

• Loading a playlist now loads all tracks into a queue (previously only the first track was played)
• Loading a single track still works exactly as before — it creates a one-item queue

Navigation

• Next / Previous track: send NEXT or PREVIOUS to the player#playback-state channel
• Widget now has ⏮ Previous and ⏭ Next buttons alongside Play / Pause / Stop

Auto-Advance

• When a track ends, the binding automatically plays the next track in the queue (no rule needed)

Repeat Modes

• New player#repeat channel: OFF (default) → PLAYLIST → TRACK
• OFF — no repeat; queue stops at the last track
• PLAYLIST — loops back to the first track after the last one
• TRACK — repeats the current track indefinitely
• Widget repeat button cycles through all three modes with a single tap

Shuffle

• New player#shuffle channel (Switch)
• Randomises playback order within the queue; the current track stays at position 0 in the shuffled order
• Widget shuffle button toggles on/off with visual highlight

Track Counter

• Widget shows current position / total (e.g. 3 / 12) next to the track title when queue has more than one track

New Channels

Channel	Type	R/W	Description
player#queue-index	Number	R	Current position in queue (1-based)
player#queue-size	Number	R	Total tracks in queue
player#repeat	String	RW	Repeat mode: OFF / TRACK / PLAYLIST
player#shuffle	Switch	RW	Shuffle queue order

New Items (optional)

Number SC_QueueIndex  { channel="soundcloud:account:myaccount:player#queue-index" }
Number SC_QueueSize   { channel="soundcloud:account:myaccount:player#queue-size" }
String SC_Repeat      { channel="soundcloud:account:myaccount:player#repeat" }
Switch SC_Shuffle     { channel="soundcloud:account:myaccount:player#shuffle" }

Upgrade

1. Replace org.openhab.binding.soundcloud-1.4.10.jar with org.openhab.binding.soundcloud-1.5.0.jar in your openHAB addons/ folder
2. openHAB detects the update automatically — no restart needed
3. The new channels appear on the existing Thing automatically
4. Update the widget from soundcloud_search.yaml in this release to get the new buttons

Files

• org.openhab.binding.soundcloud-1.5.0.jar — binding JAR
• soundcloud_search.yaml — updated widget

v1.4.10 - Seek via progressive MP3 + HTTP Range

v1.4.10 — Seek via progressive MP3 + HTTP Range Request

Problem (v1.4.9)

SoundCloud HLS streams use fMP4 (.m4s segments, #EXT-X-VERSION:7), which Chromecast Audio Group cannot play — resulting in no audio after seeking.

Fix

Seeking now works via the progressive MP3 URL:

• Byte offset = seconds x 16000 (128 kbps CBR)
• The seek proxy sends a Range: bytes=N- request to SoundCloud
• Chromecast loads a fresh MP3 stream from that byte — decoder syncs automatically

Changes

• SoundCloudSeekServlet: type=mp3 delivers Range-Request + audio/mpeg stream; type=hls kept as fallback
• SoundCloudHandler: handleSeek() uses currentProgressiveUrl with &type=mp3
• SoundCloudApiClient: resolveProgressiveUrlV2() resolves the progressive URL alongside the HLS URL

v1.4.9 - Seek via SC_CC_PlayURI routing

v1.4.9 — Seek via SC_CC_PlayURI routing

Problem (v1.4.8)

After a Thing restart, currentChromecastTarget was null, causing both slider and seek buttons to stop working entirely.

Fix

Seek commands are now routed through the SC_CC_PlayURI item via the Router Rule, eliminating the dependency on currentChromecastTarget.

Changes

• handleSeek() sends the proxy URL to SC_CC_PlayURI instead of using currentChromecastTarget directly
• extractOrigin() helper added to derive the server base URL from redirectUri
• Router Rule updated: trigger t5 on SC_CC_PlayURI and playuri field added to MAPPING

v1.4.8 - HLS seek proxy

v1.4.8 — HLS seek proxy

Introduced the seek proxy servlet at /soundcloud/seek that parses the SoundCloud HLS m3u8 playlist and returns a trimmed version starting from the requested time offset. Chromecast loads the modified playlist and starts playback from the correct segment.

Note: this approach only works when fMP4 HLS is supported by the Chromecast target. See v1.4.10 for the progressive MP3 fix.