Major disruption at Paddington causing crash

[jruys]

“Major disruption” at PAD today. That’s the station my board is showing and (I guess) somehow the software doesn't like what its getting from the API.

[jruys]

Update: 2 minutes later board started running again, all 3 entries showing “delayed” or “cancelled”.

[CalamityJames]

I believe I have added a try block for this error, however as it doesn't happen that often there isn't much real world testing that can be done here!

I made a few changes to how the drawBlankSignage function works, allowing it to display that there has been an error parsing the data, if the newly added debug mode is enabled.

If debug isn't enabled, it falls back to the Out of Hours station name, as we can't fetch the actual station name as there has been an error getting data from the API.

I did originally show this error message at any time, but I would imagine real departure displays wouldn't be verbose unless there was a debugging mode enabled, so added an if for debug.

It also should log the error to the console too.

I did consider writing a routine to temporarily speed up the refreshTime if an error like this occurs, but that might be out of the scope of this bug so decided against it for now!

I haven't submitted this a pull request yet, but feel free to check out the changes on my branch: https://github.com/CalamityJames/train-departure-display/tree/handle-openldbws-error

Will wait for @chrisys input to submit a PR!

[metacurb]

Can I suggest that if we go down this route we put it behind a config? I'd much prefer my display to not update so that there's a more graceful degredation

[CalamityJames]

That's a fair point, as it stands I think that by the point the loop has got here the old departure data will have been unset, I will try to have a play around this evening to see if there's anything that can be done

[CalamityJames]

@BeauAgst I have added a variable that gets written to each time there is good data which can be used in the event of API failure.

I left the original error handling in, in case the display gets started and there is no good data at all

CalamityJames@e73754a

Obviously if there is an extended downtime this data just plain won't update until there is any more data, but I don't think there's an easy way to sanity check that.

I guess you could add an indicator in an unused part of the display to indicate it's not using live data, maybe just an asterisk on the clock line or something. Open to suggestions!

[chrisys]

I think I'm of the view here that if we have good data (even if outdated) we can show it, but like you say if we start the display and there's no good data at all it's good to show the error message.