OpenEnergyMonitor Community

Avoiding wireless connections - EmonTX serial RPiZero solution

Idling, a Pi Zero draws 50 to 70 mA, which is right at the max spec’d value of an emonTx power supply. During startup, the Zero draws 120-140 mA. Can’t be good in either case, especially the second one.

Ref: EmonTx V3.4 - OpenEnergyMonitor Wiki
Important note regarding powering with AC: powering via AC is recommended only for standard emonTx operation without auxiliary sensors (apart from a maximum of 4 DS18B20 temperature sensors) or equipment (e.g. relay modules) connected. Correct operation via the AC supply is critically dependent upon using the correct AC-AC adapter. If you are using the recommended AC-AC adapter and the current draw exceeds 10 mA and the mains supply is below the minimum allowable, then circuit operation will be impaired, adversely affecting the accuracy of the emonTx. To avoid damage to the emonTx V3 circuits, the current drawn from the AC circuit should never exceed 60mA

Additional info:

Two things, probably related. Hostnames cannot contain an underscore! Letters, digits and minus signs only.

Secondly the error refers to a different hostname, which accounts for why it can’t find it. Most likely the hostname it is using is the result of stripping out the illegal characers, which then doesn’t match the original. Alternatively, you have the legal form stored somewhere else.

Either way, fix your hostname to be the legal form and try again.

1 Like

I think you’re thinking of when just an AC:AC is used to power the emontx, Julian has stated he is using a 5V 2A AC:DC in addition to the 9V AC:AC. I expect the PiZ is taking 5V from the FTDI port and that is direct from the 5V rail of the emonTx, ie direct from the 2A PSU.

Julian, you have many occurrences of this

which the 1st line is correct as “Settings:” is indeed not numeric. Why you are getting that instead of numeric values I do not know, what firmware are you running on the emonTx?

If there is text or rather symbols like that arriving unexpectedly, that may explain the UnicodeDecodeError: 'utf-8' codec can't decode byte errors if something out of the usual is arriving.

Can you try disconnecting the Tx-Tx line if you have one and haven’t already disconnected it? Just in case emonhub is triggering a “settings” response from the emonTx somehow.

Yep. Your’re right, and he did.

That said, the point I should’ve made is:
(also from the wiki article)
If more than 10 mA of current is required, it is recommended to remove jumper 2 (JP2) and power the emonTx via the 5V mini-USB connector. When JP2 is removed, the AC-AC adapter (if connected) will be used only to provide an AC voltage sample, i.e. it will not power the emonTx.

1 Like

Coming back on several points …

  1. Removing the 5V & GND wires between the emonTx & the Pi Zero’s header, and powering the Pi via a 5V 1A power brick didn’t solve the problem (but will leave it this way until I can find a better brick, as the PiZ specs say 1.2A is “recommended”)

  2. I have changed the hostname from emonTx_PiZero_1 to emontxpizero1 & rebooted both the Pi and emonHub on the emonTx.

  3. The emonTx is running

Administration | App v2.2.3 | Backup v2.2.4 | EmonHub Config v2.0.5 | Dashboard v2.0.9 | DemandShaper v2.1.2 | Device v2.0.7 | EventProcesses | Feed | Graph v2.0.9 | Input | Postprocess v2.1.4 | CoreProcess | Schedule | Network Setup v1.0.0 | sync | Time | User | Visualisation | WiFi v2.0.3
  1. I have removed the Tx > Tx wire and rebooted both devices, and still nothing coming through to the emonPi. This is the emonHub log from the emonTx.
2020-11-10 16:45:38,344 DEBUG    MainThread Setting MQTT timestamped: True
2020-11-10 16:45:38,346 DEBUG    MainThread Setting MQTT subchannels: ['ToEmonCMS']
2020-11-10 16:45:38,348 INFO     MainThread Setting MQTT node_JSON_enable: 1
2020-11-10 16:45:38,361 INFO     MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2020-11-10 16:45:38,364 DEBUG    MainThread Setting emoncmsorg pubchannels: ['ToRFM12']
2020-11-10 16:45:38,366 DEBUG    MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2020-11-10 16:45:38,368 WARNING  MainThread Setting emoncmsorg apikey: obscured
2020-11-10 16:45:38,370 INFO     MainThread Setting emoncmsorg url:
2020-11-10 16:45:38,382 INFO     MainThread Setting emoncmsorg senddata: 1
2020-11-10 16:45:38,389 INFO     MainThread Setting emoncmsorg sendstatus: 1
2020-11-10 16:47:15,460 DEBUG    MainThread Signal 15 received.
2020-11-10 16:47:15,517 INFO     MainThread Exiting hub...
2020-11-10 16:47:15,729 INFO     MainThread Exit completed
2020-11-10 17:00:28,671 INFO     MainThread EmonHub emonHub (emon-pi variant) v2.1.5
2020-11-10 17:00:28,684 INFO     MainThread Opening hub...
2020-11-10 17:00:28,687 INFO     MainThread Logging level set to DEBUG
2020-11-10 17:00:28,689 INFO     MainThread Creating EmonHubTx3eInterfacer 'SerialTx'
2020-11-10 17:00:28,714 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 115200 bits/s
2020-11-10 17:00:28,719 INFO     MainThread Creating EmonHubMqttInterfacer 'MQTT'
2020-11-10 17:00:28,735 DEBUG    MainThread Setting MQTT timestamped: True
2020-11-10 17:00:28,737 DEBUG    MainThread Setting MQTT subchannels: ['ToEmonCMS']
2020-11-10 17:00:28,739 INFO     MainThread Setting MQTT node_JSON_enable: 1
2020-11-10 17:00:28,748 INFO     MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2020-11-10 17:00:28,751 DEBUG    MainThread Setting emoncmsorg pubchannels: ['ToRFM12']
2020-11-10 17:00:28,762 DEBUG    MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2020-11-10 17:00:28,764 WARNING  MainThread Setting emoncmsorg apikey: obscured
2020-11-10 17:00:28,766 INFO     MainThread Setting emoncmsorg url:
2020-11-10 17:00:28,768 INFO     MainThread Setting emoncmsorg senddata: 1
2020-11-10 17:00:28,770 INFO     MainThread Setting emoncmsorg sendstatus: 1


But more importantly you no longer have the “settings:” values coming through, nor the UnicodeDecodeError: and if you had the emonLCD service running the hostname error would probably be ok now too. So progress is being made.

What firmware are you running on the emonTx?

Are you familiar with Miniterm?

If so, you could stop the emonhub service and access the emontx via miniterm to see what is going on there. Say if you need more detailed steps.

@Robert.Wall might recognise the “settings:” text perhaps? I do not I’m afraid.

That might well be an emonTx running Trystan’s CM sketch - but I don’t know where “time” has come from, that’s definitely not coming from a sketch that I recognise. If the Pi Zero has added it, then it’s probably OK. Unlike the r.f. packet, the serial output only sends values for the items in use, so it’s really not all that helpful.

I’m afraid that with everything else I’m doing for OEM behind the scenes, I’ve lost track of the original problem.

That, because of the misleading labelling on the emonTx, means that it won’t receive and react to any incoming serial data. Which might be a good thing if that data is valid but not good calibration data.

If the emonTx sends values that are zero (as distinct from no values), it might be a symptom of the calibration having been corrupted. It would send no current and energy values, but it would send the message number and the voltage, even if that were exactly zero.

Beware though, the corruption (if there is corruption) could have happened before that wire was removed.

Disconnecting the 5V wire and running the Zero via a separate power supply isn’t a bad idea, but…
I’d recommend leaving the GND connected between the two devices. Bonding devices together to
ensure a common reference point keeps weird things from happening to signal levels.

1 Like

No that’s the emoncms modules, the firmware is installed on the emonTx itself and may only be identifiable by using miniterm wilst the emonTx is connected to the zero or using a usb programmer (if you have one) on another PC.

On power-up, and if you have an appropriate monitoring device - as Paul says a programmer and the Arduino IDE on a PC or miniterm and the Pi Zero - connected to the FTDI serial port, the emonTx should display this message or one similar:

emonTx V3.4 EmonLibCM Continuous Monitoring V1.9
Node: 15 Freq: 433MHz Group: 210
NO CT's detected

alternatively as appropriate

CT1 detected, i1Cal:90.91
CT2 detected, i2Cal:90.91


Yes the time:timestamp is added by emonhub, the mqtt interfacer does it if the json format output is selected.

The bit I don’t get is the

It clearly shows a payload of “settings:” being received and I cannot find that printed from the DS sketch and in the CM sketch it is the first line of the list_calibration function, but since I can see no way in the sketch to set the verbose bool true it would seem that the list_calibration can only be triggered by a “l” serial command and the tx-tx line is apparently removed so that isn’t possible. Or at least that’s the impression I get from the latest CM FW but we don’t know what it’s actually running yet.

I am fairly confident it must be CM since not only is there a “settings:” string but also a “Band 433 MHz” string too which is the 4th line printed by that same function in the CM sketch.

It would seem the Tx3e thread is constantly crashing due to some text chars and it’s as if it keeps restarting the serial comms and occasionally it gets a little bit further before crashing. Do you know if earlier revisions were more verbose on the serial output?

We need to know that last bit.

No sketch has ever sent any data other than the “normal” output of voltages, currents, powers, energies, temperatures or pulses after the initial power-up sequence.

For a sketch with the on-line calibration, that mode must be activated by the “+++” access code during the first 10 s of its life, and only then will it respond to, and in most cases reply to, one of the configuration or calibration commands, such as l.

No, it must be restarting “r” the whole sketch - or the watchdog is doing it. But again, if it’s seeing a r, it needs “+++” sent to get into a position to see it. If either of those is happening, the message count will always start again from zero.

So, was that before the Tx-Tx wire was disconnected? I think that answer must be “yes”. And it still begs the question, is the Pi zero sending “+++” like the ESP8266 must be doing to create what’s beginning to look like the same problem? With the on-line calibration, any serial connected device connected to the emonTx must send NOTHING except the listed configuration and calibration commands.

I’ve no idea how to track versions through Github, or even if it’s possible. But from memory, that output, like the measurement output, has been fairly consistent, and the change notes in the sketch make no mention of a change to the output text. Gwil tries to let me know when a version is first shipped, so if we know the date the sketch was shipped or received, I might be able to tie it to a version number from that.

That is an easy answer, it is because on boot of the EmonTX it sends those serial messages and the interfacer tries to decode them. Sometimes it succeeds and other times not. If the Pi is powered from the EmonTX, when the whole thing is powered, by the time the Pi is powered and receiving data, the initial messages have gone. If you just reset the EmonTX with the Pi powered (rather than the EmonTX), the interfacer is already up when the messages appear.

Just a matter of boot order.

It is added by the MQTT interfacer.

and yet

Hence why we need to know what FW version is running,

Unless you know of a specific version(s) that automatically print “settings:” during start up? Which is the question I asked

Yup! that has been a gripe of mine since the first launch of original emonhub, there is no need for it. My own rfm2pi sketches and serial emontx sketches do not do that and I have tried to get the emonpi/rfm2pi FW changed too.

The “settings:” string appears 5x in the last log but one that Julian posted, are you suggesting that the emonTx has started/reset 5x without the pi restarting or that the “settings:” string is always repeated 5x during emontx start up? either way, it makes good sense to find out exactly what FW version it is so that we can work with facts rather than speculation and guesswork.

If you know for sure why the emontx would send “settings:” at start up please point us to it, I couldn’t find it.

Sorry, in this instance the “it” I was referring to was “the Tx3e thread” in emonhub, each time the UnicodeDecodeError: 'utf-8' codec can't decode byte error occurs, the thread dies and when it’s restarted it creates a new serial connection to the emontx.

@haffle can you please check to see if you have definitely disconnected the tx-tx or maybe the rx-rx in error as it is odd that you are now getting no response at all from the emontx.

Also, as a test, make sure the rx-rx wire is connected (connect both if you are unsure) and with the PiZ and emonhub settled(ish) reset the emonTx using the little on-board reset button, perhaps the version might just make it through to the emonhub log, a long shot but it might work and saves you having to exit emonhub and connect using miniterm.

From reset seen in miniterm (emonhub stopped)

emonTx V3.4 EmonLibCM Continuous Monitoring V1.80
Loaded EEPROM config
Group 210, Node 15, Band 433 MHz

vCal = 268.97
i1Cal = 90.90
i1Lead = 4.20
i2Cal = 90.90
i2Lead = 4.20
i3Cal = 90.90
i3Lead = 4.20
i4Cal = 16.67
i4Lead = 6.00
datalog = 10.01
pulses = 1
pulse period = 100
temp_enable = 1
Temperature Sensors found = 0 of 1
Temperature measurement is NOT enabled.

RF off
POST.....wait 10s
'+++' then [Enter] for config mode
CT1 detected, i1Cal:90.90
AC present

Looking back at the notes I made when setting this all up I believe that it is running “Tx V3.4 Continuous Monitoring V2.0”.

I have used Miniterm once before, but sadly I am still not au-fait with using it. But I do have a USB programmer on my desk.

Thank you, that’s useful.

This text comes from

Which I referred to earlier

and I therefore assumed that bool to be false, hence the confusion. BUT! I have just this second spotted this

that’s that mystery resolved. But not why it is repeated so much, yes I know it could be the watchdog or some other issue restarting the emontx sketch, we need to identify why that is.

I think we can assume that to be true, for now at least, until something else casts doubt or question. Unless you want to quickly hook up the tx to your PC and Arduino IDE to get an output like Brian’s (but v2.0 not v1.8 perhaps). It might also confirm the emontx is ok (or not), but I suspect it is.

Did you check the wires as I suggested?

The wires were all good, with pre-made ends, no strain / bends, and seated well.

I have now attached the programmer to the EmonTx & powered it up (PiZero removed), and opened the Arduino app on my iMac … but I don’t know what to do with it from here … :hot_face:

The Arduino app shows the 3 panes it did when I was programming the Tx’s a couple of weeks ago, ie EmonTxV3CM, config and rfm. How do I “download” the version no. etc from the Tx?

If you look through the top menu’s there will be a “serial console” or similar listed in one of the dropdowns, that will open a new window and you need to then check the baud and line endings at the bottom of the page, hopefully you will see some output.

You don’t “download” the info, the emontx writes it to the serial port whether you are watching or not, so if you get some legible output but not as Brian posted, press the reset button on the tx for it to start over.

You may need to select the right com port before opening the serial console, that should also be obvious when you open some of the dropdowns. It’s been a while since I opened the Arduino IDE.

To add to that, instructions for using the Arduino IDE are in the ‘Learn’ section - including those for a Mac.
The easy way to check the COM port is unplug the programmer, see what the IDE lists under Tools → Port . Plug in the programmer & emonTx, come out of Tools in the IDE, then go back again into Tools → Port and see what’s new, and choose the new one. N.B. It won’t re-read the list without coming out of ‘Tools’.

1 Like