Archived Forum

"The plan is to make use of the immersion diversion - not sure if to go with the router or PLL"

The main difference is the PLL sketch can monitor and send the data by radio at the same time, Robin's sketch does not (it is purely and energy diverter/router). Both can run on the same hardware with minor tweaks (if you have the RFM12B) so you can start with one and finish with the other.

Ah! Thanks for highlighting that Robert - in my excitement I hadn't spotted that - I was intending to use the GLCD at some point just to reassure me that things are running as they should once 'live' so I guess the PLL version will be my starting point. I'm not quite sure what you mean by 'start with one and finish with the other' however? I do have the RFM12B - I went with the 433MHz version - there seem to be mixed opinions on which frequency, but working with mobile phones as my day job, we tend to see better indoor RF performance on the lower bands so I figured that was a useful baseline!

I managed to get most of the passive components on to the EmonTX board yesterday - I'd forgotten how satisfying soldering up a PCB is :)

To test your new hardware, you may find some of the basic tools on my Summary Page to be of use.  RawSamplesTool will allow you to see the waveforms from your sensors to check that all is well.  The simplest PV Router sketch is my Mk2_mini_3 one.  If you're interested in understanding what's going on, that's probably the best one to start with.  My Mk2i_rev5 version supports multiple loads and has an RF capability for controlling a remote load.  As posted, no transmission of data is supported, but this could be easily added. 

Martin's PLL-based sketch, which does support data transmission, runs on the same hardware so you can switch between them at any time.

At risk of repetition, an 18R burden resistor is not likely to be suitable for a PV Router application - unless you have a 20kW system!

"I'm not quite sure what you mean by 'start with one and finish with the other' however?"  Not well phrased, I agree. As Robin says, you can easily switch between the two so if you find the one you start with doesn't suit your needs, you can switch to the other with minimal or no changes to the hardware (given you have the RF module).

Thanks Robin for your pointers, I finished soldering all the remaining major bits on earlier so just playing with the compiler and the serial output - seemed to be working ok with a few basic sketches so I'll have a look at your tools as a next step. I'm waiting for the clamps to arrive before I can do anything serious...However the mk2i_rev5 with remote load switch sounds like a useful one too - thanks :)

Thanks also Robert for clarifying - makes sense!

No doubt I'll have more questions following some tinkering over the weekend...panels didn't get finished this week, hopefully Monday...

Hello again,

It's been a while since I started this I realise! The panels went up with a few glitches along the way but have had all that sorted now and a very productive Jan/Feb - too much exported energy though!

After a lot of other diversions, to excuse the pun, I finally got an output board for the triac made up, thanks to Robin for offering a pre-made one, in the end my hand drawn, hand etched board worked without any glitches albeit changing the resistor on the LV side to 10R to get the opto-isolator to work correctly (I have an LED in series)

I went for Martin's PLL software as this is what I had started to play with and had calibrated. I *think* it is working ok the immersion neon is happily blinking away as is my output board. The serial output I had for a brief period was as follows:

509 514 513 240.11 38.49 2829.45 2772.60 50.07 300.00 2851.38 PLL is locked
509 513 513 240.15 36.47 2833.23 2773.41 50.07 300.00 2669.03 PLL is locked
510 513 513 239.64 17.25 2838.69 2761.77 50.06 300.00 2583.13 PLL is locked
509 513 513 239.72 67.86 2837.35 2763.45 50.06 300.00 2245.21 PLL is locked
509 513 513 239.57 79.08 2840.34 2760.19 50.06 300.00 1849.82 PLL is locked
510 513 513 239.92 91.89 2842.73 2768.08 50.06 300.00 1390.35 PLL is locked
510 513 513 239.90 83.90 2843.22 2767.67 50.06 300.00 972.54 PLL is locked
509 513 512 240.42 -289.89 2840.20 2390.55 50.06 300.00 2422.01 PLL is locked
510 514 513 237.90 36.89 2832.91 2721.70 50.06 300.00 2237.53 PLL is locked
510 513 513 238.73 43.81 2830.95 2740.79 50.06 300.00 2019.37 PLL is locked
509 514 512 239.02 35.80 2836.53 2747.41 50.07 300.00 1840.38 PLL is locked
510 513 513 238.86 62.48 2833.96 2743.67 50.08 300.00 1527.96 PLL is locked
510 513 513 238.79 113.65 2832.41 2742.04 50.07 300.00 961.99 PLL is locked
509 513 513 238.77 -308.02 2829.78 2357.94 50.07 300.00 2502.09 PLL is locked
510 513 513 238.67 156.37 2825.58 2739.31 50.07 300.00 1720.26 PLL is locked
510 513 513 238.41 115.25 2834.01 2733.39 50.07 300.00 1146.34 PLL is locked
509 513 512 238.74 -270.20 2840.02 2357.20 50.06 300.00 2497.32 PLL is locked
510 513 513 238.57 97.01 2838.94 2737.05 50.05 300.00 2012.29 PLL is locked
510 513 513 238.70 174.95 2840.63 2739.99 50.05 300.00 1141.05 PLL is locked

Sorry that might be a bit tricky to read, but I am cautious that the 5th value for Power1 goes negative periodically - this is export so should this happen when the system is working? I see how the energy rises to 2700J and then reduces to 900J as the energy is fed to the immersion, but as I understand it very little should be exported when balanced, no?

Second question is about the meter - we have a mechanical type with 200rev/kWh and it seemed to blip forwards and backwards - no change in the reading of course but do I have scope for changing the energy levels as they are as default for now?

Lastly, have I made any glaring errors in the calibration - I read that the ILEAD values should be about 158uS rather than the default - I can't find how to go about measuring this without a scope...

#define VCAL 231.6  //calibrated 02/03/14 calculated value is 230:9 for transformer x 11:1 for resistor divider = 281
//#define I1CAL 112.6 // calculated value is 100A:0.05A for transformer / 18 Ohms for resistor = 111.1
#define I1CAL 108.5 //calibrated 02/03/14
//#define I2CAL 94.8 // this is for CT2, the solar PV current transformer
#define I2CAL 108.2 //calibrated 02/03/14
#define I1LEAD 158 // number of microseconds the CT1 input leads the voltage input by
#define I2LEAD 158 // number of microseconds the CT2 input leads the voltage input by
#define POWERCORRECTION 0 // this value, in watts, may be used to compensate for the leakage from
                          //  voltage to current inputs, it only affects data sent to emonGLCD
#define LOAD_POWER 2890 //calibrated 05/03/14 //power in watts (at 240V) of triac load for diverted power calculation

Thanks again, I hope to pick up one of Robin's kits when he's in full production and likely swap the code as suggested. In the meantime I'm sure the novelty of checking the triac/immersion/meter and running between them will wear off ;) Very satisfying to have this going at last :)

Next step is to get the triac board boxed up - at the moment it is dangling in prototype form. Then to get the GLCD out again which I think I've killed :(

I'm pleased to hear that another PV Diversion system is in operation.  Martin's code and mine act in a very similar way for the output stage, it's only the measurement side which is different.  If Martin's PLL code is working fine for you, and your immersion is flashing away as expected, that's great.  No need to change anything.

The main thing to check re. your meter is that there is no net movement.  After each complete forward & backward cycle, the disc should end up in the same place.  Make sure that it's not hitting its backstop after each reverse movement.   I've posted various videos showing this effect.  Send me a PM if you need a pointer to any of these (or if you need a smart heatsink :)

With my Mk2 Router code, that much Serial Output would undoubtedly affect the operation.  It may be worth commenting out those print statements to see if it makes any noticeable difference.

If your Ferraris meter is jogging backwards and forwards and not hitting the ratchet that prevents it going backwards (if yours has one - some don't) and not clocking up energy, then it's all working properly. You can open up the decision values if you wish, but it's important not to allow the energy 'bucket' to underflow or overflow.

I can't think of a good reason why you should export energy unless the dump load isn't available for some reason, it may be something critical like a loose wire or a dirty contact on your immersion thermostat, so I suggest checking obvious things like that first. However, if there's no apparent cause and it's a relatively isolated and rare event I wouldn't worry too much, since tracking it down could be hard. Narrowing the decision values on the energy 'bucket' should stop it - but it will increase the flicker rate.

I haven't looked at a way of measuring ILEAD, so I can't help you there. If you have a large, suitably rated capacitor, you could try using that as the ONLY load and adjust ILEAD by trial and error to get zero real power. This works because a pure capacitor does not absorb power - the difficulty is getting a representative current with a realistic value of capacitor.. You may need to have many primary turns through your c.t. to do any good.

Thanks chaps, that's reassuring :)

The meter (ABB branded) does have a backstop but I don't know if there is more than 1 per turn, I'll take a look at your videos Robin and then see what the tolerance between backwards and forwards is. If it's one entire turn then that allows a bit of scope for value adjustment. Each turn equates to 5Wh or 18000Ws...

I don't think there's any connection issues - the immersion was drawing a full 2890W without the triac involved. The negative value seems to happen each time the energy level drops to 900J which turns the triac off, so as it then takes a brief time to get back up to 2700J this is where it would 'appear' to export. Whether this is actually the case, I'm not sure so maybe changing the hysteresis on the on/off values might change this (not seen any flicker so far so seems ok also as lights aren't usually on during the day probably not such a big issue) I'm curious as to how this affects the output on a GLCD (which I can't test right now). I think the question is whether anyone else that's running this code ever sees apparent 'export' in the 5 sec intervals with transmissions?

I'm slightly more confused with trying to measure ILEAD with a capacitive load (I feel more and more dumbed down in the 'real' world after spending 4 years doing a degree in E&E engineering and not putting it into practice for nearly 10!), I'm curious as to how the original figures might have been derived and what other figures others may be using...

As Robin has suggested before 'playing' has helped a great deal in learning the principles, so thumbs up :) Next step is to understand whether the GLCD board (sans display) is receiving the RFM12b transmissions from the EmonTX...

On the disc-meter that I've tested, the backstop cuts in after approx half a revolution in the reverse direction.  This behaviour is provided by a little nylon top hat which acts like a pawl or ratchet; one way it gets gently pushed aside as it moves past a protruding obstacle, the other way it catches and any further motion is prevented. 

The emonGLCD will display whatever data is sent to it.  Because the original emonTx sketches only measure power infrequently (and assume that nothing changes during the periods inbetween), they won't work reliably if a 'burst mode' PV Router is present.  A sketch that measures continuously will give much better results.  If you are displaying results that are  created by Martin's PLL Router, I would expect the data to be perfect because that sketch records the energy flow during every mains cycle, as do my own Mk2 PV Router sketches.

If you have a spare processing platform handy, you could run my 'continuous' code as posted for the emonTx V3.  This measures real power continuously on four channels and transmits these values by RF every couple of seconds.

That was how I understood it - the RF output on the PLL code is just sent to the GLCD i.e. the data shown from the serial output is effectively what is transmitted to the GLCD and hence displayed. So grabbing a line from above:

509 513 512 240.42 -289.89 2840.20 2390.55 50.06 300.00 2422.01 PLL is locked

realpower1 is -289.89 i.e. the nett house

realpower2 is 2840.20 i.e. the PV output

divertedpower is 2390.55 i.e. the calculated power going to the immersion

Which is exactly what would be displayed on the GLCD. However 5 sec later the following would:

36.89 = import?

2832.91

2721.70

And this is where I was under the impression that when balanced, the first value should hover around zero rather than bouncing up and down quite so much? Or is it because it is a visual 'snapshot' of the power rather than seeing what is happening in between? Just want to make sure this is the expected behaviour!

P.S. Saw the videos of the disc-meter - mine is buzzing back and forth for a couple of seconds rather than vibrating in one position - I figure this is due to the low/high energy thresholds?

If my video shows the disc meter to be "vibrating in one position", that suggests my Router is in its "normal" mode.  If I were to repeat the test with the Router in AF mode, the disc would repeatedly wind its way forwards and backwards within its permitted zone.  When using a digital meter, the penalty-free zone that's allowed is generally either 3600 J (1 Wh), or 1250 J.  In your case, you can probably extend your Router's limits because your non-reversing disc meter won't hit the brakes until around 2.5 Wh's worth of reverse flow has occurred.

Depending on the cycle rate of your Router, it's quite possible that occasional periods of nett import will be correctly reported.  Over a sufficiently long timescale, all imports and exports should balance out (as demonstrated by your disc meter), but that will only occur if energy flow is being measured continuously. 

I'm sure I've posted footage of a disc meter while running a Router in AF mode.  Yes, here's an exciting one for you to watch.  It even talks about phaseCal.  Better stock up on the popcorn first!

(is there a category for the most boring video on the Web?)

[Edit]  Sorry, that one isn't in AF mode ... nor can I find any others.  To perform that 'live' test, I connected Noah's disc-meter into our domestic supply on the 'safe' side of our 2-pole isolator box.  After some weeks of that temporary arrangement, I reconnected the wiring as it should be, and don't wish to disturb it again now.  At that time, autumn 2012, flicker had not been raised as an important issue, so my Mk2 Router did not have an AF mode. 

Thanks Martin :D More reassurance that all is well (and yes no units recorded - will check again today when I get home) - I'll also check the buffer set to zero scenario too! So in AF mode, it is expected that there might be some +/- shown as and when I get a GLCD working...

And thanks also for the link to the phasecal - this is one page I've not come across on my judicious searches! I will try that too :)

Robin - I did watch all 16.24m of that video earlier - I've seen more boring stuff, trust me ;) In this context it makes perfect sense! As you say I probably have a bit of scope with the disc meter - more experimentation ahead!

Robin - I did watch all 16.24m of that video earlier - I've seen more boring stuff, trust me ;) In this context it makes perfect sense! 

Umesh - you've made my day!

Glad to hear it Robin ;)

So I did some more tinkering and have observed as follows:

Using Martin's Phasecal sketch, I ran this with CT1 and CT2 on the immersion wire alone. With this I got values of 7uS and 3uS respectively. This surprised me but at the same time the original values were 5uS in the calibration data...

I then clipped both CTs to the PV (~400W) and got ~155uS for both...

I understand the implications of the current affecting the phase so variance between very low power levels and high ones...but are the values taken on the immersion the representative ones I should use for ILEAD1/2 or should I stick to 155uS as for the actual source/load inputs that are being measured?

Second change was the energy levels - changing to 1800J works as expected with very low import/export (below) with the meter buzzing in the same place :) No issues with flickering it seems but then we don't have any incandescent bulbs...

509 513 512 240.09 3.74 533.49 844.51 49.96 300.00 1783.88 PLL is locked
510 514 513 240.41 0.39 535.30 733.72 49.95 300.00 1781.92 PLL is locked
510 513 513 240.69 -0.14 534.79 735.44 49.94 300.00 1782.63 PLL is locked
509 513 513 240.78 -1.74 535.95 771.04 49.95 300.00 1791.29 PLL is locked
509 513 513 241.13 2.02 538.03 793.51 49.95 300.00 1781.21 PLL is locked
510 513 513 240.56 2.86 537.90 781.23 49.94 300.00 1766.97 PLL is locked

I then tried to up the buffer to 7200J with 900J and 6300J thresholds - the meter did the same as before with back and forth movement, but longer of course...

So is there any benefit to the increased buffer size if I'm not using AF mode - or at all for that matter, other than to ensure no nett energy is imported?

Last of all - I'd set the immersion thermostat to max (65deg I think) and although all but one or two taps are mixers I nearly scalded myself having 'calibrated' my brain to the 'normal' temperature for the basin tap when heated by gas! So plenty energy being shunted it seems :D

The way to look at choosing the value for phasecal is to consider the current. The PV current is roughly steady, varying with the amount of power generated. The grid current, when the diverter is in balance, is pulses of up to 12 A imported balanced by a different and lower exported current. At other times, the grid current is your normal household load, with or without the dump load.

I'd suggest you probably want the phase calibration for the PV feed to be somewhere between 7 and 155 (as 7 represents about 12 A and 155 represents less than 2 - take your pick for where you want the best accuracy!) and the grid connection should probably be set much nearer the 7 end, since the current there is around 12 A when the diverter is working. Assuming you're using the YHDC ct's, if you take a look at the report you'll see exactly how the phase error varies with current and you can make an informed choice.

In case you're wondering, the answer to the variation is a pair of (much) more expensive ct's.

Also bear in mind that the phase error is least important with resistive loads, and only becomes critical when you have a very poor power factor, i.e. a mainly reactive load, which tends to be very small appliances and those on standby.

If you and your neighbours don't experience any flicker, then there's no real advantage of one method over the other. But if your meter gets replaced, be prepared to make a change if you chose the anti-flicker mode with a wide band and you find the new meter has a small energy packet size.

Hello again!

Thanks for the feedback Robert - it makes sense. I experimented with different values for ILEAD and it seems to make little (at least visual) difference to the balance (I have the YHDC 100A CTs) as Robin has also found I believe. Instinctively, I am inclined to have more accuracy at the low end of the power scale but this changes as a result of the load, at least on the house measurement...as a result I have left them at 155uS for the timebeing with the AF off (there aren't any near neighbours!)

Another question is regarding the 'power3' value or 'divertedpower' as it is calculated - I frequently see this as being more than the output of the PV - logic dictates that this can't be the case as power1 is close to 0, but over a sample period of 1 min, it never went below the PV power output. I'm a little confused as I see where this is done in Martin's code, but also see the Brian D on Martin's original thread, averaged to value to the GLCD? Would measuring the immersion power with a third CT be any more accurate? Thoughts - does anyone else see this?

510 513 512 240.76 34.52 1210.15 1365.13 50.02 300.00 1774.97 PLL is locked
510 513 513 240.85 -15.25 1216.72 1105.96 50.02 300.00 1790.22 PLL is locked
510 513 513 240.64 -28.97 1220.80 1278.43 50.02 300.00 1819.19 PLL is locked
510 513 513 240.68 52.52 1224.20 1364.24 50.03 300.00 1767.73 PLL is locked
510 513 513 240.70 -31.62 1228.23 1395.25 50.02 300.00 1799.35 PLL is locked
510 513 513 240.77 -14.89 1234.17 1483.99 50.02 300.00 1813.94 PLL is locked
510 513 513 240.78 12.46 1238.82 1602.80 50.03 300.00 1801.72 PLL is locked
510 513 513 240.86 14.70 1243.23 1366.21 50.03 300.00 1787.32 PLL is locked
510 513 513 240.79 20.76 1253.12 1306.15 50.02 300.00 1766.98 PLL is locked
510 513 513 240.84 -17.09 1264.37 1544.24 50.03 300.00 1783.72 PLL is locked
510 513 513 240.82 -24.78 1271.31 1543.98 50.03 300.00 1808.01 PLL is locked
510 513 513 240.83 12.11 1269.01 1425.37 50.03 300.00 1796.14 PLL is locked

P.S. I have been able to get the GLCD board to receive transmissions so can at least remotely pick up the values over serial for now :)

Martin calculates the diverted energy as the product of the number of cycles and the rating of the heater, scaled for the actual voltage. My first thought is the actual rating of your immersion heater is not what it says on the tin!  Martin didn't use a thermostat as he was measuring temperature and using that to override the energy diversion (but that code isn't in his sketch as published), hence he didn't count cycles when the thermostat was open, which you can do (but apparently didn't for the period above). "Diverted energy" is wrong, if you have an active thermostat it should really be "Energy available for diversion".

This sketch works well with a 3rd ct for diverted energy. here is a copy of Martin's original sketch with the 3rd channel added which I have been happily using a version of for several months now.

The differences for the 3rd ct are all marked as when I did it I wanted to track the changes I made in case of any issues, which there wasn't.

Regards Paul

Thanks Robert, I measured the full immersion power when I calibrated at the start (i.e. just on) and that's where the figure came from. As I understand Martin's code, it is calculating Power to the immersion, rather than Energy as per the following two lines

divertedPower=((float)divertedCycleCount*LOAD_POWER)/cycleCount;
divertedPower=divertedPower*(Vrms/240)*(Vrms/240); // correct power for actual voltage

The thermostat was closed as the figure for power1 is marginally positive/negative and the energy levels are hovering around the 1800J mark as expected (no AF on). This is why I'm a bit confused as to why the calculation doesn't seem to match what one would expect...

Silly question maybe - first line is percentage of cycles on i.e. proportion of full power, second line corrects for actual voltage (Vrms/240) but why is this multiplied twice? (Peak voltage?)

Thanks also Paul, this is what I would have done eventually! - very good of you to comment the additional lines - saves having to find every place where repeating code is required! How have you found the measured value to the calculated value - I see you are still keeping both values?

Power is proportional to voltage squared hence the need to multiply twice.

Did you take the voltage into account when you measured the initial power?

Thanks Martin, of course P=V^2/R *doh!*

When you say take the voltage into account, have I missed something obvious there? I simply clipped CT1 onto the immersion feed whilst on and took the reading from the serial reading...it was close enough to 3kW hence using the figure of 2890W

Do the readings for P3 look odd to you?

Update!

I think I've gotten to the bottom of this. I have been away for most of the week so happily assuming the system was ticking along with plenty of hot water. Of course something had gone awry and when I returned things seemed normal until I realised the water wasn't quite as hot as it had been...

The output from the Emon seemed to be flashing away, as was the immersion neon, but when I checked the serial readings the energy level was stuck on 3600. That pointed to the immersion stat, which at a glance seemed 'ok' but the thermostat wouldn't kick in and when it did still nothing was happening. That pointed the finger at the overheat cut-out which had tripped :o On resetting this there was still something odd going on so I had to take the cover off to see what had happened. One of the two contacts that are separated by the overheat hadn't closed again after the reset so I reseated it. Problem solved? Not quite!

Now the neon was coming on intermittently even though the output was fully 'on'. If I connected the immersion feed directly no problem. That pointed to the output board - I thought the triac might be fried but then why was it random? I ended up taking the board off and hooking it up to my 60W test lamp testing it with Martin's manual power level feature (very handy!). Lo and behold, it was the input driver that was only firing the opto-coupler intermittently - seems the combination of the LED and resistor (only 10R) was robbing the LED in the MOC3041. In my haste I hadn't considered the implications of this but having looked at the datasheet in a bit more detail, the series LED works just as well as a current limiting resistor in this case, so I removed the 10R and it seemed to be happy again.

Reassembled and yippee all is well (apart from no hot water this morning due to the boiler not kicking in - seems the indirect overheat stat had also tripped so must keep an eye on whether this happens again). It seems that the 'divertedpower', P3 values were showing as greater than the PV output due to the trigger not turning the triac on as expected so the energy wasn't diverted so in turn the totted up value of cycles equated to a higher value than one would expect - all seems fine now! At least that's how I understand it...

Thanks again for the input folks and hopefully this might be of help to someone in the future!

The choice of opto-trigger and series resistor is critical. Martin chose to use a high-sensitivity trigger (which needs less current) and used the logical high output as "ON" and connected the trigger between the output and ground, taking advantage of the pulse jack to make the connection. Robin used the standard trigger and as the output swing of the 328 goes closer to the GND than to the Vcc, he had to use logical low = "ON" and connect the trigger between Vcc and the output. It was impossible to choose a series resistor for Robin's trigger using the active high configuration that met all the worst-case combinations of component tolerances, and that is why he had to use the active low configuration and why he cannot use a series LED.  (I know because I did the sums for him. I have not done the sums for Martin's configuration.)

Also, bear in mind that Martin's "Diverted Power" is not the power actually diverted, only the power available for diversion. Martin used a temperature sensor on the tank to override diversion when the tank was hot, therefore it worked for him. It will not work for you if a thermostat overrides the energy diverter. But from your tale of woe, it sounds as if you too need to incorporate a temperature sensor that overrides the diversion.

Yes, I hadn't noticed the subtle difference that Martin chose the MOC3063 rather than the 3041 (which bizarrely I happened to already have my box of bits!). It seems to be behaving now anyway....I had intended to get one of Robin's output boards but had already started designing and then etching my own  - I may still end up doing this with a more 'permanent' set-up. I guess you don't learn unless you play!

Unfortunately, having a temperature sensor on the tank wouldn't be practical so I'm relying on the mechanical stat. I expect having never been used since the previous owners installed the tank, it is a bit ropey so I will be keeping a close eye on this. It seemed to be clicking on and off yesterday. Looking at the data sent from the Emon and the fact that as soon as the stat opens the 'diverted power' hits the limit, I think I have established all the scenarios where this has occurred:

1. The diverted power is way more than the PV output (this is the easy one to figure out)

2. The PV is more than the full diverted power, BUT importantly the export is way more than if the immersion was actually running (this is trickier to define)

Using some combined logic (it's easy to see this mentally but harder to state it logically!) I am using the GLCD board to light up the LEDs when I believe the thermostat has opened and the 'diverted power' is on full (and/or lots of export!). If this proves to be successful then eventually I can separate out the 'real' diverted power to calculate energy diverted. Then when I get round to sorting out the LCD I can make it clear when energy is being absorbed or when the tank is hot and the stat opens. In principle I could do the same on the EmonTX but I'll need to take a closer look at Martin's code to ensure there are no side effects and how to go about 're-triggering' the diversion when the stat closes again...for the timebeing it seems we have too much hot water anyway!

At first glance, you might be able to assume that if the available energy reaches the upper limit, then the tank thermostat has opened, but this is only always true if the PV capacity is less than the immersion load. If greater (i.e. you have a 3 kW load and 3.6 kW of PV), then it's possible to hit the upper limit and still be diverting energy. Other than with a ct on the immersion feed, I don't think it is possible to know with absolute certainty when diversion is actually taking place. Hitting the upper limit certainly means export is taking place, but you knew that anyway.

I ran through scenario 2 (we have 4kWp) and I believe the following covers it:

if (emontx.power2 > 2890 && emontx.power1 < emontx.power1+emontx.power2-emontx.power3)

This checks if the PV output is more than the max immersion load (not ideal I know as this can be lower) AND whether the amount of export defies this being the case i.e. if the export value more negative than the export+PV (i.e. the house) less the immersion then the totals won't add up...

P1 = -3000, P2 = 3500, P3 = 2890 is an example where the stat has opened

P1 = -1000, P2 = 3500, P3 = 2890 is an example where the stat is closed

Basically if the immersion is fully on, then there is no way that the P1 value can be that negative. At least that's how I've seen it behave - of course there may be an alternative scenario or one where the figures are very close together and nearly balance...time will tell ;)

Ok I correct myself ;)

With the scenario 2 acting itself out today (i.e. PV > Full Immersion load), my LED came on regardless of diversion on/off :(

My flawed logic was in the emontx.power1 < emontx.power1+emontx.power2-emontx.power3 part which will always be the case when exporting - duh!

So actually what is needed is to make use of what the house is actually consuming and remove the immersion factor - if this is positive then the immersion is still on, if the stat has tripped and lots is being exported then the value is negative as such:

if (emontx.power2 > 2890 && emontx.power1+emontx.power2-emontx.power3 < 0)

Some real examples:

Immersion on:

P1 = -163, P2 = 3205, P3 = 2932: P1+P2-P3 = 110

Immersion off:

P1 = -3100, P2 = 3217, P3 = 3131: P1+P2-P3 = -3014

Seems to make sense now!

Edit: In fact the same logic covers both scenarios regardless of whether the PV is greater than the max load i.e. if the house consumption isn't positive then the diversion has stopped :)

if(emontx.power2 >= 0 && emontx.power1+emontx.power2-emontx.power3 < 0) then the diversion has stopped and there is export going on