Archived Forum

Hi Jan,

When did you purchase RFM2Pi ? If recently do you know if it is an RFM12 or RFM69 based board ?

I think if you can see a "larger" metal crystal can on the small RF sub-board (as seen here) it's an RFM12 or if not (as seen here) it's an RFM69. 

If it's an rfm69 and not an "extremely" recent build it may use a baud of 57600, easily tested for and accommodated by adding a line to the [[RFM2Pi]] [[[init_settings]]] in the emonhub.conf below the com_port setting

[[[init_settings]]]
        com_port = /dev/ttyAMA0​
        com_baud = 57600

You can find more on this on the "RFM12Pi with RFM69CW" thread.

Otherwise it maybe a permission or console issue which is unfamiliar territory for me on raspbmc but I did find this http://www.raspberrypi.org/forums/viewtopic.php?&t=33715 which seems to suggest moving the ttyAMA0.conf file or editing the files "start" line. 

Paul

Hi Paul,

Thanks for the fast response.

I have checked it and it is a RFM12.

Regarding http://www.raspberrypi.org/forums/viewtopic.php?&t=33715 : I have already checked this and updated ttyAMA0.conf.

FYI: I can "echo" things to /dev/ttyAMA0 without getting errors:

pi@raspbmc:~$ echo -en "\x02*pof\x03" > /dev/ttyAMA0
pi@raspbmc:~$ echo "^B**pof^C" > /dev/ttyAMA0
pi@raspbmc:~$ ls -l /dev/ttyAMA0
crw-rw---T 1 root dialout 204, 64 Jan  1 19:26 /dev/ttyAMA0
pi@raspbmc:~$ ps aux | grep ttyAMA0
pi        8581  0.0  0.1   1976   616 pts/0    S+   19:27   0:00 grep ttyAMA0
pi@raspbmc:~$

kr

Jan.

[Duplicate post deleted - Moderator (RW)]

This problem is solved now (output emonhub.log)

2015-01-01 19:44:12,494 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2015-01-01 19:44:12,509 DEBUG Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2015-01-01 19:44:14,518 DEBUG Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2015-01-01 19:44:16,525 ERROR Unable to create 'RFM2Pi' interfacer: Attempting to use a port that is not open
2015-01-01 16:03:40,428 INFO EmonHub Pre-Release Development Version (rc1.2)
2015-01-01 16:03:40,434 INFO Opening hub...
2015-01-01 16:03:40,436 INFO Logging level set to DEBUG
2015-01-01 16:03:40,438 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2015-01-01 16:03:40,445 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2015-01-01 16:03:40,449 INFO Setting emonCMS url: http://emoncms.org
2015-01-01 16:03:40,451 INFO Setting emonCMS apikey: set
2015-01-01 16:03:40,459 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2015-01-01 16:03:40,489 DEBUG Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2015-01-01 16:03:42,511 DEBUG Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2015-01-01 21:50:16,091 INFO RFM2Pi device firmware version & configuration: not available
2015-01-01 21:50:16,098 INFO Setting RFM2Pi frequency: 433 (4b)
2015-01-01 21:50:17,101 INFO Setting RFM2Pi group: 210 (210g)
2015-01-01 21:50:18,105 INFO Setting RFM2Pi quiet: 1 (1q)
2015-01-01 21:50:19,108 INFO Setting RFM2Pi baseid: 15 (15i)
2015-01-01 21:50:20,135 DEBUG RFM2Pi acknowledged command: > 4b
2015-01-01 21:50:21,760 DEBUG RFM2Pi acknowledged command: > 210g
2015-01-01 21:50:22,204 DEBUG RFM2Pi acknowledged command: > 1q
2015-01-01 21:50:22,418 DEBUG RFM2Pi acknowledged command: > 15i

I have no idea what I did to fix the problem.

Is it because I have installed https://github.com/lurch/rpi-serial-console and ran it once to enable the serial and once to disable the serial console:

sudo rpi-serial-console enable
sudo rpi-serial-console disable
 

Or was it because I did a hard shutdown (just pulled the power) instead of doing a "reboot".

FYI my /boot/cmdline.txt now looks like:

pi@raspbmc:/var/log/emonhub$ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootfstype=f2fs noatime quiet rootwait loglevel=1 sdhci-bcm2708.enable_llm=1 dwc_otg.microframe_schedule=1 dwc_otg.fiq_fix_enable=0 dwc_otg.fiq_split_enable=0
pi@raspbmc:/var/log/emonhub$

kr

Jan.

Glad you got it going, I wonder did you originally reboot the Pi for the initial changes to take effect ?

Paul

Hi Paul,  I certainly rebooted it originally using the "reboot" command.

kr
Jan.

I don't know why this happened to you and why it got solved, but for the record, and as a note to Paul, I had the same mysterious message the other night when I plugged my new RF69 (which was flashed with an old firmware).

At baud rate detection, in the for

com_baud in (38400, 9600):

loop, if both baud rate give no answer, the loop is exited with self._ser not None but closed.

Then

self._ser.write("v")

tries to write in a closed serial port.

In my case, the firmware was probably set to 57600. In I jvda's case, I don't know.

We may want to rework the baud rate detection, at least to yield a more explicit error message.

While we're at it, I'm not sure the continue statement is needed here, is it ?

And maybe replace

self._rx_buf = self._rx_buf + self._ser.readline()

by

self._rx_buf = self._ser.readline()

?

Maybe I'll find the time to submit something...

Hi Jérôme, Thanks for the pointers, I have opened a Rework serial port read() and auto-baud selection issue on emonHub's repo as this does indeed need some attention.

The baud selection does need to be more robust or at least more informative if an error occurs, I wasn't aware of the "loop is exited with self._ser not None but closed" status and the "continue" probably can be removed, I think it was accidently left when the "Display device firmware version and current settings" code was removed from the auto-baud code so it could be reached when a baud was manually set in the conf.

The "self._rx_buf = self._rx_buf + self._ser.readline()" was copied over from the existing read() code, as I thought it was to ensure the line read remained a string and couldn't be accidently cast if for example, a purely numeric value was read and assumed to be an int etc.

I have occasionally encountered this same issue, but when cold booting a Pi with the RFM2Pi v2 (rfm12) and I believed it maybe due to the extended "help text" printed at power up or the extra newline with no CR in the sketches setup().

Sorry about the 57600 baud, but I think it only effects a handful of us and was for the greater good to drop it as discussed in the "RFM12Pi with RFM69CW" thread.

Paul

Paul

> The "self._rx_buf = self._rx_buf + self._ser.readline()" was copied over from the existing read() code, as I thought it was to ensure the line read remained a string and couldn't be accidently cast if for example, a purely numeric value was read and assumed to be an int etc.

The only reason I did this was because the readline() method is used with timeout 0 to avoid blocking the execution, and it might get executed before the frame is received in its entirety. Therefore, the received frame is checked for "end of frame" and if incomplete, it is completed at next readline() execution.

I never thought about potential cast issues.

Apart from the read() method occurence, all occurences of self._rx_buf = self._rx_buf + self._ser.readline() are useless but harmful, although they can be misleading, for instance

    self._rx_buf = ""
    info = self._rx_buf + self._ser.readline()[:-2]

We can safely simplify this. (I can do it soon, don't bother.)

Apart from the read() method occurence, all occurences of self._rx_buf = self._rx_buf + self._ser.readline() are useless but harmful, although they can be misleading, for instance

Ideally, the "auto baud detection" and the "firmware and settings retrieval" code should use the existing read() method and just act on the results rather than reading the port directly.

Hmmm, good point. I was modifying the file step by step by small modifications first but I shall move back, stop and think. This is a nice way of improvement. I'll have that in mind.

Another point it may be worth keeping in mind with regard to the bigger picture is the need to implement threading to the intefacers.

This is needed to assist implementing subscription to mqtt topics, return multiple payloads from "one read event" using I²C and also sending (routing) data out from interfacers, including http requests eg interfacing with packetgen. Not only as this would be a lot of work for the main thread but also to prevent blocking.

The experimental branch has a working version of threaded interfacers and routed data to get the gist of the idea. So in the (not so distant) future it may be that the interfacers are threads looping a read_to_rx_queue() method unless interrupted to execute a send_from_tx_queue().

Additionally it has now occurred to me that the configuration commands may need to be considered as well. In the experimental branch there is a send() method used to write to the serial port by the "glcd time update", "rfm2piListenerRepeater" and "packetgen", it does not however currently handle the "jee configuration commands", the "auto baud detection" or determining the "firmware revision and current settings". This may lead to clashes over serial port access within emonHub possibly, although I haven't experienced this yet. 

I haven't look at the experimental branch yet, but indeed, if several threads are to send data over the serial port, they should send it first to a common buffer managed in a specific thread to prevent clashes.

Same error here: ERROR Unable to create 'RFM2Pi' interfacer: Attempting to use a port that is not open

Can I bypass the whole baud rate detection by specifying the baud rate explicitly with 'com_baud = 9600'?

I am asking because I am not using the RFM2Pi but my RS485 adapter which does not respond to any serial commands.

Jörg.

PS: or would it be possible to use the 'EmonHubSerialInterfacer' instead? And then com_baud has to be specified, too?

Hi Jörg.

The auto-baud detection is only on the "JeeInterfacer" for RFM devices as we can invoke a response to confirm a connection is successful or not. It can be over-ruled by setting 'com_baud = 9600' in the [[RFM2Pi]][[[init_settings]]], However the "JeeInterfacer" is just a "SerialInterfacer" heavy customised for the "Jee" family of devices so there is a lot of baggage and attempts to make settings that you just don't need.

I would recommend using a SerialInterfacer and if needed tune it to your needs. I'm sure you got it covered but if you search for terms like "emonhub serial direct" you'll find a couple of examples or just holla if you need any pointers :-)

Paul

Thank you very much for the info, Paul!

Then I will go with the SerialInterfacer. I have gone through the sources in the meantime and this is what I thought already. Just wanted to be sure because I gave one of my RS485 Pcbs to a friend and he had a lot of problems with it and the newest 'Low-Write' Emoncms version. Most of the problems came from typing errors (but which were based on documentation errors! There are examples with [runtimesettings] and [runtime_settings] and 'type' instead of 'Type'). Hope we get it fixed tomorrow. He is some 500km away, so it always takes some time between 'iterations' :-)) (and a lot of guessing what is happening there).

BR, Jörg.

PS: just found it again (the wrong documentation):

https://github.com/emoncms/emoncms/blob/bufferedwrite/docs/setup.md

"

Emonhub reporters config example for posting data to both the local buffered write installation and emoncms.org

[reporters] [[emonCMS_local]] type = EmonHubEmoncmsReporter [[[init_settings]]] [[[runtime_settings]]] url = http://localhost/emoncms apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [[emonCMS_remote]] type = EmonHubEmoncmsReporter [[[init_settings]]] [[[runtime_settings]]] url = http://emoncms.org apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

"

Is there somebody out there who could correct this, please? Just cost me and my friend a few hours of our precious time :-))))

Hi Jörg.

I've submitted a pull request for the corrections. not quite sure how they slipped though the net. They are very early references from the days of listeners and dispatchers.

It's alittle late now but for future ref Type Is CamelCase As Per The EmonHubInterfacerTypes, all_the init_settings have_underscores and runtimesettingsarelowercasenobreaks (indicating settings that can be changed 'withoutstopping').

I am around on and off tomorrow so post if you have any issues.

Paul

Hello,

I still could'nt figure out a way to solve this error.

Please help me

I am getting error:

ERROR Unable to create 'RFM2Pi' interfacer: Attempting to use a port that is not open

thank you

Rao

You will need to tell us more to be able to help you. 

Are you using Raspbian or raspmc? are you using a pre-built image, guide or self build?

Have you made the serial port available by editing cmdline.txt and inittab?

Which rfm2pi board are you using ? has it ever worked (ie has it stopped working or is this 1st install)?

Paul

I'm starting to get this message. I'm using Raspian with a self build and self install, recent. I added the RFM69PI and it didn't work at first, then ran the disable/enable serial port and it started to work. It worked until last night when it stopped with this message:

2016-01-31 23:59:11,891 INFO emonCMS sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1454302750.63,8,4,20,0,0,12530,3000,3000,3000,3000,3000,3000,1,0,-58]]&sentat=1454302751
2016-01-31 23:59:13,086 DEBUG SIGINT received.
2016-01-31 23:59:13,282 WARNING emonCMS couldn't send to server, Exception: Traceback (most recent call last):
  File "/home/pi/emonhub/src/emonhub_reporter.py", line 227, in _send_post
    response = urllib2.urlopen(request, timeout=60)
  File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 401, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 419, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 379, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1211, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
    r = h.getresponse(buffering=True)

  File "/usr/lib/python2.7/httplib.py", line 1034, in getresponse
    response.begin()
  File "/usr/lib/python2.7/httplib.py", line 407, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.7/httplib.py", line 365, in _read_status
    line = self.fp.readline()
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
error: [Errno 104] Connection reset by peer

2016-01-31 23:59:13,286 WARNING emonCMS send failure: wanted 'ok' but got ''
2016-01-31 23:59:13,319 INFO Exiting hub...
2016-01-31 23:59:13,321 DEBUG Closing serial port
2016-01-31 23:59:13,390 INFO emonCMS sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1454302750.63,8,4,20,0,0,12530,3000,3000,3000,3000,3000,3000,1,0,-58]]&sentat=1454302753
2016-01-31 23:59:13,433 WARNING emonCMS couldn't send to server, URLError: [Errno 97] Address family not supported by protocol
2016-01-31 23:59:13,436 WARNING emonCMS send failure: wanted 'ok' but got ''

2016-01-31 23:59:13,442 INFO Exit completed
2016-01-31 23:59:42,534 INFO EmonHub Pre-Release Development Version (rc1.2)
2016-01-31 23:59:42,592 INFO Opening hub...
2016-01-31 23:59:42,595 INFO Logging level set to DEBUG
2016-01-31 23:59:42,598 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2016-01-31 23:59:42,604 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2016-01-31 23:59:42,608 INFO Setting emonCMS url: http://localhost/emoncms
2016-01-31 23:59:42,611 INFO Setting emonCMS apikey: set
2016-01-31 23:59:42,616 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2016-01-31 23:59:42,621 DEBUG Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2016-01-31 23:59:44,630 DEBUG Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2016-01-31 23:59:46,636 ERROR Unable to create 'RFM2Pi' interfacer: Attempting to use a port that is not open

And then nothing from then on. I rebooted and same thing. rpi_serial_console status says ttyAMAo is disabled and it's set to do that in inittab and cmdline.txt

I added the line COM_BAUD=57600 and got a slight different message: ( I also tried 38400 and got the same message)

...

2016-02-01 09:57:07,650 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2016-02-01 09:57:07,655 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2016-02-01 09:57:07,660 INFO Setting emonCMS url: http://localhost/emoncms
2016-02-01 09:57:07,662 INFO Setting emonCMS apikey: set
2016-02-01 09:57:07,665 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2016-02-01 09:57:07,670 DEBUG Opening serial port: /dev/ttyAMA0 @ 57600 bits/s
2016-02-01 09:57:09,676 WARNING Device communication error - check settings
2016-02-01 09:57:09,683 INFO Setting RFM2Pi frequency: 433 (4b)
2016-02-01 09:57:10,687 INFO Setting RFM2Pi group: 210 (210g)
2016-02-01 09:57:11,691 INFO Setting RFM2Pi quiet: 1 (1q)
2016-02-01 09:57:12,696 INFO Setting RFM2Pi baseid: 15 (15i)
2016-02-01 09:57:13,700 DEBUG Setting RFM2Pi interval: 300
2016-02-01 09:57:13,717 DEBUG RFM2Pi broadcasting time: 09:57

I don't know why it would be working and then suddenly stop. 

Any ideas?

I cannot figure out the order of events from the logs since the second item in the log is 

2016-01-31 23:59:13,086 DEBUG SIGINT received

which is a "ctrl-C" issued from the command line which is odd as emonhub should be running as a service not from the command-line. The next lines seem to suggest emoncms is not responding, but that could be due to some sort of shutdown being issued???

However the first line of the logs included show a packet recieved into emonhub 1s before the attempt to pass it to emoncms which would suggest at the time the SIGINT was issued all was ok.

Is there any log from prior to this? it's difficult to establish the root cause since the log seems to start at the response to those events.

Did you update anything? change anything? why was the SIGINT issued? could it be that you have more than one instance running somehow?

What baud is your rfm2pi? setting 9600, 38400 or 57600 is to match the device only one will work and emonhub has no control over which, it just needs to use the correct one for your device.

What happens if you just restart emonhub without rebooting the pi using " sudo service emonhub restart "

Paul

Here's the log prior to the DEBUG SIGINT:

2016-01-31 23:59:10,627 DEBUG 8393 NEW FRAME : 1454302750.63 OK 8 4 0 20 0 0 0 0 0 242 48 184 11 184 11 184 11 184 11 184 11 184 11 1 0 0 0 (-58)
2016-01-31 23:59:10,645 DEBUG 8393 Timestamp : 1454302750.63
2016-01-31 23:59:10,647 DEBUG 8393      Node : 8
2016-01-31 23:59:10,657 DEBUG 8393    Values : [4, 20, 0, 0, 12530, 3000, 3000, 3000, 3000, 3000, 3000, 1, 0]
2016-01-31 23:59:10,665 DEBUG 8393      RSSI : -58
2016-01-31 23:59:10,757 DEBUG 8393 Append to 'emonCMS' buffer => time: 1454302750.63, data: [8, 4, 20, 0, 0, 12530, 3000, 3000, 3000, 3000, 3000, 3000, 1, 0, -58], ref: 8393
2016-01-31 23:59:10,861 INFO emonCMS sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1454302750.63,8,4,20,0,0,12530,3000,3000,3000,3000,3000,3000,1,0,-58]]&sentat=1454302750
2016-01-31 23:59:11,769 WARNING emonCMS couldn't send to server, HTTPException
2016-01-31 23:59:11,779 WARNING emonCMS send failure: wanted 'ok' but got ''
2016-01-31 23:59:11,891 INFO emonCMS sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1454302750.63,8,4,20,0,0,12530,3000,3000,3000,3000,3000,3000,1,0,-58]]&sentat=1454302751
2016-01-31 23:59:13,086 DEBUG SIGINT received
2016-01-31 23:59:13,282 WARNING emonCMS couldn't send to server, Exception: Traceback (most recent call last):

The Raspberry is rebooted at midnight daily. It's been doing running emonyx for several days and the Raspberry is going through the shutdown cycle so not sure if that's causing the issue. Why it doesn't restart upon reboot I don't know. I have not done a power reset, just a "reboot' command.

I have not done any updates or changes since I installed the RFM69PI board. It's been running fine for several days and going through the reboot cycle. I was letting it run standalone for a few days prior to installing the emontx. 

When this started I did not have a COM_BAUD line in the config file. I've tried setting it with all three values with the same result. The RFM69PI is a brand new board so it should be using the latest, but I don't know what it is.

When I comment out the COM_BAUD line, it seems to be trying 38400 and 9600, both fail and I get no connection. When I specify 57600 (or any value) I get this:

2016-02-01 19:32:07,759 DEBUG Opening serial port: /dev/ttyAMA0 @ 57600 bits/s
2016-02-01 19:32:09,765 WARNING Device communication error - check settings

I've restarted emonhub service several times when dealing with the baud issue. 

Thanks

if it's a recent rfm69pi the baud will be 38400 so setting " com_baud = 38400 " in [[RFM2Pi]] [[[init_settings]]] in emonhub.conf will remove that possible issue, note "com_baud" is all lowercase, I haven't tried all uppercase so cannot say if it will or won't work but it is not intended to be written that way so could get broken in future development.

Personally, I do not like the idea of rebooting at midnight, the most stressful time and the most likely time to experience an issue is at boot time. There should be no reason to do it and I can only see it causing problems and at a time when you are least likely to notice for several hours.

The http posting errors will be where emoncms is still trying to find it's legs following the reboot.

can you post the content of /boot/cmdline.txt and confirm if you are using wheezy or jessie?

Can you also confirm you have not installed emoncms's retired raspberrypi module?

Paul

I have com_baud in lower case. And I tried 38400 and got this: This is the entire log from when I restarted emonhub:

2016-02-01 20:22:06,403 DEBUG Closing serial port
2016-02-01 20:22:06,405 INFO Deleting interfacer 'RFM2Pi'
2016-02-01 20:22:06,408 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2016-02-01 20:22:06,413 DEBUG Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2016-02-01 20:22:08,418 WARNING Device communication error - check settings
2016-02-01 20:22:08,422 INFO Setting RFM2Pi frequency: 433 (4b)
2016-02-01 20:22:09,425 INFO Setting RFM2Pi group: 210 (210g)
2016-02-01 20:22:10,429 INFO Setting RFM2Pi quiet: 1 (1q)
2016-02-01 20:22:11,433 INFO Setting RFM2Pi baseid: 15 (15i)
2016-02-01 20:22:12,440 DEBUG Setting RFM2Pi interval: 300
2016-02-01 20:22:12,444 DEBUG RFM2Pi broadcasting time: 20:22
2016-02-01 20:22:12,498 DEBUG SIGINT received.
2016-02-01 20:22:12,501 INFO Exiting hub...
2016-02-01 20:22:12,503 DEBUG Closing serial port
2016-02-01 20:22:12,571 INFO Exit completed
2016-02-01 20:22:15,327 INFO EmonHub Pre-Release Development Version (rc1.2)
2016-02-01 20:22:15,329 INFO Opening hub...
2016-02-01 20:22:15,333 INFO Logging level set to DEBUG
2016-02-01 20:22:15,335 INFO Creating EmonHubEmoncmsReporter 'emonCMS'

2016-02-01 20:22:15,341 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2016-02-01 20:22:15,346 INFO Setting emonCMS url: http://localhost/emoncms
2016-02-01 20:22:15,348 INFO Setting emonCMS apikey: set
2016-02-01 20:22:15,351 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2016-02-01 20:22:15,356 DEBUG Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2016-02-01 20:22:17,363 WARNING Device communication error - check settings
2016-02-01 20:22:17,366 INFO Setting RFM2Pi frequency: 433 (4b)
2016-02-01 20:22:18,369 INFO Setting RFM2Pi group: 210 (210g)
2016-02-01 20:22:19,373 INFO Setting RFM2Pi quiet: 1 (1q)
2016-02-01 20:22:20,378 INFO Setting RFM2Pi baseid: 15 (15i)
2016-02-01 20:22:21,381 DEBUG Setting RFM2Pi interval: 300
2016-02-01 20:22:21,399 DEBUG RFM2Pi broadcasting time: 20:22

cmdline.txt:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline rootwait rootdelay=5

And contents of /etc/os-release:

PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
NAME="Raspbian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"
ID=raspbian
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

How would I know which version of the Raspberry module I have loaded?

I got it working but not sure why it wasn't. I installed avrdude as mentioned in this post:

http://openenergymonitor.net/emon/node/10055?page=1 on 7/2/2015

When I restarted emonhub, it was working. Perhaps a power cycle might have worked.

What does the command "avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400" do?

Thanks for your help

That command is used to just "test the waters" before trying to upload a sketch, it just tries to communicate with the rfm2pi without actually doing anything. 

Just have to keep an eye on it and see what happens, especially around midnight :-)

Paul

Thanks, I stopped the nightly reboots. I started doing it because I was having trouble with the Ethernet. It would go catatonic and require a power cycle to fix. Not sure what the issue was but it appeared when I started using the Raspberry as an FTP server to save captured images (lots of them - 8 images every 15 seconds 24/7). I did a system upgrade and that fixed the Ethernet problem but I never stopped the reboot. Prior to that the system stayed up for over 1/2 a year.