Archived Forum

Remove the "console=ttyAMA0,115200 kgdboc=ttyAMA0,115200" from the cmdline.txt to free up the serial port for use with the RFM2Pi.

What's currently happening is the rfm2pi is outputting directly into a shell serial console, causing a lock up.

Paul

I did notice in the emonhub.conf file it did reference that serial port.

So tried that and the output to screen has gone and pi is responsive but no nodes detected and nothing in either log (and I mean nothing).  Checked the old emonhub.conf and the settings (group, node etc) are the same.

Brian

Should have done this before my last post :(

This response to a status is different to what I was used to in Wheezy. IIRC the way daemons are started is different in Jessie.  Is this the issue?

root@server-pi:/var/log# service emonhub status
● emonhub.service - LSB: Start/stop emonHub
   Loaded: loaded (/etc/init.d/emonhub)
   Active: active (exited) since Tue 2015-11-24 08:13:01 UTC; 12min ago
  Process: 251 ExecStart=/etc/init.d/emonhub start (code=exited, status=0/SUCCESS)

Nov 24 08:13:00 server-pi emonhub[251]: /etc/init.d/emonhub: 33: /etc/init.d/emonhub: sudo: not found
Nov 24 08:13:01 server-pi emonhub[251]: Starting OpenEnergyMonitor emonHub: emonhub has been started ok.
Nov 24 08:13:02 server-pi emonhub[251]: start-stop-daemon: unable to start /usr/share/emonhub/emonhub.py (Permission denied)
Nov 24 08:13:02 server-pi systemd[1]: Started LSB: Start/stop emonHub.


-rwxr-xr-x 1 root root 13439 Nov 23 22:08 emonhub.py

Ah, OK, I think I know roughly why this is happening but not how to fix it!  I had noticed the sudo command was not found and I had assumed it was because I am logged in as root (I modified the install script and removed the sudos).  The emonhub daemon trys to start as the user emonhub with sudo (which fails).

Which is better to run the daemon as root or try and fix the sudo problem (and if so how)?

Brian

Probably try and fix the sudo problem. Has all of your system been installed by 'root' or just emonhub?

If it's just emonhub you could probably remove it and then reinstall it normally. If you look at the install script you will be able to see how to remove it.

Paul

Hi Paul, thanks.  yes everything has been done as root.  the emonhub user was generated by your script I think.

So I modified the service/emonhub file so it runs as user root and removed all the sudo commands.  The daemon now starts happily (as you can see) but the emonhub.log has this;

root@server-pi:/var/log# service emonhub status
● emonhub.service - LSB: Start/stop emonHub
   Loaded: loaded (/etc/init.d/emonhub)
   Active: active (running) since Tue 2015-11-24 08:46:20 UTC; 30s ago
   CGroup: /system.slice/emonhub.service
           └─1727 python /usr/share/emonhub/emonhub.py --logfile /var/log/emonhub/emonhub.log --config-file /etc/emonhub/emonhu...

Nov 24 08:46:20 server-pi systemd[1]: Started LSB: Start/stop emonHub.
Nov 24 08:46:20 server-pi emonhub[1716]: Starting OpenEnergyMonitor emonHub: emonhub has been started ok.
Nov 24 08:46:40 server-pi systemd[1]: Started LSB: Start/stop emonHub.
root@server-pi:/var/log# cat /var/log/emonhub/emonhub.log
2015-11-24 08:46:23,339 INFO EmonHub Pre-Release Development Version (rc1.2)
2015-11-24 08:46:23,358 INFO Opening hub...
2015-11-24 08:46:27,379 WARNING Device communication error - check settings

Any suggestions on how to check this?

Brian

Ok so I have solved it.

I installed sudo (was as simple as apt-get install sudo) then added the emonhub user into the group (https://www.privateinternetaccess.com/forum/discussion/18063/debian-8-1-...).

I then tried to go back to the daemon that runs as emonhub but still got a permission denied when trying to run the python script.

Went back to the daemon running as root and it works fine.  Inputs appear in emoncms.

Not totally sure why except there must be something inherent inside the emonhub script than needs sudo access and adding in sudo fixed it.

Thanks for your help and I hope this helps others who are silly enough to try this <VBG>

Brian

If only that was the end of the story....

Moved the Pi to it's final location, restarted it and emonhub failed to start;

2015-11-24 09:48:48,086 WARNING Device communication error - check settings

On restarting the service it came up no bother.  I suspect that the service started too soon and I'll look into how to delay it, but could the emonhub retry a number of times rather than just stopping?  Not sure how to do it, but can it also tell the service handler it is not happy so automatic restart could occur?

Does it leave a trail somewhere that says it is still communicating?  I have used MONIT in the past but it needs something to look at (could be anything with a timestamp effectively).

Brian

Emonhub should automatically detect the baud rate, but it has been known to get it wrong!
Try hard coding your baud rate in your emonhub.conf file;

# This interfacer manages the RFM2Pi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 9600

...setting the baud rate accordingly - 57600 or 9600 depending upon your system.

Paul

or 38400

As Paul says the auto-detection of baud isn't 100%, there is a fix for this in testing and will make the next emonhub version. 

The removal of the sudo's in the init script look like they had actually fixed the permission issue prior to installing sudo, those 3 "sudo" entries are actually redundant as all init scripts are always run as root at start up and all services must be started as root (or sudo). That line got added to overcome a log permission issue with read-only installs and the use of "sudo" was probably habit and never cropped up as an issue since the sudo package is included with Raspbian and so they can be safely removed.

Paul

Thanks.  Any suggestions on which of the 3 speeds is best :)

It is a Raspberry Pi B+ (though it may go back to an A) and an old RFM12B board.  I'll try the middle speed (or is it possible to see what it settles to).

What difference does a higher speed make?

[edit] set it to 9600 and it still failed to start on boot.  A restart of the service worked immediately so I'm sure it is to do with when the service is being started.

Cheers.  Brian

The "best" speed will be the one that is defined in the RFM2Pi firmware, unfortunately you don't get a choice unless you change or edit the RFM2Pi firmware and the default was originally 9600, then very briefly 57600 and currently 38400. Only the correct baud will work and there is no easy way of 'knowing' the correct baud but if you have a rfm12b RFM2Pi then the odds are it's 9600 unless you have changed the firmware at some point.

This is the reason auto-baud detection was added so users didn't need to know the baud of their board. When emonhub succesfully starts the "correct baud" will be the last one tried if you observe the emonhub.log ("loglevel=DEBUG" set in emonhub.conf) as each is tried in turn until a legible response is received, you can determine the correct baud this way or trial and error setting each and restarting emonhub, only the correct baud will work.

The reason it "appears" to be a start up issue is because that is when the RFM2Pi interfacer is created and the "com_baud" setting is in "init_settings" which can only be changed with a restart of the interfacer in question, unlike the "runtimesettings" which can be altered on the fly at anytime whilst running.

So when you alter the "com_baud" you either need to restart the emonhub service like you have been or you can force the RFM2Pi interfacer to rebuild by placing a "#" before "Type = EmonHubJeeInterfacer" at the same time when editting the com_baud setting and save the conf file and then remove the "#" and save again, this will have deleted the RFM2Pi instance on the 1st save and created a new one on the 2nd save as an interfacer cannot exist without a Type. in most cases it is just easier to restart the service to pick up the changes but it is the interfacer creation not emonhub starting that struggles with the wrong baud.

Paul  

Hi Paul,

Thanks.  Well I just tried rebooting it again and this time it just worked.  I think I'll need to keep an eye on it.

Thanks for your help.  Brian