Allow ESPHome to trigger the HA tag scanned event

[jesserockz]

Breaking change

Proposed change

This allows ESPHome node to trigger the tag scanned events by posting a crafted event.
esphome/esphome#1281
esphome/esphome-docs#763
esphome/feature-requests#848

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:

# Example configuration.yaml

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

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

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[MartinHjelmare]

Looks good! Converted to draft since we're waiting for upstream. When upstream feature is released, we can go ahead here.

[jesserockz]

@MartinHjelmare
This will work without the esphome changes as you could still send the event manually.
The action in esphome is really just a helper

on...
  then:
    - homeassistant.event:
        event: esphome.tag_scanned
        data:
          tag_id: some-tag
          device_id: deviceid

[MartinHjelmare]

Ok.

[balloob]

device_id needs to be the device registry ID of ESPHome device in Home Assistant.

The device registry entry is returned from calling device_registry.async_get_or_create on line 278. The ID is available as entry.id

[balloob]

#40132

[mythicaleinhorn]

This feature apparently breaks the usage of own custom data entries in the event.

Example:

I'm trying to send the following event:

on...
  then:
    - homeassistant.event:
        event: esphome.tag_scanned
        data:
          tag_id: some-tag
          some_other_key: some_other_value

What I receive on the event bus is the following:

{
    "event_type": "tag_scanned",
    "data": {
        "tag_id": "some-tag",
        "device_id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    },
    "origin": "LOCAL",
    "time_fired": "xxxx-xx-xxTxx:xx:xx.xxxxxx+00:00",
    "context": {
        "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "parent_id": null,
        "user_id": null
    }
}

When I instead use a completely custom event, I lose the device_id, but receive my custom data values again:

on...
  then:
    - homeassistant.event:
        event: esphome.my_own_event
        data:
          tag_id: some-tag
          some_other_key: some_other_value

{
    "event_type": "esphome.my_own_event",
    "data": {
        "tag_id": "some-tag",
        "some_other_key": "some_other_value"
    },
    "origin": "LOCAL",
    "time_fired": "xxxx-xx-xxTxx:xx:xx.xxxxxx+00:00",
    "context": {
        "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "parent_id": null,
        "user_id": null
    }
}

Expected Behaviour:

Home Assistant should pass through any additional data it receives on a esphome.tag_scanned event in addition to how it's treating the event now.

[jesserockz]

Ah I see, yes this is because the event is not forwarded through, but just calls the HA tag_scan code which itself makes the tag_scanned event.
Perhaps we should still forward the original event onto the event bus.

[MartinHjelmare]

Please discuss this in an issue instead.