Archived Forum

Are you looking at the message from your emonTx as bytes? If yes, then the message format is specified in the default emonTx sketch, which you can download from GitHub.

What you're seeing is the nodeID (probably 10) followed by something like this (V3.4)

typedef struct {
int power1, power2, power3, power4, Vrms, temp[MaxOnewire];
int pulseCount;
} PayloadTX;

which is 6 integers if you have no temperature sensors connected, and accounts for your 13 bytes.

Looking at the sketch the struct seems to be updated:

const byte MaxOnewire=             6;                            // +1 since arrya starts at 0. maximum number of DS18B20 one wire sensors

typedef struct {
int power1, power2, power3, power4, Vrms, temp[MaxOnewire];
int pulseCount;
} PayloadTX;     // create structure - a neat way of packaging data for RF comms
  PayloadTX emontx;

So I end up with 12int = 24bytes - it seems that either pulseCount or the one element of temp-array is missing?

At least with the emonhub.conf
[[9]]
datacodes = h, h, h, h, h, h, h,

I get proper feeds (as far as I can tell because I only have 4CTS and 1 Sensor) from the emonhub.log

2015-04-22 22:14:50,299 INFO emonCMS sending: http://xxxxxxx/emoncms//input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1429740890.09,9,46,35,33,40,24708,222,0,0,0,0,0,0,-39]]&sentat=1429740890

Hi Alexander

Can you post some more of the log so we can see a data frame arrive a nd get processed. in the log (when loglevel = DEBUG) the "NEW FRAME" shows the raw values and should then show the node id, decoded values and rssi.

​The nodes section is not required for handling integer only frames so remove that from the equasion by commenting or deleting the [[9]] or [[99]] sections.

Some how there are 12 additional zeros being added to the frame, which are taken to be 6 intergers which gives you 6 valid values 6 rogue zero values and an rssi.

How does the data get to emonHub? do you have an RFM2Pi? does it run the stock firmware?

Has the emonTx sketch been altered in anyway? was it pre-installed ? if not can you link to the sketch you used?

Paul

Paul,
I played around quite a bit - and I just revised me original post as I started to understand better:

I'm running emonTX 3.4 with descrete sampling FW 1.6 (previously 1.5) with RFM69CW 868Mhz.
The RFM2Pi has stock firmware, Pi running emonSD-13-03-15.img.

I think it has to do, that in the latest version of the sketch the number of Temp Sensors have been increased - however the math does not sum up to me yet - missing 2 bytes or an integer.

Only the data is included in the datacodes maths

from the rfm2pi emonhub also receives a node id and an rssi which to not enter into the sums. and to that it adds the unix timestamp.

From the current data above I would expect to see 12 values from the sketch plus the rssi in emoncms

    unixtime, nodeid, power1, power2, power3, power4, Vrms, t1, t2, t3, t4, t5, t6 pulseCount, rssi

​which is indeed a 24byte data frame (12 x 2byte integers) 

Paul

edit or if its the "+1" comment next to the temp sensors that's throwing it out possibly that should be expressed as

    unixtime, nodeid, power1, power2, power3, power4, Vrms, t0, t1, t2, t3, t4, t5, pulseCount, rssi

got it working now: thanks for the DEBUG hint

2015-04-23 08:11:15,807 DEBUG 4 NEW FRAME : 1429776675.81 OK 9 0 0 14 0 1 0 0 0 112 89 215 0 0 0 0 0 0 0 0 0 0 0 0 0 (-48) 
2015-04-23 08:11:15,817 DEBUG 4 Timestamp : 1429776675.81
2015-04-23 08:11:15,820 DEBUG 4      Node : 9
2015-04-23 08:11:15,823 DEBUG 4    Values : [0, 14, 1, 0, 22896, 215, 0, 0, 0, 0, 0, 0]
2015-04-23 08:11:15,827 DEBUG 4      RSSI : -48
2015-04-23 08:11:15,905 DEBUG 4 Append to 'emonCMS' buffer => time: 1429776675.81, data: [9, 0, 14, 1, 0, 22896, 215, 0, 0, 0, 0, 0, 0, -48], ref: 4

I changed the emonhub.conf accrodingly

[[9]]
​        datacodes =  h, h, h, h, h, h, h, h, h, h, h, h,

​however odd is the reading of CT2 (14) while actually no device is drawing power. I think I need to calibrate the system more.

Glad you have it working now,

Just for clarity I would like to explain the default datacode for the [[RFM2Pi]] interfacer is "h" so if it is not overridden in the [[RFM2Pi]][[[runtimesettings]]] or in [nodes] it will assume all incoming data to consist of integer type (ie pairs of bytes). It is only necessary to define datacodes if they differ from the default so if you had not added the [[9]] datacodes line emonHub would of processed the frame correctly..

In [nodes] it is possible to define either a single datacode eg " datacode = L " to process all values (ie undefined count) from that node as longs, or using the plural datacodes eg " datacodes = L, L " to specify explicitly the frames from that node will be exactly 2 longs (8 bytes) no longer no shorter.

Since "h" is the default type, "datacodes = h, h, h, h, h, h, h, h, h, h, h, h," only serves to define the number of values as 12 (24byte) causing emonhub to discard any frames not 24bytes long, this can be useful as a "belt and braces" check to ensure no additional "pairs of bytes" are dropped or added but the elevated checks are also less flexible and therefore less forgiving when not defined absolutely correct or legitimate changes are made, as you discovered.

the value of 14 isn't that odd, some noise will be detected and 14w on a 24Kw range is less than a 0.06% error calibration may well help but not guaranteed. at that level. 

Paul

Paul, thanks for your support and pointing me to the right direction. I do not care to much about the 0.06 Error in general - but would like to have a 0 reading on 0.
I might do this on emoncms be reducing the input by 15 or something like this.

Alexander

Apologies for joining this thread, but I also have the same problem with a new emon TX 3.4 installation, but I haven't delved deeply like the OP. I too am seeing a value on Key 13, which is always negative, and has changed slightly when the emonTX was moved around, so it looks like RSSI. I am also using a Raspberry Pi, running emonbase 3.18.7+ with the RFM69Pi RF Board. I assumed this was just due to a change in the code, and that the RSSI had moved to a new key, but this thread suggests this behaviour was not expected?

If I should have raised this in a new thread, then I will happily do so (still learning the protocols for this forum!)

Cheers

Ian

There is no problem with receiving 13 values via an rfm69, yes the last value is the RSSI. This is added to all frames received by the rfm69 but not a rfm12.

Paul