popflamingo/mannele

A Discord bot providing schedules for CTS trams and buses in Eurométropole de Strasbourg

Mannele

Mannele (Alsatian name for Stutenkerl) is a Discord bot for the University of Strasbourg students. It currently displays live transit schedules around our university (and everywhere in the city) but may evolve to provide additional data such as weather and pollution alerts or university related infos.

Docker Configuration

Installation

Linux: Install Docker.io

sudo apt install docker.io

macOS: You can install Docker desktop directly from the Docker website or using brew cask install docker

Usage

Commands to run on Mannele's directory

docker build . --tag mannele
docker run -d --name mannele mannele

Attention: Before launching the run command, be sure to have set up an .env file at the directory root where will be stored your bot's Discord token, CTS Token and Discord's Server Token. Also add the value below;

STATS_SLOT_COUNT=1

You may run this command to check out if Mannele is correctly running;

docker logs mannele

Contributing

Don't hesitate to contribute by opening issues and pull requests to help with bugs and enhancements.

Licence

This bot is licenced under the MIT License (see the LICENSE file).

mannele's Issues

Determine if embeds could provide better formatting for presenting stop times

It seems Discord embeds allow some customization of messages by adding titles, custom fields, images and more.
It probably has pros and cons compared to the method currently used (which is just posting a simple message that's formatted as nicely as possible).

Add error handler method to CommandDescriptor

The method would be passed the interaction as well as the error in order to properly handle it

Ensure that the order of destinations stays consistent

Context

In a station, for a given line, we already sort the stations with consistent directions, so if lane X and Y share the same tracks, the first destination displayed for lane X should generally be on the same side of the tracks as lane Y (as long as the CTS data enables it by properly setting the direction id).

Issue

Sometimes, there are more than one destination in a certain direction (for instance Kehl Rathaus and Port du Rhin for lane D) and it seems the order in which they are displayed varies across calls, which will be problematic for the future refresh feature.

Improve SIRI response parsing

The CTS API provides stop times and other information using the SIRI API, the responses are in JSON format.
Currently, checking that the correct fields are present is done manually with highly repetitive boilerplate code. TypeScript or libraries probably offer much cleaner way to check that a JSON file has the correct fields / structure. It would be nice to be able to define a class with the correct fields and get TypeScript to deserialize the JSON to it.

Add more details about Docker deployment

A DEPLOY_COMMANDS argument has been added and while it is currently set to YES by default to stay backwards compatible, it may change in the future so it's important to properly document it.

Retransmit CTS info messages

The bot could optionally post CTS information messages (SIRI's general-message endpoint) to a selected Discord room. This way students can be informed of live events occurring on the lanes around the university.

Support a command for lane stops schedule

Currently the "horaires station" command returns the stop times for all lanes at a given station.
In some cases one might be interested to instead get the stop times of a lane at all stations around the university, which can be useful if you are equally close to two stations served by the same lane and want to catch a bus or tramways as soon as possible.

Enable per server configuration

Enable server administrators to configure the bot behavior for their servers. This for instance includes selecting the lanes and stations provided in the commands parameter lists as well as configuring CTS messages retransmission and where they should be posted.

Create a repeating task for fetching stops and address data

Currently, this data is only fetched on bot startup, which is ok with process managers such as PM2, however some hosting platforms make using PM2 redundant, therefore there needs to be a better way to fetch the data without relying on a process restart.

Check if stop monitoring requests can be batched

They currently are not (in CTSService.ts) but from the API it looks like it should be possible, which would enable performance gains for some stations where requests to more than a single station are needed (like Ile de France and Boecklin)

Make sure of where isRequired is needed in the SIRI types

Handle API slowness

If some APIs are slow the bot must still respond quickly to the user to show it is up and running (there are specific Discord APIs for this case)

Allowlist some stations

Some stations that cause ambiguities, such as Ile de France, display a warning message when the users request them:

⚠️ Avertissement: Affichage des résultats pour 2 stations potentiellement distinctes. Voir les détails plus bas.

This message is general and was meant to automatically work whenever a case like this occurs. Yet it might be too general for cases where we are aware of what is actually going on (for instance, here, we know the two stations actually are distinct) so we should allowlist those stations, maybe even enable adding a custom help message for the users.

Refactor the stop times aggregation code

The code for aggregating stops is quite heavy and hard to understand, it must be refactored and probably also extracted to a new method since it will be useful for other API calls.

Add CTS API endpoint failure resiliency

The CTS API may sometimes fail. Currently if this happens the user won't get a clear error message. In some cases it may even look like the bot is unresponsive.

GTFS files could be used as a backup in the future to enable getting (less precise) schedule info if the API is down, this may be overkill if the CTS API is reliable most of the time.

Add TypeORM

TypeORM will be useful for persisting data such as customized stops or CTS alert delivery. For these use cases a JSON file wouldn't scale very well.

Refactor response formatting code

The code that formats responses listVehicleStops can be simplified a lot.

Ensure the database stations indexes are deterministic

It would seem that even for the same station database (same hash), the order of elements in memory might differ depending on the OS and/or Node/TypeScript version, meaning an index isn't guaranteed to be stable.

Use stations from data.ts for slash command generation

Currently slash command generation is decoupled from the data in data.ts, this means new stations must be added twice.
Making slash command generation more dynamic will also lay the foundations for future improvements where a given server can select a specific subset of stops (depending on what is relevant to the students of this server).

Add a README

A nice README should be added to present the bot

Better organize command handling code

The Discordjs library has guides on how to best structure files so that command handling code is well organized, it would be preferable to having everything in main.ts.