Use stack-in-card instead of vertical-stack. That allows you create vertical and horizontal stacks where the button cards have no gaps and look like one single card. This is what I use for most of my UI to give it a more clean look.
Hello dear people…i have been reading the original post and scrolling till 2021. I am quite confuse to which is the working iteration now on the current HA version.
I got a google home mini and interested in streaming tunein or other radio to the mini. I don’t have a Spotify account. If anyone can point me to the right direction please?
Thanks
Not sure if this is the right forum, but would it be possible to use the same setup for TV-stations? I want to see live TV on my chromecast with a list of tv stations, like SVT1, TV4 etc (Swedish).
And here is an example how the media_content_id needs to be set:
(PS. Did not check if people have set the extra.title, but here is an example for that aswell. it will show the title in non-audio chrome cast devices and so on…)
(PPS media_content_type is music, as documentation suggests. Don’t know why OP had string there)
media_content_id: >
{% if is_state("input_select.radio_station", "City") %}{% set url = "https://stream.bauermedia.fi/radiocity/radiocity_64.aac" %}
{% elif is_state("input_select.radio_station", "Nostalgia") %}{% set url = "https://stream.bauermedia.fi/nostalgia/nostalgia_64.aac" %}
{% elif is_state("input_select.radio_station", "Radio Rock") %}{% set url = "https://supla.digitacdn.net/live/_definst_/supla/radiorock/playlist.m3u8" %}
{% endif %}
{% if "Sonos" in states("input_select.chromecast_radio") %}x-rincon-mp3radio://{{url.split("://")[1]}}
{% else %}{{url}}
{% endif %}
media_content_type: music
extra:
title: "{{ states('input_select.radio_station') }}"
Sonos uses the scheme x-rincon-mp3radio instead of http/https. All my streams work with https and http, so I’m not sure if sonos actually plays https streams.
Thanks for sharing your code with specific reference to how to tackle different URL for Sonos and chromecast which works perfectly fine. I’m using the script to serve multiple rooms. For that purpose I wish to store the currently selected station for each room such that once I return to the specific room selection menu, it defaults to the currently selected/played music station. In principle it’s the reverse of the selection procedure:
- platform: template
sensors:
radio_select_sonos:
value_template: >-
{% if is_state_attr('media_player.office', 'media_content_id', "x-rincon-mp3radio://https://21223.live.streamtheworld.com:443/SKYRADIO.mp3") %}
Sky Radio
........
{% endif %}
This all works fine for my google chromecast devices which return the stream URL as specified. For SONOS, the situation is different. The above station returns a URL which is totally different from what was entered and moreover not consistent in what it returns. In case of the above URL, SONOS returns on the command:
{{state_attr('media_player.office', 'media_content_id')}} the following URL which differs every time:
x-rincon-mp3radio://https://21283.live.streamtheworld.com:443/SRGSTR01.mp3
As stated, this URL is not consistent and changes very time the station is selected such that it would be impossible to store the currently selected station for the specific room.
Have you ever come across this phenomena and know how to overcome.
For chromecasts the urls should look like https://example.com and for sonos x-rincon-mp3radio://example.com. I see you are checking the state for x-rincon-mp3radio://https://example.com.
That shouldn’t work for either of the devices. Maybe try to figure out what the media_content_id for the devices are in the developer tools. Select the entity there and see what the url is. For me the Sonos has what I have set it. Anyways, I think you should read the state to a variable first and then just check if it contains the some part that is after the scheme for example:
{% set mediaIdOffice = state_attr('media_player.office', 'media_content_id') %}
{% if "SKYRADIO.mp3" in mediaIdOffice %}
Sky Radio
........
{% endif %}
Thanks a lot for putting me on a progressive trail. My URL’s specific to chromecast and sonos respectively are consistent with what you quoted in your response. Your proposed solution based on identifying string with {% if "SKYRADIO.mp3" in mediaIdOffice %} based on ‘media_content_id’ works fine for SONOS.
For chromecast using the Beosound Core, the content of ‘media_content_id’ is not always consistent and sometimes results in { {url}} response instead of the stream URL. However, I figured out that consistently and in all cases, the selected station name is being stored in ‘media_content_id’ and subsequently used instead using your if “contains-string” concept. Thanks a lot.
What I noticed though is that once changing room selection, though it defaults properly to the selected (currently running) radio station, it’s not a bumpless transfer. In other words, it reloads the currently played radio station URL. This looks obvious since one trigger is ‘input_select.radio_station’. I have tried to implement a value_template condition which, once true, will only continue with the action which contains the media_content_id’s.
To avoid a reload of the stream URL, the condition checks whether the result of the ‘mediaIdOffice’ is un-equal to ‘input_select.radio_station’ in which case fire ‘action’, otherwise stop.
If the above makes sense and you have a suggestion, I would appreciate yr feedback.
But I have several ways to initiate playback on my devices. And if I use any other method than this Lovelace card, I’d like to make an automation that automatically populates this card, so that it shows the chosen settings independently of how it was initiated.
I know that it is possible to set the input.select value in a script. My problem is that if I do, it automatically also triggers the automation behind the card - just as if I had made a manual selection. This in turn again triggers the script, and I’m in a never ending loop.
So, I’m looking for a clever way to populate the on-screen display, without actually triggering the automation.
Any ideas, anyone?
Well yes and no.
No because it’s honestly quite time consuming to set up, and no because any update to the html/page layout will result in the scrape sensor no longer working.
The yes part would only be “valid” if you’re able to provide a link to a json page from the radio as this is less likely to break/fail.
Sorry can’t help you there. Not all radios post the info in json.
What you’re looking for is a URL that posts information like this example
Then you can fairly easily extract the data. What you don’t want is to scrape the HTML as it will require maintenance at some stage.