Quick end-to-end data-flow proof using only what's on the ESP32-C6- DevKitC-1 itself (no sensors on the bare devkit -- confirmed via research: BOOT button, WS2812 LED, no external sensors): - drivers::chip_temperature_* wraps ESP-IDF's built-in temperature_sensor driver (SoC die temperature). - drivers::rgb_led_* wraps the onboard WS2812 (GPIO8) via the espressif/led_strip managed component (another external registry dependency, like mdns/mqtt). - profiles::ChipTemperatureSensor is the first real implementation of the Sensor interface designed earlier, converting the driver's float reading to the fixed-point convention once at the boundary. - transport/mqtt.cpp publishes chip temperature as an HA "temperature" sensor every 30s, and exposes the LED as an HA "light" entity (rgb_command_topic) -- the first use of MQTT subscribe in this project, not just publish. Added a ChipTemperature SensorChannel (distinct from AmbientTemperature -- different meaning/range) to sensor.h. Verified live: both the chip temperature reading and LED color control work from Home Assistant against the real device. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
83 lines
2.6 KiB
C++
83 lines
2.6 KiB
C++
#pragma once
|
|
|
|
#include <cstdint>
|
|
|
|
namespace kvida {
|
|
|
|
// Fine-grained channel identifiers, one per physical quantity a sensor can
|
|
// expose -- mirrors Zephyr's SENSOR_CHAN_* granularity so a single sensor
|
|
// (e.g. a BME280) can expose several channels from one fetch().
|
|
enum class SensorChannel {
|
|
Contact,
|
|
Motion,
|
|
AmbientTemperature,
|
|
ChipTemperature, // SoC die temperature, e.g. ESP32-C6's internal sensor -- distinct from AmbientTemperature since the value range/meaning differ
|
|
Humidity,
|
|
Pressure,
|
|
AccelX,
|
|
AccelY,
|
|
AccelZ,
|
|
Analog,
|
|
PulseCount,
|
|
Generic,
|
|
};
|
|
|
|
// Fixed-point value: actual value = val1 + val2 * 1e-6 (same convention as
|
|
// Zephyr's struct sensor_value). ESP32-C6 has no hardware FPU, so avoiding
|
|
// float/double here avoids paying for software-emulated floating point on
|
|
// every sample -- relevant given the battery-first design goal.
|
|
struct SensorValue {
|
|
int32_t val1;
|
|
int32_t val2;
|
|
const char* unit;
|
|
uint64_t timestamp_ms;
|
|
};
|
|
|
|
enum class SensorTriggerType {
|
|
DataReady,
|
|
Threshold,
|
|
};
|
|
|
|
// Plain function pointer + user_data, not std::function, to avoid heap
|
|
// allocation for callback storage on embedded targets.
|
|
using SensorTriggerHandler = void (*)(void* user_data);
|
|
|
|
class Sensor {
|
|
public:
|
|
virtual ~Sensor() = default;
|
|
|
|
virtual const char* id() const = 0;
|
|
|
|
virtual void begin() = 0;
|
|
|
|
// True if this sensor exposes the given channel. Lets `profiles`
|
|
// discover capabilities generically instead of hardcoding per
|
|
// concrete sensor.
|
|
virtual bool supports(SensorChannel channel) const = 0;
|
|
|
|
// Triggers a hardware read and caches the result internally. A
|
|
// single fetch() may populate several channels at once (e.g. one
|
|
// I2C transaction on a BME280 yields temperature + humidity +
|
|
// pressure), so multi-channel sensors only pay the hardware cost
|
|
// once per fetch(), not once per channel.
|
|
virtual bool fetch() = 0;
|
|
|
|
// Reads a previously fetched channel from the internal cache.
|
|
// Returns false if the sensor doesn't support the channel, or if
|
|
// fetch() hasn't been called yet.
|
|
virtual bool get(SensorChannel channel, SensorValue& out) = 0;
|
|
|
|
// Registers an interrupt-driven callback (data-ready pin, threshold
|
|
// crossing, edge on a reed switch, ...) for sensors that support it.
|
|
// Default: not supported: polling-only sensors don't override this.
|
|
virtual bool set_trigger(SensorTriggerType type, SensorTriggerHandler handler, void* user_data)
|
|
{
|
|
(void)type;
|
|
(void)handler;
|
|
(void)user_data;
|
|
return false;
|
|
}
|
|
};
|
|
|
|
} // namespace kvida
|