Alerts / Changes on rail network

[sh00t2kill]

Is it possible to pull alerts for your configured routes ? eg upcoming track work, stopping pattern is changed due to running late, etc etc.

Basically, the alerts that the tripview app shows.

[andystewart999]

Interesting - I can check the API to see if it's already returning that information, or if I can do another trip-specific call. There could be a per-journey 'has an alert/alert text' attribute, although re your use case of stopping patterns changing, as the sensor only returns trips that meet your origin/destination it won't know or care about that particular journey possibly having different stops to usual, and I don't retain historical stop info.

Let me look into it though!

[sh00t2kill]

If you cant find anything, ill try using MITMproxy with the tripview app and see where it pulls that info from.

I had a quick squizz at the documentation, and it seems to mention something called Trip Updates which calls out at least some of this info.

Theres also a service alerts API which seems to have info RE track work and the like.

[andystewart999]

There's an 'infos' array within each journey leg that contains an array of Service Alerts (section 4.3.9 of the Trip Planning API technical documentation). Here's an example:

"infos": [
  {
    "priority": "low",
    "id": "ems-37581",
    "version": 4885,
    "type": "stopInfo",
    "infoLinks": [
      {
        "urlText": "Town Hall Station Escalator 6 between the concourse and Platform 4 is not available",
        "url": "https://transportnsw.info/alerts/details#/ems-37581",
        "content": "At Town Hall Station Escalator 6 between the concourse and Platform 4 is temporarily out of service.\n\nIf you need help, ask staff or phone 02 9379 4110.",
        "subtitle": "Town Hall Station Escalator 6 between the concourse and Platform 4 is not available",
        "smsText": "Town Hall Station Escalator 6 between the concourse and Platform 4 is not available",
        "speechText": "At Town Hall Station Escalator 6 between the concourse and Platform 4 is temporarily out of service.\n\nIf you need help, ask staff or phone 02 9379 4110.",
        "properties": {
          "publisher": "ems.comm.addinfo",
          "infoType": "stopInfo",
          "appliesTo": "departingArriving",
          "stopIDglobalID": "200070:2000394"
        }
      }
    ]
  }
]

The API schema says that the 'type' enum comprises of routeInfo, stopInfo, stopBlocking, lineInfo and bannerInfo. lineInfo and stopBlocking sound like the two most likely to relate to specific journey issues, so some filtering could be done, but one quick and dirty option could be to just have a new sensor attribute that contains the raw JSON for the entire 'infos' branch, and allow the user to decide what they want to do with it.

I'll see about adding then when I get some time.

[sh00t2kill]

That sounds like a good enough idea.

Could potentially add a config item for the priority of the alerts too, along with some config as to whether or not to fetch them.

[andystewart999]

Hi - I've just done a beta release (1.2.0b1) that includes alerts as an attribute. Give it a try and see what you think.

Also, do you prefer 'alert_filter', 'alert_type' or something else for the config setting that defines what types of alerts to return? I'm moving towards alert_filter, or alert_list...

For the next release when I take it out of beta I'll change the config to something like this, it's cleaner and removes issues if multiple alert types aren't separated by a pipe properly.

  - platform: ha_transportnsw
    include_alerts: normal
    alert_list:
      - lineInfo
      - stopInfo

Edit I went with alert_types for some reason :-)

[sh00t2kill]

thats great, thanks. I will take a look over the weekend.

alert list makes sense to me.

[sh00t2kill]

I quickly deployed it and dont see any alerts yet, but also there are none in the other apps either!

[sh00t2kill]

So it should be automatically pulling those alerts in right ? eg atm theres an alert for the north shore line (IIRC you are at gordon or chatswood) about a police operation at st leonards, but im not seeing anything in the alerts attribute,

[andystewart999]

If the alert type and priority meets the filter requirements then yes, they should be included.

A good test is to set include_alerts to verylow and either remove alert_types entirely (so it defaults to all) or make sure that all alerts are included:

alert_types:
  - lineInfo
  - stopInfo
  - routeInfo
  - stopBlocking
  - bannerInfo

I've just done that to my Chatswood/Gordon test route and the sensor now includes a bunch of low stopInfo alerts about the lifts.

Let me know how you go.

[sh00t2kill]

I think I may have fat fingered the config and had include_alert not include_alerts. Weird that the integration didnt explode though!

[andystewart999]

Thanks for the update, I think I can close this one now.