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

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
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
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__.pyand tried to understand what is happening from# -- DEDUPLICATION STEPon 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:
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_idconfiguration 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 resetskey_trip_idconfiguration 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