Thingsee PRESENCE Configuration

Overview

Thingsee PRESENCE configuration is performed via Service API (GraphQL) or by sending CBOR-encoded downlink messages. This page documents all configuration parameters, valid ranges, and common configuration scenarios.

Configuration Methods

Service API (GraphQL)

Recommended method for managing device configuration via cloud platform.

Advantages:

• User-friendly API interface
• Automatic CBOR encoding
• Built-in validation
• Configuration history tracking
• Batch configuration support

See: Service API Documentation for details.

CBOR Downlink Messages

Direct binary message approach for custom integrations.

Requirements:

• Wirepas endpoints must be 21/21
• Include transactionId for request-response correlation
• Sensor replies with same messageId, all fields populated with current values

See: CBOR to JSON Conversion for encoding details.

Configuration Messages

Message 13200 - PIR Sensor Configuration

Profile: Presence and Occupancy Profile (13000-13999)

Purpose: Configure PIR sensor behavior and reporting mode

Configuration Request:

{
  "tsmId": 13200,
  "tsmEv": 30,
  "transactionId": 1493312188,
  "threshold": 150,
  "enableLed": 0,
  "mode": 0,
  "passiveReportInterval": 3600
}

Configuration Response:

{
  "tsmId": 13200,
  "tsmEv": 31,
  "transactionId": 1493312188,
  "threshold": 150,
  "enableLed": 0,
  "mode": 0,
  "passiveReportInterval": 3600
}

Sensor replies with tsmEv: 31 (Application profile update response) and includes all current configuration values, even if only one parameter was changed in the request.

Empty Configuration Query

To query current configuration without changes, send message with only header fields:

{
  "tsmId": 13200,
  "tsmEv": 30,
  "transactionId": 1493312188
}

Sensor will reply with all configuration fields populated with current values.

Configuration Parameters

transactionId

Type: Integer
Range: 0 to 2,147,483,647
Required: Yes
Default: N/A

Purpose: Correlate configuration request with sensor response

Description: Transaction ID is reported back unchanged in the sensor response. Use this to match requests with responses when sending multiple configurations or tracking configuration status.

Example:

{
  "transactionId": 1493312188
}

Best Practices:

• Use UTC timestamp for traceability
• Use unique ID per request for batch operations
• Store transaction ID in database for audit trail
• Implement timeout mechanism (typical response: 5-30 seconds)

threshold

Type: Integer
Range: 60 to 1100
Default: 150
Unit: Sensitivity units

Purpose: Configure PIR sensor movement detection sensitivity

Description: Detection threshold for the PIR sensor. Lower values increase sensitivity (detect smaller heat changes), higher values decrease sensitivity (require larger heat changes).

Behavior:

• Values < 60: Clamped to 60, sensor reports 60
• Values > 1100: Clamped to 1100, sensor reports 1100
• Value = 0 or omitted: Resets to default (150), sensor reports 150

Common Values:

Example:

{
  "threshold": 150
}

Troubleshooting:

• Too many false triggers: Increase threshold (e.g., from 150 to 400)
• Missing detections: Decrease threshold (e.g., from 150 to 100)
• Under-desk too sensitive: Use 800 with Occupancy Dome
• Doorway insufficient coverage: Use 60-100

Configuration Tips:

1. Start with default (150)
2. Monitor for 24 hours
3. Adjust based on false positives/negatives
4. Test during peak hours
5. Consider seasonal temperature variations

enableLed

Type: Integer
Range: 0 to 1
Default: 0

Purpose: Enable/disable LED indicator on movement detection

Values:

Description: Controls whether the LED provides visual feedback when PIR sensor detects movement.

Example:

{
  "enableLed": 0
}

Use Cases:

Enable LED (1):

• Installation verification
• Testing sensor positioning
• Troubleshooting detection issues
• Demonstrating sensor functionality
• Temporary installations

Disable LED (0):

• Production deployments
• Maximize battery life
• Discreet monitoring
• Permanent installations
• Energy conservation

Battery Impact:

• Minimal when enabled (< 5% battery life reduction)
• LED only activates on detection events
• Negligible in low-traffic areas
• More significant in high-traffic (>100 detections/day)

Best Practice: Enable during installation and testing, disable for production use.

mode

Type: Integer
Range: 0 to 2
Default: 0

Purpose: Select PIR sensor operating mode

Values:

Mode 0: Movement Count Reporting (Default)

Behavior:

• Reports movement count periodically using message 13100
• Uses reportInterval from message 1500 configuration
• Reports regardless of whether movement detected
• Counter increments during measurement interval
• Counter resets after each report

Message Flow:

1. Interval starts (e.g., 60 seconds)
2. PIR detects movements, increments counter
3. At interval end, sends message 13100 with moveCount
4. Counter resets to 0
5. Next interval begins

Typical Settings:

{
  "mode": 0
}

Combined with message 1500:

{
  "tsmId": 1500,
  "measurementInterval": 60,
  "reportInterval": 60
}

Use Cases:

• Visitor counting
• Traffic analysis
• Doorway monitoring
• Area popularity tracking
• Trend analysis

Network Traffic: Moderate (reports every interval regardless of activity)

Mode 1: Occupancy Reporting

Behavior:

• Reports occupancy state changes using message 2100
• Sends message only when state changes (occupied ↔ vacant)
• Reports every passiveReportInterval regardless of state
• Reduces network traffic significantly
• Lower power consumption

Message Flow:

1. PIR detects movement → state = occupied
2. Sends message 2100 with state = 1 (occupied)
3. No movement for threshold period → state = vacant
4. Sends message 2100 with state = 0 (vacant)
5. If no state change for passiveReportInterval, sends periodic update

Typical Settings:

{
  "mode": 1,
  "passiveReportInterval": 3600
}

Use Cases:

• Workspace occupancy monitoring
• Meeting room status
• Desk utilization tracking
• Hot-desking management
• Binary occupancy status

Network Traffic: Low (only on state changes + periodic updates)

Mode 2: Event-Based Movement Count Reporting

Behavior:

• Reports movement count using message 13100
• Uses reportInterval when movement detected
• Uses passiveReportInterval when no movement
• Balances detail with efficiency

Message Flow:

With movement:

1. Interval starts (reportInterval)
2. PIR detects movements
3. At reportInterval, sends message 13100
4. Continues using reportInterval while movement detected

Without movement:

1. No movement detected
2. Uses passiveReportInterval instead
3. At passiveReportInterval, sends message 13100 with moveCount=0
4. Returns to reportInterval if movement resumes

Typical Settings:

{
  "mode": 2,
  "passiveReportInterval": 3600
}

Combined with message 1500:

{
  "tsmId": 1500,
  "measurementInterval": 60,
  "reportInterval": 60
}

Use Cases:

• Variable traffic areas
• Energy-efficient monitoring
• Areas with intermittent activity
• Battery conservation priority
• Reducing cloud data volume

Network Traffic: Variable (low during idle, moderate during activity)

passiveReportInterval

Type: Integer
Range: 0 to 86400
Default: 3600
Unit: Seconds

Purpose: Configure reporting interval when no movement detected (modes 1 and 2 only)

Description: When in mode 1 (Occupancy) or mode 2 (Event-based movement count), this parameter defines how often the sensor sends reports when no activity is detected.

Valid Only For:

• Mode 1 (Occupancy reporting)
• Mode 2 (Event-based movement count)

Ignored For:

• Mode 0 (Movement count reporting) - uses reportInterval from message 1500 instead

Requirements:

• Must be longer than reportInterval (configured in message 1500)
• Common values: 3600 (1 hour), 7200 (2 hours), 21600 (6 hours)

Example:

{
  "mode": 2,
  "passiveReportInterval": 3600
}

Use Cases:

Interaction with reportInterval:

Active reporting (reportInterval from message 1500):

• Used when movement is detected (mode 2)
• Used for state changes (mode 1)
• Typically 60-300 seconds

Passive reporting (passiveReportInterval):

• Used when no movement detected (mode 2)
• Used for periodic updates (mode 1)
• Typically 3600+ seconds

Battery Impact:

• Longer intervals = extended battery life
• 3600s (1 hour): Standard battery life
• 7200s (2 hours): ~10% battery life increase
• 21600s (6 hours): ~20% battery life increase

Best Practice: Set passiveReportInterval to at least 10x reportInterval to balance monitoring needs with battery conservation.

Message 13210 - Occupancy Light Configuration

Profile: Presence and Occupancy Profile (13000-13999)

Purpose: Configure occupancy light behavior (if device supports lights)

Configuration Request:

{
  "tsmId": 13210,
  "tsmEv": 30,
  "transactionId": 1493312188,
  "mode": 0,
  "index": 2,
  "staticFilter": 1,
  "threshold": 20,
  "duration": 10
}

Configuration Response:

{
  "tsmId": 13210,
  "tsmEv": 31,
  "transactionId": 1493312188,
  "mode": 0,
  "index": 2,
  "staticFilter": 1,
  "threshold": 20,
  "duration": 10
}

Occupancy Light Parameters

mode

• Type: Integer
• Range: 0 to 2
• Default: 0

index

• Type: Integer
• Range: 0 to 2
• Purpose: Select which light to enable in forced mode

staticFilter

• Type: Integer
• Range: 0 to 1
• Default: 0

threshold

• Type: Integer
• Range: 0 to unlimited
• Default: 30
• Purpose: Hot-region detection threshold when using filtering
• Note: Lower values increase sensitivity, but very low values may cause false detections

duration

• Type: Integer
• Range: 0 to unlimited
• Default: 0
• Unit: Seconds
• Purpose: Reset time after which device is set to unoccupied if no region changes detected
• Note: Value of 0 disables reset behavior

Message 13211 - Occupancy Light Single Light Configuration

Purpose: Configure individual light color intensity

Configuration Request:

{
  "tsmId": 13211,
  "tsmEv": 30,
  "transactionId": 1493312188,
  "index": 1,
  "max": 50
}

Configuration Response:

{
  "tsmId": 13211,
  "tsmEv": 31,
  "transactionId": 1493312188,
  "index": 1,
  "max": 50
}

Single Light Parameters

index

• Type: Integer
• Range: 0 to 2
• Purpose: Select which light color to configure

max

• Type: Integer
• Range: 0 to 100
• Default: 100
• Unit: Percent
• Purpose: Maximum light intensity
• Description: Controls the maximum brightness as a percentage (0% = off, 100% = full brightness)

System Configuration

Thingsee PRESENCE also responds to common system configuration messages documented in the Common Profile (1000-1999).

Message 1500 - Measurement and Reporting Intervals

Purpose: Configure measurement frequency and reporting intervals

Configuration Request:

{
  "tsmId": 1500,
  "tsmEv": 30,
  "transactionId": 1485925806,
  "measurementInterval": 30,
  "reportInterval": 300
}

System Parameters

measurementInterval

• Type: Integer
• Range: Device-specific (typically 1-3600)
• Default: Device-specific
• Unit: Seconds
• Purpose: How often sensor takes measurements
• For PRESENCE: Typically equals reportInterval (continuous PIR monitoring)

reportInterval

• Type: Integer
• Range: Device-specific (typically 60-3600)
• Default: 60
• Unit: Seconds
• Purpose: How often sensor sends messages to cloud (when active)
• For PRESENCE: Used in modes 0 and 2

Configuration Scenarios

Doorway Visitor Counting

Objective: Count visitors passing through standard doorway (0.9m wide)

Configuration:

{
  "tsmId": 13200,
  "tsmEv": 30,
  "transactionId": 1234567890,
  "threshold": 150,
  "enableLed": 0,
  "mode": 0,
  "passiveReportInterval": 3600
}

{
  "tsmId": 1500,
  "tsmEv": 30,
  "transactionId": 1234567891,
  "measurementInterval": 60,
  "reportInterval": 60
}

Installation:

• Use Visitor Counter Dome
• Mount at ceiling above doorway center
• Height: 2.4-2.7m
• Position: 5-10cm from wall

Expected Behavior:

• Movement count reported every 60 seconds
• Maximum 34 movements per minute
• Passive report every hour when no movement

Accuracy: ~85-95% in single-file traffic

Under-Desk Workspace Occupancy

Objective: Monitor desk occupancy for hot-desking system

Configuration:

{
  "tsmId": 13200,
  "tsmEv": 30,
  "transactionId": 1234567892,
  "threshold": 800,
  "enableLed": 0,
  "mode": 1,
  "passiveReportInterval": 3600
}

{
  "tsmId": 1500,
  "tsmEv": 30,
  "transactionId": 1234567893,
  "measurementInterval": 300,
  "reportInterval": 300
}

Installation:

• Use Occupancy Dome
• Mount under desk center
• Height: 60-70cm from floor
• Clearance: 50mm from table legs

Expected Behavior:

• Occupancy state changes reported immediately
• Periodic status every 1 hour
• Low network traffic (only on state changes)

Accuracy: ~95% for typical desk usage

Meeting Room Occupancy

Objective: Track meeting room usage and availability

Configuration:

{
  "tsmId": 13200,
  "tsmEv": 30,
  "transactionId": 1234567894,
  "threshold": 150,
  "enableLed": 0,
  "mode": 1,
  "passiveReportInterval": 3600
}

{
  "tsmId": 1500,
  "tsmEv": 30,
  "transactionId": 1234567895,
  "measurementInterval": 300,
  "reportInterval": 300
}

Installation:

• No dome required (standard detection)
• Mount on ceiling or wall
• Height: 2.4-3.0m
• Position: Central location with clear view

Expected Behavior:

• Occupied/vacant states reported on changes
• Hourly status updates
• Integrates with room booking system

Accuracy: ~90% for typical meeting usage

High-Traffic Corridor Monitoring

Objective: Monitor traffic flow in busy corridor, conserve battery

Configuration:

{
  "tsmId": 13200,
  "tsmEv": 30,
  "transactionId": 1234567896,
  "threshold": 100,
  "enableLed": 0,
  "mode": 2,
  "passiveReportInterval": 7200
}

{
  "tsmId": 1500,
  "tsmEv": 30,
  "transactionId": 1234567897,
  "measurementInterval": 120,
  "reportInterval": 120
}

Installation:

• Consider Visitor Counter Dome for focus
• Mount on ceiling
• Height: 2.5-3.0m
• Position: Center of corridor width

Expected Behavior:

• Reports every 2 minutes during active periods
• Reports every 2 hours during quiet periods
• Balances detail with battery conservation

Accuracy: Variable based on corridor width and traffic density

Installation Testing Mode

Objective: Verify sensor placement and detection coverage

Configuration:

{
  "tsmId": 13200,
  "tsmEv": 30,
  "transactionId": 1234567898,
  "threshold": 150,
  "enableLed": 1,
  "mode": 0,
  "passiveReportInterval": 3600
}

{
  "tsmId": 1500,
  "tsmEv": 30,
  "transactionId": 1234567899,
  "measurementInterval": 10,
  "reportInterval": 10
}

Installation:

• Temporary mounting (tape or hand-held)
• Test various positions
• Walk through detection area
• Observe LED flashes

Testing Procedure:

1. Apply configuration
2. Wait 30 seconds for sensor to update
3. Walk slowly through detection area
4. Observe LED flash on detection
5. Review cloud data every 10 seconds
6. Adjust position or sensitivity as needed
7. Once satisfied, disable LED and set production intervals

After Testing: Set production configuration (disable LED, increase intervals).

Configuration Best Practices

General Guidelines

1. Always include transactionId - Essential for tracking configuration status
2. Query before changing - Send empty config to see current values
3. Change one parameter at a time - Easier to troubleshoot issues
4. Monitor for 24 hours - Verify configuration effectiveness over full day
5. Document configurations - Maintain record of settings per sensor
6. Test during peak hours - Validate during typical usage patterns

Sensitivity Tuning

Step-by-step process:

1. Start with default (150)

   • Deploy sensor with standard settings
   • Monitor for 24 hours

2. Identify issues

   • Too many false triggers → increase threshold
   • Missing detections → decrease threshold

3. Adjust incrementally

   • Change by 50-100 units at a time
   • Test for several hours between changes

4. Consider environment

   • High ambient temperature → may need lower threshold
   • Thermal variations → may need higher threshold
   • Under-desk → start with 800

5. Seasonal adjustment

   • Summer (warmer): May need lower threshold
   • Winter (cooler): May need higher threshold
   • Consider quarterly reviews

Mode Selection

Choose based on use case:

Interval Configuration

Balancing factors:

• Data freshness - How quickly you need updates
• Battery life - Longer intervals = longer battery
• Network load - Shorter intervals = more Wirepas traffic
• Cloud costs - More messages = higher processing costs
• Use case criticality - Critical areas need frequent updates

Common patterns:

Network Considerations

Wirepas mesh network capacity:

• Each sensor transmission uses network bandwidth
• Dense deployments need longer intervals
• Consider total messages per gateway
• Typical limit: ~100 sensors per gateway at 60s intervals

Optimization strategies:

1. Use mode 1 (Occupancy) for most sensors
2. Use mode 2 (Event-based) for variable-traffic areas
3. Set passiveReportInterval to 3600s or higher
4. Stagger reportInterval across sensors (avoid synchronized bursts)

Battery Life Optimization

Factors affecting battery life:

• Report interval (most significant)
• Movement frequency (more detections = more transmissions)
• Network hops (distance to gateway)
• LED usage (minimal impact)
• Configuration changes (avoid frequent updates)

To maximize battery life:

1. Use mode 1 or 2 instead of mode 0
2. Increase passiveReportInterval to 7200s or higher
3. Disable LED (enableLed: 0)
4. Optimize gateway placement to reduce hops
5. Use event-based reporting where possible

Expected battery life:

Troubleshooting Configuration

Configuration Not Applied

Symptoms:

• Sensor response shows old values
• Behavior doesn’t change
• No response to configuration message

Possible Causes:

1. Sensor not joined to network
2. Incorrect Wirepas endpoints (must be 21/21)
3. CBOR encoding error
4. Invalid parameter values
5. Network congestion

Solutions:

1. Verify sensor is reporting to cloud
2. Check Wirepas endpoints in configuration tool
3. Validate CBOR encoding with test decoder
4. Review parameter ranges in this document
5. Retry during low-traffic period
6. Increase configuration timeout to 60 seconds

Sensor Not Responding to Query

Symptoms:

• No response to empty configuration message
• TransactionId not returned

Possible Causes:

1. Sensor in sleep mode
2. Batteries depleted
3. Network disconnection
4. Wrong device serial number

Solutions:

1. Wait for next scheduled report
2. Check battery level alerts
3. Verify gateway operational
4. Confirm correct tsmTuid in request
5. Trigger movement to wake sensor
6. Allow up to 5 minutes for response

Parameter Value Clamped

Symptoms:

• Response shows different value than request
• Threshold 50 requested, 60 returned

Cause: Value outside valid range, sensor clamped to nearest valid value

Solution: This is expected behavior. Review parameter ranges and adjust request to stay within valid range.

Mode Not Changing

Symptoms:

• Mode configured to 1, sensor still sends message 13100
• Expected message 2100 not received

Possible Causes:

1. Configuration not yet applied
2. Old firmware version (may not support all modes)
3. Misunderstanding of mode behavior

Solutions:

1. Wait 5-10 minutes for configuration to apply
2. Query current configuration to verify
3. Review firmware version (check with support@haltian.com)
4. Verify expected message IDs for each mode

Unexpected Battery Drain

Symptoms:

• Battery depleting faster than expected
• Device reporting low battery prematurely

Possible Causes:

1. Very short report intervals
2. High movement frequency
3. LED enabled in high-traffic area
4. Dense network (many hops to gateway)
5. Frequent configuration changes

Solutions:

1. Increase reportInterval to 300s or higher
2. Use mode 2 or mode 1 instead of mode 0
3. Disable LED (enableLed: 0)
4. Optimize gateway placement
5. Minimize configuration updates
6. Check passiveReportInterval is set (mode 1/2)

Related Documentation

• Thingsee PRESENCE - Device overview and installation guide
• CBOR to JSON Conversion - Message encoding/decoding details
• Service API (GraphQL) - Cloud API for device configuration
• Binary Passthrough API - Direct CBOR message access
• Presence and Occupancy Profile - Complete message profile specification
• Common Profile (1000-1999) - System configuration messages