Hi all,
Long time user but haven’t been around much as my system “just works” and has been rock solid for years!
I currently have a Freetronics EtherTen (Arduino Uno with onboard ethernet) with the EmonTX shield running a customised version of @calypso_rae’s PV router firmware (from 2013!).
I modified it to add ethernet support and to publish readings for all CTs to MQTT. It also controls a remote load (my hot water cylinder element) via MQTT, sending ON/OFF signals which another Arduino with a solid-state relay is listening for. It has been working very well.
I am about to build a new house, which will have 3 phase supply. So I need to get another 2x EmonTX shields to monitor the extra 2 phases. I was planning on just copying the current sketch I am running but thought I better ask here in case there have been some major improvements or advancements in the mean time!
I see there are new EmonLibCM and EMmonTxV3CM repos on Github but none of these seem to have support for MQTT built in. I am fine with adding ethernet/MQTT support myself but I thought I would ask if anyone else has already done this, or if I am missing a version/repo somewhere?
Also, how does the new CM versions of the firmware compare to the continuous sampling implemented by @calypso_rae for his PV Routers? Is it based on the same code/principles? Or is this a new way of doing things I should be using going forward?
Thanks!
Ben
You could copy your ‘old’ sketch verbatim, or you could copy your old sketch and replace emonLib with emonLibCM, or you could add the MQTT capability (I don’t even know what that can be used for or what it entails) to one of the example sketches that come in the zip file emonLibCM (if you download it from my release post here, rather than from Github). The first will give you exactly what you have now; if you don’t have rapidly switching loads - like Robin’s diverter - ‘CM’ shouldn’t be much different. The second would involve a fair amount of work, and I doubt if the result would be worth the effort. Although I know nothing about it, adding MQTT lifted from your old sketch to the demo is likely to be the easiest.
EmonLibCM is derived from Robin’s code, so large parts are identical. It does have compensation for the transformer phase errors, and the bias offset is removed differently (but the result should be indistinguishable).
The “Discrete Sample” code that you have leaves the processor idle or asleep for most of the 10 s interval between sending the data - it only samples for a few hundred milliseconds per channel and is free to do other things in between. What you need to watch out for with the ‘CM’ code is exactly that, it does monitor continuously - it samples something every 104 µs and it uses the processor for a little under half that time for every sample, and if you need to do something else while that’s happening, it had better be able to do it in 50 µs bursts between samples to allow them to be processed, because if it doesn’t, everything will go haywire.
Hi Robert,
Thanks for the detailed reply. The version I have now is not using EmonLib or EmonLibCM - it is all self-contained in the one sketch, and is using interrupt driven monitoring, so I believe is “continuous”. I am not expert on this code but I would be more than happy to share what I have if that is useful?
The MQTT stuff is just a different way of publishing the sensor readings - instead of using the RF module I publish everything to MQTT where downstream systems (e.g. openHAB) can subscribe to the topics and consume the data.
I prefer this method as it is a hard wired approach, via ethernet, and I can power the device using POE. I don’t have to worry about RF interference or signal issues.
I haven’t seen any problems using this approach with Robin’s continuous diverter sketch, so I think I will have to do some playing around. I am not planning to do any PV diversion initially, hence my looking around for a more up-to-date and simpler version of what I have.
I will keep digging, I am surprised more people don’t use the EmonTX shield with an ethernet enabled Uno and publish direct to MQTT. I was expecting to find examples of that in the forums, but I guess most don’t have ethernet to their distribution board and WiFi/RF is the easier option.
Thanks again.
Ben
Hi Ben,
Since starting my own business at www.mk2pvrouter.co.uk, my contributions to this community have greatly reduced. “Mk2” sketches on the archived OEM forum should all still work OK but no refinements have been added in recent years.
To reliably divert surplus power in a 3-phase setting, it is necessary to accurately measure the flow of energy on all three phases. I first set about this challenge using a prototype rig with three separate 1-phase boards, and that setup is still operating perfectly. Its owner has declined the offer of replacing it with the PCB version because the original prototype ain’t broke!
A three phase control board is now available from my online shop, either as a bare PCB or as a kit of parts. This allows the flow of energy to be accurately monitored just as a 3-phase meter does. When using my 3-phase “Mk2” firmware, surplus power can then be accurately quantified and diverted to one or more resistive loads at no charge to the customer.
Because all of the processor’s analog ports are fully occupied doing back-to-back V*I measurements, none are available to measure any power that is diverted. That task could be performed by a second 3-phase control board with another set of 3 CTs. Data from the second board could then be transmitted by RF or any other suitable means for datalogging.
The 3-phase Mk2 sketch on my website’s Downloads page is for when the meter charges for net consumption (with the individual consumptions on all three phases summed together). Most locations around the world appear to operate in this way but some treat each phase separately. In that case, a separate dump-load would be needed for each phase, and the 3-phase controller would have to operate as three separate 1-phase diverters. Software for that alternative scenario is available on request.
Thanks @calypso_rae - we don’t have “net” metering here in NZ so I need to measure each phase independently and since I will only have a single phase solar inverter, will only need diversion on that phase.
I have just ordered another 2x EmonTX shields with 8x CT clamps. I will mount these alongside the existing EmonTX (in the new house) and have each monitoring a single phase, along with a few loads on each phase.
I think I will have a play with the new EmonLibCM on these new devices, but will probably keep the existing firmware on the phase with solar so I can use for remote diverting (via MQTT).
OK Ben. One of the benefits of my own hardware implementation is that no external power adapters are needed. 3-phase AC is fed directly onto the PCB, and the per-phase AC voltages are monitored via three on-board transformers. My 3-phase PCB is essentially doing the work of three Arduinos, each with its own EmonTx Shield, but only one current path can be monitored on each phase because the processor only has six analogue ports.
Yeah I looked closely at your hardware - it ticks a lot of boxes for 3 phase supplies. I really like the simplicity of installation with a single AC feed per phase. But the lack of ethernet was a deal breaker for me, and I will find it useful having additional circuit monitoring which will be available in spades with 3x EmonTXs shields.