I have set up a system where I send a command every 10 seconds to the charger based on solar production,
by doing this this way I don't have to worry about the current state of the charger and save the world from more of my terrible code...
The charger seems happy enough to keep receiving updated current limits and being told enable repeatably. Im hopping these are only effecting ram variables and not nvram, can anyone confirm this?
In searching for some information about the $SC command I came across these posts. In the original post you ask if the commands "are only effecting ram variables and not nvram" so I'd like to recommend adding a "V" after the $SC XX command, e.g. $SC 20 V. According to the OpenEVSE – Developers Guide it says that this attribute of the command is used to "Set current and DO NOT Save to EEPROM".
I evaluate my system and send updates as required on 1 minute intervals. I am an off gridder and I have the Charge Controller sweep set to 1 minute also. Without a sweep the output of the system cannot change so altering the charge rate more quickly does not make sense. Also I feel sorry for my car charger making too many changes. Incrementing up 1 A or mdown 1A per minute works well for me.
Why would you enable the charger repeatedly? My experience is once it is on it stays on. I turn it on and then just change the charge rate. I put my charger to sleep when the system is powered up as the OE defaults to an on state. Then when there is power for the car it turns on and then turns off when the power is not available. I put various timers in so that the OE does not cycle on and off as the power available changes.
How do you evaluate your solar production? How can you tell if there is more production or less production that can be utilized by your car?
This is being used on an off grid system also. The system is utilising a fronius 8kw solar inverter and a couple of Outback Mppt chargers, they all seem to respond quite quickly to load changes.
Good point on the Enable. I haven't really checked its default behaviour, but since I went for a really simple comms (1 way 1200 baud) I can't read values from the unit. So just incase some pushes the physical button on the unit, to turn it on or off, this will over-ride it. I assume I'm only setting ram bit, so no harm done.
As for evaluating solar production I target 0 battery amps on the off grid system which keeps the inverters "pushing" as hard as possible as they are still trying to charge batteries. I take a reading of solar production and battery current every second from the off-grid battery inverter/charger and average it over 10 seconds. I then do a simple calc (solarProductionWattsAverage - batteryDischargeWattsAverage / acVoltage) to work out my new value to send to the OpenEvCharger, the car also responds very quickly. Once again I hope I'm only writing a ram variable...
I also have some simple timers (plus some other conditions) to start and stop the EVcharger ie. off-grid battery charging for more than 1 minute continuous to start and battery discharging continuous for more than 1 minute to stop.
I've had a look at the source code for the OE charger to see how the variables are stored but it's a bit (lot) past my programming abilities. I write all my code in one file and bassically use Boolean logic to achieve the desired outcome, think of how a 10 year old in the 80's would have programmed Basic....ha.
Screenshot of OpenEnergy monitor dashboard showing it (mostly) working. Obviously midday sun... The little 32A between shed and house solar dials is the current calculated charge rate.
Thanks for the reply and explanation. My system is 3 Magnum 4448 inverters with 2 Midnite Classic 150 charge controllers, 2 arrays totalling 9.3 Kw STC. I read and write to the Classics using modbus and RS232. The Midnite WBJr gives me current flow to/from the batteries.When not diverting some power to the Hot Water Tank and using the diversion KW as a setpoint for the car charger I use the voltage difference between the battery charge state setpoint and a setpoint .3V less then the battery setpoint. The charge controller tries to get to it's higher battery setpoint and the control increases / decreases the OE charge rate to try to get to the lower setpoint.
It appears to me that you are reading data from the the Outback charge controllers. What system are you using to do that? I am very interested in reading data from the Outbacks into a microcontroller system.
Tracking the chargers set point voltage looks like a good approach to the problem, depending on how quick/hard you want the system to react you could just increase the voltage difference target... assuming the midnite's react quick enough. I have installed a couple of them and have found their response time fine.
Unfortunately I'm not reading data from the outbacks so I can't help you there. I'm using a locally manufactured 7.5kw inverter/charger from Selectronic that seems very similar to your magnums. It has shunt inputs to monitor DC loads/sources, which I'm using for the Outbacks. The fronius solar inverter is AC coupled and has comms to the Selectronic so its output can be controlled. This makes the job easier as I can get all the data I need from the Selectronic inverter ie. load, solar production, generator production, battery voltage, SOC, battery amps etc.
PS. my previous calc of (solarProductionWattsAverage - batteryDischargeWattsAverage / acVoltage) had a big flaw in that it didn't account for the "batteryDischargeWattsAverage" from the previous calculation which caused the result to jump up and down by the value of its self. It didn't show if the house loads were low or the solar input was high.
So now my calc looks more like (( solarProductionWattsAverage - previousBatteryDischargeWattsAverage - presentBatteryDischargeWattsAverage + presentBatteryChargeWattsAverage ) / acVoltage )) and it seems to be working reasonably well.