As a Developer, I would like to have a Swagger JSON endpoint for API documentation so that I don't have to write separate documentation and get nice documentation with an interactive "try out" feature.

In addition to adding the nuget-package this also requires a bit of configuration and making sure all existing HTTP methods are properly documented.
I'd prefer the swagger endpoint only being active while running in "Hosting environment: Development"

As a User, I'd like to be able to hide an engine from the engine list so that I can "ignore" an engine that isn't available for some reason without deleting it.

As a user, I would like to be able to sort engines by different criteria so that I can find my target easier.

As a developer, I would like to have Tool to generate some load on my system, so that I can get a rough estimate of the application performance.

The current LoadGenerator Tool is outdated and needs to be updated to the current PiStellwerk. I also need to define what constitutes a "realistic" usage pattern and need to deal with acquiring (locking) engines etc.

As a User, I would like to be able to configure the application so that I can use a different server and username than the currently hardcoded ones.

This includes:

• Settings Window
• Saving and loading Settings (.json file?)
• Providing the settings via some service or something.

Not included:

• Validating things like server address.

PiStellwerk as a Name isn't really fitting anymore since the Raspberry Pi part kinda fell away.
A proper logo would be nice too. Ideally this should happen rather sooner then later.

As a Developer, I would like to serve an app to users, so that I have more control over suspend/resume and can implement a more complicated layout.

Currently waiting for a somewhat ready MAUI in one of the upcoming .NET 6 Previews.

As a developer, I would like for the clients to share as much code as possible so that maintenance is as simple as possible.

Blazor WebAssembly would allow reusing a bunch of stuff. It would also add things like data binding and lowering the need for javascript/typescript.

The big question how will loading times and performance change. I'm fairly certain they will not improve, the question is how noticeable worse they will get.

Therefore a prototype would be useful.

As a User, i would like PiStellwerk to support consists, so that i can drive multiple engines together.

Requirements Phase 1

• As a user, it's clear if a steerable thing is an engine or a consist
• As a user I can quickly determine which engines are part of an consist.
• As a user, I would some kind of image to represent the engines.
• As a admin I don't want n! consist db entries for n engines.

Requirements Phase 2 (Put in separate Issue at some point)

• As a User I can quickly create new consists.
• As a User I can delete consists.

As a user, I would like for PiStellwerk to interface with DCC++ EX so that I can use hardware I own or have a low-cost alternative to more expensive command stations.

Doesn't happen on the normal desktop browser with the device emulator, only on a actual device or android emulator.
I'm certain it's caused by the softkeys being part of the screen but obviously covering the content.

Some kind of control panel.
It should be fast to create and modify turnouts and tracks
Not total free-form drawing but not just tiles

Requires #72 first

As a user of the web app, I would like to be able to switch pages, so that I can use all my engines if I own more than 20.

As a User, I'd like to Create, Update and Delete engines without editing the database directly.

(Doesn't include images)

No implementation in the webapp, only backend. Actual usage needs the Avalonia or MAUI Clients.

• One function per line
• reduce whitespace slightly

As a User I would like to be able to switch between different themes so that I can use light/dark mode as I prefer.

As a user, I would like to be able to search for an engine based on a custom string so that I can find my target easier.

For the initial implementation only searching in names is good enough, searching in Tags can be done separately.

Currently images placed in /userContent will both be used for generating other sizes and formats and for serving to clients. I would prefer if that wasn't the case.

The requirements of the two usages are quite opposed to each other. As the "golden copy", the image should be high-quality, with little or no compression, so that I can use different formats or compression ratios at a latter date.
For serving the images to clients, I want maximum compression to reduce load times.

Therefore I don't want the image from userContent served to Clients.

Some functionality should be moved around. Better documentation wouldn't hurt either.

Currently the pagination in the WebClient is non-functional.

• Think about different primary colour, green might not be ideal (Red-green colour blindness)
• Every button should use the same style ( or at least similar, tags count as buttons even thought they're not functional yet)
• Similar style for a active buttons
• Styles for pressed buttons

As a user, if my device reconnects to the backend, I would like for my session to lose the "inactive" state so that I can continue using the application.

As a user/admin, I would like a option to force PiStellwerk to regenerate all the images from the "golden record" so that I can apply new settings related to compression/formats etc.

As a user, I' would like for engines to save their datetime of creation in order to be able to find new engines more easily.

As a user I would like to be able to toggle engine functions via the desktop app so that I can use the horns on my engine.

As a Admininstrator, I would like to be able to configure the ECoS IP so that I don't have to set the ECoS to use the hardcoded IP.

As a User, I would like to be able to send a emergency stop command to an engine, so that they stop instantly instead of using the deceleration rate.

Currently PiStellwerk only utilised a shared model for things like engines across the whole application. This lead to the situation, that even Clients require EF Core and similar dependencies.

As an admin, I would like to be able to configure the location where the large original images are stores so that I can store them on bigger, slower storage.

While prototyping the Blazor WebAssembly WebClient, the staticFile middleware was reset and /generatedImages is no longer served.
Ideally #58 is resolved first.

As I developer, I would like a simple way to check if I can connect to the PiStellwerk so that I can easily check if the connection works.

As a user, I would like to change the database connection string, so that I can set options like the location of the database file.

As an admin, I would like to be able to change the location of the generatedImages directory, so that I can put it on fitting storage.

As user I want the web app to save settings (like the username) so that I don't have to change them every time.

NDesk seems like it's not developed further, last commit happened more than 2 years ago

CommandLineParser seems to fullfill a very similar goal and I've used it in other projects.

• Increase size to "full" Raspberry Pi size.

• Less dense layout => easier to solder
• Larger surface => better thermals
• • More silkscreen to make assembly easier

• Add possibility to attach USB without using the USB Isolator IC (for testing)

• • Make sure the USB thing has the correct 5k5 Resistor

• Use JTAG instead of SWD
• Add keyed debug headers and additional PCB to connect the J-Link 20 pin JTAG connector

As a system admin, I would like to be able to create backups and restore from backups without much hassle.
This would include the original images and the database data.

The inital Idea was to create a second executable for this purpose, but with the "self-contained"-deployment this would lead to two copies of all dependencies. So some kind of command line switch in TauStellwerk.Server would probably be the best solution.

I'm not quite sure how to deal with the relational data. Either just copying the .db file, or creating a json dump from the database.
Copying the database would obviously be the simpler way.
Dumping the database to a json file is a bit more complex. The big payoff I see is that I could create a more "general" export-import feature that could support things like not exporting the complete dataset or essentially "merging" two databases. If I ever wanted to add support for an additional RDBMS this would enable the transfer of a database to another system.

Possible problems:

• No database migrations touch the json, so restoring old backups in a new version might be difficult
• • Can I just say that's not supported?
• Data is denormalized
• • Might not be that bad, I think the database file isn't that efficent either, especially with little data.
• • Compression might help here

Scope:

• Can view first page of the engine list
• Can select engines
• Can control speed and direction

Doesn't include: settings, anything with images, perfect styling

On small screens, the throttle and reversers tend to get cut off.