64 emonTH with 3 emonBase and custom emonCMS, working but something is weird

emonHub
1

Hello everyone,

My sensors architecture is

emonBase01
22 emonTH each nodeID from 01 to 22 (emonHub conf)
Network Group: 201

emonBase02
21 emonTH each nodeID from 01 to 21 (emonHub conf)
Network Group: 202
nodeoffset = 22 (with this parameter nodes are considered in emoncms by nodeID + nodeoffset, right?)

emonBase03
21 emonTH each nodeID from 01 to 21 (emonHub conf)
Network Group: 203
nodeoffset = 43 (with this parameter nodes are considered in emoncms by nodeID + nodeoffset, right?)

So, now in my custom emonCMS I have node from 1 to 64
The weird appears when, with the same sketch with nodeID and network group changing values for each (logic described below), the value are not the same with a 10 factor scale.
every scale in emonhub conf are the same for each node
sample:

[[01]]
nodename = emonth01
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
[[02]]
nodename = emonth02
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
…

Seems that the network group logic is the issue…
Can you help me understand things please?

Thanks

2

I’m not quite sure what your problem is, but I’ve just tested nodeoffset with an emonPi and emoncms.org, and it appears to do what you want.

I accidentally put it in the wrong place - and it worked. Then I put it where I thought it should be (in the [[emoncmsorg]] section) and it did not.

In emonhub.conf (in the emonPi, naturally)

[interfacers]
### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400                        # 9600 for old RFM12Pi
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,

        group = 210
        frequency = 433
        baseid = 5                              # emonPi / emonBase nodeID
        calibration = 230V                      # (UK/EU: 230V, US: 110V)
        quiet = true                            # Disable quite mode (default enabled) to enable RF packet debugging, show packets which fail crc
        # interval =  300                         # Interval to transmit time to emonGLCD (seconds)
        nodeoffset=30

The entry lower down in the same emonhub.conf is unchanged as Node 5, (but it has left a gap in the local record, so I think that too became Node 35 in the emonPi’s emonCMS.)

And in emoncms.org, I see the emonPi itself - it should be Node 5 - appears as Node 35.

As you are sending to another emonBase(?) over a LAN(?), remember that in that case, it bypasses emonHub in the receiving emonBase. Therefore the emonhub.conf in your custom emonCMS has no effect.

The purpose of nodeoffset is to bypass the limitation of 0 - 31 for the NodeID in JeeLib only - so when the data has got through the radio channel and JeeLib, the restriction no longer applies.

1 Like
3

nodeoffset is working correctly for me

22 emonTH each nodeID from 01 to 22 (emonHub conf)
Network Group: 201
baseId: 1
no nodeoffset → so emonTH are from 1 to 22

emonBase02
21 emonTH each nodeID from 01 to 21 (emonHub conf)
Network Group: 202
baseId: 2
nodeoffset = 22 → so emonTH are from 23 to 43

emonBase03
21 emonTH each nodeID from 01 to 21 (emonHub conf)
Network Group: 203
baseId: 3
nodeoffset = 43 → so emonTH are from 44 to 64

my question is : network group means that you can put in a group 30 nodeID independant of the offset(offset is just a naming rule), right?
Because I see with the same arduino code, some changes , depending on the group and nodeID (for me groups used are 201 for 22 nodes, 202 for 21 nodes, 203 for 21 nodes)
Those changes are a 10 multiplication factor for node 10 to 22 on group 201 …
i am testing the same for group 202 and the values are good for the moment

Are there some rules on Network group that I have to know outside of the documentation :smiley: ?

4

The starting point is the Radio Module (RFM12B or RFM69CW). There are two frequency bands that we use, usually we use the lower of the two at 433 MHz. Everything that all your emonTHs send is on the same radio frequency.

As part of the data packet, there are two pieces of information. The first is the Network Group. All the radios that use the same Group can talk to each other. Those in a different group can also talk to each other within that group, but each group ignores messages from the other groups. The second piece of information is the Node ID. Each unit within a group must have its own unique Node ID.

Therefore, to identify any one node, you must know its Group and its Node ID. EmonCMS knows nothing about Groups, it also does not have a limit of 31 on the Node ID. So what nodeoffset does is translate the NodeIDs belonging to a Group by moving them to a different block of numbers. When that happens, the “Group” disappears.

There does not need to be a link between the nodeoffset and the Group. You could have
  Group 210: Nodes = 6 & 7, nodeoffset = 0
  Group 38: Nodes = 7, 8, 9, 11, 14, 15 & 18, nodeoffset = 2
  Group 212: Nodes = 11 - 18, nodeoffset = 10
which would give you the new Node IDs:
6 & 7 (from Group 210)
9, 10, 11, 13, 16, 17, & 20 (from Group 38)
21 - 28 (from Group 212)

5

Ok so my logic is correct
so my problem concerns

problem with node ID = 10 to 22 on the first emonPi with group 201
no problem detected on 21 other emonTH nodes connected to the second emonPi with group 202 (node offset = 22)
no problem detected on 21 other emonTH nodes connected to the third emonPi with group 203 (node offset = 43)
Same arduino code but for the first emonPi with group 201:

node 1 send 250 on Temperature
…
node 9 send 250 on Temperature
node 10 send 25.0 on Temperature
…
node 22 send 25.0 on Temperature

So is there something special to know? with emonHub conf with group = 201 nodeID = 1, or node 10 to 22 connected to this emonPi, or both…?

Seems really tricky to investigate correctly

6

I don’t have a spare emonPi that I can experiment with.

In the emonbub.conf in the group 201 emonPi, have you specified all 22 nodes? Are any nodes specified twice?

7

On each of your emonBase, you need to look at the emonhub log - what is it sending to the main emoncms?

Is it sending by MQTT or HTTP?

Do you mean emonPi or emonBase?

8

it’s an emonBase
with http

9

I generate this long node string with a loop in python with the right formatting in the nodes part of the conf

[nodes]

## See config user guide: https://github.com/openenergymonitor/emonhub/blob/emon-pi/conf/emonhub.conf

[[01]]
        nodename = emonth01
        [[[rx]]]
                names = temperature, external temperature, humidity, battery
                datacode = h
                scales = 0.1,0.1,0.1,0.1
                units = C,C,%,V
[[02]]
        nodename = emonth02
        [[[rx]]]
                names = temperature, external temperature, humidity, battery
                datacode = h
                scales = 0.1,0.1,0.1,0.1
                units = C,C,%,V
[[03]]
        nodename = emonth03
        [[[rx]]]
                names = temperature, external temperature, humidity, battery
                datacode = h
                scales = 0.1,0.1,0.1,0.1
                units = C,C,%,V
[[04]]
        nodename = emonth04
        [[[rx]]]
                names = temperature, external temperature, humidity, battery
                datacode = h
                scales = 0.1,0.1,0.1,0.1
                units = C,C,%,V

So everything is in the right place, only integer changes for the nodename and node number

11

You need to send a portion of the emonhub log that shows a complete cycle of the emonTHs for that emonBase. Please save as a text file and upload.

12

Are you certain that each emonTH has an identical sketch uploaded to it, except for the Group and NodeID?

13

emonhub _PROOF.log.zip (170.5 KB)

remove the zip extension after download
I put you the essential of the value received by emonhub
with the same arduino code
node 1 to 9 send values like [250,…]
and node 10 to 22 send values like [25.0, …]

14

image
Sorry, that zip file is damaged.

15

delete zip off the filename.

16

Are you running custom firmware on the emonTHs?

The first number after the OK, is the node i.e should reference the emonTH sending the data. You are getting about 20 readings that say they are all from node 3. Clearly they are not as the readings seem to be cyclic.

Also you never seem to send any data on. Can you restart the emonhub and post the log of the restart?

2020-06-30 17:49:53,399 DEBUG    RFM2Pi     173 NEW FRAME : OK 3 10 0 0 0 0 0 0 0 (-63)
2020-06-30 17:49:53,507 DEBUG    RFM2Pi     174 NEW FRAME : OK 3 9 0 0 0 0 0 0 0 (-63)
2020-06-30 17:49:53,614 DEBUG    RFM2Pi     175 NEW FRAME : OK 3 8 0 0 0 0 0 0 0 (-63)
2020-06-30 17:49:53,722 DEBUG    RFM2Pi     176 NEW FRAME : OK 3 7 0 0 0 0 0 0 0 (-63)
2020-06-30 17:49:53,830 DEBUG    RFM2Pi     177 NEW FRAME : OK 3 6 0 0 0 0 0 0 0 (-62)
2020-06-30 17:49:53,937 DEBUG    RFM2Pi     178 NEW FRAME : OK 3 5 0 0 0 0 0 0 0 (-63)
2020-06-30 17:49:54,045 DEBUG    RFM2Pi     179 NEW FRAME : OK 3 4 0 0 0 0 0 0 0 (-63)
2020-06-30 17:49:54,152 DEBUG    RFM2Pi     180 NEW FRAME : OK 3 3 0 0 0 0 0 0 0 (-62)
2020-06-30 17:49:54,260 DEBUG    RFM2Pi     181 NEW FRAME : OK 3 2 0 0 0 0 0 0 0 (-61)
2020-06-30 17:49:54,367 DEBUG    RFM2Pi     182 NEW FRAME : OK 3 1 0 0 0 0 0 0 0 (-63)
2020-06-30 17:49:54,475 DEBUG    RFM2Pi     183 NEW FRAME : OK 3 0 0 0 0 0 0 0 0 (-63)
2020-06-30 17:49:59,812 DEBUG    RFM2Pi     184 NEW FRAME : OK 3 234 0 0 0 22 2 5 0 (-63)
2020-06-30 17:50:57,477 DEBUG    RFM2Pi     185 NEW FRAME : OK 3 234 0 0 0 20 2 5 0 (-64)
2020-06-30 17:51:03,922 DEBUG    RFM2Pi     186 NEW FRAME : OK 3 10 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:04,029 DEBUG    RFM2Pi     187 NEW FRAME : OK 3 9 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:04,138 DEBUG    RFM2Pi     188 NEW FRAME : OK 3 8 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:04,248 DEBUG    RFM2Pi     189 NEW FRAME : OK 3 7 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:04,356 DEBUG    RFM2Pi     190 NEW FRAME : OK 3 6 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:04,464 DEBUG    RFM2Pi     191 NEW FRAME : OK 3 5 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:04,571 DEBUG    RFM2Pi     192 NEW FRAME : OK 3 4 0 0 0 0 0 0 0 (-63)

020-06-30 17:51:09,505 DEBUG    RFM2Pi     193 NEW FRAME : OK 4 10 0 0 0 0 0 0 0 (-63)
2020-06-30 17:51:09,613 DEBUG    RFM2Pi     194 NEW FRAME : OK 4 9 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:09,720 DEBUG    RFM2Pi     195 NEW FRAME : OK 4 8 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:09,828 DEBUG    RFM2Pi     196 NEW FRAME : OK 4 7 0 0 0 0 0 0 0 (-63)
2020-06-30 17:51:09,936 DEBUG    RFM2Pi     197 NEW FRAME : OK 4 6 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:10,044 DEBUG    RFM2Pi     198 NEW FRAME : OK 4 5 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:10,151 DEBUG    RFM2Pi     199 NEW FRAME : OK 4 4 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:10,259 DEBUG    RFM2Pi     200 NEW FRAME : OK 4 3 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:10,366 DEBUG    RFM2Pi     201 NEW FRAME : OK 4 2 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:10,474 DEBUG    RFM2Pi     202 NEW FRAME : OK 4 1 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:10,582 DEBUG    RFM2Pi     203 NEW FRAME : OK 4 0 0 0 0 0 0 0 0 (-63)
2020-06-30 17:51:15,814 DEBUG    RFM2Pi     204 NEW FRAME : OK 4 234 0 0 0 20 2 6 0 (-62)
2020-06-30 17:51:58,235 DEBUG    RFM2Pi     205 NEW FRAME : OK 4 10 0 0 0 0 0 0 0 (-62)
2020-06-30 17:51:58,343 DEBUG    RFM2Pi     206 NEW FRAME : OK 4 9 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:58,450 DEBUG    RFM2Pi     207 NEW FRAME : OK 4 8 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:58,558 DEBUG    RFM2Pi     208 NEW FRAME : OK 4 7 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:58,665 DEBUG    RFM2Pi     209 NEW FRAME : OK 4 6 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:58,772 DEBUG    RFM2Pi     210 NEW FRAME : OK 4 5 0 0 0 0 0 0 0 (-61)
2020-06-30 17:51:58,880 DEBUG    RFM2Pi     211 NEW FRAME : OK 4 4 0 0 0 0 0 0 0 (-61)
17

The first transmission from power-up is the factory test, a countdown from 10 to 0 in the word following the NodeID (“temp”), with a 100 ms delay between transmissions. But it should only happen once - it looks as if the watchdog might be firing if it goes a second time.

18

No I mean you get about 20 frames saying node 3, then 20 saying node 4. The first byte is very similar each set of frames apparently from the same node (byte 1 frame 1 for ‘node’ 3 [173] & 4[193] is 10 etc)…

19

@gregory That is NOT the way you make a zip file. Do you not know how to “zip” and compress a file so that it is made smaller for transmission?

@borpin
Now that I’ve got into the not-a-zip file, the watchdog is firing repeatedly on Node 3. Starting at the top, it gets as far as 4 then fires again, then gets through and does two apparently genuine temperature readings 1 m 6 s apart, the 6 s later the watchdog fires again, gets to 4, then fires again.

There’s something seriously wrong with the sketch or the power supply - I think we need to see the sketch because the standard official one transmits the pulsecount as well, and that’s missing. I wonder what else has been changed - a battery voltage of “5”, “6” or “7” is suspicious as it’s in mV.

21

emonhub _PROOF.log.zip (170.5 KB)

remove the zip extension after download

22

Thanks guys for your consideration, but you miss my point

i took 22 emonTH one by one and:
powered on each
put the same code on each, just, node ID changes for each
wait to have at least some correct values
and poweroff this one and pass to another
the important to me was to be sure they all send values to something like
[253, 240, 517, 4] (Here this is the nodeID 3 )

What I am asking is why those emonTH WITH nodeID 1 to 9 send something like the nodeID 3
and (the point is here) why with the same code and node ID from 10 to 22 they send something like
[25.3, 24, 51.7, 0.4]

Am I clear?