OpenSky, icao24 not recognized as part of trigger data

[vingerha]

The problem

{{trigger.event.data.icao24 }} does not work

{{trigger.event.data.callsign }} works fine

What version of Home Assistant Core has the issue?

2023.9

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

OpenSky

Link to integration documentation on our website

https://www.home-assistant.io/integrations/opensky/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

2023-09-08 13:36:45.306 ERROR (MainThread) [homeassistant.components.automation.message_flight_entry_notification] Error while executing automation automation.message_flight_entry_notification: string value is None for dictionary value @ data['value']

Additional information

No response

[home-assistant[bot]]

Hey there @joostlek, mind taking a look at this issue as it has been labeled with an integration (opensky) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `opensky` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign opensky` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

opensky documentation opensky source _{^{(message by IssueLinks)}}

[joostlek]

To what events are you listening? opensky_entry or opensky_exit?

opensky_entry returns everything: opensky_exit doesn't return everything, only the sensor and the callsign since we don't store the full flight details to compare with, only the callsigns.

[vingerha]

In my previous version (OzGav fork) I used this both for in/ex flights and never had issues so I am not sure if this was there before in 'core'. My wish is to track flights entering and departing an airport of choice. The icao at exit might even be more important as it indicates the flight actually started and entry in the target airport is then sort-of know as the flight duration is rather stable.

[joostlek]

Hmm, I need to think about this more. Currently we just keep a list of the callsigns of the last tracked planes. and we compare that. Probably someone is going to mess stuff up and I want to know what the consequences are when you try to load, mutate and compare 9000 data objects every 90s. I can imagine that that would be a heavy task. Not sure if I like that idea at the moment.

[vingerha]

understand , I will verify next week with the fork or maybe @ozgav can already comment here?

[OzGav]

Firstly, great job @joostlek !

I am away for a few days so can’t comment much. Although I think if it worked ok in the original core version then it should work now. My fork was a very minor modification of the original core version…

[joostlek]

That's what I thought as well. Can you maybe install the custom integration as well and try if that also throws this error? Maybe something changed in the logging?

[vingerha]

I am still using this fork on my main instance, i.e. a automation that trigger on both in / out events and no error, also 2023.9. I now have to review my earlier assumption that this also worked on exit admitting I did not use this a while as I use a bunch of known callsigns / icao24 (always flyiung the same routes)

[vingerha]

Is working now, sorry for the long wait and thanks for the implementation !