Add unique_id to RFLink entities

[javicalle]

Proposed change

Add unique_id property to the RFLink entities.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

There is no changes to device settings

# Example configuration.yaml entry
switch:
  - platform: rflink
    device_defaults:
      fire_event: true
      signal_repetitions: 2
    devices:
      newkaku_0000c6c2_1:
        name: Ceiling fan
      conrad_00785c_0a:
        name: Motion sensor kitchen

Additional information

This change has been successfully tested in my local environment, including automations, HA interactions and phisical devices interactions.

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

[frenck]

Hi there @javicalle!

Thanks for opening up a PR! However, there are all kinds of unrelated commits in this PR. Could you please clean that up so the PR only contains your changes?

Thanks! 👍

[javicalle]

I think I was able to resolve the mess I had made with commits.
I hope the tests go fine

[javicalle]

Local coverage ups to 100%
Not sure why codecov fails now. It is a problem?

[javicalle]

I've been reviewing how the unique_id has been implemented in other integrations.
In general, they follow the recommendations of the documentation in this regard and those cases that are not, but there are possibilities, it has been rejected (#34668).

So, what is the situation in this case?
(disclaimer: the following is my personal analysis of RFLink library and may be incorrect and / or totally wrong)
The RFLink gateway reads RF signals. These signals have limited information on the device that generates them (besides the signal value) they have 'protocol', 'id' and 'button'. There are represented in the format <protocol> _ <id> _ <button> and is the value stored as _device_id

And, are these values uniques?
It cannot be guaranteed. In fact, some devices have a switch that allows you to change the ID to avoid conflicts, or there are others that change the ID every time you replace the batteries.
So it may not seem like a good candidate to define the unique_id value.

BUT IMHO there is another approach that is intended to follow this PR.
In the configuration you define an entity with a entity_id. And the RFLink library allows you to control changes to the device_id by defining device aliases. So you can have a device configured that is 'unique' in the configuration.
Obviously this value is "unique" in terms of the treatment the person gives it, not because it is identified by an internal value of the device that generates the signal. There is no possibility of accessing an identifier of type 'serial_number' or 'mac_address' from the RF signal.

But it is also true that this implementation enables the possibility of this operation being perverted so that you can substitute one physical device for another and assign it the same device_id.

So before going any further in this RP I think you should evaluate if the approach is correct. For my part, I don't think there is another way to generate a unique_id value for this type of integration.

[javicalle]

It seems that I have done a mess with code rebase.
Also, there is no interest or activity about it, so I close the PR

[jeroen85]

It seems that I have done a mess with code rebase.
Also, there is no interest or activity about it, so I close the PR

That's a pity, that's exactly what I was looking for. Any chance this can still be implemented?

[qweluke]

@javicalle will you add unique_id? we really need this!

[MuadDib007]

unique_id would make my life much easier with regards to RFLink so I would like to see it as well.