4 CT emonBase using emonTx and Pi Zero W

Bramco · 2018-02-15T13:02:28.016Z

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 · 2018-02-15T13:34:21.237Z

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 · 2018-02-15T14:05:46.559Z

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 · 2018-02-17T08:31:37.366Z

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 · 2018-02-17T17:55:00.211Z

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 · 2018-02-21T14:59:53.333Z

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 · 2018-02-23T16:31:33.180Z

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 · 2018-02-23T16:54:12.015Z

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 · 2018-02-23T17:14:17.299Z

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 · 2018-02-23T17:17:38.957Z

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 · 2018-02-23T17:33:43.557Z

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.

image446×685 8.28 KB

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

image426×706 8.77 KB

Bramco · 2018-02-24T11:39:54.019Z

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 · 2018-02-24T11:42:22.513Z

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 · 2018-02-24T12:24:41.605Z

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.

Robert.Wall · 2018-02-24T13:25:19.524Z

Bramco:

Is there a case for having a short cable to allow for more flexibility in positioning the emonESP or PiZero?

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.

Bramco · 2018-02-25T12:18:16.993Z

pb66:

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

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

pb66:

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

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

pb66:

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.

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.

borpin · 2020-03-29T14:18:01.247Z

pb66:

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.

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.

Robert.Wall · 2020-03-29T14:45:57.533Z

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.

haffle · 2021-02-16T16:02:17.824Z

An embarrassingly long time ago I managed to get three RaspberryPiZero’s c/w emonTx boards to send data to my emonPi via wi-fi, but for some reason I could never get the fourth one to work for more than a day or two.

In case it was something to do with my wiring on the pins on the Zero, I have just set it up on a RaspberryPi 4 c/w emonTx board instead - using ethernet for now. I have only connected one CT lead, and the cable it is wrapped around is not powered up at the moment, so I would expect a zero or thereabouts value.

Within emonHub of the new Pi in the Barn, I hashed out all of the RFM2Pi section, and within the SerialTx section I gave it a nodename = Serial_PiZero_topbarn - which is what I called it last time. I didn’t turn the emonTx’s RF off as I didn’t get involved with the Arduino side of things, although I suppose it may have remembered that from last time?

Looking at my Inputs page on my emonPi, the node Serial_PiZero_barn is not updating, but a new node of rx is; what might the cause of this be?

Sorry if I am being dim (again), but it has been so long since I did all of this that I have forgotten some of the details …

TIA

Screenshot 2021-02-16 at 15.59.101742×1780 184 KB

Robert.Wall · 2021-02-16T17:20:59.103Z

Dim? You’ve posted on an 11 months old thread, I can’t remember 11 days later

I’m rather lost about what you’re doing. Remember, you know your setup, all we know is what you describe.

haffle:

In case it was something to do with my wiring on the pins on the Zero, I have just set it up on a RaspberryPi 4 c/w emonTx board instead - using ethernet for now.

Have you connected an emonTx to your Pi Zero W, hard-wired using serial, then you’re sending that by Wi-Fi to the RPi4 running emonCMS, which is also feeding into your LAN on wired Ethernet? What IP address and APIKey did you give it in its emonhub.conf?

haffle:

I didn’t turn the emonTx’s RF off as I didn’t get involved with the Arduino side of things, although I suppose it may have remembered that from last time?

If you have never turned it off, it’s on. If you turned it off “last time”, it should still be off unless you didn’t save the setting, in which case it will have reverted to the saved setting, or defaulted to on.

haffle:

a new node of rx is [updating]; what might the cause of this be?

Are we looking at emonCMS NOT on the RPi4 you mentioned earlier?
Your emonPi is obviously receiving something from somewhere. If it’s in emonHub, it didn’t come via the LAN, and as it’s not wired, it must be by radio.