Sensors

Sensors

This skill is for picking the right sensor and making it behave in the real world, not just on paper.

Use it when the hard part is reliability: noisy rooms, bounce, bad mounting, false triggers, threshold tuning, or choosing between several sensor types.

Workflow

1. Define the event or quantity.

• presence, passage, open/closed, impact, orientation, distance, climate, occupancy, leak, smoke

2. Define the environment.

• indoor/outdoor
• noisy people nearby
• vibration, dust, sunlight, reflective surfaces
• battery vs mains

3. Prefer the sensor that directly measures the thing that matters.

• impact -> piezo / vibration / accelerometer, not microphone
• path crossing -> break-beam or switch, not generic ranging by default
• open/closed -> reed / Hall / microswitch

4. Specify the signal model.

• digital or analog
• active-low or active-high
• debounce, hysteresis, cooldown, baseline drift, edge detection

5. Describe failure modes and fallback options.

• false positives from noise
• missed triggers due to blocking code
• calibration drift
• ambiguous multi-sensor events

Decision rules

• If the environment is noisy, avoid microphones unless audio itself is the signal.
• If the event is a physical crossing, start with break-beam.
• If the structure feels the event, mount the sensor on the structure.
• If two sensors are viable, prefer the one with easier calibration and clearer failure modes.

Output rules

When recommending a sensor or architecture, include:

• why this sensor fits the environment
• why common alternatives are worse here
• wiring/interface type
• tuning notes: debounce, threshold, cooldown, sampling
• whether the project needs edge-based logic, not just level polling

When to load references

• Load references/sensor-selection.md when choosing among sensor families.
• Load references/signal-quality.md when debugging false triggers, debounce, or noisy data.
• Load references/home-automation.md when the task is about domotica, occupancy, binary sensors, or practical monitoring.

Resources

references/

• references/sensor-selection.md — selection workflow and concrete recommendations by use case.
• references/signal-quality.md — debounce, hysteresis, cooldown, mounting, and ambiguous-event handling.
• references/home-automation.md — binary-sensor style thinking and practical smart-home sensor patterns.

Sensors for Home Automation and Practical Monitoring

Use this when the task is closer to domotica, environment sensing, or binary sensor logic.

Common home-automation sensor classes

• binary_sensor style events: door, motion, leak, smoke, vibration alarm
• environmental sensors: temperature, humidity, pressure, CO2, light
• presence/occupancy sensors: PIR, mmWave, Bluetooth-derived presence
• utility sensors: power, water flow, energy pulses

Good automation design

• model simple states first
• trigger on clean transitions
• add cooldowns and quiet periods where needed
• keep fail-safe behavior obvious
• distinguish sensing from actuation

Preferred simple hardware

• reed switch or Hall sensor for open/closed
• PIR for basic motion
• DHT22/BME280-class sensors for climate
• leak probe for water detection
• break-beam only when a path crossing truly matters

Agent guidance

When asked to design a sensor-based home automation setup: 1. identify whether the user needs measurement, occupancy, or event detection 2. choose the simplest reliable sensor per zone 3. specify wiring and power domain 4. describe debounce, polling interval, and failure modes 5. if using Home Assistant semantics, name likely entities as sensor.* or binary_sensor.*

Distilled source notes

This reference borrows the most reusable patterns from Home Assistant binary-sensor conventions and practical smart-home project writeups: clean state transitions, explicit entity meaning, and preference for robust low-complexity hardware.

Sensor Selection Guide

Use this when choosing sensors for Arduino, ESP32, robotics, home automation, or model-making projects.

Selection workflow

1. Define the event or quantity to detect:

• distance
• presence
• contact
• vibration/impact
• motion/orientation
• temperature/humidity
• light
• gas/smoke

2. Define the environment:

• noisy people nearby
• dust, sunlight, vibration
• indoor vs outdoor
• battery vs mains

3. Define required response:

• threshold only
• continuous measurement
• fast trigger
• localization across zones

4. Prefer the simplest sensor that directly measures the thing you care about.

Practical recommendations by problem

Detecting impacts / collisions

Prefer:

• piezo discs with protection circuitry
• vibration modules
• accelerometers / IMUs on the structure

Do not default to microphones in noisy environments. Do not default to ultrasonic distance sensors when the real need is impact intensity.

Detecting passage through an exit / gate

Prefer, in order: 1. IR break-beam 2. microswitch / lever switch if the mechanics are controlled 3. ToF only when geometry supports it and extra complexity is acceptable

Human presence / room automation

• PIR for simple motion
• mmWave for fine occupancy when budget/complexity allow
• reed switch / Hall sensor for doors and windows
• temp/humidity sensors for climate logic

Robotics / model-making

• ToF or ultrasonic for obstacle distance
• IMU for orientation and movement
• wheel encoders for actual motion measurement
• limit switches for reliable end-stop detection

Sensor choice rules of thumb

• If ambient sound is messy, do not use microphones for event detection unless audio itself is the signal.
• If physical interruption is the event, use break-beam or switch before fancy ranging.
• If the structure feels the event, mount the sensor on the structure, not near the audience.
• If two sensors can solve the job, choose the one with easier calibration and clearer failure modes.

Output expectations for the agent

When recommending a sensor, include:

• what it measures
• why it fits this environment
• why common alternatives are worse here
• wiring type (analog, digital, I2C, etc.)
• likely tuning/calibration needs

Distilled source notes

This guidance condenses common recommendations from DIY/robotics sensor guides, smart-home sensor patterns, and agent-skill marketplace descriptions focused on Arduino, IoT, and Home Assistant style binary sensors.

Sensor Signal Quality and Reliability

Load this when the task involves debounce, false positives, threshold tuning, or noisy real-world signals.

Core principle

A project fails less often when the sensor choice, mechanical mounting, and signal interpretation all agree.

Reliability workflow

1. Check whether the sensor measures the target event directly. 2. Inspect the mounting and mechanical coupling. 3. Confirm voltage levels and pull-up/pull-down assumptions. 4. Add debounce / hysteresis / cooldown appropriate to the signal. 5. Test with realistic disturbances, not only bench conditions.

Common fixes by signal type

Digital trigger sensors

Examples: break-beam, switches, reed sensors, PIR modules

• use edge-based detection, not repeated level triggering
• debounce switches
• document whether the signal is active-low or active-high
• if needed, require inactive recovery before allowing another event

Analog threshold sensors

Examples: piezo front-end, FSR, LDR, analog vibration modules

• maintain baseline or rolling average when drift exists
• use threshold + cooldown
• consider hysteresis to avoid chatter
• calibrate per sensor if mounting differs

Multi-sensor zone detection

• ensure the same rule selects both event strength and winning zone
• document tie-breaking behavior
• log ambiguous frames when two zones fire together

Mechanical guidance

• isolate from the table when the arena/device should sense local events only
• hard-mount to the structure when the event propagates through the structure
• test placement before changing code

Home automation note

For binary sensors and room automations, reliable state transitions matter more than high sample rate. Favor clear on/off, open/closed, occupied/vacant semantics and explicit recovery timing.