IoT sensor integration connects the physical world to digital signage — motion sensors trigger welcome screens, CO₂ sensors drive air quality dashboards, people counters show occupancy, and NFC readers enable interactive kiosks. SpinetiX players integrate with IoT ecosystems at three levels: GPIO for direct sensor connections, REST APIs for IoT platform data, and MQTT (via HUB) for real-time sensor streams. The result is signage that reacts to its environment.
Integration Levels
Level 1: Direct GPIO Sensors
SpinetiX HMP players have GPIO pins that accept direct sensor connections. Wire a PIR motion sensor to a GPIO input — when motion is detected, the content project receives an event and switches from standby to active content. No IoT platform, no network, no middleware — just sensor wire to player pin.
- PIR motion: Detect presence → activate exhibit content
- Door contact: Door opens → show welcome message
- Push button: Visitor presses button → show information
- NFC reader: Tap badge → show personalized content
Level 2: IoT Platform APIs
Sensors connect to IoT platforms (Azure IoT Hub, AWS IoT, ThingsBoard, FIWARE) that aggregate and process data. SpinetiX players fetch processed data via REST API widgets. The IoT platform handles sensor management, data validation, and aggregation — the player renders the final visualization.
Level 3: MQTT via HUB
For real-time sensor streams, SpinetiX HUB acts as an MQTT-to-HTTP bridge. HUB subscribes to MQTT topics from IoT brokers, caches latest values, and serves them to players as JSON. This keeps MQTT protocol complexity off the player while delivering near-real-time sensor data.
Common Sensor Applications
| Sensor Type | Data | Display Application | Integration |
|---|---|---|---|
| PIR motion | Presence / absence | Trigger exhibit content | GPIO direct |
| People counter | Room occupancy count | Capacity indicator | API / MQTT |
| CO₂ sensor | ppm level | Air quality dashboard | IoT platform API |
| Temperature | °C reading | Environmental display | API / MQTT |
| Parking sensor | Bay occupied/free | Available spaces count | IoT platform API |
| NFC reader | Tag ID | Personalized content | GPIO / middleware |
| Ambient light | Lux level | Auto-brightness adjust | GPIO / API |
Key Parameters
| Parameter | Value | Why It Matters |
|---|---|---|
| GPIO pins | 4+ digital inputs | Direct sensor connection |
| IoT protocols | HTTP, MQTT (via HUB) | Connect to any IoT platform |
| Data refresh | Seconds (API) / real-time (GPIO) | Match sensor update frequency |
| Sensor count | Unlimited via API aggregation | Building-wide sensor networks |
| HUB as bridge | MQTT → HTTP translation | Keep player integration simple |
Common Mistakes
- Raw sensor data on screen. "CO₂: 842 ppm" means nothing to most viewers. Translate raw values into actionable information: "Air Quality: Good ✅" with colour coding. Design for the viewer, not the engineer.
- No sensor timeout handling. If a PIR sensor triggers content and the visitor walks away, the content should return to standby after 30–60 seconds. Without timeouts, triggered content plays indefinitely to empty spaces.
- Direct MQTT on the player. SpinetiX players don't natively speak MQTT. Don't try to implement an MQTT client in jSignage JavaScript — use HUB as the MQTT bridge. It's more reliable and maintainable.
- Ignoring sensor calibration. A people counter that consistently over-counts by 15% shows inaccurate occupancy data. Calibrate sensors during installation and recalibrate periodically.