lincomatic/open_evse

Firmware for Open EVSE

This is the development branch - latest bleeding edge code here The version in this repo is usually functional DO NOT use any of the other branches, including the stable branch.. they're just for my own testing, or kept for historical purposes

Tip Jar: I developed/maintain this firmware on a volunteer basis. Any donation, no matter how small, is greatly appreciated.

Firmware for OpenEVSE: Open Source Hardware J1772 Electric Vehicle Supply Equipment

NOTES:

• Working versions of the required libraries are included with the firmware code. This avoids potential issues related to using the wrong versions of the libraries.
• Arduino 1.6.x or newer is STRONGLY RECOMMENDED for compiling OpenEVSE. Older versions of Arduino will build sketches which are too big to fit into OpenEVSE, unless features are disabled.
• Current official build tools version is Arduino AVR Boards by Arduino v1.6.15. You can install any version of the GUI, but make sure to use that version of the build tools, as it was used for UL certification. WITH LATEST CHANGES, v1.6.15 results in a sketch that's too big (>32768). MUST DISABLE FEATURES TO BUILD A COMPATIBLE SKETCH.. disabling RAPI_WF does the trick. -> Currently testing v1.6.23, which builds a sketch that fits, even when all options enabled. FOR DEVELOPMENT ONLY UNTIL FURTHER TESTING IS DONE

---

Open EVSE is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.

Open EVSE is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with Open EVSE; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

• Open EVSE is distributed in the hope that it will be useful,
• but WITHOUT ANY WARRANTY; without even the implied warranty of
• MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

open_evse's Issues

Async event for setting change

It would be really handy to send an async event when changes are made to any of the settings via the LCD, eg $VC GE if any of the flags change. This would cut down on a lot of the polling the WiFi module has to do.

PlatformIO vs Arduino IDE: same binary firmware?

Hi Glyn,

PlatformIO and Arduino IDE generate different firmware.hex files from openenergymonitor/open_evse. Is that to be expected or am I missing something?

dev@openevse-dev:~/OpenEVSE/eu/open_evse$ ls -al firmware/open_evse/*.hex
-rw-rw-r-- 1 dev dev 88565 Aug 25 22:14 firmware/open_evse/open_evse.ino.standard.hex
-rw-r--r-- 1 dev dev 88016 Aug 25 22:14 firmware/open_evse/open_evse.ino.with_bootloader.standard.hex

dev@openevse-dev:~/OpenEVSE/eu/open_evse$ ls -al .pio/build/openevse/*.hex
-rw-rw-r-- 1 dev dev 87821 Aug 25 22:05 .pio/build/openevse/firmware.hex

Jan

Going to sleep while charging trips GFCI

I've been charging my Renault Zoe with OpenEVSE for about a year without issue. Lately I added a WiFi module and so I now have the option to stop charging by pressing the pause button. Doing this while the car is charging and pulling current often trips the GFCI breaker in my house's power board, which happens at 30 mA residual current.
My set up is as follows (all 3 phase + N devices), which is very common at least in the Netherlands:

Grid ==> main breaker ==> utility meter ==> GFCI ==> circuit breaker ==> dedicated energy meter ==> relay ==> car

My hypothesis is that when OpenEVSE signals the car to stop charging via the control pilot, the car immediately changes its pilot status to state B and the EVSE switches the relay off right away. There is no noticeable delay between me pushing the button in the web interface and hearing the relay click. Presumably some residual current is still flowing at that time, which has nowhere to go but the PE lead, thus tripping the GFCI.
Adding a small delay between the the detection of state B and switching the relay off solves the problem for me. I set the delay to 200ms, but I didn't test if smaller values work as well.

I made the following change in J1772EvseController.cpp, starting from line 1101, to insert the delay. Obviously this is an ugly hack, but maybe you could consider building in a good solution to achieve this.

...
    if (chargingIsOn()) {
      // wait for pilot voltage to go > STATE C. This will happen if
      // a) EV reacts and goes back to state B (opens its contacts)
      // b) user pulls out the charge connector
      // if it doesn't happen within 3 sec, we'll just open our relay anyway
      // c) no current draw means EV opened its contacts even if it stays in STATE C
      //    allow 3A slop for ammeter inaccuracy
      if ((phigh >= m_ThreshData.m_ThreshBC)
#ifdef AMMETER
	  || (m_AmmeterReading <= 3000)
#endif // AMMETER
    ) {
      // Pull time-out forward to 200 ms after first detection.
      if (m_ChargeOffTimeMS > curms - 2800) {
        m_ChargeOffTimeMS = curms - 2800;
      }
    }
    if ((curms - m_ChargeOffTimeMS) >= 3000) {
      chargingOff();
...

Sleep status cause problem on Smart ED

What steps will reproduce the problem?

1. Connect Smart ED to EVSE
2. Set EVSE on via RAPI "FE"
3. Set EVSE sleeping "FS"
4. Set EVSE on via RAPI "FE" within 60 sek

Smart ED LED on Charging Socket flasching red.
I think the problem is that the EVSE goes to status disabled and disconnects the relais.

What is the expected output? What do you see instead?

when EVSE is set to sleeping, don´t open the relais and set state to disabled. Sleeping means, that the it is possible to start the charging immediately.
Maybe it is useful to make a new Command on Rapi -> "Soft Stop"

What version of the product are you using? On what operating system?
OpenEVSE Plus DIY

Bad temperature reading between 0oC and -0.5oC

Hi, I have seen a problem with the OpenEVSE (firmware 5.0.1) with Wifi (firmware 2.8.1) when reporting temperature of -0.25oC. You can see from the attached picture of data logged to emoncms that there is systematically -256oC reading when the temperature crosses near 0oC. I see also the same from the OpenEVSE web page as you can see from two pictures taken a couple of seconds apart.

I've looked at the code here: https://github.com/OpenEVSE/open_evse/blob/stable/firmware/open_evse/open_evse.ino and it looks to me that the DS3231 detection mechanism at line 330 is the problem. The value of 0x3FF is a valid value of -0.25oC and does not indicates that the chip is not there. The I2C address ACK/NACK should be used for that purpose. Also, a valid check on the data would be a non-zero value in bits 0 to 5 of register 0x12, but that must be checked before shifting the byte and losing those bits of course.
Another remark also regarding this code section. From the DS3231 datasheet, it is recommended to check the BSY bit before starting a conversion with the CONV bit and waiting for both bits to be cleared before reading the temperature.

thanks a lot,
Jean-Pierre Lefebvre

RAPI command to set voltage

RAPI command to set voltage for power calculations.

Power calculations for L2 are based on a fixed 240v. Depending on location the baseline voltage could be 208, 220, or 230.

L1 is based on a fixed 120v which could be 100, 110 or 120.

Accuracy could be greatly improved by sending regular RAPI updates from an external measurement source or a user could set the voltage to match their readings under load at the time of charge.

Is it possible to run OpenEVSE without an LCD display?

Hi, lincomatic!

I want to use OpenEVSE firmware without using an LCD screen. As far as I understand, if you simply disconnect the screen from the controller, charging will not start at all. Is there any way around this? All data on the state of charge I get through Wifi (ESP8266).
I tried to disable I2CLCD and other screen settings in open_evse.h, but this leads to errors.

L2 minimum current should be 6A not 10A?

The correct L2 minimum current should be 6A not 10A:

https://github.com/lincomatic/open_evse/blob/development/firmware/open_evse/open_evse.h#L354

Updating from OpenEVSE v3.10.4 to v4.8.0 the minimum L2 current increased to 10A. I've traced the change back to this commit: e144329

I can't find any comments about why the minimum current was increased to 10A? Trickle charging at 6A used to work fine

---

On a slight different topic: IMO it would also be a good idea to limit L2 max current to 40A max since this is the maximum the single-phase cables EV cables can handle. Most are rated at 32A. It would certainty be a good idea to limit the max rate to 40A for a full-assembled 40A unit. This issue should probably be opened with @chris1howell on the OpenEVSE repo.

$FP command causes crash

Print more than 6 spaces on the LCD using $FP causes a crash, eg "$FP 0 1 IP Address "

This is probably because the array of tokens is 10. So one possible fix would be to make this 20, but a simpler solution maybe to just stop token parsing when the max is reached, the last token would then included the remaining spaces.

GetChargingCurrent returns last charging current after charging

I thought there was a measurement error occurring in the GetChargingCurrent() function because my OpenEVSE was always reporting 880-1100mA power usage. I didn't put two and two together for a few days when I realized it worked fine before a charge, it was just after the charge it always reported current use.

Looking at the code, I see that the m_ChargingCurrent variable is only updated in EVSE_STATE_C (charging state). When the charge completes, it stops updating the value, leaving it at the last value right before the charge cycle completed. The simple fix would be to add
https://github.com/lincomatic/open_evse/blob/development/open_evse.pde#L1233

void J1772EVSEController::chargingOff()
{
...
#ifdef AMMETER
  m_ChargingCurrent = 0;
#endif
}

This covers all other state transitions where the relay is shut off. I'd submit a pull request but it seems silly for a one line change.

LCD RGB backlight colour changes

Recently the background LCD colour when the EVSE is sleeping was changed: 984857f

Now the colour when sleeping is identical to the current when charging. Is this intentional? It was quite useful to be able to distinguish between sleeping / charging at a glance.

NEW

OLD

---

I personally preferred magenta backlight when sleeping. What was the reasoning behind the change?

Temperature monitoring - subzero temps

Apologies if this is the wrong place to note this. In freezing temperatures, the temperature control triggers an overtemperature alarm and stops charge. Does the temp sensor work sub zero?

Session elapsed time should be consistent with session energy

I'm running latest dev version with the update to reset the session energy when the car in un-plugged even in the unit is in 'sleep' state (charging timer active). This is working very well.

However I have noticed another issue: the time elapsed resets each time the evse is paused then resumed. IMO the session timer should be consistent with session energy. I would consider pausing then resuming a charge (without un-plugging the car) the be the same charging session therefore the time elapsed should not reset. See illustration video:

https://youtu.be/R8hdGba5Ygw

In order to start support of car identification

Wondering if this place is a good one for proposal of enhancement. Please feel free to let me know if not and redirect me to the right place, please.
I actually and happily own an OpenEVSE device and I plan to have a second EV car connecting to it. In order to help split the electricity consumption bill, I would need to trace which car consumed energy. Looking for a simple solution, I though about having a separate RFID next to the charger that would enable/disable the device. I though about having a new "RAPI variable" be available. Through RAPI command it would be possible to set the, let's say, "carid" variable to a byte number. But once the firmware detects the cable is disconnected, it resets the variable to 0. The downstream system (EVSE Wifi, or any other) can thus disable the charger. The charger could be energized back by the external system when the RFID detects a valid code and set the "carid" variable through RAPI. The external system is still responsible to poll the charger. The only new responsibility for the charger is to reset the carid value to 0 once a disconnect state is detected.

RAPI over I2C

Hello. I wanted to try openEVSE remote control via I2C and I did not succeed. I uncommented the line "#define RAPI_I2C", and tried to use the STM32 board as an I2C master, to manage openEVSE. It did not work. Having studied the code, I realized that openEVSE itself would be an I2C master, and for remote control I should have a slave device. Is this true?
If so, this is not good for my project. I need to manage 3-4 openEVSE single board and I would like to see it as an I2C master device, and all openEVSE is a slave. Is it possible to do this?

Physical Security - RAPI command to disable button.

RAPI command needed for physical security to disable push button.

PP_AUTO_AMPACITY should set absolute maximum charge for a single session

PP_AUTO_AMPACITY works well to set the correct max charge rate for the non-tethered cable in use. However, once a cable is connected or a charge is active it's then possible for a user to override this maximum by setting the current manually. For obvious reasons this should not be possible. How difficult would it be to make the max current set by PP_AUTO_AMPACITY the absolute maximum current for that session.

Update: After further testing it was found that the openevse does currently revert to the previous max charge setting when the cable in unplugged. Only the issue above remains.

Currently when a cable is unplugged is unplugged the display shows the pilot setting from the last cable to be used. e.g. if a 20A cable was used for the last charging session the display will show 20A when the cable is unplugged. This could be misleading for the next users of the station who understandably would think that this stations is only capable of 20A. While in fact when a 32A cable is plugged in the EVSE then increases the pilot to 32A.

Energy Limit: additive rather than cumulative

Currently, the energy limit is added onto the current elapsed energy e.g. if an EV has charged to 5kWh and then user applies an Energy Limit of 6kWh the charge will not stop until the elapsed energy has reached 11kWh.

I think a more consistent user experience would be for the charge to stop when the elapsed energy reaches the energy limit e.g. 6kWh in the above example. What are your thoughts on this?

I've tried to illustrate with a video, sorry it's a bit of a ramble:
https://photos.app.goo.gl/CYVaFccno2mLa4ih9

Setting the charge/time limit via RAPI does not update LCD

When setting the charge or time limit via RAPI the LCD does not update to show the lightning/clock icon. Entering/exiting the menu then displays the icons as expected.

Setting the LCD text via RAPI can corrupt display

When setting the LCD text via RAPI (eg '$FP 0 0 Client-IP.......') the display can get corrupted depending on the state of OpenEVSE, eg;

Could we add an RAPI command to claim/release the the LCD? When claimed the LCD will only be updated via RAPI (using $FP, $FB). On release the LCD will revert back to OpenEVSE control.

Issue compiling latest stable when you undefine RTC

If I comment out #define RTC (Because I don't use the timer, etc).. I wind up with this in the compile output...

Users/dans/Library/Arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.3-arduino2/bin/avr-gcc" -w -Os -flto -fuse-linker-plugin -Wl,--gc-sections -mmcu=atmega328p -o "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/open_evse-stable.ino.elf" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/twi.c.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/Adafruit_TMP007.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/Gfi.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/I2CIO.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/J1772EvseController.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/J1772Pilot.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/LCD.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/LiquidCrystal_I2C.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/LiquidTWI2.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/MCP9808.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/RTClib.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/Time.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/Wire.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/avrstuff.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/open_evse-stable.ino.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/rapi_proc.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/serialcli.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/strings.cpp.o" "/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/core/core.a" "-L/var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp" -lm
/Users/dans/Documents/ArduinoFiles/open_evse-stable/open_evse-stable.ino: In function 'ProcessInputs':
open_evse-stable:2227: error: unable to find a register to spill in class 'NO_REGS'
}
^
open_evse-stable:2227: error: this is the insn:
(insn 749 746 752 132 (set (mem:QI (post_dec:HI (reg/f:HI 32 SP_L)) [0 S1 A8])
(subreg:QI (reg/f:HI 758) 1)) /var/folders/m4/n4xf0jg17djdjhcyrgtnwq9c0000gn/T/build4f48d17d60941664f85a5b58df5c7485.tmp/sketch/rapi_proc.cpp:403 1 {pushqi1}
(expr_list:REG_ARGS_SIZE (const_int 7 [0x7])
(nil)))
/Users/dans/Documents/ArduinoFiles/open_evse-stable/open_evse-stable.ino:2227: confused by earlier errors, bailing out
lto-wrapper: /Users/dans/Library/Arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.3-arduino2/bin/avr-gcc returned 1 exit status
/Users/dans/Library/Arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.3-arduino2/bin/../lib/gcc/avr/4.9.2/../../../../avr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
exit status 1
unable to find a register to spill in class 'NO_REGS'

When I put the #define RTC back in... all is fine..

Where can I find eeprom_24.bin?

Hi! I want to test the latest version of the OpenEVSE firmware, but I can not figure out where to get eeprom_24.bin? As far as I understand, with each version of the firmware the contents of this file change or can I use this file with v4.8.0?

Overcurrent feature: delay required

I've been testing the overcurrent feature implemented in 5.0.0 60b5083

It works well, however, there is a false positive when the openevse reduces the set charging rate while the car is charging (this can happen automatically during solar PV divert).

The EV takes a finite period of time to react to the change of pilot signal to reduce the charging rate. Before the EV gets a chance to reduce it's currently the openevse triggers an overcurrent error since momentarily the EV is drawing more current than the pilot signal is set.

This could be easily fixed by adding a 'grace period' to allow the EV to re-adjust.

Is there enough memory to make such an addition? I think something around 3 to 5s would be more than enough grace period.

Also is there any way to detect an overcurrent hard error via RAPI? I don't currently think there is a way to display an overcurrent error on the WiFi interface. This is not a big deal, but it would be good to be able to show that the openevse has entered an error state on the wifi interface. Since currently when an overcurrent error is triggered the wifi interface becomes unresponsive.

230v/400v single/three phase detection and correct energy calculations.

I've recently installed an OpenEVSE on a 400V-TN circuit and this allows the connected car to either charge 400V three phase or 230V single phase and it makes the energy counter go out of whack.

Given the OpenEVSE board needs to be wired between L1 and N I take it only knows about 230V regardless of being in a 400V system. Adding a voltmeter wouldn't help either as it wouldn't tell us if the connected car is using L1/L2/L3/N or just L1/N.

Would it be doable to add a a second ammeter as a digital input, monitoring L2 or L3, and based on this decide to calculate the energy based on the correct voltage and correct number of phases? Or is this just something we'll have to wait for the next generation to see resolved?

As a dirty fix I scaled up the current measurements so the 400v/three phase measurements that is what the user is using is correct, but it'll be wrong when some visit with a car that cannot charge off 400V and reverts to pulling single phase 230V from L1 and N.

State: EV Connected / Disconnected while sleeping

A user has noticed there is no way to tell if an EV has been connected / disconnected while the EVSE is sleeping. The state remains at 254.

Do you know if there is a work around to detect this?

What are your thoughts on adding another couple of state values to indicate:

• EVSE sleeping no EV connected
• EVSE sleeping EV connected

https://community.openenergymonitor.org/t/request-for-new-input-to-emoncms-from-openevse/10161/4

Alert user when temperature throttling was activated during a charge session

Currently the RGB LCD displays red when temperature throttling is active i.e charging rate is reduced if temperature goes above 75 degC:

50% | 65°C - 150°F
25% | 68°C - 155°F
Shutdown | 71°C - 160°F
Resume 100% | 62°C - 145°F

Temperature throttling is great and is an important safety feature however it can have the side effect of masking an underlying issue with the EVSE build that's causing excessive heating e.g. EVSE starts to overheat (up to 70 deC) > charge current is throttled > temperature plateaus > temp never reaches the 71 deg C shutdown level > but damage to components still occurs overtime.

Especially in cold (sub-zero) ambient temperatures the actual conductors get very hot indeed before triggering a over temp shutdown. In many parts of the world in winter 70 deg C is actually rather hot and defiantly not normal.

Most users charge their EV overnight in a garage therefore would miss spotting the instant the LCD turn red to indicate high temp and charge rate throttled. The user would wake-up and unplug their car in the mornig with the EVSE showing a normal display unaware of issue causing the overheating.

A possible solution to this suggested by @chris1howell would be to display a warning message on the second line of the LCD which is persistent until the car is unplugged to alert the user that at some point in the current charging session temperature throttling was activated. The user can then investigate accordingly. The LCD could also display red until car is unplugged.

Do you think this is a viable solution that should act as an early warning for potential build issues? I understand that healthy systems in hot countries could potentially trigger this warning under 'normal' operation, however the warning could still be useful since the user is alerted that the car might not be fully changed since charging rate was throttled during the session. Happy to discuss other options...

Service level display issue

When cycling around the Service level menu options the + is initially correct, but on looping round it moves to the previous option, eg if the service level is 2, the following is displayed on each press of the button;

• +2
• Auto
• +1
• 2

see https://youtu.be/O1HNXLJIG9A

No RAPI API for getting the current delay timer

I see an API to set the timer ($ST) but I do not see an API to get the current delay timer state/values. Can one be added?

extended_fuses setting causes unreliable booting

The setting for the openevse.bootloader.extended_fuses property in the boards.txt.arduino1.6.x should be 0x04, not 0x05. The 0x05 value causes unreliable booting for many OpenEVSE units. See this issue on the openEVSE support site for more details.

https://openev.freshdesk.com/support/discussions/topics/6000051632

Set temporary (single session only) charging current

As far as I'm aware using the volatile flag when setting charging current e.g $ SC [amps] V only restores the original current after a reboot.

Would it be possible to add a RAPI flag to set a temporary (single session only) current? After the session ends (car is unplugged) the current would restore back to default.

Maybe a S flag could be used for this to denote session? e.g.

$ SC [amps] S

PCF8574 support

Hi,

I've been trying to compile firmware with PCF8574 support without luck. I have monochrome based LCD.
So far I did get some garbage on the screen while display works great with this library:
http://www.mathertel.de/Arduino/LiquidCrystal_PCF8574.aspx

What I did in the code:
(openevse.ino)
// if using I2CLCD_PCF8574 uncomment below line and comment out LiquidTWI2.h above
#include "./LiquidCrystal_I2C.h"

I don't see LiquidTWI2.h anymore. Just doing this didn't help - display acted like dead.
So next I did
(openevse.h)

// Support PCF8574* based I2C backpack using F. Malpartida's library
// https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads
#define I2CLCD_PCF8574

No luck as well.

I get garbage (and it's dynamic I can see data changes on the display) only when I do:

#define I2LCD
but on the other hand there is

#ifndef I2CLCD
#undef I2CLCD_PCF8574
#endif

I have tried several combinations without luck.

I have also tried to replace LiquidCrystal_I2C.h with LiquidCrystal_PCF8574.h but it seems wire and twi libraries are tied with LiquidCrystal_I2C and it's beyond my skills to fix that :(

Compiling openenergeymonitor/open_evse

Hi Glyn,

I do not understand why the compiler issues this warning. It is as if the compiler doesn't know about the #if directive? Any suggestions? I'm compiling the master branch, no local changes, with Platform IO.

While on topic of compiler directives and conditionals, is there a way to test whether we're compiling with Platform IO so we can make this conditional, ie. include the define for the Arduinio IDE but not for Platform IO? Something like:

#ifdef PIO
// #define VERSION "D5.1.0" -- see platformio.ini
#else
#define VERSION "D5.1.0"
#endif

and add "-D PIO" to the src_build_flags in platformio.ini

Jan

/home/dev/OpenEVSE/eu/open_evse/firmware/open_evse/open_evse.ino:1187:0: warning: "SVC_LVL_MNU_ITEMCNT" redefined
#define SVC_LVL_MNU_ITEMCNT 2
^
/home/dev/OpenEVSE/eu/open_evse/firmware/open_evse/open_evse.ino:1185:0: note: this is the location of the previous definition
#define SVC_LVL_MNU_ITEMCNT 3
^

The corresponding section in open_evse.ino is this:

#if defined(ADVPWR) && defined(AUTOSVCLEVEL)
#define SVC_LVL_MNU_ITEMCNT 3
#else
#define SVC_LVL_MNU_ITEMCNT 2
#endif // ADVPWR && AUTOSVCLEVEL

Testing for supported features

I have just been testing the fix for #69 and it is protected by TEMPERATURE_MONITORING_NY which I will raise separately, however this raises a larger question of what is the best way to check if the firmware supports particular features? Just trial and error or is there something more explicit?

Restore LCD display after corruption

I have recently got the openevse controller CE tested, one of the main components of CE is EMC compliance. We managed to get the unit passed with a few minor changes e.g filter on the AC input and a FW modification to restore the LCD display after it was corrupted. I will be contributing the test report back to the openevse project.

During the EMC immunity test open circuit disturbance surges of 1 kV and 2 kV were applied to the AC input. When the disturbances where applies the evse controller continued to function fine, however the LCD display got corrupted:

Power cycling the unit fixed the issue, however to obtain a pass the LCD function must restore automatically. To obtain a pass I 'hacked' the FW to re-draw the LCD every 60s by clearing it then printing to it. This worked and the unit passed. However, this need to be implemented better

openenergymonitor@85df0a6

What do you think would be the best way to redraw or reinitialise the LCD every 5min or so to ensure if the worst was to happen the display would recover? Just printing to the LCD didn't result in the LCD recovering, it required a full reset.

Overcurrent cutout?

Since the openevse has the ability to monitor the actual current being drawn by the EV has an over current cutout been discussed? I.e if the real-time current being drawn the the EV is greater than the pilot setting the openevse could stop the charge and throw a error.

I admit that in practice this is unlikely to happen, unless there was a serious fault with an EV, however since we have the ability to measure real time current I think this would be a good fail save feature to add.

This was particularly apparent today when I was testing PP_AUTO_AMPACITY (which works very well 👍 ), when I simulated a non-tethered 13A charging cable with a 1.5K ohm resistor between PP>GND the openevse limited the pilot signal to 13A, great. However, there is nothing stopping a faulty EV that disregards the pilot signal drawing more current.

Here I was drawing 22A with the pilot signal set to 13A by PP_AUTO_AMPACITY:

It could be argued that the evse should be installed using a power outlet with a MCB/fuse rating to match the max output of the evse. Therefore if overcurrent occurs the MCB/fuse would trip. However if the evse is non-tethered and the pilot signal was set to the rating of the cable e.g 13A by PP_AUTO_AMPACITY if an EV then draws 32A it will be within the supply limit of the evse but not the cable limit. In this scenario the evse would continue the charge regardless of the current being drawn damaging the cable.

If you think this is a good idea I'm happy to try and have a go at implementing.

Delay end time not stopping charge

After updating from 4.11.0 to latest version (4.12.3) the delay timer end charge time does not work. Starting a charge using the delay timer works fine, however the charge does not stop as it should at the allocated end time.

Over the weekend I will try and debug establish after what version this bug was introduced, sorry not had much time to debug today. This is just an interim post to establish if anyone else can re-create this issue?

The delay timer was set using RAPI via the wifi-gateway and was verified to be correct on the LCD and using $GD.

Pin change RelayAC

Hi, lincomatic! I need to change pin relayAC from digital to analog. In open_evse.h I found the lines:

#define CHARGINGAC_REG & PINB #define CHARGINGAC_IDX 1

Everything was fine, if I used a digital pin for the relay, but I only have an analog one. Any ideas? In J1772EvseController.cpp, I found the code responsible for setting the relay pin:

#ifdef CHARGINGAC_REG   pinChargingAC.init (CHARGINGAC_REG, CHARGINGAC_IDX, DigitalPin :: OUT); #endif

It's unclear how to change the pin from digital to analog. Any ideas? I apologize for diverting stupid questions.

Session Wh Counter Code Not Accurate

I was just looking at the session Wh counter code, and it appears to make the erroneous assumption that it's called once per second. The code is in g_OnboardDisplay::Update() and is as follows:

      if (g_EvseController.GetCurSvcLevel() == 2) {                        //  first verify L2 or L1
	g_WattSeconds =  g_WattSeconds + (VOLTS_FOR_L2 * current / 1000);  // accumulate Watt Seconds for Level2 charging
      }
      else {
	g_WattSeconds =  g_WattSeconds + (VOLTS_FOR_L1 * current / 1000);  // accumulate Watt Seconds for Level1 charging
      }

The code doesn't take into time how much time has elapsed. It's just assuming that it's being called once per second. Though the code is usually called once per second, it can actually be called at random intervals, whenever the display needs to be updated

No RAPI API for enabling/disabling the temperature checking

I do not see an API for enabling/disabling the temperature monitoring. Can one be added?

PP_TABLE_TESLA?

Sorry, this is a question rather than an issue.

It's fantastic that openevse has implemented PP_AUTO_AMPACITY for non-tethered EU type-2 socket units. Nice work 👍

The PP_TABLE_IEC resistor and current values all match the EN 61851:1 spec. My question is why the need for PP_TABLE_TESLA

https://github.com/openenergymonitor/open_evse/blob/master/firmware/open_evse/AutoCurrentCapacityController.cpp#L30

Tesla's charge using standard EV cables in the EU which have the same PP > GND resistor in the type-2 plug to identify the cables current rating. Why the need for a separate lookup table? I can't see this documented anywhere.

Thanks.

m_TMP007_temperature stuck at initialization of 230 if not present

All 3 temp monitors are initialized to 230 (23C):

void TempMonitor::Init()
{
  m_Flags = 0;
  m_MCP9808_temperature = 230;  // 230 means 23.0C  Using an integer to save on floating point library use
  m_DS3231_temperature = 230;   // the DS3231 RTC has a built in temperature sensor
  m_TMP007_temperature = 230;

But if a TMP007 is not present, it stays at 230, which is misleading. This is because although m_tmp007.begin() returns false if it fails, the return value isn't checked.

When we read the temperature:

m_TMP007_temperature = m_tmp007.readObjTempC10();

int16_t Adafruit_TMP007::readObjTempC10(void) {
  int16_t raw = read16(TMP007_TOBJ);

  if (raw & 0x1) return (int16_t)NAN;

we should be getting back NAN, but i'm not sure how that works on assignment. In any case, in my unit with no TMP007, the reading for this non-existent device stays at 230.
Maybe the simplest solution would be to just initialize everything to 0?

RAPI GS command response and ST asynchronous have different number format

For example, in sleep mode the RAPI GS command response would be as follows: "OK 254 1". The asynchronous state announce would be like this: "ST fe". The documentation in rapi_proc.h implies they are in the same format "EVSE_STATE_xxx".

Perhaps the decimal response is better than hexadecimal because that's what everything else uses. But I do think they should have the same number format. What do you all think?

Should I really use Arduino 1.6

The front page suggest Arduino 1.6.x

Should that be or newer?

Compile Error

Newbie here; sorry if this has already been asked. When I try to compile the latest download, I get the following error:

In file included from sketch\ammeter_cal\ammeter_cal.cpp:23:0:

sketch\ammeter_cal\ammeter_cal.h:29:18: fatal error: time.h: No such file or directory

#include <time.h> (time.h)

Please note that time.h won't display with the correct brackets on here, so I've substituted round ones.

$FS 'rebounds' when trying to pause a delay timer charge

If a delay timer charge is active i.e the current charging session was started by the start time on the delay timer then issuing $FS to pause the charge results in the charge being momentarily stopped then re-started 1s later, presumably by the delay timer.

Interestingly, pressing the button to pause the charge when a delay timer charge is active works as expected: the charge stops, delay timer is overridden.

Is this intended behaviour? IMO is would be best if $FS has the same effect as a button press, overriding the delay timer.

Auth_Lock and EEPROM

Hi, lincomatic!

In the firmware, there is the function Auth_Lock, which allows you to limit access to charging. Is the state of Auth_Lock written to the EEPROM? I've heard that the EEPROM has a limited write cycle, I want to connect a lock, with which I'll turn on the charging.

Session Wh counter does not reset if using delay timer

The Wh session counter does not reset in between charging sessions when the delay timer is active.

Example: I use the OpenEVSE charging timer to schedule overnight charging of an EV, after a few days the session counter is massive and therefore useless as a "session counter". This also makes the "Energy Limit" feature impossible to use.

See session wh counter screenshot below showing of 35 kWh which is impossible for a single session since my 24kWh Nissan LEAF only has 20 Kwh of usable capacity! Also I'm pretty sure my domestic single phase-supply would struggle to deliver 25kWh over elapsed time of 10min!

We it be possible to reset the session counter (write it to total kWh EEPROM) when state changes from:

Charging

to

SLEEPING (connected) or SLEEPING (disconnected) or READY

RAPI response has no checksum

There doesn't seem to be any checksum ability on the RAPI response packet. Maybe this was deemed unnecessary as the responses won't cause potential hazards like a bad command could. I'm just wondering what the thoughts on this are; if I added a way to optionally turn on a response checksum (XOR) would that be desired?

Newbie

Hi folks,

Thanks for all the hard work done on this project, it's much appreciated. And (almost) works like a charm on my off grid system here. I realise I am probably a bit of an exception charging an old 2011 Nissan Leaf on an off grid power system with a few relatively big other power consumers.

One thing that is not working for me is the current over-current defaults in the firmware as it seems the charger in my old Leaf is not responding fast enough to a change in current.

So ... I'd like to compile a custom version of the firmware with the OVERCURRENT_TIMEOUT changed to (an arbitrary) 8000L instead of the default 5000L to see if that is a better fit for my car.

I found open_evse firmware in the OpenEVSE repository as well as here. Unfortunately I can't compile the v5.0.1 firmware as published in the OpenEVSE repository with v1.6.15 of the build tools as that results in a sketch that is too big.

I've tried compiling the development branch from this repository with RAPI_WF disabled/commented out but that too results in a sketch that's too big. The stable branch does compile but as far as I can tell that is v3.11.3, much older, I presume, than v5.0.1

I'm a bit confused as to which repository I can or should use. The v5.0.1 firmware appears to be pretty good apart from the issue with the default OVERCURRENT values so I'd prefer to first compile v5.0.1 as-is, which should result in the same firmware as I've got running currently. Then I hope I can download the firmware as it is shipped in the OpenEVSE charge controllers so I can confirm that I have been able to compile the exact firmware as that was shipped. Once that all checks out, I can make the one small change and compile the custom firmware.

A few pointers from someone how I can upload that firmware to the OpenEVSE charge controller would be much appreciated. I've done some Arduino stuff in the past but could always upload that straight from the IDE via USB.

And once all this is done, I can start learning more and hopefully one day make more complex and meaningful contributions to the project.

thanks in advance,
Jan

$FE does not work when delay timer is active

Sorry to post another issue, I've just noticed that $FE cannot be used to start a charge (change state from sleeping > charging) when delay timer is active.

I have a very useful use case which requires $FE to work when the delay timer is active e.g.

• User has delay timer set to charge EV during an off peak tariff overnight
• User is using with Wifi gateway with 'EcoMode' SolarPV divert setup and enabled. If the EV is connected and it's a sunny day once the solar PV starts to generate more than 6A (1.4kW @ 240V) the EVSE will start charging at 6A, if the solar PV output increases the charging speed with be increased accordingly.
• In the UK (it's not that sunny here) with small domestic solar array it's unlikely (outside of mid-summer) that the solar PV will produce enough to fully charge EV.
• The delay timer should then kick in during the off-peak overnight tariff to fully charge to EV at full rate

This all works apart from $FE does not work when delay timer is active.