The ThingBox Documentation – Receiving enOcean Temperature Sensor data

This documentation will show how to analyse data sent by a enOcean temperature sensor and received on a Raspberry Pi with a enOcean extension card.

Material

STM 330 / STM 331 / STM 330C / STM 332U / STM 333U

Depending on the field Packet Type, a different kind of packet is transmitted. Temperature data is always transmitted in packet type 1 (for instance, responses are transmitted in packet type 2).

The header part of a telegram was already explained here.

Teach In telegrams

The data part of the sent telegram is built as follow:

When the “teach In” button is pressed, a teachIn telegram is sent by the device.

It can be recognized as such because the bit 3 of the byte 0 (lets print it DB_0.3) is 1.

For instance:

55000a0701eba5a97dff0b01899dbb0001ffffffff3d00a0

The data part following RORG is

a97dff0b01899dbb0001

DB_0 is forth byte:0b
DB_0_3:08 which means it is a data telegram

For instance:

55000a0701eba51c080b8701899dbb0001ffffffff4000ff

The data part following RORG is

1c080b8701899dbb0001

DB_0 is forth byte:87
DB_0_3:00 which means it is a teachIn telegram

Two types of DATA part in telegrams can be received depending of the device manufacturer: variation 1 and 2.

Variation 1 - No Profile ID included

In the teachIn Telegram variation 1, there is NO profile in the telegram (and no manufacturer ID). Thus, it is impossible to deduce the device capabilities from the teachIn telegram.

Clearly, these devices should be avoided. They can be used in home control software that allow manual edition of device profiles. In the case of a temperature sensor, this is a problem since the profile is the way allowing to retrieve the RANGE and SCALE needed to calculate the temperature given the raw data of the sensor.

Probabilities can be also used: temperature sensor most often have profile “A5-02-05”.

--- telegram dump ----------------
...buffer: 55000a0701eba5000072000181878f0001ffffffff3000e3
...data: 000072000181878f0001
...packetType: 0x01
...RORG: 0xA5
...teachin: true
...VARIATION: 0x01
...FUNC: 0x00
...TYPE: 0x00
...temperature: 22.11
...senderID: 0181878F
-------------------------

Variation 2 - Profile ID included

In these telegrams, the bit 7 of the byte 0 (lets print it DB_0.7) is 1.

--- telegram dump ----------------
...buffer: 55000a0701eba508284680018a76e50001ffffffff390033
...data: 08284680018a76e50001
...packetType: 0x01
...RORG: 0xA5
...teachin: true
...VARIATION: 0x02
...FUNC: 0x02
...TYPE: 0x05
...senderID: 018A76E5
-------------------------

Be aware that a LOT of temperature sensors are in variation 1. We found this one in variation 2: http://www.nodon.fr/enocean/capteur-de-temperature-sans-fil-sans-pile-enocean_6-1

Distinguishing between the two variations: the LRN-type bit

In the telegrams, the bit 7 of the byte 0 (named “LRN type”, do not confuse with “LRN bit” which is the bit 3) (lets print it DB_0.7) is 0 in variation 1 where no profile is included and 1 elsewhere.

Data telegrams for profile A5-02-05

Here is the data part:

In the picture above, the first byte of the data, the RORG, is missing. The raw temperature 0..255 is in byte 4 (offset 3) of the data part (offset 9 of the telegram).

--- telegram dump ----------------
...buffer: 55000a0701eba500007108018a76e50001ffffffff3400cd
...data: 00007108018a76e50001
...packetType: 0x01
...RORG: 0xA5
...teachin: false
...VARIATION: 0x01
...FUNC: 0x00
...TYPE: 0x00
...temperature: 22.27
...senderID: 018A76E5
-------------------------

Notice that in data mode (non learn mode), the profile FUNC, TYPE is not sent.

With the raw value, there is a formula to use to scale the raw value to the real temperature: