Skip to content

[Bug]: Duplicates removal does not work (with KVV at least), more generic idea for solution #116

@fft1010

Description

@fft1010

The problem

HI,
it's me again and my duplicates. I am on the latest release, and my first feedback was, everything is fine, which was true, unless I touched the configuration via Settings -> devices and services -> db-infoscreen

Image

After first thinking it was a change I did, I now assume, that the KVV API changed, and all all my departures are treated as unique. Reason:

With my little knowledge I found
/homeassistant/custom_components/db_infoscreen/__init__.py and tried to understand what is happening from # -- DEDUPLICATION STEP on is happening.

What I found out: None of the parameters you use to build a unique are in the KVV API it seems to me. See here the raw data from the sensor:

  - countdown: "41"
    datetime: 1774865460
    delay: "0"
    destination: Rheinstetten
    hints:
      - Niederflurwagen
    is_cancelled: 0
    line: S2
    origin: Hagsfeld Reitschulschlag
    platform: "3"
    platform_name: Gleis 3
    platform_type: Gleis
    rt_datetime: 1774865460
    sched_datetime: 1774865400
    type: S-Bahn
    trainClasses:
      - S-Bahn
    departure_current: "12:11"
    departure_timestamp: 1774865460
    changed_platform: false
    trip_id: null
    arrival_current: "12:11"
    arrival_timestamp: 1774865460
  - countdown: "42"
    datetime: 1774865520
    delay: "0"
    destination: Rheinstetten
    hints:
      - Niederflurwagen
    is_cancelled: 0
    line: S2
    origin: Hagsfeld Reitschulschlag
    platform: "1"
    platform_name: Gleis 1
    platform_type: Gleis
    rt_datetime: 1774865520
    sched_datetime: 1774865460
    type: S-Bahn
    trainClasses:
      - S-Bahn
    departure_current: "12:12"
    departure_timestamp: 1774865520
    changed_platform: false
    trip_id: null
    arrival_current: "12:12"
    arrival_timestamp: 1774865520

So my best guess is, that something changed in the KVV API again, my idea now is, that you give the user the possibility to have a unique identifier on his own, and leave it up to the user, like in the text_sensor. So in my case I would choose: {line} as the identifier, as I know I get all departes for this line, and filter "all interesting" already out by only using platform 1,3 So all remaining liens are candidates, and if a departure is within the 120 sec, than leave out the later one.

I could not find any errors in the logfile, everything seems to run, but duplicates are there.

As I assume, that the APIs of the local systems might change more often, my idea is, that like in the text-sensor you have a line for the key_trip_id configuration e.g. {journeyID}{journeyId}{id}{key}{trainNumber}
and I would simply fill it with {line} to make potential screwups easier to fix a button next to it, with "default", that resets key_trip_id configuration to {journeyID}{journeyId}{id}{key}{trainNumber} might help users to play around and not have too many problems.

thank you for considering this
Juergen

What version of Home Assistant Core has the issue?

really does not matter

What type of installation are you running?

Home Assistant OS

What version of this Integration has the issue?

latest

If possible, please provide the station name you were using.

No response

What data source are you using (usually IRIS-TTS)?

KVV

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

No response

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions