Hello - Advice on implementation of control applications

First post here, so Hello!

I have the EmonTx and associated bits & pieces on order, but I hope to be able to extend the project to control one of my own prototypes.  Just wondering where is the best place in the architecture to implement control logic.

In a similar fashion to the solar diverter projects I want to trigger when solar generation is greater than consumption by set amounts, then send a signal to a ATMega8 microcontroller that will signal an electric car charging station to begin charging.  It will be possible to vary the charge rates from trickle charge right up to normal charge rates, approx 1.4kW to ~2.5kW.  As more surplus power is available a signal will be sent to the controller to step up charge rate.  Likewise if surplus reduces a step-down, or stop signal will be sent to the charging station.  No high current mains switching is required as the micro will provide a DC 5V 'input current' signal to a commercial charge controller that will negotiate with the car to step down rate of charge, or stop.

I also want to have my cake and eat it.  I considered adapting the solar PV router, but I actually want emoncms functionality as well for general energy & Solar PV monitoring.  If I'm correct, Robins PV router uses its own firmware on EmonTx and doesn't talk to emoncms.  Is there a way to have both emoncms support and solar PV routing & extend the logic for my application?

From what I've read so far it seems there are a few options to play with when the kit arrives:

- implement control trigger logic in emoncms, but control what?  I'd rather not RF enable my charge controller.  Ideally the RPi would send a signal back to the emonTx board which would toggle an output or send a serial command that would be picked up by my micro.  The charge controller will be close enough to the eMonTx to have a wired connection.  The logic triggers would need to be smart enough to send step up/down signals and preferably implement protection against the outputs toggling too quickly - though I could implement that downstream.

- modify the emonTx code to implement the necessary logic locally based on a delta from the solar PV router code and repurpose a PIN or PINs for the external triggering whilst trying to keep emoncms support.  [is this hard work?]

- bite the bullet and implement a RFµ328 with RFM12B in my charge controller.  I wanted to keep overall cost, size & power consumption (<100mA) down as space is tight, but this might have some neat advantages like removing the wired connection which could make a portable unit possible when using just a 'dumb' 13A power socket if the protocol is reliable enough.

What do you think?  Any other implementation options to consider?


Thanks, Paul

Robert Wall's picture

Re: Hello - Advice on implementation of control applications

You might not have noticed that Robin has done a design for a second radio remote load, which seems to go some way to meeting your objectives, but it doesn't interface with emonCMS.  His Mk2i_PV_Router_rev6 does have the code to report to emonCMS, but not the radio-controlled remote load.

An alternative is MartinR's PLL diverter, which has the reporting capability, but you would need to extend the software to allow it to control your car charger.

It ought to be possible to add control to emonCMS  - it's something that is being looked at, but I'm a bit lost as for the reason why - is it that you want manual remote control? If your car charger is the first priority load, it will accept the excess energy while it can (and you adjust your algorithm to signal it so that it exactly balances the surplus energy available); then when it can't accept any more, your immersion heater load will take over completely automatically. 

Paul Morris's picture

Re: Hello - Advice on implementation of control applications

Hi Robert,

Thanks for the reply.  I saw Robin had started to implement logic for a second load.  Modifying that could be an option, but I don't want to lose emonCMS monitoring and reporting.

I had looked at MartinsR's solution, but couldn't tell what the material difference was.  What are the pros/cons of the two approaches to PV diversion?

I initially thought of trying to implement as much logic in emonCMS to avoid making a fork from the standard arduino sketches.  It would be nice if there was a output pin or serial port on emonTx that emonCMS can control.  That way, almost everything can remain standard, and I only need to implement custom hardware in the car charger to recieve/send data and signal the charge protocol controller accordingly.  Manual override control or semi-automatic scheduling from the internet/smartphone might actually be nice if you need the car fully charged asap, or set a schedule such that if the car has not charged sufficiently by 14:00 ignore PV generation and override into 32A rapid charge to ensure its fully charged before the school run.  I'm still waiting for the kit to arrive to have a play, but it feels like these types of scenario suit the emonCMS logic better.

I really want to keep PV diversion to cater for situations where either the car is not plugged in, or it has entered the trickle charge or battery conditioning stage where it draws much lower currents.  Does this make sense?


Kind regards,


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.