Connecting multiple emonbase units to emoncms

borpin · 2020-10-16T17:01:57.270Z

Are you logging via HTTP or MQTT?

Robert.Wall · 2020-10-16T20:49:18.713Z

@borpin Isn’t this where “Node offset” comes into play?

borpin · 2020-10-16T21:22:32.203Z

Yes but needs more than that for 7 devices.

Just reread this so it is by HTTP

bez:

To summarise, I am asking is it possible to log outputs from say 6 emonbase units to one single emoncms.org account.

Probably best to set the nodeID on the EmonTX (using the CM firmware) and then modifying emonhub to suit I’d suggest.

Robert.Wall · 2020-10-16T22:42:16.717Z

One bit of essential information is missing: How many sensor nodes are associated with each Base? The top post implies one - is that correct?

It’s only our convention that the Node IDs are allocated as per the list in emonhub.conf, there’s no limit other than the restrictions of JeeLib, i.e. Nodes 0 and 31 (the highest available) are predefined, between those the numbers are free to allocate as desired. And this applies only to the radio hop. Once the data is in the base, the NodeID can be shifted if necessary for onward transmission to anywhere in the range 32 - 255.

If you do have 7 sets comprising one emonTx + one emonBase, then I don’t see a real problem - I’d suggest even numbers for the emonTx’s, and the next higher odd number for the base. It’s possible to change the NodeID of both the emonTx and the emonBase without editing and recompiling: for the emonTx it’s done with a programmer at startup; for the emonBase it can be done over the LAN. In both cases, the setting is retained in EEPROM.
[I don’t think it’s strictly necessary for each emonBase to even have a NodeID, as it doesn’t generate any data of its own and it never transmits.]

Of course, each emonhub.conf must be correct for it’s own nodes, and not have a definition for any of the other sensor nodes that it might be able to receive - otherwise emonCMS will receive two copies of the same data.

bez · 2020-10-19T10:22:22.327Z

Hi guys, thanks for replies so far and sorry for my limited knowledge (but I am getting better!).

To answer @borpin question, how would I know if i am logging via http or mqtt? I can say though that it is the standard way of logging to emoncms.org as per the instructions in the guide and I did not deviate from those. 3. Log Remotely - Guide | OpenEnergyMonitor

@Robert.Wall, some of the units have 2 emonTX connected to the base and some have only 1 - depending on individual installations.

bez · 2020-10-19T11:54:15.993Z

Hi borpin, how do I do this (modify the CM firmware)?

Robert.Wall · 2020-10-19T12:07:50.159Z

borpin:

Probably best to set the nodeID on the EmonTX (using the CM firmware) and then modifying emonhub to suit I’d suggest.

It’s a setting you can change by plugging in your programmer and looking at the serial monitor window in the Arduino IDE, as the emonTx starts up. (The Guide says it can be done over a limited range with the DIP switch - that only changes it by one, and you’ll need more than that. It sounds as if you’ve potentially got 14 sensor nodes.)

borpin · 2020-10-19T12:09:18.486Z

@bez, I need to be clear on the setup here, do you have 7x EmonTX and 7x EmonBases that you want to all log to emoncms.org? Are they located close to each other?

How recently did you buy them?

bez · 2020-10-19T12:23:00.042Z

@borpin - yes, we have 7 emonbase units and 13 emonTX units. They are not close to each other rather spread out among various sites/farms in northern ireland. 5 setups are currently up and running. 3 of these setups have 2 emonTX units and the emonbase and 2 of these have 1 emonTX unit and emonbase.

We wich to log all of these setup to a single emoncms account, to which we have credits from the purchases.

We purchased in the past month or so … three separate orders. Let me know if you need further information,

Cheers

borpin · 2020-10-19T12:55:30.379Z

Ok that helps.

EmonTX, by default uses node 15/16 and this can be changed in the firmware by connecting a programmer to the EmonTX or by using the dip switch (which you may have done as you have sites with 2 EmonTXs) - but that is more difficult.

However, emoncms.org only accepts numeric NodeIDs so you have 7 different stations sending to node 15/16 at emoncms.org.

The simplest way to fix this is to specify a nodeoffset - this is added to the NodeID sent by the EmonTX.

In the UI on each emonbase, select emonhub an then select edit config (save onec the changes are made)

Under this section

[[RFM2Pi]]
    Type = EmonHubJeeInterfacer

you need to add under runtimesettings

      [[[runtimesettings]]]
           nodeoffset = 2

An offset of 2 + 15 = 17.

What you then need to do on that emonhub.conf file is modify the node 15 so that it matches the new node 17

So in the emonhub.conf find [[15]] and change it to

[[17]]
    nodename = emontx3cm17
    [[[rx]]]

Do that for each. It will mean you need to set up the processing again on each base (if you use the local info), but these new ‘Inputs’ can be linked to the existing Feeds.

TrystanLea · 2020-10-19T13:29:42.883Z

bez:

We wich to log all of these setup to a single emoncms account, to which we have credits from the purchases.

It is possible for one emoncms.org account to administer credit for multiple accounts (see ’ Administer multiple accounts’ section on the emoncms.org My Account page). You could avoid the custom configuration by having one emoncms.org account per emonbase if you wanted to? that might make things simpler?

TrystanLea · 2020-10-19T13:32:49.521Z

Alternatively @borpin’s suggestion of changing the nodeid on the EmonTx and in emonhub.conf on the EmonBase units will also work. That can make it easier to then access all the data in a single account if that’s particularly useful for you?

bez · 2020-10-19T16:57:11.844Z

Hi all, thanks for the info. I have tried @borpin suggestion to offset the nodeID’s and can confirm that I have now 3 units sending data to emoncms.org successfully (on the same account). Great instructions and I will try the remaining units this week.

Just as a matter of interest, I have tried one unit using the nodeoffset = 2 (meaning units 15 and 16 are now 17 and 18) and one unit using the nodeoffset = 15 (meaning units 15 and 16 are now units 30 and 31). What is the maximum offset? going back to @Robert.Wall comments, I can have any number of node IDs from 32-355. Is that correct?

Thanks again.

Robert.Wall · 2020-10-19T17:28:43.175Z

To be honest, I’m not certain that the NodeID is restricted to a byte. In JeeLib, hence over the air, it’s restricted to 5 bits, so 0 - 31, but 0 and 31 are reserved, so the reality is 1 - 30.

Assuming it is a byte, I think, once you get into wires and Ethernet (one way or the other), the allowable range is in fact 0 - 255. (Not 355.)

I suggest try it and see. If it breaks, it’s wrong, and you put it back. The worst that can happen is some bits get masked off so (say, using the radio hop and JeeLib for the example) you have NodeID=35 (binary 100011), at the receiving end you’ll get it come out as NodeID=3 (the bottom 5 bits).

borpin · 2020-10-19T21:44:28.915Z

bez:

I have tried one unit using the nodeoffset = 2 (meaning units 15 and 16 are now 17 and 18) and one unit using the nodeoffset = 15 (meaning units 15 and 16 are now units 30 and 31).

KISS; just use 2,4,6,8

Robert.Wall · 2020-10-19T22:45:57.793Z

That will need a corresponding change in emonHub of the associated Pi Zero - and beware, you’re not allowed two node definitions in emonhub.conf with the same ID (obviously, but easily missed in a long list - also it’s in order to delete the unused ones).

borpin · 2020-10-20T06:50:06.150Z

Ah yes. Simply delete or comment out all the unused or duplicate definitions

bez · 2020-10-20T09:46:04.054Z

Yes, should have noted the reason for using nodeoffset = 15 is that there are some already used IDs with corresponding IDs namely 19 (emonth1) to 26 (emonth8), but suppose I could delete those as suggested.

Robert.Wall · 2020-10-20T12:03:00.639Z

bez:

but suppose I could delete those as suggested.

Indeed you can. In the early days (pre-emonPi and thus pre-emonHub), node IDs were a free-for-all and you chose whatever seemed a good idea. But then, this was largely a constructor’s website and not at all plug-and-play. As it and the shop moved towards the latter, NodeIDs got ‘suggested’ and then more and more cast in stone. There’s actually no need for that, but those of us who help with answering questions will assume you’re using the standard numbers unless you say otherwise. If you do change, it’s up to you to make their use consistent across your system. So if you want to call your emonBases 1 - 7 and the emonTx’s 8 - 21, that’s fine. So is 1, 2 & 3 for the first set of enontx/emonBase; 4, 5 & 6 for the second, etc.

borpin · 2020-10-20T12:04:01.048Z

bez:

there are some already used IDs with corresponding IDs namely 19 (emonth1) to 26 (emonth8)

If you have emonTH reporting, then the nodeoffset setting will affect those as well as it impacts on all nodes reporting to that base by RFM. This does complicate things .

Best to map out exactly what you have - what the default IDs are and what setting an offset on each base will do to those IDs.