4 CT emonBase using emonTx and Pi Zero W

[pb66 (Paul)]

Inspired by @TrystanLea’s “Huzzah” based emonESP/emonTx combo, I decided to try a similar thing with an RPi Zero W. Due to many other balls in the air right now progress is “intermittent” so for now I thought I would share some pictures and what I had tried so far.

The emonSD image runs on the Pi Zero W ok but I didn’t go to town on the services eg I didn’t use nodered etc.

It’s a bit slow to use over ssh but it will run quite happily, I would want to try and streamline things a bit for this to be a better solution, We have been spoilt by the resources of the Pi 3 and things could perhaps be more efficient.

I have not yet tried compliling a 4 CT version of the emonPi FW, but I see no reason for it not to work as the emonTx has the same resources as the emonPi add-on board, although having double the CT’s of an emonPi might reduce the time left for the RFM receiver to process received RF data.

The cheap case I used does impede using the rj45 connector but I could easily cut a bit of perspex away and use one les nut and bolt to allow access to the rj45, the next one I might try making a dog leg in the connector so the Pi lines up with the far rh side so it clears the rj45.

However! I have (unrelated to this directly) also written a 1-wire python script (first step towards an emonhub interfacer) so that temp sensors can be connected directly to the Pi’s gpio and each sensor id can be saved/defined in emonhub.conf so that the devices are always recognized correctly, I have tested with 18 ds18b20 sensors as that’s all I had to hand but the bus is supposed to accept upto 128 sensors and there are no restictions in the script or emonhub, so I’m guessing you could have as many as the PSU and the wiring will sustain up to (but probably not even close to) 128.

The Pi Zero is powered via the emonTx just like the emonESP is so both an AC:AC and an AC:DC power supplies are required like with the emonESP and also the emonPi setups.

The price of this is likely to be very close to the emonTx/emonESP hardware as the only difference is a emonSD and a Pi Zero with a cheap case, instead of the emonESP “huzzah” (around a tenner more perhaps) everything else would also be required for an emonESP. Except it’s not just a wifi emonTx, it’s a full emoncms and IoT server running emonHub too just like an emonBase or emonPi. Loadsa bang for your buck!.

I have deliberately used a different gpio pin for the emonTx reset so that the emonPi update cannot overwrite the FW and so it is possible to tell the devices apart in software, but this requires an edit to the pin number in the rpi-avrdude script to upload a sketch, that’s ok for a temp solution but not ideal, more thought on that required.

I will try and report back here once I make some more progress

[TrystanLea]

Nice work @pb66! thats a great idea, a significant increase in capability, wow the pi zero is cheap! Raspberry Pi Zero W – Pimoroni

[pb66 (Paul)]

@TrystanLea

wow the pi zero is cheap!

I know! The Pi3 isn’t exactly expensive for what it can do but a Pi Zero with on-board WiFi for a little over a tenner. plus a cheap case, plus a rfm69pi and emonSD, you have an emonbase for under £50 including PSU etc, it would just about do a full emoncms server, but it would easily make a modern “Rock Solid Gateway” for forwarding data to another server, self-hosted or emoncms.org.

I would like to explore whether we can get 4ct’s and a RFM base running on an emonTx, If we can I would like to try @Robert.Wall’s unitless CM lib with a close coupled connection between the Pi and the Tx so the Pi can do all the calibration and phase correction calculations whilst the Tx focuses on just continuous sampling and RFM reception.

The Pi can handle multiple pulse counters which the emonTx(due to limited interrupts) and emonPi (due to no easy access to the gpio) cannot. One of these would allow easy “plug’n’play” connection of up to 4 optical pulse counters or temp sensors. I’ve already done separate Python scripts for 2 optical pulse counters and for 18x ds18b20’s so if we can get emonHub rolling again these new interfacers wouldn’t be hard to implement at all.

[Robert.Wall]

@pb66

I would like to try @Robert.Wall’s unitless CM lib

Moving the phase calculations out of the fast per-sample loop frees up a significant chunk of processor time back into the main loop, and should make comms and other processing a lot more reliable. Not to mention, it becomes tweak-free, so no need to talk to it, ever.

[Bramco (Simon)]

@pb66

although having double the CT’s of an emonPi might reduce the time left for the RFM receiver to process received RF data

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.

Simon

[pb66 (Paul)]

@Bramco

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.

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.

@Bramco

Or does Robert’s continuous monitoring code need more ‘oomph’ than the TX has available.

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.

[Bramco (Simon)]

@pb66

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.

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

@pb66

I have used MartinR’s code (or rather a personal variation of it) from day one

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

Simon.

[pb66 (Paul)]

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).

[pb66 (Paul)]

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 emoncms.org load in the short term and b) avoid potentially paying for emoncms.org hosting in the long term. Since a emonTx+ESP alone can only post to emoncms.org, 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!

[Bramco (Simon)]

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.

Simon

[TrystanLea]

@Bramco

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.

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

[TrystanLea]

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 emoncms.org potential costs too:

https://openenergymonitor.org/optionexplorer/

[Bramco (Simon)]

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.

Thoughts?

Simon

[pb66 (Paul)]

@Bramco

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.

Yes I saw that too, but I assumed it included an emonSD@£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 - #5 by pb66 thread.

[TrystanLea]

@pb66

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

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

[pb66 (Paul)]

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).

@Bramco

I wonder whether you shouldn’t have emoncms local and emoncms service as the two columns at the end

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 emoncms.org, 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 emoncms.org costs but only be available to non-emonESP/IoTaWatt options

[pb66 (Paul)]

@TrystanLea

and the header with the crossed rxtx pre-prepared also takes time.

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

[Bramco (Simon)]

@pb66

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

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.

@pb66

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

Agree

[Bramco (Simon)]

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?

Simon

[pb66 (Paul)]

@Bramco

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.

@Bramco

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.

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.