@callum8004 copy and paste the same module config with the information for the other station

 {
    module: 		'MMM-UKNationalRail',
    position: 		'bottom_left',
    header:			'Walsall Live Departures',	
    config: 
 		{
 		stationCode: 	'WSL',	
 		app_id: 			'fe0f5d14', 
 		app_key: 		'7de7aa1439665fef7ad6eb151190a6a1', 
 		maxResults: 		3, 
 		showOrigin: 		false,
 		calling_at:		'BHM',
 		showPlatform:	true,
 		}
 },
 {
    module: 		'MMM-UKNationalRail',
    position: 		'bottom_left',
    header:		'Another Station Departures',		
    config: 
 		{
 		stationCode: 	'BSC',	
 		app_id: 			'fe0f5d14'
 		app_key: 		'7de7aa1439665fef7ad6eb151190a6a1', 
 		maxResults: 		3, 
 		showOrigin: 		false,
 		calling_at:		'BHM',
 		showPlatform:	true,
 		}
 },

@callum8004 You have to add a separate set of configs for each station that you want to track.

I added a tweak that I came across while building a different module that means you can now specify multiple device categories. BUT, I’ve not mapped these extra categories to different states.

Basically you can now say show me the Dimmable lights & Switchable lights [2,3] in the new veraCategories part of the config, but it doesn’t differentiate between ON/OFF or a percentage value in between for the dimmable lights.

It also means that you can end up with very long lists of items that take up big chunks of the mirror!

The README in the repo lists the categories.

YMMV.

@cyberphox Personally I use more than just Z-Wave to control my house. Experience has taught me that the Veralite becomes increasingly unstable when you ask it to deal with too many other plugins or technologies. It’s also costly to implement pure Z-Wave and has gaps in offerings available in the UK.

So I use the Vera to control the Z-wave and let other technologies control their own portfolios. Using OpenHAB I can install the connectors (bindings) that correspond to the different technologies (Z-Wave, BTLE, Hue, Sonos, RFX, Plex, Xiaomi, Weather, Honeywell Heating, Harmony, Onkyo amps etc etc) and then integrate them all together through a single interface.

A Z-Wave door sensor probably costs around £30 in the UK for 1. I got 3 Xiaomi door sensors and the controller hub for £35. Adding temp/humidity sensors at £6 each is also a cheap alternative.

This means I can then write cross technology rules to control the house: If external temperature goes above a certain temperature, set the house heating to eco mode. At bedtime, boost the kids bedroom temperatures, turn on their hues and various fairy lights… and then turn it all off again at lights out. I can integrate presence detection across multiple detectors (Z-Wavre PIR, RFX PIR, BTLE, Wi-Fi) and adjust things accordingly.

You can do the same stuff with Home Assistant. Both platforms have a learning curve (OpenHAB more so), but personally I find it gives me much more options.

Simple concept module is here, but it is only a concept/prototype, I’m not planning on taking it any further at this point. If anyone else wants to, they can fork the repo and do with it as they please.

Currently only displays Category 3 (Switchable Light) devices. No other options.

Looking at the possibilities of this, it’s NOT complicated to get the information back from a Veralite.

My ‘simple’ setup lists 12 rooms, 65 devices, 1 scene and 9 categories.

The complexity lies in either displaying it in a meaningful way or providing a configuration capability that allows a users to specify their needs.

• Do we group by room or category? Both? Nested how?
• Are all rooms required?
• Are all categories required?
• Are all devices required?

Personally I control my Vera via OpenHAB and others use Home Assistant. Have you considered those as options and then linking them to the Mirror via their existing modules?

Information on Simple UI based on HTTP requests is here - http://wiki.micasaverde.com/index.php/UI_Simple

@randomnoise Glad you got the answer from Transport API.

I had a quick look at the code, but not having a Pi/Mirror available to run soak tests I’ve not been able to fully test it.

I’ll drop the edits.

N

I suggest your best bet is to log an issue with TransportAPI as they might be able to identify if the issue lies with them or with the info coming through from the train operator.

@yawns Explains why my email had the key and the post was XXXXXX.

Thought I was losing it!

@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.