A quick showcase on how to interact with our 2nd generation temperature sensor.
With the introduction of our new 2nd Generation Wireless Temperature Sensor, we have added a new inter-heartbeat sampling mode that makes it possible to sample data points between periodic heartbeats. Like our 1st generation sensors, an event is generated every periodic heartbeat, but with the 2nd generation hardware, the event can contain up to 30 temperature samples. Increased sampling rate between heartbeats provides higher temporal resolution, with only a minor reduction in battery life.
Configuring Sample Rate
Details coming soon.
When the sensor is configured for inter-heartbeat sampling, additional samples are included with every temperature event as a list of timestamps and values. As shown in the Temperature Event documentation, the first element in the list is equal to the event timestamp and values, independent of configuration.
If more than 1 sample has been sampled during the period, the list is ordered for decreasing time, meaning that the oldest sample is located at the end. The total length of the list will depend on the configuration.
Concatenating Historic Events
Sensors with default configuration, one sample per heartbeat, can be indexed in the same way as sensors with an increased inter-heartbeat sampling rate. When fetching the event history, all the samples can be grouped by concatenating the samples list.
The following snippet shows how to unpack a list of historic temperature events fetched using our Python API. A full example can be found here.
for event in events:
samples += event.data.samples
Publishing Emulated Events
Temperature events from the 2nd Generation Wireless Temperature Sensor can be generated without access to physical sensors using the Emulator API.
In DT Studio, click API Integrations -> Emulator, then select or create a temperature sensor. When selecting Emulate sampling between heartbeats, the feature appears.
The publish_event() method is available under the Emulator resource of our Python API. The following snippet shows an overview, and a full implementation example can be found here.
When a Cloud Connector receives an event, the updateTime field is measured. This is not directly possible for samples, which are sampled in between heartbeats. Instead, their timestamps, called sampleTime, is estimated by the cloud.
Currently, the implementation of this estimation assumes an ideally distributed interval according to the configuration. For instance, if the sensor is configured for 5 samples per heartbeat, each sample is distanced equally based on the previous heartbeat.