# New config format

Currently, the integration has a Config Flow for setting op the integration, i.e. specify properties of the USB dongle.

Devices are still configured via YAML and need to be migrated towards UI configuration.

[ADR-10](https://github.com/home-assistant/architecture/blob/master/adr/0010-integration-configuration.md) states new YAML configuration by default are not allowed anymore. Of course, exceptions are still possible ;)

Integrations are encouraged to migrate toward config entries and the ConfigFlow / OptionFlows to manage this configuration via the UI. Moving away from YAML is a big change, since it would require a complete UI to configure the integration, since the config entries cannot be edited manually.

As mentioned in [here](https://hackmd.io/fgmRUKCJRWq7wzDonsBQdg?view#Points-of-attention), a migration path from current YAML -> new YAML -> Configurable UI would be a good solution.

Independent of this path, a new config format should be defined.

### Challenges / Issues

* Profiles can define a set of functions that are applicable for that profile (A5-38-08 or D2-01). Not all functions are supported by all devices, thus we need a way to express the supported functionality of a device.
* Some devices have different kind of sensors. These devices should result in a set of entities.
For example, a sensor that provides temperature and lumination should result in two entities. Their device id should be the same, such that they are properly coupled in the HA device registry

### Proposal #1

enocean:
   serial_path: /dev/ttyUSB1  # Could be auto discovered
   base_id: [0xff, ......]    # Also auto discoverable
   devices:                   # map of devices, key = platform, value = list of devices
     switch:
        - enocean_id: [0x..,..] 
          offset: 1           # offset w.r.t. base_id
          sending_profile: D2-01-01
          receiving_profile: D2-01-01
     light:
        - enocean_id: [0x..,..] 
          offset: 1
          sending_profile: D2-01-01
          receiving_profile: D2-01-01

In this approach, the devices are grouped per platform. This explicitly defines the functions to use.
During setup of the integration, all entries in the device map are forwarded their corresponding platform.

#### Pros
* Easy, explicit configuration

#### Cons
* Difficult to combine actuators with sensors, e.g. actuators with energy measurement cannot be expressed this way.

### Proposal #2

enocean:
   serial_path: /dev/ttyUSB1  # Could be auto discovered
   base_id: [0xff, ......]    # Also auto discoverable
   devices:                   # List of devices
      - enocean_id: [0x..,..] 
        offset: 1           # offset w.r.t. base_id
        sending_profile: 
           EEP: D2-01-01
           features: 
             - switch
        receiving_profile: 
           EEP: D2-01-01
           features: 
    

In this approach, profile specific features can be expressed. Each platform could analyse properties in the device and generate entities that are supported

#### Pros
* Very expressive, most flexible
* Makes it possible to combine devices that have actuators & sensors

#### Cons
* Profile specific settings are variable, making validation + building UI of the configuration data a bit more challinging.

## Other notes

* Entities that have the save device identifiers are automatically coupled in HA Device registry. See [here](https://developers.home-assistant.io/docs/device_registry_index). As identifiers, we could use EnOcean & the device ID
* Rockers should not be represented as entities. They can be registered explicity in the device registory
* When building UIs and updating config entries, the `homeassistant.helpers` are available to 'live' update the entities.