/var/log filled up in emonSD-03May16

Ian, got to say I’m impressed with the way you’ve presented your support request, providing loads of information to enable this issue to be resolved.
…wishing others would/could do the same!

Hopefully, Jon’s post will help.


@Paul - I have an emonPi and I can click in an Update Now button on the Administration page. How does the emonbase Pi (or any other Pi device) do an update?

@Jon - thanks for confirming I was on the right track. Currently running the update - after I worked out how to do the update, as this is the first time i’ve updated from the web interface ! I was on a back level version for a long time (“ain’t broke don’t fix it”) until I updated to the new May 3rd image, so am still getting up to speed on the auto-update features.

@Paul - thanks - I guess that’s 30 years working in IT showing through :wink:

@Jon Since I upgraded from the back level code to the current emonSD, I understand I am now running the same image on my RPi /emonbase as is used on the emonPi, so I also have “update” button in the Admin section of local emoncms. I’ve just run the update, now rebooting as requested in the output from update process. root crontab was already looking better :wink:

The updates are normally done by git ‘pulling’ any changes from the emoncms repo into the local installation.
Simply SSH into the pi, navigate to the emoncms directory, and issue the command ‘git pull’.
You also have the flexibility to ‘pull’ different branches to test new features, or roll back to known stable versions.
But… it’s not for everyone, Git is a bit of a beast, and like learning a foreign language!


Ho Hum. Feeds not appearing at emoncms.org. emonhub.log shows it’s sending data and getting OK acknowledgment, and correct API key still in emohub.conf. :frowning:

I had that also! Look in the emonhub config near the bottom. The is an [[11]] that needs two line feeds before it!

@Jon Thanks Job - updated and rebooting now…

Doesn’t seem to have fixed it. Checked emonhub.log, no error about config file, although an odd warning which seems to relate to the RFM2Pi module, but I don’t think that is a problem as log says it’s sending data to emoncms.org:

cat emonhub.log
2016-05-24 23:10:30,254 INFO MainThread EmonHub emonHub ‘emon-pi’ variant v1.1
2016-05-24 23:10:30,257 INFO MainThread Opening hub…
2016-05-24 23:10:30,354 INFO MainThread Logging level set to DEBUG
2016-05-24 23:10:30,357 INFO MainThread Creating EmonHubJeeInterfacer ‘RFM2Pi’
2016-05-24 23:10:30,433 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2016-05-24 23:10:32,439 WARNING MainThread Device communication error - check settings
2016-05-24 23:10:32,442 INFO MainThread Setting RFM2Pi frequency: 433 (4b)
2016-05-24 23:10:33,446 INFO MainThread Setting RFM2Pi group: 210 (210g)
2016-05-24 23:10:34,450 INFO MainThread Setting RFM2Pi quiet: 0 (0q)
2016-05-24 23:10:35,454 INFO MainThread Setting RFM2Pi baseid: 5 (5i)
2016-05-24 23:10:36,458 INFO MainThread Setting RFM2Pi calibration: 230V (1p)
2016-05-24 23:10:37,462 DEBUG MainThread Setting RFM2Pi subchannels: [‘ToRFM12’]
2016-05-24 23:10:37,466 DEBUG MainThread Interfacer: Subscribed to channel’ : ToRFM12
2016-05-24 23:10:37,468 DEBUG MainThread Setting RFM2Pi pubchannels: [‘ToEmonCMS’]
2016-05-24 23:10:37,502 DEBUG MainThread Interfacer: Subscribed to channel’ : ToRFM12
2016-05-24 23:10:37,561 INFO MainThread Creating EmonHubMqttInterfacer ‘MQTT’
2016-05-24 23:10:37,565 INFO MainThread MQTT Init mqtt_host= mqtt_port=1883 mqtt_user=emonpi
2016-05-24 23:10:37,648 DEBUG MainThread MQTT Subscribed to channel’ : ToEmonCMS
2016-05-24 23:10:37,717 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer ‘emoncmsorg’
2016-05-24 23:10:37,754 DEBUG MainThread emoncmsorg Subscribed to channel’ : ToEmonCMS
2016-05-24 23:10:37,822 INFO MQTT Connecting to MQTT Server
2016-05-24 23:10:37,964 INFO MQTT connection status: Connection successful
2016-05-24 23:10:37,968 DEBUG MQTT CONACK => Return code: 0
2016-05-24 23:10:38,222 INFO MQTT on_subscribe
2016-05-24 23:10:47,776 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1464131447
2016-05-24 23:10:48,951 DEBUG emoncmsorg acknowledged receipt with ‘ok’ from https://emoncms.org
2016-05-24 23:10:57,824 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[]&sentat=1464131457
2016-05-24 23:10:58,758 DEBUG emoncmsorg acknowledged receipt with ‘ok’ from https://emoncms.org

time to bring in the big guns! I am out of my skill level!

It’s late and I need to go to bed, but any other suggestions will be appreciated.

I have searched the forums, and found Some feeds not updating after upgrading 8.4.0 -> 9.6.0 which mentioned time zone setting, which I have never changed, and was still at UTC, but have changed to Europe/London on local emoncms and emoncms.org, but not made any difference. emonhub.log still shows ‘ok’ acknowledgement from emoncms.org, api key matches what is in emoncms.org, but Inputs not updating.

Thanks for your help tonight guys.

there are two timezone settings. One is a command line. The other one is in Setup > My Account > My Profile:

Maybe this one needs to be set?!?

Hi Ian, What model RFM2Pi are you using and what baud is it running at?

You are right in thinking this appears odd because of the emoncms log entries, otherwise the log simply shows emonhub tries to create an RFM2Pi interfacer with a baud of 38400 and then advises to check the settings for your device as it cannot communicate with it.

so try changing the baud in emonhub.conf if you suspect it could be different (ie 9800 or 57600) otherwise look for a connection / seating issue.

Although it does also show some (attempted) posts to emoncms, the payload is empty “data=[]” and therefore misleading, which is then acknowledged by emoncms.org as successfully received, which although arguably accurate it is again misleading as it did successfully receive no data!

@pb66 Hi Paul, Thanks for your help. I had noticed that emonhub.log did not have the details of packets being processed like it used to, and I incorrectly assumed this was due to a change in logging levels as a result of the update.

As I lay in bed trying to go to sleep last night I reconsidered this, and the warning message about connection to RFM2pi, and wondered if that was the problem. This morning a quick check showed the red led was on solid on the rfm69cw module.

I did a shutdown halt, and powered off the Pi, and after it restarted, it’s all working again. I didn’t change any of the settings in emonhub.conf.

I need to dash to work now, but will be happy to provide any further information later


Hi @IanDavies, sorry to hear you’re having trouble. Agree, thanks for your excellent support request with plenty of info to work with. Also thanks a lot to @Jon and @Paul.

If a user is running a pre-built image (emonSD-03May16) then updata via the web interface should be used rather than git pull since the web interface update does more that just git pull e.g. update db, fix logrotate issue, fix emonhub nodes issue, fix service runner user permission issue etc. The web interface update will work the same on both emonPi and em on Basel (RFM69Pi + Raspberry Pi).

This emonhub conf spacing issue should now be fixed with the latest update.

A solid red light indicates the the RFM12Pi unit has crashed. A power cycle should fix it. This is the reason why the emonhub log does not show any received packets. Do you have a newer RFM69Pi or an older RFM12Pi? . This is an ongoing issue, that only seems to affect some users:

Hi @glyn.hudson I have an RFM69CW (bought from the OEM shop about a year ago) connected to an existing RPi.

Do you mean RFM69Pi? The RFM69CW is the name of the RF module, the RFM69Pi is the name of the whole unit:

Did a power cycle fix the hanging issue?

Apologies, I do mean rfm69pi - it is the whole unit, supplied from the shop, and yes the power cycle fixed it

If the rfm2pi led stays on that must mean the avr of the rfm2pi has stopped rather than the rfm module just losing it’s settings so please post again if it reoccurs as it is not the same issue mentioned above.

For that issue there are no reports of the led staying on and a simple change of setting resumes the data without a reset, that is unlikely to be possible if the avr is non-functional

Thanks Paul, i’ll look out for that and post if it happens again. As this solid LED condition only happened after a reboot, and I don’t usually reboot very often, I hope it won’t happen again.

However I used to get problems that were similar to the issue where traffic just stopped whilst the Pi was active, and I had been following the thread on the old forum, but as I was on and older emonSD from 2015 I was waiting until I upgraded to test the scripts for detecting when traffic stopped and automatically nudge the rfm2pi back into life.

I’ve had enough fun this week with /var/log filling up (solved) and lwrfd not starting (not yet solved) that I haven’t had chance to re-read that thread and test scripts! Hopefully will do soon.