Archived Forum

Additional info - watching log, I got interesting info. By each reading data from RFM12, there is log record :

Reading discard, no numerical values

But checking jeelink output, there are correct int values, separated by spacec. baudrate is also correctly set to 9600.

Strange...

Can you post a bit of the log so we can see the frames? I believe the log message says "non-numerical content" which is the message given if any of the values in the frame fail the test to confirm only numbers are passed to the decoder.

Paul

Here we are, three rows from  log:

2014-08-16 19:28:21,663 WARNING 140 Discarded RX frame 'non-numerical content' : ['20', '112', '9', '254', '255', '171', '253', '6', '0', '153', '0', '254', '255', '23', '254', '79', '247', '28', '253', '26', '12', '227', '3', '', '0']
2014-08-16 19:28:22,497 WARNING 141 Discarded RX frame 'non-numerical content' : ['18', '48', '1', '45', '1', '109', '0', '0', '0', '221', '0', '16', '38', '', '0']
2014-08-16 19:28:23,547 WARNING 142 Discarded RX frame 'non-numerical content' : ['20', '119', '9', '254', '255', '147', '253', '6', '0', '151', '0', '254', '255', '24', '254', '78', '247', '27', '253', '23', '12', '227', '3', '', '0']

I have two transmiting nodes (No.18 and 20), each one sending integer values (pairs of integers to be completed in emoncms as a one input value).

Radek

Hi Radek

it appears there is a value missing from each frame, the second from last on both nodes 18 and 20 . is that an error or is that value permanently omitted? the frames are space separated so a double space could also be interpreted as a missing value.

node 20 has 25 values (including the missing one, which is a nodeid plus 12 integers. and node 18 is 15 values (including the missing one) correct for node id plus 7 integers. so I would guess your sketches are each passing one empty value.

If you change the loglevel to debug in emonhub.conf you may see more detail about the frames received. 

Am I understanding correctly? from your explanation are your final values are longs constructed from 2 integers, if these are in the correct order you could use a datacode of L (usigned) or l (signed) to reconstruct the values in emonhub and send to emoncms as real numbers if you wanted. It would mean changing your input processes but you could still use the existing feeds.

Paul

You are right, Paul. There was unused tail in each dataframe (there was RSSI value in original skecth of boredman not used by me). So I cut off this unused tail and now dataframes arent discarded. But input values are still not coming into emoncms.

I changed loglevel in emonhub.conf to debug, but I dont know where I can see those more details.

Yes, you are right, node 20 has nodeid plus 12 integers, node 18 nodeid plus 7 integers.

What should I do now to get my data in any form into localhost emoncms? (I have enabled local emoncms already and I can login with no problem)

Radek

If you have changed the loglevel to debug emonhub should be quite verbose and give you loads of info you can either open the logfile to view using a text editor

nano /var/log/emonhub/emonhub.log

or print to screen 

cat /var/log/emonhub/emonhub.log

or if you prefer to watch the log as it's running use

tail -f /var/log/emonhub/emonhub.log

You can track each frame through its processing by its packet id, that is the number after the loglevel in the log message, for example your log excerpt above is of frames 140, 141 and 142.

The last input process is when emonhub appends the frame to each reporters buffer. After that the reporters independently send the buffer contents where and how that reporter is set up. All its attempts and fails should be logged if they are not the reporter hasn't initialized correctly and you will need to either look way back in the logs to when emonhub tried to create that reporter, probably at start up or maybe easier to just restart emonhub and watch the tail.

sudo service emonhub restart

tail -f /var/log/emonhub/emonhub.log

Paul

When I open log file, there is just a few warnings regarding starting frames (header of RFM12demo), but not more warnings or debug infos. After some running time there start warnings, that limit of emoncms inmemory buffer 1000 items is reached and oldest item is deleted. But no debug info you mentioned above. Could you check, please, my emonhub.conf file (attached), whether is there everything correct?

Radek

The emonhub.conf looks ok. But if you are still only seeing WARNING messages in the log and not getting data in emoncms, that would suggest the conf is not being read so log level remains WARNING and the apikey is not being seen.

Can you confirm where you are editing the settings. emonhubs default location is 

/etc/emonhub/emonhub.conf

but I believe Trystan has moved the location to the boot partition of the sd card in the latest image so it maybe

/boot/emonhub.conf

Paul

I thought this maybe helpful once you can see the log messages, it's an example logfile with notes.

My emonhub.conf file, I modified is located  here:

/home/pi/emonhub/conf

At location /etc/emonhub/emonhub.conf is just shorcut link redirecting to location above

BUT

There is another copy of emonhub.conf file at /boot/emonhub.conf, where just a part of modification I made to that file at

/home/pi/emonhub/conf

So, which one of them is that RIGHT one?

I tried to modify that file located in /boot directory. But owner ot this folder is root and it is read only for others. I dont know root password of that precompiled image. Any idea how to get this file writable for pi user? Sorry for probably sily question, but Im still very beginner with Linux.

If you are using the latest image I would expect the /boot/emonhub.conf to work but I do not know how that's implemented.

Changing that symlink you found to point to the boot partition copy rather than the homedir copy would have been my 1st guess but going by your last comment I guess that's not the case.

Try changing the loglevel in that copy and see if it effects the log entries. If it does then that is the copy being used.

Paul

Sorry writing together :-)

Have you tried 

sudo nano /boot/emonhub.conf

YES ! I just put correct API key in /boot/emonhub.conf file and inputs in emoncms are live ! Nothing else changed, just URL and API key in /boot/emonhub.conf and it works! Now Im going to play with datacodes formats to see, how it works. But connection Nodes - Emonhub (with Jeelink at RPI USB port instead of RFM12PI ar GPIO) - Emoncms is working now.

My BIG THANKS for you excelent, patient support, Paul !

Radek

No worries, glad you are up and running.

Can I suggest you change that symlink to point at the correct version because if you update emonhub at some point using a git pull emonhub may revert back to its original form and look in /etc for it's config file. If you run

sudo rm /etc/emonhub/emonhub.conf
sudo ln -s /boot/emonhub.conf /etc/emonhub/emonhub.conf

you will be able to access /boot/emonhub.conf via /etc/emonhub/emonhub.conf and therefore if emonhub gets updated it shouldn't break because it can't find the conf file.

Paul

Good idea, Paul. I did it. I have to learn your "magic" sudo..... commands. :-) Could you recommend me some good online source of this know-how?

Thanks

Radek

Unfortunately I don't know of a particularly good single point to reference I tend to "google" a lot. you could start with a unix/linux shell tutorial. 

"sudo" is just a sort of "run as administrator" type prefix to run the following command with elevated root super user privileges.

I'm still a novice myself.

Paul

Something has happened, Paul. After more than 12 hours of smooth operation, communication Emonhub to Emoncms was suddenly interrupt (I didnt change anything at that time). RPI is still working, but it stopped sending data to emoncms. When I checked logfile, there is something, I dont understand - long list of the same messages:

1970-01-01 01:00:05,523 WARNING Send failure: wanted 'ok' but got
1970-01-01 01:00:05,641 WARNING Couldn't send to server, URLError: [Errno -2] Name or service not known
1970-01-01 01:00:05,644 WARNING Send failure: wanted 'ok' but got
1970-01-01 01:00:05,760 WARNING Couldn't send to server, URLError: [Errno -2] Name or service not known
1970-01-01 01:00:05,763 WARNING Send failure: wanted 'ok' but got
1970-01-01 01:00:05,880 WARNING Couldn't send to server, URLError: [Errno -2] Name or service not known
1970-01-01 01:00:05,882 WARNING Send failure: wanted 'ok' but got
1970-01-01 01:00:05,999 WARNING Couldn't send to server, URLError: [Errno -2] Name or service not known

Do you have any idea, what caused this communication interrupt?

Radek

Hi Radek,

Are you able to see what log messages were produced before the error?

Looking at the time it looks like it errored 1 hour previous (1970-01-01 12:00:00) did anything happen then?

What was the target emoncms.org or local?

The error messages clearly indicates a problem  getting a response from the target, it expected 'ok' but got no response and an exception was raised. ordinarily I would suspect emoncms if the settings were correctly set in emonhub.conf.But the incorrect log dates throw doubt on the validity of the messages.

If you have any useful data in the log copy it to another location as the log files are lost when rebooted on a RO SD image.

Paul

Also can you type "date" at the command prompt to check the current time/date.

Paul

I haven't previous "OK" logs. But strange is, current date is set to Jan 1st, 1970. (answer to "date" command).

Should I reinstall SD image?

Ok has the Pi been rebooted at all, that is has the incorrect date survived a reboot or are you still running since last night without rebooting?

What do you get if you run this ?

cat fake-hwclock.data

Paul

It is after fresh sudo reboot a few minutes ago. When I run your command, answer is : Nos such a file or directory.

oops! I meant 

cat /etc/fake-hwclock.data

does that return anything?

Yes, it returns 1970-01-01 00:17:01

Ok that is odd! it is supposed to get updated automatically but it can't because of being in RO mode, so I would of guessed it to have been just old data, not be 1970 as if file is RO how can it be changed to 1970 ? When it can't use fake-hwclock it is totally dependent on the network connection, is this Pi permanently connected to network? 

We could just try bringing it up to date and see if it happens again try running

sudo sh -c "echo '2014-08-19 18:15:00' > /etc/fake-hwclock.data"

sudo ntpd

I think it's every hour the file gets updated so leave it in RW mode for an hour or so and whilst in RW mode you could make sure you are fully updated as there have been a fair few updates to the lastest raspbian image.

sudo apt-get update

sudo apt-get upgrade

Paul

I tried those update/upgrade commands and it is rejected with "No space left on the device" message. There is 8 GB SD used.

Ok you need to resize your root partition, although the card is 8gb you are only using a portion of it if you type

df -h

you can see the sizes, the root filesystem is shown twice though once as a filesystem and again as a partition, probably near the top and around 2.6Gb i'd guess. It will be easy to spot as use% will be 100% or there abouts.

There are loads of guides on the internet on this subject and this thread should help you http://openenergymonitor.org/emon/node/3889 most of these guides are directed at a hdd but the actions are the same, the reason for that is normally resizing the sd card partition can be done using "sudo raspi-config" but a hdd cannot, however we cannot use "raspi-config" to resize this sd card image because of the 3rd partition, "raspi-config" won't know what to do so it will do nothing.

My personal advise on this is to only have partitions as big as you need now as you can always increase the size later. This is to make it easier to back-up your image. A 4gb image simply takes half as much time and half as much space as 8gb. It is also easier to increment to the needs of each partition rather than having to decide the final partition sizes now.

Paul

You found it! There was 100% usage of 2,6 GB space. I tried to increase this space, but I lost myself in that process. So I gave it up a reinstalled SD image. And it worked immediately. Next week I will try that filesystem size management once more, but for this time its important for me, I'm up again. Thanks Paul for you patient support!

Radek