jacknewman12/koradmote

A simple control server for Korad power supplies

koradmote's Issues

Use the usb descriptors to list possible devices

The lower library already does this. We should be able to easily list all ports on the device that are most likely connected to a PSU.

Add error notif for failing psu

Currently if a psu is failing to update there is no warning for that individual PSU in the web interface.

Add more compile targets

Note: Use musl for linux so we can ignore the libudev dependency.

I think the target matrix should be:

x86_64-unknown-linux-musl
x86_64-pc-windows-gnu
arm-unknown-linux-musleabihf
- Whatever the Mac OS one is - 

Add -v debugging

The -v flag currently does nothing.

Would probably be nice to dump the serial ports + settings, rocket mounts, etc.

Changing threading implementation

Original feature just splits the database (containing the serial port + current status) and the combines it again once the threads are complete.

Task is to change it so that each thread takes the serial port permanently and pushes the status results to a mpsc. The receiver thread can then push the changes to the status dict (and maybe also trigger a websocket push once its implemented).

This should make it a little easier to recreate serial devices if something goes wrong with them (im looking at you windows) and means we can just poll the PSUs as fast as possible without hurting the web interface speed.

Improve Toggle / Status update error handling

Should probably make the update_state and set_power function return a Result. Currently is very rare to fail, and its mostly harmless (the next UI update will probably show the real state).

Also adding a with_context({psu_name}) would be nice

TODO: Should we retry the update? Push some information back up to the user?

Forward the entire PSU Status struct

Should be very simple to import the entire Status from the Ka3005p driver:
{"voltage":0.0, "current":0.0, "power":false}
to
{"voltage":0.0, "current":0.0, "channel1": "CV","channel2": "CV","beep": "On","lock": Unlocked,"output": "On"}

Note this ticket doesn't involve updating the web interface to show all this data. (Is this extra data even useful for the user?)
This is simply so we don't have to redefine the state struct ourselves.

Merge to Warp to compare features / overhead

I think warp might be better than rocket for such a small project.

TODO: Merge over to warp and see if it reduces the memory footprint (its only 2mb atm).
Also just curious how that library compares in features.