We’ve just released 0.4.6 and are going to shift focus to our supporting cast, which includes the HACS AmpliPi plugin. I’d like to poll for community input, see what you all think we should have that we don’t.
So far we’ve been looking into how we can make automations easier to make and more useful, as well as making it so that we can integrate alongside Home Assistant’s recent official Music Assistant plugin.
So, what do you all think we should add? What should we change? What makes the current experience less than stellar? What do we already do well and should leave untouched while doing these updates? Let us know!
One thing I use the OpenHab plugin for is linking power states to certain things, so that when nothing is playing, the zones all get muted.
It’s been awhile for me since I’ve tinkered with HA, but I can say one of the major reasons I keep bouncing off it is needing to deal with HACS. If there is a way to make the pluging an actual official plugin that one doesn’t need to use HACS for, that would be a big win in my book. (Not sure that’s even doable.)
One issue that needs addressed is when a zone doesn’t belong to any source it shows as powered off and it’s not possible to control it or assign it to a source. The only option is to go into the AmpliPi’s interface and add the zone into a source, then it becomes controllable in Home Assistant.
I can share that the first thing I’ve done in our upcoming update was make the power buttons on the default HA media players disconnect zones from whatever they’re on and mute them rather than just giving you the “This doesn’t support media_player.toggle” or “This doesn’t support media_player.turn_off” messages so while you’ve got a working solution, it will make more sense in the future.
Also, I haven’t personally looked to much into how to get an official plugin but we can shoot for that. It’s also possible that we have too short a dev cycle to wait for their approval process for every AmpliPi version that would effect the HA plugin so we might be stuck with HACS for some time until we reach a 1.0 version as opposed to the 0.4.6 that we’re currently in.
A “nice to have” feature would be to leverage the system in Home Assistant to notify about new firmware releases.
I’m not entirely sure how it works, or if a HACS item can use it, but when one of my Zwave switches or Shellys has a firmware update it appears in the Updates section under Settings in Home Assistant and is very useful for seeing new releases.
I have just started playing with Music Assistant, now that they have added Spotify Connect support, and I am quite impressed.
A native player provider for AmpliPi zones in Music Assistant might be something worth looking into? Currently you can link them in via the Home Assistant media player entities but that seems like an extra step - i.e. MA should be able to talk directly to AmpliPi?
I can’t quite get my head around how it should work in MA however. Ideally I would like to be able to just select a track to play and select which AmpliPi zones to play that track on. However how does this get played on the AmpliPi…does it use a source per zone I select, or does it know to group the selected zones onto a single source, and play the track on that?
I guess that might be something that can be worked out if there is a native MA player provider, but I have no idea how that would work.
The thing I would like to see is a simplified to the Media Devices. I currently have 15 media devices associated with Amplipi. Whenever I am creating an automation it is always difficult to figure out what device to intereact with to do what. The only functionality that I have been able to get to work consistently is playing from a media file on the announcement channel. Everything else has been unpredictable in what it does. (There are sources, zones, groups, it is never clear how do you make sure where to set the source, where to turn on/off power, where to mute/unmute)
My preference would be to have 4 media players and the announcements channel as the only devices and have the output zones/groups as configurations for the players, and the preset sources as part of the controls. I think that model would be clearer for the Home assistant interactions and it would make automations easier.
I agree, as someone who is experienced with AmpliPi but not experienced with Home Assistant it was difficult to get into making those automations myself; I initially thought they might just outright not be possible with the current HA plugin, though now that I’ve poked around I understand how to run these automations better.
The way to think about things is “I want to use this source to play this stream to this/these zone/zones or group/groups”, so for your automations you want to start by using a source and deciding the stream and use the media_player.select_source automation type, and select the source as an entity and type the name of the stream you want to play into the textbox like so:
Then you also want another portion of the automation to select all the zone or group entities you want and type in the name of the source you want to connect them to like this:
For your ask to make there be only 4 media players to represent the sources and have the stream and zones/groups be attributes to those players: You can achieve something similar within the GUI (but not automations) with our custom media cards plugin that sits on top of both hacs_amplipi and mini-media-player:
I’ll try setting it up as you suggested. However, I am not sure what kind of media entities “Amplipi: Output 1” (Mine source 1 is shown as Player 1 I assume that is the same) and “Amplipi: All”, I assumethis is a group?
I was trying to set it up to play the CBC Radio 1 stream (which is one of my preset streams) and I wanted to use the gradual volume to have it start up in the morning.
With the way I set it up it sometimes worked, but on other occasions started with a different source, or needed to press play or needed to unmute and in one case it started with a very high initial volume. It seems it was very dependent upon how it was left (although some of it might have been tweaks I tried to make to get it to work). Hopefully if I follow your approach it will work more consistenty.
Also thinks for the custom media card, I somehow missed that. I’m still finding it a little challenging to use the way I would want, but I probably just need to experiment with it more.
I appreciate this feedback, I’m looking into making a custom automation type to do what you talked about in your previous request all at once and will add the volume as an optional field.
As it stands, the mute and volume state is persisted from when you last used the zone. You can get around this by using the media_player.set_volume automation type like so:
You can do this to a source or zones/groups, just note that doing it to a source will require that source to have zones/groups connected to it to have any effect. The same goes for the media_player.mute automation type, which is straightforward enough to not need a screenshot as you just say “I want this to be (muted/unmuted) when the automation goes off” using a switch. Unfortunately, you do currently need to use this automation to unmute zones and simply using the volume change won’t unmute like they do elsewhere.
If you’d prefer a slow wake up / ramp up, you can do something like this which will increase the volume by 1% every half second until volume reaches 65%:
I’m excited that you will soon be focusing on the HA integration!
I think it would be great if there was a fully baked way for Home Assistant to call the announce API, using the UI. This would make integrating the announce API into automations far easier I made a script to do this:
amplipi_announce_zone:
url: "http://192.168.2.20/api/announce"
method: post
payload: '{ "media":"/home/pi/Music/{{ type }}.mp3" , "vol_f" : {{ volume }} , "zones" : [ {{ zones }} ] }'
headers:
content-type: 'application/json'
Then I have automations like this:
action: rest_command.amplipi_announce_zone
data:
type: bird
volume: 0.2
zones: 2
alias: Play sound to Office
But it would be nice if there was a way to select the actual zones (by name) and some form of media to play. I store my media on the amplipi for this, but woudl gladly change to storing locally within HA if that was the direction.
I also wish the media loaded as entity_picture was a higher quality. It seems to load up a tiny thumbnail. When I try to grab that and put it on my wall tablet, it looks very low quality. I’m generally playing via DLNA when I attempt this, but I think the same is true using Spotify, if I recall correctly.
We’ve had a few announce notifications in the office, one for when the front door opens as an arrival notification and another for a sensor in our mailbox to announce when we receive mail. Here’s the yaml for the mail sensor’s output:
You can do this in the UI using a media_player.play_media type automation, using media that is hosted on the home assistant in the “my media” folder and choosing what zones to play using the source-zone connection automation I shared earlier in the thread since the announcement output is recognized as a source for home assistant purposes:
Hi. I’ve been using the latest HA integration and it’s more workable than the previous version but I’m still missing the full on/off toggle (only off works now) and then the state is never actually Off but only Idle. Very old versions of this integration implemented all of these standard media_player controls and states. So this new version still breaks my user interface and media_player conventions. I am happy to explain further including why I think this is important if this is not clear enough. Cheers!
Could you explain the use case for the off state? In our experience it caused us two issues:
It was an inaccurate reflection of the true state of the related entities as nothing is ever meaningfully powered off within AmpliPi as long as the unit itself has power
It caused the UI controls for the entities to be inaccessible as the only way to recognize something was “off” was when it had nothing selected, but home assistant seems to hide the source selection dropdown when things are off so there was also no real way to turn them back on
What value does the off state hold, for you and/or in general? If we were to reimplement it, what would you expect its behavior to be?
I’ll start with the state issues. In order to keep my UI as compact as possible, I only want to display those media_players that are playing something. In every case except Amplipi, that state is Off.
Idle is used by some players when they are on but not playing anything. However, I don’t see that as appropriate for speakers as they are basically dumb devices. Also, other media players such as TVs and AVRs aren’t necessarily off but in standby mode, yet they report an Off state, not Idle.
If a media player can’t provide an off/on state (and related actions) then it probably also has limited value when trying to be used in derivative entities like the Universal Remote Card or a even simple media player group.
Indeed, I have (or had, since it’s broken now!) a group of media players that is either On or Off based on whether all of the players are off, but this is broken because of the Idle state of the Amplipi speakers.
Keep in mind that the old version of this integration did all this as one would expect (or at least as I would expect!). The on/off states were there and turn_on would actually work.
The problem now with actions is that I need to explicitly select a source to turn a speaker on. So I somehow have to remember source state for Amplipi which I didn’t previously. To do this, I would have to use at least one helper entity for each speaker along with an automation. But things like TVs and AVRs remember their state and don’t need source selection to be turned on so IMO this should be emulated by this integration.
I think the premise of the current way of thinking about Amplipi is speakers simply flawed: just because something always has power doesn’t mean it can’t be considered to be on or off. There are zillions of counterexamples, whether they are media players or other. I’ll stick with media players:
Google Chromecast devices (speakers included) are also always powered on but can be turned “on” and “off”. Idle is only used when they are spooling
I mentioned TVs and AVRs which we always keep on standby mode but are considered on or off in HA.
Pretty much every device in HA can be considered on/off:
Philips Hue lights are always powered on but can be switched on and off in HA.
A pool pump always has power but can be switched on and off on HA.
Even a HA script van be on/off.
I guess the Amplipi line of thinking about source selection turning a speaker “on” maybe goes back to the oldschool whole house audio analog wall controls which would have a set of sources and an off button. But that is so archaic it seems to me.
Besides, you did decide to add the turn_off action even though it’s not really off, so it really isn’t such a stretch to have an turn_on action and their corresponding on/off states. Whatever logic was used to be convinced that turn_off was worthwhile because it’s convenient is what I would ask be considered for all these other reasons. Not least which is that almost every HA device can be turned off and on.
I mean all of this constructively while perhaps challenging the status quo way of thinking.
