Closed stephenmetzger closed 2 years ago
parautenbach
commented
2 years ago Could you try e.g. MQTT Explorer (Mac app) or mosquitto_sub from the command line by connecting to your MQTT broker to check the topics for activity?
There was also an API change (with HA 2021.12) to use coroutines for MQTT calls in the integrations code which I still need to check out. Not sure if it's related.
stephenmetzger
commented
2 years ago @parautenbach, thanks for the quick response. Yes, I’ve opened up MQTT.fx to listen for messages. Nothing comes through on any mini-media-play button presses, but I set up an events-all node in nodered, to listen to what happens on button presses and it is sending call_service events, so as a temp fix I may map those to mqtt_pubs.
parautenbach
commented
2 years ago So if I follow, this is when you hit the buttons on the HA side, e.g. to change tracks?
Now, on the other side: When you're casting (e.g. from your iPhone to your Shairport Sync instance), and change tracks/volume from the controlling device, do you see those messages/updates in MQTT.fx?
stephenmetzger
commented
2 years ago Correct. Buttons on the HA side do not work to control SPS playback and also do not show up as published messages on my MQTT broker.
Play/Pause, volume changes, track forward and backwards from the controlling device do show up as messages on my MQTT broker.
I've developed a nodered flow as a workaround for now. It monitors for the call_service event that is produced by button presses in the media_player on the HA side, and converts them to MQTT commands. This is working well. In fact, I implemented some additional functionality: pressing the power button on the media_player card sends a sudo systemctl restart shairport-sync command to the device running SPS, which stops playback to that device and (when using AirPlay 2 multi-speaker it stops playback to that device and removes it from the 'group' without disrupting playback to other speakers that were part of that group - nice!), and also clears the album art, artist, and track information which makes the media_player card go blank rather than retaining the info from the last played track - which I like.
The flow can be found here if anyone else is having the same issue that I am:
Easy enough to disable the flow if/when this issue is addressed.
Thanks!
parautenbach
commented
2 years ago stephenmetzger
commented
2 years ago Ahh. Thanks for this. Fixable?
parautenbach
commented
2 years ago Yup, just testing the new release via HACS. See v1.1.0.
parautenbach
commented
2 years ago Ok, it all looks good. Let me know if it doesn't work for you.
stephenmetzger
commented
2 years ago Thanks! All is working now except for one thing: the pause button will pause a currently playing SPS stream, but the button on the HA side stays as the pause icon, and pressing again wont resume playback.
Looks like SPS offers MQTT commands for: pause, play, and playpause. Possible to use "playpause" rather than pause or play, if the HA-side button has trouble with states and cant tell which command to send?
parautenbach
commented
2 years ago I think this may be due to this HA bug (I got this and I'm running this versions): https://github.com/home-assistant/frontend/issues/11039#issuecomment-100230973. I want to hang on and see what happens here first.
I need to remember, but I think the reason I opted for the current implementation was that I wanted the state to show on media players. If I use playpause the button will always be the play button. Maybe I can make this a config option.
parautenbach
commented
2 years ago I've observed two other things before:
After hitting e.g. play on the HA site (and hence publishing it to the MQTT topic), it can take a few seconds before the subscription topic is updated with the state.
The other has to do with initialisation: I took the shortcut of assuming an initial idle state, assuming the user will first interact with SPS from their device after which this media player will receive the correct state. I guess I can read, on startup, the LTW and ensure the states are synced.
stephenmetzger
commented
2 years ago You are right. I was being impatient. Play/Pause control on HA side does eventually update to the correct state and allows control once properly updated. I assume you use the active_end or play_end command for this, which takes a few seconds to get published once a pause is triggered.
Thanks for everything!
parautenbach
commented
2 years ago That's it exactly. I suppose I can just immediately update the state, but thought it's better to wait and reflect the state as "echoed" back. :-)
You're welcome! Glad things are working again for you.
stephenmetzger
commented
2 years ago No need change, this implementation is better. would it be difficult to add an mqtt pub function to send blank payloads to /cover, /artist, and /title on the play_end/active_end trigger to get the media player to clear those fields?
parautenbach
commented
2 years ago That came up before. The issue is that active_end and play_end always seem to appear together. It seems the intent in SPS is to distinguish between play/pause vs connect/disconnect behaviours, but in reality doesn't work like that. If I implement this, if you pause, the cover would disappear, when I think one would rather only want this to happen when disconnecting. Also see https://github.com/parautenbach/hass-shairport-sync/issues/5#issuecomment-893753212.
If this media player had an on/off state, I could clear it when switched off. In my case, I have a smart plug connected to the device (hence the note on the universal media player in the README). I decided to keep that functionality separate, as not everyone might have my same setup (rather than making providing a smart switch an optional config entry). I suppose I can still do the latter (then again, if one uses state with the built-in media card or the 3rd party mini media card, it already reverts to a default background).
stephenmetzger
commented
2 years ago Thanks for explaining. This makes sense. No problem, I can implement my own metadata clearing, no need to integrate it as a standard feature. Thanks again.
P.S. Where is your "Buy Me a Coffee"/ "Donate" link? I like to donate to small projects like this to show my appreciation. Your next beer, or coffee, should be on me!
parautenbach
commented
2 years ago Where is your "Buy Me a Coffee"/ "Donate" link? I like to donate to small projects like this to show my appreciation. Your next beer, or coffee, should be on me!
Much appreciated! I added one now.
stephenmetzger
commented
2 years ago Thanks! Your next few drinks are on me! Happy new year!
parautenbach
commented
2 years ago That is very kind of you, thank you.
Hello, and thank you for your work on this project.
I have the integration loaded, and am getting track information (including album art) working great. However, none of the controls on the mini-media-player UI are working (i.e., play/pause, skip tracks, volume). I have "remote" enabled in my shairport-sync.conf file, and publishing payloads like "play", "nextitem", "volumedown" to my defined topic works to control shairport-sync playback.
I'm running shairport-sync version 4.0-dev-312-g687fd167-AirPlay2-OpenSSL-Avahi-ALSA-soxr-metadata-mqtt-dbus-sysconfdir:/etc, which is a dev version with AirPlay2 support.
I'm not seeing any logs in home assistant when I use the buttons on the mini-media_player card, and nothing is getting published to the topic for the associated SPS instance.
Is there any further configuration needed to set up remote commands from SPS to home assistant media_player? Alternatively, any way to manually map each media_player buttons to a specific call_service?
Thanks, and happy holidays!