erichhansen / golight Goto Github PK

Create a bootstrap app to run through all the lights in sequence. This would aid in quick debugging on new machines/environments.

Not sure what is causing this. The defer leds.Close() should be fine as it will close the device when the scope of the parent function ends. Hmm.

I recommend that sendCommand is run rapidly in a loop and monitor file/resource usage in Linux and see if we can get it to crash fast.

I double we are hitting a ulimit/file handle limit -- those seem very high and with the 10s polling that would take FOREVER to hit. The limit can be seen with ulimit -n, see files with lsof and the max files with cat /proc/sys/fs/file-max.

In order to support recovery of the Delcom light unplugged and plugged back in, it would be nice if sendCommand returned an err so the caller can retry.

Or... perhaps a way to test if the device exists? Could present race conditions on when the device is unplugged during a post-test sequence of commands, though.

Seems like returning an err is the best way so the caller can handle these situations?

Include a sample of /etc/udev/rules.d rules to allow r/w access to the Delcom HID device as non-root. Ideally include instructions to reload udev (seems weird, search SO) with rebooting as well.

Seems like every usage of Flash would be accompanied by an On?