It looks as if you put it in the wrong place, you should not have any spaces in the string for the ESP format. If you look at all the other variables and their print statements that make up the string, the format I gave you is exactly the same.
I can’t help you any more with the interfacer, I don’t know the inner workings and I’ve never found where it is properly documented.
I think that is the wrong interfacer (the text string is in the wrong format - it expects the format I mentioned above). Not sure what the right interfacer is though.
[edit]
It may be this one (you do need spaces)
If that’s the case, then you need to do much the same in the
#if defined SERIALOUT && !defined EMONESP
section, copying the format of the lines around it. There’s no need to remove it from the unused sections - they don’t even get compiled. (That’s what the #ifdef ... does.)
As I understand it:
The “normal data” output (from the radio) is a byte stream that needs a Node Definition in emonhub.conf to tell emonhub how to parse out the values, scale them, and their names in order to pass this on to emoncms.
The “normal” serial output (“SERIALOUT”) is space-separated integer values only without their names, thus you need a Node Definition in emonhub.conf to scale the values and tell emoncms what the names of the variables are.
The “key:value pairs” serial output (“EMONESP”) is comma-separated pairs of the variable name and value separated by a colon. The values can be floating-point values and no Node Definition is therefore required.
If I get time later, I’ll try to run a definitive test to check the accuracy of the above.
Hi @Robert.Wall and @borpin Thank you again for your help with this. I now have values coming through emonhub per the screen shot below:
I’ll create a post shortly that details the steps I went through to get this working. Hopefully it will make sense for the next person to use.
Please see steps below to enable emonTx 3P to RPi4 over serial using the emonTx_3Phase_PLL sketch. Thank you to @Robert.Wall and @borpin for your help with this.
The sketch has been edited to include a sum of the 3 phases to pull through a single kWh figure (sumPower).
I have edited the sketch as follows:
edited the emonhub.conf node decoder:
[[17]]
nodename = emonTx_three_phase17
firmware = three_phase
hardware = emonTx V3.2/V3.4/Shield
[[[rx]]]
names = power1, power2, power3, power4, sumPower, Vrms, temp1, temp2, temp3, temp4,
temp5, temp6, pulsecount
datacode = 0
scales = 1,1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
units = W,W,W,W,W,V,C,C,C,C,C,C,p
changed ‘//Output Settings’ on row 82 to ‘SERIALOUT’
added ‘sumPower’ to row 300
added the following below row 838:
emontx.sumPower=(int)(realPower1+realPower2+realPower3+realPower4+0.5);
added the following below row 930:
Serial.print((int)(realPower1+realPower2+realPower3+realPower4+0.5)); Serial.print(F(" "));
In emonhub I added the following interfacer:
[[SerialTx3e]]
Type = EmonHubSerialInterfacer
[[[init_settings]]]
com_port = /dev/ttyAMA0
com_baud = 9600
[[[runtimesettings]]]
pubchannels = ToEmonCMS,
I finally added the the node below:
[[99]]
nodename = my-serial-device
[[[rx]]]
names = power1, power2, power3, power4, sumPower, vrms
datacode = 0
scale = 1
units =W,W,W,W,W,V
The emonTx is connected to the RPi4 over serial per the diagram here:
Direct connection emonTx V3 > Raspberry Pi GPIO
The RPi4 is powered using a USB-C PSU and is connected via Ethernet. The emonTx is powered by the 9V AC PSU.
I have also connected a RPiZero W to the emonTx using the jump leads per the diagram above. The RPiZero W is powered directly by the emonTx, with the emonTx being powered by the 9V AC and the 5V USB DC PSUs. I added wifi to the SD card before putting it in the RPiZero W
Thanks rdc-Green (and Robert and Brian) for the info on configuring the three phase sketch with direct serial connection to a rpi running emoncms. As a first time user of this equipment (but some experience with other Arduino and RPi projects), the documentation available for this process seems quite scattered across countless pages and forum posts with possibly crucial details missing. There is also a lot of conflicting info relating to ostensibly similar configurations which makes it more confusing than it probably needs to be. Can I suggest a definitive step-by-step guide be included somewhere as a Guide or on the Learn section of the website? Once I get this sorted I’ll be writing it up for my own purposes (memory like a sieve) so happy to contribute…
From lots of reading on the forums, guides and docs etc I formed the interpretation that the EmonHubSerialInterfacer [SerialDirect] was an older/less ideal/supported method than the EmonHubTx3eInterfacer [SerialTx3e] (eg: @glyn.hudson Direct connection emonTx V3 3-phase to RaspberryPi - #11 by glyn.hudson). There’s another explanation of the difference between the two by either @glyn.hudson or @TrystanLea somewhere (that currently I can’t find across the 64,000 OEM browser tabs I currently have open…) which I think suggests that for the current emonTx/firmware we should really go with the [SerialTx3e] option.
rdc-Green - it looks like you’ve just kept the [SerialTx3e] title for the interfacer but changed it to match the [SerialDirect] way of doing it…?
I too cannot get EmonCMS to receive any Input from the [SerialTx3e] interfacer over /dev/ttyAMA0, but it is received just fine in the EmonHub log. I’d like to make sure I set this up in the most optimal way - is there any downside to reverting to the [SerialDirect] interfacer instead of sticking with [SerialTx3e]?
My setup is functionally identical to the one described by rdc-Green.
(As a new user I’m only allowed to 'mention two users in a message - hope all the relevant people see this anyway…)
Many thanks!
I’ve cured that for you.
The problem I think is there’s a great reluctance to mark data as “obsolete”, and an equal reluctance to fully and properly document anything added, so it’s really hard to steer people like you to the correct, up-to-date information.
The 3-phase sketch actually contains all three output formats I mentioned above https://community.openenergymonitor.org/t/re-rs485-and-other-sensor-cabling/17676/2 - you choose the one that suits your needs. (I’ve yet to run those tests - I can’t find my jumper wires and had to order some more.)
Thanks Robert!
The EmonCMS code is the one area I haven’t looked at (that seems like a rabbithole best avoided given my available time at present!), so I have no idea why the [SerialTx3e] interfacer does not work as it apparently(?) should in this application. I’ve been through the three phase sketch you wrote Robert and whilst it would probably have taken me a thousand years to write I do understand most of it (I think)…
Just noticed in the emonhub log that it claims to be receiving the [SerialTx3e] data from “Node : 0”, despite the fact that the EEPROM and firmware Node are both set to 11… what’s that all about?
2021-05-04 16:37:56,225 DEBUG SerialTx3e 1363 NEW FRAME : ct1:7.74,ct2:-0.36,ct3:-0.12,ct4:0.00,vrms:250.29,t1:300.00,t2:300.00,t3:300.00,t4:300.00,t5:300.00,t6:300.00,pulses:1
2021-05-04 16:37:56,227 DEBUG SerialTx3e 1363 Timestamp : 1620142676.2238631
2021-05-04 16:37:56,240 DEBUG SerialTx3e 1363 From Node : 0
2021-05-04 16:37:56,242 DEBUG SerialTx3e 1363 Values : [7.74, -0.36, -0.12, 0, 250.29, 300, 300, 300, 300, 300, 300, 1]
2021-05-04 16:37:56,244 DEBUG SerialTx3e 1363 Sent to channel(start)’ : ToEmonCMS
2021-05-04 16:37:56,245 DEBUG SerialTx3e 1363 Sent to channel(end)’ : ToEmonCMS
Also the CT1 output there is (consistently) garbage - all three CTs are currently clipped around the same wire with zero load attached… when I change the sketch to SERIALPRINT output and look at the Arduino IDE serial monitor it gives the correct output for CT1, so why is the EMONESP output going haywire… am I missing something obvious here?
That’s because it doesn’t send the NodeID. So you need an extra line in emonhub.conf to give it a node number - or write a definition for Node 0. Just don’t ask me to explain why.
I want to go and cook my tea, meantime here’s my cryptic crib that might explain a little:
EmonESP
also
NodeOffset: So when the emonhub interfacer was written for that emonESP format serial output with no node id (aka node id is None) we could use the nodeoffset to add a “offset” to that absent node id ie your node is currently 0 offset by 1 = 1. So using nodeoffset is how you define the node id for each emonTx using the (emonesp format) serial output.
Under this section
[[RFM2Pi]]
Type = EmonHubJeeInterfacer
you need to add under runtimesettings
[[[runtimesettings]]]
nodeoffset = 17
An offset of 0 (default) + 17 = 17.
Thanks Robert - Bon appetit!
I’ve commented out the whole [[RFM2Pi]] section (in frustration) as I’m only using a direct serial wired connection… did you mean to correct this node offset under the [[SerialTx3e]] section or do I still need the [[RFM2Pi]] section even if I don’t want to use the radio at all?
When I change the node offset in the [[SerialTx3e]] runtimesettings I now get the following log entries (which I’m sure has a bleedingly obvious cause but by now I’ve gone completely cross-eyed):
2021-05-04 18:18:39,871 DEBUG SerialTx3e 1 NEW FRAME : ct1:6.40,ct2:-0.99,ct3:0.24,ct4:0.00,vrms:248.74,t1:300.00,t2:300.00,t3:300.00,t4:300.00,t5:300.00,t6:300.00,pulses:1
2021-05-04 18:18:39,875 WARNING SerialTx3e 1 RX data length: 12 is not valid for datacodes [‘h’, ‘h’, ‘h’, ‘h’, ‘h’, ‘h’, ‘h’, ‘h’, ‘h’, ‘h’, ‘h’, ‘L’]
Is this a complete waste of time? Is there any advantage to trying to use [SerialTx3e] vs [SerialDirect] interfacer for wired serial connection to a locally hosted emoncms?
The “3e” interfacer is (as I understand it, but remember, documenting stuff isn’t “cool”) specifically for the ESP8266 WiFi adapter, the correct one to use for a direct wired connection is the “SerialDirect”.
The error
… is not valid for datacodes … is when the received data does not match the specification for that NodeID in emonhub.conf.
So when you changed the node offset, you also needed to make sure that there was a specification that matched with the new (+offset) NodeID. (And there must only ever be one specification with that NodeID.)
Bane of my entire life…
I bought this kit for a client thinking it would save him some money over a commercial closed-source product… it will - but it has cost me a small fortune in unbillable hours due to documentation apparently being uncool. I saw the size of the community, the website and repositories and thought setting one of these up couldn’t possibly be that hard…
I used the existing three phase node [[11]] included in emonhub.conf, which appears to have the same data format as the sketch outputs (other than the first data field spat out by the sketch is the actual node ID), so I’m none the wiser as to why this error appears?
I gave up and went back to the [SerialDirect] interfacer and after getting a similar error realised that changing “datacodes” to “0” also requires changing the word “datacodes” from plural to singular!! 
Now I get no errors in the emonhub log but still no inputs in emoncms…?
I got the prewritten SD card from the shop and I already have a whole bunch of null inputs populated - will the correct ones magically appear by themselves or is there another (undocumented) step?
Ok - I played around with the example links on the page reached from the “Input API Help” button at the top of the inputs page… I didn’t expect I’d need to write JSON queries to get the GUI to work! I assumed I could configure the GUI via the GUI itself! Am I missing something here?
I feel your pain, I have helped many users over the years in exactly the same position as you, it is indeed frustrating (to put it mildly).
I assume you originally compiled the 3phase firmware to output the “emonesp format” of named pairs? Having switched back to the serial-direct method have you recompiled the firmware with the serial-direct output selected?
Without a shadow of a doubt, if anyone was compiling emonTx FW for a direct serial connection I would always recommend using the serial-direct method. It was built for the purpose, has always worked perfectly and was only “superseded” to regain serial comms between emonhub and emonTx’s after the emontx serial output was changed to suit just the emonesp without any consideration for emonhub or any other uses. It’s a “fix” for a problem rather than an ideal solution.
If you were using a default emonTx, out of the box, the tx3e interfacer will save you changing the FW. If you are changing the FW anyway, you should use the serial direct method. it’s simpler and purpose built. So now, if you have compiled the FW for the emonESP format you need to choose whether to follow the “fix” and revert to the tx3e interfacer or recompile to use the serial-direct method that does what it says on the tin.
“datacode” and “datacodes” are 2 differing ways of defining a payload. the singular means any number of that one data type only, whilst the plural means each datacode needs to be defined specifically. So you could indeed use datacode = 0 as you have, or you could have used datacodes = 0,0,0 . . . where the number of zeros equals the number of values in your payload. The former is useful for payloads that can change in length (number of values) whilst the latter is more secure (aka fussy) as it will only pass payloads that match the string of datacodes, no more, no less, everything that “doesn’t fit” gets rejected.
Yup, I’m guessing that’s just poor housekeeping prior to releasing the image.
Can you post some emonhub.log showing the serial data passing through? include some mqtt or http sends too please.
[edit]
No, you should not need to do anything, the inputs should just appear. I just don’t know exactly where your at now and would rather find out and advise accordingly than give you all the possibilities (and the why and wherefores) as I’m sure you are getting bogged down with less compatible options.
Surely it’s not that difficult to put together a (reasonably) bulletproof step-by-step guide? Can we not prevent countless others having to go through this crazy process? Surely this situation is bad both for the success of the OEM shop as well as the whole open-source project??
I can’t believe I even suggested to the client that if he had the interest/inclination he could probably just read the website/forums and set it up himself insteading of paying me! 
yes and yes.
Wish I’d seen this recommendation earlier! 
Thank you!!! This is clearly obvious to those in the know and seems logical now that you describe it, but it’s yet another case of the uninitiated trying to push an undocumented button (based on forum recommendations without the background explanation) on a black box (I don’t have the time to read and learn the emoncms source code).
That’s a relief!
I don’t see any http or mqtt sends, but perhaps I was overzealous with commenting out bits of the conf file… (edit: I only commented out the emoncmsorg section not the MQTT section, but there were some lines in the MQTT section already commented out without my interference - eg :
# emonhub/rx/10/values format
# Use with emoncms Nodes module
and
# emon/emontx/power1 format - use with Emoncms MQTT input
# http://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md)
2021-05-04 21:23:11,416 DEBUG SerialDirect 2621 NEW FRAME : 11 0 0 0 0 24722 30000 30000 30000 30000 30000 30000 1
2021-05-04 21:23:11,440 DEBUG SerialDirect 2621 Timestamp : 1620159791.4162369
2021-05-04 21:23:11,448 DEBUG SerialDirect 2621 From Node : 11
2021-05-04 21:23:11,450 DEBUG SerialDirect 2621 Values : [11, 0, 0, 0, 0, 247.22, 300, 300, 300, 300, 300, 30000, 1]
2021-05-04 21:23:11,452 DEBUG SerialDirect 2621 Sent to channel(start)’ : ToEmonCMS
2021-05-04 21:23:11,453 DEBUG SerialDirect 2621 Sent to channel(end)’ : ToEmonCMS
2021-05-04 21:23:14,432 DEBUG SerialDirect 2622 NEW FRAME : 11 0 0 0 0 24723 30000 30000 30000 30000 30000 30000 1
2021-05-04 21:23:14,436 DEBUG SerialDirect 2622 Timestamp : 1620159794.432179
2021-05-04 21:23:14,438 DEBUG SerialDirect 2622 From Node : 11
2021-05-04 21:23:14,440 DEBUG SerialDirect 2622 Values : [11, 0, 0, 0, 0, 247.23000000000002, 300, 300, 300, 300, 300, 30000, 1]
2021-05-04 21:23:14,441 DEBUG SerialDirect 2622 Sent to channel(start)’ : ToEmonCMS
2021-05-04 21:23:14,443 DEBUG SerialDirect 2622 Sent to channel(end)’ : ToEmonCMS
2021-05-04 21:23:17,475 DEBUG SerialDirect 2623 NEW FRAME : 11 0 0 0 0 24720 30000 30000 30000 30000 30000 30000 1
2021-05-04 21:23:17,490 DEBUG SerialDirect 2623 Timestamp : 1620159797.4753528
2021-05-04 21:23:17,491 DEBUG SerialDirect 2623 From Node : 11
2021-05-04 21:23:17,493 DEBUG SerialDirect 2623 Values : [11, 0, 0, 0, 0, 247.20000000000002, 300, 300, 300, 300, 300, 30000, 1]
2021-05-04 21:23:17,495 DEBUG SerialDirect 2623 Sent to channel(start)’ : ToEmonCMS
2021-05-04 21:23:17,496 DEBUG SerialDirect 2623 Sent to channel(end)’ : ToEmonCMS
When I run:
http://192.168.1.7/input/post?node=emontx&fulljson={"power1":100,"power2":200,"power3":300}
I then end up with the corresponding three inputs appearing on the input page… but of course I’d like a bit more than just those three…
I suggested the opposite - a correctly formatted serial string as key:value pair is far simpler - no datacode(s), no definitions or anything else to get wrong.
I don’t think there is inherently anything different between the 2 interfacers except how the received data string is decoded. The TX3 interfacer expects key:value pairs so there is nothing to decode (scale or anything), it is just parsed. In fact, if you wanted to, you could just pass the received string on as the string inherently makes sense. I suggested as much by proposing the EmonTX had a JSON option.
Oh, and just for completeness
you could as a 3rd option (should actually be the very first option) just define nothing! Do not have datacodes or datacode defined at all, the default mode for the serial-direct interfacer is “datacode = 0” so by simply commenting out the datacode(s) line would work just fine! That is how emonhub was intended to work, with minimal settings for the user to need to set and plenty of option should they want/need something else, but the project maintainers have opted for foisting all the (duplicated default) settings on the user in an explicit conf file, hence the confusion when looking at many different forum threads and guides as all the settings are there not just the ones pertinent to the application or feature being discussed.
I would expect nothing less Brian!
That’ll fix it, yet another option to simplify things 
