Emonhub interfacer for 'new' emontx serial format

Hardware emonTx
1

I have seen various articles about direct connection of emonpi to emontx3 using the uart connector on the emontx.

It seems that the format of the messages sent on that port has changed to be compatible with EmonEsp.

I cannot see examples in the emonhub files of an interfacer to read those messages.

Has someone developed an interfacer for emonhub that reads the new format messages from emontx3.

Owen

2

The ‘standard’ serial output of the emonTx never worked with emonHub. The emonhub serial interfacer requires data in the format: ``NODEID VAR1 VAR2 VAR3

It’s easy enough to generate that serial output using the following in the emonTx sketch:

Serial.print((int)(realPower1)); Serial.print(' ');   // These for compatibility, but whatever you need if emonHub is configured to suit.
Serial.print((int)(realPower2)); Serial.print(' ');
Serial.print((int)(realPower3)); Serial.print(' ');
Serial.print((int)(realPower4)); Serial.print(' ');
Serial.print((int)(Vrms*100));

If using direct serial most users would want to use the emonTx direct serial sketch which has the RFM disabled.

No, not yet. but that’s a good idea! Fancy having a go? :slight_smile:

The new emonESP compatible format is

name:value name:value

e.g.

ct1:100 ct2:234 temp1:23

3

Ok Glyn… I might try that.

I am a Python novice… but it looks like copying the serial interfacer and parsing the record like this might work:

#!/usr/bin/python3

rec="ct1:100,ct2:234,temp1:23\r\n"

if '\r\n' not in rec:
  exit #return

# Remove CR,LF
f=rec[:-2]

payload=''

if f.startswith('ct1:'):
  for item in f.split(',')[:]:
    kv=item.split(':')
    payload+=' '+kv[1]

print(payload[1:])

then supply that payload to the cargo fn???

4

Well… I have added an interfacer module but having problems understanding just what needs to be supplied from the interfacer module’s read method. I see a cargo object, and it looks like I should stuff the raw record (a string) into that, but I don’t understand just want it expects in the .realdata part… is it a list of bytes with the binary encoded values stuffed in them (like you would read from a binary encoded input record from some source) or can I pass it a list of the numeric values from the rawdata? Maybe I missed some documentation somewhere?

Passing the values as a list of values as strings gets me this:

2017-03-15 17:27:18,358 DEBUG SerialTx3e 9 NEW FRAME : ct1:0,ct2:0,ct3:0,ct4:0,vrms:23958,pulse:18,t0:225
2017-03-15 17:27:18,361 WARNING SerialTx3e 9 Discarded RX frame ‘non-numerical content’ : 0 0 0 0 23958 18 225:

I have also tried passing a list of numeric values.

I think I am trying to unpack something that is not packed binary.
Owen

5

I think I have it working.

I had to write a _process_rx fn that did not try to unpack the data that was not packed binary to start with.

I will let it run for a while and see what happens.

The config is a RS485 link from the emontx3 to the RPi. At 115k, this should work over a quite long cable. Both feeds are working at the moment (radio and wire). I will dig around for an SMA load to see if that disables the RF path.

Owen

1 Like
6

I set out wanting to use a wired connection from the emonTx3 to the emonhub host, preferably using RS485.

This working reliably and the solution is described at EmonTx3 v3.4 ‘wired’ implementation.

The article has links to forked repos with the relevant code.

Owen

7

Wow, good effort and nice write up :slight_smile:

Would it be possible to create a copy and rename your version of the serial interfacer for the new version to be something like ‘serial-direct-feed-value’ so we don’t break backwards compatibility with users using the old direct serial format. If you then create a pull request to openenergymonitor/emonhub I will test and merge into master emonhub.

8

Thanks Glyn.

I hand installed emonhub to a Ubuntu server that runs 24/7, and am feeding it from the emonTx3 via RS485. The RS485 serial link works just fine (as I expected, I am not new to this, and experienced enough to not make claims until actually tested).

I have submitted PRs as requested.

Owen

9

Ok, the changes are now in the production repository.

The wired solution is described at EmonTx3 v3.4 ‘wired’ implementation.

I expect this is what you will want to do for a direct wired connection to a RPi as documented in the Wiki.

10

Sorry I haven’t been about much to give you any pointers on this but FYI

“rawdata” is just that, the raw un-processed data as recieved, often in byte values from the RFM but can be full values from the serial or scket interfacers, this is kept/logged for debugging. “realdata” is the result of the processing and should contain real values, unpacked and scaled, when the incoming data is already real values and do not require any scaling then these 2 arrays will usually be the same.

This isn’t needed, the code is written so that passing a data code of “0” bypasses all the unpacking

Taking a look at your code you should have inherited from the EmonHubSerialInterfacer rather than from the EmonHubInterfacer directly, that way you would not have hae to repeat the code for connecting to the serial port and all you needed to do was over-write the reading/parsing of the serial data and add your settings much like the EmonHubJeeInterfacer’s relationship with the EmonHubSerialInterfacer.

A couple of minor points
Since this is aimed specifically at the emonTxv3 with the latest serial output the serial baud is only ever likely to be 115200, so initialising the interfacer with a default setting of 9600 and then setting it to 115200 in the settings seems unnecessary, initialize it at 115200 and the setting becomes redundant and is only needed if the device has a baud that isn’t 115200.
In your example settings (conf file) you have all the redundant emonPi settings left which will not do anything and may just cause some confusion.
Plus you seem to have used

nodeoffset=14
baseid = 14                             # emonPi / emonBase nodeID

If both are used that would give you a node id of 28, I suspect you are just using the nodeoffset to set a node id from scratch and the “baseid” is redundant (I haven’t checked the code though, just guessing).

So the interfacer code could have been much shorter, pretty much just a custom read() not far off your suggested parsing code above with just it’s own _init_(), But well done for doing it without any pointers, hope the comments help any future devs.

11

Hi,

Well I spent too much time searching for explanations, sought advice here, and we have what we have. Someone else can rework it if needed.

I did not see datacode 0 documented, and didn’t pick it up in the code.

The basid is redundant in this interfacer, it in fact does not affect this interfacer (which was derived from the serial interfacer). I should have removed it from the conf file since it was not doing anything.

I went down this path intially guided by the Wiki which showed a direct serial connection to the Pi. Whilst I did not test it, it is not signicantly different to what I have done with RS485 interposed, I expect that the scheme in the Wiki would not work with the ESP format stream from the 'Tx3.

It is under reliability trial to see if CRC checksum is warranted.

I have investigated gaps in the online graphs… but the data is in the exports so there is something subtle there about interval timing I don’t understand. The graphs on a local emoncms do not have this defect.

Owen