You can just run emonhub on it’e own without emoncms to interface to the RFM board.
@pb66 just uses node-red serial node to interface IIRC.
I’ve told you the frequency, but I would have thought that 80 kHz away you would have seen something. And note that the emonTx doesn’t flash its LED as it transmits, it flashes it immediately after it has completed the transmission. (This is to save current, as the power supply is strictly limited.)
1 Like
Stupid question: does the device get created/made to work by emonhub?
Am I missing a big point here? I.e. that the device /dev/AMA0 needs emonhub to exist/work at all? I’d assumed it was nearer the hardware layer than that.
Sorry - I interpreted “As far as I know, the frequency we use is 434 MHz” as something I needed to do further research on 
I have tried forcing the rtl_433 onto 434.0MHz and, indeed, still see nothing.
Cool. That’s a very sensible design decision.
The RFM board simply takes the RFM signal and sends received messages out via the serial interface.
emonhub is simply a python script to decode that serial data and send it onwards.
However, if the firmware is no longer stock (as delivered), determining the issue is more difficult to solve (and not my area of expertise).
BTW have you disabled bluetooth on the Pi?
1 Like
I have not! I am sure the ‘getting started’ instructions didn’t tell me to do so.
I did disable the serial console, though
$sudo rpi-serial-console status
Serial console on /dev/ttyAMA0 is disabled
Do I need to disable bluetooth also then?
I did write “434 MHz exactly”, i.e. 434.000000 MHz. It came from my stand-alone transmit code that was cribbed directly from JeeLib:
#else // default to 433 MHz band
writeReg(0x07, 0x6C); // RegFrfMsb: Frf = Rf Freq / 61.03515625 Hz = 0x6C8000 = 434.00 MHz as used JeeLib
writeReg(0x08, 0x80); // RegFrfMid
writeReg(0x09, 0x00); // RegFrfLsb
#endif
And I assume JeeLib has the multiplier constant right, as it is given in the RFM69CW data sheet as FOSC / 219, and FOSC is 32 MHz.
1 Like
HOLY COW. THAT WORKED. Disabled bluetooth. Bingo.
A thousand thanks.
Welcome to minicom 2.7
OPTIONS: I18n
Compiled on Apr 22 2017, 09:14:19.
Port /dev/ttyAMA0, 23:29:16
Press CTRL-A Z for help on special keys
OK 8 178 1 189 1 86 254 0 0 194 96 184 11 184 11 184 11 184 11 184 11 184 11 196 53 0 0 (-26)
OK 8 174 1 169 1 88 254 0 0 203 96 184 11 184 11 184 11 184 11 184 11 184 11 197 53 0 0 (-26)
OK 8 197 1 198 1 61 254 0 0 127 96 184 11 184 11 184 11 184 11 184 11 184 11 198 53 0 0 (-26)
OK 8 192 1 197 1 50 254 0 0 178 96 184 11 184 11 184 11 184 11 184 11 184 11 200 53 0 0 (-26)
1 Like
Yes as it is a shared UART.
Which instructions did you use?
1 Like
I’ve got that T-Shirt in the wardrobe.
https://wiki.openenergymonitor.org/index.php/RFM69Pi_V3 (doesn’t mention disabling bluetooth)
Thanks so much, again. I literally never would have thought of that.
@alexbloor, from what you have posted I think both the emonTx and the RFM2Pi were fine, providing you have flashed the right FW that should still be the case.
You can ignore the strace errors, that is just a quirk of the avrdude-rpi wrapper.
We do not know anything about your RPi image so an easy check would indeed be to download and install either a stack Raspbian image or a emonSD image for testing so we know what we have.
However there are 2 main differences between a stock raspbian image and the emonSD and we do not know if either of these have been altered in your image.
- is the serial console needs disabling BUT without disabling the GPIO serial port altogether.
- The GPIO and Bluetooth are remapped by an overlay so that the GPIO is using the better serial port (normally mapped to the bluetooth on a Pi3)
You can get around the mapping just by using /dev/serial0 instead of /dev/ttyAMA0 or /dev/ttyS0.
If you are confident about using the gpio pins directly, then a good test would be to wip off the rfm2pi and link the rx and tx pins of the gpio serial port together. Then when you use minicom, everything you send should be echoed back to you. This proves you are using the right address and minicom is working ok. Then remove the link and refit the rfm2pi, it should work providing the baud is 38400 and it is set to the right freq and group (the defaults are correct) which can be changed by using the instructions posted by Robert earlier.
[edit - I have just edited the formatting in Roberts post as it wasn’t displaying quite right, so hopefully it makes better sense now]
1 Like
Thanks to all who’ve responded.
It seems as though the Bluetooth not being disabled was the killer tip.
So now I know that it was something stupid I was doing (or, rather, had omitted to do). Oops.
Oddly, my puzzlement was worsened by my sincere attempt to ‘rule out’ things; using the rtl_433 software to try and receive it (and finding it also not working) convinced me that the emonTx wasn’t transmitting anything, at least for a time.
And that mystery does still remain. I’d be intellectually satisfying to suss out why, though, since I bought the RFM69Pi and it’s working now, I’m tempted to let it slide.
Once, again, thank you again to all who’ve kindly taken time to respond. Very happy to see it working!
@pb66
It looks like this
https://wiki.openenergymonitor.org/index.php/RFM69Pi_V3
is lacking.
I’ve flagged it to Gwil.
2 Likes
Possibly, but that isn’t a characteristic or requirement of the rfm2pi’s, that is just a decision made for the emonSD/Pi etc.
The reason for the problem is that you are addressiing the bluetooth module on a Pi3 when you use “ttyAMA0”. If you use “ttyS0” on a Pi 3 and “ttyAMA0” on any other pi there is no real issue other than the BT is utilising the better serial port(on a Pi 3).
This is why the serial0 and serial1 addresses were introduced, they always address the same hardware, serial0 is always the gpio serial port, regardless of whether it is mapped to the better(ttyAMA0) or the lesser (ttyS0) serial ports.
Disconnecting the bluetooth is actually NOT needed, in fact many emonSD used reconnect it to use the bluetooth for the sunnyboy inverter interfacer in emonhub. To be accurate, the ports need SWAPPING only if you want to use the better serail port for the gpio, as long as you use the right address, which IS NOT /dev/ttyAMA0 unless you do go to the trouble of swapping.
[edit] here’s a better explanation Raspberry Pi Documentation - Configuration, when you “disable bluetooth” what you actually do is move the better serial port (ttyAMA0) to the gpio(serial0).
pi3-disable-btdisables the Bluetooth device and restores UART0/ttyAMA0 to GPIOs 14 and 15. It is also necessary to disable the system service that initialises the modem so it doesn’t use the UART:sudo systemctl disable hciuart.
effectively making it like any other non-Pi3 model Pi, but you could just go direct by using “serial0” which keeps the BT working (or use pi3-miniuart-bt overlay to swap them).
PS when I have made references to the Pi 3 above, it also applies to the Pi Zero WiFi too.
2 Likes
It is interesting that OEM can talk to a sunnyboy with a BT board in it.
I have a SB1200. I’ve not looked into whether I can install a bluetooth module in it, but instead had planned to simply install a CT on the output of it. Certainly something to look into in future, perhaps.
It certainly won’t hurt to mention that there is a problem with BT. That Wiki page is all about using a RPi & RFM69Pi together, so something that needs changing to facilitate that should have a mention, a pointer to the instructions, or the instructions.
2 Likes
My head exploded at this point 
.
I agree with @Robert.Wall, that it would be really useful to update that Wiki page. My suggestion would be to simply point to that explanation you linked to and inform any user what to do. TBH I’m still not exactly clear what I’d actually need to do, especially if I wanted BT and emonhub.
I just knew that the UARTs were shared so turning off BT helped 
. The other info is really useful as if I’d understood I may well have continued the path I was on to rationalize 2 Pis one running BT presence and the other an RFM board.