Using an R-Pi with a self-constructed RFM12Pi. Using the emoncmspiv5avr_19-05-13 image, I am able to see the web interface and the 'Raspberry Pi' page has banner "RFM12 to Pi interface script is up and running ". I'm able to SSH into the board and minicom runs on ttyAMA0 and I get "Current configuration: 79 i15 g1 @ 433 MHz Lock: 1"
However, I have yet to see any data on minicom, despite my two sensors working fine (as seen on their own receivers). So I suspect this is due to me not having set NodeID/BaseID or Network Group, so I am now stuck !
I have two sensor devices...
- Efergy 'energy monitor' which sends about every 4secs with AC power consumption data and
- I.T. works temperature sender KW9007B
I think they are both 433Mhz band, but I don't know which channel. Is there any way I can discover the NodeID/BaseID and Network Group they are using ?
I've searched high and low on the web without any luck, so I'm wondering if I need to create some sort of scanner to see if I can capture something?
Would be grateful for any pointers please ?
GB.
Re: How to find NodeID/Network Group for sensor node ?
OpenEnergyMonitor is only designed to work with it’s own transmitters. Your other devices are likely to be using a different frequency, baud rate, modulation method and data protocol. You may find some info from people who have hacked these devices but the protocols will be proprietary so you’re unlikely to find any official info.
This is why OpenEnergyMonitor is such a great project – everything is open source.
Re: How to find NodeID/Network Group for sensor node ?
You might find something over at JeeLabs.
(Just a note: as far as I'm aware, Efergy sensors only transmit current, and the display makes a guess at power and energy based on that. You can read up here in the Building Blocks section why that is inaccurate.)
Re: How to find NodeID/Network Group for sensor node ?
Google for "hack Efergy" There are many entries.
Re: How to find NodeID/Network Group for sensor node ?
Hi,
Thanks for the comments guys, but all the 'hack efergy' entries refer to grabbing the serial data straight from the device not using the radio side at all.
Appreciate that OEM is really for its own sensors, but there must be loads of perfectly good sensors out in the world that could be used on this excellent project without having to junk them and buy new. Also, decoding the proprietary data is no problem, I've spent a lifetime doing realtime coding !
One method of fonding the IDs that occurred to me is to borrow a storage scope or data analyser and capture the init sequence going into the RF module, but I don't have either of course !
Another would be to go through all the combinations, but life's too short for that sort of game :)
Any other suggestions would be most welcome ?
Cheers,
G.
Re: How to find NodeID/Network Group for sensor node ?
Hi G,
late reply, but only just joined forum!
The RFM12Pi v1 uses an attiny84 with a hoperf rfm12b radio. (I'm sure you knew this). It has firmware very similar to jeelabs rfm12demo.ino, just a little trimmed and a few xtras like 'lock'/'unlock' etc.
This radio in combination with the rfm12driver code, can only listen/process 1 channel/band at a time, So whilst it is listening for packets on say 210/433 it cannot collect data from 200/433 etc. Further it is designed to reject any data packets not using the jeelib envelope format. The current jeelib address scheme allows only for 31 nodes in each of these band/frequency slots. Any foreign data being rec'd in the group/freq you are listening to is omitted in the firmware. The underlying driver code can however be more flexible in that it can be told to listen for almost any data packets flying about on that frequency, but you must have a 'decoder' routine. The emoncms firmware for this little board does not have these decoders built in, so you need to roll your own, your only problem is the attiny84 is a little memory constrained, (and its uart support/accuracy can be temp dependent without a crystal), so the number of decoders you will be able to squeeze in is limited along with its reliability in fluctuating temp extreemes. The v2 board has more breathing room as it is based upon attiny's big brother.
On the subject of finding ID's etc, well this is actually protocol dependent, and whilst you can use a logic analyser etc to obtain this data you are still going to have to make it 'fit' the OEM receiver formats. One way is to have a dedicated uC with say another rfm12b or SAW etc, to listen to other protocols like DCF, OOK, FSH etc, and to 'relay' the info in a more specific OEM format, in other words your other uC acts as a foregin gateway/protocol decoder and forwarder. I have done this for a number of protocols that dont fit the normal pattern. Also some rfm12 variants are not good with OOK without modification.
Unfortunately there are lots of devices all with protocols of their own and people want to handle them in specific ways, hence you will have to do a little research. You could start by specifying what your other sensors are, and forum members may already have dealt with them, or have some code you could use/incorporate.
In short, the cleanest way seems to be to build cheap radio listeners from say a atmega328/84 etc, code up your foreign decoders and have then all 'forward' the data to emoncms pretending to be another OEM node. I myself use Nathan Chantrell's excellent tinytx PCB's (I ordered a few batches of v2 & v3 from china last year). They act as proxy devices in this respect. I'm sure there are lots of other ways, but your limiting factor is that a single rfm12b cannot be doing two things at the same time, not listening to two freq's nor sending AND receiving - you'll need more than 1 radio to crack this.
Hope that helps!