Deployment Best Practices

Arrows & Display Conventions

Cloud Display Devices support directional arrows to guide operators to the correct pick or put location. Use arrows consistently across your deployment to reduce training time and minimize mispicks.

• Arrow direction — Always orient arrows relative to the operator's perspective, not the rack. Left means "look left from where you're standing."
• Display lines — Use Line 1 for the SKU or item identifier, Line 2 for quantity, and Line 3–5 for supplementary info (bin, lot, description).
• Font size — Keep critical information (quantity) on a line by itself so it renders in a larger font.
• Color coding — Use color to indicate priority or zone, not to encode data the operator must memorize. Green = go, Red = alert, Yellow = caution.

Pilot Design

A well-designed pilot validates both the technology and the workflow. Follow these guidelines:

1. Start small — Deploy 10–25 Turbos on a single aisle or zone. This is enough to prove throughput improvements without requiring full warehouse integration.
2. Pick a representative workflow — Choose a process that reflects your highest-volume or most error-prone workflow. The pilot should demonstrate measurable improvement.
3. Measure baseline first — Record current pick rates, error rates, and training time before deploying Turbos. You need a comparison point.
4. Run for at least 2 weeks — Operators need time to adjust. First-day metrics are not representative of steady-state performance.
5. Assign a champion — Designate one person on-site who owns the pilot, collects feedback, and communicates with Voodoo support.

REST vs QueryString Integration

Voodoo supports two integration approaches. Use REST when your environment supports it, and fall back to QueryString for simpler or more constrained clients:

import requests

url = "https://www.voodoodevices.com/api/device/D4F660:AFA0CB/"
headers = {
    "API-KEY": "YOUR_API_KEY",
    "Content-Type": "application/json"
}
payload = {
    "line1": "SKU-1234",
    "quantity": 5,
    "color": "green",
    "arrow": "left"
}

response = requests.post(url, json=payload, headers=headers)
print(response.json())

# Light up device D4F660:AFA0CB with SKU and quantity
curl -H "API-KEY: YOUR_KEY" \
  "https://www.voodoodevices.com/api/D4F660:AFA0CB/message/SKU-1234~Qty:5/"

LED Color & Light Usage

LEDs on Cloud Display Devices provide visual cues that operators can see from a distance. There are two common ways to use color, and it is important not to mix them in the same workflow.

• Picker-assigned colors — In many deployments, each picker follows one color so multiple pickers can work in the same area at the same time. If you use this model, let each picker choose the color they will follow. Do not assume everyone sees every color equally well.
• Status colors — In other workflows, colors communicate meaning. A common pattern is Green = active pick, Red = error or alert, Yellow/Amber = caution, and Blue = informational or replenishment.
• Off — No action required. Don't leave LEDs on when not in use — it creates visual noise.

Battery Optimization

Cloud Display Devices are designed for long battery life, but display and LED usage patterns affect longevity. Follow these guidelines to maximize uptime:

• Don't worry about the e-paper display — The display itself does not consume extra power just because text remains visible. Battery drain is mainly caused by LEDs and radio activity.
• Turn off LEDs when work is done — The LED turns off when the operator pushes the button or when you send a Kill command through the REST API. Once the LED is off, the device returns to its static display behavior as described in the Commands vs. Statics guide.
• Monitor battery levels — Enroll your email address to receive notifications or use the device endpoint to check battery levels proactively. Replace or recharge before levels drop below 20%.

Request Efficiency

These practices help your integration move updates through the server more efficiently, especially when many devices are involved.

• Use the plural devices endpoint for bulk work — You can send bulk commands or bulk static updates to /api/devices/ as a JSON array. This can save time when updating many devices together.
• Reuse connections in your code — The biggest time savings usually come from reusing the same HTTP connection or session object for multiple requests instead of opening a new connection each time and paying for DNS lookup, TLS setup, and other connection overhead.

Operational Guardrails

These guardrails help prevent common deployment issues:

• Error handling — Always check HTTP response codes. A 200 means the server accepted the command; it doesn't guarantee the Turbo received it. Use the closed-loop system for confirmation.
• Location naming — DeviceIDs are assigned at the factory. What you control is the location naming in your WMS, Big Block, or alias mapping. Use a consistent location format such as Zone-Aisle-Position (e.g., A-03-12).
• Test in staging — Where possible, test integration changes against www.voodoodevices.com (hosted, multi-tenant) before deploying to self-hosted Big Block in production.