Archived Forum

Either there is something wrong with my parameters or dont yet understand MK2 or mk5a does not work as:

The led blinks even if CT is not connected (led does stop when AC is disconnected, also when inverter power is redirected through CT it calms down but still blinks occasionally.

...Need to test mk4...

ps. I wish the parameters (ports and calibration) would have been put to a separate #include file to make updates and version changes easier.

.... aha ... there is a fairly long calibration time before the rev5a starts to work. During that period the dump load is off - that is a not desired feature from my point of view, during initialization the rev5a should have dumpload on...

Anyway the Mk2i rev5a led and dummy load is blinking in a case there is no load in CT - that still needs some investigation !

Something is loading up the energy bucket ???

Testing why energybucket is filling even there is no PV circuit connected.

CT not connected tallymode:

9, 0
7, 0
5, 0
3, 0
1, 218
-1, 0
-3, 17
-5, 1
-7, 4
-9, 0

CT freerunning (ie not around any wire but connected to emonTx

9, 0
7, 0
5, 0
3, 0
1, 166
-1, 0
-3, 68
-5, 2
-7, 3
-9, 0

CT connected toa 40W bulb (i.e. load)

45, 1
43, 1
41, 135
39, 99
37, 0
35, 0

Tested with normal emonTX script, values exactly as it should be...

ct.voltageTX(234.26, 1.7);           // normal values from original script                            
ct.currentTX(3, (111.1*18)/150);  // This is the new burder resistor

W=40 Vrms=236
W=40 Vrms=235
W=40 Vrms=235
W=40 Vrms=235
W=40 Vrms=236
W=40 Vrms=235
W=40 Vrms=235
W=40 Vrms=235
W=40 Vrms=235

No answer in here really... still something odd going on ... with Mk2i rev 5a ???

Is your c.t. connected the wrong way round? If not, it should be!  Robin's convention for the c.t is export power (bucket filling) is positive whereas the emonTx convention is import power is positive. That would explain the bucket filling on import power with no PV connected. Try just reversing the c.t. on its cable.

Because the Mk2 (all versions) controls to balance the energy flow, changing the burden resistor won't have any effect on whether it works in principle, but it will affect the sensitivity and hence the accuracy of the balance between imported and exported energy;  and provided the calibration is reasonably accurate, it also will have no effect on the flicker performance.

Tested the transformer s  both ways. Really need to have high quality piccies of both side of emontx and working code for emontx to validate.  Its possible that something in the full emontx  build disturbs the code.

My mk2 cannot work correctly if the CT is not connected to anything!  I suggest you use a test rig as I have shown in Section 8 of my online article (linked from the Orem home page)

the emontx_ct123 sketch is nothing to do with my mk2 router code.  Although it Runs on th same hardware platform, it operates in a quite different way

(send from a borrowed iPad, on which I am struggling!)

The Mk 2 code also runs on an emonTx, with minor modifications for the Inputs and outputs - which are wired to different pins.

Load up the example sketch "emonTx_CT123_Voltage" and check the power when exporting - it may be a positive or a negative number. Reverse your c.t. and you should get the same value but the opposite sign. Fit the c.t. so that you have a positive number - that is the way the c.t. should point for the Mk2. If the two values are different by a few watts, that is normal and we think it is due to noise picked up by the analogue input. The fact that, when running Tallymode, you are seeing a cluster of values around zero tells me that the you should read about the same number each time, so this is not your problem.

Do you understand the basic principle of how the router works (are you familiar with Diverting surplus PV Power)? Where is your c.t.? As explained in that series of articles, it should be on the supply side of the point where the P.V. feeds into your system.

Thanks gents,1

1) emontx script used to verify that my ct and ac adc conversion works as it should 2) standard mk2rev5a used with different test rigs. 

My assumption is that slightly different port settings or alternatively built ct1 and ct2 hardware make the script fail. Rather than disassembling ct1 and ct2 circuits and without connecting switches its best to figure out whats happening before next user stumbles with similar issues with less experience in testing. Any thoughts around what missing switches and built ct1/ct2 circuits may do the the script ???

I'm sorry, Petrik, I don't understand much of what you are saying.

If you want to get a Mk2 Router to work, you need to be using one of my Mk2 PV Router sketches.  They all start with "Mk2 ...".  These sketches are all available from my Summary Page.  My Mk2 Router code is NOT on Github, and does NOT include the emonTx_CT123 sketch.  If you want to uses an "emonTx" sketch from Github to monitor your power, that's fine, but it will not divert any surplus power for you.  My Mk2 code requires one CT to monitor current, and one voltage sensor, plus the output circuit with its trigger and triac. 

Rather than disassembling ct1 and ct2 circuits and without connecting switches its best to figure out whats happening before next user stumbles with similar issues with less experience in testing. Any thoughts around what missing switches and built ct1/ct2 circuits may do the the script ???

I think you are worrying far too much Petrik.  If you do the basic checks and connect everything together in the recommended way, any of my Mk2 sketches really will detect and divert your surplus power :-)  

There is no need to move the hardware around. All you need to do is change the I/O addresses in the sketch. For example, if your c.t. is connected to CT1 (which happens to be AIO 3 - see the photo in part 8 where all the I/O's are labelled) then you change the line:

const byte currentSensorPin = 1;   // analogue

to read

const byte currentSensorPin = 3;   // analogue

Yes,

Obviously mk2rev5a does not work as with thest done so far, tested with tallymode showing correct results and many other tests. But led continues to blink without ct being connected,

 Also twsted with Emontx script which shows just correct values, i.e. Ct and ac volts seem to be operational and correct.

there is a missing piece of puzzle which is needed to make this functional, most likely something simple but not obvious. 

there is a missing piece of puzzle which is needed to make this functional, most likely something simple but not obvious. 

Petrik, the difficulty I'm having is that I don't understand what is bothering you.  In what way do you think that the behaviour of your rig is wrong?  There should be no puzzle.

Please can you explain exactly what you are trying to achieve.  In your initial post you said:

logging some experiences here about building a Mk2i here ... any comments and corrections to mistakes are welcome. Build is a standard emonTx with sandard CT from openenergymonitor shop. Firmware is latest rev5a when starting this thread. 1) Built everything, modified CT123 voltage script a

If you're trying to divert power, then you cannot use the "CT123" script;  you have to use one of my "Mk2..." sketches.  As posted, my Mk2 sketches all require the voltage signal to appear on Analog pin 2 and the current signal to be on Analog pin1.  On the emonTx hardware, Analog pin 1 corresponds to CT3.   So, when using my Mk2 software on the emonTx hardware, your CT needs to be plugged into the emonTx socket marked CT3.  That's the top socket of the three.

My tool MinMaxAndRangeChecker displays the signal that is being seen by the first four analog inputs.  If you make no changes, a working Mk2 system will show a signal on each of the inner columns (for Analog inputs 1 and 2), and no signal for the outer columns (Analog inputs 0 and 3).  This can be better seen if you earth your unused inputs.  Otherwise, if they are left floating, they will probably pick up stray signals from their neighbouring channels.

Robin:

Remember Petrik has changed the burden to 150 Ω so his maximum current before clipping will be 15.5 A at best  - that's only 3.5 kW so he has an extraordinarily sensitive set-up.

Any load exceeding 3.5 kW will never balance because he will be out of the linear region and into clipping. I don't think that is the problem yet, but it is likely to become a problem.

Also, he's using DIO 3 for the trigger output. If he's wired it tip-ring as it should be, it should be OK; whereas if he's wired it ring-sleeve, it needs to be active-high. That could be a source of confusion.

Petrik:

The Mk2 is a "Closed Loop Control System" - see http://en.wikipedia.org/wiki/Feedback 
The c.t. measures the total energy flow into or out of your house and when it sees energy flowing out, it tries to balance that outflow by adding some extra load. Because the amount of outflow varies but the extra load is fixed, you can have a small outflow for a long time before there is enough accumulated energy to supply the extra load for a very short time. Therefore it has to calculate the average over time and operate the triac so that the average is zero.

The energy bucket fills when the total energy flow is export and empties when the total energy flow is import, and the slightest imbalance in the export direction will slowly fill the bucket. When the energy in the bucket hits the trigger threshold, it fires the triac and that causes a large pulse of imported energy that rapidly empties the bucket. If you are not firing the triac, or you are not measuring the total energy flow in both directions, you will not empty the bucket and it will continue to fire the triac until it succeeds in emptying the bucket. That is quite normal operation and exactly as we expect.

How is your triac trigger connected? Where is your c.t. fitted? These are things you have not told us yet.

RW: Remember Petrik has changed the burden to 150 Ω so his maximum current before clipping will be 15.5 A at best  - that's only 3.5 kW so he has an extraordinarily sensitive set-up.  Any load exceeding 3.5 kW will never balance because he will be out of the linear region and into clipping. I don't think that is the problem yet, but it is likely to become a problem.

Yes, it's important to ensure that the measurement system can cope with the maximum rates of energy flow that can occur in either direction while the router is active.  An easy way to check this is by using my RawSamplesTool.  This tool will display all of the recorded voltage and current samples that have been taken during a single mains cycle.  When the maximum power is flowing, the "current" waveform should appear as a sinusoid which spans most of the available input range of the processor's ADC.  

If the peaks of the "current" waveform appear to be truncated or clipped, then it would be sensible to use a smaller value of burden resistor so that the sensitivity of the system is reduced.  Similarly, if the "current" waveform is very small, then it makes sense to increase the burden resistor's value so that more of the available ADC range is used.

Mk2_PV_Router_mini_3.ino  is a suitable sketch for checking that a Mk2 system is working correctly.  This sketch is fairly small, it uses floating point maths, and there is only one output mode.  This sketch also displays the energy change per second in Joules, which is ideal for calibration.  Surplus power (export) needs to give positive values.  If the displayed values are negative when surplus power is present, then the CT needs to be reversed or clipped around the other wire (Live or Neutral).  If the dump load flicks rapidly on and off when some surplus power is available, then the system is probably working correctly.

If a Mk2 system appears not to be working, then it's more than likely that the input sensors are incorrectly setup.  Use of RawSamplesTool will allow their performance to be verified.  Or the CT may simply be the wrong way around. 

Busy right now but let me straighten up as feel like you guys are talking too much about very basic stuff - read the slgorithm, read the code, have not yet understood everything on code level but its very simple idea. So this is what i have. : 1) used emontx basic ct123volts script to test the volts and amps, nothing more. Added a test for triac output to verify that it works too. 2) my testing rig is 40w bulb so sensitivity is needed with mk2irev5, also have a testing gti with 10-40w output. 3) when ct is disconnected (i.e. Not clamped) the bulb flashes occasionally (maybe once in 30-60 secs) so there is a bug somewhere consuming energy while there is no generation available. Anyhow the tallymode shows a distribution around zero. 4) tried mk2irev4, same thing, dump load flash at steady interval. ... Maybe there is a byte or integer that overflows if std emontx with all components built should work just fine without (selector switches etc. Extra hw presented in mk2 thread.)? Alternatively the bucket fills up slowly as my CT seems to read 1-2w extra all the time with mk2irev5 where as wi emontx ct123volts its steady 0, but this is a calibration bug then.

Still have not found time to check out the mk2i algorithm where the bias could be set to avoid unnecessary dumping of enery when there is no PV generation available. Also ordered a din rail mountable kwh meter to check out if it can log the amount of energy dumped, partially to analyze this unwanted behaviour and also partially to check out the real generation. Not sure how well it counts the energy in pulses though so will be an interesting experiment.

Anyway here is my DIN RAIL mk2i triac to have a very tidy installation and to keep the mains far away from close proximity of emontx.

Anyone having an idea of how much power the FET can take without cooling fins ? Can still add some aluminium inside the casing or alternatively extend the cooling fins outside the DIN RAIL enclosure.

That "FET" should be a Triac and I'd suggest a 4 degree per W heatsink as a minimum. This should be with fins vertical in free air - not inside a box.

I use a solid state relay in my implementation which essentially has the same components as your module and I'm thinking of improving the heatsink from 4 degrees per watt to something better.

The SSR is inside the box and the heatsink is on the outside. Surface temperature is about 30 degrees above ambient.

hth

Bob

I recently mounted a standard BTY41 triac inside a small aluminium diecast box.  After passing 3 kW through it for around 20 minutes, the entire box was warmer than I felt comfortable with.  I will therefore fit an external heatsink adjacent to where the triac is.

On another box, this time a plastic one with a large aluminium heatsink, the temperature rise was much less.  It seems fairly clear that heatsinks work well because of their fins - and air circirculation.  With no air movement inside a DIN Rail cartridge, I doubt whether much power could be usefully diverted before something overheats.

Oh sorry - triac of course ;-). Thanks, 4C/W is good guidance - what load are we talking about then ? Even more interestingly if a standard SSR can be used for MK2 it makes the story even better. What type of SSR was used ? Sounds like I need to cut one SSR open right now ;-)

Opened up FOTEC SSR-25 DA, these can be found in ebay for a fiver or so and with a heatsink for din rail (way more or should I say better as less than 4C/W) for a tenner. Inside there is a BTA25-800. Need to do some reverse engineering of the schematic.

Looks like the following drawing is very close to what FOTEK SSR 25 DA has inside, this drawing was find somewhere from internet so resistor values are not correct. First two diodes to drive the LED. Resistor R2 (MOC driver) seems to be around 100Ohm and R1 50Ohm. Dont really see any reason why a SSR like this could not be used for Mk2i. The high voltage side of the SSR is slightly different with one more resistor connecting both sides of the MOC through a resistor (which may be good for safety) but dont see how that would cause problems with operation.

So is it really so simple that SSR can be used with mk2i ???

[Edited by Moderator - the linked image no longer exists]

SSR works just fine but the mk2i unwanted behaviour continues, even if there is no PV generation mk2i diverts. Looks like the diverting happens at fixed frequency 0.35Hz (2.8s) with 40ms pulse width ??? (my Parallax USB scope is acting up and being very slow so can not be really exactly sure about the frequency).

Other than that the SSR + mk2i is just perfect !!!

Oh sorry - triac of course ;-). Thanks, 4C/W is good guidance - what load are we talking about then ? Even more interestingly if a standard SSR can be used for MK2 it makes the story even better. What type of SSR was used ? Sounds like I need to cut one SSR open right now ;-)

My immersion heater measures up at 3165 watts - our mains voltage is invariably nearer 250 than 240.

Bob

Looks like the diverting happens at fixed frequency 0.35Hz (2.8s) with 40ms pulse width ???

With the Mk2i_rev5 sketch, the shortest time that the triac can be 'on' for in 'normal' mode is 2 mains cycles, i.e. 40 ms.  If this occurs every 2.8 seconds, that's 2 cycles 'on' in every 140, or 1 in 70, or approx 1.5% of the time.  

If you had a 3kW load, that would imply a leakage rate of around 42W, which would seem a very high value.  But maybe your load is not as high as this?  If your dump-load is only 100W, then your background leakage is only just over a Watt, which doesn't sound too bad.

If you switch over to anti-flicker mode, the dump-load will still be on for the same proportion of the time (one-seventieth), but the cycle rate will be somewhat slower.

My primary dump load is 1kw. The leak is on 24h where as solar is only on around 10h. I feel its important to find out the reason why mk2i rev5a and rev4 behaves like that. Propably just by setting a bias to 50w instead of targetting zero could help ?

What is your "leak"?  On all of the MK2 systems that I've built,  I've never seen the energy bucket to drift by more than I Joule per second, so that's less than a Watt of leakage.

Because the Mk2a and Mk2i versions use integer maths rather than floating-point, the energy bucket's units are not in Joules.  If you were to display these values, there may well appear to be quite a lot of drift.  But with several million energy units per WattHour, that should not come as any surprise. 

Tallymode, in Mk2i_rev5a, should show you exactly what's going on.  Just do a run from -100W to +100W and see what the results look like.  You should see a fairly tight distribution of values around the 0 Watt point.  If your distribution is centred around any other value, then something is clearly wrong with your setup.  Similarly, if your distribution is all over the place rather than being tightly packed, then again something is wrong.

If your Tallymode results are as I've describe, then your Mk2 system is working fine.  There should be no need for you to set up any kind of "bias".

Petrik, here are some Tallymode results I've just taken with an emonTx-based rig that's running Mk2i_rev5a.

There are three runs, with 0, 40 and 1000 Watts.  The 'leakage' that can be seen in the first run is no more than a couple of Watts.  This is well below the anti-creep threshold of any utility meter, so should have no adverse effects in practice.

9, 0
7, 0
5, 0
3, 394
1, 105
-1, 0
-3, 0
-5, 0
-7, 0
-9, 0
 

1) About tallymode

My tallymode is not even close to that even - anyhow I use for PV generation simulation a very dirty GTI output instead of steady bulb load. This is my next worry, how well can mk2i handle fast varying input from GTI  as tallymode shows this wide distribution ??

This tallymode test was run both with SSR25 and Triac interface with very similar results. Tallymode.txt attached to this message.

2) Leakage, not significant

A good question Robin, the one about how much is my "leak", had not calculated it earlier but looks like its not significant at all - so nothing to be worried. Sorry for pestering about it, should have calculate earlier.

Leakage calculation 
0,35 Hz
2,86 sec between pulses
40 ms pulse width
80 W dump load
0,001    Wh/pulse
1,120    leakage Wh/hour
0,027    leakage kWh/day

3) Verifying the operation

To test that my mk2i Rev5 really works I attached oscilloscope to SSR-25 output and kept the PV generation simulation on same level and varied only the dump load. Results can be seen below just showing that the setup reacts to load changes. This verification tells that when dump load is reduced then the pulsewidth increases which is exactly how mk2i should work.

Hi Petrik, 

It seems to me that your system is working very well now.  If you are simulating your PV power with a non-resistive load, then I suppose it's likely that you will see strange results.  Might it be possible for you to do a check with a simple bulb or heater?

As your dumpload is only 80 Watts, that explains the occasional 'on' pulses that you were seeing.  As you say, its not a problem.  That's for letting us know.

When you are checking the behaviour of the dump load (triac), please remember that Mk2i_rev5 has a completely different kind of algorithm for power distribution than all previous versions have used.  In its "normal" mode, the triac has to remain on or off for at least two cycles; it cannot change every cycle as it could in previous builds.  When in AF mode, the two behavours are quite different.  In Mk2i_rev5, the triac stays on or off for a specified amount of time rather than for a specific amount of energy change.  I recall posting graphs of these two behaviours a while ago, but can't now remember where ... 

Finally got to have the PV system installed and can divert actions to mk2i. Having looked at the total consumption watts today its more than 1kwh that is sent to the grid. As the house is connected to a three phase system I guess some tweaking of the mk2i is needed - anyhow to start I guess that just one phase system shall do it.

Anyway if there is an easy solution for a three phase mk2i without tweaking the code too much would be interested to hear of it.

Total yield (10-12am is affected by one tree, on neigbours side who is on vacation). Before that its a forest.

Energy balance, all phases included

Here is how the load is divided between balances, -301W is the one where inverter is connected, total house consumption for all phases is 252W.

Present thinking is that a 3-phase Mk2 is not necessary, because to the best of our knowledge the meter sums the energy over the 3 phases before it transfers the chargeable unit into the registers, thus in effect there is only one 'energy bucket'. Of course if you can prove otherwise, we'll add that to our accumulated knowledge of electricity meters.

Sorry Robert, now dont understand the logic behind the statement. Yes - the meter sums the phases (this is what electricity company confirmed). Anyhow mk2i only detects voltage and current from one phase so the mk2i optimization happens in one phase neglecting the load in other phases.

Something I have missed ?

I can have an intermediate cure on personal level by transferring some more baseload to phase1 where my mk2i and inverter are connected.

 But knowing that there is a tendency from local electricity companies to recommend 3 phase inverters as most local houses have 3 phase line -  this transferring baseload will not help others interested in mk2i.

Btw mk2i works perfectly in a this setup: emontx + SSR + 8VAC DIN rail transformer + CT. SSR can take 5-8A load uncooled and when having a din rail mount on it that adds ability to take more power power. This SSR setup barely reaches 30C when operating 1kw heating element. This way all the low power components can be neatly boxed outside the main board and all 230VAC components inside the main fuse box.

The DIN rail AC transformer runs way more hot - around 50C.

Recall vaguely having read something about saturation current without a load making a transformer to run hot ???

edit - lets add here a log from all three phases how it works, at around 17.48 and 17.50 energy is moved to hot water tank regardless of Jacuzzi pump being on - meaning that energy is imported from grid more than would be needed.

I was assuming you only have a controlled load on one phase - that is the underlying assumption of the Mk2, and that the controlled load is approximately matched to the inverter output on that phase. But is that correct? Do you really have a 3-phase inverter but only 300 W total of PV, or is it 300 W per phase? It is the controlled load that matters, not the baseload which the Mk2 can do nothing about. What is the rating of your controlled load?

If your generating capacity really is that low, and your controlled load is comparable to the total capacity,  then you do indeed need to measure the power in each of the three phases and add them into a single Mk2 'bucket'.

Oh - let me try to give more information, first the personal setup.

3 phase mains, main devices
- Consumer devices like TV, computers etc. now mainly connected to phase 1
- Jacuzzi on Phase 3
- Two washing machines on Phases 2 and 3
- Oven and cooker in phases 1,2 and 3 depending on what part is used
- 13kw electric heating 3 phase system. When this is on there is no PV generation
- Two heatpumps (one used also as air conditioner) on Phase 1
- Hot water boiler , 3 phase star (3.1kw resistors) with center grounded. Normally heated during night tariff

1.2kW SMA inverter, single phase
- Connected to Phase 1

mk2i
- Connected and measuring phase 1
- Hot water boiler on phase 1 connected to SSR

So normally baseload is around 250w in phase 1 as baseload and 10-50w on other phases. Most consumer devices in phase 1 but sometimes oven, cooker, jacuzzi, washing machines etc may be on generating min 1kw load on other phases.

Then more generic setup:
- Normally 3 phase lines to the houses, with exeption of very remote summer cottages and older houses. This is mainly because of heating needs during the winter.
- Electricity companies are pushing for 3 phase inverters to have more balanced load, no regulation yet about unbalanced generation limits like in germany for max 4.6kw on single phase
- Heating system if electric almost always 3 phase
- Hot water boilers, mainly 3 phase systems
- Consumer devices wiring split evenly over 3 phases

So I am ok personally but knowing that there is interest towards mk2i or alike for 3 phase systems would be interested to co-operate on that one. The load for mk2i could still be single load or alternatively secondary etc. loads could be on other phases - but key would be to calculate mk2i variable P_sum for all phases with 3 CT:s.

I think I see what you are thinking now. Here in the UK, I had never heard of a domestic property having a 3-phase supply until I read about MartinR's (and Noah, but he's different, his is a converted industrial site so he inherited his 3 phase supply). Even many offices and small factories only have a single phase supply. I have a friend living on a farm in Scotland and he and his immediate neighbours - 5 farms and a bungalow all told - all share the same single phase supply.

The difficulty I see with a 3-phase Mk2 (Mk3 ?!) would be deciding on the algorithm for sharing the load. I have not thought very much about this, but it would have to work on a common energy bucket so as to remain compatible with the meter. Each phase could/would have its own Mk2 and controlled load - or maybe loads, and each switch would make its own decisions independently. I'm not quite sure how that would work if part of the controlled load was 3-phase. And I can see problems with the anti-flicker mode because in effect everything would be happening 3 times faster as the meter's energy bucket appears to be the same size whether it is single or three phase.

Using the interrupt version, it might be possible to run all 3 phases in one processor but with a reduced sampling rate. If the reduced rate was not acceptable (or more monitoring was required), there would be a case for 3 stacked processors communicating after the fashion of MartinR's full-fat monitor.

My house is just about have its single phase supply changed to a 3 phase supply so I have been looking at a similar thing. I have been adapting Robins code to suite. (with the very helpful guidance of Robert as I don't have much knowledge of code).

Just to clarify, do you have one single meter for all the 3 phases or an individual meter on each phase?

If the latter, which from what you describe it seems not to be, you just need one Mk2i on phase 1 with the controlled load on phase 1.

If the former then you would need a Ct and voltage measurement on each phase with one energy bucket, though the load SSR could be on any phase and a tweak of the code.

Single meter on all three phases, the meter sums the phases so Solar PV inverter production in phase 1 gets summed to the consumption on phase 2 and 3.

The voltage is very stable here (<1% variance in voltage in reality) which means that in reality would only need 1 AC voltage source and 3 CT:s. If I remember correctly there is a variable called P_sum in mk2i which would just need to be amended to read the three CT:s and sum it all up. That way the single mk2i energy bucket would have real load from all phases included.

I really like how elegantly mk2i does it work. Here you can see between 11:55 to 12:20 how around 300-500w is pushed to the hot water boiler using mk2i (emontx + ssr setup).

Now starting to miss datalog of how much power is going to the hot water boiler. Maybe it would be possible to easily output some internal variables using rfm12b routine that already exists in mk2i code.

Petrik: Look at MartinR's code  "Solar PV power diversion with emonTx, emonGLCD and temperature measurement" http://openenergymonitor.org/emon/node/1535

Petrik, I'm running MartinR's code to divert surplus power AND update emoncms, and you can see a screenprint of the data I get at http://openenergymonitor.org/emon/node/2527 if you are interested.

Paul

Thanks chaps - browsed through the thread and that could be an alternative.

Is there a wiring schematic somewhere for Martins system ? Got an understanding that its a 2 CT system but also saw a note of 3phases which looks promising. Need to dig more info about this when I have time.

Martin has also done a 3-phase monitor-only using 3 stacked emonTx's: Full-fat 3-phase http://openenergymonitor.org/emon/node/1170

Wiring is essentially the same as Robin's - with changes to the I/O pin numbers (and you need to check the triac drive polarity - active high or active low) it should run on your hardware. With one voltage input you just don't monitor the PV infeed - the controller works exactly the same as Robin's.

Is there a wiring drawing somewhere for Martins sketch ?

Reading the script does not really tell much about how the CT1 and CT2 are supposed to be hooked and which way triac is fired. Also there seems to be hardcoded 240Vac in to the scipt. I guess that CT1 is the mains for phase 1 and CT2 is for PV inverter. The purpose of SYNCPIN and SAMPPIN i dont yet understand.

Just ordered my 5th emontx to try out Martins sketch. What I read from the code is that it also could calculate emontx.power for at least one more additional phase making it even more versatile for my 3 phase environment.

The test rig I have is a small GTI inverter hooked up to a power supply and dump load which enables to have a very realistic testing environment. Also having a temperature sensor there allows that one to monitor the SSR (=triac) temperature and put a safety limit not to fire triac if temperature is too high.

Additionally it looks like some calibration may be needed... ?

I also don't quite understand MartinR's sketches either. I can see how the slave and master work to transmit the data but I cant find any receiver/diverter/display sketch anywhere.

Are you two talking about different sketches?

Martin's "emonTx_Solar_Controller_Temperature_PLL.ino" uses the standard RF packet format in line 91:

typedef struct { int power1, power2, power3, Vrms, temp; } PayloadTx;
PayloadTx emontx;

So that will interface with whatever base you use and he says it works fine with the standard emonGLCD sketch.

The hardware interface is defined in line 64 onwards. SYNCPIN and SAMPPIN are there purely for monitoring - don't use them if you don't want to. The triac connection is DIO3, which is the pulse socket. If you look at line 331, it's pretty obvious that the output is active-high and the opto-emitter is therefore connected between the output (plug ring) and ground (plug sleeve) with the appropriate series resistor as he mentions in the first post in the thread.

"Reading the script does not really tell much about how the CT1 and CT2 are supposed to be hooked  ..."
I think knowledge that it was derived from Robin's work, plus Line 21, says it all.
 

The Full-fat 3-phase monitor again uses the standard RF packet format (line 133 of the master sketch) - all you need is to lift a copy of emontx_lib from the standard example sketches. Plus of course customise your GLCD if you need to display all 3 phases separately, or add the powers if you don't.

All of my Mk2 PV Router sketches only use one CT, this being to measure the current/power at the supply point, next to the meter. 

Martin's equivalent code supports an additional CT, to measure the amount of PV that is being generated.  The difference between these two values reveals the amount of PV power that is being consumed on-site.

By including both CTs in the same processing loop along with the voltage measurement, continuous measurements are obtained for all three signal sources.  This is quite different than the standard '123' sketch in which each CT is processed in turn for a fixed period.

The way how I understand the both scripts so far is that there is regular timer based interrupts at which moment the V and I pairs are measured.

As the timer runs constantly and locks during phase 1 rising zero cross point it should be fairly easy for 3-phase system to determine which are the points running 120 and 240 degrees later where the raising edges for phase2 and phase3 starts. The Voltage measurement could happen only for phase1 and stored into a StoredV[samplecounter] table where it could be recalled for processing StoredV[timer-120degrees] * Irms.

I.e. in mk2i something like this could implement 3phase system

- For timer sript add CT2 and CT1 and for voltage conversion add line StoredV[samplecounter++]=SampleV;
- For start of a new +Ve cycle reset samplecounter = 0;
- In main loop calculate all phases 

Needs more studyinig how to implement this - still dont understand code well enough...

----

OK - understood, wiring is same for CT1 and Vac for both robins and martins scripts.

Having studied now Martins script I still dont understand why there is SAMPPIN and SYNCPIN in use ? Those are surely not used as interrupt sources but dont get why those are there at all ? Maybe just to debug the operation of the device.

Maybe I go with the route of getting the PV generation output using bluetooth from SMA - dunno yet. Adding another CT just to measure PV generation does not sound right as there is only 3 CT inputs and really measuring consumption on all 3 phases should be the ultimate target.

hmmm. maybe something like below could be added to mk2i to show on the rfm12b package the load duty cycle which could be by knowing the load (e.g. 1000W) then converted into kwh diverted in emonGLCD.

#ifdef ADC_TIMER
// This is the Interrupt Service Routine for when the ADC is fixed timer mode.  It is
// executed whenever the ADC timer expires.  In this mode, the next ADC conversion is
// initiated from within this ISR. 
//
void timerIsr(void)
{                                        
  static unsigned char sample_index = 0;

if (triggerNeedsToBeArmed) {dytu++,};

if(dutycount > 500) {duty=0;dutycount=0;}

....

and then somewhere in main()

....

if (dutycount >= (500-1)) {emontx.loadduty=duty/dutycount;}

If you make the number of samples per cycles an integer multiple of 3, then the "stored array" of voltages becomes very easy and the same (or very nearly the same) phase correction should apply to all 3 phases.

If you read my answer again, I did tell you what SAMPPIN and SYNCPIN were for. The full explanation is in MartinR's first PLL post. 

Thanks robert - I do understand the output those are providing but do not understand how those are used for the code in PV power diverter ? To me it looks like those are there for the fun not for any real use ?

Sorry completely missed that part, now crystal ...

Maybe for 3-phase mk2i implementation RMS power and voltage could be used. As there is no voltage measurement for other phases than L1 therefore RMS method would simplify algorithm to be very easy to be implemented on mk2i? ???

For PV geneation was thinking to give nanodesmamonitor a go, perhaps could get that working...

I don't understand the point you are trying to make. Are you trying to say that you only want to calculate apparent power (VA) and estimate real power based on unity (or some other) power factor?

(And "RMS Power" does not exist. It is a nonsense. You mean average power.)

Yep, meant to say RMS current and voltage like explained here: http://openenergymonitor.org/emon/buildingblocks/ac-power-arduino-maths

Using apparent power (apparent_power = root_mean_square_voltage * root_mean_square_current) does not really matter at which point of a wave the calculations start so maths could be done even the voltage phase is not in sync with phases were current is measured - as long as one full 360 degree cycle is summed together. So for RMS voltage i could use phase 1 and then could measure RMS current be measured from phases 2 and 3.

That would assume PF=1 which it rarely is but still better than neglecting phases 2 and 3 completely. If really want to include phase 1 pf could calculate PF for phase 1 and multiply apparent_power with PF for phases 2 and 3 but dont see that necessarily adding value.

In mk2i code there is a clear point where a new 360 degrees cycle stars so integrating RMS method there should be fairly easy.

Dont see a benefit of measuring voltage for one phase and then delaying it by 120 degrees to calculate instant power for each point compared to using RMS method.

How does this sound ?

The normal reference is the voltage wave. You can average (voltage, current, power - it makes no difference) over any part of the wave. The starting point makes no difference. Normally, and only because it is easy to identify, we use one of the zero crossings.

The point about power factor is it does not have to be the same for all 3 phases. If the load is properly balanced, it will be; but for an installation where there are single phase loads distributed over different phases, each phase will have its own, different, current wave and different power factor. The 'delayed array' sketch assumes - as it clearly says in the comments - that the voltage wave is the same shape and amplitude for all three phases. This too is not likely to be strictly true, but it will probably be the best approximation available without monitoring all 3 voltages.

As always, the quantities you measure will be determined by the accuracy you need. If you have purely resistive linear loads that are always accurately balanced, you only need one voltage and one current and P = 3 x V x I. If the voltages remain equal but the loads are different but still resistive and linear, P = V x (I₁ + I₂ + I₃). If the loads are different and non-linear and/or reactive, for an accurate answer you need to multiply the samples of V and I and then take the average, separately for each phase, which implies knowing or approximating the three voltages, which is where we started from.

All you can do is evaluate the likely accuracy of whichever measurement method you will use and decide whether it is acceptable for your purposes.

Yes, improving the accuracy is the main target. With only 1 phase system a lot of the load in 3 phase network gets neglected and therefore ample measures needs to be taken to improve accuracy. Anyhow most limiting factor is the time, even though implementing 3 phase measurement using RMS method is straight forward it most likely takes a couple of days which is difficult to spare.

Today spent most of the day with nanoderfSMAgateway (nanode + bluetooth module) and SMArepeater (jeenode + bluesmirf). Learned a lot but could not get either of those working.

Anyone on this board who could advice ?

Ok - decided to bite the bullet and took the martins code and modified that for 3 phase use. First tried the Vrms * Irms method but that proved to be fairly inaccurate and therefore generated a table where the voltage samples are stored and the read afterwards. Implemented code is really a bruteforce attack to this issue - but seems to be working on the desktop.

Instead of emontx decided to use emonshield, that has 4 CT inputs which comes very handy. CT1-3 for phase monitoring and CT4 for PV generated power monitoring. Additional bonus is that now I can log pv generated and diverted power to emoncms. Also if this approach works then can remove one emontx that is currently being used for 3 phase monitoring.

This version assumes 1 phase dump load. In my case I have a warm water boiler that has a star connected 3 phase resistor there - but as its a star I can just use one resistor as dump load by having a SSR to connect that on and off. This code should work also with a 3 phase inverter dump load inverter as the available energy (in bucket) is calculated as a sum of all three phases - same method I have understood the 3 phase electricity meters use. The limitation is that energy generation only to 1 phase can be monitored, but for any reasonable accuracy it can be assumed that a three phase inverter produces equal amount of power for each phase.

The components used for 3phase energy diverter / 3 phase energy monitor are:

- 1 x EmonShield with 1 AC transformer and 3 CT:s

- 1x Arduino UNO for emonshield and adequate PSU

- 1 x SSR for switching the load on and off.

- 1 x additional CT for monitoring PV generation

First version of the code attached. Still needs to test the 3phase accuracy but first need some more CT:s ...

Slowly getting there. Today finally managed to test that 3 phase power calculations using delayed V array for each I sample. Looks like it does work with slightly modified script compared to above, of course.

In big picture when putting 3kw (3 x 1kw) load on did get around 1kw per phase. Anyway for small loads the value was -7w instead of real +20w for phase 2 and similar difference for phase 3. Need to look more carefully into phaseshift as this looks like an issue of what V sample is used for each I sample as did not used phaseshift at all, just new V samples. The samples are 9 degrees apart so there should be a huge improvement of implementing phase shift formula for phases 2&3.

Hooked up also LCD to emonshield, that is very handy and seems to be running just fine in 4 bit mode with no extra pins left with uno+emontxshield+rfm12b and LCD. Anyway without any optimization Arduino UNO is running only at 40 samples @ 50Hz. Maybe this is enough for decent diverting operation, dunno ?

Really interesting that phaseshift needs to be around 2.0 - 2.7 for apparent power to match real power... tried to check if there is difference if Voltage is sampled first or last but no real change.

Apparent power looks like being on level 30-50W without any load.

...back to to drawing board with apparent power calculation...

I think there is an error in the way Martins diverter calculates apparent power. When using latest samples in square gives too high area for Vrms * Irms, rather it should be Vrms * Irms(new,last) to calculate an area that match voltage.

Ie the previous sample should be used in this calculation instead like this example:
sumI1squared+=((long)newI1*lastI1)
lastI1=newI1;

With this method the phaseshift settles around 1.6..1.7 - hmmm, maybe also need to look if the Vrms should be calclulated using "average" of last pair instead of last sample squared.

Edit - dunno, taking last and current sample reduces apparent power too much. Anyway this average between current samples makes some sense as there is only a limited number of samples available for calculating apparent power so similiar to "phaseshift" may occur with apparent power as with real power calculations ???

May be barking a completely wrong tree but after some more testing it starts too fomulate a pattern: When changing the apparent power calculations towards something like below the apparent power seems to be more accurately calculated both at small and high resistive loads.

      //sumI1squared+=((long)newI1*lastI1);
      sumI1squared+=((long)newI1*(lastI1+(((((long)newI1-lastI1)*0.3)))));
      fI1Offset += (sampleI1-I1Offset);
      I1Offset=(int)((fI1Offset+FILTERROUNDING)>>FILTERSHIFT);
      lastI1=newI1;

Here is a piccie of the normal 2x20 LCD being integrated to 3-phase diverter based on Martins initial code and emontxshield.

I did build this setup with EmonShield . Tested  today without SSR. It seems to work right out from box with code published by Petrik. I did simulate PV generation by reversing CT3 where was more consumption than CT1 + CT2.

I have now burden resistors 33ohm installed to CT1,CT2,CT3. That means CT's scale is 0-100A. Is there any benefit to use smaller scale for measuring the current, as I currently have 3x25A fuses on mainswitchboard? Fast calculated my burden resistor should be about 120ohm to achieve 30amp maxium ad-conversion value.

Is there still an issue with this apparent power calculation?

You overload a current transformer by increasing the value of the burden resistor, which makes it put out more voltage hence more power. If you increase the resistor too far, the transformer will distort and not give you the correct output waveform, so your power calculations will be wrong. When that will happen depends on which c.t. you use and what its VA rating is. The standard one (YHDC SCT-013-000) should give acceptable results with a 120 Ω burden.

Petrik can best answer your question about his rms calculation.

I did the test rig and found out CT1 realpower measured ok. CT2 shows 80% less than reality. CT3 always negative with almost correct reading. Diversion starts when CT123 sum negative. 

You need to adjust the calibration constants for the c.t's that are not accurate. But first, make certain that the two parts of the core meet properly and there is no foreign matter between the core faces resulting in an air gap. The inaccuracy could be due to the c.t., the burden resistor, or both.

CT-installations are OK. Calibration should be enough close to get proper results.  Now I have about 1kw load. Load is quite balanced to all phases. Printed from arduino have following results:  L1=369.72w   L2=40.35w    L3= -231.70w  .   VAC and HZ measurements are OK.  I have not yet skill to analyze the code how phase measurements are arranged. I'll understand  3-phase theory and reactive components, but this needs much more. If I would have time to get new hobby, this is it. 

"Slowly getting there. Today finally managed to test that 3 phase power calculations using delayed V array for each I sample. Looks like it does work with slightly modified script compared to above, of course."

Perhaps Petrik' published code is still in develepment phase and not ready to test. Luckily idea of code start to open slowly...

Ah - i will publish a working code when back on my pc. Been waiting for analogue meter to dig deeper with apparent power before sending it out.

the code earlier here was a concept idea not the one with testing implemented.

Sorry for confusion.

I don't really want to get involved with debugging your code Petrik but as Zakke was trying to use it I did glance at it and noticed one immediate problem in your voltage shift...

phasesample=samples+(P2degree/360*NUMSAMPLES);
if (phasesample > NUMSAMPLES) {phasesample = phasesample - NUMSAMPLES;}

there's a couple of problems with this code, phasesample and samples are integers so (P2degree/360*NUMSAMPLES) will always return 0 and you won't actually shift at all. You should use (P2degree*NUMSAMPLES)/360

Also phasesample should always be less than NUMSAMPLES or you will exceed the bounds of your array and voltage will be garbage if (phasesample > NUMSAMPLES) should be if (phasesample >= NUMSAMPLES)

You also don't appear to be compensating for the extra delay in sampling for CTs 2-4.

Hi,

Sorry it took so long time even briefly come back on this. Had my daughters wedding this weekend and this once in a life moment has taken all the time and priority over anything else for past couple of weeks(www.facebook.com/#!/ecueditor/posts/512373418841507).

The code introduced here earlier was a concept idea like said. The attached is a code I have started to test in 3-phase system but has not put it yet in production as I have this issue of PF (reactive power) getting odd readings. Also looks like there is some leakage when using old rotation type meter when testing with a real inverter as generation. Not so much when using reversed resistive load like Robin is using.

Hopefully after next week when things are settling back to normal shall get into this reactive matter in more detail and then have more thorough testing done.

I did try this with 60w resistive load on every phase. Found apparent power measurement ok. Realpower measurement is ok on phase 1, but other phases gives steady negative sign results with less than half of Real-realpower.

Could you check if you have the vac transformer connected to phase 1 and phases in correct order.

Yes, Now double checked everything. Here is a picture from my test setup. I have 60w bulb on every phase. Old analog powermeter was also fitted to test rig, but it was not working. I will get new used one maybe next week. 

Couple of parameters I did change when try to get working: SUPPLY_VOLTS,  VCAL,LOADPOWER,and  I1CAL, I2CAL,I3CAl,I4CAL to match my burden resistor.

Here is sample what get from serial monitor:

4.99 511 508 511 512 513 Vrms:228.94 rP1:57.96 aP1:62.00 rP2:-30.73 aP2:59.99 rP3:-5.29 aP3:53.26 rP4:54.50 aP4:60.20 dP:0.00 TC:2.81 aW:0.01 f:49.93
4.99 511 508 511 512 514 Vrms:229.05 rP1:56.61 aP1:59.60 rP2:-30.50 aP2:59.33 rP3:-3.01 aP3:53.37 rP4:53.51 aP4:59.38 dP:0.00 TC:2.81 aW:0.00 f:49.93
4.99 510 508 511 512 514 Vrms:228.98 rP1:53.90 aP1:56.09 rP2:-29.76 aP2:57.11 rP3:1.94 aP3:54.78 rP4:53.02 aP4:60.85 dP:0.00 TC:2.81 aW:0.00 f:49.93

CT 2 and 3 realpower is negative and surely wrong measured. CT4 is connected also to Phase 1.

I have not touched PHASESHIFT parameters.

Because real power is so much different from apparent power, this is surely an indication that either the phase rotation is wrong (i.e. CT 2 is on phase 3 and CT 3 is on phase 2), and/or the phase calibration is badly wrong - is the calculation of the index into the array of voltage samples correct?

Phase rotation was wrong. I did try to change CT1 and CT2, but actually phase rotation was same because VAC-measurement was also shifted from CT2 to CT1. Thats why I supposed the rotation was ok. When I replaced CT2 and CT3 then calculations was correct. Thanks for help.

There is little unbalance between phases. Also 2-3 volts diffirence between phases. Now I have 1kw total realpower measurement on emontx. The electric company's energymeter measures 60w more. I dont know if this is causing problems when divert.

I would like to test diversion functions, but I dont have possibility to do it right now, because overproduction is always on same time when I have to be outside home :(  At september the sun is not so high anymore in Finland.

Couple of sunny days behind now. Diverter works nice and steady. Found out poor quality of electric network.  I can see more than 10 volts diffirence between phase voltages. Propably our household is quite far away from transformer site. Also house load is impossible to get balanced. House's base consumption runs between 600 and 1100 watts. Error to real measured consumption is approximately 30 to 90watts.

I think I should be able to get more accurate readings with 3x voltage and current measurement.  Currently only possible option would be 3x mk2 diverters. Also remote RF load control suits well to my dual immersion point. 3-phase RF control should be able to arrange with one pair of rfm tranceivers. Of course both immersion tank should be equipped with three SSR, one for every phase. 

Kakke, you may be interested in some code I've posted on another thread.  As written, it measures two power streams on one phase, and two on another phase.  But it could easily be changed to measure one power stream on each of three phases.   That would allow you to take all your measurements (3 voltage and 3 current) with just one emonTx or Uno.  With the ADC free-running, there are 32 sets of samples per 50 Hz mains cycle.

Reinstating the diversion logic for surplus power should be fairly straightforward, the main processor has plenty of spare time.

Yes, there is a margin of error when using only apparent power for 2 out of 3 phases. Like said its a few tens of watts per phase. My strategy is to allow some grid electricity in the house as the hot water is needed to be heated anyway - as adding two more voltage sources does add complexity.

Which part of the country are you zakke located ? 

I am still running Petrik's 3phase energy diverter code. I can live with some measurement error on phase 2 and 3. But one thing I cant understand. 

Here is an example,

October 16th daily totals:

Solar production 10.2kw (measured by solar inverter)

Consumption 19.2kw   (measured with emontx 3phase diverter CT1,CT2,CT3)

Diversion 4.2kw   (measured with emontx 3phase diverter, calculated value)

Paid consumption 23,4kw   (measured by electric company)

Attached barchart picture is showing what I pay for. I am able to get it from electric's company net service.   It's showing consumption from electric network same time when solar production is over base consumption.   The paid consumption is exactly same as diversion and consumption calculated together.   Those values are generated by energy diverter code.

This is happening every day when we have overproduction available to divert .  Daily emontx calculated energy+diversion match with real paid daily comsumption.   I cant understand why diverted power is add to electric bill. 

"Which part of the country are you zakke located ?"

I live in west coast.  Plenty of sun here this year :)

Possibly a silly question: You are measuring the energy at the correct places?

Here is a schematic of current connections:

First, CT1 - CT3 are measuring the nett energy imported. Your meter may be set to register only the energy imported and to ignore the energy exported.
Second, the calculated energy diverted might not be the actual energy diverted. It is the energy available to be diverted. If your water heater has a thermostat, that will prevent energy from being diverted but Martin's code calculates it by counting the number of cycles when the triac is turned on. This was OK for him because he used the water temperature measurement in his emonTx to inhibit the diverter, so the triac stays off and his thermostat never needs to open.

So I think you generated 10.2 kWh of which you calculated that up to 4.2 kWh was diverted, 23.4 - 19.2 = 4.2 kWh was exported and at least 1.8 kWh (= 10.2 - 4.2 - 4.2) was used in the house.

And those connections look absolutely correct. It was a silly question (but worth checking) and I think it is just coincidence that the two numbers are the same or nearly so.

I can give a vote for your first quess. Energy meter is remote controlled by electric company and can be programmed to do anything. Before I bought my first 3.25kw PV panels and 6kw inverter, I did ask how the metering is done. Company said that measuring unit is 1 Wh and it is sum of all three phases. So it should be able to import and export same time inside 1Wh window. Now it seems like there is two registers, one for import and other to export. I have to discuss more with the company.

I cant see coincidence with the numbers. Pattern is easy to see from other days also. So currently real paid consumption is emontx p1+p2+p3 + diverter power. Of course there is something +-500w diffirence with real values.

"So I think you generated 10.2 kWh of which you calculated that up to 4.2 kWh was diverted, 23.4 - 19.2 = 4.2 kWh was exported and at least 1.8 kWh (= 10.2 - 4.2 - 4.2) was used in the house."

Yes, somehow electric company got 4.2kw free of charge. No problem personally, but the idea is exported also.

Here is a picture when divert fuse is open:

Yes, that shows how it thinks the energy is being diverted when it is not.

"So currently real paid consumption is emontx p1+p2+p3 + diverter power."  I am not sure even that is always true. Have you read about energy meters in Building Blocks? We think you can send upto 1 Wh (3600 J) back and forth through the meter without registering. If you export more than that, you donate it to the company. If you import more than that, you pay.

Have you got ENERGY_BUFFER_SIZE and the thresholds set correctly for your meter? If it is too large, or the thresholds are too close to the limits, that could be part of your problem.

Unfortunately, unless you can synchronise the meter's "packet" and your buffer, you can never be certain that you will not donate or pay for energy at some point as the two drift relative to each other. But when that happens, they synchronise again.

"somehow electric company got 4.2kw free of charge" Nothing new there! They write the rules. They ALWAYS win.

When a PV Diverter is working correctly, it is important to ensure that the meter's LED is not flashing.  If the LED were to change state every time that the dump load is activated, that would be a very bad sign.  As Robert has mentioned, incorrect calibration could cause this effect, which may account for what is being seen here.

An easy check would be to run the diverter system in "normal" mode rather than with any anti-flicker measures in place.  By this means, the router would maintain the system's energy level within a very tight range, which should sit well within the "sweet-zone" for any known type of meter.

In "normal mode", the upper and lower energy thresholds need to be very close together, preferably coincident.

Now energy company said that they measure all phases separate.  They have changed something after last contact.   So if exporting some energy on phase 1, it is not possible to get back from other phases.   Thats why diverting makes more bill right now.    When solar production is high, then more accurate formula (p1+p2+p3 + divert)  will be in this case.

 I can see that only possibility is to install MK2i based emontx one for every phase. It means that diverting and some importing is going on same time, because energy transfer between phases is not possible.

Energy company won this time.

As I mentioned earlier in this thread, on 23/10, a single Atmega platform should be able to monitor the flow of energy on all three phases at the same time.  It should also be possible to include a separate "energy bucket" plus power diversion logic for each phase. 

Then you would only pay for what you import, not what you divert :)

Solution like that would fit nice to my setup.  All software components seems to be already done.   In other hand "Stacked 3x emontx diverter" solution would allow solar PV measurement. Then Serial data transfer between EmonTX boards should be implement to current PLL-based solution.

By way of completion, a link to the 3-phase version of my Mk2 PV Router website could usefully go here. 

This uses a new PCB with three transformers, one per phase.  A single Atmega processor repeatedly samples the voltage and current on each phase and can divert any surplus energy to one of more dump-loads.  Datalogging is supported via the on-board RFM12B, and SSRs can be controlled directly by running the processor at 5V, with a separate step-down stage for the RFM12B's 3.3V supply.

I'm not aware of any commercial system on the market for diverting surplus power in a 3-phase environment.

Now I have a nice setup of Petrik's sketch working with output to 4x20 LCD. Thanks to Petrik and Martin! Also actual Energy bucket is displayed and SSR (40A) is working.

But I have problems with sending data to emonGLCD. I have already checked the node (10), group (210), emonGLCD and emonTX Shield are with same frequency (433Hz). The RF-part of Petrik's code I didn't touched. emonGLCD has same typedef struct, but all emonGLCD displayed values are still 0.

Is there anybody who has a working sketch for emonGLCD to use it with Petrik's code (emonTx Shield)?
Should I test emonTx Shield with Raspberry Pi to determine error in emonTX or emonGLCD.

In your GLCD sketch, you copied the data structure from Petrik's code, but did you keep the same names for the elements as in the original structure? (See Part 2 of the Building Blocks' RFM12B article to understand what I mean by that. If the names don't fit the rest of the GLCD code, the values are disappearing into the universal bit bucket.)
Also, have you got the Node ID of your emonTX in there, as the source of the data?
(I've not checked Petrik's sketch, so these are only points to check.)

If you need my GLCD test sketch, ask. It receives anything from anywhere, and displays bytes.

[Edit:]

The Payload structure you have, if I've looked at the correct sketch, is:
typedef struct { int power1, power2, power3, powerPV, powerdiverted, Vrms, temp; } PayloadTx;

You'll need to modify the 'standard' GLCD sketch to either add the three phase powers together, or (harder) carry the values through to display them. If you are going to heavily modify the sketch, there are notes in the .md file on GitHub alongside the SolarPV sketch that should help.

Here is the 'GLCD Debug' sketch.

That's interesting, I've never been able to upload .ino files, only .zip ones.  Has something changed?

The "File attachments" dialogue states that:  Only files with the following extensions may be uploaded: zip jpg jpeg gif png txt doc xls pdf ppt pps odt ods odp tar.gz gz tar sch brd java pde docx ino svg.

Maybe the ability to post .ino files is a moderator's privilege ...

Thank you Robert for posting your GLCD Debug sketch. It's a very useful tool. Now I received data of emonTx 3.2 (emonTxV3_RFM69CW_DiscreteSampling) and also of emonTxShield 2.5 (Shield_CT1234 sketch), so my hardware is ok.

But I have still problems with emonTxShield 2.5 and Petrik's sketch to send data to GLCD (Debug sketch). Maybe rf is insufficient implemented or different configured. The numerous hex-commands in Petrik's rf code are intransparent for me. So I'll further grapple with.

Is there anybody who has an adapted working code able to send data from emonTxShield to GLCD based on Petrik's code? Please post it. Thx Wilfried.

Without looking at Petrik's sketch, I am prepared to bet the commands to set up the RFM12 are the same as MartinR's PLL Diverter, and there is some documentation for that:Solar PV power diversion with emonTx using a PLL, emonGLCD and temperature measurement, by Martin Roberts

If you need more, there's always the Hope data sheet for the RFM12B, which should help you with decoding the commands (though it probably won't help you to learn why they are there).

The obvious question: are your I/O pins correct? I don't keep a close watch on the Shield versions, if the pins have changed between the version of the Shield that Petrik used and the one you have, there a possibility that the I/O pins are wrong.

Thx Robert, I studied Hope data sheet and checked hex-commands and I/O pins, all looked good. After finishing compairing codes between MartinR and Petrik, I found out the problem for sending to emonGLCD. If using part of MartinR's code:

sumI1squared+=((long)newI1*lastI1

instead of Petrik's code:

sumI1squared+=((long)newI1*(lastI1+(((((long)newI1-lastI1)*0.3)))));

sending works fine. Is it a performance problem if using the complexer mathematic operation for each power? MartinR's approximation I think is sufficiently for me (I use it with NUMSAMPLES = 38 - samples enough).

Obviously the maths will take a bit longer to execute. Are you saying that with Martin's maths it works fine, yet the radio doesn't work with Petrik's maths? I have no idea (without actually measuring it) whether time to execute was your problem, I think it's much more likely to be a memory corruption problem, and by reducing the size of the sketch by that tiny amount, you have cured it.