Configuring Ignition Maker Edition as a Kiosk Display

Overview: Kiosk Displays on Ignition Maker Edition

Ignition Maker Edition is positioned for personal, non-commercial use with restrictions defined in its End User License Agreement. Deploying it as a permanent wall-mounted or countertop kiosk is a common home-automation pattern: a small single-board computer or low-cost tablet loads a Perspective project at boot and remains on screen indefinitely. The two modules typically evaluated for this role are the Workstation module (native launcher, integrated on-screen keyboard, kiosk window manager) and the Perspective module (browser-based HMI served from the Ignition gateway, with native iOS and Android applications). For platform documentation, refer to the Inductive Automation documentation portal and the product pages.

Licensing Constraints for Maker Deployments

Maker Edition is licensed under specific terms around revenue, headcount, and use case. Any kiosk deployment must remain inside those terms:

• Annual gross revenue from activities tied to the deployment must stay under the published Maker threshold.
• Workforce (including founders and contractors) must remain under the published Maker cap.
• The deployment cannot be used to deliver paid services to external customers.

Installing additional modules on a Maker gateway that introduces commercial capability may violate the EULA. Treat Workstation availability as a gateway module flag, not a license to redistribute the resulting display. Re-check the current EULA before extending the system or scaling the deployment beyond the personal-use scope.

Module Selection: Workstation vs Perspective

For home automation, Perspective is the practical path on Raspberry Pi or low-cost tablets. Workstation is favored when a full Windows host is acceptable and the on-screen keyboard behavior must be deterministic across reboots. Custom Chromium kiosks can approximate the Workstation experience, but the browser's on-screen keyboard surface area is limited and inconsistent across Wayland/X11 sessions.

Hardware Selection for the Kiosk Host

Three hardware classes appear repeatedly in field reports for Maker Edition kiosks.

Raspberry Pi Class (SBC + Touchscreen)

A Raspberry Pi paired with the official 7" DSI touchscreen is the most cited low-power option. Power consumption is in the 5-15 W range under typical Ignition client load, low enough to leave on 24/7 without thermal concerns. Display options:

• Official 7" DSI touchscreen (800x480 or 1080p revisions): single-cable solution; plastic bezel and surround kits exist for kitchen or panel mounting.
• Third-party HDMI capacitive touchscreens (10-15"): better for wall mounting at viewing distance; require separate USB touch cable.
• DSI vs HDMI trade-off: DSI is cleaner but exposes a touchscreen handshake race during kernel init; HDMI is more compatible with mainstream Linux drivers but uses two cables.

Low-Cost Android Tablet

An Amazon Fire HD tablet running a side-loaded Perspective APK is the cheapest production-quality kiosk. Considerations:

• Side-load the APK by enabling Install Unknown Apps from a local file manager.
• Disable or uninstall Amazon's launcher to prevent returning to the Fire OS home screen on reboot.
• Use a charging-only cable or always-on USB power to keep the tablet at 100% SoC; sustained display brightness is the primary heat and battery-aging factor.
• Lock the Wi-Fi profile so the tablet cannot roam to a neighbor's network.

Repurposed PC or Mini-PC

If a Windows host is already available, the Workstation module removes the Chromium auto-launch configuration entirely. A NUC-class device draws more power (15-35 W) but supports Workstation's integrated on-screen keyboard without browser quirks and adds native USB and serial support that a Pi lacks without adapters.

Raspberry Pi Kiosk Configuration

Prerequisites

• Raspberry Pi 4 or 5 with Raspberry Pi OS (Lite or Full, 64-bit recommended). See the Raspberry Pi documentation for the current OS image.
• Official 7" DSI touchscreen or compatible HDMI touchscreen.
• Persistent power supply: 5V/3A minimum for Pi 4; 5V/5A recommended for Pi 5 under touchscreen load.
• Network reachability to the Ignition gateway. Ethernet preferred; Wi-Fi is usable but adds boot-time variance.
• A Perspective session URL recorded from a normal browser load.

Install Chromium and Dependencies

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y chromium-browser unclutter lightdm
sudo raspi-config
# Display Options -> DSI resolution to match the touchscreen
# Boot Options -> Desktop / CLI -> Desktop Autologin

Configure Chromium Kiosk Launch

Create an autostart entry that strips all chrome and locks the session to the Perspective session URL:

mkdir -p ~/.config/lxsession/LXDE-pi
cat > ~/.config/lxsession/LXDE-pi/autostart << 'EOF'
@xset s off
@xset -dpms
@xset s noblank
@unclutter -idle 0.1 -root
@sleep 10
@chromium-browser --noerrdialogs --disable-infobars \
  --kiosk --check-for-update-interval=31536000 \
  --disable-pinch \
  --overscroll-history-navigation=0 \
  --password-store=basic \
  https://gateway.local:8043/web/perspective-client
EOF

Replace the gateway URL with the actual Perspective session URL on the Maker gateway. Pull the session ID from a normal browser session by copying the address bar contents once the project is loaded. The sleep 10 line gives the gateway and DSI touchscreen time to finish initializing before Chromium launches; reducing or removing it is the most common cause of first-boot blank screens.

Lock Down the Browser

Reduce the chance of a user breaking the kiosk by blocking navigation away from the launch URL:

• Add --disable-features=TranslateUI to suppress the translate banner.
• Use --password-store=basic to avoid keychain prompts on boot.
• Persist a Chromium policy in /etc/chromium/policies/managed/ restricting allowed origins to the gateway hostname.
• Set the X11 keyboard layout explicitly in /etc/default/keyboard to avoid layout drift after a power loss.

On-Screen Keyboard Options

The on-screen keyboard is the single largest usability gap in a Chromium-based kiosk. Built-in browser virtual keyboards are inconsistent, and most third-party JS keyboards do not integrate with form-element focus inside a Perspective view.

Auto-Launch and Boot Diagnostics

Field reports on Raspberry Pi identify several boot-to-autolaunch failure modes. Use the following matrix as a first-pass diagnostic.

Verification Checklist

1. Power-cycle the host three times consecutively and confirm the kiosk comes up without intervention each time.
2. From a separate device, confirm the gateway Perspective session URL resolves and returns HTTP 200.
3. Open the Perspective project on the kiosk and exercise every text input; confirm the on-screen keyboard appears and submits.
4. Disconnect and reconnect the gateway network; confirm the kiosk recovers without manual reload.
5. Verify Maker Edition license banners in the gateway status page remain within limits (tag count, client count, revenue).
6. Touch every screen region; confirm input is mapped within 5 pixels of the cursor.
7. Leave the kiosk idle for 30 minutes; confirm the backlight stays on and no screensaver engages.

Perspective App on Android Tablets

The side-loaded Perspective APK on an Amazon Fire HD is a reliable low-cost alternative for locations where running a full SBC is impractical (living room, bedside, garage). The deployment steps:

1. On the Fire tablet, enable Settings -> Security & Privacy -> Install Unknown Apps for the file manager.
2. Transfer the Perspective APK to the device via USB or a download link.
3. Install the APK; launch once to confirm the project URL is reachable.
4. Disable the Fire OS launcher with a kiosk launcher from the Play Store (sideload Google Play first if needed).
5. Lock the device to power from a continuous 5V supply; configure the screen brightness to a fixed value to prevent auto-dim.
6. Pin the Perspective app in the recents view so a stray back gesture cannot exit it.

When to Justify a Workstation Module

Workstation's value proposition is consistency. For a Maker deployment, justify adding a Windows host with Workstation only when:

• The on-screen keyboard must appear reliably on every input focus, including non-Perspective native dialogs.
• The kiosk shell must survive a Chromium crash and respawn automatically.
• The same hardware is shared with Vision clients in a mixed-mode environment.
• The site already runs Windows fleet management (Active Directory, Group Policy, MDM) and another OS adds friction.

If none of the above apply, the Chromium + Perspective + Perspective-component keyboard combination delivers the kiosk experience at a fraction of the power and licensing footprint.

Field-Proven Caveats

• DSI touchscreen power sequencing: Undervoltage at boot is the most common cause of Raspberry Pi autolaunch failure. Measure the 5V rail at the Pi GPIO header under touchscreen load; Pi 5 with a 1080p DSI panel can sag a 3A supply.
• Chromium GPU acceleration: Leave it enabled on Pi 4/5; disable only if chart rendering shows tearing. --disable-gpu trades smooth animation for lower boot latency.
• Browser storage growth: Local storage can accumulate on long-uptime kiosks. Add --disk-cache-size=104857600 (100 MB cap) and a periodic cache-clean maintenance task in /etc/cron.weekly.
• Maker client ceiling: Even with a kiosk, the underlying Maker gateway still enforces the configured client limits. A kiosk only consumes one client session; verify against the live count before adding another display.
• Touchscreen surrounds: Plastic surrounds for the official 7" panel improve kitchen aesthetics but trap heat; verify case ventilation before sealing the install.
• Bluetooth keyboards: Battery degradation causes random disconnects; budget for replacement or move to USB-rechargeable models with always-on charging cradles.