Setup multiple emontx's

Hardware emonPi
1

Hello,

I have 40 emon tx’s and 4 emonPI’s (four because of possible range issues)

Looking at the docs it seems I can only have 30 emonTX’s per pi so I need to setup something like this:

emonTX ID’s 1-10 on group 200
emonTX ID’s 1-10 on group 210
emonTX ID’s 1-10 on group 220
emonTX ID’s 1-10 on group 230

I then need to update the config file on each PI to the respective groups, this will in effect pair them/subnet them (hope this is right, I have not tried it yet).

My question is this, as some of my emonTX’s are only doing very specific things like CT clamp monitoring, can I update the PI config for the respective node ID and remove all the features I am not interested in to clean up my data a little? the docs say I can rename them, but not sure about removing them all together

for example:

[[5]]
    nodename = emonPi
    firmware = emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino
    hardware = emonpi
    [[[rx]]]
        names = power1,power2,power1_plus_power2,Vrms,T1,T2,T3,T4,T5,T6,pulseCount
        datacodes = h, h, h, h, h, h, h, h, h, h, L
        scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
        units = W,W,W,V,C,C,C,C,C,C,p

becomes

[[5]]
    nodename = emonPi
    firmware = emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino
    hardware = emonpi
    [[[rx]]]
        names = light,sockets,heating,fans
        datacodes = h, h, h, h
        scales = 1,1,1,1
        units = W,W,W,W
2

But the node you give as an example, Node 5, is the emon part of the emonPi itself. I don’t think you actually asked the question that you intended to ask. Don’t you mean you want to change all the remaining node definitions? If that’s the case, then you must edit the emonTx sketch to send only the data that you want, and the Node description in the emonPi must match exactly.

One more point to consider: all 40 emonTx’s will use the same radio band, so you might need to slow the reporting rate - the time between samples - to reduce the probability that two will transmit at the same time.

3

A definite range issue will fair better than a possible range issue. As Robert points out, they will still use the same frequency, in reality there is only one channel, the grouping is a filter so that only the same group nodes are processed, but to know what group a packet belongs to requires it to be decoded, so neighboring groups will still cause congestion and as the emonTx transmissions are not synchronized, it’s anyone’s guess what will get through where.

De-tuning the RF networks (shorten the antenna’s for example) might help ensure each network can’t reach the neighboring network. There is also a way of altering the FW of the receiver for a higher RSSI threshold so only the strongest signals can get through, but don’t ask me how. you will need to do some digging unless Robert can recall.

To be honest, even 10 emonTx’s on a single network is going to be congested at 10s intervals. Unfortunately even if you increase the interval to 60s, who’s to say they still won’t clash, yes the chances are reduced, but have you heard of sods law!

Where are all these emonTx’s located relative to the emonPi’s? could some of them be usb connected rather than RF?

I assume all this data will converge to a single emoncms at some point is that correct? In which case your node ids may need to be unique to the whole network depending on how you have it configured, In the original emonhub there was a feature called “node offset” where every node received was offset by a set amount eg nodeoffset=20 on the second receiver would make your nodes 1 to 10, appeared as 21 to 30 etc Setting a nodeoffset=32 would prevent any overlap giving you access to the full 32 node ids on each receiver/network . I do not know if this still works in the emonpi variant of emonhub without checking/testing.