Feature request

[Gr3ytooth]

At the moment only the 2 upcoming departures are being shown. I think it would be a great addition if the sensor could show all the upcoming departures were real time info is available.

A real life example: My house is a 6-7 minute walk from the train station. If I would use the sensor during rush hours for all trains going north, the 2 departures that are displayed in the current version of the sensor would most likely already have departed before I have a theoretical chance of getting to the station. But if the sensor would have shown all the available real time information then I would have been able to see the trains that I actually would be able to take.

If this feature would be implemented I would think it would be great if there was a sensor attribute added to show how many real time entries are available. That way it would be easier to make some clever scheme for visualizing the traffic information in the UI.

Best regards Fredrik

[fredrikbaberg]

I've started with something like this related to Issue #2, where my idea is to have a "raw sensor" which calls the API, and then one sensor for each "departure" (set of line(s) and/or direction) that uses the raw data to update. I'm almost done with the raw sensor, but haven't started with the other.

What is the best way to present the data? Previously I added "_0", "_1" and so on to each entry, to make it readable from UI. Now I'm just adding the data itself, which gives the following output (when I open the data in dev-state). State is 8 in this case:

{
  "attribution": "Data from sl.se / trafiklab.se",
  "unit_of_measurement": "departures",
  "departures": [
    {
      "line": "161",
      "departure": "Nu",
      "destination": "Gröndal",
      "time": 0,
      "deviations": ""
    },
    {
      "line": "43",
      "departure": "Nu",
      "destination": "Bålsta",
      "time": 0,
      "deviations": ""
    },
    {
      "line": "142",
      "departure": "2 min",
      "destination": "Telefonplan",
      "time": 2,
      "deviations": ""
    },
    {
      "line": "161",
      "departure": "2 min",
      "destination": "Bagarmossen",
      "time": 2,
      "deviations": ""
    },
    {
      "line": "43",
      "departure": "5 min",
      "destination": "Tungelsta",
      "time": 5,
      "deviations": ""
    },
    {
      "line": "144",
      "departure": "7 min",
      "destination": "Gullmarsplan",
      "time": 7,
      "deviations": ""
    },
    {
      "line": "40",
      "departure": "9 min",
      "destination": "Södertälje centrum",
      "time": 9,
      "deviations": ""
    },
    {
      "line": "42X",
      "departure": "12:11",
      "destination": "Märsta",
      "time": 127,
      "deviations": ""
    }
  ],
  "friendly_name": "sl sl_sensor_raw",
  "icon": "fa-subway"
}

[fredrikbaberg]

The branch multi_id should provide data in that format now, if everything works as intended.

[Gr3ytooth]

I've not yet tried your latest version, so perhaps you already have implemented and solved some of these things, but I will list some of the things I thought about for my dashboard.

I live in Huddinge and want to check site-id 9527. This site offers buses and commuter trains. Even though they have the same site-id, the buses leave from two different locations (opposite sides of the train tracks). My idea was to divide it in 4 groups; trains going north, trains going south, buses on one side of train tracks, buses on other side of train tracks. One of the problems with this was that it generates four API questions, even though it's just one site-id.

I think it sounds good with one raw sensor from which you can extract things. A wish to that would be if you could make groups of lines based from that raw sensor. And in a perfect way filter on direction as well. E.g. group 1= "lines 40, 41", "direction 1", group 2= "lines 40, 41", "direction 0" . That way you could cut down on API questions but still separate and visualize your data in a nice way.

[fredrikbaberg]

That's close to what I've started with, the raw sensor extracts all matching combinations (but does not separate them afterwards). So it should only require one API call.

Some issues are:

• How should the groups of lines be represented? Nested lists/dict in the raw sensor? Separate sensors for each (sub-raw-sensors)?
• Currently I clear all data when the sensor I'm checking is disabled, to avoid old data. Does that make sense?

[Gr3ytooth]

I'm not sure I have thought enough to cover all bases and know exactly how I want it, but my first thought is to have the groups in separate sensors. That way you can more or less just print the sensor and get something useful. If it's all in the raw sensor then I guess you would more or less need a template sensor to sort the data.

One of the worst scenarios I can think of is to show faulty information. So in my opinion it's better to have a delay in presenting new information, during which no information is displayed, rather then having old/faulty information being displayed before it's been updated.

Best regards Fredrik

[fredrikbaberg]

As this repository is being archived, I'm closing the issue.