Yeah - I’ve always found the express generator adds more stuff than I’d normally like. Then again, I rarely aim to develop a full fat webapp, and I usually use restify instead.
Train/Bus departures board
Looks a bit shonky at the mo, but has real live data.
Need to squeeze the layout a bit so it all fits - and make space for the other bits.
@systems @tomnewsom … or … someone! Can I hook into the membership system for events? Also, discourse?
It’s configurable so you can have as many bus stops as you like.
I assume the calendar is just the google calendar as per here
1 Like
the systems guys are a bit busy with tool control right now, but @unknowndomain (membership system original author) might be able to help get the event stream to you.
I might have a play with this tonight if there’s time. Is there a USB-RS232 in the space somewhere?
I have some experience with these displays… I have reverse engineerd once the communication for it an still have the classes in php if you need it. But I guess we can easily convert it to typescript if that’s what you prefer
Also I might have an extensive documentation on the full protocol somewhere down to pixel animation. Just need to find it
It shouldn’t be hard to link with tfl’s api
I’ve just granted you access to the Github so you could transfer the repo into that place.
As for the screen, looks like a good start but one of the things I was trying to avoid when I was doing this was not displaying it how it’s shown on Countdown, but instead show when the next of each bus is coming.
I find it incredibly frustrating at the bus stop that I can see the next 9 buses, but actually all I want to know is when the 42 bus is coming. In otherwords show them by route/direction rather than by stop, and collate the information so you can put:
468
To Camberwell Green in 3 minutes
To Elephant & Castle in 7 and 12 minutes
To South Croydon in 9, 15, and 22 minutes
etc…
That with a better display layout would be brilliant.
The calendar is that which you mentioned.
The events log has no API but I can provide one relatively easily, what do you want to display?
1 Like
Yes, sorting by route would be fantastic
1 Like
Awesome!
Yep, definitely on my radar. As you spotted, I have literally just pulled it out of Countdown (or rather the new Unified API which proxies it) - just to sketch it out. Plan would be to do the same for trains if feasible. Apart from anything, it eats screen space up.
For events… I’d probably display the name of the last activity and time, if it’s within the last, lets say, 2 hours. It’d also be nice to be able to get a websocket stream off it rather than polling, so we could ping up welcome messages when the door is opened (for example).
Also hoping to add something to display calendar events - e.g. if there’s an event taking place now, have a banner saying “welcome to $event” or something - as well as the next things that are happening. I’m trying to build an iCal interface for that right now, but if there’s a better way (I’m sure its something that’s come up before) I’m all ears 
Merry morning!
Thanks to @unknowndomain this is now on the southlondonmakerspace github https://github.com/southlondonmakerspace/slms-dashboard
Yesterday I made the bus routes be grouped by line number and towards - plus the logic required to make a nice display of number of minutes (though, some work still required to put commas and ‘and’ in the right places!).
Also after a quick chat with @tobyspark last night, I’ve started working towards making it modular - now there is a widgets folder into which you can create new widgets. Eventually, the idea is that members can do pull requests to add new functionality by creating new widgets in this folder.
NB: the below is what I’m aiming for, not what actually works right now!
The structure is pretty straightforward - you have a widget.html for the partial HTML, a routes.js for adding new routes in, and a public folder with script.js and style.css which get included when the widget is loaded.
There’s an application global set of library functions that you can use in your widgets (in /lib) but you should also be able to use the lib folder within the widget to a similar effect.
TODO: work out how to programmatically define layout, and how to define pages which can be flipped between carouselle style.
TODO: work out how to store widget specific config, not just the application level libraries.
2 Likes
Nice.
Oh, the hours I’ve lost on code to format / lay out text nicely…
“Can’t we just redesign English instead? It would be less work.” 
1 Like
I’ll be honest any information more than what is currently displayed needing multiple pages is probably going to be annoying like at the station when you have to wait for it to stop showing information about “storm lolcat” affecting trains, when actually you want to know when is the train.
What I am saying is maybe keep it simple and if necessary just have another dashboard screen for that.
I don’t think the tube status is that useful, but if it is you should put in the status from Thameslink and Southeastern.
Really KISS, Keep It Simple Stupid!
Well, the code to get the status from any TfL service is basically the same - I’ve just picked the Tube ones because it seemed to make sense to get started with. Certainly I have often travelled on the Victoria line to get to/from SLMS. If I make it configurable so we can pick a selection of relevant TFL service statuses to display, that might make the most sense.
Disruption alerts are useful, I can get them off the LDBWS - but I’d display them above the box for train times so they’re not obscuring anything (there was one yesterday, worked pretty well).
Also I’d like to further aggregate the buses so that it groups busses that are going in the same direction - but I’m not sure how to do that right now without obscuring the fact that some busses go towards the same place, but take different routes.
Oh and as for information overload @unknowndomain and @tobyspark ; we had the thought of having this dashboard on the screen in the social area if nothing else is plugged in.
Having thought about that, maybe that needs to be it’s own thing - that could display the dashboard sometimes, but also other ambient things like flickr photos and mugshots and stuff.
I think the dashboard, as is, should have travel information, calendar events (now and coming up soon) and maybe some display of telemetry events (doors opening, etc). I think that can all fit reasonably comfortably. Could even be in portrait. Could go on a small-ish screen somewhere not too imposing, preferably near the front door.
Group by route, then destination.
68 > Camberwell
68 > Euston
68 > West Norwood
196 > West Norwood
196 > Vauxhall
That will cause screen burn on what is a nice TV, why not use an old LCD by the door, on the wall instead?
Make it move!
I think he floated the idea and rejected it in the same post. It seems a bit wasteful anyhow to have a large screen like that permanently drawing power?
2 Likes
It depends on the value that what is displayed brings. I have a plan, but it is in the background. Chris’s efforts are helping, as it can bring a code-framework for doing displays. (If we wanted / had a Mac attached, and we didn’t mind something that only I have a the code for, we’d have had something years back!)