elpollouk / itokawa Goto Github PK

thanks for sharing your code,
I have tried running this on an elink R8311 but receive the following errors:

2020-04-25T04:13:59.437Z:ERROR:Application: CommandStationError: Unsupported eLink version encountered, version=105
at ELinkCommandStation.
(/home/pi/Itokawa/Itokawa/dist/devices/commandStations/elink.js:347:23)

and also this error keeps scrolling through, is this a pi configuration issue?

2020-04-25T04:14:10.896Z:ERROR:Application: Command station error
2020-04-25T04:14:10.898Z:ERROR:Application: Error: Error Resource temporarily unavailable Cannot lock port

As a developer, I want to be able to specify persistent test command station settings so that I don't have to keep specifying command line args.

This will require updating application._openDevice() to check the config for command station settings.

As a new user, I want to know how to set up Itokawa.

As a Raspberry Pi user, I would like to be able to back up my loco and config data so that I don't lose everything if I suffer an SD card file system error.

This will also need a corresponding restore feature.

Files that need backing up:
~/.itokawa/data.sqlite3
~/.itokawa/config.xml - If present

Process should zip these files and present them as a download.

As a server admin, I want to be able to create scripts for interesting action sequences.

These scripts will need to included in back up zips created by Itokawa.

1. Start CLI with eLink plugged in
2. Unplug eLink
3. Execute exit command

Following callstack reported:

dcc> exit
Error: Port is not open
    at SerialPort.close (C:\Projects\Itokawa\node_modules\@serialport\stream\lib\index.js:426:29)
    at C:\Projects\Itokawa\dist\devices\asyncSerialPort.js:87:24
    at new Promise (<anonymous>)
    at AsyncSerialPort.close (C:\Projects\Itokawa\dist\devices\asyncSerialPort.js:86:16)
    at ELinkCommandStation.<anonymous> (C:\Projects\Itokawa\dist\devices\commandStations\elink.js:103:30)
    at Generator.next (<anonymous>)
    at C:\Projects\Itokawa\dist\devices\commandStations\elink.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (C:\Projects\Itokawa\dist\devices\commandStations\elink.js:4:12)
    at ELinkCommandStation.close (C:\Projects\Itokawa\dist\devices\commandStations\elink.js:99:16)
dcc> exit
TypeError: Cannot read property 'close' of null
    at C:\Projects\Itokawa\dist\devices\asyncSerialPort.js:87:24
    at new Promise (<anonymous>)
    at AsyncSerialPort.close (C:\Projects\Itokawa\dist\devices\asyncSerialPort.js:86:16)
    at ELinkCommandStation.<anonymous> (C:\Projects\Itokawa\dist\devices\commandStations\elink.js:103:30)
    at Generator.next (<anonymous>)
    at C:\Projects\Itokawa\dist\devices\commandStations\elink.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (C:\Projects\Itokawa\dist\devices\commandStations\elink.js:4:12)
    at ELinkCommandStation.close (C:\Projects\Itokawa\dist\devices\commandStations\elink.js:99:16)
    at C:\Projects\Itokawa\dist\cli\main.js:53:31
dcc>

Exit command doesn't work

As a layout owner, I want to be able to set an admin password to protect sensitive operations.

This is a stop gap measure to set an admin password in config.xml until it's client UI is implemented. The password should be bcrypt or script hashed in the XML. The tool should directly read the password from stdin without echoing it back to stdout while being entered.

Repro steps:

1. Open the demo site
2. Navigate away from the root page and back a couple of times

There will be multiple instances of the root page in the DOM, translated off the left side of the screen.

As a Itokawa server maintainer, I want to be asked if I want to restart the server after an update so that I can update both the application and OS in one go.

With the new life cycle lock, it's now safe to perform a restart at any time. This can be triggered by a request from the client UI, simplifying the server updater logic further.

As a train driver, I want easy to interpret button actions in a compact space.

As a developer, I want to be able to push out updates for testing without impacting stable branch users.

This will require creating specific branches for version point releases, latest stable and latest test.

As a layout owner, I want to prevent guest users from modifying the train roster or shutting down the server.

Things to restrict to admin users only:

• Adding, removing, modifying locos on server
• Access to the loco roster in client
• Access to server update, shutdown, restart on server
• Access to server menu in client

Admin mode should be locked behind a password and once a session has been granted an admin token, it should be valid for both web socket and REST API requests. Admin restricted items should be hidden in the client UI if the user has not enabled admin mode. Admin tokens should persist between Itokawa reboots but have a maximum life time (TBD).

Using "LIKE %abcd%" is really inefficient, we should switch to using SQLite3's FTS capabilities instead.

Example gist:
https://gist.github.com/elpollouk/b60a3758a6bde1a8b58a5c97a642ed08

As a train driver, I don't always want my device to go to sleep so that I can make quick adjustments in an emergency.

Wake Lock API is currently in trial until April:
https://web.dev/wakelock/

As a UI developer, I want to use something like SCSS to simplify the task of maintaining the CSS.

As a code maintainer, I want as little logic in Application as possible to reduce the amount of untested code.

As a code maintainer, I want as little logic in Application as possible to reduce the amount of untested code.

As a space conscious user, I'd want the Sqlite database periodically vacuumed.

This can just be a boot counter stored as a KV setting in the DB and then running the vacuum command every N(20?) boots after loading the DB.

Looking at the initial error in issue #20, the error Error Resource temporarily unavailable Cannot lock port is reported in a loop. This is probably caused by the serial port not being closed when the initial handshake error is raised.

Adding automatic device closing after an error in application.ts should make this more robust across all future command station implementations.

As an Itokawa dev, I want a way to prevent user triggered shutdowns and restarts while a sensitive operation is in progress to prevent accidental corruption of local data.

This could be implemented as a simple semaphore style counter on the application object.

• When a sensitive operation starts, it requests to increment the counter.
• When the operation completes or fails, decrement the counter.
• If a life cycle change request is made and the counter is non-zero, reject it.
• If a life cycle change request is in progress, reject any requests to increment the counter.

As a normal user, I don't want to install and build everything when there are no new changes to pull.

As a first time user, I want an initial OOBE to guide me through set up and adding my first locomotive.

As an Itokawa maintainer, I want to be able to restore a backup by dropping a zip file onto the exposed file share.

At boot, Itokawa should check for the presence of restore.zip in the data directory. If present, it should extract config.xml and data.sqlite3 and then rename the zip file to _restore.zip.

adm-zip looks like the best option for this.

As a Loco Tweaker, I want to be able to specify smaller ranges to read so that I don't have to wait for the full set of CVs to be read.

This is most useful for working with decoders like the ESU LokSound 5 that has the ability to auto configure CVs related to back EMF control.

As a developer, I want to prepare the database for searching so that I don't have to perform the needed schema update in the future.

Add an indexed text field that contains a concatenation of the locomotive address and name. In the future, if we need to search for a loco, we can use this field without having to unpack the JSON.

The save and return after updating a loco is outside the if statement meaning that only the first loco in the roster can be updated.

As an Itokawa developer, I want as close to 100% test coverage as possible.

With #85 and #86 completed, the remaining code in application.ts should be fairly straightforward to test as it's mostly initialisation code and property getters.

As a loco driver, I want to be able to control speed, direction and functions from the loco panel.

I also want to add a speed display and single step speed adjustments to make matching loco speeds easier.

The regex /EADDRNOTAVAIL/ should be updated to /(EADDRNOTAVAIL)|(ECONNREFUSED)/.

As a train configurator, I want to be able to set up macros that drivers can use to trigger a sequence of actions.

As a developer, I'd like to be able to connect the CLI to an running Itokawa server so that I can manually issue commands for testing.

This could also be used for running simple scripts without a web browser.

As title

As an Itokawa server maintainer, I want to be able to update the OS without needing to SSH into the server.

This needs a new life cycle command which should run:
sudo apt-get update && sudo apt-get -y dist-upgrade && sudo apt-get autoremove.

As a train driver, I want to be able to filter the full locomotive list down to only usable locomotives.

Views should be:

• Created by an admin.
• Persisted to the database.
• Selectable by a guest user.

As a CV Reader, I don't want to have to wait until all the CVs are read if I accidentally start reading the full list.

This will require proper command status tracking on the server side so that the client can issue an out of band request to cancel another command it has started.

As a web interface user, I want to know the following details:

• Server version
• Server code hash (with link to commit)
• Command station type and version
• Number of currently connected clients

As the CSS styling of buttons is minimal, they are very rounded and not properly centred on iOS.

As a new locomotive purchaser, I want a convenient way to run-in my new loco.

This can be a simple procedure launched from the loco setup screen that will run the loco forward for X minutes and then backwards for X minutes.

A progress/time remaining bar would also be helpful for keeping track of how far through the run-in we are.

The eLink heartbeat messages are to bit too frequent to be useful. Adding a verbose log level between info and debug should make logging a bit more manageable.

As an Itokawa developer, I want a single class to encapsulate the life cycle API so that it's easier to cover with tests.

Creating a dedicated life cycle class will allow for testing as it would be independent of the non-automated Application singleton.

The current favicon needs updating to remove text.

As a train driver, I want to be able to run scripts created by the server admin.

To run the scripts, the CLI script executor will need to be made available to the server. Script commands will need to be organised into guest and admin commands to that the users privileges can be checked when running them.

As a train driver, I want see if someone else has adjusted the control of my train so that I can take corrective action if necessary.

This will require the server to broadcast speed changes over all the WebSocket connections and a request to query current speeds.

As an admin, I want an easy way to configure the server port and enable/disable ngrok publishing

As a loco maintainer, I want to be able to re-order the loco list to allow me to move my favourite locos nearer the top.

As a loco driver, I want to be able to issue an emergency stop from any screen.

This change would also address the issue of the emergency stop button being pushed off the bottom of the main screen when there are a large number of locos available.

As a train configurer, I want to be able to read and write CV values to and from locos.

Repro Steps:

1. Select Trains
2. Click "New..."
3. Fill in some train details
4. Click "Functions"
5. Click "New"
6. Set the function name
7. Click back

Result:
Details entered on the loco setup page will have been lost.