OK, I’ve searched for some considerable while and not come up with a definitive listing of the format, the details of what the output from an emonTH (v1 if it makes a difference) represents. My notes from ages ago say:
> emonTH v1 typical output
> OK 23 169 0 0 0 27 1 31 0 1 0 0 0 (-54)
> OK Start of message (? = dodgy data)
> 23 Node
> 169 0 Internal temperature
> 0 0 External temperature
> 27 1 Humidity
> 31 0 Battery
> 1 0 Pulse count
> 0 0 Dunno
> (-54) Radio signal strength indicator (dBm)
which sort of makes sense.
However, in weeks of testing, I realise that the second byte of the humidity from my emonTH is always 1, the humidity is always nn.1% - obviously wrong.
Could someone point me to the definitive words - thanks.
Up to now, I’ve been feeding the temperature alone into an rrdtool database and producing graphs, from a Raspberry Pi, glued together with my first stab at Python. It seems to work prettily, so it would be useful to sort humidity (and probably battery and signal strength). Next may well be central heating boiler control.
You’ll really need to know which sketch is in your emonTH. Because it is sending 12 bytes, I suspect it will be “emonTH_DHT22_DS18B20_RFM69CW_Pulse.ino” (still available in GitHub).
The data structure is
typedef struct {
int temp;
int temp_external;
int humidity;
int battery;
unsigned long pulsecount;
} Payload;
Not shown here is the NodeID, which is 1 byte. It is injected by JeeLib as part of the message header and precedes the data struct.
The integers are 2 bytes, signed, low byte first.
The long is 4 bytes, so your “dunno” is the high 2 bytes of the pulse count.
Temperatures are sent in deci-degrees (i.e. degrees ×10).
Humidity is sent as percent ×10.
Battery voltage is sent in deci-volts (i.e. V ×10).
So you have
Node = 23
Int temp = 16.9 °C
Ext temp = 0 °C
Humidity = 28.3%
Battery = 3.1 V
Pulse count = 1
The signal strength of course doesn’t form part of the transmission itself, it comes from the RFM69CW receiver.
The pseudo-code for extracting the signed integer data (courtesy of Paul Burnell) is:
x= ([1st byte] + ( [2nd byte] * 256) )
if x > (2^15)
x = (x - (2^16))
return x
Ah that explains why my temperature graph was correct (second byte always zero) but not humidity (second byte always one). Thank you for that extensive post, especially the example, which I suspect will be useful to more than just me.
One point; in the real world, is there any purpose to the pseudo-code ? (2^15) is 32k, far bigger than any parameter than could be returned by a domestic emonTH. I’ve currently updated my Python to the info in your post, less this >32k check, which appears to save RPi oomph.
Not many of those in my house, I’m pleased to say. Having said that, I see I created the rrdtool database with a minimum of -10ºC, although the minimum I have seen is 8ºC. Well, easy enough to code the check.
OK I added the code yesterday and it seems to be producing graphs as expected. For that extra fun, I’ve now ordered an external temperature sensor but… how should it be connected ? The jpg above here is missing for the DS18B20.
I’ve also looked at the GitHub “sketch” to little understanding as GitHub is code - or perhaps “sketch” means code - and I’m not clear how to identify my emonTH anyway. Perhaps I need to examine the board of the emonTH more carefully.
Yes, “sketch” is Arduino-speak for the application that runs inside the processor (remember there’s its own operating system of sorts inside there as well).
You’ll find the hardware version printed on the circuit board. To find the software version, you need a ‘programmer’ and you may need to solder in a 6-pin header to connect it. Then load the Arduino IDE and watch to see what it puts on the screen as it starts up. Unless you have everything set up, that’s not trivial.
The external DS18B20 sensor is a One-wire device, it needs GND, 3.3 V (or switched power) and the One-wire data line. Those are all available in the terminal block. OpenEnergyMonitor Wiki - check your hardware version.
although I don’t think that tells me anything about the data format (sketch). A work in progress for me.
I’m impressed overall, to such an extent that as well as conducting a reliability run on the emonTH, I’ve ordered a JeeLink with the intent of hacking into my central heating controller’s 433 link and boiler switching with the emonTH (+ Python). Approval has already been obtained from Mrs Chiny
Suggestion: the emonTH box would be improved by 2 keyhole-shaped mounting holes.
that explains why my temperature graph was correct (second byte always zero) but not humidity (second byte always one). Thank you for that extensive post, especially the example, which I suspect will be useful to more than just me.
