Using your code with the Efergy e2 IR optical

[jockeastrom]

I bought an Efergy e2 IR optical power meter (wireless transmission every 30s) a couple of days ago and received my R820T dongle two days ago. Installed and fired up rtl-sdr hoping Nathan's/Gough's c hack would just give me power readings right away. Didn't happen.

Once I found your contribution at the end of the comments on Gough's site I got my hopes up. After a bit of frequency tuning I finally got a validated preamble but still no successful readings. Just the same sequence of bytes.

09 33 64 40 00 00 00 00

I assumed that the pulses-to-bits-converion was ok since I got the same sequence over and over again. Started to get frustrated and increased the FRAMEBYTECOUNT to 19 (!) just to see if there were anything interesting further down and to my surprise I found some interesting data that varied with different power readings but was the same for specific readings.

Ex: 09 33 64 40 00 00 00 00 0a 0f bd 55 00 00 00 00 = 1199W 09 33 64 40 00 00 00 00 0b 0f 8e 64 00 00 00 00 = 1319W 09 33 64 40 00 00 00 00 0c 0f 17 f3 00 00 00 00 = 1439W 09 33 64 40 00 00 00 00 0d 0f 24 c2 00 00 00 00 = 1559W

I noticed that byte 9 was increasing with higher watt numbers and I suddenly remembered that the resolution of the meter is 120W (1 pulse per 30s on a 1000p/kwh meter). Added these two things together and came to the conclusion that

power = byte[8] * 120W. The monitor has some really weird round off error though.

So now I just have to figure out the rest :).

byte[0-3] is always 09 33 64 40. Some device identifier? byte[9] is always 0f. Battery status? byte[10-11] is consistent with the power reading but doesn't add information. Checksum/CRC?

I got really excited about this and I basically just wanted to say thanks! I will add to your code locally. If I get things fully working I could push if you'd like me to,

[magellannh]

Thanks for the comment. I'm glad the code helped at least somewhat. When you get it all the way figured out, be sure to post an update and I'll add a section with #defines for the e2 IR power meter.

It'd be great if we could have sets of #defines to support each Efergy product, all in one file. Then people can just uncomment the settings for their device and recompile. When I got my Efergy Elite TPM, I found myself googling furiously, trying to figure out which efergy products used which frame formats and confused about all the code that was available, but didn't quite work.

Also, I'm working on updates to my rtl-wx repo to include energy monitoring support in addition to temperature monitoring, but that's not quite ready for prime time yet. I'm trying to integrate a graphing package from highcharts.com that will help with graphing energy data. So far it's looking very promising.

[magellannh]

Also, check out the crc calculator at: http://www.lammertbies.nl/comm/info/crc-calculation.html

Bytes 10 and 11 are definitely a CRC. I pasted the '09 33 64 40 00 00 00 00 0a 0f' from your first packet into the calculator, selected the 'hex' option and clicked calculate. The result for CRC-CCIT (Xmodem) was 0xBD55.

I think the CRC code that I added for the Elite 3.0 TPM should work on this too if you adjust the packet length appropriately.

[tombatossals]

Hi @magellannh, I'm in the same situation of @jockeastrom, maybe someone could give me some advice.

I own an Efergy Elite Classic 1.0 for some years, and discovered the RTL-SDR possiblitiles, so I bought an R820T dongle which I received two days ago and installed it in a Raspberry Pi 2 HW. After some trials and fine tunning, I accomplished to be able to read frames, interpreted by your RPI_Efergy program, but all the readings shows the same value. I post some logs of the standard readings below.

All frames shows those values: "Msg: 00 62 46 40 01 cksum: e8 crc16: 454a kW: 1.719". Could you tell me if that's becouse the Efergy Classic 1.0 protocol is different, or I am doing something wrong?

Thanks!

# rtl_fm -f 433524500 -s 200000 -r 96000 -g 19.7 | ./EfergyRPI_log -d 2
Found 1 device(s):
  0:  Generic, RTL2832U, SN: 77771111153705700

Using device 0: Generic RTL2832U
Found Rafael Micro R820T tuner
Tuner gain set to 19.70 dB.
Tuned to 433824500 Hz.
Oversampling input by: 6x.
Oversampling output by: 1x.
Buffer size: 6.83ms
Sampling at 1200000 S/s.
Output at 200000 Hz.

Efergy Power Monitor Decoder - (debug level 2)

Analysis of rtl_fm sample data for frame received on 04/28/15,16:19:27
     Number of Samples:   1367
    Avg. Sample Values:  -7057 (negative)     7117 (positive)
           Wave Center:     30 (this frame)      0 (last frame)
Msg: 00 62 46 40 01  cksum: e8 crc16: 454a   kW: 1.719

Analysis of rtl_fm sample data for frame received on 04/28/15,16:19:33
     Number of Samples:   1367
    Avg. Sample Values:  -7070 (negative)     7078 (positive)
           Wave Center:      4 (this frame)     30 (last frame)
Msg: 00 62 46 40 01  cksum: e8 crc16: 454a   kW: 1.719

Analysis of rtl_fm sample data for frame received on 04/28/15,16:19:39
     Number of Samples:   1367
    Avg. Sample Values:  -7093 (negative)     7077 (positive)
           Wave Center:     -8 (this frame)      4 (last frame)
Msg: 00 62 46 40 01  cksum: e8 crc16: 454a   kW: 1.719

[magellannh]

I assume you have the receiver and can verify what the actual kW value is supposed to be, and that the value is changing at least according to the receiver?

It's been a while since I've messed around with this code, but you might try adjusting FRAMEBYTECOUNT. Maybe you could increase the length like @jockeastrom did just to see if there's anything interesting at the end of the message.

Below is a link to a site with more info on efergy decoding and in the comments it sounded like someone may have gotten a 1.0 transmitter decoded correctly, but I'm not sure. It seems like every efergy device has different decoding and it's sort of a confusing mess.

http://rtlsdr-dongle.blogspot.com.au/2013/11/finally-complete-working-prototype-of.html

[tombatossals]

Yessss, thanks so much for your response, I have almost decode the frame because of your previous posts. Adjusting the FRAMEBYTECOUNT I could see that the frame is composed by 9 bytes, and the last byte is the checksum of the previous ones.

I'm almost there, only 3 bytes have the information, and as you say the reader shows values that varies as the frame change, so I only need to understand the byte-to-watt conversion and the formulas.

Thanks again @magellannh !!

[karis79]

hi @magellannh

I hit exactly same problem than @jockeastrom above i.e. efergy e2 opto did not worked with your code. @jockeastrom had already pretty much decoded the data from opto so I used those and put together simple formula to get wattage from opto frame.

The changes I did are shown in my fork https://github.com/karis79/RPI_Efergy and i think that is good enough for me but needs more work if you want to integrate it to your code(thas why no pull request yet).

This is data from opto: Msg: 09 25 7a 40 00 00 00 00 0b 0f 24 b7 crc ok W: 1319.000

and from that I know that: bytes 0-3 is propably serial number etc as mine is different from @jockeastrom bytes 8 is pulse count from 30 seconds of period bytes 10-11 is crc

my electricity meter is sending 1000 pulses per 1kwh so one pulse is 1w. Opto counts pulses for 30secs so it means every pulse is 120wh (3600/30).

I think i did not properly understand the FRAMEBYTECOUNT or EXPECTED_BYTECOUNT_IF_CRC_USED because i had to put those to 13 and 12 respectively to get it working

[tyldum]

Confirm @karis79 changes works for this unit.