OpenEVSE with Wifi Build V2 and Testing

Hello All. I thought I’d start a new thread to share some of my experiences building an OpenEVSE +WiFi.

This is not my first EVSE build. I have a ‘old’ OpenEVSE I’ve used to charge every day at work for several years now. Its been extremely reliable (apart from one minor issue of water ingress via the illuminated switch). I have also built my own based on a viridian EPC and a couple of years ago build another as a side project to look at things like diverting from PV (which was only partially successful)…

As the OpenEVSE has the Wifi integration now I decided to build another. I bought the kit earlier this year but only got around to assembling it a few weeks ago. The build was without issue. Following the build I setup the WiFi and ran some basic test, getting to to charge the Leaf and upload data to the openEVSE instance of emoncms.

I then started work on updating to the latest ‘new’ v2 WiFi code.Using the Arduino IDE initially I mistakenly flashed the ESP8266 with the ‘stable’ branch. This took several attempts - my arduino install was quite out of date and I was missing a few libraries but eventually it worked. Things didn’t look as I expected from screenshots and after a tweet from Glyn I realised I had not used the master branch.

The following day I tried to update to the master branch but my arduino install just wouldn’t compile the code. It threw a number of errors so I decided to look at the platformio route recommended by others. I have never used Atom or Platformio before so it took a surprisingly long time to install everything and configure itself. I then found I also needed to install Python, so added that before I could get going. After a bit more bumbling / googling it was quite late in the evening before I had code loaded on the board and the html files installed.

Once that was all done I connected it to my home WiFi (see below) and I configured the OpenEVSE to connect to my existing emoncms. It started posting data no problem.

A few observations so far :

  • From my Windows 10 desktop I was able to connect to the access point network but the configuration pages would not load running chrome or Edge. It hung at ‘loading’ on Chrome, Edge failed to connect.
  • I was also unable to to connect to configure from my android phone running 7 and chrome.
  • My Windows 10 netbook did work. I was able to connect and reconfigure the network to my home WiFi. However, once I had done this I was unable to access it until I power cycled the EVSE.
  • The ‘services’ tab does not record / report the current choices made. Once ‘Energy Monitoring’ is activated and emoncms configured the isn’t obviously stated / shown anywhere. I wasn’t sure if it was still connected or not and had to check the incoming data.
  • Accessing the OpenEVSE via Edge kills it. It doesn’t load the site but the ESP8266 board seems to almost stop working. I tried this whilst pinging the EVSE and it slows to the point of timeout but recovers once the Edge session is killed.
  • The EVSE doesn’t seem to like more than one browser session open at a time. Again the ping drops away and it seems overloaded. Manageable but you do need to be a bit patient with it sometimes!

So, after a bumpy start, so far so good.

1 Like

So on to today. This morning I did some tests with varying the ‘Max current’. It works well. Its been running for several hours with me playing with the values manually and watching the Leaf try to track it!

I posted this on twitter earlier today. The purple line is the pilot advertised ‘Max Current’ (amps) the green line is the current the Leaf is actually drawing (amps) as reported back by the OpenEVSE and the yellow line is the power being drawn by the car in Watts (read from a separate CT clamp connected to my emonTX).

I also tested some stop / starts via the pause function in the openEVSE interface. The car stopped charging and recovered without any problems.

One thing I have noticed - the ‘email’ functionality described in the openEVSE emoncms documentation is not present in

Next I want to look at the solar divert but the MQTT topic is completely new to me so any pointers would be helpful.


Thanks for the feedback, I am looking at a few of the issues you have pointed out and will have a more detailed look over the feedback (as will @glyn.hudson I am sure) over next week.

Yesterday evening I tested the ‘Energy Limit’ function. I’m particularly interested in this as I often just want to put a few kWh in in the evening, basically to top me up enough to get to work.

I set the current to 11A (as testing from a plug) and the energy limit to 2kWh. It worked, stopped the charge after 1hr and 36 mins and 2 kWh. I checked the charger and it was ‘sleeping’. Here is a view of the GUI :

A couple of similar points of note :

  • Once the mode / energy limit is set, there no feedback to the user through the web GUI of the current task / target. Something like “Status : Charging to Energy Limit - 2kWh” would be very helpful.
  • Again I experienced issues with the availability of the web GUI. Mid charge I tried to check on progress and I just couldn’t get in. I don’t think the WiFi itself is an issue as the unit is happily posting to emoncms.

For the MQTT element, my emonpi card build is several years old (2013 or early 2014) so I’m going to build a new one to ensure I have everything as up to date as possible.

Yesterday evening I did another energy limit test. Something doesn’t add up. Its reported that it took 03:15:30 to delivery 4Wh at 11 amps.

The car was pulling 10.5 A. That would give just over 8kWh in 3 1/4 hour, not 4. I have checked my other feeds in emoncms (I have a CT clamp on this line) and it confirms the EVSE delivered 8.3 kWh yesterday.

whats going wrong?

I also had trouble with the ram overflow issue on esp8266 WiFi V2 so moved back to openevse rapi wifi. I was able to edit this ino file with my emoncms pi’s IP address so as to keep everything in house. I then run home assistant on the same pi. It monitors emoncms feeds and has programmable automations I use to vary the charge current of the car depending on how much power my panel’s are putting out verse home much power the house is using. These are URL rapi commands set up in my switches yaml.
Also little things like before work hass sends the sleep timers required for my charging at work.

Are you using L1 or L2 charging on the evse & what voltage is your house?

I ask this because the ammeter calculations are based off 120v for L1 & 240v for L2. So if your using L1 on 240v this would explain the low reading. Been there myself.

1 Like

That’s a good point about 120 Vs 240. I will check later.

That was a good call. I switched it to L2 and retested at it reads the correct Wh when charging and stops at the right kWh value :


I set it to stop at 2kWh. It did. I had to un-pause it to take this photo!

I’ve also notices that the webUI seems not to like being requested again from a ‘stale’ browser. I checked the EVSE on my phone this morning and went to work. When I can home I took out my phone and tried to access it again from the same tab in Chrome and it would connect. I pulled down to reload the page, still nothing. I closed the tab, connected again from a fresh tab and it went in straight away…


I also noticed that when L2 is selected in the openEVSE menu the number of current options is very limted whereas via the web UI the full range can be accessed.

Hey guys, thanks for testing. @jeremypoulter has fixed the webpage hanging issues in the latest update to the master branch (PR #87). After this update the ESP does not mount the spiffs file system, instead all the data is served from the flash. This significantly reduces the amount of memory required.

I’ve been running the latest update for a week or so now and it it’s made the interface very smooth and snappy. Well worth updating. To make it easy to update I’ve attached a a compressed compiled firmware.bin to this post. Once unzipped you can upload this via the ESP web page HTTP updater. Only a single upload is require since the SPIFFS is no longer used. (354.8 KB)


OK, now updated. I thought it hadn’t worked at first as I couldn’t reconnect to it, then I realised that it would have probably wiped the WiFi settings back to stock AP mode… so I set up the WiFi again and now its working!

My observations :

  • None of the information on Firmware of the OpenEVSE or the WiFi module is reported :
    It would be good to have this so I know / remember what version of your code i’m running.

  • For the ‘services’ page, its not clear what is connected. I thought the update had wiped the emoncms connection but when I click the ‘enable’ tick box I can see its is connected and posting. It would be better to have this in view to begin with.

  • Timer : Previously I’d set a timer for 5 mins for a test. This isn’t visible in the web UI, only on the unit. There
    doesn’t seem to be a way to remove it? How do I wipe the timer and switch it back to normal operation?

  • Safety : Is this section working? I have recorded several ground faults (deliberately) but the count reads zero?

In summary, it works, much better! It’s now very snappy from my phone or desktop PC running Chrome. It still doesn’t load in Edge though, not that Edge immediately matters to me! :slight_smile:

Did you have any thoughts on my comments on providing a summary of what the unit is currently tasked with doing? Such as ‘Charging for 1 hour’ or ‘Charging to 1 kWh limit’?


Also I’ve noticed that the webUI is now remember settings such as ‘Energy Limit’. It also correctly reports the values in a browser on a different device. :slight_smile:

Hi @sean_fosberry

Thanks a lot for testing.

I think this will work after the OpenEVSE controller is rebooted.

That’s interesting, maybe the config got messed-up / incomplete during the update. Maybe @jeremypoulter could comment on this. If Emoncms is enabled the checkbox should be selected .

Timer limit should be visible on the UI. It’s only possible to set a time limit when an EV is charging. This is a limitation of the OpenEVSE controller. The timer and energy limit are only valid for the current charging session, both will be cleared when the next charging session begins.

Should be working, we will investigate. I’ve opened a git issue: Check safety error reporting · Issue #93 · OpenEVSE/ESP8266_WiFi_v2.x · GitHub

Yes, @jeremypoulter has really done a good job optimising in the latest update, all the laggy issues seem to be thing of the past. Edge doesn’t matter to me either but it should work, it’s important to support Edge, even if it is a pain! I’ve opened a git issue Investigate Edge compatibility · Issue #92 · OpenEVSE/ESP8266_WiFi_v2.x · GitHub

The first UI box should show all the current session charging options as well as icons being displayed on the LCD to indicate charge timer / energy limit.

Almost always when you get missing values it is because the /config and/or /status endpoint are returning invalid JSON, which in turn is almost always because the serial comms between the WiFi module and OpenEVSE have got out of sync. There is still some work to do to make the comms more robust.

If a reboot of the WiFi module does not fix the issue can you post the content of http://openevse.local/config and http://openevse.local/status?

By reboot, do you just mean turn the open EVSE off and on again? Or on the board?

“The first UI box should show all the current session charging options as well as icons being displayed on the LCD to indicate charge timer / energy limit.”

Can you post a screenshot of what you mean?

By reboot, do you just mean turn the open EVSE off and on again? Or on the board?

Yeah, just turning the OpenEVSE on and off will do it, or there is a restart button in the WiFi UI, on the System tab.

So from a fresh power up :

http://openevse.local/config :


http://openevse.local/status :