Looking for dev confident with JSON and Linux CLI skills for DMX lighting project

We are looking for a developer that is confident working on Linux via CLI, parsing JSON from an API, and using that data to generate numerical values in a controlled fashion (data values on multiple timers/delays, increasing/decreasing, etc) that will be passed to a local application by way of a standard pipe. These values are lighting intensities that will be used to control operation of LED lighting. On the Linux device, we are running Debian 8 on a custom embedded ARM board. This board interfaces with lighting control components using a protocol called DMX512 (or commonly known as DMX for short). Software to control the DMX bus is Opening Lighting Architecture (aka OLA). All configuration of hardware and OLA is pre-completed, so only interaction/work needed with OLA at this point is to give it DMX values through the following method: “ola_streaming_client” - CLI utility that allows passing any number of DMX frame updates per run. Application runs as an open data pipe to “olad” and allows for any number of values to be passed. Ex: /path/to/some/script_you_write | ola_streaming_client -u 1 This means any DMX values that are generated by the “script” are passed directly to the DMX universe 1. Same scene as defined above, but in this case, instead of a call to the CLI utility for every DMX update, we run the utility once, and send all value updates directly via the open pipe between applications: 0,0,0,0 64,64,64,64 For actual implementation on the CPE, the most basic description is “anything you can do in the web portal should work on the CPE”. Meaning, all controls in portal for scenes should then result in those actions happening on the CPE’s attached fixtures as per configuration in portal. From a JSON standpoint, the scenes (duration, assigned fixture/fixture group, schedule) are what will drive action on the CPE, with other included elements being simply relational so we know what channels in which to apply the scene actions. Specific implementation items: 1. Items scheduled in portal must be schedule on CPE. If a scene is scheduled for a specific date/time, we want to ensure the CPE fires that scene at the appropriate time. All system clocks are synced with NTP, so we have generally good precision minus some expected clock drift, but again pure accuracy of start/end is not required (not your concern directly, just a note). Scene elements must be implemented: a. Color - Setting a color on the fixtures (directly or by way of fixture group) should be simple, taking the passed RGB value to the appropriate channels for the fixture(s) (mapping RGB to channels 1,2,3 for example if so configured) b. Fade - This may pose to be the most difficult scene element to implement. A fade on multiple channels will not always be the same number of steps per channel to get from color A to color B. Example RGB values 10,100,50 to 20,200,250 would mean difference in color values of 10,100,200. To fade between the two A/B colors, would mean probably seeing how many seconds the fade should take, finding how many steps from A to B values within those seconds, and firing off the number of interim steps per second (calculated delay between DMX value updates) required to make the transition. Care must be made to do the highest number of steps from A to B to give better resolution and visual transition, but while still keeping within the specified time constraints for the fade. c. Sleep - Simply doing nothing for the configured number of seconds d. Blackout - Setting all fixture channels to a value of “0” e. Loop - Restart running scene elements from beginning again, but keeping a count of how many times we’ve looped through as eventually we’ll get to the number of loops configured and need to stop.