Brian, just take a step back and take in the overall view. We have a man who has been struggling with following your advice, now you’re suggesting that he gets confused again by doing something he knows was successful once a different way.
I shall repeat myself: I advise him to exactly repeat what he did the first time. We all know it worked.
Thanks dad.
The Inputs are coming through as P1, P2, P3, P4 and E1, E2, E3, E4, along with T1, T2 etc. All good so far, and the values “look about right”.
Previously I used to have processes such as Log to feed, followed by Publish to MQTT, followed by Power to kWh on each ct#. Am I right to think that I would just add a Log to feed on the P1 and add a Power to kWh the on E1 instead of both on each ct# (as above)?
How do I prevent loosing cumulative data if the emonTx gets powered down for any reason?
And one more; and I know this is a bit back to front, but “why” does one need emonSD loaded & running on the Pi Zero at all? I always understood that the ESP8266 was just a “wifi dongle” and that it passed the EmonTx’s messages through effectively unaltered. So in that regard, what does the Pi bring other than comms? 
One of 2 ways.
Note in both of these examples I am scaling the input figure that over reads compared to the meter and multiple logging for testing purposes.
On the Power Input use the Power to kWh process
On the Cumulative Energy Input, the Wh Accumulator (I was testing the kWh Accumulator process and scaling the Input here)
Of the 2, logging the Power is least likely to reset during power off (it should auto correct).
The PiZ brings
for basically the same cost.
You could just install and run emonhub on the PiZ with a RaspberryOS image, but you’d lose the UI to edit the config, update etc.
Job Done! 
Well almost; I now have four EmonTx communicating to my emonPi via Raspberry Pi Zeros; I have recreated the Inputs & Feeds etc, just need to re-build my Dashboards and Apps now.
For future reference, I have attached a “How-To for Dummies” that I have cobbled together, in case it help others if they struggle as much as I do.
In hindsight, I found the process as fascinating as it was frustrating, but I have learnt a lot in the process. Words like sketch, Arduino, avrdude and miniterm are now familiar, even if what they do isn’t always …
2020-10-22 emonTx - Raspberry Pi Zero W.pdf (3.4 MB)
Once again, Thanks All for your patience !!!
Looks good. I have just noticed on one of the photos, the internal serial breakout (JP3). You could have put a header on that and connected up so no external cable!
Interesting; are the screw terminals effectively the same as the pins next to them (but in a different order)?
1 (5V) > pin #4 (5V)
2 (3.3v) > n/a
3 (GND) > pin #6 (GND)
4 (IRQ1) > pin#???
5 (ADC5) > pin #???
6 (Dig 5) > pin #???
No, only the ones sharing the same designation.
The UART connector is specifically for the programmer, the screw terminals are specifically for I/O, such as the temperature sensor and pulse input.
If you want the nitty-gritty details, take a look at the circuit diagram (ideally, you need to download and install Eagle CAD (free for personal use with the size of PCB we use) then you can see the same track highlighted on the pcb and on the circuit diagram.
I think they are but I was thinking of this
@haffle, @Robert.Wall, I think I have worked out why the writing of the firmware from the RPi directly didn’t work. The utility is using Python not Python3.
Interesting. And I am so pleased to learn that it was probably not all down to my ineptitude causing that grief the other week
Hmm, first drop out, despite the Pi Zero still being accessible via the IP address. Looking back at a Feed graph it must have gone wrong on Sunday.
Can one learn anything from this emonHub log? What might be the solution?
TIA
2020-11-03 04:35:34,878 WARNING MainThread SerialTx thread is dead.
2020-11-03 04:35:34,880 WARNING MainThread Attempting to restart thread SerialTx (thread has been restarted 1515 times...)
2020-11-03 04:35:34,892 INFO MainThread Creating EmonHubTx3eInterfacer 'SerialTx'
2020-11-03 04:35:34,897 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 115200 bits/s
2020-11-03 04:35:34,911 DEBUG MainThread Setting MQTT timestamped: True
2020-11-03 04:35:35,866 WARNING SerialTx Exception caught in SerialTx thread. Traceback (most recent call last):
File "/opt/openenergymonitor/emonhub/src/emonhub_interfacer.py", line 32, in wrapper
return func(*args)
File "/opt/openenergymonitor/emonhub/src/emonhub_interfacer.py", line 99, in run
rxc = self.read()
File "/opt/openenergymonitor/emonhub/src/interfacers/EmonHubTx3eInterfacer.py", line 46, in read
self._rx_buf = self._rx_buf + self._ser.readline().decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc2 in position 19: invalid continuation byte
This is a problem with the Serial data from the emonTX.
It could be dying and trying to restart repeatedly.
Try resetting the EmonTX as a starting point I suggest.
@bwduncan, could this exception be handled more gracefully (error in log and discard frame)?
Thanks @borpin ; pressing the Reset button didn’t kick the Inputs in to life, so I powered the Pi Zero down through the EmonCMS / Admin page, waited a bit then powered both bits down and back on again. But that too has not cleared it.
There is always a chance that it is a physical issue - jumper lead coming dislodged etc, but that seems unlikely as the unit is screwed on to a purlin high up in a rodent / bird / cat free barn in close proximity to an Apple Airport Express.
You can see from the emonhub log, the issue is the serial connection between the EmonTX and the Pi.
You need to look at the emonhub log and see what it is telling you.
Not sure how relevant this is, but here’s some info on that particular error:
What data are you referring to, exactly?
As far as I can tell, the emonTx sends to the serial port nothing outside the range [0x0a, 0x0d, 0x20-0x7f] and I think those characters lie wholly within the utf-8 character set.
If the baud rate has become wrong for an unknown reason, then I cannot predict how characters within the utf-8 set will be interpreted, but it’s feasible that the result of a wrongly interpreted character could well fall outside the utf-8 character set.
Although that may be, something is afoot. Otherwise, there’d be no error, or a different error.