Archived Forum

Hi,

RFM12Pi V2 pinout is available here: http://wiki.openenergymonitor.org/index.php?title=RFM12Pi_V2

The Beaglebone black looks like a really nice bit of kit. Please let us know how you get on interfacing with the RFM12Pi. It should be quite simple. Al it needs is a serial port. It would be great to get a blog post up with instructions of how to connect the RFM12Pi to a beaglebone and run emoncms.

Instructions for running emoncms on the pi are available here, should be similar for the bone I imagine: http://emoncms.org/site/docs/raspberrypibuild

Best of luck!

Hi Anthony.

I'm interested in your feedback about the RFM12Pi working on the BeagleBone. Do you intend to use it as just an emonBase (repeater to a remote server) or do you also want to use it as a local server (database, emoncms instance) ?

I've got the RFM12Pi connected to my BBB, and am able to send / receive serial commands.

It appears as though the packets that are being passed back and forth are not just standard strings?  I am trying to get the standard Tx_SimpleRFM12B_demo to give me data I can use, and the Rx_SimpleRFM12B_demo to let me give it a meaningful update (so I can update the EmonLCD)

Right now I am just trying to get communication happening.  I have a ZWave HEM energy monitor that is tied to my BBB, I would like to feed that sensor data to EmonCMS, perhaps even running locally.  But for now I would me happy simply relaying the values to my EmonLCD.

Anyone familiar with how I can encode/decode the data?

I forgot to include, when I use the simply TX sketch, it is received on the BBB like this:

root@beaglebone:~/node-zwave# node rftest.js
I am connected
10 63 0 126 0 189 0 252 0
10 64 0 128 0 192 0 0 1
10 65 0 130 0 195 0 4 1
10 66 0 132 0 198 0 8 1
10 67 0 134 0 201 0 12 1
10 68 0 136 0 204 0 16 1
10 69 0 138 0 207 0 20 1
10 70 0 140 0 210 0 24 1
10 71 0 142 0 213 0 28 1

The leading 10 I will assume is the nodeID, then it appears as though the counters in the Tx demo are incrementing as expected, each series is separated by a number which increments as it gets above 255?

A simple CSV format would have been nice :)

I found some clues in this python script of how that packet needs to look, back in business:

https://github.com/emoncms/raspberrypi/blob/master/rfm2pigateway.py

OK, trying to set the time, using the python script as an example:

sp.write("10,00,22,00,s");

For some reason in the HomeEnergyMonitor script running on the LCD:

https://github.com/openenergymonitor/EmonGLCD/blob/master/HomeEnergyMoni...

On line 123: RTC.adjust(DateTime(2012, 1, 1, rf12_data[1], rf12_data[2], rf12_data[3]));

The data being received looks like:

rf12_data[1]: 0

rf12_data[2]: 15

rf12_data[3]: 0

Any ideas where I am going wrong?  I am able to get the Rx_SimpleRFM12B_demo script to output the correct values if I do this, so I do believe I am sending data properly:

sp.write("1,0,2,0,3,0,4,0,a");

OK I can get it to set the time on the LCD if I do the following:

Modify line 123: RTC.adjust(DateTime(2012, 1, 1, rf12_data[1], rf12_data[2], rf12_data[3]));

To: RTC.adjust(DateTime(2012, 1, 1, rf12_data[0], rf12_data[1], rf12_data[2]));

And then on the serial port write this: sp.write("06,21,00,s");

This will set the LCD to 6:21

This is progress, but I am sure that I am not doing this the right way, and it seems that when I do this the LCD cant receive any more commands after this one.  It does, however continue to report its temperature,  any help would be very appreciated.

I was trying to pass in a value to of 1353, and I was able to do it with:

sp.write("73,5,0,0,0,0,0,0,a\r");

It was received by Rx_SimpleRFM12B_demo as:

power1: 1353

power2: 0

power3: 0

power4: 0

Looks correct to me, so I am a little baffled here on why doing the same doesnt work with the LCD running the homeenergymonitor code.

Tested the LCD hardware running Rx_SimpleRFM12B_demo and the sketch receives the packets flawlessly.

I'm not sure, but there must be something different about the way the HomeEnergyMonitor processes the packet.  Is something like 1353 not in the acceptable range for power1 value?

Well, I have a working system now. 

https://plus.google.com/112693340411141805940/posts/BPVmjEyvfSy

Would still like to know more about setting time, it seems like the python code and the arduino code on the other end just dont jive.

For anyone who happens upon this thread in the future, and would like to get the RFM12Pi talking to their BBB.  It is important to note that by default  the UART ports are not enabled, this can be done manually but is a huge PIA.  Adafruit has a library that makes this real easy:

http://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-bla...

http://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-bla...

Once that is done you can then connect to /dev/ttyO1 // note that is a O, not a zero

I used nodejs, as it is preinstalled on the BBB and super easy to work with.  Here is some sample code:

var serialport = require("serialport");
var SerialPort = serialport.SerialPort; // localize object constructor

var sp = new SerialPort("/dev/ttyO1", {parser: serialport.parsers.readline("\n") });

sp.on("data", function (data) {
  console.log(data);
});

sp.on("open", function () {
  console.log("I am connected");
  sp.write("73,5,0,0,0,0,0,0,s");
  //sp.write("06,0,15,0,0,0,s");
});

Hi.

I just ran quickly through your messages. Thank you for your feedback.

Regarding the RF communication protocol, there is some information in the "networking" pages, in the "building blocks" section. Especially in Part 2. Reading the python code as you did is fine as well.

Now, concerning the emonGLCD time synchronization, it is quite likely that I introduced a bug in the python gateway, from which you took inspiration. This came out yesterday and it seems to be an easy fix, but before doing the modification, I'd like to take 5 minutes to understand. In the meantime, you may want to try the correction yourself. See here for the bug report and the potential fix. And there for Trystan's php implementation I assume correct.

I'm a bit surprised no one ever complained before yesterday, but perhaps no one uses both the python script along with an emonGLCD. I don't have any emonGLCD to test that myself, I just got the sending format from Martin's blog.

Sorry for the inconvenience...

(Note that if you don't intend to use the whole emoncms solution on your BeagleBoard, the standalone gateway might be an alternative.)

Hi Jerome,

I was able to get the time working by simply extending the tx object to include time.  Since my BBB is creating the object and sending it to the display, it was easy to append, and prevented the need of another device sending just the time.

In addition, I have the BBB calculating the total watts used for the day, and sending it in the packet the LCD receives, this means that all my displays always show the same data, even after they power off and come back to life.  So really the LCD is just a display that doesnt have much in the way of logic.

Seems to be working well for me, albeit I had to hack up the code a bit and roll my own, not sure if anyone else is interested in  doing something similar, if so I am happy to contribute the code I use.

Hello,

Following this thread I learn that the RFM12Pi module would ne capable to receive RF433 frames on a Beagle Bone Black..

So, I bought, and receive it few days later...  :-)

After updated my BBB under Ubuntu (13.10), I successfuly recompiled the drivers for this distribution (https://github.com/gkaindl/rfm12b-linux).

According this image : http://wiki.openenergymonitor.org/index.php?title=File:RFM12Pi_V2.6_brd.png and theses instructions (found on the above git), I connect my my module to my BBB

Beaglebone & Beaglebone Black

Beaglebone            RFM12B
---------------------------------
P9/1                  GND
P9/3                  VDD (+3.3V)
P9/27                 nIRQ
P9/29                 SDO
P9/30                 SDI
P9/31                 SCK
P9/42                 nSEL

Finally, I powered up my BBB, and load the module.

the dmesg content seems to be good :

[304488.785541] rfm12b: added RFM12(B) transceiver rfm12b.1.1
[304488.787064] rfm12b : driver loaded.
--> everything seems to be okay

in lsmod the module appears as
Module                  Size  Used by
rfm12b                 14897  0

a device is now present under /dev  : /dev/rfm12b.1.1

And now, I don't know where to go to get raw frames..

any help would be welcome

thank you

ps:

tech infos:

uname -a
Linux BeagleBoneBlack 3.8.13-bone32 #1 SMP Fri Dec 13 20:05:25 UTC 2013 armv7l armv7l armv7l GNU/Linux

hello,

I reply to myself.

It works!

more informations on my blog http://mymiscellaneoustricks.wordpress.com/

Pinout used :

after that, following the informations given by "ievolve" I activate the UART1 GPIO profil, then upgrade the sketch embeded in the RFM12pi.

After this upgrade, now I receive all RF raw frames visible to my RFM12Pi

Bien joué.

Thanks for sharing.

Thanks, great work. I've added your blog to the RFM12Pi wiki. Feel free to edit :-)

http://wiki.openenergymonitor.org/index.php?title=RFM12Pi_V2#Using_RFM12...

Hi!

Thank ya Glyn !

Now i'm trying to rebuild a customized firmware for rfm12pi.

I can rebuild/flash the RFM12pi with this sketch : https://github.com/mharizanov/RFM2Pi/blob/master/firmware/RF12_Demo_atme...

but not with this one:

https://github.com/mharizanov/RFM2Pi/blob/master/firmware/Full_RF12demo_atmega328/Full_RF12demo_atmega328.ino

The only way I found to build it, is to comment the line 7 (#include <WProgram.h>). After that I can update thsi firmware but, i can't modify RFM12Pi settings (got a "config save failed error").

is there a special arduino's version to use for the build ?

Hi. Sorry for off-topic-ing.

I compiled RF12_Demo_atmega328.ino (the one you used successfully) but it doesn't work when loaded. Apparently, there must be something I didn't do correctly.

Here is the thread I opened to ask about this: http://openenergymonitor.org/emon/node/3958, in case you'd have any idea of what I did wrong.

Thanks.

just back today.

I will answer you shortly

Thanks !