Deploying New Boxes

For phase II of the project (late April) we need to discuss how to deploy new access boxes.

What the user experience should look like for MakerSphere staff:

• This must be accomplished by non-technical staff.
• Open Nexudus and pick the machine that will receive the new access box.
• Look at the machine's properties (on Nexudus) to see what kind of relay it needs (e.g. amperage and voltage).
• Select a prebuilt access box with an appropriate relay, or have a technical person build one for you.
• Open the access box.
• Connect the Arduino unit to the computer (the regular staff computer) with a USB cable.
• Copy the machine's unique id that is in its properties on Nexudus.
• Open the deployment wizard. (***)
• Paste the machine's unique id. Click to start deployment process.
• Deployment wizard writes the necessary UniqueMachineId.h file for the Arduino code, compiles the Arduino code, and uploads the bytecode to the Arduino unit.
• Deployment wizard reports the result of the deployment to the user (success or error).

Requirements for the Deployment Wizard:

1. Ask for the unique machine id.
2. Write the UniqueMachineId.h file.
3. Run the Arduino compiler.
4. Run the Arduino deployment executable.
5. Display a status message to the user.

Options for implementing Deployment Wizard:

1. Run a local Python server on the staff computer.
   1. Pros:
      1. It's Python so it will run on any operating system (Windows, MacOS, Linux, etc.).
      2. We can put a link in Nexudus to the URL "localhost" so users don't have to leave Nexudus to activate it.
      3. We might be able to put a link within Nexudus that sends the unique machine id automatically inside an HTTP GET request.
      4. The server would just run on localhost and not interact with other servers. Doesn't even need internet access.
      5. It can run local executables.
   2. Cons:
      1. Staff computer required to have Python installed.
      2. Must keep documentation on how to autostart the server for a few different operating systems. We can probably ask IT to update the scripts and instructions but we should write the first ones.
      3. Requires 3rd party libraries which may "need" updating or become incompatible because of an update.
2. Program written in C++ run on the staff computer.
   1. Pros:
      1. Being in C++ it can be compiled for any system (Windows, MacOS, Linux, etc.).
      2. It is likely to be easily supported since there is a lot of support for C++ on the internet.
      3. Staff can easily run the program since it (or its icon) can live on the desktop.
      4. Does not depend on 3rd party libraries, which may need updating or getting ruined by an update.
      5. Runs locally on the computer and does not rely on internet technology.
   2. Cons:
      1. Must be compiled. This means installing a compiler on the staff computer, which is not ideal.
      2. Can't be linked to directly from Nexudus.
3. Separate Raspberry Pi running a Python server.
   1. Pros:
      1. Doesn't matter which OS the staff computer is running.
      2. We can put a link in Nexudus to a specific IP address (local router only) so users don't have to leave Nexudus to activate it.
      3. We might be able to put a link within Nexudus that sends the unique machine id automatically inside an HTTP GET request.
      4. The server would not interact with other servers. Doesn't even need internet access.
      5. It can run local executables.
      6. Theoretically can stay powered on indefinitely.
   2. Cons:
      1. Requires a separate machine with a separate OS that staff will not be able to support.
      2. Raspberry Pi requires proper shut down for integrity of memory / hard drive. Does not like sudden power outages.
      3. Relies on network connectivity would be more easily implemented as option #1.
4. Connecting Raspberry Pi directly to staff computer.
   1. Cons:
      1. While this addresses some of the cons of option #3 it is simply a complicated combination of options #2 and #3.