Well I suggest you answer the questions we pose to get help. Am I clear?
The emonhub log does not make sense.
Is the emonTH code exactly the same as default except for the nodeID?
Turn on one emonTH and send us the emonhub log from restarting the service.
It CANNOT be the default sketch. As I pointed out above, that sends a pulse count by radio, which is missing from the emonhub.conf and logs we’ve seen sent. Here’s the code snippet:
typedef struct { // RFM RF payload datastructure
int temp;
int temp_external;
int humidity;
int battery;
unsigned long pulsecount;
} Payload;
That’s 12 bytes by my reckoning. We are seeing 8.
Agreed, just wanted the user to acknowledge it and tell us that for sure - I’m with you - this is a very non standard setup!
@gregory
Are you absolutely certain that you have edited and sent us the correct emonhub.conf?
The reason I ask is today, I set up a test using an emonTx and my emonPi. I wrote a sketch for the emonTx that sent exactly the same data that your emonTH’s send, and it sent that from 29 of the 30 NodeID’s available - missing Node 5 because that is the emonPi itself.
I removed all except Node 5 from the emonhub.conf file, and put in the 29 node descriptors for the emonTH.
The log file shows all 29 are treated exactly alike. So at first sight, there is nothing wrong with the way emonHub handles the different nodes.
Hello,
You are cristal clear, as I try to be
I just removed some lines and values to get to the point of sent data values glitches
The goal was to determine what could be wrong: same arduino code, normal values for node 1 to 9 and a ten factor glitch in data from 10 to 22, it could be explained because those nodes are reserved for something else in an architecture with an emon base with base ID 1 and network group 201, that’s all.
Here is the original emonhub.log
I correct the problem with some scales for nodes 10 to 22 with a scale of 1 for each
/ nodes 1 to 9 was with scale of 0.1 for each emonhub.log.zip (64.7 KB)
Yes I remove a member of struct, the pulscount data is irrelevant for me
And I just remove carrefully everything related to it in code
no interrupt on onPulse, no incremental pulse count, cleaning arduino code with success.
as pulsecount is an unsigned long, what you are seeing is right
So i Definitely change the struct of data, but it can’t modfiy other values … 
This emonhub.log.zip (post no.25) relates to this emonhub.conf.zip (post no.27)?
Let me check that everything I think I know is correct:
You have 64 emonTh’s. All are exactly the same.
The emonTH’s have the same sketch, except for the NodeID and Group.
You have 3 emonPis. All are exactly the same.
The emonPis have the same emonhub.conf except for the Group, the baseID and the nodeoffset and the different number of nodes. They receive the data from the emonTh by ISM band radio (433/868 MHz).
The emonPis send the data to an emonBase (“http://surya-monitoring.com”) by Wi-Fi/Ethernet.
The emonBase is where you have emonCMS.
These two files emonhub.log.zip (post no.25) and emonhub.conf.zip (post no.27) belong to the emonPi baseID=1, Group 201
I am as sure as I possibly can be that emonHub does not treat NodeID 1 - 9 differently from nodeID 10 - 30, yet that does appear to be what is happening:
Looking at the first two entries in the log file -
Node 10 is sending the value for temperature as 61 + 1 × 256 = 317, and then scales = 1 and it is sent correctly as 317. [I guess you multiply by 0.1 in emonCMS]
Node 4 is sending the value for temperature also as 61 + 1 × 256 = 317, and then scales = 0.1 and it is sent incorrectly as 317 - it should be 31.7 when you have scales = 0.1
But this is not a documented “feature”, it does not happen with my emonPi and it has never been reported as a fault until now.
The only thing I notice is your emonhub.conf has two digits for the NodeID, whereas we use a single digit for NodeID 1 - 9. Is that the same on the other two emonPis? Can you try delete the leading zero in the NodeID?
This is my last hope for your problem. (scales = 1 is the default, my thinking is "scales = " is not being read and applied.)
Part of the issue I suspect is that each TH appears to be sending data every 100ms.
Are there are 4 different 433MHz RFM receivers in play (3x emonPi 1x emonBase) or is the base, just an emoncms instance?
I still think the way to debug this is to have just one emonTH and one emonPi in play and see what happens.
[[01]]
nodename = emonth01
[[[rx]]]
I think this is it - the Python does a string match not a numerical match IIRC.
What I’ve been doing over the last couple of days suggests that the emonPi needs around 100 ms (quite likely depending on the size of the radio packet) to handle a single incoming radio message.
That depends on what it then does with the data. If you add in an MQTT interfacer, it needs headroom to actually send the data.
Oh and that is one emonth, if all 20 are sending every 100ms…
With the overhead, the 8-byte payload gives you a 17-byte message, at 49200 bits/second, that takes 2.76 ms to transmit and receive, that’s without any processing. Then sending the 30 or so bytes of serial data to the Pi takes 6.25 ms. So it looks as if the Atmel board on its own will take around 10 ms just to process and send a single message.
Normally of course, this is not a problem because temperatures don’t usually change very rapidly, the default reporting rate is once per minute.
In the top post, Gregory wrote:
So I was probably wrong and misled you when I wrote
It’s probably a RPi or a stand-alone server, with no radio (so not an emonBase with a radio).
Thanks for you answer guys
It really help me understand the whole thing
But, have you found the problem - why it seemed to be ignoring the scales =