Getting started with a Raspberry Pi 2b and TXV4

I am brand new to all this and have just installed my hardware to monitor my houses energy consumption. Alas I’ve got stuck…

I have a used an old Raspberry Pi 2b, since I had it lying around and wanted to save money. This maybe where I have gone wrong, but it boots very happily with the latest image on a new SD card so I feel it should work…

The Pi is connect via USB to a brand new TXV4 interface which has current clamps around cables, one temp sensor, and a brand new emonVS powers everything.

There is no WiFi on the 2b so it has always been connected by Ethernet cable to my router from day one.

I follow the “get started” instructions, all good until I got to look for “Inputs”. Nothing there. I tried turning the USB C connector around and rebooting but nothing is appearing.

What is going on? Has anyone else used a Pi 2b successfully? Why can’t the Pi see the TXV4 automatically? How do I debug this?

Thank you for your help,


Good to know the image works on a 2b!

This issue is probably the USB port it is using. emonHub is the tool we use to bring the data in from the outside (look at the Docs for more info). The USB Port is not usually used.

The first place to look is the emonHub Log. Click restart and see what error messages you get.

You may need to click on Edit Config

And change debug level to DEBUG.

You probably need to follow This Doc which is found from here for the OEM Interfacer and add an entry for that interfacer.

Will @Matthew_Lee need to ‘fix’ the Pi’s USB port with an entry in Udev rules as described in the section “Assigning the Programmer’s Port (Linux Only)” in FTDI Programmer — OpenEnergyMonitor 0.0.1 documentation

The ID for the emonTx V4 is 10c4:ea60 and the rule:
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="FTDI", MODE="0666"

No, I think that is only to flash the TX not to receive data. @TrystanLea

When I get the time I’ll check.

The way I read this, it’s a permanent serial data connection that’s required - which implies the USB port on the Pi must always be the same, else intervention will possibly be needed after each reboot.

Locking the USB is nice, but not imperative. RPiOS usually restarts with the same ports and has been mentioned before. That command though was in a thread about FTDI.

Has some thoughts, but again this refers to FTDI adapters to a UART, not to the USB port on the TX4.

But @Bill.Thomson posted this a while back (might be good for the docs)

Exactly - but the problem is identical. The computer (desktop interrogating a programmer or RPi interrogating a programmer built into the emontx V4) has the same problem if, maybe when, the OS allocates a different identity to the USB socket the “programmer” is plugged in to.

I would suggest this is wrong. When the OS assigns a different identity, the emonTx V4 - emonBase link fails.

Thank you for your help everyone.

I have located and played with the emonHub config file.
New interfacer is added and I can see it trying to connect in the log:

2023-01-31 20:23:49,826 ERROR MainThread Could not open serial port: /dev/ttyUSB3 @ 115200 bits/s (retry every 10s)

I have tried guessing the path: USB0, USB1, USB2… but no good. Is there away to see what is connected to the Pi and thus the path to put into the config file? Can I get a command line through the web pages or something?


Yes, disconnect it and do lsusb Note what you have. Reconnect it and do the same again. The new entry in the list is your emonTx.

On my Ubuntu machine, it’s the second on the list

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 003: ID 174f:118d Syntek Integrated Camera
Bus 001 Device 004: ID 8087:0026 Intel Corp. 
Bus 001 Device 002: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

(which happens to be exactly the same as the earlier OEM FTDI programmer.)

The magic word is “CP210x”
Now do dmesg | grep tty and you should get a list with “CP210x” appearing somewhere, like

dmesg | grep tty
[    0.129941] printk: console [tty0] enabled
[35092.898070] usb 1-9: cp210x converter now attached to ttyUSB0

On this machine, it appears as ttyUSB0 (/dev/ttyUSB0). And that is indeed what the Arduino IDE reports.

I don’t have a RPi to hand so I can’t tell you what it might be on that - but the procedure should work, though I’m not a Linux expert.

Adding to Robert’s post…

ls /dev/ttyU* will show which USB ports are present.

And adding a bit more… I have the appropriate setting in udev, and whichever port out of 3 it’s connected to, it still appears as ttyUSB0, which is good - except when I have both the emonTx V4 and the old OEM programmer plugged in (both have the same ID), in which case the second to be plugged in becomes ttyUSB1, and remains as that when the first is unplugged (as one would expect).

Thank you Robert and Bill,
I think I understand the commands OK, proof will be in the testing…
Idiot’s question: Where do I type them in? How do I get a command line with Open Energy Monitor? My Pi is headless, only Ethernet connection serving me the local OEM web pages… what am I missing?

You need to have another computer on the same LAN, then you can use something like Remmina (a Remote Desktop client program - see to log in remotely to the Pi, using the SSH protocol (usually referred to here as “SSH into the Pi”.

You’ll need to know its dotted IP address (something like, for the emonSD-10Nov22 the user name is pi and the password is emonsd.

Here’s the result:

(No V4 connected - it’s an old emonPi with a USB WiFi dongle.)

That’s quite a bit more complicated than it needs to be.

If the “other computer” is a Windows box, then puTTY works well,
is light on resouces, and a 1-click install.


If the other machine is a Linux box, then the native Linux terminal app, e.g. xterm, is all that’s needed.

No real need for a Remote Desktop client app. :wink: :grin:

1 Like

Thank you Robert and Bill, I am up and running!

I’m actually using a Chromebook, so downloaded a putty app and tried that. I didn’t get too far with SSH before realising that if I went back to USB0 (there is only one USB thing plugged in!) and flipped the cable it might work, and it did :grin: Data is being logged!

I opted for standard TxV4 set up and check the amperage of the CTs was correct, all good. Since I’m not using the radio, I even managed to turn that off in the config serial window.

I’ve only got one question, what are the inputs E1 to 6? They seem to be live readings with units of kWh but not really related to the power readings P1 to 6?

Thanks for you help,

1 Like

I got the original emonLibCM working properly, and those E (accumulated Energy) quantities are indeed related to the powers. They are the accumulated energy recorded by that CT input from time zero. Whether this value persists across a power-down, or returns to zero on restarting, depends on whether the values are stored using the OEM EEProm library. I haven’t had time to check the modifications that Trystan has made to get emonLibCM to work on the emonTx V4, nor looked at the sketch. If those quantities are unchanged, then the documentation for the '328P version of emonLibCM should help you.

Just looking at the circuit diagram for TxV4, I think my E1 to 6 are the spare analogue inputs which are just floating about not connected to anything. It would be nice if there were the accumulated energy on P1 to 6 but the values don’t match, one is negative!

Anyway time to call it a night and see what data logging has happened overnight :grin:

I think that’s unlikely - the extension card inputs (on a real extension card) are labelled CT7 - CT12, as they are on the main PCB. I’m not aware of any published software that reads those inputs.

[Edit] Having looked at the sketch, those are the energy values associated with the 6 c.t. inputs you have.

But nobody expects them to match! The relationship is energy is the time integral of power. If a power has been negative for a while, and then becomes positive, the accumulated energy may well be negative, but it will become less negative, changing in a positive direction.

Thanks Robert, I was a bit tired last night I think… Today I have 24hrs of data and can see what is going on. Yes the E values are cumulative energy in kWh for each of the power measurements.

I’m not sure why some of my E values started out with random negative values but they eventually crept into positive territory. I did a quick search, and used the following post to zero the E values and now everything is as I’d expect it to be:

Thank you for your help, much appreciated!

I’ve got one more question, but maybe this should start another topic? Forum etiquette?

Since I have a radio in my TxV4 that I am not currently using (Pi is connected by USB), could I use it to receive temperature measurements from an emonTH2 and pass them through the TxV4 to be logged by the Pi? :thinking:

In theory, probably yes. In practice, I wouldn’t like to say. Even if your emonTx was using my RFM69n library, I would anticipate difficulties. Since the emonTx V4 uses the LPL library that I’m not at all familiar with, this has to be a question for @TrystanLea.