@noelandrews said in MMM-UKNationalRail - Rail departure info for specific UK Railway stations:

I have to say - changing the " to ’ made it work for me.

    {
        module: 'MMM-UKNationalRail',
        position: 'bottom_left',
        header: 'Departures', //Optional - delete this line to turn OFF the header completely
        config: {
            stationCode: 'LNB', // CRS code for station
            app_id: '49XXX014', // TransportAPI App ID
            app_key: '1a3d4XXXXXXXXXXXceac3d9f14be', // TransportAPI App Key
            maxResults: 5, //Optional - Maximum results to display.
            showOrigin: false //Optional - Show the origin of the train in the table
        }
    },

Also using the API_ID, API_Key and Station code in the actual TransportAPI also worked. Could it be the rest of JSON config that has issues? Have you tried pasting the whole file into something like jsonlint.com to validate it’s right.

I’d STRONGLY advise you remove your API keys from the JSON. Hate for other people to mis-use your account BTW

Still running without issue this morning, although I’m now getting emails about hitting my daily API usage allowance from the Transport API.

The only errors I’m getting are ones that the module generates when it doesn’t get the expected train info from Transport API - generally around 02:00 when no passenger trains are actually running.

Sorry to say that without being able to replicate the issue, there is very little more I can do.

@randomnoise The mm_error_log file is not something I’ve come across, I assume it is the failure report generated by PM2 that lists all the times it has had to restart a service.

npm start dev displays the mirror, but also has a full JS console output running down the side of the screen. The “No departure info” message in my previous post is an example of that output.

So still running without issues.

Got all the expected “No departure info” errors in the console for the overnight period where trains don’t actually run.

Have you updated the module itself?

I used to run the mirror 2.1.2 on a RPi3, but that PI got repurposed for another project and is unlikely to make it back. For dev work I run it in either server or dev mode on a Mac. I’m running v2.1.3 on Node v8.7.0/npm v5.5.1 on the dev machine.

As it the mirror is a client-server architecture, it makes sense that the server part would be still receiving info from the Transport API. This seems to point to either Electron (UI) or Sockets.io failure rather than data ingest.

What version of Node & npm is running on your mirror? Are you running it as an all-in-one or are you running it in a different way (server only, docker)?

There is a simple “debug” : true setting you can add to the module config, but that mostly just gives the params & url that would be used by the module to contact the TransportAPI. The only other way is to launch the mirror using:

npm start dev

which will start Electron and also display a debug console on the right hand side of the screen.

OK, I’ve had my test environment running for a couple of days running both my station and your config with the provided station ID.

So far I’ve not seen the module fail to update, although the mirror itself has frozen on 1 occasion. I’ll keep trying it, but it’s quite difficult to debug without actually figuring out how to replicate it.

@randomnoise Can you tell me the station code? I can’t try to replicate or even figure out if it’s the provider without it.

@randomnoise Can you send me your config for the module? Don’t need the API keys, but the rest of it would allow me to see if it’s something specific to the data provider.

Thanks

@randomnoise Apologies, I’ve only just seen this message. I’ll try to look tomorrow and see if I can replicate the issue, but I suspect it is due to the data coming in from the Transport API. I’ve already got bugs from months ago still not addressed by them to do with bus times failing to be properly updated.

I’ve released an updated version that removes buses with a delay of more than 60 minutes from the results.

This is a hack until TransportAPI address the issues on their side. There is a side effect in that if 2 buses are delayed excessively, the module will only show 3 buses instead of the default 5.

Hopefully this will not make any difference to the majority of users.