How to specify custom integration entity features as filter for services.yaml?

Hi developpers
I want to use an entity service for a custom integration that filters for supported entity features. According to the developper docs, the entitfy feature must be defined as a string in the format domain.class.attribute.
However, when I do so, I always get an error that the class or feature is not know when the integration is started.
The only way I got it to work was by specifying the interger which represents the value defined in the IntFlag class for the integration entity attributes.

However, the hassfest validation of the git repo now complains that a string must be specfied in services.yaml, which I could not get to work by lots of various combinations that I tried.
Error: R] [SERVICES] Invalid services.yaml: expected str @ data[‘get_solarbank_schedule’][‘fields’][‘entity_id’][‘selector’][‘filter’][0][‘supported_features’][0][0]. Got None

Here is the code I use now that works:

      selector:
        entity:
          filter:
            integration: anker_solix
            domain: sensor
            supported_features:
              - 1

The class is defined in the entity.py module of the integration:

class AnkerSolixEntityFeature(IntFlag):
    """Supported features of the Anker Solix Entities."""

    SOLARBANK_SCHEDULE = 1

I also tried to specify it in const.py but that does not make a difference. The AnkerSolixEntityFeature class is imported in sensor.py where the entity service is being registered:

    # register the entity services
    platform = entity_platform.async_get_current_platform()
    platform.async_register_entity_service(
        name=SERVICE_GET_SOLARBANK_SCHEDULE,
        schema=SOLARBANK_ENTITY_SCHEMA,
        func=SERVICE_GET_SOLARBANK_SCHEDULE,
        required_features=[AnkerSolixEntityFeature.SOLARBANK_SCHEDULE],
        supports_response=SupportsResponse.ONLY,
    )

The big question to me is what kind of string I have to specify in services.yaml to have the feature accepted as valid entity feature?

I tried:

            supported_features:
              - sensor.AnkerSolixEntityFeature.SOLARBANK_SCHEDULE

and

            supported_features:
              - anker_solix.AnkerSolixEntityFeature.SOLARBANK_SCHEDULE

None of those formats is accepted or known when the services are being registered.
Does anybody have a clue how entity supported features must be specified to be accepted by supported_features specification in services.yaml ?

To be a bit more precise on this. Actually there is no error in the core logs, but the problem is that the Service UI does not show any valid entity for the entity_id selector field, no matter which syntax I use in the service.yaml or whether I define the

AnkerSolixEntityFeature

class in the sensor.py of the custom integration.

It seems that core cannot find the class definition with the custom sensor features for the custom sensor entity?

This how I did that with a target selector:

set_absolute_position:
  name: Set absolute position
  target:
    entity:
      integration: sunsa
      device_class: blind

HA detects the entities by the integration domain.

You’ll have much more traction asking dev questions on the Discord server.

I don’t believe it’s possible to invent own supported features. You need to work with the pre-defined ones (as frontend isn’t dynamically reading supported features)

Hi
Thanks for your example. Unfortunately that doesn’t help to resolve the issue I have. I saw other examples in core integration for how the specify the supported_features filter in target or entity selectors. It was always the string in the format as I also tried.
The problem I see is only the specified feature string in services.yaml does not seem to be resolved properly by core.
When I specify the IntFlag value (1) of the required feature directly in services.yaml, the filter works in the UI for the field selection:

            supported_features:
              - 1

When I specify the string, it does not find any entity that matches the specified criteria.

            supported_features:
              - sensor.AnkerSolixEntityFeature.SOLARBANK_SCHEDULE

This leads me to think that core does not resolve properly the supported feature string to the class which defines the IntFlag.
At least this is not resolved properly for the sensor entities under my integration domain…

Ah, so you mean I would have to choose existing features for sensor entities in my case that have some meaningfull matching for my use case?
That would explain why core cannot resolve the specified feature string in the filter

I believe so and since SensorEntity doesn’t have any supported features flags there is not much to do here.
But I haven’t looked at this for custom services so I’m not entirely sure that’s the case.

I made some more testing on this, and the UI filtering behaves differently for Target selectors and entity selectors in regards to the supported_features string.

The trick I had to do is to use a core domain feature that resolves to the same IntFlag as I use in my integration sensor. It is a nasty workaround, but following filter declaration works for target selector:

get_solarbank_schedule:
  target:
    entity:
      integration: anker_solix
      domain: sensor
      # anker_solix.AnkerSolixEntityFeature.SOLARBANK_SCHEDULE is not resolved by core when frontend is loaded
      # therefore core domain feature is used as filter that resolves to same IntFlag as used in AnkerSolixEntityFeature
      supported_features:
        - calendar.CalendarEntityFeature.CREATE_EVENT

The same filter however does not work for entity selector and I have no clue why not. There are no errors logged, why the filter string is not resolved properly for entity selectors.

get_solarbank_schedule:
  fields:
    entity_id:
      example: "sensor.solarbank_e1600_home_preset"
      required: true
      selector:
        entity:
          filter:
            integration: anker_solix
            domain: sensor
            supported_features:
              - calendar.CalendarEntityFeature.CREATE_EVENT

So I probably have to change all my services descriptions and use the target selector instead of entity selector…