In a very cool development, Nathaniel Elijah of RTL-SDR Projects had posted about the decoding of the Efergy E2 Classic FSK data transmissions using RTL-SDR and a Raspberry Pi. I just so happened to stumble upon his page, and knowing just how difficult it can be to reverse engineer transmissions made over the air by proprietary devices, immediately felt a sense of awe.
For those who don’t know, Efergy is a company which has produced many wireless energy monitors which operate in the 433Mhz band. Their most basic systems consist of a wireless energy monitor base station with an LCD that displays the current usage to 2 decimal places (kW), and tallies the aggregated daily usage for the past week, and aggregated monthly usage for the past 12 or so months. The data comes from an inductive clamp sensor which is installed in your distribution box, which plugs into a 433Mhz data transmission device which can be configured to send data every 6s, 12s or 24s.
In order to get more detailed data, they have more advanced models and a hub controller which receives the transmission and “visualizes” it by using their cloud services. This adds more expense to the system, and means that someone else is ultimately dealing with your data. I think in this day and age, it’s high time we considered whether the benefits of the cloud (whose services could disappear or change at any time) outweigh the cost (or sometimes savings) of doing it all in-house.
There’s been quite a bit of interest in the efergy monitors, in terms of physically modifying the receivers for data, and some other attempts at decoding the raw data from the sensors, but I wasn’t made aware of it until I stumbled upon Nathaniel’s site.
Nathaniel specifically referred to the Efergy E2 model, however, I’m currently using an Efergy Elite 1.0R. I suspected that most of their “Elite” models and some others shared the same protocol, so I held high hopes that it would work.
Interestingly enough, I downloaded his source code and tried to build it on my Samsung ARM Chromebook running Chrubuntu with rtl-sdr already installed. Aside from a small hiccup which complained of “undefined reference to function `pow'”, which was resolved by changing the compilation command, it compiled and it ran just fine.
For reference, the compilation command that worked looks like:
gcc -o EfergyRPI_001 EfergyRPI_001.c -lm
Apparently the ordering of the -lm option makes a difference to the linker, so keep that in mind.
To run the program, use:
rtl_fm -f 433550000 -s 200000 -r 96000 -g 19.7 2>/dev/null | ./EfergyRPI_001
This asks for rtl_fm (included in the rtl-sdr package from Osmocom) to demodulate, centred at frequency 433.55Mhz with a bandwidth of 200khz, resampled to 96kHz with a tuner gain set to 19.7dB sent through stdout (to be piped into EfergyRPI_001), whereas the diagnostic information from rtl_fm is sent to /dev/null (silenced).
It builds and runs just fine on Chrubuntu, but it should work equally well on everything that rtl-sdr builds on as it’s just straight C code. I must praise the author for making it so elegantly simple and small.
There’s a few troubleshooting tips – firstly, if you only see the header banner, but no decode and get “thrown” back to the shell, rtl_fm probably ran into trouble.
To find out, just delete everything after the gain value (19.7 in the example) and see what happened. You should get something indicative of an error. If it can’t find your tuner, you may need to run everything as superuser (i.e. su or sudo) or add the current user to a privileged group to access USB devices.
You may find that it doesn’t seem to work at all for some tuners and antennas. For example, my R820T tuner stick will sit there with no packets showing. You should play with the gain figure (19.7 above), and try values between 0-50dB, although values above 35 seem to amplify noise rather than signal.
You may also find that the two processes take a lot of CPU time and eventually slow down the decoding, missing packets and having the cursor blink in the terminal hang. I found this happens with my R820T stick, and it may just be a sign that it’s not too happy with the USB bus, or something went wrong with rtl_fm and it’s not providing samples fast enough/dropping samples due to lack of CPU, or that the signal is just really noisy. I’ve had the best experience with E4000 sticks, decoding for hours with no loss of packets at all. I have no FC0012/0013 based sticks, however, Nathaniel was using an FC0013 based stick. Your mileage will vary.
The output itself is in CSV format to the terminal, although date/time will be affected by your locale settings (thanks Chrubuntu). With this data, you can reprocess it, archive it and analyze it to your hearts content. Great!
If the decoding stops all of a sudden and dumps you back to the prompt, it’s likely rtl_fm died and this can happen if your dongle accidentally gets disconnected from the USB port due to vibration or instabilities.
I’ve personally verified the figures that come out of this, and I can definitely say it’s correct and provides a higher level of precision than the LCD screen itself does. That’s a nice added bonus! But do remember to set your voltage correctly in the .c source file before compiling, if your efergy LCD monitor is set to 240v, and the .c file is set to 230v, you will get slightly different numbers!
Maybe this will cause Efergy branded energy monitors to fly off the shelves … now that a $17 SDR dongle can decode them …
My Tiny Insignificant Contribution
In no way do I intend to overshadow Nathaniel’s developments, in fact, none of this could have happened without him. However, I still felt that for data-logging convenience, I could (with my fairly basic and rusty C skills) add data logging to the core program itself, so it dumps to console and to file.
But better than that, I have it accept an argument for the dumping file name, with compile time options for line ending (Unix or DOS) type and flush interval (number of samples). This can be important if you want to log as much data as possible, knowing the power could go out at any time, but if you don’t want to hammer your disk. SSDs can wear out quickly if you keep flushing small writes as they cause metadata updates which cause additional wear.
I also recommend using the -O3 compiler option for gcc, although its real life impact is probably very small. Maybe for Raspberry Pi users, avoiding the GUI altogether and an overclock might help make it work a little better as well.
I’ve uploaded the code here: EfergyRPI_log.
If you invoke it as …
rtl_fm -f 433550000 -s 200000 -r 96000 -g 19.7 2>/dev/null | ./EfergyRPI_log
… it doesn’t log. It behaves just like the previous code, although maybe slightly less efficient.
But if you invoke it as …
rtl_fm -f 433550000 -s 200000 -r 96000 -g 19.7 2>/dev/null | ./EfergyRPI_log log.csv
… it will log into log.csv, appending to any existing data at the interval specified at compile time. You can wrap this up in an infinite looping script which will call the program again in case it dies because the USB got jiggled. There’s no risk of losing data as the file is always opened in append mode rather than write mode. If the file fails to open, the program (should) exit with a message (as per the coding).
It’s mainly a code of convenience for myself, although if others find it useful, they can use it. As a result, of course, there are no warranties and in fact maybe I’ve even made the code worse. But again, you should probably refer to Nathaniel’s site for further updates and information, and maybe leave him a comment of thanks if it worked for you.
Conclusion
To sum it up – the RTL-SDR shows its versatility yet again, thanks to the genius of the community. In this case, I thank Nathaniel Elijah (whose code I’m using right now) – and I hope to see more interesting developments and details of the work required coming in the future.
Pingback: Decoding Efergy Energy Monitor Signals with RTL-SDR - rtl-sdr.com
Stupid question. Is there a way to make your software work with a sound card. I have a pc1000 scanner and i want to plug the discriminator into the sound card but not sure how to get the audio into your program.. Can one pipe it in somehow.
It may be possible if the scanner has adjustable FM demodulation bandwidth – at least 140khz bandwidth is necessary to cover the FSK, preferably 200khz to take tuning error into account. You will need to find a program that takes audio from the input at 96000hz, 16 bit mono and pipe it into the decoder.
If you can satisfy this somehow, you may be able to get it to work, although I’m not sure what effect the sound card’s frequency response will have on the FSK data waveform. I’m sure there’s a way to try under Linux but I don’t know it off the top of my head. Maybe sox can take input from a sound card?
cool if i find out I will let you know
Hi All! I can use this script with a Chacon ecowatt 700 that looks like efergy. And this configuration
rtl_fm -f 433500000 -s 200000 -r 96000 -g 10 2>/dev/null | ./EfergyRPI_log log1.csv
But log1.csv allways is empty when I stop the script. Why?
Thanks!
I have set it to dump output after 10 samples minimum. Please leave it running for at least 10 samples (that could be 60-seconds for 6 second transmit interval, or 180 seconds for 18 second interval) before closing and check the file.
Also ensure you are running it from a directory without write restrictions (i.e. Don’t use C:\, anything under C:\Program Files).
– Gough
A very interesting hack. The Efergy is a 3 phase monitor but is usually sold with just one sensor. Additional sensors for the other phases are available for AUD $20 here:
http://efergy.com/au/products/accessories
Decoding of data packet for the other phases is covered by Marcus Lond in comments on this post:
http://electrohome.pbworks.com/w/page/34379858/Efergy-Elite-Wireless-Meter-Hack
The Efergy is not a directional device so it cannot track energy exported to the grid where a solar system is installed. But by using the Efergy to monitor different circuits in the switchboard, the exported energy can be calculated with simple maths!
So with the addition of a few lines of code and another sensor or two, we now have a 3 circuit solar energy monitor! How awesome is that!
My Raspberry is currently monitoring my Sunnyboy Solar inverter via a bluetooth connection and pushing the data to PCoutput.org (using SMAspot) so hopefully it will be able to handle this task as well (Once I get my hands on a radio dongle!)
My dongle arrived and I have got this working on my raspberry PI thanks to all of the useful info on your blog. I had to tweak the frequency to 433.5Mhz for my dongle.
I also made a new 173mm long antenna by turning a brass adapter on my lathe with an M3 female thread at one end (that screws to the antenna base) and a 6×32 female thread at the other to take a piece of 1/8″ metal rod (salvaged from a printer) that I also threaded. This also let me drop the gain on the antenna to 3.7 just as you did.
Provided the voltage is set the same in the code as in the Efergy monitor, the results are very close. I am still not sure how accurate this meter actually is until I get some data recorded.
It seems that I won’t have to use multiple circuit sensing as if you attach the sensor clamp so it goes round both the solar and mains inputs the right way, the net consumption data is recorded as the circuits subtract the solar output to report a net consumption figure.
So now I just need to modify Nathaniel’s code so that I can update consumption data on http://www.pvoutput.org every 5 minutes. The Raspberry PI has a temporary folder that is RAM disk so I will probably write a cumulative total to a file in this location to avoid dealing with interprocess communications which would be beyond me. I can then read this as if it was a meter every 5 minutes.
Thanks again
Dear Rod,
Nice to hear! Sounds like you’re quite the handy person with the metalworking – good job. Having the right length antenna really helps ensure you get as much of the signal (with as little of the other less interesting signals to confuse the tuner). Lowering the gain helps lower the amount of noise picked up from the computer via the USB power, at least, in my observation and that helps improve the signal to noise. The exact frequency always depends on the tuner crystal offset – if I have the time, I will make a posting about my (relatively large collection of) tuners and their offsets, but I’ve seen a range over 160ppm (i.e. ~0.07Mhz at 433.5Mhz) error.
As for inter-process communication – I think you’ve got the idea right in some regard – although, if sending the value to pvoutput.org is quite a simple thing to do (e.g. you can write a short socat command for it, for example), then it might be worth investigating piping the data directly (as that will save potential hassles – e.g. ramdisk full).
As usual, it’s a world to be explored :). Thanks for letting us know how you’ve managed!
– Gough
Gough, thanks for your encouragement. I have been trying to avoid coding in favour of building things in my shed but this has lured me back! As always, there are more ways than one to get the job done! I use SMAspot on my Raspberry to upload data to PVoutput.org. It collects the data via Bluetooth from my SMA solar inverter. My PVOutput site can be seen here:
http://pvoutput.org/list.jsp?userid=28912
You can see from the live data that the data is uploaded every 5 minutes as SMAspot is scheduled via a cron job.
Initially, I had thought it would be best if SMAspot did all the uploading in one operation but from what I can see, PVOutput.org will allow multiple upload clients. So with this in mind, I have modified the EfergyRPI code to add an interval period so that power consumption (in Watt Hours) is tracked in a cumulative meter and also for a given interval (default 5 minutes as per PVOutput.org). I have added a few additional fields to the program output and the code is here:
http://www.vehiclemods.net.au/docs/EfergyRPI_002.c
I just hope my maths converting from Watts to Watt Hours is right!
See the comments in the source for the meaning of the additional fields. You may like to reduce the value for the OUT_INTERVAL #define for testing purposes. After OUT_INTERVAL seconds, the interval meter is reset to zero.
SMAspot provides a pretty good template to use the CURL library to upload to PVoutput in PVOutput.cpp so I don’t think it will be hard to get the data uploaded now I have got this far.
Incidentally, if you are using the Rasberry or another Unix computer to drive the SDR dongle, you can use “rtl_tcp -a 192.168.0.18” and then use SDR_sharp.exe on our Windows PC to connect remotely to view the waterfall visualisation accross the frequencies. Just substitute the IP address for the one used by your Unix box. This removes the need to install cygwin on your Windows box.
Sounds like you’re pretty close to having it all sorted. Thanks for the useful information – I’m sure others reading would very much appreciate it too!
Thanks,
Gough.
Gough, thanks for this and the other posts – I have checked the freq using rtl_tcp & gqrx and its around 433510000 as your other post suggest. I am seeing a signal every 6 seconds, but the decode trace only print 0 values:
02/09/14,19:37:32,0.000000
02/09/14,19:37:38,0.000000
02/09/14,19:37:44,0.000000
02/09/14,19:37:50,0.000000
02/09/14,19:37:56,0.000000
02/09/14,19:38:02,0.000000
Am I right to assume its getting through the checksum in the code to get this far or is the something else I should be looking at
Appreciate any pointers
/DB
I’m assuming that the transmitter does give you the right value on your Efergy branded LCD? I know it’s silly, but accidentally disconnecting the clamp will give you the same 0.000 result.
If it works with your original LCD, my thought would be that the actual data bits are in a different location, and it seems by chance that the code had recognized the packet. I think you might have to grab a sample transmission and see if Nathaniel Elijah (the original implementer of the code) has any ideas.
It would be nice to know which model, and otherwise, maybe try relocating the clamp between the three sockets on the transmitter (although it shouldn’t matter as it seems to send an aggregate value, might still be worth a shot).
– Gough
Dave, I had something similar happen yesterday. When I went out to the meter box, the transmitter was lying on the ground and no longer connected to the sensor clamp! I think it is telling you the transmitter is working but there is no data being received from the meter box. I think you have a problem where the clamp plugs in to the transmitter or the clamp is not fitted correctly. Maybe try plugging the clamp into another socket. I am guessing the Efergy meter is also showing no data.
I sucessfully got a modified version uploading consumption data to http://www.pvoutput.org yesterday. I had a bug at midnight and the values were not reset to zero for the next day. Very exciting!
Once I have tidied it up and got it fully installed, I will share the code.
All,
thanks for all your helpful comments, I have just checked the clamp is fitted ok (tx is an elite 1.07). The LCD is receiving data fine, if I disconnect the clamp then it reports 0.00.
I suspect it maybe a protocol issue rather than a hardware one. I will do a capture at some point and ask if Nathan or someone could look at it to see if there is any decodable (if perhaps offset) data in there
thanks again
/DB
Dave, sounds odd. Does your meter look like the one shown above? Does your neighbour have one too? In the calculate_bytes function try adding this line above or below the existing printf() statement
printf(“%X,%X,%X,%X,%X,%X,%X,%X,%X\n”,bytes[0],bytes[1],bytes[1],bytes[2],bytes[3],bytes[4],bytes[5],bytes[6],bytes[7],bytes[8],bytes[9]);
This will provide a Hexadecimal dump of the data returned from the meter which may be useful for debugging purposes. You would have to work through the maths in the code to see if can make any more sense against the original work by Nathaniel.
Rod
thanks for the response; the receiver is the same as the one shown and same version, I have isolated that its my transmitter I can hear by powering down and the signal stopped.
I added the line:
printf(“%X %X %X %X %X %X %X %X %X %X\n”,bytes[0],bytes[1],bytes[2],bytes[3],bytes[4],bytes[5],bytes[6],bytes[7],bytes[8],bytes[9]);
And got the same results even when I also disconnected the clamp and got 0 values at the LCD receiver.
02/10/14,12:39:50,0.000000
0 0 0 0 0 0 0 0 5 0
02/10/14,12:40:02,0.000000
0 0 0 0 0 0 0 0 5 0
02/10/14,12:40:08,0.000000
0 0 0 0 0 0 0 0 5 0
I am going to go back and look a the RTL_FM build too
Out of interest what versions of the transmitter are people using, mine is marked “elite 1.07”?
My Meter is an “elite 3.0R.”
The data format is pretty well described here in a table format
http://electrohome.pbworks.com/w/page/34379858/Efergy%20Elite%20Wireless%20Meter%20Hack
Note the 2nd and 3rd bytes have constant data and yours are 0 so something is wrong!
I am clutching at straws here as I know nothing about digital radio comms but I would revisit the frequency offset you are using. Maybe some of the data is being clipped as it seems unlikely that the data structure has changed from Gough’s V1.0 and my V3.0
My efforts with PVOutput export continues. The data needs to accumulate until midnight and reset to 0. If you restart the program during the day, your meter goes back to zero so no data is added to the power consumed on PVOutut until the meter catches up. I have written some code that should retrieve the last consumption data on PvOutput on startup so the meter variable can be initialised but I have yet to test it. I have also had no luck scheduling the script to run unattended when the raspberry reboots.
Dear Rod,
If your Raspberry Pi is running in console, you can try sticking the path to your script at the end of /etc/rc.local like how I did for my ADSBpi (http://goughlui.com/?p=3889).
If your Raspberry Pi runs in the LXDE desktop, you will have to make a .desktop file entry in ~/.config/autostart/ like how I did for x11vnc in my Intro to Raspberry Pi (http://goughlui.com/?p=50).
I did this all a while back, so some things might have changed, but hopefully this gives you something to go on :).
As for the transmitter – yes, mine is an Elite 1.0R (the R would stand for receiver, but since I bought them together, it would be a 1.0 transmitter as well). I have the clamp plugged in the left-most port when the text is facing the right way and you’re looking at the transmit interval button, and I’ve had to make no modification to get mine to read just fine – I would still guess that the ADC value might have shifted elsewhere in the packet since the Elite transmissions are quite long (bit-length wise).
– Gough
Gough, thanks, I did not spend much time with this today and will come back to the scheduled task later. I played with rc.local without much luck. It is a headless box and X is not used. Anyway, there seem to be a few solutions. In the meantime it can continue to run in a Putty instance on my laptop.
I am successfully getting the last status for the day from PVoutput.org (which required a callback function to capture it) but CURL reports an error with a stream or something. It is a bit too late to debug this tonight but I will resolve it. Once the code proceeds past the error condition, I need to test it is extracting the consumption from the returned CSV string. I think the program should have a config file that would let the user to set his PVoutput credentials so they are not hard coded. Should be pretty neat once it is done.
It is really interesting to see the graph of power usage graph on Pvoutput now the script has been running for a full day with spikes at meal times when the kettle is boiled! Looks like the coffee maker uses less power than the kettle!
Well, finally got it working (provided the meter resets to zero tonight). The following version of EfergyRPI software exports consumption data to http://www.pvoutput.org:
http://www.vehiclemods.net.au/docs/EfergyRPI_PVO.c
Just enter your PVOutput siteID and API key in the code before you compile it using the updated gcc command in the code. Even if you don’t have solar, PVoutput has some nice daily graphs of consumption.
Note that on startup, the software retrieves your current consumption for today from PVoutput. This means that if you restart the software, you will only loose consumption data for the time it is down not the full day!
The watts data uploaded for the PVOutput recording interval (default 5 minutes) is the maximum recorded in that period. Enjoy!
Many thanks for sharing with us all! Nice work on extending the code – you may be able to modify it so that the keys are read in as command line arguments rather than being hard-compiled into the program (e.g. if you started the program with two arguments (e.g. ./EfergyRPI_PVO argument1 argument2), argc should be 3 (program name, argument 1, argument 2) and the strings should be accessible at argv[0] (the program name), argv[1] (argument1), argv[2] (argument2)). Maybe do some quick googling of “C argc argv” if you need a few examples. This should be enough to prevent any need for hard-coding the values in, but you’ll have to document how to use it somewhere.
I would probably have a quick section of code in main that checks argc for the expected number of arguments – if not correct, print a quick message on how to use the program and quit. If it is correct, then validate that the two arguments are the right format (e.g. key is of right length) – if not, print message and quit, otherwise then use it in place of your const char arrays. It’s been a little since I’ve played with it – I’m not certain if the last argument includes the \n or \r\n in the command line – if it does, you’ll have to trim that off before validating.
Of course, you don’t have to do this, as you’ll probably have just one PVOuptut siteID and key pair to deal with – but it might be a handy tip if you write more C programs in the future that needs to take in some variables.
Great work however – I think the best motivation to program is to solve a problem and watch the fruits of your labour in action.
– Gough
Thanks Gough. It is so long since I have written code, I can always remember the procedure to call but not always the syntax.
I have forgotten the argv/argc stuff but I can remember that get getopt() is really powerful to parse the command line. I have run out of time for a while and yes, I only need one instance!
I thought that a few switches are required. Something like:
-s = sid
-k = API key
-f = config file
-c = calibrate (eg +- a percentage value to get the readings more accurate)
Pairing this with SMAspot on a Raspberry is a logical choice and if the config file used the same syntax as SMAspot (PVOutput_SID and PVOutput_Key) you could use the settings in SMAspot.cfg so you only had one config file to maintain.
In one lot of test readings, I thought the meter was out by about 7% so it will be good to review this once I have a stable system and some data recorded. It would be good to be able to adjust for this if it proves to be a consistent figure.
Next thing is to get the script auto loading on bootup before finetuning it. Can’t leave it running in a window on my laptop forever!
If you don’t want to leave it running in an SSH session, you might want to investigate the ‘screen’ command. It lets you open a terminal remotely, and leave it open despite disconnecting the SSH, thus your processes should remain running. Next time you connect via SSH, you can re-connect back to your screen sessions. I remember using this to keep some things running on someone else’s VPS for a while, although again, the exact syntax evades me. (Try this for a start: http://blog.scottlowe.org/2011/06/23/using-gnu-screen-with-ssh/ or better yet, this one: http://www.howtogeek.com/howto/ubuntu/keep-your-ssh-session-running-when-you-disconnect/)
As for the accuracy of the efergy power meter – I also found some discrepancies with low-power-factor devices – some seemed to read much higher consumptions (e.g. microwave oven standby appeared to be ~ 70w, whereas an accurate meter with the power outlet proved it was only ~5w but with very low power factor of 0.1). I don’t think it’ll ever be perfect, as the change of mix of appliances changes the total power factor and hence the “error”. That’s part of the reason why turning on certain appliances causes very little-to-no change on my LCD …
It’s still good for being indicative, but as they said in the manual, it’s not supposed to be used as a revenue meter :).
– Gough
Gough, Thanks for the info on the screen command. That did the trick! I can give my laptop a rest! For the benefit of others:
Install: sudo apt-get install screen
New session: screen bash
Detach from session: Ctrl-A, release, then press “D” (you can close Putty at this point)
Re-attach: screen -r
Kill screen: Ctrl-D
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=8099&p=97315
I created the new session and ran rtl_fm in it and it is running fine.
The background power consumption is a bit under 1000 watts (did I tell you I have a very good network here that uses a bit of power?). Errors at low current draw will not be an issue. I am more concerned that the single clamp has been placed around both the mains input and the solar inverter input. They are meant to cancel each other out to provide a net consumption figure but it might be at the expense of accuracy.
Another alternative (which is y plan B) would be to use an Arduino to sense the LED on the mains meter that flashes every watt hour consumed and send it to the Raspberry by a zigbee. But that will cost a lot more than the $25 I spent on the SDR dongle! If you have an electrician in the family, I saw on Whirlpool that you can purchase a Class 1 meter with a pulsing output for under $50 that you can fit in the switch board so you could wire an Arduino to it as well.
For information I sorted the issue; i got hold of a more up to date transmitter and did nothing to my configuration including leaving the RTL_TCP configuration in place and immediately was able to decode the signal:
02/13/14,19:26:33,492.175293
9 EF 43 60 44 7A 2 5B 5 0
Thanks for everyone’s help; there is obviously a much older specification transmitter out there that has the data somewhere else.
/DB
Dave, glad you got it sorted. There was some talk about an earlier model having a different protocol so I guess the Efergy LCD meter is backwards compatible. I wish I was so lucky! I still have not been able to get my code to reset the counter at midnight back to zero. In the meantime, I have got my head around the various getopt () incarnations and added all of the command switches I think could be useful Including parsing a simple text based config file.
I will try another approach to trigger resetting the timer by checking how many second past midnight it is everytime the meter reports a reading and if it is greater than 86400 (seconds in 24 hours) reset it.
I rebooted last night and could no longer run rtl_fm and found with some tweaks to rc.local made earlier, that an older version of the decoder had been started as a service so that is one accidental step forward. I have not updated the code in the link above but will do so when I know it is working!
Well, I got this working perfectly for a day and the totals got reset at midnight as PVO requires and on the second day (this morning), at 3:00am, it returned some ludicrously high value to PVO that overflowed the numeric value at their end so the consumption is off the scale! I think the error must be in Nathaniels code.
I added a few command line switches and I added some logging to see what happens at midnight and I caught an entry that said I had used 49,000 watt hours in a six second period! That is about 48 hours of consumption.The Efergy meter was unaffected and reports a more conservative value that I expected. I need to add some data validation to catch any unexpectedly high values and ignore them. I just have to work out what would be an acceptable threshold to test against.
Dear Rod,
That is not unexpected. In my extended logging, I have found spike values about once every 2-3 days which can be very very very large positive or negative. I think it may be from noise/interference causing decode errors or mangled frames due to rtl_fm and how it handles packet losses over USB. Alternatively it might be a bug with data validation, but my efergy LCD has had these glitches but only about once a YEAR.
I have experienced it numerous times before, but the values that are incorrect are off by a “large” margin (e.g. reading in the hundreds of kW+). You might be able to set a “filter” by comparing it to previous value and if delta > 10kW, then use previous value?
– Gough
Gough, Thanks for the advice.
Hmm, if you look at the data format described by the guys at electrohome which I linked to previously on 11 Feb, Alex in comments on 7 Sep 2013 use some conditional code for calculations and Nathaniel doesn’t. I wonder if that is where it is coming unstuck? Is he using the same meter?
Alex used this
double bigbyte = Reading1 * 256 + Reading2;
if (bigbyte == 0)
return 0;
if (Exponent != 255)
retvalue = voltage * (bigbyte / 32768f) * (System.Math.Pow(2, Exponent));
else
retvalue = voltage * (bigbyte / 32768f) * (System.Math.Pow(2, -1));
return retvalue;
Exponent = bytes[7] which Nathaniel uses in a conditional that indicates it is a checksum. I will study this a bit more but I am very rusty! I’d like to know Nathaniels source for the data format or if he worked it out himself.
I have found the spurious entries are not as big a problem as I thought as you can edit the faulty readings for a given date and time at PVO from your browser with something like this:
http://pvoutput.org/service/r2/addstatus.jsp?d=20140217&t=08:35&v3=2836&v4=836&sid=(Your SID>&key=
Where:
v3 = Cumulative watt hours for the day
v4 = Current Watts (well I am using the maximum in a 5 minute period)
I have a 63 amp main breaker so I can only consume 15120 watts (63 A * 240 V) before the main breaker flips. So taking say 80% of this figure that gives an instantaneous limit of 12096 Watts. I think simply throwing away any meter values exceeding this threshold in a six second period will probably do the trick. We won’t miss six seconds of consumption per day.
As I keep working through this, I keep thinking of more command line switches to add (like voltage, and now main breaker size…. It never ends.
Anyway, touch wood, it is behaving today.
Sounds good. Thanks for the continual progress updates – rest assured I will approve them as soon as I can see them so everyone can benefit from them.
On the other hand, I do have a 63A main breaker myself, but my peak consumption at this house has never exceeded 5kW with the air conditioners and oven going. I’d hazard to say any reading above about 8kW for me can be safely ignored (and that’s what I tend to use as my limit). I think I’d be hard pressed to try and get it above 5kW – most of the time, we hover (with our network core services) at about 0.48kW during the night and about 1kW during the day (both with an aircon going) with occasional usage spikes (e.g. +1kW for microwave, +2.2kW for kettle, +3kW for stove).
I suppose as long as any spikes you experience are of the “obvious” sort – that should work. But be wary – I have also seen NEGATIVE values which is why I did suggest to take care and maybe look at a “delta window” of +/- 5kW from the last reading – possibly in combination with a range of 0-12kW. I suppose the range 0-12kW instantaneous could be enough.
Just my thoughts – but I find the spikes to be 1-2 days in my experience. Will vary due to antenna placement etc.
– Gough
Thanks Gough. Your feedback has been invaluable. I have added a heap of switches to the code today (now about 15 of them) but have not compiled and tested it yet. This will mean a user will not have to edit the source and recompile.
I added switches for –voltage, –breaker and –derating. These default to 240 volts, 63 amps and 1.25 respectively. the watt limit allowed will be (63*240)/1.25 = 12096 watts.By playing with the derating parameter (eg. increasing it), you can bring this down. The code has been inflated from Nathaniel’s original 200 odd lines to about 750 lines now. I also need to revisit my end of day roll over as it is currently a bit crude.
My idle current is about double yours (Todays minimum is 857 W)….
Negative values cannot exist in the wild. There can be no such thing a negative watts, I think I will throw them away. It is possible that Nathaniel has missed an exponent that only impacts with high readings when a byte value overflows to a neighbouring byte in the Efergy data packet. i might add another switch to enable Alex’s date decoding method and you can test as well.
And darn, I had another spike of 55000 W tonight! I will log the exceptions above the threshold once I get this deployed and they happen at night not during the day. Funny I never saw one until my code was finished,it could be a physical installation issue. as I have not mounted stuff up yet and the antenna is not standing upright., maybe playing with the gain could help too…..
My main concern would be interference mangling the packet. Maybe it’s an unlucky coincidence and someone pushed a 433.92Mhz key fob right as the packet was being transmitted and mangled it enough while still being able to validate, or maybe impulse noise. My habit is to turn the gain as low as practicable as it reduces the impact of noise from the computer’s power supply itself, and try positioning the antenna away from the Pi if you can. Apart from that, you can’t turn it too low otherwise you might start missing too many packets.
Regardless of platform, I have witnessed the spikes, both negative and positive, so there may indeed be a validation issue. I’m not too sure if it’s with any exponent because it happens randomly and doesn’t seem to coincide with a load “switching on” or “switching off” when you would expect large step changes in consumption level. Nothing’s perfect but there might be a way to improve it. It may come down to how the FSK itself is decoded even. For now, I’m at a loss, and as it works the majority of the time, the easier way would be to deal with the erroneous data values and sort out the validation if time permits.
I only mentioned the negative watts thing as I have experienced it. Maybe it is an overflow or data-type issue with the C code – but regardless, I think it’s something to be careful of. Unfortunately, aside from that, I really don’t have much to contribute :\.
– Gough
Well, I am nearly there. I tidied up my installation, mounted the antenna, dongle and raspberry permanently with good separation between them. I was finding that with rtl_fm and SMAspot both running, the Raspberry was struggling a bit and dropping some SMAspot values intermittently during the day. This is not really a problem as on the next reading, it catches up but the pvoutput graphs were not very pretty!
I added a –quiet switch to the app which disables all output to the screen and all the memory intensive calls to sprintf() and printf () in an attempt to free up the CPU a bit. This and the changes to the physical installation has solved the problem and yesterday I did not see a single dropped entry with the software running in the background on bootup.
Unfortunately, in my attempts to make the end of day roll over more robust, I had a regression and the meter did not reset to zero at midnight. I am pretty sure I have solved the issue so hopefully after midnight tonight I will have something to share.
I think I need to find another home for this application so I can fully document this properly, not just in the comments here!
Sounds like you’re pretty much there. On that note, why not start up your own free blog at wordpress.com or blogger.com, and maybe upload your code to Dropbox public folder and link it from there (since WordPress does freak out about hosting code files)? Or maybe you can try Google Sites as well.
As long as you submit it to a search engine, you should get found and it should cost you nothing to host something this small.
As a plus, you’ll be able to share pictures and more information about your later projects as well, which would be most interesting.
– Gough
Just an update because I still have not taken the time to make a home for this yet. I have updated the source file referred to previously (link repeated again):
http://www.vehiclemods.net.au/docs/EfergyRPI_PVO.c
http://www.pvoutput.org has a field for temperature which is not being populated on my system. I ordered a DS18B20 temperature sensor from http://littlebirdelectronics.com/ and a header socket for the Raspberry GPIO. They only cost a couple of bucks each. I spent half an hour or so soldering the sensor onto some cat 6 cable and followed the instructions on this link
https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/temperature/
to fire up the sensor and it is working happily. I have written some C code which writes the temperature (in either Celcius or Farenheit) to the screen. The next step is to incorporate this code into the SDR code above and add one more command line switch to enable temperature reporting.
If you are trying to make sense of how to configure this, compile and run it on its own with the -h or –help switch and it will provide a list of all of the switches. No need to call it from rtl_fm to see the help screen.
Anyway, it has been happily running in the background for a few days now.
Gday,
Just corious as to weather you have had any luck decoding the output from a transmitter that has multiple sensors? eg solar in, mains in, house main etc
As far as I know, those who have used multiple clamps only get one reading. The clamps are designed for use in monitoring a three phase supply, rather than multiple disjoint inputs. Unfortunately, the clamps don’t know the current direction either – however, if your house consumption always exceeds the solar generation, you may clip both leads into the same clamp so that the generated energy is subtracted and you’ll be monitoring only the supply from mains.
I don’t have a three phase supply nor a PV system to monitor, so I can’t test this out, however, I do know that if you run multiple transmitter units, the decoding will have interleaved values, without any way to differentiate which transmitter is which.
Hope this helps.
– Gough
Thanks for the update! I can pull the data out from the solar system directly so if i have to use just one clamp i can.
Also, im not sure if this is for you or for the upstream guy Nathan, but i think there is a bug in the code.
Whrs = (result * EF_INTERVAL) / 3600.0; /* RW – assume power used is constant for Efergy sample period and convert to watt hours and update meters */
I think that should be (result * interval) / 3600.0
Because if you miss 3 EF_INTERVAL’s due to bad transmission etc, its only calculating for a maximum of 1 EF period, when it should actually be calculating for the interval between received data packets.
Dear Nathan,
I can’t seem to find that line in my code anywhere (the one linked in the main body text of the article), so you might be looking at some other downstream contributions (e.g. by Rod), however, in principle I would agree that if a packet is lost in decoding, you aren’t “integrating” that 6-second (or possibly more) period of data and you’ll underestimate the energy.
That being said, it’s important to realize that it’s not a 100% result all the time, and also more importantly, that these devices can be horribly inaccurate for power factors deviating significantly from 1. As a result, to use it and expect it to be within 10% might be optimistic in some cases. I’ve done a few quick informal experiments, but I haven’t had the time to detail them properly, so do understand that you’re not going to capture short energy usage spikes and the actual values may not be 100% either.
– Gough
Nathan, the RW gives it away! It was Me!
Great to see somebody else is interested in this.
I don’t see this is a bug in my code but your suggestion may improve the accuracy by using data I calculate in my improved version.
I added the variable “interval just to track time between readings and did not change the original calculations which returned the Instantaneous Watts in the variable result
So the line of code you refer to simply takes the original result and converts it to watt Hours.
Now that I am tracking the time between readings, your suggestion will extrapolate the last successful reading across any missed readings. This would be an improvement as the current code simply does not track any missed readings.
Since I added the temperature logging, I think the poor old raspberry’s CPU has maxed out and I am getting a number of missed power consumption readings on PVoutput.org which did not happen before. I am happy to ignore this as for me, the data is sufficient to show the trends which is background idle current consumed of about 1 kW and occasional spikes during the day as we turn on appliances that use a bit of power. The secret to reducing costs is to reduce the house idle current.
We actually have a few updates for you. Ill send it through shortly. We found another issue with the getStatus from pvo at startup, in that it seems to be sending GMT time as part of the initial query, which in AU (+10) gets the results from 10hrs ago and sets that as the last power consumption. We found that if you dont send a datetime in the getstatus request, it just gets the last update automatically
Correct, it will “guestimate” across any missed readings, which for us based on the location of the receiver was important as we were losing 1 in 10 updates, so it was sufficiently out when calculating total whrs for the day.
Nathan,Thanks. I always hate working with UNIX dates and times.
All of the PVoutput stuff has been added by me. I can’t see how I can tell you to contact me here. If you use this form
http://www.vehiclemods.net.au/contact-us/default-form
I will reply by email. If you send me the update, I can publish the updated code on my web server.
It has been working tirelessly for months now.
Nathan, I missed your earlier comment about multiple sensors, In one related blog elsewher, some of the Efergy monitors overseas populated data in the packet for each of the three phases but I did not see this happening with my unit when I swapped the clamp to another input.
If you want to get deep into it, have a look at http://openenergymonitor.org/emon/
Robin Emley has solved the directional aspect of current sensing by also monitoring voltage on the mains and tracking each AC cycle. After documenting his findings on the Open Energy Monitor forum above, he has set up his own web site here. http://www.mk2pvrouter.co.uk/
The cool thing that Robin does with his PVRouter is that his circuit diverts surplus solar power to your hot water system. I have built and tested his circuit and am waiting for my friendly electrician to have the time for a freebie installation. The plan is to move my hot water off the current off peak circuit onto the normal tariff. As long as I have about 4 kW of surplus solar power a day, I will have free hot water. For the few days a year that I don’t achieve this (guessing > 10) , there is a manual bypass switch to allow it to be boosted from the mains. Restating what Robin’s router does; no power is exported to the grid until the hot water thermostat switches off. If at a given point in time, solar output exceeds consumption by say 100 watts, then that 100 watts will be directed to the hot water system and the meter will not register any consumption. All very clever.
Nathaniel and Gough’s work has been super helpful for decoding messages from a new Efergy Elite 3.0 TPM using a Raspberry Pi with an R820T based rtl-sdr device.
The Efergy TPM has an extra byte of data (9 total) and seems to embed the line voltage into the power number that’s transmitted by the sensor. I don’t know what the extra byte is for yet and I can’t figure out the checksum. But I set VOLTAGE to 1 in EfergyRPI_log.c and the KW numbers I’m getting are within 1-2 watts of what the Efergy receiver is showing. Yay!
I added a new debug/analysis mode to Gough’s EfergyRPI_log.c that might be helpful to folks trying to figure this stuff out. Also, I fixed the signed/unsigned char problems that the original code had. Updated source code is available here:
https://github.com/magellannh/RPI_Efergy/blob/master/EfergyRPI_log.c
I had good luck invoking it in debug mode using:
rtl_fm -f 433.51e6 -s 200000 -r 96000 -A fast | ./EfergyRPI_log -a 2
A big thanks to everyone who worked on this, and to commentors above that helped a ton as I was trying to understand why I wasn’t getting good data.
Thanks for letting us know of your progress in working with the Efergy device, I’m sure it will be useful to all who are interested.
– Gough
Possible good news for folks using Efergy devices that transmit 9 byte messages and have been struggling with undecipherable checksums. The mystery might be solved!
I tried some furious googling on checksum/crc algorithms used by various 433mhz transmitter/receiver chips. I don’t know which chip the Elite 3.0 TPM uses, but I lucked out and stumbled on a site that helped me figure out that it uses the CRC-CCIT (XModem) crc algorithm. I’m hopeful that this algorithm might also work with some other Efergy devices that transmit 9 byte messages.
This site has a great online crc calculator:
http://www.lammertbies.nl/comm/info/crc-calculation.html
This site has a c code snippet with the algorithm:
http://www.nongnu.org/avr-libc/user-manual/group__util__crc.html)
Apparently, CRC-CCIT (XModem) uses a polynomial of 0x1021 with the crc seeded with 0. The crc is 16 bits long, which explains why messages from my device have 9 bytes instead of 8.
Here’s a link to an updated RPI_Efergy_log.c file:
https://github.com/magellannh/RPI_Efergy
Since I only have the Elite 3.0 TPM, I can’t test other Efergy devices and I could have broken something. If you pull the code down, check the first set of #defines to make sure they match up with your device.
It’d be great to have #defines with comments stating the exact model numbers and appropriate values to use, so folks could just uncomment the correct set of #defines for their device. If you have a device that works and could post the full model number and the #defines that work, I’ll update the file (alternatively, you could make the changes with github and do a pull request). With minor tweaks I think this code can handle several Efergy FSK based devices.
Pingback: Sharing the Data: Efergy Wireless Energy Monitor | Gough's Tech Zone
Hi Guys
I am not so much wanting to decode the Efergy but wondering if anyone has checked out its accuracy with non-linear loads like a powerful battery charger that has a bad power factor (rectifier front end). Efergy appear completely unable to get past telling me that it measures current and sends it to the display – kind of obvious.
Anyone?
Thanks
John
As far as my experience is, the accuracy degrades quite severely with non-unity power factor loads. It is not intended as a device for accurate metering, merely indication, and there are errors that can arise from the non-sinusoidal current flow especially due to distortion due to the magnetics in the clamp sensor, offsets/linearity issues with hall-effect sensors and limited sampling abilities of the transmitter unit. I wouldn’t use it where you’d want accurate measurements – I’ve seen it to be off by about 70-80w on some idle loads with <0.01 power factor. But for loads with power factor of about 0.8 and above seem to do reasonably well.
- Gough
Thanks for the quick response Gough.
I don’t need accuracy so much as indicative, clear differences. The Trec I tried can’t tell if I have 12 chargers or 11 chargers running (200W battery chargers).
Yes, I won’t bother with it if it hasn’t got some kind of true RMS measurement system.
The Smartmeter does fine but it measures the whole house and I just want one powerpoint measured.
I wonder if any progress has been made in reading the three phases separately; I have a ‘XRQELITE20’ transmitter with three inputs. It’d be really cool to see all three phases, where the load’s at, and (being lazy!) what fuses to check first when lights start to go out and the computer can tell me ‘phase X is at zero!’. 😉
A brainstormed brief idea (it’s 2AM.. ugh) would be to put in a cycling set of three transistors that enables the transmitter contact with them one at a time, so that the readings received are for ‘phase 1(or2) / phase 2(or3) / phase 3(or1)’ over a 30-second period. And then apply Cleverness to deduce which phase info got sent. Maybe something as invasive as including the transmitter’s send button – ‘if it’s 10 seconds, it was phase 1 we got, if we waited 15 seconds, it was phase 2, if 20 seconds, it was phase 3’.
For anyone interested – I love the Efergy monitor, but their cloud visualization doesn’t show if you’re losing data. If you’re doing whole-house monitoring at 10 second intervals, you could be losing HALF your packets before it would be obvious (a 0.00 kW reading for a minute, on their downloadable Report). Far worse at longer time intervals. I am going to ask them to improve this, and came across your work. It’s interesting to see that they have no apparent fault tolerance in their data. (The simplest would be to say how many seconds ago the previous packet was sent. Or the time. Or duplicate the last packet. There are lots of things that could be done.) Your info says it’s simply the time and watt reading. Period. Still, they could do a few calculations on the server side to see if it is generally consistent with getting all readings, and/or they could include e.g. a count column in their ouput (how many readings per minute). Something/anything would be better than the *nothing* they have now. Where you could be missing a lot of data but have no idea (unless you were independently looking into what it ought to be, or otherwise knew it was way off).
Very cool stuff you’ve done. Any comment on packet loss? Or jump into the Reddit packet-loss thread (I am DistFunc there).
Oops, Reddit link here
I’m not a Redditor myself, and I’m a bit strapped for time at this stage, but I am surprised that the Efergy product doesn’t seem to care about packet loss. Indeed, the transmission is really only the raw ADC value at a period which is defined by your settings on the transmitter itself (at least, on the Efergy Classic, intervals of 6, 12, 24 seconds or thereabouts).
The code belongs to Nathaniel Elijah, and I’ve appropriated it somewhat for basic logging using the system clock as the time output. I suppose if you wanted to, you could write a simple program to comb through the output and look for missing times and interpolate a reading, or decide to use time “differences” for integration – i.e. time between readings of x seconds, power consumed = y watts * x seconds = z watt-seconds (then divide by 3600 to get watt-hours). The beauty of open source is you are free to go and modify to your liking.
It is inevitable in a wireless situation that packet losses are going to happen. Especially because this is a unidirectional broadcast from the transmitter – the receiver has no way of informing the transmitter that it didn’t get the transmission. The screen itself tends to hold the last value for a while in case it doesn’t hear the transmission. I suspect there are some flags which are also transmitted (maybe a unique model ID) which is not decoded by Efergy_RPI, which allows for separating multiple Efergy transmitters in the same range by the original receivers. As a result, if you have multiple transmitters, Efergy_RPI will be somewhat confused and decode the output of both “interleaved” (provided they don’t trample on each other transmission-time wise).
That being said, the RTL-SDR itself is also prone to interference from strong in-band transmissions (say nearby Radio Amateur 70cm band usage), and its sensitivity at 433Mhz is not that great. Range is probably a little less than the bundled receiver. Minimising distance always helps. The other thing to be aware of is that 433Mhz is also sometimes crowded with other tranmissions – e.g. wireless doorbells, wireless weather stations, old fashioned wireless headphones (wide-FM modulation), wireless IR remote extenders, some central-locking key-fobs, remote alarm sensors and keyfobs, etc. Minimising or eliminating these sources of competing transmission (especially when they are relatively frequently used) has wonderous effects on reliability.
– Gough
Yeah we had the same issue with the base code, that we were using, so that was one of the things we added. Eg if we missed 4 readings, we would take the average usage between the last successful and the new one, and fill in the blanks. Not ideal, but it alteast gave us a more accurate feel.
Thanks for responding. Right, the issue isn’t that packets might be lost… packet loss can happen any time, to anything wireless. The issue is that there’s absolutely no built-in checking. So how will you ever know if you’re missing packets (without a lot of bother)? Sometimes packet loss can be insidious, like interference in high humidity (mainly affecting your apparent A/C energy load). Or maybe you move a filing cabinet 2 years from now and bam, half your packets are lost… but you don’t realize it until many many months later.
If Efergy packets only have datetime and watts, as you two found, they’d have to add support on the back end. At the very least, simply say how many packets were received in whatever time interval is being shown. And yes, they can perform “watt smoothing” if it’s pretty clear packets were missed. Ideally, it would be optional (a setting on the Efergy Dashboard, like some of the other ones). And if they’re also showing packet counts (so you can see when data was lost), then users automatically know when smoothing happened (if the smoothing option is on). Simple.
When I petition Efergy, I’m only going to ask them to put packet counts in the download csv report you can get. This means even less dev time for them (no web graphs to make more complex).
If they show the number of packets in the interval but the interval can change (10, 15, or 20s in US; 6, 12, or 18 elsewhere), I don’t think it’s a problem because the owner is the one changing the reporting frequency. If the count goes from 10 to 5 per minute a couple of months ago, you’ll just remember that’s when you switched the reporting frequency from 6 to 12s. Pretty obvious, shrug. But if it is mostly 10 and never higher, but occasionally lower in a somewhat random way, you’ll know you have an interference problem. (Or if they’re all 10 you’ll know you don’t, which is important to know, too.) Yes, Efergy will have to do a little “time smoothing” because of internet lag (so you don’t keep having some minutes get 9 packets and others 11 or whatever), but that should be pretty straightforward.
Something else that can be done with your intercepted data: Right now Efergy lets you show up to 5 results per graph (5 transmitters). At my house, I had A/C in the summer (up to 8000 W if both on) and also I have a dehumidifier in the basement that keeps cycling on and off constantly (600 W). It’s very hard to make out anything else going on in the house, with these constant spikes. With your approach, if you had three transmitters (whole house, HVAC, and dehumidifier) you could make your own code to subtract the spikes to see what else is happening on your house. Assuming you can keep the transmitters straight.
In case it helps anyone: I use a 5 V USB charger to power my transmitters (three 1.5 V batteries) together with clips and a barrel plug, a USB to barrel plug, a cheap USB charger which is also uber energy efficient at low or no load. Efergy docs say batteries last 8 to 12 months; by my estimate, it only averages 1 mW across the year, then. Also note if you use more than one transmitter at your breaker box (up to five), I think you could draw them all off the one charger (in parallel).
If there is one time you don’t need your Efergy transmitters working, it’s when the power is down at your house (lol), so why waste batteries or find out the batteries went bad months ago, if you only get around to a whole-house analysis once or twice a year. At the macro environmental level, batteries are a really wasteful way to convey energy, so I avoid it when possible. I think some manufacturers power consumer devices with batteries simply because it’s cheaper to make an empty battery compartment than include an adapter, plus it makes it mobile, so there – that’s that.
Also I realized that, although Efergy only sells the CT clamp approach (at least in the U.S.), you can simply separate the hot lead on an extension cord and clamp it, and now you can easily monitor anything that can be plugged in, too. Of course for any newbies, be uber careful and never cut live wires. But certain extension cords (at least here in the U.S.) have very clear individual wires that can be teased apart while retaining all insulation. (Or, just dig into one that doesn’t, and know what you’re doing.)
In this way I could readily also use the CT inline with a Kill-A-Watt on the dehumidifier and confirm the two types of monitoring agree (they seem quite close in early testing) and just leave the Kill-A-Watt on there a long time to make sure things stay similiar, over long periods. I have a P4482 Kill-A-Watt and greatly recommend it over the so-simplified-its-sad P4400, but also have a new PortaPow Premium USB Monitor to look at USB charger and other very low currents at far better resolution than the Efergy or Kill-A-Watt.
I’m just talking out loud here, I hope some of this is helpful to you two. I can’t do anything of the deeper stuff you do, but there’s still things to figure out, as you can see.
Your work is great, please keep it up!
Hi,
I have an efergy e2-ir, when I run
sudo rtl_fm -f 433510000 -s 200000 -r 96000 -g 19.7 | ./EfergyRPI_001 -a 2
I get (every 30 seconds)
.
..
…
Decode from positive pulses: 09 2e 14 40 00 00 00 00 chk: 8b kW: 0.000
I have a couple of questions, if I want to make an “analog” plot of what I have received, how can I do that and can it actually be that I do not have the right center frequency (and in that case how can I figure that out?)?
Would really appreciate your help.
/R
I’m not sure that looks right. Each RTL dongle has a crystal offset, and the antennas are not necessarily optimal for the signal. You should look for transmission pulses while tuning around with an SDR program (e.g. SDR# on Windows, GQRX on Linux) and play with the gain and -p ppm offset (or determine the “apparent” centre frequency from looking at the SDR waterfall) and use that.
Unfortunately I don’t have the tome to answer everyone’s queries, so you’ll have to do some legwork to try and work it out.
– Gough
Fro Roger, how to view the waterfall to see where the frequency is was mentioned in my post d. 9 Feb 2104
Hi Gough,
I have been successfully using the code you and Nathaniel developed to decode Efergy reading from a e2 classic transmitter, thanks a lot!
Now I have new problem as I added another device (Telldus Duo, a device to control other NEXA brand 433.92mhz switches at my home), when I send ON/OFF command (On Off Key coding) from this controller, the decoding of Efergy on RTLSDR will hang (as if waiting for valid sample.)
What I am guessing is that the signal from Telldus Duo confuses /interferes the algorithm in Efergy decoding. If I restart the decoding it works as normal, until next time a command is sent from Telldus duo.
I wonder, is there anyway I can modify the decoding program to reinitialize itself /discard the invalid signals if an interfering signal is detected?
I’ve not been working on the code for quite some time now, and I’m fairly busy at the moment, but I’d encourage you just to check that the RTL-SDR hasn’t been otherwise affected by the signal. If close enough to your transmitter, I’ve seen the dongles start to do strange things (i.e. drop out, stop sending samples via USB bus) which could explain the hang. Otherwise, it is possible that your new 433Mhz device is creating a signal which is tripping up the decoding. I personally have two other models of 433.92Mhz OOK modulation devices – three OnebyOne Quhwa doorbell senders (which sends long trains of pulses), and two outdoor weather station senders (which send shorter, periodic trains), and neither of them provoke the issue, so it is somewhat difficult for me to pinpoint (at least, at a glance) why this may be happening.
Perhaps a recording of rtl_fm’s output with signals from the offending transmitter and the efergy would be useful, and a check of what the signals look like on a waterfall might help someone else who has the time to debug this.
– Gough
Thank you for replying, Gough.
I managed to solve the issue by lowering the gain value and moving the RPi/Dongle to another spot in the house, to reduce the interference.
Wish you a very good year in 2016.
-James
Hi All
Thanks to everyone who helped with the C++ version.
I just got a C# version up and running with an E2 Classic and NooElec NESDR XTR (E4000)
The following might be useful to others
1. Use SDR# to find the centre frequency for your device mine was 433.574MHz and the power fell off sharply away from this number
2. 19.7 gain works well other values less so
3. MINLOWBITS and MINHIGHBITS need to be tuned for your device 3 and 8 did not work at all for my device. I printed the hctr counts and got 12 and 27 so I used 10 and 20 for the MINLOWBITS and MINHIGHBITS respectively and that created a nice separation
4. There are some coding tricks to getting this running in C# and I’m happy to share the code but not sure how best to do that on this site
Regards
Ian
Hello All,
I have mine working, thanks to all this incredible work.
I have cannot make the total consumption of one day because i just cannot figure out the formula.
I have 6 seconds data transmitting, so at the end of day i would have 86400 data (60sec*60min*24 hours).
Can some one help me:
Consumption by hour(sum all for the hour and divide by 3600) ? By day (sum all for the day and divide by 86400??
Thanks all,
Paulo