Advice setting up (and integrating) solar diverter

Hi - I’m fairly new here so I hope this is the right place for this thread - couldn’t see anything exactly the same having been asked.

So currently I have a EmonPi (located next to consumer unit) that’s working nicely and logging home power use and solar generation. I plan to add a solar diverter to my setup - probably the mk2 router but it doesn’t have to be). My question is basically this - what’s the simples and cheapest setup that will allow me to also log diverted power (and potentially cylinder temperature). Key points: the immersion heater is on the same circuit as my boiler, so I can’t monitor its power use from my the consumer unit.

The simples option I can see is the following
i) Use a EmonTx on the meter tails to get net consumption/export - have that ‘drive’ a mk2 PVRouter.
ii) Another EmonTx by the cylinder meaning power consumption by the immersion heater and potentially tank temperature.

So that configuration means I need to buy the diverter plus two EmonTx. Have I missed anything - can I do it more simply? I’m fairly sure I can’t use the existing EmonPi to drive a diverter - is that true? Thanks!

Basically - yes, because it’s going to be really hard to connect onto the “emon” front end, and even if you could, that processor is likely to be far too busy.

What is the distance between your meter and the immersion heater? Is a cable run of any sort possible? (I’m thinking of a cable between those for the grid c.t.)

I think that’s going to be more-or-less essential because the short switching interval of the diverter will make the emonPI’s reading “erratic”, so you need the continuous monitoring that the emonTx will give you. Unfortunately, it means the “emon” part of your emonPi becomes redundant, unless you have sub-circuits you’d like to monitor. But it might be worth holding fire here. I’m working on a CM version of the emonPi, but it’s nowhere near ready for release and I can’t give you a timescale.

If you’re willing to forego tank temperature, or you add an emonTH and external sensor for that, then you use Robin’s diverter with reporting via radio - that will dispense with the need for a second emonTx.

The beauty of Robin’s Mk2PVRouter is we know all about it, so you have support that could be hard to come by with another unit. If the emonPiCM happens, the Mk2 will need a software modification to work - but I know what’s needed. As you’ll be assembling the Mk2 yourself, I presume updating the software won’t be a problem?

Ah great thanks. Unfortunately a cable between CU and cylinder is out of the question. A CM PI would be fantastic, software update when needed wouldn’t be an issue.

So in the interim I think the easiest solution (requiring only one EmonTX to be bought) is this:
Just have a EmonTX by the CU monitoring meter tails and solar circuit. It could then communicate via radio to Robin’s Mk2PV AND the EmonPi (can it do both at the same time?). If the answer is yes that would then free the EmonPi up to move next to the cylinder where I could record power use by the Immersion heater and cylinder temperature.

So I guess there’s two implicit questions in there:

  1. Can one EmonTX report to a PI and Mk2PV at the same time?
  2. I’m assuming there’s nothing in the Mk2PV that’s capable of reporting back to an EmonPI how much power it has diverted?

Thanks again (I’m completely blown away by how good the Emon hardware is and the level of fantastic community support)

Yes it will, but I’m not sure how he does the “remote load” bit. Essentially, in the absence of a cable route, you’ll be splitting the Mk2 into two boxes with a radio link in between. The ‘metering’ part will need to be at the C.U., the load switch at the immersion heater. The basic unit can measure the diverted load and temperature, and report by radio, but I’m not sure if that can be done with the remote load. You’ll need to check with Robin.

I don’t think the standard emonTx will report sufficiently fast for that to be realistic. But if it does, then it’s a broadcast message and anyone listening can hear it.

Ah I see - for some reason I’d formed the view that an EmonTx could be used as the remote ‘metering’ part of an Mk2 (i.e. instead of using Robin’s own remote metering hardware).

Edit: Having looked here again: Learn | OpenEnergyMonitor I now see what I’d missed. An EmonTx can be used to drive an Mk2 but only in a physically wired configuration not wirelessly. At least I think that’s the case.

Sounds like it might just be easier to get the ‘standard’ MK2 with radio linked boxes from Robin AND possible have an EmonTx up at the immersion/cylinder to record power use on the immersion circuit and cylinder temperature.

Let’s see what Robin says. He should be aware of this thread before long.

1 Like

Hi folks, plenty of interesting ideas so far…

The Mk2 PV Router “product” is esssentially a software routine which monitors the flow of energy at the grid connection point and determines when the load(s) should be activated. The “Mk2” software can run on any suitable platform. My own hardware avoids the need for any mains adapters whereas an emonTx will require at least one of them. The primary CT (CT1) must be hardwired to the control board; an RF link from CT1 would not have the capacity to support real-time monitoring of the energy state for diversion purposes.

The Mk2 PV Router comprises two distinct sections: the control part which monitors the flow of energy at the meter, and the output stage which allocates power to the load(s). These two sections are normally co-located and joined by a short 2-core control cable. If an RF link is used between the two sections, the processor at the receiving end of the control link can measure and display the amount of diverted energy. It should also be able to measure the temperature of your DHW cylinder. Similar information could then be transmitted to a suitable receiver.

None of my published software supports transmitting and receiving from the same RF module, but it can been done. When I needed to include that feature, I made use of the emonGLCD’s software where the RF module both transmits and receives.

1 Like

Great thanks that’s very useful. So I must have misunderstood before, I think I do have two options for the control half - either way I’ll have to use an RF based solution (the output stage will be in the loft near the cylinder, while the monitor will need to be downstairs by the CU).

The options for the control half are:

  1. EmonTx running an appropriate sketch. In which case do you happen to know if it could still function as a source for an EmonPI?

  2. Just go with a complete Mk2 RF solution using your monitoring hardware.

Robin: I just wanted to check does the kit-form with RF that you sell include the monitoring hardware or just the receiving/control bits?


That’s likely to be possible. It would need to transmit two separate and separable messages, one short one commanding the power switch to turn on or off (and from memory, Robin’s software in the receiver times out and turns off if it isn’t commanded for a short while), and interleaved with that the “usual” report every 10 s to the emonPi. The easy way to do that is to use our standard Group 210 for the emonPi and something else for the power switch - the filtering is then all but automatically handled by the receivers.

Ok thanks. Sounds like I should get some bits and have a play around to see what I can get to work.