OpenEnergyMonitor Community

4 CT emonBase using emonTx and Pi Zero W

Not sure what you mean by this Paul. Surely you would be thinking of stripping out the RF section of the emonTX code, after all it’s now using the serial connection, so you would have more time on the TX to handle the phase calculations as is in the TX without recourse to any more moving of functionality from one system to the other.

Or does Robert’s continuous monitoring code need more ‘oomph’ than the TX has available. I’d be kinda surprised as a lot of folks have emonTXs running PV diversion code - I use Martin’s code which also manages 6 DS18B20s without any issues.

I’d be interested to see this with Martin’s code installed on the emonTX (with reporting done through the serial interface and the RF code commented out). If I wasn’t still hacking away at my Heatbank controller software to get it to fit on a Sonoff 4CH I’d have a go myself. Maybe in a week or two.


Not if I am making a 4CT “emonBase” for that I need the ability to receive RFM data from other devices like the “emonPi” but more CT’s and no LCD display.

No but continuous sampling on 4ct’s (plus the Vac) and receiving lots of RFM data might prove tricky, I also modify my emonTx’s to be 5CT which I would like to accomadate here. I suspect all this is possible but it isn’t a given. The “unitless CM” is something we have been talking about in PM’s for sometime now and whilst it does move a sizable chunk of processing out to the Pi, the serial traffic is also doubled due to 2 values per CT channel being passed to emonhub to interpolate the value using the calibration and phase correction data and there have been talks about exploring faster/shorter reporting periods too.

I have used MartinR’s code (or rather a personal variation of it) from day one, all my installs out in the field have 3 emontx’s running my MartinR PLL FW connected serially via USB to a Pi 3.

Ultimately it’s not important to me to retain the RFM transceiver for my use, but as a 4ch alternative to the emonPi for the cost of an emonESP connected emonTx, it would be good to evaluate and test the option.

I’m still struggling with why you would need the RF. If you have data from other devices, e.g. emonTXs then wouldn’t you use an emonESP on those to be able to use WiFi? It’s a small extra cost and is much more reliable.

Maybe I need a diagram to see exactly what you are trying to achieve

And my version is a derivative of yours - so thanks for sharing way back when.


If I was thinking about buying an emonPi and a couple of emonTH’s but just 2 CT’s doesn’t work for me I could spend £40 less and have twice as many CT’s by using an emonTx and Pi Zero in this way.

I was originally comparing this configuration (and cost) against the existing models of

  • EmonESP+Tx - Basic WiFi app with no RFM network and 4 CT’s (£10 cheaper)

  • EmonPi - Full server with RFM network and just 2 CT’s (£40 more expensive)

  • EmonBase - Full server with RFM network but no CT’s (£?)

  • EmonBase+Tx - Full server with RFM network and 4 CT’s (£significantly more)

A change of FW from emonLib “discrete sampling” 2 CT’s to unitlessCM for 4 or 5 CT’s might (but hopefully not), demand more “grunt” than is available to retain the RFM receiver and a fast enough sample rate, but the more I/we move out of the sketch into the Pi, the more likely it is we can keep the option.

But yes the RF is not essential to the operation of the 4CT’s and can be dropped if required, but there may well be users that would prefer to keep the RFM network and discreet sampling 4CT’s rather than have CM on 4 CT’s (and perhaps maintain a separate RFM base).

This idea mainly comes from the result of 2 discussions.

Firstly, Robert and I were discussing unitlessCM and an emonHub interfacer so that all calibration data could be held in the emonhub.conf and applied in realtime to data passing from the sketch. Robert was specifically thinking about the emonPi and I was specifically thinking of a serially connected emonTx (Personally I don’t see how anyone gets by with just 2 CT’s, but that’s just my opinion). During that conversation I suggested a Pi Zero and emonTx would cost around the same as a emonTx+ESP but it would accommodate the unitlessCM implementation (sketch and emonHub).

Secondly, Trystan recently said that the emonESP+Tx option came about because he had noticed the escalating costs of a basic energy monitor when including an emonBase or emonPi. In that same discussion he also mentioned that he encouraged users to configure their own emoncms servers to a) lighten the load in the short term and b) avoid potentially paying for hosting in the long term. Since a emonTx+ESP alone can only post to, this seemed like opposing ideals to me. But an emonTx+PiZeroW would be as cheap as the emonTx/ESP option but also provide emoncms hosting, plus an expansion route to add emonTH’s and more TX’s to boot!

It would be interesting to flesh out the table with all of the options and cost as well as the pros and cons. Might be useful for newbies who are trying to work out their optimum solution.

To your 2nd post it could help Trystan if that also had a view of the cost of self hosting emoncms or using the .org servers. I think I said in the post replying to Trystans post on future development that a separation of ‘personal’ and commercial use of emoncms makes a lot of sense. But if a separation is made then the ‘personal’ install will need thorough instructions for backup and restore as well as remote access.

That notwithstanding, it would be interesting to see your scenarios fleshed out with all of the options, perhaps based on a user’s requirements, e.g. just monitoring, pv diversion etc. And then to also have various pros and cons, e.g. no RF means no additional TXs or THs etc. but does give a better WiFi connection etc.

If we had a fairly complete table of requirements and the various options it might also help to direct what needs to be done to create the universal emonhub.


I’ve been thinking about just this :slight_smile: and yes it would be interesting to consider costs as part of it. I will try put this together over the coming week.

Ok here’s a draft OpenEnergyMonitor system options explorer, I ended up writing it as a js program as you can then easily change the inputs. I’ve included the pi zero idea for those keen to DIY. I haven’t added the EmonTx shield yet or a discussion of pros/cons.

You can test a variety of potential costs too:

Trystan hi, just had a look at the tables and they are a great start.

I do wonder though about the cost of living in Wales - PiZeros at £25!!! Here in England we can get the Zero W for £10 or £12 for the Zero WH with the header pre-soldered. Also you have ESPWifi, by that I assume you mean the emonESP? If so they are only a few quid without the socket which are only a few pence.

On the table itself, I wonder whether you shouldn’t have emoncms local and emoncms service as the two columns at the end. This would mean you could reduce the number of rows because you have them repeated to cater for the two versions.

Also the first column is a bit redundant until you get to the emonTH bit. Maybe again this should be an options column to the far right which would in fact be very useful as you couldn’t add an emonTH to an emonTX with emonESP unless of course you had an emonBase. Hope that last bit makes sense.

So maybe we need 4 main headings Energy Monitoring, Energy Monitoring with PV (and diversion), Whole house energy monitoring (although the IOTawatt might be in the plain Energy Monitoring category) and Temperature Modelling.



Yes I saw that too, but I assumed it included an [email protected]£9 and a case with the 2x 6pin headers like my example. That would be about £25 quid’ish.

I also noticed that some emonESP and Zero entries did not have a “USB” listed which I’m assuming is the PSU that is required for all emonESP and Zero based emonTx installs, but I haven’t had chance to check the shop pricing to see if it’s missing from the calcs or just a typo in the description.

I think there is also a place for the emonBase (minus the rfm69pi) with a serially connected emonTx as per the Confused Newbie thread.

Yes that’s it PiZeroW with case, SD card and the header with the crossed rxtx pre-prepared also takes time. The ESP8266 adapter module we stock also includes a little bit for the header preparation and a little to cover development work that goes into the EmonEsp firmware :slight_smile:

I think an alternative FW or extension the existing emonTx FW to allow the emonTx to be used as an RFM base would be a great addition, as it is a “no cost” upgrade for emonESP, Zero and emonBase (Pi3+ 2serial-direct" tx) that would pave the way for adding additional nodes (eg emonTH).

I think that would be much clearer and it would also better identify the systems that can do both, ie a user that buys a emonESP cannot then choose to have a local install (after the credit has run out?) to save on the costs. Or as users become more “hooked” on OEM eg start off with a cheap emonTx+Zero reporting to, then by adding more devices and becoming more comfortable with emoncms, or needing the more advanced processes for some complex calcs, they can just start using the local server that isn’t available on a emonESP or IoTaWatt.

Perhaps we need a 3rd column for “both” since many users do run both a local plus a remote instance, especially if they are getting an element of “included” hosting when they buy devices. Although the cost for both will mimic the costs but only be available to non-emonESP/IoTaWatt options

On the zero version it is the +5v vcc and the gnd that are crossed rather than the rx and tx.

The next one will possibly be more like this to give a tad more clearance for the rj45 and allow 1x 5way header to be used with 1x 6way so it is clear which way round it goes

Yes but…

There are plenty of DIYers out there that might have a Zero lying around and an SD card, so could run this up for a lot less than £25. So somehow we need to indicate that a DIY solution could be cheaper.


On the headers, the ones I’ve seen are made up to be quite short and with stiff wire as far as I can see. Is there a case for having a short cable to allow for more flexibility in positioning the emonESP or PiZero?


I used the extended “stacking” headers because I didn’t want the Zero flapping around, I was looking for a more ridged attachment with the WiFi antenna held high and away from the metal case, also the gpio conns are on the rear facing topside of the Zero.

Solder is not very good for physical strength, so just “dabbing” shorter header legs end to end wasn’t IMO and option, the way I have done it the legs are overlapping and soldered along pretty much their whole length, here the soldering isn’t the weak point.

I would also like to look at modding a “P clip” or something similar to secure the Zero to the emonTx by the corner screw, I have a couple of idea’s but this is benched for the moment as I have other more pressing things on at the moment.

Indeed, but there are users that will build their own emonTx’s or use a Pi3 that they already have etc etc, there’s only so many options you can include. Many users will download and flash their own SDcard images and some users will buy their CT’s on Ebay or reuse a 5vdc PSU, in those cases users will have to make adjustments, I think it’s right to try and ensure everything is included so users get the full picture and there are no big surprises.

The description, price breakdown and the pro’s and con’s should tell users more about what is or isn’t included. eg the emonESP isn’t cased.

I also think there is a bit of a case for including a USB programmer (I know this will meet resistance so I don’t expect it to happen), but changing FW or nodeid/group or debugging issues will require a programmer in many of those setups. It becomes essential with the 3rd emonTx or the 5th emonTH. Any/all IMO users that buy any emonTx or emonTH should buy a programmer “just in case”, it becomes a more expensive purchase when bought separately due to P+P.

I would rather pay an extra £7 with my initial order and have it to hand if the need arises, rather than paying £10 and waiting for it to arrive after having discovered I need one whilst trying to install or debug an issue. The Zero can be plugged on to any emonTx/TH to carryout programming or debugging (as could the missing emonBase direct-serial option) I think every other option is potentially £7 (or £10) dearer, except perhaps the emonPi without any additional emonTH/Tx’s.

For completeness, I have a short (200 mm) length of ribbon cable with 6-pin header plug to header socket, which I always use on one end of the programmer to allow it to be not ‘fixed’ to whatever while I’m using it, and a USB extension lead on the other end.
OK, my use case is probably different to most because my almost exclusive use of all emon kit is either answering problems here or developing sketches.

1 Like

Might be interesting to test it with the zero strapped to the case of the emonTX just to see if there is any issue with the wifi. Although fully understand the concept of having the zero fairly rigidly attached to the side of the TX

Good point, might be an idea then to have some indication (*) to show that some configurations can be DIYed at a lower cost.

Hmmm - not sure about this one. It should certainly be an option on the configuration drop down when you are ordering and something to indicate it might well be a useful option. The emotional difference between £7 uplift when you are ordering and maybe don’t yet realise you need it and the £3 difference when you do find you need it isn’t comparable for me. Folks might not even notice the £3 extra it has cost them when they find they do need one. But let’s leave that to Trystan and Glynn.

Now I have found this thread (no idea why I would not remember it), I’m reviving it as I wonder if you did any more on this @Robert.Wall, @pb66?

I think it is a great idea and definitely worth looking at again @TrystanLea.

I did nothing further because it would involve big changes/additions to emonHub, and life’s too short to learn everything about everything.

If you’re going to move the greater part of the processing into the Pi, then it’s definitely worth, not pursuing, but looking at again in a fresh light with a view to doing the minimum - really only the data collection - inside the emonTx.

I’m still not sure how that will run with still handling serial data from the RFM, but it’s got to be worth a look.