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));
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.
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”
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.
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.
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.
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