Recording Multiple emonPi - nodeID on local emonCMS fixed to 8

Getting Started
,
1

Hi,
I’ve been tasked with setting up a side-wide power monitoring system using OpenEngeryMonitor. We’ve got multiple buildings we need to monitor power use in, so have bought multiple pairs of emonTX and emonBase units. We’ve then got a local server with emonCMS running on it.
I can get one emonBase to communicate with emonCMS, but trying to add a second takes over the first. I can’t seem to get the inputs page on the emonCMS server to have anything but “node 8” as the input node. I’ve changed the emonHub config on one of the emonBase units so that the baseID value in [[RFM2Pi]]/[[runtimesettings]] is 9 and changed the [nodes] section so that [9] refers to the emonTX.
In the Inputs view on the emonBase, the input node I’ve seemingly changed to 9 in emonHob config still shows as node 8, so I think that might be the problem I’m having. However, I though that the emonBase would be treated as a node by emonCMS, and the baseID value set its node number.
I’ve clearly misunderstood something fundemental, so if anyone’s able to give me a pointer so I can make sure different emonBases are seen as different nodes on our emonCMS server, I’d be very greatful.

Kind Regards,
Alyn Sparkes.

2

Welcome, Alyn, to the OEM forum.

What have you changed in the emonTx? “Node” refers to the sensing node, the emonBase (that you’re using to forward the data - presumably via Ethernet?) isn’t a “Node” in our nomenclature.

[Can you clarify exactly what you mean by “emonBase” - is it a Raspberry Pi with the RFM69Pi RFM module sitting on the GPIO connector? https://cdn2.bigcommerce.com/server4400/98a75/products/164/images/648/IMG_5350__74182.1425392972.1280.1280__80483.1425393084.220.220.jpg?c=2]

So I think what you need to do is alter the NodeID inside each emonTx so that each is unique.
You’re not tied to using our default Node IDs, you can have any number in the range 1 - 30 (this is a limitation of JeeLib, the radio library that we use). If you’re decoding and saving the data in each emonBase, then you do need a definition in emonhub.conf that matches each emonTx and nodeID that the base is intended to receive.

This refers to the serial data that comes into the RPi from the “emon” analogue front end of an emonPi. (So an emonPi is a sensing node with NodeID = 5 plus an emonBase in the same box.)

Note: If your emonBase is a RPi, you’ll have (n+1) copies of emonCMS - there’s one in each emonBase, plus the one running on your server. And they are all different and entirely separate copies. I mention this as it’s a real source of confusion to newcomers to the system.

3

Hi Alyn,

Key thing is that the ‘Node’ is hard coded (well the dip switch can change it a little) on the EmonTX. If the TXs are close enough, each base will pick up the data from each others RFM transmission, so I suggest you define a single node in each config so it will ignore the others.

You say ‘multiple’ how many?

The EmonTX transmits data via RFM to the EmonBase RFM card. The EmonHub then takes this data, off the serial interface, decodes it and forwards it. This can be done in a number of ways, the most common are MQTT and HTTP.

In a ‘single’ system, the emonbase Pi has a copy of emoncms running locally, so the emonhub is, by default, setup to talk to that local copy.

What you really need is for each ‘base’ to just use the local emonhub and forward all the data to a single instance of emoncms (that can still be on your LAN or just one of the EmonBase Pis).

Start with 2 EmonTX and the EmonCMS instance you want to use as your ‘master’.

Ideally each machine should have a static IP (or fixed lease). The EmonCMS machine definitely needs that.

Point each of the base’s emonhub MQTT config to the EmonCMS IP.

[[MQTT]]

    Type = EmonHubMqttInterfacer
    [[[init_settings]]]
        mqtt_host = 127.0.0.1
        mqtt_port = 1883
        mqtt_user = emonpi
        mqtt_passwd = emonpimqtt2016
4

Hi Rob,
Thanks for getting back to me. Firstly, the emonBase is as you describe - as Raspi with the RFM module sat on top. We’ve had one of these for ages, working with a local server install of emonCMS and now want to expand the system to cover multiple building (all 3-phase power).
I’ve not changed anything on the emonTX - I’ve only been altering numbers (baseID and node numbers) in the emonHub config file.
So to alter the nodeID on the emonTX, I have to alter the sketch running on it? Arduino IDE and a USB to UART device required?
I’m aware that each emonBase is running its own emonCMS - it’s why I’ve referred to emonCMS server above. I’ve only been using the local emonCMSs to alter the emonHub config file.

Cheers,
Alyn

5

Hi Brian,
Thanks for that. We’re looking at 9 “pairs” of emonTX and emonBase. They’re in different buildings and each emonBase shouldn’t be able to pick up more than one emonTX.
We’ve had one single “pair” AND an emonCMS server running for a while - it’s now trying to add new pairs to this system that I’m running into trouble with identical node IDs. The original has been sending its data to the server via http as it would if it was sending to the cloud-hosted emonCMS service. I figured that the hosted service can distinguish between multiple senders of “node 8”, so the self-hosted version should too, but I just counldn’t work out how. It looks like I was mistaken in that assumption if I have to alter the nodeID on the sketch running each emonTX as mentioned in the previous answer.

Cheers,
Alyn

1 Like
6

Not necessarily. If your installed “pairs” are in no risk of receiving data from the other installs then there is a much simpler way to do what you want.

There is a “nodeoffset” setting available to all emonhub interfacers so leaving the first installs emonhub’s settings totally stock you can (for example) set nodeoffset = 10 for the second install and the received “node 8” data will be remapped as node 18 (8+10) and you can alter the node definitions for that install accordingly, ie edit [[8]] to [[18]] and remove/comment out any previous “node 18” (there can be only one node definition per node id). The Third install could be nodeoffset = 20 and so on. This would make no change to local data, but the common server would receive nodes 8, 18, 28 etc thru to node 88 if you have 9 installations.

The nodeoffset setting lives in the [[RFM2Pi]] [[[runtimesettings]]].

Be aware that the “node id” aka baseid you changed in the runtimesettings only changes the node id of the base ie the rfm69pi so it has no real effect unless transmitting from the base or you have some exotic sketch in the emontx that sends specifically FAO a perticular node id rather than “broadcasting to all” as the regular emonTx’s do, but you should ideally change it back just to be safe.

1 Like
7

Everyday a learning day - thanks Paul.

It seems it does not appear in the default / example conf file which is why I didn’t know about it.

[edit]
It is also not documented it seems. I did find it in one of the md files and some of the python files.

8

I’d remembered it - looked for documentation for how exactly it needed to be used, and couldn’t find anything - and then I’m never clear about all the various data pathways through emonHub and emonCMS.

9

Hi Everyone,
Just to report that I’ve gone for altering the NodeID in the sketch running on the emonTX. Changing the nodeoffset value didn’t seem to affect anything other than the Pi that was receiving the data from the emonTX - the offset value was not being passed on to the emonCMS server.
Changing the nodeID and uploading a new sketch via the UART connector has worked fine though.

So thanks - I’ve got a plan to move forward with, and I got to buy a new little tool (the USB-UART dongle) so it’s all good!

Cheers,
Alyn

1 Like