@sasha_jpr You’re missing the requests module:
Hi - just checked this (in hope) - but not i:
openHab2:/etc/openhab2$ sudo apt-get install python-requests
Reading package lists... Done
Building dependency tree
Reading state information... Done
**python-requests is already the newest version.**
python-requests set to manually installed.
I followed the instructions to auth the app,
Went through the html page and got the status change from red to green, with a message “New Auth Code successfully saved to OpenHab”
If I use the karaf console to check item values, I get:
openhab> smarthome:items list | grep AQ
spotify_auth_code (Type=StringItem, State=[xxxxxxxxxxxxxx]
and
openhab> smarthome:items list | grep spotify_clie
spotify_client_id (Type=StringItem, State=[xxxxxxxxxxxx], Label=null, Category=null)
spotify_client_secret (Type=StringItem, State=[xxxxxxxx]
all with the valid params populated
I am using RR4DJ for persistence, since it was quick and easy to setup - could this have something to do with it?
======================= MORE INFO ========================
When I look at the auth page URL after authentication, I get the uri: http://192.168.0.168:8080/static/spotify-auth.html?code=AQAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
in the Auth code field one the HTML page however, it tells me the auth code is QA… (no A at the start)
checking my params in the karaf console, I see
openhab> smarthome:items list | grep AQ
spotify_auth_code (Type=StringItem, State=AQA9 again.
bug perhaps?
Could you reset (empty) your item states and try again?
Sure - here’s what I currently have
spotify_forceupadte (Type=SwitchItem, State=NULL, Label=null, Category=null)
spotify_auth_code (Type=StringItem, State=xxx
spotify_client_id (Type=StringItem, State=xxx, Label=null, Ca
spotify_client_secret (Type=StringItem, State=xxx, Label=null
spotify_access_token (Type=StringItem, State=xxx
spotify_refresh_token (Type=StringItem, State=NULL, Label=RefreshToken, Category=null)
spotify_token_expiry (Type=StringItem, State=NULL, Label=TokenExpiry, Category=null)
spotify_token_issued (Type=DateTimeItem, State=NULL, Label=TokenIssued, Category=null)
spotify_current_track (Type=StringItem, State=NULL, Label=null, Category=null)
spotify_current_artist (Type=StringItem, State=NULL, Label=null, Category=null)
spotify_current_cover (Type=StringItem, State=NULL, Label=null, Category=null)
spotify_current_duration (Type=StringItem, State=NULL, Label=null, Category=null)
spotify_current_progress (Type=StringItem, State=NULL, Label=null, Category=null)
spotify_current_progress_percent (Type=NumberItem, State=NULL, Label=null, Category=null)
spotify_current_playing (Type=SwitchItem, State=NULL, Label=null, Category=null)
spotify_current_context_uri (Type=StringItem, State=NULL, Label=null, Category=null)
spotify_current_device (Type=StringItem, State=NULL, Label=null, Category=null)
spotify_current_device_id (Type=StringItem, State=NULL, Label=null, Category=null)
spotify_current_volume (Type=NumberItem, State=NULL, Label=null, Category=null)
spotify_action (Type=StringItem, State=NULL, Label=null, Category=null)
spotify_lastConnectionDateTime (Type=DateTimeItem, State=2017-09-01T14:28:05.000+0100, Lab
spotify_device_list (Type=StringItem, State=NULL, Label=null, Category=null)
openhab>
I’ll blank everything, regen the App in Spotify Dev again and update you:
Update code:
openhab> smarthome:update spotify_access_token
Usage: smarthome:update <item> <state> - sends a status update for an item
openhab> smarthome:update spotify_access_token empty
Update has been sent successfully.
openhab> smarthome:update spotify_client_id empty
Update has been sent successfully.
openhab> smarthome:update spotify_client_secret empty
Update has been sent successfully.
openhab> smarthome:update spotify_auth_code empty
Update has been sent successfully.
openhab>
and from rest:
{"link":"http://192.168.0.168:8080/rest/items/spotify_auth_code","state":"empty","type":"String","name":"spotify_auth_code","tags":[],"groupNames":[]}
Looks like the state is now the string “empty”. It should be NULL.
OK - was doing exactly as I was told earlier (perhaps I should have used some sense)
Anyway, continuing
{"link":"http://192.168.0.168:8080/rest/items/spotify_auth_code","state":"NULL","type":"String","name":"spotify_auth_code","tags":[],"groupNames":[]}
QQ - Docs say:
Save the Client ID to spotify_client_id in OpenHab (e.g. through openhab CLI smarthome:update spotify_client_id {your_id})
Copy the Client Secret to spotify_client_secret in OpenHab (e.g. through the rest API)
I assume doing the following in karaf is ok?
openhab> smarthome:update spotify_client_id xyz123
Update has been sent successfully.
openhab> smarthome:update spotify_client_secret xyzabc
Update has been sent successfully.
Yep, and now re-auth the app
Oh FFS.
I am so sorry for wasting your time - went through this a THIRD time . . .and realised I’d missed one little thing:
> Set the REDIRECT_URI in spotify.py to the right value
Got a feeling I may have overwritten my original edit and then not changed it again
For anyone else who gets this:
– Calling Token Refresh Service
CaseInsensitiveDict({‘content-length’: ‘69’, ‘keep-alive’: ‘timeout=600’, ‘server’: ‘nginx’, ‘connection’: ‘keep-alive’, ‘date’: ‘Fri, 01 Sep 2017 13:22:52 GMT’, ‘content-type’: ‘application/json’})
{u’error_description’: u’Invalid refresh token’, u’error’: u’invalid_grant’}
Please make VERY sure that you’ve updated spotify.py
Issue resolved - thanks for your time - no doubt, you’ll hear from me again!
No worries!
Thanks again.
2 quick questions:
- How often do the Spotify items get updated?
- Have you implemented the code above to allow device selection?
Device selection is implemented already.
It’s up to you how often you want to update. Right now it’s on demand. I will try a suggestion to auto update while HabPanel is open when I have time.
Coolios,
In my case I want to autoupdate regularly, since I have Amazon echo all over the house running Spotify . . but when someone launches music via the voice command on alexa, I want to trap this and redirect the music to a dedicated Spotify client (re purposed Android TV device, plugged into several AV receivers around the house)
Workflow runs like this:
Spotify.py detects device change
if (device.match(“Kitchen Echo”)){
Make music in kitchen
} else if (device.match(“Loft Echo”)){
Make music in loft
}
The $1million is what happens when I am playing spotify to a Group
But these are my worries
Super work - thanks again!
I’ll sort through the .py code for now - but according to: GitHub - pmpkk/openhab_spotify-webconnect-api: A simple Python script to integrate Spotify's Web Connect API (https://developer.spotify.com/web-api/web-api-connect-endpoint-reference/) to OpenHab (openhab.org) the only current params are:
Use
spotify.py
parameters:
none = refresh data
play = resume playing
play uri = play suported uris (album, artist or playlist), e.g. spotify:user:spotify:playlist:37i9dQZF1DX5OepaGriAIm
pause = pause
next = next track
previous = previous track
volume_up = 10% up
volume_down = 10% down
The doc was outdated. Fixed now.
Please note that the transfer of playback from one device to another works by setting the openhab item to the right id and then calling “transfer_playback”.
Thanks,
Tested, works if I set spotify_current_device_id
and execute:
vanwyks@openHab2:/etc/openhab2/rules$ sudo /usr/bin/python /etc/openhab2/scripts/spotify.py transfer_playback
Fails if I set spotify_current_device and execute code above (no probs, I can work around this - I suspect the array containing device to device_id mappings is not getting updated.
I have a small feature request…
Are you able to retrieve whether the current track is tagged as “Explicit” so I can skip these during hours where the kids are downstairs?
Thanks again for all the help - huge progress today
How would you suggest I set this up to constantly update? cron job?
Correct, right now it only works by setting id. I haven’t merged the fuzzy search code in. Since the number of devices doesn’t change often and it’s easy to update the list of ids, I think this covers most use cases.
Good one re “explicit”. It should be possible but it may actually already be a setting inside Spotify. Did you check?
Yes, cron job, but again ponían Spotify API every 5 minutes around the clock seems exesssive.
Yes, cron job, but again ponían Spotify API every 5 minutes around the clock seems exesssive.
I was thinking more like every 5 seconds!
Shame there’s not mqtt type setup for the spotify data…
Yeah, every 5s sounds good IF music is playing … but not all day long.
What I did was just make a new IFTTT for my google echo which passes on the argument. So I say “Hey google spotify [args]” it runs spotify.py [args]. So say I want to play spotify using my pc speakers I’ll say “Hey Google spotify play PC”, which then runs spotify.py play PC. I’ts a bit awkward and you have to set up a rule to handle all the different commands. With Alex your have to have something like “Alexa turn on bathroom beats”, with custom rules, etc. If spotify is already playing then I just need to say “hey google spotify play/pause” and it will use the current device rather than the device receiving the command.
It would be really cool/amazing if we could access the media player commands for alexa/google to modify or create your own media player that is device sensitive, etc. I have seen a few things about this recently but not sure on the progress.
Hi,
I’ve set up a simple switch which can be managed by Alexa (if I want) - I then run the .py regularly (every 10 seconds)
If someone starts anything using the echo ON the echo, within 10 seconds, a spotify update runs, identifies that the incorrect source is being used and then takes ownership of that spotify track - shifting the spotify to the correct target device (if the AV receiver that should be playing is not on, it also handles powering that up, changing to the correct source and shifting to the correct default volume)
The up (and down) side, is that my wife and children are now also able to drive the music in the house, without my ceiling mounted echo dot having to play tinny music, when I have a bucket load of proper AV gear around the house, waiting to be used.