emonTXv3 creates 13 key in input

Hi,

I'm new to the openEngergymonitor and trying to setup my first home installation. With my first emonTXv3 initial setup worked well, however I do get in the "Inputs" 13 key's. In other posts and in the setup guide there are always fewer keys. (I just turned on the emonTX, no sensors connected, usb powered)

Key 13, I assume, seems to be the signalStrength, as it's value is comparable to the emonTH which have this additional key as well.

How do I figure out which inputs are used for what?

Thanks
Alexander

Robert Wall's picture

Re: emonTXv3 creates 13 key in input

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.

astoklas's picture

Re: emonTXv3 creates 13 key in input

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

 

 

pb66's picture

Re: emonTXv3 creates 13 key in input

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

astoklas's picture

Re: emonTXv3 creates 13 key in input

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.

pb66's picture

Re: emonTXv3 creates 13 key in input

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

astoklas's picture

Re: emonTXv3 creates 13 key in input

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.

pb66's picture

Re: emonTXv3 creates 13 key in input

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

 

astoklas's picture

Re: emonTXv3 creates 13 key in input

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

Ian Davies's picture

Re: emonTXv3 creates 13 key in input

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

pb66's picture

Re: emonTXv3 creates 13 key in input

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.