Archived Forum

Hi Paul

Can you clarify the usage of Emonhub. Is it useable only if you have a rfm12pi module on the Raspberry Pi? I use a Pi as my local server but with data coming in on the network connection as I use a remote NanodeRF as the base station.

Regards

Ian

Yes, it's purely the gateway to enable the rfm12b module to talk to emoncms.

Paul

Thankyou Paul Reed and Paul Burnell for posting this. Thats brilliant, Il copy it into a blog post.

Thanks for posting the info about emonHub Paul, the scripts you've linked to need to be improved (and documented), they do the job but are a little rough around the edges. The dev-emonhub script was just a tool I knocked up to use during development of emonHub before it got debian packaged (hence the dev- prefix).

The install script does not yet tackle access to the serial port by disabling the serial console so the /boot/cmdline.txt and /etc/inittab will need editing if installed to a new image.

The last line in /etc/inittab should read (in particular the # should of been added)

# T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

​And the single line in /boot/cmdline.txt should read (changind mmcblk0p2 if required)

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

I intend to improve the install scripts (and the documentation) soon ('ish), especially as I don't think the debian packaging will be happening for a while now.

Thanks Trystan a blog post would be good.

Ian, Although currently the only interfacer used in emonHub is indeed primarily for the RFM2Pi, emonHub is actually able to accept other inputs, the socket interfacer just needs to be defined in the conf file to work. This functionality is carried over from OEMGateway and allows data from the LAN to come in via a websocket.

If you cast your mind back sometime to a discussion we had about your nanodeRF I started an issue on OEM gateway, which was carried over to emonHub. I also did some experimenting and found that "all" that is really needed was some form of authentication as it is already possible to do what you need with emonHub but not in a secure way. see https://github.com/emonhub/emonhub/issues/25.

I will take a look at implementing some sort of authentication ( hopefully sometime soon) as I think this would be very useful,

Paul
 

cmdline.txt & inittab changes now added to main post.

Paul

Hi,

As a starting point, I would like to use the ready-to-go SD card image described here that contains emonhub + emoncms (low write version).  Two questions :

1. I guess I have to update emonhub using the first procedure above. Correct ?

2. The issue described here is solved or not after updating emonhub ?

Thank's

Eric

Hi Eric

The scripts mentioned in this thread are for installing emonhub from scratch (one also removes a previous rfm2pi interface). Since emonhub is included in the ready to go image you wouldn't need either of these.

The "read-only time issue" in that discussion isn't specific to emonhub, it's to do with keeping time on the Raspbian OS when the file system is mounted as read-only. To avoid the issue you can install ntp-backup, which is the modification mentioned in that same thread,

You can run this command when in RW mode (rpi-rw) to install ntp-backup to the "read-only SD image"

    git clone https://github.com/emonhub/ntp-backup.git ~/ntp-backup && ~/ntp-backup/install

Paul

The scripts mentioned in this thread are for installing emonhub from scratch (one also removes a previous rfm2pi interface). Since emonhub is included in the ready to go image you wouldn't need either of these.

Ok but do I need to update emonhub if I want to use this image ? If yes, how ?

Eric

And which version(s) is/are the starting point on which to run the scripts? That's a vital piece of information that's missing.

Eric, the upgrade is to change from the old rfp2pi interface, not an upgrade from emonhub to a newer version of emonhub. You either have it or you don't as there is only one release version at this time. The image you are installing comes with emonhub pre installed, so there is no need to install it again.
Robert, I view emonhub as a completely separate piece of software from emoncms, and the only connection is that they talk to each other, the same way that the old rfm2pi interface did. So it doesn't matter what version of emoncms you use, as the communication protocol is common across as many versions of emoncms that I can recall.

Paul

Paul (Reed), I didn't mention emonCMS, like you I'm talking about the Raspberry Pi software. My point was that it's not clear where to start from. If it's the "new" version (that goes by two names!) that's recommended in OpenEnergyMonitor Guide then it wouldn't hurt to say so. And what about the two SD cards in the shop - are they both ready to go, or which script should be used for those? Again, an explicit mention of what's right and what's wrong would give some clarity.

There is now only one current "image" that may get referred to by several labels many depend on context, the current version of that "image" is emonSD-13-08-14.img.

That "image" is the complete Raspbian OS modified to mount in read-only mode with both emonhub and emoncms pre-installed. emonhub just needs the configuration file edited with some details to work out of the box where as emoncms is installed but not configured, so additional steps are required to "enable" emoncms if a local instance is required, otherwise it will remain dormant.

The version of emonhub pre-installed is the "Pre-Release development version (rc1.0)" which is still the current copy in general use. ...(rc1.1) is in progress and any other versions are not strictly supported as they are  early prototypes etc.

The pre-installed emoncms version is "master:8.2.8, bufferedwrite:0.0.1" which is an early copy of the newer, leaner "low-write" or "lite" strain of emoncms, which has since been revised and the current version is "8.3.6, bufferedwrite:0.0.2" this can be updated on the "image" using usual git methods.

emoncms can also be upgraded from the "low-write version" to a "full version" if using a hdd and would like to regain the features suppressed to reach "low-write" status. This I believe can be achieved by switching git branches after installing a hdd as documented in this guide (despite the references to an earlier "image")

I believe the only difference in the 2 cards sold in the shop is the media format. Both are 4gb and both have the "latest image". The new Pi model B+ only accepts a microSD card and the previous Pi model B takes a standard larger SD card (or a microSD in an adapter).

If using an "image" whether purchased on one of the cards or downloaded as an "image" and written to a card, emonhub is ready to go (except config) and doesn't require installing or (at this time) updating so the only "script" that should be run is the ntp-backup script. This is to further modify the changes made to the latest "image" to accommodate the clock in a read-only file system. It should also be safe to use on earlier images but is predominantly needed by the latest "image" due to a characteristic of that image. It is IMO  recommended that the ntp-backup script be used with any "read-only" raspbian image.

The "dev-emonhub/install" script is something basic I knocked up to install emonhub to a fresh image during development and can be used for that purpose without an issue, it is not a refined installer and it may not cope with other scenarios eg an existing install.

In addition to that script there is "dev-emonhub/upgrade" (note - upgrade not update), it is a simple script which will remove a pre-existing emoncms "rfm2pi package" or "raspberrypi module", before triggering the afore mentioned basic "dev-emonhub/install" script. It does not update emonhub it merely removes the old rfm2pi interface to allow an upgrade to "emonhub" from said interface, which is done in turn by the "dev-emonhub/install" script.

When emonhub gets revised and an update is required it will probably be via the usual git route or I may create another script to automate the process. All of this is work in progress and hopefully one day all scenarios will be catered for in one menu driven script, but thats a way off yet.

When Trystan puts the next "image" together, I expect it will have the latest emonhub and emoncms at that time and hopefully, the ntp-backup mod too.  

Sorry for the long post, I hope it helps clarify (and not confuse further) what can be quite a confusing subject. It isn't intended to be a "how to" guide, just an insight and explanation of how the current "bits" fit together.

Paul

Thank's Paul for this very complete post. Now it's clear in my mind.

Eric

Hello all!
Tried switching to the new SD image as I had a corrupt SD :-(...

I followed this guide, edited the emonhub conf file and also ran this command:

git clone https://github.com/emonhub/ntp-backup.git ~/ntp-backup && ~/ntp-backup/install

The only things my log give me are:

pi@raspberrypi ~ $ tail -f /var/log/emonhub/emonhub.log
1970-01-01 00:00:25,080 INFO EmonHub Pre-Release Development Version (rc1.0)
1970-01-01 00:00:25,083 INFO Opening hub...
2014-10-31 17:07:43,745 INFO EmonHub Pre-Release Development Version (rc1.0)
2014-10-31 17:07:43,747 INFO Opening hub...

After a reboot:

pi@raspberrypi ~ $ tail -f /var/log/emonhub/emonhub.log
2014-10-31 17:08:58,559 INFO EmonHub Pre-Release Development Version (rc1.0)
2014-10-31 17:08:58,562 INFO Opening hub...

emonCMS version: Powered by openenergymonitor.org | v8.3.6, bufferedwrite:0.0.2

And ofcourse an empty input screen in emonCMS. Any clues here? I use a RFM2Pi with RFM69CW module, can that be the problem?
 

Hi, yes emonHub rc1.0 doesn't accommodate the rfm69 yet (rc1.1 definitely will) I've PM'd you some details rather than go too far off topic on this thread, since the rfm69 isn't widely used yet.

You should also set "loglevel = debug" in emonhub.conf to see more of what's going on when trying to iron out any issues it's far more informative.

Paul

Does the PacketGen module work with emonHub?

There is a "hack" that Trystan put together as a temporary measure. The previous implementation wasn't carried over into emonHub so other methods of passing control packets could be explored without the restriction of having to fit in with pre-existing code.

This will tie in with other areas of development like MQTT, Data over secure HTTP into emonhub, emonHub configuration via emonCMS etc

Paul

The oemgateway had an implementation called OemGatewayRFM2PiListenerRepeater that enabled me to send packets on the RFM12PI via sockets. Are there any plans of of implementing something similar for Emonhub?

Hi Paul

Thanks for the update and appreciate the time that you are committing to this, it's good to know that it's still under development, and look forward to the next release.
 

Paul

There certainly is intention to provide the same functionality, I would like to say soon but may need to settle for hopefully soon'ish. It was deliberately omitted from emonHub to leave room for a more universal solution to outgoing data.

Rather than retain the ListenerRepeater and add packetgen code and then bolt on some MQTT etc etc I'm looking at making emonHub interfacers bi-directional, with some routing control. As mentioned in a post on the MQTT thread today I do have a working prototype but it still needs a fair bit of work yet.

Paul

I just followed the guide here

http://openenergymonitor.blogspot.co.uk/2014/10/emonhub-installationupda...

I did

 git clone https://github.com/emonhub/dev-emonhub.git ~/dev-emonhub && ~/dev-emonhub/upgrade

now when I run the command to start i get an error 

root@oemgateway:~/emonhub/service# ./emonhub start

[....] Starting OpenEnergyMonitor emonHub: emonhubstart-stop-daemon: unable to start /usr/share/emonhub/emonhub.py (Permission denied)

Any ideas, as I would rather not reinstall the whole sd ?

it does seem to be updating but I dont know why it errors..

Have you tried;

$ sudo service emonhub start

-- as per the blog?

Paul

Yep

MacBook-Pro:~ davidd$ ssh 192.168.0.5 -lroot

root@192.168.0.5's password: 

root@oemgateway:~# sudo service emonhub start

[....] Starting OpenEnergyMonitor emonHub: emonhub has been started okstart-stop-daemon: unable to start /usr/share/emonhub/emonhub.py (Permission denied)

root@oemgateway:~#

I'm just heading out so can only point you in the right direction for the moment.

Your command prompt "root@oemgateway" suggests you are using the older OEM gateway "rock-solid" image.

The IPE-R1 read-only OS that that image was based on is the main reason behind the image needing replacing, it cannot be updated and has several flaws, it was never factored in that someone may want to replace OEMG and retain IPE-R1. You really are in effect keeping the worst bit and trying to replace the good bit with something that was not really designed to run on IPE-R1.

It may well work but not by just using the installer I'm afraid. If you are still getting data it is probably because OEMG is still functioning. The error message tells us emonhub couldn't be started due to permission issues. which maybe related to the fact IPE-R1 is run as root (which isn't good either)

If you run 

sudo update-rc.d -f emonhub remove

that should prevent emonhub from attempting to start at boot and OEMG should work as before.

I would recommend considering the new image as it's built on raspbian and runs read-only mode which was the original and only real benefit of IPE-R1. 

Paul

OK Thanks, I have run your suggested command and will go to emonSD-13-08-14.img.zip in the festive break

Hi David,

Can you tell me how you configured OemGatewayRFM2PiListenerRepeater?

Is it just a case of adding stuff to the .conf file?

Thanks,

David

@David - I have answered you on the "Emonhub and OEM Gateway" thread, but yes you just define a ListenerRepeater in place of the existing Listener.

Paul

Hi,

I installed emonhub. I used raspberrypi module before.
The installation worked fine, but starting emonhub fails.

I receive a "Permission denied" when starting emonhub using root or pi user.

pi@raspberrypi ~ $ sudo service emonhub restart
[....] Restarting OpenEnergyMonitor emonHub: emonhubstart-stop-daemon: unable to start /usr/share/emonhub/emonhub.py (Permission denied)
[ ok been restarted ok.

What is wrong? Can anyone help?

Checking the status of emonhub:

pi@raspberrypi ~ $ sudo service emonhub status
[FAIL] Checking OpenEnergyMonitor emonHub: emonhub process has failed!

I installed emonhub as root.

Emonhub logfile is empty!

Best regards,

Christian

Hi Christian

What does " ls -la /usr/share/emonhub/emonhub.py " return?

Which OS are you using? Wheezy or Jessie? 

Can you expand on "I installed emonhub as root" ? are you saying you were logged in as a  root user or that you used sudo for the git clone?

Much of the parts are installed as root from within the install script but using root could have set the cloned emonhub folders to root ownership. If " ls -la /home/pi/emonhub " shows "root:root" try "sudo chown pi:pi /home/pi/emonhub " to reset the ownership.

(Sorry if I'm a bit rusty on this, the scripts were written sometime ago)

Paul

Hi Paul,

thank you, I got it to work now!

For the first installation I was logged in as root.

s -la /usr/share/emonhub/emonhub.py
returned root:root. Changing the owner did not solve the problem!

I removed emonhub again and installed it using user "pi" (logged in as "pi" and not as "root").
Everthing is fine now!

Thank you for your support. Your post was very helpful!

Best regards,

Christian

My bad! I think that should of been " sudo chown -R pi:pi /home/pi/emonhub " so that all the files and sub-folders were changed too.

Good to hear you're up and running anyway.

Paul

Hi Paul,

emonhub works fine now! I am happy with the new version. Great tool, good job!
Hope I can contribute some code to emoncms in the future...

Christian

Hello,

I have problem that after fresh installation of Raspbian Jessie, Emoncms and EmonHub communication between EmonHub and RFM12Pi does not work.

I followed installation guide - https://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/readme.md

In EmonHub log I can see:

2015-12-31 20:09:58,348 DEBUG SIGINT received.
2015-12-31 20:09:58,349 INFO Exiting hub...
2015-12-31 20:09:58,442 INFO Exit completed
2015-12-31 20:10:10,090 INFO EmonHub Pre-Release Development Version (rc1.2)
2015-12-31 20:10:10,093 INFO Opening hub...
2015-12-31 20:10:10,094 INFO Logging level set to DEBUG
2015-12-31 20:10:10,095 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2015-12-31 20:10:10,098 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2015-12-31 20:10:10,106 INFO Setting emonCMS url: http://localhost/emoncms
2015-12-31 20:10:10,107 INFO Setting emonCMS apikey: set
2015-12-31 20:10:10,109 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2015-12-31 20:10:10,111 DEBUG Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2015-12-31 20:10:12,115 ERROR Unable to create 'RFM2Pi' interfacer: device reports readiness to read but returned no data (device disconnected?)

in syslog I can see repeated following lines:

Dec 31 20:22:56 raspberrypi systemd[1]: Stopping Serial Getty on ttyAMA0...
Dec 31 20:22:56 raspberrypi systemd[1]: Starting Serial Getty on ttyAMA0...
Dec 31 20:22:56 raspberrypi systemd[1]: Started Serial Getty on ttyAMA0.
Dec 31 20:23:07 raspberrypi systemd[1]: serial-getty@ttyAMA0.service holdoff time over, scheduling restart.
Dec 31 20:23:07 raspberrypi rsyslogd-2007: action 'action 18' suspended, next retry is Thu Dec 31 20:24:07 2015 [try http://www.rsyslog.com/e/2007 ]

I am out of ideas what to check and how to fix it...

Lubos

[Read "Read this before posting"    Your duplicate post has been deleted. Moderator (RW)]

Hi Lubos

​Have you definitely restarted the Pi after editing the cmdline.txt file in the "Install Emonhub" section of that guide? the emonhub.log says there is a serial port comms issue and the syslog seems to suggest the original settings for the serial port to be used as a serial console are still in play.

Otherwise ss the baud correct for your device? 38400 is the most widely used now but there are some 9600 and 57600 baud rfm2pi's out there.

Paul

Hi Paul,

first of all - Happy New Year 2016!

yes, I did (I attached reciever after installation without power RPI) and after that again and again.

I had to reinstall my previous installation due to SD card failure.

Can you please point me where can I change bauds? I can't find it, I tried steps described in post "/etc/inittab no longer present in Raspbian Jessie?" (https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=123081)

"console=ttyAMA0,9600 kgdboc=ttyAMA0,9600 console=tty1"

It did not help.

Thank you,

Lubos

Am I the first to post in 2016?? (sad I know!)

To force a baud rate to emonhub:

$ nano /etc/emonhub/emonhub.conf

[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
​        com_baud =57600

Best Wishes

Paul

Hello,

I installed Jessie, EmonCMS, EmonHub again and strictly followed the guide (all actions double checked).

Now I see different lines in emonhub.log, I probably made a mistake before.

2016-01-01 12:23:32,976 INFO EmonHub Pre-Release Development Version (rc1.2)
2016-01-01 12:23:32,977 INFO Opening hub...
2016-01-01 12:23:32,980 WARNING Setting emonCMS apikey: obscured
2016-01-01 12:23:32,982 ERROR could not open port /dev/ttyAMA0: [Errno 13] Permission denied: '/dev/ttyAMA0'
2016-01-01 12:23:32,983 ERROR Failed to create 'RFM2Pi' interfacer: Could not open COM port /dev/ttyAMA0
2016-01-01 12:27:51,933 ERROR could not open port /dev/ttyAMA0: [Errno 13] Permission denied: '/dev/ttyAMA0'
2016-01-01 12:27:51,935 ERROR Failed to create 'RFM2Pi' interfacer: Could not open COM port /dev/ttyAMA0
2016-01-01 12:29:10,081 INFO EmonHub Pre-Release Development Version (rc1.2)
2016-01-01 12:29:10,096 INFO Opening hub...
2016-01-01 12:29:14,118 WARNING Device communication error - check settings
2016-01-01 12:32:40,430 INFO Logging level set to DEBUG

2016-01-01 12:34:02,295 DEBUG SIGINT received.
2016-01-01 12:34:02,297 INFO Exiting hub...
2016-01-01 12:34:02,298 DEBUG Closing serial port
2016-01-01 12:34:02,362 INFO Exit completed

Here I restarted R-PI and permission denied disappeared.

2016-01-01 12:34:12,902 INFO EmonHub Pre-Release Development Version (rc1.2)
2016-01-01 12:34:12,921 INFO Opening hub...
2016-01-01 12:34:12,923 INFO Logging level set to DEBUG
2016-01-01 12:34:12,925 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2016-01-01 12:34:12,928 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2016-01-01 12:34:12,938 INFO Setting emonCMS url: http://localhost/emoncms
2016-01-01 12:34:12,939 INFO Setting emonCMS apikey: set
2016-01-01 12:34:12,940 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2016-01-01 12:34:12,956 DEBUG Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2016-01-01 12:34:17,022 WARNING Device communication error - check settings
2016-01-01 12:34:17,023 INFO Setting RFM2Pi frequency: 433 (4b)
2016-01-01 12:34:18,026 INFO Setting RFM2Pi group: 210 (210g)
2016-01-01 12:34:19,028 INFO Setting RFM2Pi quiet: 1 (1q)
2016-01-01 12:34:20,031 INFO Setting RFM2Pi baseid: 15 (15i)

I added com_baud = 9600 into emonhub.conf and it works! I can see new nodes in EmonCMS.

2016-01-01 12:42:46,270 DEBUG Closing serial port
2016-01-01 12:42:46,272 INFO Deleting interfacer 'RFM2Pi'
2016-01-01 12:42:46,273 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2016-01-01 12:42:46,275 DEBUG Opening serial port: /dev/ttyAMA0 @ 9600 bits/s
2016-01-01 12:42:48,279 INFO RFM2Pi device firmware version & configuration: not available
2016-01-01 12:42:48,280 INFO Setting RFM2Pi frequency: 433 (4b)
2016-01-01 12:42:53,730 DEBUG emonCMS acknowledged receipt with 'ok' from http://localhost/emoncms
2016-01-01 12:42:53,784 DEBUG RFM2Pi confirmed sent packet size:  -> ack
2016-01-01 12:42:56,476 DEBUG 3 NEW FRAME : 1451652176.48  1 250 30 244 11 54 1
2016-01-01 12:42:56,478 DEBUG 3 Timestamp : 1451652176.48
2016-01-01 12:42:56,481 DEBUG 3      Node : 1
2016-01-01 12:42:56,482 DEBUG 3    Values : [7930, 3060, 310]
2016-01-01 12:42:56,539 DEBUG 3 Append to 'emonCMS' buffer => time: 1451652176.48, data: [1, 7930, 3060, 310], ref: 3

Thank you for your help!

Lubos

Pleased that you have got it sorted.

Paul

Yes good to see it sorted, although I cannot explain the " ERROR could not open port /dev/ttyAMA0: [Errno 13] Permission denied: '/dev/ttyAMA0'" errors, I will try a Jessie install "by the guide" myself and see if I can reproduce.

Paul