PS4 configuration via YAML

The official PS4 Home-Assistant must be configured through Integrations instead of configuration.yaml.

As a user, I want to be able to configure all my entities through YAML files instead of having to rely on the UI.

This is to best allow transferring set ups to GitHub repositories without having to rely only on backups.

This will not happen. Read this topic for more details.

New integrations will only be configurable through UI, YAML is being deprecated for configuration of integrations.

1 Like

Thanks for sharing. A bit of a pity, although there’s some contradiction, I feel.

On the one hand:

For the future, Home Assistant will be moving towards that concept more and more. This allows anybody to use the method they prefer.

On the other hand:

We will no longer accept any changes to the YAML configuration for existing integrations that communicate with devices and/or services.

I understand the PS4 interacts with the device and, therefore, it means that we do not have the method we prefer. I would understand it not being required, but not being accepted does seem like phasing out YAML, though; which is a bit sad to remove the creators/contributors the option too.

At least, the workaround is published:

This is actually not true, the .storage folder contains all Home Assistant managed configuration files in JSON format, which in those cases, can be stored and versioned in a git repository.

The parts you quoted are out of context. Read the blog post carefully.
YAML is going away for CONFIGURATION OF INTEGRATIONS, not for automations, scripts, input booleans etc., YAML functionality is even extended for these things. It’s stated in the same part of the blog as your first quote.

Did you actually read the blog?

Please read the blog again, and all other +500 posts, your concerns have been discussed to death a 100 times in there.

Personally, I’m totally fine with configuration of integrations through the UI (once the UI provides the same functionality as YAML, which is currently not the case for a lot of integrations as this blog has only been released recently), because normally you only set this up once and then only again when you replace a device or get a new one.
It’s a different story for automations, scripts, etc., but honestly I fear this will also be replaced by UI config at one point, even if they say it won’t, they said the same about YAML in general… but let’s see.
Just my 2 cents.

Yes. I did. Both the posts and a big chunk of the replies.

I was expressing my opinion here, the same as you just did.

I’m sorry but then you didn’t understand the blog, because the two quotes you posted are not contradicting at all, the first quote talks about configuration zones, lovelace and helpers and the second quote about configuration of integrations, which communicate with devices and/or services…

And again, why is it sad for creators/contributors, when YAML option is removed? I quoted the blog and I’ll do it again:

The blog states that it’s actually better for the devs to remove YAML support.

And be careful with uploading this

to git (assuming you upload it to a public git repo), it contains sensitive information :slight_smile:

In this particular case the core PS4 integration has always been UI-only since day one, and released long before this policy. Nobody added YAML config to this integration after 15+ months.

With ADR-10 that would no longer be accepted today, but creators/contributors that do not agree with this policy still have the option of going the custom component route instead. They’d have total freedom to do whatever they wanted, and publishing to HACS makes it super easy for users to discover, install, and upgrade.

1 Like

Thanks SeanM, I’m indeed working on that.

Lol, @Burningstone. Thanks a lot for the reading and humility lesson. </irony>

Happy to reply to your message, but not here. Let’s keep this as the feature request it is. If you want to copy this over to the blog post thread, I will happily add my view. Although, in all honesty, it will be a waste of both of our times.

For those interested, this is about how many lines it took me to add YAML support to the PS4 component:

Config = collections.namedtuple(
    'Config', f'{const.CONF_ENTRY_ID} {const.CONF_DATA}')


async def async_setup_platform(
        hass, config, async_add_entities, discovery_info=None):
  """Loads configuration and delegates to official integration."""
  # Load configuration.yaml
  host = config.get(const.CONF_HOST)
  name = config.get(const.CONF_NAME, const.DEFAULT_NAME)
  region = config.get(const.CONF_REGION)
  token = config.get(const.CONF_TOKEN)

  # Format it in the new config_entry JSON format.
  config_entry = Config(
      util.slugify(name),
      {
          const.CONF_TOKEN: token,
          const.CONF_DEVICES: [
              {
                  const.CONF_HOST: host,
                  const.CONF_NAME: name,
                  const.CONF_REGION: region,
              },
          ],
      }
  )

  await ps4_media_player.async_setup_entry(
      hass, config_entry, async_add_entities)

  return True

Although, of course, this assumes you already have the token. However, the same config_flow could provide that for you to configure as many other components do. I will be publishing a full example when completed.

1 Like

While this Feature Requests still stands and should be kept open; as a workaround, I created this PS4 Custom Component. Similar components can be created for other components without YAML.