PS4 does not turn on with lovelace media card power button

[ktnrg45]

Home Assistant release with the issue:

102.0.dev.0

Last working Home Assistant release (if known): 101.3

Operating environment (Hass.io/Docker/Windows/etc.):

Debian Buster

Integration:

https://www.home-assistant.io/integrations/ps4

Description of problem:

• Changes made by me from #28261 (Changing STATE_OFF to STATE_STANDBY) causes a bug with the Lovelace media player card where if the state is STATE_STANDBY, then pressing the power button calls the media_player.turn_off service instead if the intended turn_on service.

The frontend conflict is here: https://github.com/home-assistant/home-assistant-polymer/blob/6ecc60423f6bafddef7d6a8d342525c36855d983/src/util/hass-media-player-model.js#L179

  togglePower() {
    if (this.isOff) {
      this.turnOn();
    } else {
      this.turnOff();
    }
  }

  turnOff() {
    this.callService("turn_off");
  }

  turnOn() {
    this.callService("turn_on");
  }

State must = 'off' for service turn_on to be called.

  get isOff() {
    return this.stateObj.state === "off";
  }

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

2019-11-19 23:54:23 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.281470748259104] Received {'type': 'call_service', 'domain': 'media_player', 'service': 'turn_off', 'service_data': {'entity_id': 'media_player.playstation_4'}, 'id': 21}
2019-11-19 23:54:24 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=media_player, service=turn_off, service_data=entity_id=media_player.playstation_4>
2019-11-19 23:54:24 INFO (MainThread) [pyps4_2ndscreen.ps4] Standby Failed: TCP Protocol does not exist

Additional information: Roku integration may also be affected #28148

[jamieshaw]

Whilst not going to be open an issue for a similar issue but this also extends to the universal media player component.

I have my Living Room entertainment setup in the following order, with precedence towards the top. However, with PS4 reporting a state as "Standby", when everything else is off and watching live TV directly via the Television, the current programme is not reported as active.

• Plex (Apple TV)
• Apple TV
• PlayStation 4
• Television

[ktnrg45]

Whilst not going to be open an issue for a similar issue but this also extends to the universal media player component.

I have my Living Room entertainment setup in the following order, with precedence towards the top. However, with PS4 reporting a state as "Standby", when everything else is off and watching live TV directly via the Television, the current programme is not reported as active.

• Plex (Apple TV)
• Apple TV
• PlayStation 4
• Television

Thanks for the info. Ill look into this as well. If you could post the entity state attributes for the universal entity and your television entity from the developer tools -> states tab that would be great. Also if you could post your configuration.yaml for your universal entity

[sephrioth]

Another issue here.

I exposed my PS4 to Homekit as a switch (media player feature_list: on_off), but the HA v102 change status "Off" to "Standby", which will set this switch always "On" in Home App after every HA restart, so I can't really turn on it from Home, need turn off the switch first, then turn on to activate PS4.

Is there a solution to show this switch "Off" in Home App if in standby mode? @ktnrg45

[ktnrg45]

Another issue here.

I exposed my PS4 to Homekit as a switch (media player feature_list: on_off), but the HA v102 change status "Off" to "Standby", which will set this switch always "On" in Home App after every HA restart, so I can't really turn on it from Home, need turn off the switch first, then turn on to activate PS4.

Is there a solution to show this switch "Off" in Home App if in standby mode? @ktnrg45

Yes we would have to add the state here: https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/homekit/type_media_players.py#L193. But that will probably be a separate PR.

As for now, you can try using the select_source service using an arbitrary source, and your PS4 should turn on. I'm not sure if you can do this from the HomeKit App however.

[sephrioth]

Thanks for the reply, I will try later. BTW, source switching is only for TV class in Homekit...

[ktnrg45]

@sephrioth Ok thanks for the info. Added fixes for homekit and universal in PR.

[sephrioth]

@sephrioth Ok thanks for the info. Added fixes for homekit and universal in PR.

Huge thanks!

[goodlucknow]

Thanks for the info. Ill look into this as well. If you could post the entity state attributes for the universal entity and your television entity from the developer tools -> states tab that would be great. Also if you could post your configuration.yaml for your universal entity

also experiencing this since the ps4 component was changed to report "standby" instead of "off". my main media device is a kodi instance and this used to take precedence but now as soon as it's not actively playing/paused the PS4 becomes the active child. Kodi state shows up as "idle" and the UMP state is "standby", with all the attributes of the PS4.

config entry below

` - platform: universal name: Bedroom children:

• media_player.cast
• media_player.kodi
• media_player.playstation_4`

[ktnrg45]

also experiencing this since the ps4 component was changed to report "standby" instead of "off". my main media device is a kodi instance and this used to take precedence but now as soon as it's not actively playing/paused the PS4 becomes the active child. Kodi state shows up as "idle" and the UMP state is "standby", with all the attributes of the PS4.

config entry below

- platform: universal name: Bedroom children: - media_player.cast - media_player.kodi - media_player.playstation_4

@killthewiseone So I tested the open PR with this configuration and it appears to resolve the issue if you can confirm:

  - platform: universal
    name: Universal
    children:
      - media_player.onkyo_receiver
      - media_player.playstation_4

[fleXible]

Hi,

I am having issues with my Playstation and the standby state for quite some time now. Actually, after diving in the code, I was quite happy to see the revert, because the media_play UI toggle is not the only piece broken.

• media_player toggle service does not work and the logic differs from its is_on function (used in the tests)
• essentially, media_player is missing STATE_STANDBY completely, see device_condition
• homekit uses its own differing logic
• external plugins, like kalkih/mini-media-player#218
• to complicate everything even more, STATE_IDLE is completely astray, sometimes handled as on, othertimes as off

Therefor I propose, to properly implement STATE_STANDY into media_player by inheriting from ToggleEntity and leveraging its is_on property. In that regard, home-assistant/home-assistant#28897 already looks quite complete.

Best regards!

[ktnrg45]

@fleXible Would you like to make a PR for this? I don't have homekit so I won't be able to properly test this.

[fleXible]

@ktnrg45 Yeah, I could. But honestly, it's way more sensible to first (if we then decide so) remove the STATE_STANDBY before further changing the power-behaviours. Today, I had a look at all the places, where a media_player is using standby.

1. There really are not that many, but more importantly
2. I could just find 1 use of it (in mediaroom), where it was used for something else, than just a STATE_OFF replacement.
3. Lately, I started diving deeper into automation and for my despair, more often than not, I found myself wrestling Jinja2 templates like those:

   {{ trigger.from_state.state in ("off", "standby") 
   and is_state("media_player.pioneer", "off") }}

   or another one, quite similar:

   {{ trigger.from_state.state in ("idle", "playing")  
   and trigger.to_state.state in ("off", "standby")  
   and is_state("switch.ambilight", "on") }}

   You get the idea :)

[ktnrg45]

I'm all for reverting STATE_STANDBY. It was a mistake on my part.

Since you brought up the STATE_IDLE inconsistencies in homekit I had a look here: https://github.com/home-assistant/home-assistant/blob/ced870c588bf319daa96791a715ea4a875ccd2a1/homeassistant/components/media_player/__init__.py#L701-L712

According to this STATE_IDLE should be a 'off' state. So perhaps the fix is really simple: STATE_IDLE should have been the state used instead of STATE_STANDBY all along.

Can you check if this plays well with homekit as far as the state reporting? The power/toggle issues still need to be worked out. https://github.com/ktnrg45/home-assistant/blob/ce2518672d59a4eafa8eca3401fe34f13ad0fc25/homeassistant/components/ps4/media_player.py

[fleXible]

I just cherry-picked your commit onto my sourcetree and trying it out now. The issue with homekit was, STANDBY was not recognized as off by it, so I was not able to start it this way.

Here's the verdict:

• the PS4 is always on in Homekit and can't be turned off
• when I turn it off in homekit, nothing happens
• play/pause/stop all just switches between the currently running app and the homescreen
• constantly "Sources out of sync" from homekit, and quite some "Standby Failed: TCP Protocol does not exist" from ps4-helper because they completely disagree about on/off

First I thought, it's a nice twist with play/pause, but in this context just a bit nonsensical. And giving up the real STATE_OFF for that doesn't make sense. Also some other mediaplayer report their "Homescreen" as idle, which is quite understandable.

The "IDLE is off" faction, is just very small and only doing for lack of imagination. Take [Plex],(https://github.com/home-assistant/home-assistant/blob/ced870c588bf319daa96791a715ea4a875ccd2a1/homeassistant/components/plex/media_player.py#L597) they clearly state to use turn_off to issue a stop for lack of capability.

In the end, this makes things just weird and me as a user end up having the plexplayer beeing reported as a nonsensical unavailable when it's not running.

P.S. how do you reference multiple lines of code?

[ktnrg45]

Sorry I don't understand. Plex shouldn't be affected at all.

play/pause/stop all just switches between the currently running app and the homescreen

This is intentional.

Well in that case I think reverting back to state off is the best idea. But that PR was rejected so I'm not sure what to do at this point.

If you would like to do a PR with your idea to fix this that would be great. I'm not to sure of what direction you have in mind though without seeing it.

Oh and btw just use this after the file #L701-L712

[fleXible]

Sorry I don't understand. Plex shouldn't be affected at all. @ktnrg45 I think you misunderstood me, I used Plex on my PS4 just for testing.

play/pause/stop all just switches between the currently running app and the homescreen

This is intentional. Everything fine, I wasn't thinking about it. But with this change, STATE_OFF is gone, which is not as intended. I believe, it was good the way it was before, STATE_IDLE on the homescreen, this is also the way, other media_player implementations handle this. It's a nice idea with STATE_PAUSED, but as the PS4 doesn't provide information if and what app is currently residing in the background, you can't decide between idle and pause. Because if there is no app in the background, pressing the PS4 button doesn't do anything, and STATE_PAUSED would be wrong in this event. So to keep it simple, I'd prefer just IDLE and OFF

I think, you just need to provide the information regarding the breaking changes to the PR and hopefully it will get through.

[ktnrg45]

@MartinHjelmare I'm not sure why PR #30344 (Revert STATE_STANDBY back to STATE_OFF) was rejected. I don't want to submit another PR for this if it doesn't get accepted though since it got rejected the first time but IMO it is the simplest, best solution. What are your thoughts on this?

[MartinHjelmare]

The issue is partly that we don't have clear state guidelines for the media_player integration and its implementation is too broad which makes guidelines necessary.

To change the media_player integration requires a decision in an architecture issue. Is there an architecture issue for this proposal?

[fleXible]

@MartinHjelmare The PR just reverts a previous change, that broke some functions in ps4 implementation. It does not introduce any architectural changes.

[MartinHjelmare]

We closed the PR since we want the frontend to support the current state implementation, I think. Why not pursue that?

[fleXible]

Because STATE_STANDBY is not officially added to architecture as possible state for media_player. The current ps4 implementation using standby should never have been accepted. STATE_STANDBY is missing in several places and breaking functions, not just in the frontend. Homekit doesn't recognize standby either. So we figured, the correct way forward is to revert the change.

[MartinHjelmare]

I'm not sure we have defined the possible states for the media_player integration. Have you seen that somewhere?

[fleXible]

@MartinHjelmare I think the best references are the details of the current implementation:

• device_condition.py and
• reproduce_state.py

Those 2 files provide the basis for all common functions for media_player implementations. Anything not in there, but only found in a specific implementation is prone to break things somewhere else.

As an example take androidtv, which uses the state STATE_STANDBY that can not be reproduced by the underlying media_player implementation, because there it's missing.

I have the feeling, there is a mismatch between architectural consent and actual implementation reality, which leads to funny surprises all over the place.

[ktnrg45]

As fleXible has mentioned there is some discrepancies with state usages. We hope to not add additional complexities/compatibility issues to the media_player architecture trying to fix this so we are thinking of alternative solutions.

What is the use case for STATE_IDLE?

As mentioned above, the base class infers that STATE_IDLE is like an 'off' state in the toggle method. https://github.com/home-assistant/home-assistant/blob/ced870c588bf319daa96791a715ea4a875ccd2a1/homeassistant/components/media_player/__init__.py#L701-L712

Additionally, Universal seems to concur the same:

https://github.com/home-assistant/home-assistant/blob/be14b94705aebc7ed8dd395bbfd49e8ba8e7d5b2/homeassistant/components/universal/media_player.py#L86

Homekit does not however as it is missing here. https://github.com/home-assistant/home-assistant/blob/be14b94705aebc7ed8dd395bbfd49e8ba8e7d5b2/homeassistant/components/homekit/type_media_players.py#L193

So would using STATE_IDLE be a valid alternative to STATE_STANDBY?

[fleXible]

@ktnrg45 From my analysis of the different media_player implementations, using STATE_IDLE as STATE_OFF is an artifact of some implementations not having the possibility of being turned on/off. So to also incorporate those implementations, STATE_IDLE, which those implementations do use, is additionally regarded as an off-state in some places.

On the flip side, this is never really expressed anywhere else than in some particular code segments, especially not in any test-cases, leaving a lot open to chance/interpretation.

I think, instead of further manifesting this mismatch in more places, we should ignore it for now and step-by-step change those implementations to line-up to the rest. I think further up, I suggested to make media_player inherit from ToggleEntity which introduces a property is_on, which can be overriden by implementations with special need and act apart of the actual state.

[ktnrg45]

@ktnrg45 From my analysis of the different media_player implementations, using STATE_IDLE as STATE_OFF is an artifact of some implementations not having the possibility of being turned on/off. So to also incorporate those implementations, STATE_IDLE, which those implementations do use, is additionally regarded as an off-state in some places.

On the flip side, this is never really expressed anywhere else than in some particular code segments, especially not in any test-cases, leaving a lot open to chance/interpretation.

I think, instead of further manifesting this mismatch in more places, we should ignore it for now and step-by-step change those implementations to line-up to the rest. I think further up, I suggested to make media_player inherit from ToggleEntity which introduces a property is_on, which can be overriden by implementations with special need and act apart of the actual state.

Perhaps it would be wiser to add the property is_on to the MediaPlayer class? We shouldn't change it's class inheritance like that.

Homekit uses the core.State.state attribute to determine on/off. We would need to change homekit to be able to access the actual media player entity objects for this.

https://github.com/home-assistant/home-assistant/blob/be14b94705aebc7ed8dd395bbfd49e8ba8e7d5b2/homeassistant/components/homekit/type_media_players.py#L188-L193

[fleXible]

Can we please take a step back from the STATE_IDLE issue and first focus on the standby problem? I'm still unable to controle my ps4 via home assistant as homekit and the ui are broken for the power functions, which really is a big pain.

[ktnrg45]

I didn't say it was an issue. I brought it up as an alternative solution.

[ktnrg45]

@fleXible If you would like to share your thoughts on this ->home-assistant/architecture#352

[ThomasPrior]

I don't mean to press anyone, I know this is all done on goodwill and free time but has there been movement on this? My PS4 behaves entirely differently than every other media player I have and I can't find a way to make it behave like everything else using the Universal card.

[sephrioth]

@ThomasPrior Beta has fixed it... I used it for a while and works great.

[broyuken]

Will this fix Roku as well? I just got a TCL Roku TV and found this issue.

[ThomasPrior]

@ThomasPrior Beta has fixed it... I used it for a while and works great.

Do you know which change I beta fixes this? I've compared the PR's between 108.8 and 109.0 and I can't see anything that would directly affect this.

[sephrioth]

@ThomasPrior Sorry I just can't find the commit either... my current version is 0.109.0.dev20200411, you can try it.

[fleXible]

I couldn't find any patch either. Unfortunately it has been quite impossible to get any traction on this issue, a real solution still seems far away.

At least for all users of HACS, I am now providing a custom dirty fix. Just add fleXible/ha-ps4-custom with category Integration to your Custom Repositories and install PlayStation 4 Custom.

@ThomasPrior The Media Control Card widget, should then work normally.

[ThomasPrior]

Thanks for your efforts on this. It's disappointing to see the PR's to resolve this go round in circles but I am very thankful to have a way forward, even if it is via a custom component.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[fleXible]

@ThomasPrior But not all hope is lost! A while ago, someone stumbled upon this issue and at least fixed part of it from the homekit-side: Roku STATE_STANDBY / HomeKit #32156

The Mediaplayer widget in Lovelace still doesn't work correctly, but the one in HomeKit now does. Step by step, we're moving closer! Maybe, that's the way to get this working, too? ;)

Seems to have been fixed by #37427, this issue can be closed.

[mihail4anov]

@ThomasPrior But not all hope is lost! A while ago, someone stumbled upon this issue and at least fixed part of it from the homekit-side: Roku STATE_STANDBY / HomeKit #32156

The Mediaplayer widget in Lovelace still doesn't work correctly, but the one in HomeKit now does. Step by step, we're moving closer! Maybe, that's the way to get this working, too? ;)

Seems to have been fixed by #37427, this issue can be closed.

Have just tried to turn PS on. Does not work. What do I do wrong?

[fleXible]

@mihail4anov Have just tried to turn PS on. Does not work. What do I do wrong?

Sorry for the late response, but can you please describe in detail, how you tried to turn the PS4 on?

Further above, there is the clear statement, that not all issues are fixed yet.

The Mediaplayer widget in Lovelace still doesn't work correctly, but the one in HomeKit now does.

But if you closely read through this page, you will find several different kinds of workarounds.

I also provide a custom_component to be easily installed using HACS. The installation and config should not take more than 10 minutes!

[behtjes]

I've got the same problem using the native home assistant ps4 plugin:

It does work the first time, but stoppes working after...

2020-09-16 16:52:14 INFO (MainThread) [pyps4_2ndscreen.ps4] Standby Failed: TCP Protocol does not exist

2020-09-16 16:51:59 DEBUG (MainThread) [pyps4_2ndscreen.ddp] Status: {'status_code': 200, 'status': 'Ok', 'host-id': 'F8461C076225', 'host-type': 'PS4', 'host-name': 'PS4-689', 'host-request-port': '997', 'device-discovery-protocol-version': '00020020', 'system-version': '07550001', 'running-app-name': 'Red Dead Redemption 2', 'running-app-titleid': 'CUSA08519', 'host-ip': '192.168.0.112'} 2020-09-16 16:51:59 DEBUG (MainThread) [pyps4_2ndscreen.media_art] Starting search request 2020-09-16 16:52:07 DEBUG (MainThread) [pyps4_2ndscreen.media_art] Item: Red Dead Redemption 2, CUSA08519 2020-09-16 16:52:07 INFO (MainThread) [pyps4_2ndscreen.media_art] Direct Match 2020-09-16 16:52:07 DEBUG (MainThread) [pyps4_2ndscreen.ps4] Found Title: Red Dead Redemption 2, URL: https://store.playstation.com/store/api/chihiro/00_09_000/container/NL/nl/19/EP1004-CUSA08519_00-REDEMPTION000002/1600257273000/image 2020-09-16 16:52:09 DEBUG (MainThread) [pyps4_2ndscreen.ddp] SENT MSG @ DDP Proto SPORT=37735 DEST=('192.168.0.112', 987) 2020-09-16 16:52:09 DEBUG (MainThread) [pyps4_2ndscreen.ddp] RECV MSG @ DDP Proto DPORT=37735 SRC=('192.168.0.112', 50400) **2020-09-16 16:52:14 INFO (MainThread) [pyps4_2ndscreen.ps4] Standby Failed: TCP Protocol does not exist** 2020-09-16 16:52:14 DEBUG (MainThread) [pyps4_2ndscreen.ddp] SENT MSG @ DDP Proto SPORT=37735 DEST=('192.168.0.112', 987) 2020-09-16 16:52:14 DEBUG (MainThread) [pyps4_2ndscreen.ddp] RECV MSG @ DDP Proto DPORT=37735 SRC=('192.168.0.112', 61912) 2020-09-16 16:52:19 DEBUG (MainThread) [pyps4_2ndscreen.ddp] SENT MSG @ DDP Proto SPORT=37735 DEST=('192.168.0.112', 987) 2020-09-16 16:52:19 DEBUG (MainThread) [pyps4_2ndscreen.ddp] RECV MSG @ DDP Proto DPORT=37735 SRC=('192.168.0.112', 50633)

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[anubisg1]

Is there any update on this? the issue seems to not have been fixed... i can turn off, but never able to turn on

[Sholofly]

Bug still present in core-2021.4.0b2

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[anubisg1]

we are waiting on you to answer. if you do nothing, bugs don't get fixed on their own

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.