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!
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 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.
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:
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 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.
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
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 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
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
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.
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.
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.
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 …
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.
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?
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.
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.
Thanks @Robert.Wall .
Instead of connecting a PiZero to an emonTx using 5 jumper wires & then communicating to my emonPi running emonCMS via wifi, for this Barn I have connected a RPi4 to the emonTx using 5 jumper wires, and then connect to the emonPi / emonCMS via ethernet. NB: I use a local emonCMS on my emonPi, not the “hosted” emoncms.org. I am not quite sure how to answer the “serial” bit of your question, unless using the jumper wires means serial.
The emonPi is 192.168.2.50, and the Pi4(/emonTx) is 192.168.2.54; this is the first section of the RPi4/emonTx’s Emonhub conf, which shows where I hashed out the RFM2Pi section, set a serialTx nodename and told it where my MQTT broker(?) is - NB: I use my emonPi for MQTT brokering.
#######################################################################
####################### emonhub.conf #########################
#######################################################################
### emonHub configuration file, for info see documentation:
### https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md
#######################################################################
####################### emonHub settings #######################
#######################################################################
[hub]
### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
loglevel = DEBUG
### Uncomment this to also send to syslog
# use_syslog = yes
#######################################################################
####################### Interfacers #######################
#######################################################################
[interfacers]
### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
#[[RFM2Pi]]
# Type = EmonHubJeeInterfacer
# [[[init_settings]]]
# com_port = /dev/ttyAMA0
# com_baud = 38400 # 9600 for old RFM12Pi
# [[[runtimesettings]]]
# pubchannels = ToEmonCMS,
# subchannels = ToRFM12,
#
# group = 210
# frequency = 433
# baseid = 5 # emonPi / emonBase nodeID
# calibration = 230V # (UK/EU: 230V, US: 110V)
# quiet = true # Disable quite mode (default enabled) to enable RF packet debugging, show packets which fail crc
# # interval = 300 # Interval to transmit time to emonGLCD (seconds)
[[SerialTx]]
Type = EmonHubTx3eInterfacer
[[[init_settings]]]
com_port= /dev/ttyAMA0
com_baud = 115200
[[[runtimesettings]]]
pubchannels = ToEmonCMS,
nodeoffset = 0
nodename = Serial_PiZero_topbarn
[[MQTT]]
Type = EmonHubMqttInterfacer
[[[init_settings]]]
mqtt_host = 192.168.2.50
mqtt_port = 1883
mqtt_user = emonpi
mqtt_passwd = emonpimqtt2016
[[[runtimesettings]]]
subchannels = ToEmonCMS,
timestamped = True
node_format_enable = 1
node_format_basetopic = emon/
[[emoncmsorg]]
Type = EmonHubEmoncmsHTTPInterfacer
[[[init_settings]]]
[[[runtimesettings]]]
pubchannels = ToRFM12,
subchannels = ToEmonCMS,
url = https://emoncms.org
apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
senddata = 1 # Enable sending data to Emoncms.org
sendstatus = 1 # Enable sending WAN IP to Emoncms.org MyIP > https://emoncms.org/myip/list
sendinterval= 30 # Bulk send interval to Emoncms.org in seconds
#######################################################################
####################### Nodes #######################
#######################################################################
[nodes]<<SNIP>>
I don’t think I inserted my local emonCMS’s write API key anywhere with this RPi4 / emonTx.
I am 99% sure I did turn the TX’s RF off last time - and would have saved it, so I will assume for now that it is off.
The screen grabs in my earlier post are what shows within emonCMS on my emonPi, yes. If I look at the emonCMS Inputs on the RPi4 / emonTx, ALL are n/a NULL. This is a snippet of the emonHub log on the RPi4 / emonTx…
I was going to say you are using the wrong format node_format_enable because the topic it is published on says emon/rx, but you haven’t. I wonder if the Timestamped option is causing the issues.
timestamped doesn’t work for that format (I think) so try taking it out.
Alternatively, use the JSON format.
# Single JSON payload published - use with Emoncms MQTT
node_JSON_enable = 1
node_JSON_basetopic = emon/
and yes it would be interesting to consider 
