Archived Forum

Yes, that's one way to do it.

Another way would be to reconfigure your hardware to match the multi-load sketch from my website.  For this you would just need to:

1.  plug the wire from your voltage sensor into A3 rather than A2;

2.  plug the wire from your current sensor into A5 rather than A1

3.  plug the wire that controls your output stage into D4 rather than D9

Having made these changes, all of the other output pins will be available for your use.  They are all defined in the sketch, so you won't need to alter the software at all.  

Don't worry about the IO pins which drive the display; they can just rattle up and down in the background.   If you wanted to use the display for its intended purpose, you would need to provide a second current sensor + CT.

OK?

Don, let me know which way you want to go. If you're happy making the changes Robin suggests, that's fine by me. Otherwise, I'll look at adding the second output drive to your existing sketch (always assuming it is still as published and you have not changed anything).

Hi Dom,

The sketches can look scary but they are well written and easy to change.

I use two loads and the changes I made to Mk2i_PV_Router_rev5a can be found on the Talking Solar website.

http://www.talkingsolar.co.uk/index.php/forum/7-arduino-circuit-discussi...

I'm now using  rev5c but the changes are still the same for my set up.

I hope this helps.

Regards, Keith

[Duplicate post deleted - Moderator (RW)]

Hi Keith,

This is exactly what I was looking for, fantastic.

I have moded Mk2i_PV_Router_rev5c to your instructions and tested with the following results.

With my primary load connected to digi pin 9 and nothing to digi pin 10, the LED flickers when the primary load is satisfied (I must be producing more PV than I am using). If I move my primary to digi pin 10 and nothing connected to digi 9, the LED stays on solid when the primary load is satisfied (I know that I am producing more PV than I am using). I would have expected it to flicker the same as when connected to digi pin 9. In both situations, when the primary is using all my PV, the LED stays off, Is this normal or do I need to have both primary and secondary connected for the LED to flicker when they are both satisfied?

Thanks for help, Don.....

Hi Robin,

Thank you for your help with modifying my pin connections to match your coding, which does make things a lot easier. The reason I have gone with Keith Walkers solution of modifying your Mk2i_Rev5c, is I cannot see any LED on your sketch to indicate when I am producing surplus PV. I do rely on the excess LED indicator.

Hi Robert Wall,

Thank you for your kind offer, it is greatly appreciated. Keith Walker has already added extra coding to make my sketch work the way I really want.

Cheers Don....

Don, there are two reasons why the sketches on my website (and hence the latest versions of tmy Mk2i code) do not support an LED:

1. When the RF module and the 4-digit display are both in use, there aren't any spare IO pins, and

2. A neon does the job just as well.  In fact, it does the job better because a neon will also come on if the load is activated via a manual override switch.

If you really want an LED to show when the load is on, an LED and series resistor can be simply connected in parallel with the trigger.  The processor's IO pin will then drive both circuits in parallel.

If you only have one load, it should behave exactly the same when connected to either of the control pins.  If your system is not behaving like this, then something is wrong with it, IMHO.

Hi Robin, just wanted to say thanks for all your help in getting my objective met. I also got help from Keith walker and have my rig running on your mk2i_rev5c with the sketch mods provided by Keith.
Cheers Don...

While looking through the power-diversion logic in rev5d, the function decreaseLoadIfPossible() did not appear to be structured as I had intended it to be.   I suspect cut-and-paste errors.  

It is possible that this code does work OK in practice, but the upgraded version (rev5e) looks better to me, as attached.

The sketch Mk2i_PV_Router_rev5e.ino has been proven on a test rig today with two physical loads, so I am happy this this code is working as intended.

Hi All,

These are the additions/changes that I made for two local loads.

NUMBER OF DUMP LOADS

I've added an extra dump load for the second physical load.

1 = first physical load

2 = remote load - not used

3 = second physical load

const byte noOfDumploads = 3;

SURPLUS PV LED

I'm not using the wireless pins so I've used the standard pin for the surplus PV led.

// const byte surplusPV_LED = 8;

  const byte surplusPV_LED = 13;

PIN FOR SECOND PHYSICAL LOAD

I'm not using the remote load but I need to have a pin for the second physical load.

const byte physicalLoad_0_pin = 9; // for trigger (active low)

const byte physicalLoad_2_pin = 10;

FORCE LOAD OFF DURING START UP

digitalWrite(physicalLoad_0_pin, physicalLoadState[0]); // force the load to be "off" during start-up period

digitalWrite(physicalLoad_2_pin, physicalLoadState[2]);

UPDATE PHYSICAL LOADS

// update all other physical loads

digitalWrite(physicalLoad_0_pin, physicalLoadState[0]);

digitalWrite(physicalLoad_2_pin, physicalLoadState[2]);

Regards, Keith

ACTARIS ACE 1000 METER ISSUES

This meter is a real pain and has a smaller sweet zone than the standard 3600 joules. I've been running with a bucket size of 1800 joules and a change to postMidPointCrossingDelayForAF_cycles, from 25 to 10.

I used to have a tank of hot water and had used 0.5 kWh which I put down to my lodger getting home form work earlier than me.

My lodger left but the 0.5 kWh was still be consumed even on the sunniest of days.

To get over this I've had to reduce the bucket size down to 360 joules.

So if you have the same meter it might be worth checking your meter readings on a sunny day when the house is empty.

Regards, Keith

When running a Mk2 system in 'normal' mode, no consumption should be registered by the meter while surplus power is being diverted.  The meter will always allow a small amount of 'free' consumption within its anti-creep mode, so this should accommodate any small amount of residual drift between the two measurement systems (router and meter).

When running in 'anti-flicker' mode, the same situation should apply.  Having said which, any AF setting is less safe than when running in 'normal' mode.  The easiest way to establish an 'optimal' AF setting is to slacken the AF criterion until the meter is clearly no longer ignoring the see-saw flow, and then tighten it until the meter is happy again.   Then apply a safety margin to suit one's approach to risk (faster transitions = less risk of financial penalty).   By this simple approach, it should be possible to get a Mk2 system working in AF mode just as effectively as if it were in the ultra-safe normal mode.

Just a reminder that the definition for JOULES_PER_WATT_HOUR 3600 should never be changed.  The capacity of the energy bucket can be adjusted using SWEETZONE_IN_JOULES.

Hi Robin,

It is the sweet zone that I've changed and I am running in anti-flicker mode. I'm getting zero creep with the sweet zone of 360 joules. I just wanted to share my issues with the meter from hell. It wasn't until my lodger had left that I knew I was getting any meter creep.

is there any disadvantage of having my sweet zone set so low?

Also, when using anti-flicker mode, should I be calibrating my system or will the defaults be fine.

Thanks, Keith

when using anti-flicker mode, should I be calibrating my system or will the defaults be fine.

As have posted on many occasions, calibration is not necessary when running a Mk2 Router in "normal" mode. 

If using an AF mode which has two energy thresholds (which is probably all versions except Mk2i Rev 5), it is the separation of those thresholds which determines the switching rate.  Setting the sweet-zone range to any particular value only makes sense when the system is calibrated.  The switching thresholds need to lie well within the meter's sweet zone, that's what the offset parameter is for.  Typically this is set at 0.1 which means that only 20% of the sweet-zone is actually being used.   It's up to the user to find the optimal value for their circumstances.

float offsetOfEnergyThresholdsInAFmode = 0.1; // <-- must not exceeed 0.5

If running my alternative AF system which has only a single energy AF threshold (as used in Mk2i_rev5), accurate calibration is no longer required.  That's because this alternative system only relies on its knowledge of time, and the 50/60 Hz mains frequency can be relied on without need for calibration.   This system works particularly well when multiple loads are in use.  When using this AF scheme, it's the delay that's applied after the mid-point of the energy bucket has been crossed which needs to be adjusted in order to obtain the optimal setting.

const int postMidPointCrossingDelayForAF_cycles = 25; // in 20 ms counts

This was the meter that i had. It should run fine with a sweet zone of 1100 if you have everything set up right. I used af with it as well.

You certainly need to calibrate if using af with the early version sketches.

I'm using version 5 in anti-flicker mode. I thought all was good until the lodger left and no one was in the house all day. I'm just passing on my experiences with that meter. Thanks for confirming that I don't need to calibrate.

Thanks for confirming that I don't need to calibrate.

For Rev5 (only) of my Mk2i code, the AF algorithm is based around the systems's knowledge of  the passage of  time rather that its measurements of  the flow of energy.  During a particular period of time, the maximum amount of energy that the dump-load can consume is determined by its rating.  The AF mechanism can be adjusted by altering the 'hold-off' delay  which is applied whenever the mid-point of the energy bucket is crossed.

With this particular AF algorithm, the value of powerCal has no effect on the system's behaviour, hence my claim that the system does not need to be calibrated.  However, to ensure that the energy state of the premises is maintained within the penalty-free zone, the hold-off delay does need to be set appropriately for the type of meter that is present.

Ever since its first release, my Mk2 PV Router code has included the 'long' variable cycleCount.  Its purpose is to count the number of mains cycles that have occurred since the system was started.  This provides a simple time-base without the need to repeatedly call millis(). 

Initially, this variable was only used for trivial tasks such as displaying data every second.  Within the Mk2i code, however, cycleCount has gradually become used for more significant purposes.   During the first 1.5 years of operation or so, everything should be fine.  But when this variable eventually overflows, there could be some unpredictable effects. 

Some modified sketches have just been posted on the Downloads page of my website.   They contain alternative logic which will not suffer from this effect.  The same changes would be useful for  the equivalent code that has already been posted on this forum.

The Mk2i rev5 code on this forum is similar to the  "Mk2_multiLoad_CAT5_n"  sketches on my website.  The _2 to_3 update of my website code is for the cycleCount fix.  Both of these versions are available on the Downloads page.

The Mk2i rev6 code on the OEM forum is similar to the  "Mk2_RFdatalog_n"  sketches on my website.   Again, the _2 to_3 update of my website code is for the cycleCount fix.  Both of these versions are available on the Downloads page.

These latest versions have been checked using my own PCB-based hardware.  The Mk2i PV Router code on the forum is intended for use on the emonTx V2 which has different pin-allocations and which I no longer use.  I am therefore not intending to post updated versions of the Mk2i code. 

If anyone wants to upgrade their Mk2i code in this way, and needs any assistance, just send me a PM.

You're assuming uninterrupted use for 1.5 years! 

If the system is turned off or reset, or there's simply a power failure at some point, the clock starts ticking all over again. If that's unlikely, then the upgrade becomes a good idea.

You're assuming uninterrupted use for 1.5 years!

Sure, but that's how many Mk2 systems (including my own) are likely to be used. 

If it ain't broke, why bother to ever reset it? ;)