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: emonTx3 User Guide — OpenEnergyMonitor 0.0.1 documentation 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
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.
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.
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.
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”)
I have changed the hostname from emonTx_PiZero_1 to emontxpizero1 & rebooted both the Pi and emonHub on the emonTx.
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.
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:
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?
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.
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.
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.
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 …
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’.
