Archived Forum

Have you looked at MartinR's design: Solar PV power diversion with emonTx, emonGLCD and temperature measurement: http://openenergymonitor.org/emon/node/1535

If I understand your needs correctly, it will do what you want, with possibly a minor modification for your hardware. MartinR is a well-regarded member of the community and you need have no worries on that score. The PLL design is however quite complicated to understand at first, but it is established and proven. Note that this design only uses two c.t's. For a diverter/controller, one c.t. must measure the nett grid power and is used for both measurement and control, the second is for measurement only. The third is unnecessary since the third quantity can be calculated knowing the other two.

Thanks for the reply Robert, I had looked at MartinR's design, but the thread is quite long and complex, some discussions appeared unfinished to my untrained eye. I had however assumed the software was sound as there was no criticism and Paul Reed had mentioned in another post he uses MartinR's design. I believe I became more comfortable with Robins design because it is well documented and has been continually revised, with a revision history.

I have re read the thread as I'm unsure about the hardware mod you mention, are you referring to the hot water tank temperature sensor? I don't think I would use that method to control or calculate the diverted load. I believe external hot water tank temperature sensors are less accurate/responsive than internal sensors ie immersion heater sensor and then consumption of the available surplus power is just an assumption I would still need to install at least 1 more CT for a Consumption & Dump load calculation (calculation is better than assumption) or better still 2 more CT's for Consumption & Dump load measurements. (rather than a CT clamp I did intend to use a pcb mounted CT and burden resistor for dump load consumption)

Am I right in thinking this will work seamlessly with the Raspberry Pi in place of the emonGLCD as they listen to the same transmissions?

I have also noted it states "Support for a single DS18B20 temperature sensor" is this correct if so can it be changed? I had planned to add several temp sensors at a later date.

I hope I don't sound critical of MartinR's design (if I do I apologise) as that not my intention as there is no doubt its a great design and I do not have the expertise to say otherwise, I'm just hoping to establish (if) it's what I need.

The reason I recommended MartinR's over Robin's is that Martin's has reporting to a GLCD or emonCMS via RF built in, whereas Robin does not do any reporting and uses the RF for controlling a remote load only.

The hardware mod you might need depends on the voltage you designed your triac interface for. If you followed Robins 5 V Arduino design, you'll need to change one resistor for the lower emonTx voltage of 3.3 V.  I've been intending to comprehensively document Martin's design for some months now, and have yet to get past the contents list! The delay is due to responding to forum posts ;-)

If you don't control the water tank temperature but rely on the cylinder thermostat, then Martin's code for reporting the diverted load fails and shows only the energy available for diversion, not that actually diverted. If you want that as a separate value, then you probably need to measure it with a further c.t. As you suggest, a split core one is overkill and a small ring type is most suitable. (Though I can think of a way to know when the cylinder 'stat has opened to allow you to estimate the diverted energy correctly.) Courtesy of Herr Kirchhoff, you don't need a further c.t. for overall consumption (and you will run out of sockets and probably processing power anyway if you have one for both that and diverted power).

The base and the GLCD listen to the same transmissions, so if you don't want the live display (or want it somewhere else), that's fine. All you need to do is ensure exactly the same data that you send now is sent, and then absolutely no change needs to be made to emonCMS.

You'll need to check with Martin regarding the temperature sensors. His code only works with one, I think the time it takes to read the sensor was the limiting factor.

Robert - I've been intending to comprehensively document Martin's design for some months now...

I wish you would, I'd love to know what's under the bonnet!

Paul

So I have tweaked Martin's code to add another CT (solar, grid & dumped) and the reporting side appears to be working ok, I say appears as I've not made a test rig and the sun's barely made an appearance over the last couple of days, certainly not produced enough solar power to cover use let alone a surplus ;-( 

I am going to play with it over the next few days and see if I can get my head around the code and any adjustments or calibrations that may be needed and bench test the triac before hooking up to the immersion heater.

Could someone summarize in (words of one syllable or less) the differences between Martins & Robins approaches?

Is it possible to ease the processors workload by removing the RF code and hardwiring the EmonTX to the Raspberry Pi? as the Pi is connected to the router wirelessly it only needs power so they could go in the same box. although I would want to keep the RFM12Pi on the Raspberry Pi to add further nodes. In fact I guess could I also move the temp sensors across to the Pi if they were in one box.

Also if hard wired to the Raspberry Pi, could Robins code be modified to report the power and voltage values it already has, leaving the RF as it is to control a remote load and then maybe add 1 or 2 more CT's purely for reporting? has anyone tried this or is there a reason it can't be done?

Could someone summarize in (words of one syllable or less) the differences between Martins & Robins approaches?

As I wrote above, Robin's code does not do monitoring and RF transmission of the measured values. It is purely a dump load controller. So that answers a few of your questions. On the load control side, both use similar algorithms.

It should be possible to send the data serially using the I²C one-wire bus, which I believe the RPi can accept; in fact that is the approach Martin used in his 3-phase "Full fat" monitor (http://openenergymonitor.org/emon/node/1170) to share data between 3 emonTx's. I don't know though whether it would significantly reduce the loading

Thank you Robert. I was aware that Robin's was just a dump load controller in its present form but all I was wondering is whether it was superior at that function or perhaps more efficient with processor time to help establish whether it is worth the effort to try and add monitoring, but if they do a similar job controlling dump loads then there would seem little reason to when Martins already does the monitoring. 

Your previous comment regards running out of processor power concerns me as although you're right about not needing a 4th CT, I would prefer not to be running the processor flat out or harder than needed as thats when things fall over and I may want to add/change things down the line eg a second dump load or more likely RF the dump load.

I'm giving Martins code a run currently & see how it goes......

As Martin's code, and the later "i" examples of Robin's, all use interrupts, it is vital that the interrupt handler (ISR) completes in time to allow the main loop to do all it needs to in a timely manner. It's been a while since I looked in detail at Martin's code, from memory you need to use a 'scope to check how much free time is available. At least some of Robin's versions have that built in.

I have run both in a test situation - I did not do any rigorous measurements and found no flaws in either, and as the algorithms are based on the same principle, I would expect both to have very similar performance when set up the same.