Serial-Direct connection between Pi and emonTx shield

Actually, very different!

this last line of that first block you included

tells us there is a device /dev/ttyACM0. That is what you need to use in emonhub.conf eg

[[Arduino]]
    type = EmonHubSerialInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyACM0
        com_baud = 9600
    [[[runtime_settings]]]

You may also be able to address them using either

        com_port = /dev/serial/by-id/usb-Arduino_LLC__www.arduino.cc__Genuino_Uno_85535303536351D0A2E0-if00

or

        com_port = /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0

i do not know for sure this would work and would be interested to hear how it goes if you try it. If either of these is unique to your Arduino it might work to distinguish between similar devices too.

A note to point out that the Arduino must output NOTHING except the data that emonHub actually needs.
e.g.

Serial.print(nodeID); Serial.print(’ ‘);
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 (numSensors)

{
for(byte j=0;j<numSensors;j++)
{
Serial.print(’ ');
Serial.print(emontx.temp[j]);
}
}
Serial.print(“\n”);

Hi Robert

Another option worth considering for adapting “RFM” sketched for serial would be to include something like

  Serial.print(nodeId);
  const char* dp = (const char*) &emontx;
  for (int i = 0; i < sizeof(emontx); i++) {
    Serial.print(" ");
    Serial.print(byte(*dp++));
  }
  Serial.println();

this could be added to almost any existing sketch that uses a typedef struct for the RFM packet, serving as a debugging line for RFM as well as a serial output in it’s own right. The output would be in byte values (ascii) so the existing [[nodes]] configurations in emonHub would be reused instead of having to change to “0” datacodes due to the “real values”

I posted in the form that I did so that the format required would be immediately obvious to anybody.

(My guess is @gonczoll’s sketch is sending some or all of the introductory test preamble, which emonHub is choking on. It’s easy to get wrong because while we know what’s required, I can’t remember ever seeing a formal specification of the format.)

Certainly, a fluid and universal format that could be switched in or out as required would get around this problem - hopefully once and for all, and I’d fully support that.
What we really need is a serial output that can detect whether there’s a human or emonHub on the other end! I suppose we could always do “Press any key to continue…” and if it saw a key during the first 5 - 10 s say, send human-friendly output, otherwise send emonHub-compatible serial output.

ditto!

I’m guessing it’s unlikely to happen though due to development of the emonESP.

So, I tried all the possibilities: /dev/ttyACM0, and the other two paths to /dev/serial/by-id and /dev/serial/by-path.
Still no entries in emoncms database
the sketch I’m using is “EmonTx V3 Direct Serial example”

I think the sketch is blameless, so that is a step forward. It will appear as node 10, therefore you need in emonhub.conf:

[[10]]
    nodename = emontxshield
    [[[rx]]]
       names = power1, power2, vrms
       datacode = 0 
       scales = 1,1,1
       units =W,W,V

Note: it sends at 9600 baud. “datacode = 0” was “datacode = h” - see post below.

Can you see any serial activity in emonhub.log?

There are various reasons the data may not be reaching emoncms, can you confirm the data is being processed by emonhub first. There may be some clues as to where it is failing.

If you are using an emonSD image or more specifically MQTT to post to emoncms it will not accept numerical node ids via MQTT, so you will have to create an entry in the [[nodes]] section of emonhub.conf with a nodename= so the node id is replaced with a text name before publishing to MQTT. You may even need to reboot the emonPi for any newly created nodes to get recognized due to an issue with the MQTT inputs of emoncms.

First things first before taking wild guesses at what might be, can you please post some emonhub.log so we can see what IS going on.

Unfortunately that won’t work as the data is being sent as human readable values, so they do not need decoding, so datacodes = 0,0,0 or datacode = 0 is required rather than datacode = h.

no, nothing.
emonhub.log is empty. :frowning:

That isn’t possible if emohub is running!

?
Am I checking the right file?

/var/log/emonhub/emonhub.log

Yes, I believes so, how are you checking it?

When you are debugging the best thing to do by far is to have a second ssh window open and run tail -f /var/log/emonhub/emonhub.log and just leave it open while you work in another window.

Ouch sorry - I missed that (my cat was on my lap, I was struggling).

No, I do have only one ssh-window open - untill now. (I’m not an expert, I expected they will disturb each other. :slight_smile: )
But still no entries in

/var/log/emonhub/emonhub.log

:frowning:

and in emoncms db.

Are you saying there are no entries you consider valid or are you saying “emonhub.log is empty”? Is the loglevel set to DEBUG in emonhub.conf?

Try this, stop emonhub with sudo service emonhub stop. And then open (or reset) a second ssh window and issue the sudo tail -f /var/log/emonhub/emonhub.log command you should see around 10 log lines and then stop. Restart emonhub in the first window with sudo emonhub service start. At which point the logging should start again in the 2nd window with something like “opening emonhub” and give the version number etc, it will then go through some setting up, printing the progress as it goes.

In those logs we should see emonHub try to create the serial connection and the messages there (or lack of) should tells us what is happening, if the set up is successful it will pass each new data frame as it arrives and it should inform us of any issues.

Once restarted, let it run for 30 secs and then stop the logging window with ctrl-c and then copy and paste the whole log, into a post here on the forum between 2 sets of 3 backticks eg

_paste log file here_

You can also include your whole emonhub.conf the same way, but hide any apikeys or private urls etc.

PS to cut and paste from a ssh window you only need to select the text and then switch windows and paste, selected text is effectively already copied when selected.

Nothing in the log. Emonhub seems not running.
Loglevel is set to DEBUG

emonhub_conf.txt (1.8 KB)
here is the current config file.

Changed the sketch using this example
extended with node ID and print out of that, but left all 4 ct entries. ct1 is network income, ct3 is PV-income. #4 seems to be damaged, because there is nothing connected to it, however it shows something. I use #3 for PV because on #2 there were unreliable values earlier.
there is a beuatiful sunny day in Budapest,so I’m feeding back to the NW. (showing on CT1 with a negative value)
Serial sample outputs:
I guess the outputs are OK: space separated, beginning with nodeID, CT#1, #2, #3, #4, and RMS Voltage (FromAC-AC-adapter)
10 -1107.59 0.00 1386.02 7.21 245.31
10 -1132.23 0.00 1404.65 5.75 245.25
10 -1128.49 0.00 1402.92 4.06 246.39
10 -1141.25 0.00 1425.59 6.80 246.53
10 -1150.84 0.00 1428.49 5.71 245.31
10 -1137.80 0.00 1412.86 5.06 245.66
10 -1263.21 0.00 1432.17 6.40 245.73
10 -1271.11 0.00 1428.38 4.46 246.67
10 -1259.58 0.00 1428.90 6.76 245.61
10 -1237.21 0.00 1413.12 4.62 245.37
10 -1249.53 0.00 1413.86 7.45 245.57
10 -1251.72 0.00 1412.77 5.19 245.49
10 -1250.95 0.00 1416.72 5.06 245.74
10 -1246.85 0.00 1418.02 4.72 245.90
10 -1236.36 0.00 1416.29 1.99 245.73
10 -1245.77 0.00 1398.39 5.28 245.87
10 -1233.07 0.00 1403.49 5.16 245.80
10 -1226.56 0.00 1397.82 5.60 245.86

Do I need a separate power for the Arduino/TXshield combo?
They are powered now by USB from the RPI.