I bought one in November '22 when they came out, I want to get the extra board now its available but I can’t see either EmonTX4 or the add on board in the shop?
Has emonTx V4 been abandoned?
Ok, so EmonTX4 is abandoned, and all those that bought into Open Energy Monitor are left without the ability to upgrade or extend their systems in summary.
This is a huge mistake in my opinion, I am not going to buy a £200 EmonPi2 when all I need is a £50 EmonTX3 or a £120 EmonTX4.
I bought my EmonTX4 at launch in good faith the add on board would be released, which it was over 6 months later and now 6 months after that the entire product is scrapped and I am left high and dry.
I have been a huge fan and advocate of OEM over the years, many people I know have OEM as a result but I simply cannot recommend it anymore if the core function of having he dedicated TX is removed.
Maybe the developers have a single consumer unit, but its clear from the forums many people have a requirement to monitor in more than one location.
What is someone starting out today with the need to monitor in a house and garage expected to do? They are really going to spend £300 on EmonPi2 (with Pi and 2-3 clamps) then another £230 on an empty EmonPi2 (2 clamps) - £530 on simple monitoring?
I’m sorry but I think the plot has firmly been lost…
Hello Paul
I appreciate that the current position does not fully meet our stated intention with the move from the EmonTx4 to the EmonPi2. I will try and explain:
-
The emonPi2 measurement board is basically the same board as the EmonTx4 functionality wise. This is the blue board with the CT sockets and AVR-DB microcontroller core inside the case. The intention was to make one board that could be used as either an emonTx4 replacement or an emonPi2.
- In the emonPi2 configuration it would have a RaspberryPi attached.
- In the emonTx4 configuration it would not have a raspberrypi attached, and would transmit it’s data to an emonBase or emonPi basestation elsewhere, or connect via USB, exactly the same as you would do with the original emonTx4.
-
It is currently possible to buy the emonPi2 without a raspberryPi for this purpose (or to allow use of an existing raspberrypi). The price with an emonVs is £201.88 inc VAT and the price without the emonVs is £144 inc VAT. See shop option ‘No RaspberryPi’
When used without the raspberryPi there is an associated firmware option to transmit the data via radio, this firmware is available from the firmware update UI (we can also upload this here for you before sending the hardware out):
-
We still stock the emonBase if no monitoring is required at a basestation location emonBase 433Mhz (RFM69SPI) - Shop | OpenEnergyMonitor
-
Perhaps the main issue that we have now is that the emonPi2 price point without the raspberryPi and not including the emonVs is £144 inc VAT vs the equivalent emonTx4 price of £86 inc VAT. The previous emonTx4 + emonVs price was £120 ex VAT but £144 inc VAT if I remember correctly. So a price increase of £58 to achieve the same. The reason for the difference in price is mostly the higher cost of the enclosure and that we are currently supplying the no Pi kit with everything required for a user to add in their own Pi.
The ideal solution I think would be for us to find a way to bring the enclosure cost down on this no Pi variant of the emonPi2, which might as well be called an emonTx4 as that is how it is intended to be used.
We are also planning to bring the same 6CT extender board to the emonPi2 to give the option of extending to the full 12 channels and if you or anyone else need this extender board for an existing emonTx4 we do still have a number of these available.
I appreciate we’ve not managed to provide quite the seamless emonTx4 replacement with the emonPi2 based board (but without the Pi) yet at a similar price point. We are working on this to make this option clearer and at a closer price point in the shop. I hope to be able to update positively on this soon!
Hi Trystan,
Thanks for the detailed reply, and sorry if my earlier post was a bit grumpy, I was just frustrated that I could not add the expansion board I wanted to right now - and lack of options for the future.
Reading it back it was not very objectively worded in places so I apologise for that.
I still believe a lower cost sensor option would be a great benefit for existing and future OEM customers, I know your producing in low volume and a single board design makes sense - but as you note £58 extra over a EmonTX4 is a pretty large jump that’s hard to swallow. I had forgotten to deduct the EmonVS when comparing, but I have a EmonVX mini which I think was cheaper than the full EMonVS? (no USB-C as its just a voltage reference for the EmonTX4).
With battery storage, EVSE, heat pump - lots of green energy tech would need a TX solution outside the main monitoring location at the CU.
I still really love EmonCMS and EmonPi, its been great over the years and the integration with other open source options is really helpful.
I did add up the other day what I had spent in total on my solution… and (inflation adjustment asides) I think if the sensors were more significanlty expensive it would be really hard to justify. You do need to cover your costs and make a profit though of course.
1 Like
Thanks for understanding!
I do very much agree and will put this back up to a higher priority. I would also like to get the emonVs mini back in stock as like you say that’s a good option to reduce costs as well. Sometimes it is good to have a nudge that this is needed, I know @gwil has bought it up with me a couple of times in recent weeks that customers have been asking for the emonTx functionality.
1 Like
Not sure this is the right direction to go, but appreciate why you have done so.
I think the part you are missing is the increasing number of folk using Home Assistant.
The TX4 will happily communicate directly with HA and with the emoncms add-on, there is no reason to run an additional Pi.
There are virtually no other devices out there that can monitor 12 circuits for power consumption simultaneously.
Personally, I’d like to see a roadmap of
- Combine The VS & the TX and create a one-piece 12-circuit monitor that ‘Works With Home Assistant’. That is a great USP!
- Cheap enclosure.
- Drop the RF facility
- Drop the other connections and anything not related to energy monitoring.
- Use an ESP32 with ESPHome or Tasmota by default.
- Officially support the emoncms HA Add-on
- Support an HA emoncms component.
Create a 12 circuit energy monitor that ‘Works With Home Assistant’. That is a great USP!
Time, money, stock, development time can be better used;
- Drop RF completely (contentious view but saves development and has become too confusing)
- Pi2 OK but has become too expensive IMHO. Jack of all trades and master of none.
- HP Bundle is the way forward for OEM and needs more time to develop this offering.
- Adopt clear links with HA - this is the future. Anyone putting in a 12-circuit monitor probably is using HA as well.
- Use standard ESP code - e.g. ESPHome and create component(s) for it. Reduces development time.
When the project started, there was no simple way of measuring and recording room temperature (hence emonTH), Wi-Fi was not universal (hence RF).
$0.02 worth 
1 Like
It is interesting to look at the schematic for emonTx V4 and then emonPi v2. They are almost identical. That is really cool, because it means that the next generation of emonTx devices will use the same board as the new generation of emonPi. Very cool. I like it.
The trick is to create a next generation of emonTx based on this board.
While I see where @borpin is headed with the wishlist above, I would have a wishlist like the following.
- A smaller, less expensive enclosed than the emonPi, similar to what we’ve had with the emonTx in the past.
- Keep RF as an option, for the ultra-low power heritage from both Jee and LowPower labs.
- A battery-power option, which some have used for some very cool things in the past.
- Selfishly, as a US user, I’d be interested in the return of the option to get the voltage signal and power supply from a cheap AC/AC adapter, like the emonTx v3, but I suspect this would be more controversial and I understand why.
- OR, as Brian said above, take advantage of the absence of the Pi and use the space to include an emonVs inside the enclosure. That would also be nice and tidy.
1 Like
FWIW…
I can think of two devices…
The GreenEye Monitor from Brultech, which can monitor 32 circuits
as well as
IoTaWatt which has 14 inputs.
The main “issue” with the GEM is cost. They’re fairly proud of it at 458 USD.
And, you’re likely aware of the story behind IotaWatt.
1 Like
Iotawatt is very hard to obtain outside the US, in the UK at least… plus I am already invested in OEM so EmonTX is best for me.
Understood.
Just pointing out that there are at least two other devices capable of monitoring 12 or more circuits.
1 Like
Yeah sorry hit send before I finished… I thought of Iotawatt when I first read Borpin’s post.
I also use HA, but I still like all the monitoring in EmonPi dedicated, its always there reliably logging away - HA often needs a restart and runs as a VM and I would not want gaps in logging if I have to take HA down.
I do agree the world is a different place to when OEM started, HA and other open source tools are now much more mature. With HA you have access to lots of other integrations like Octopus (UK energy supplier with API), weather stations for temperature readings, automation etc. I can see why its a primary driver now and people may move to that as their central hub.
1 Like
You’ve got the advantage there, as I don’t use HA. It’d be overkill for monitoring PV system
output. (which is all I do, hence my comment about your “advantage.” i.e. you’re up to speed on subject matter I know very little about. 
)
1 Like
I’d forgotten about that, but…
I still think the 12-channel is a pretty good USP.
Making emoncms Docker based (i.e. as the HA add-on is) would also simplify things like Wi-Fi connection which again has taken up a lot of time it seems. You could do this on top of DietPi for instance.
Personally, I like the TX more than the emonPi. Making the enclosure cheaper, integrating the emonVS functionality, removing ‘other’ functionality and moving to an ESP32 based system using a common ESP base seems to make sense.
I would concur, for backward compatibility, making the RFM optional makes sense.
1 Like
Especially where a 3-phase supply is normal, i.e. Continental Europe.
1 Like
It will be interesting to see what the green technologies drive longer term with 3-phase here.
I am excited to finally get battery storage next week, but with 7kW car charger, then battery inverter (*2) I am starting to reach the limits of the single phase connection. The fuse might be 100A but the DNO won’t allow past 60A without inspection my battery installer tells me.
1 Like
I understand UK new builds will be (if not already) getting 3-phase to the house as standard.
1 Like
Thanks all for the $0.02 on this! It’s a good point to have a wider range of perspectives on this before we dive in too far on the next version.
In the view of longer term plans, there is another significant update coming up that I haven’t mentioned yet, but it does not change the overall fundamentals in terms of the exterior appearance / form factor / connector placements etc, at least as of yet! That is that @awjlogan has been helping us develop a version of the emonPi2 that uses the ATSAMD core instead of the AVR-DB core, it will be called emonPi3. This is to provide more processing power for higher sampling speeds and ultimately more advanced phase correction. There are other improvements on this board that are thanks to @awjlogan’s extensive hardware design experience.
To date this design is designed to fit in the same enclosure and fascia design as the current emonPi2 and to support the same basic functionality: up to 12 CT channels via the extender, emonVs input via the RJ45, one wire temperature sensors and the RFM69 radio. It allows for the internal integration of the RaspberryPi in exactly the same way and the option discussed above of being used as an emonTx4 transmitter (though perhaps it will be named emonTx6 by then, with emonTx5 being the design based on the current AVR-DB hardware).
We are currently working provisionally on a January/February 2025 release date for this version so we are still some way off yet.
@awjlogan has suggested that we might like to consider including the ESP32 footprint at least on the emonPi3 board itself and so we will look into this a bit more.
emonVs: We are keen to keep this separate for now, it helps to keep the high voltage side of things separate and contained. We do want to look at some improvements to the emonVs that might improve the form factor at least.
12 CT’s: Will work on getting this option available again and the Tx replacement (emonTx5) in the mean time.
2 Likes
@TrystanLea The update sounds good!
One thing you might want to consider with respect to the emonVs with the included 5V psu …
The 5v supply current to the emonPi(n) will give voltage drops along the +5V wires (pins 4 &5) and the 0v wires (pins 7 & 8). Let’s assume that the end to end voltage drop on wires 7 & 8 in parallel is Vdrop.
Pins 7 & 8 also act as the 0V return for the VSx (x = 1, 2, or 3) reference voltages.
So the reference voltages arriving at the emonPi(n) will be:
Voltage at emonPi(n) = VSx-Vdrop.
Vdrop will have a DC component from the DC supply current to the emonPi(n). This is not important for VSx as VSx is AC coupled at the emonPi(n) input.
However, Vdrop will have an AC component due to the 5V PSU ripple (100Hz?) and noise, plus the variations in the emonPi supply current from digital device operation.
The ripple and noise of the 10W Multicomp PSU with a 10uF electrolytic and 1uF ceramic across the output (the configuration in emonVs) is specified at 50mV typical, 100mV max. A little of this may appear across the zero volt wires and be included in the AC component of Vdrop. This may be significant compared to VSx at about 900mV peak and perhaps affect the measurement accuracy.
To have any effect on the power measurement, the AC component of Vdrop would need to contain multiples or sub-multiples of 50Hz to be coherent with the current measurements. And there is the ~ 10 second measurement period.
The effect wouldn’t be present with the emonVs mini as it does not include a PSU.
I don’t know if the AC component of Vdrop is a problem at the moment, but it can be avoided completely if the emonPi(n) supply current doesn’t flow though the VSx return.
This could be done by using an isolated pin 6 wire as a separate VSx return, with no connection to earth or 0V at the emonVs end, only at the emonPi(n) end.
A Caveat - This change removes the existing direct connection between the VSx zero volt return and the mains earth at the emonVs. I have no knowledge of the current relevant safety, RFI or other regulations so I don’t know if this change would satisfy the regulations. OEM would need to check with its test house whether the change is acceptable and whether the emonVs would need to be recertified…
If necessary, to stop the VSx zero volt return from floating when the RJ45 cable is unplugged, something like a 5V bi-directional transient-voltage-suppression (TVS) diode could be added between pin 6 and pins 7 & 8 at the emonVs.
