Coder Social home page Coder Social logo

openevse / esp8266_wifi_v2.x Goto Github PK

View Code? Open in Web Editor NEW
75.0 38.0 45.0 10.89 MB

ESP8266 WiFi for OpenEVSE Version 2.x

Home Page: https://openevse.openenergymonitor.org

C++ 19.01% C 78.21% JavaScript 1.84% Shell 0.10% Python 0.85%
esp8266 openevse openenergymonitor evse wifi emoncms mqtt-client

esp8266_wifi_v2.x's Introduction

OpenEVSE WiFi Gateway

OpenEVSE WiFi V2.x is now archived, the current version is OpenEVSE V4.x , upgrading from V2.x to V4.x requires a WiFi module hardware upgrade to ESP32.

main

The WiFi gateway uses an ESP8266 (ESP-12) which communicates with the OpenEVSE controller via serial utilizing the existing RAPI API serial interface. The web interface UI is served directly from the ESP8266 web server and can be controlled via a connected device over the network.

Live demo: https://openevse.openenergymonitor.org

Features

  • Web UI to view & control all OpenEVSE functions
    • Start / pause
    • Delay timer
    • Time limit
    • Energy Limit
    • Adjust charging current
  • MQTT status & control
  • Log to Emoncms server e.g data.openevse.org or emoncms.org
  • 'Eco' mode: automatically adjust charging current based on availability of power from solar PV or grid export
  • OhmConnect integration (California USA only)

Requirements

OpenEVSE charging station

WiFi Module


Contents


User Guide

WiFi Setup

On first boot, OpenEVSE should broadcast a WiFI access point (AP) OpenEVSE_XXX. Connect to this AP (default password: openevse) and the captive portal should forward you to the log-in page. If this does not happen navigate to http://openevse, http://openevse.local or http://192.168.4.1

Note: You may need to disable mobile data if connecting via a mobile

Note: Use of Internet Explorer 11 or earlier is not recommended

Wifi connect Wifi setup

  • Select your WiFi network from list of available networks

  • Enter WiFi PSK key then click Connect

  • OpenEVSE should now connect to local WiFi network

  • Re-connect device to local WiFi network and connect to OpenEVSE using http://openevse.local, http://openevse or local IP address.

If connection / re-connection fails (e.g. network cannot be found or password is incorrect) the OpenEVSE will automatically revert back to WiFi access point (AP) mode after a short while to allow a new network to be re-configured if required. Re-connection to existing network will be attempted every 5 minutes.

Holding the boot / GPIO0 button on the ESP8266 module for about 5s will force WiFi access point mode. This is useful when trying to connect the unit to a new WiFi network. If the unit cannot connect t0 a WiFi network it will resturn to AP more before retrying to connect


OpenEVSE Web Interface

All functions of the OpenEVSE can be viewed and controlled via the web interface. Here is a screen grab showing the 'advanced' display mode:

advanced

The interface has been optimised to work well for both desktop and mobile. Here is an example setting a charging delay timer using an Android device:

android-clock

Charging Mode: Eco

'Eco' charge mode allows the OpenEVSE to adjust the charging current automatically based on an MQTT feed. This feed could be the amount of solar PV generation or the amount of excess power (grid export). 'Normal' charge mode charges the EV at the maximum rate set.

Solar PV Divert Example

This is best illustrated using an Emoncms MySolar graph. The solar generation is shown in yellow and OpenEVSE power consumption in blue:

divert

  • OpenEVSE is initially sleeping with an EV connected
  • Once solar PV generation reaches 6A (1.5kW @ 240V) the OpenEVSE initiates charging
  • Charging current is adjusted based on available solar PV generation
  • Once charging has begun, even if generation drops below 6A, the EV will continue to charge*

*The decision was made not to pause charging if generation current drops below 6A since repeatedly starting / stopping a charge causes excess wear to the OpenEVSE relay contactor.

If a Grid +I/-E (positive import / negative export) feed was used the OpenEVSE would adjust its charging rate based on excess power that would be exported to the grid; for example, if solar PV was producing 4kW and 1kW was being used on-site, the OpenEVSE would charge at 3kW and the amount exported to the grid would be 0kW. If on-site consumption increases to 2kW the OpenEVSE would reduce its charging rate to 2kW.

An OpenEnergyMonitor solar PV energy monitor with an AC-AC voltage sensor adaptor is required to monitor direction of current flow.

Setup

eco

  • To use 'Eco' charging mode MQTT must be enabled and 'Solar PV divert' MQTT topics must be entered.
  • Integration with an OpenEnergyMonitor emonPi is straightforward:
    • Connect to emonPi MQTT server, emonPi MQTT credentials should be pre-populated
    • Enter solar PV generation / Grid (+I/-E) MQTT topic e.g. if solar PV is being monitored by emonPi CT channel 1 enter emon/emonpi/power1
    • MQTT lens Chrome extension can be used to view MQTT data e.g. subscribe to emon/# for all OpenEnergyMonitor MQTT data. To lean more about MQTT see MQTT section of OpenEnergyMonitor user guide
    • If using Grid +I/-E (positive import / negative export) MQTT feed ensure the notation positive import / negative export is correct, CT sensor can be physically reversed on the cable to invert the reading.

Operation

To enable 'Eco' mode charging:

  • Connect EV and ensure EV's internal charging timer is switched off

  • Pause charge; OpenEVSE should display 'sleeping'

  • Enable 'Eco' mode using web interface or via MQTT

  • EV will not begin charging when generation / excess current reaches 6A (1.4kW @ 240V)

  • During 'Eco' charging changes to charging current are temporary (not saved to EEPROM)

  • After an 'Eco mode' charge the OpenEVSE will revert to 'Normal' when EV is disconnected and previous 'Normal' charging current will be reinstated.

  • Current is adjusted in 1A increments between 6A* (1.5kW @ 240V) > max charging current (as set in OpenEVSE setup)

  • 6A is the lowest supported charging current that SAE J1772 EV charging protocol supports

  • The OpenEVSE does not adjust the current itself but rather request that the EV adjusts its charging current by varying the duty cycle of the pilot signal, see theory of operation and Basics of SAE J1772.

  • Charging mode can be viewed and set via MQTT: {base-topic}/divertmode/set (1 = normal, 2 = eco).

* OpenEVSE controller firmware V4.8.0 has a bug which restricts the lowest charging current to 10A. The J1772 protocol can go down to 6A. This will has be fixed with a firmware update. See OpenEnergyMonitor OpenEVSE FW releases. A ISP programmer is required to update openevse controler FW.


Services

services

Emoncms data logging

OpenEVSE can post its status values (e.g amp, temp1, temp2, temp3, pilot, status) to emoncms.org or any other Emoncms server (e.g. emonPi) using Emoncms API. Data will be posted every 30s.

Data can be posted using HTTP or HTTPS. For HTTPS the Emoncms server must support HTTPS (emoncms.org does, the emonPi does not).Due to the limited resources on the ESP the SSL SHA-1 fingerprint for the Emoncms server must be manually entered and regularly updated.

Note: the emoncms.org fingerprint will change every 90 days when the SSL certificate is renewed.

MQTT

OpenEVSE Status via MQTT

OpenEVSE can post its status values (e.g. amp, wh, temp1, temp2, temp3, pilot, status) to an MQTT server. Data will be published as a sub-topic of base topic.E.g <base-topic>/amp. Data is published to MQTT every 30s.

MQTT setup is pre-populated with OpenEnergyMonitor emonPi default MQTT server credentials.

  • Enter MQTT server host and base-topic
  • (Optional) Enter server authentication details if required
  • Click connect
  • After a few seconds Connected: No should change to Connected: Yes if connection is successful. Re-connection will be attempted every 10s. A refresh of the page may be needed.

Note: emon/xxxx should be used as the base-topic if posting to emonPi MQTT server if you want the data to appear in emonPi Emoncms. See emonPi MQTT docs.

MQTT can also be used to control the OpenEVSE, see RAPI MQTT below.

RAPI

RAPI commands can be used to control and check the status of all OpenEVSE functions. RAPI commands can be issued via the direct serial, web-interface, HTTP and MQTT. We recommend using RAPI over MQTT.

A full list of RAPI commands can be found in the OpenEVSE plus source code.

RAPI via web interface

Enter RAPI commands directly into to web interface (dev mode must be enabled), RAPI response is printed in return:

enable-rapi

rapi-web

RAPI over MQTT

RAPI commands can be issued via MQTT messages. The RAPI command should be published to the following MQTT:

<base-topic>/rapi/in/<$ rapi-command> payload

e.g assuming base-topic of openevse the following command will set current to 13A:

openevse/rapi/in/$SC 13

The payload can be left blank if the RAPI command does not require a payload e.g.

openevse/rapi/in/$GC

The response from the RAPI command is published by the OpenEVSE back to the same sub-topic and can be received by subscribing to:

<base-topic>/rapi/out/#

e.g. $OK

See video demo of RAPI over MQTT

RAPI over HTTP

RAPI (rapid API) commands can also be issued directly via a single HTTP request.

Assuming 192.168.0.108 is the local IP address of the OpenEVSE ESP.

Eg.the RAPI command to set charging rate to 13A:

http://192.168.0.108/r?rapi=%24SC+13

To sleep (pause a charge) issue RAPI command $FS

http://192.168.0.108/r?rapi=%24FS

To enable (start / resume a charge) issue RAPI command $FE

http://192.168.0.108/r?rapi=%24FE

There is also an OpenEVSE RAPI command python library.

OhmConnect

USA California only Join here

Video - How does it Work https://player.vimeo.com/video/119419875

-Sign Up -Enter Ohm Key

Ohm Key can be obtained by logging in to OhmConnect, enter Settings and locate the link in "Open Source Projects" Example: https://login.ohmconnect.com/verify-ohm-hour/OpnEoVse Key: OpnEoVse

System

system

Authentication

Admin HTTP Authentication (highly recommended) can be enabled by saving admin config by default username and password.

HTTP authentication is required for all HTTP requests including input API

Firmware update

Pre-compiled .bin's can be uploaded via the web interface, see OpenEVSE Wifi releases for latest updates.

Hardware reset

A Hardware reset can be made (all wifi and services config lost) by pressing and holding GPIO0 hardware button (on the Huzzah WiFi module) for 10s.

Note: Holding the GPIO0 button for 5s will but the WiFi unit into AP (access point) mode to allow the WiFi network to be changed without loosing all the service config


Upload pre-compiled firmware

esptool.py write_flash 0x000000 firmware.bin

  • Or the OpenEnergyMonitor emonUpload tool can be used to automatically download and flash the latest firmware. Be sure to select the correct version.

  • Or use Pyflasher GUI avilable on windows/mac

Firmware Compile & Upload

The ESP should be shipped with latest firmware pre-installed, firmware can be updated via the HTTP web interface.

Updating from V1: it's possible to update from V1 to V2 firmware using the HTTP web interface uploader, just upload the latest .bin pre-compiled firmware release.*

If required firmware can also be uploaded via serial using USB to UART cable.

The code for the ESP8266 can be compiled and uploaded using PlatformIO or Arduino IDE. We recommend PlatformIO for its ease of use.

Compile & Upload Using PlatformIO

For more detailed ESP8266 Arduino core specific PlatfomIO notes see: https://github.com/esp8266/Arduino#using-platformio

a. Install PlatformIO command line

The easiest way if running Linux is to install using the install script. See PlatformIO installation docs. Or PlatformIO IDE can be used :

$ sudo python -c "$(curl -fsSL https://raw.githubusercontent.com/platformio/platformio/master/scripts/get-platformio.py)"

b. And / Or use PlatformIO IDE

Standalone built on GitHub Atom IDE, or use PlatformIO Atom IDE plug-in if you already have Atom installed. The IDE is nice, easy and self-explanatory.

Download PlatfomIO IDE

1. Clone this repo

$ git clone https://github.com/OpenEVSE/ESP8266_WiFi_v2.x

2. Compile & upload

  • Put ESP into bootloader mode
  • On other ESP boards (Adafruit HUZZAH) press and hold boot button then press reset, red LED should light dimly to indicate bootloader mode.
  • Compile and upload using platformIO
pio run -t upload

To enable to OTA upload first upload via serial using the dev environment, this enables to OTA enable build flag. See `platformio.ino

*Note: uploading SPIFFS is no longer required since web resources are now embedded in the firmware

Building the GUI

The GUI files are minified and compiled into the firmware using a combination of Webpack and a custom build script. You will also need Node.JS and NPM installed.

In addition the GUI is now maintained in a separate repository and included as a Git submodule. If the gui directory is empty use the following to retrieve the GUI source and fetch the dependencies.

git submodule update --init
cd gui
npm install

To 'build' the GUI use the following:

cd gui
npm run build

You can then just compile and upload as above.

For more details see the GUI documentation


Compile & Upload Using Arduino IDE

1. Install ESP for Arduino with Boards Manager

From: https://github.com/esp8266/Arduino

Starting with 1.6.4, Arduino allows installation of third-party platform packages using Boards Manager. ESP Arduino packages are available for Windows, Mac OS, and Linux (32 and 64 bit).

  • Install Arduino 1.6.8 from the Arduino website.
  • Start Arduino and open Preferences window.
  • Enter http://arduino.esp8266.com/stable/package_esp8266com_index.json into Additional Board Manager URLs field. You can add multiple URLs, separating them with commas.
  • Open Boards Manager from Tools > Board menu and install esp8266 platform (and don't forget to select your ESP8266 board from Tools > Board menu after installation).

2. Compile and Upload

  • Open src.ino in the Arduino IDE.
  • Compile and Upload as normal

Troubleshooting

WiFi Connection issues

It's been reported that the OpenEVSE WiFi has issues with non standard MTU settings, we recomend using the standard 1500 bytes for router MTU setting

Uploading issues

  • Double check device is in bootloder mode
  • Try reducing the upload ESP baudrate
  • Erase flash: If you are experiencing ESP hanging in a reboot loop after upload it may be that the ESP flash has remnants of previous code (which may have the used the ESP memory in a different way). The ESP flash can be fully erased using esptool. With the unit in bootloader mode run:

$ esptool.py erase_flash

Output:

esptool.py v1.2-dev
Connecting...
Running Cesanta flasher stub...
Erasing flash (this may take a while)...
Erase took 8.0 seconds

Fully erase ESP

To fully erase all memory locations on an ESP-12 (4Mb) we need to upload a blank file to each memory location

esptool.py write_flash 0x000000 blank_1MB.bin 0x100000 blank_1MB.bin 0x200000 blank_1MB.bin 0x300000 blank_1MB.bin

View serial debug

To help debug it may be useful to enable serial debug output. To do this upload using openevse_dev environment e.g.

pio run -t upload -eopenevse_dev

The default is to enable serial debug on serial1 the ESP's 2nd serial port. You will need to connect a debugger to the ESP serial1 Tx pin (GPIO2).

To change to use serial0 (the main ESP's serial port) change -DDEBUG_PORT=Serial1 to -DDEBUG_PORT=Serial in platformio.ini. Note that using serial 0 will adversely effect RAPI communication with the openevse controller.


About

Collaboration of OpenEnergyMonitor and OpenEVSE.

Contributions by:

  • @glynhudson
  • @chris1howell
  • @trystanlea
  • @jeremypoulter
  • @sandeen
  • @lincomatic
  • @joverbee

Licence

GNU General Public License (GPL) V3

esp8266_wifi_v2.x's People

Contributors

chris1howell avatar glynhudson avatar jeremypoulter avatar joverbee avatar kronenpj avatar lincomatic avatar moeabm avatar realdesilets47 avatar sandeen avatar slyremarks avatar suriv avatar trystanlea avatar wt avatar yoavl avatar zymurgic avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

esp8266_wifi_v2.x's Issues

Several EVSE settings are read only once at bootup

There are several OpenEVSE values that may be changed at runtime but are polled only once, when the wifi boots up.[1] On the other hand, they change infrequently enough that they probably don't need to be part of the primary RAPI polling loop. Perhaps they should be directly updated if any of the input methods (RAPI screen, future config screen) are used to change their values.
[1] ammeter scale, charge limits, pilot value, safety check status

RAPI over MQTT broken?

Just tested RAPI over MQTT which was working reliably in the past. Now seems not to work running latest master with PR #51

Publishing a RAPI command to MQTT e.g. openevse/rapi/in/$GC (assuming openevse is the base MQTT topic set on the ESP) should result in a RAPI response being posting to openevse/rapi/out. There is no response.

Looking at the debug output I don't think the MQTT message is getting received since there is no debug output to indicate. "MQTT received" should appear in the debug ouput when an MQTT message is received: https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/blob/stable/src/mqtt.cpp#L33

MQTT status is publishing nicely has has been reliable for 20hr 👍

Whitespace is kind of a disaster ;)

What is the desired whitespace/indentation for the project? The mix of tabs & spaces is kind of a disaster for readability; is there a desired editor setting to make it all come out right, or would a flag-day whitespace fixup be reasonable?

Tree-wide whitespace fixes can be nasty because patches won't apply well across the change, but a once and for all cleanup might help with code maintenance going forward ... Just a thought.

So in short: What is the expected coding style, and would you accept a patch to make it consistent?

Thanks,
-Eric

Change energy limit to drop down box

After using the UI interface for a few weeks I've realised that drop-down menus are much easier to use on mobile devices than entering numbers directly. I propose changing the energy limit field to a drop down box.

I've made a start implementing this but can't work out why the options are not showing up. @jeremypoulter could you try finish this for me! Thanks.

I've committed my changes so far to energy-limit-picker branch: 96c633d

Session Wh counter does not reset if using delay timer?

In the past when charging with my OpenEVSE I've always used the onboard charging timer in my Nissan LEAF, however now I have the ability to easily set the OpenEVSE delay timer via the Wifi 2.0 GUI interface I have now turned off the car internal timer and am now using the OpenEVSE delay timer to schedule charging overnight.

Once issue I've noticed is the OpenEVSE Wh session counter does not reset in between charging sessions when the delay timer is active. I.e previously when the car was unplugged then replugged in the OpenEVSE session wh counter would reset.

@chris1howell @lincomatic is this a known bug in 3.11.3? Or is it due to the Wifi 2.0 FW? Are you able to replicate?

e.g. my session wh counter is now 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 23kWh in 10min! Btw I'm loving the new UI, nice work @jeremypoulter 👍

screenshot 2017-08-10 at 00 51 05

Print IP address to LCD on WiFi connect

After a hard reset I connected to the ESP WiFi AP and entered my SSID password. The Wifi ESP connected successfully. It would be very useful if at this point the ESP printed to the openEVSE LCD to announce successful connection (or otherwise!) it's new IP address on the network like it does at startup.

Can't update SPIFFS via webpage update

I know this is a known issue, but I'm wondering where things are at development-wise. Chris had mentioned the inability to update SPIFFS over the air.

There seem to be 2 OTA update libraries; ESP8266HTTPUpdateServer and ESP8266httpUpdate.

I see that https://github.com/esp8266/Arduino/tree/master/libraries/ESP8266httpUpdate/examples/httpUpdateSPIFFS allows a SPIFFs update, but it expects a URL to the update image, rather than a local file. Is local file upload a requirement?

Thanks,
-Eric

master branch?

Would it be possible to set master branch as the default branch and remove the incorrectly spelt 'Devolopment' branch? We can then create feature branches as appropriate .

Replicate OpenEVSE local (LCD) controls on web UI

All the controls on the OpenEVSE LCD should be available on the web UI with a focus on;

  • Change charge current limit
  • Set the time limit
  • Set energy limit
  • Set charging timer
  • Setting the current time, see #15
  • Set the service Level
    • Use location to set appropriately for the region?

Data corrupted after SPIFFS HTTP upload failure

Just tried to upload SPIFFS via HTTP which seemed to fail now the unit does not seem to be responding:

Does this debug log give you a clue as to what might have gone wrong?

e: 10736
Free: 13320
Time1
emonpi/emoncms/input/post.json?node=openevse-http&json={amp:0,wh:0,temp1:305,temp2:0,temp3:230,pilot:32,state:254,freeram:13176,divertmode:1}&apikey=906b00dc816304b4793568913d1c14c2
HTTP
ok
openevse/amp = 0
openevse/wh = 0
openevse/temp1 = 305
openevse/temp2 = 0
openevse/temp3 = 230
openevse/pilot = 32
openevse/state = 254
openevse/freeram = 13176
openevse/divertmode = 1
Free: 18808
Free: 18808
Free: 18808
Free: 18808
Free: 18808
Free: 18808
Free: 18808
Free: 13320
Free: 18808
Free: 18808
Free: 18808
Free: 18808
Free: 18808
Free: 18976
Free: 20896
Time1
emonpi/emoncms/input/post.json?node=openevse-http&json={amp:0,wh:0,temp1:305,temp2:0,temp3:230,pilot:32,state:254,freeram:20872,divertmode:1}&apikey=906b00dc816304b4793568913d1c14c2
HTTP
ok
openevse/amp = 0
openevse/wh = 0
openevse/temp1 = 305
openevse/temp2 = 0
openevse/temp3 = 230
openevse/pilot = 32
openevse/state = 254
openevse/freeram = 20872
openevse/divertmode = 1
Free: 20896
Free: 20896
Free: 20896
Free: 20896
Free: 20896
Free: 17360
Free: 16096
Free: 20344
Free: 14584
Free: 14584
Free: 19240
Free: 19240
Free: 19240
Free: 11120
Time1
emonpi/emoncms/input/post.json?node=openevse-http&json={amp:0,wh:0,temp1:305,temp2:0,temp3:230,pilot:32,state:254,freeram:11144,divertmode:1}&apikey=906b00dc816304b4793568913d1c14c2
HTTP
Emoncms error: server error: -1
openevse/amp = 0
openevse/wh = 0
openevse/temp1 = 305
openevse/temp2 = 0
openevse/temp3 = 230
openevse/pilot = 32
openevse/state = 254
openevse/freeram = 11144
openevse/divertmode = 1
Free: 11008
Free: 10984
Free: 10960
Free: 11104

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld

Using default ''
Got '�' 15 == 110 @ 544:33
Using default ''
Got '' 255 == 128 @ 128:45
Using default 'data.openevse.com/emoncms'
Got '' 255 == 128 @ 173:32
Using default 'openevse'
Got '�' 0 == 4 @ 438:60
Using default '7D:82:15:BE:D7:BC:72:58:87:7D:8E:40:D4:80:BA:1A:9F:8B:8D:DA'
Got '' 255 == 128 @ 205:45
Using default 'emonpi'
Got '' 255 == 128 @ 250:32
Using default 'openevse'
Got '' 98 == 128 @ 282:32
Using default 'emonpimqtt'
Got '(a,b){var c,d,e=n.ajaxSettings.flatOptions||{};for(c in b)void ' 48 == 172 @ 314:64
Using default 'emonpimqtt2016'
Got '!==b[c]&&((e[c��' 105 == 127 @ 378:30
Using default ''
Got 'b.js' 0 == 213 @ 408:30
Using default ''
Got '�' 0 == 63 @ 498:16
Using default ''
Got '�' 0 == 80 @ 514:16
Using default ''
Got '�' 0 == 97 @ 530:10
Using default ''
Got 'eb00ec'  0 == 135 @ 540:4
Using default '000000'
After config_load_settings: 30760
Starting AP
AP IP Address: 192.168.4.1
After wifi_setup: 29504
Server started
After web_server_setup: 23456
After ota_setup: 22560
Free: 22640
first read RAPI values
Free: 22872
Free: 22872
Free: 22952
Free: 22952

Once enabled, emoncms & mqtt cannot be disabled

The javascript under the save-emoncms element checks for null server name and wrong-length API key, and fails the save request in those cases. However, this makes it impossible to gracefully disable the emoncms push once it has been configured. (Similar problems exist for mqtt)
Either an "enable" checkbox, or simply adding the ability to save empty server name + empty API key, would allow the service to be turned off if desired.

Favicon

Low priority but nice to have :-)

How about the OSHW cog logo from the OpenEVSE logo?

'automatically' set current time setting misleading?

From this discussion #15 I remember that the auto time should be obtained from the web browser. I remember when I initially tested this when #51 was merged it seemed to work.

However testing again now it seems not to work, see attached. Tested in both firefox and Chrome

selection_096

Recent changes seem to have mismerged

After commit f7c61ca things seem to have gone off the rails a bit - perhaps a mis-merge, I can't tell for sure, some of the changes are dated March if I use git blame...

  • #define DEBUG_SERIAL1 got commented out in src/emonesp.h, and now debug messages are going out on the main serial line.
  • The solar divert tab is also now visible by default (was that intentional?)
  • home.html got renamed to home.htm
  • input.cpp gained new whitespace damage
  • etc.

Did something go wrong on recent commits to master?

Delay timer does not fit on a mobile device

When webpage is viewed on Nexus 5x the delay timer 'Start' / 'Stop' boxes don't fit:

screenshot_20170814-232653


Btw loving how the openevse webpage uses native mobile device date / time picker 👍

screenshot_20170804-235846

Solar PV divert (to do)

To summarise my discussion with @jeremypoulter this afternoon. Solar PV divert should:

  • Only adjust charging current up to the maximum already set in the OpenEVSE
  • When diversion charging has finished (in Eco mode) or car is unplugged the Openevse should revert back to normal mode ready for the next charge. By default the car should always start a normal charge when it's plugged in
  • The RAPI commands sent by the divert function should be changed to use the rapi sender class which will add the checksum and be more robust.
  • The text information in the html page should be changed to info pop out boxes
  • The Solar PV divert buttons (eco / normal) should be moved to the main OpenEVSEtab and the Mode button should be removed
  • Solar PV diversion to be tested using MQTT nodeRED solar PV simulator: https://github.com/openenergymonitor/openevse-solarpv-divert-nodered

Simple Status UI: elapsed time?

I've made a start at making a simple status UI box to sit at the top of the page. The idea is that this status UI should show the user at a glance the most important things. e.g is the car charging? At what rate? How many Kwh so far?

One useful metric that we're not currently displaying is elapsed time. Elapsed time (in seconds) is returned in the 2nd element via RAPI get status $GS. @jeremypoulter do you think it would be possible to get elapsed time (in minutes) onto the UI display and add it to my status UI box as a third column?

I think it would be also good if the status message e.g. "Charging / Waiting etc." was highlighted in the same color and the LCD. e.g. green = charging , purple = sleeping / waiting.

Any feedback on this proposed status UI box? Do you think it' useful?

screenshot 2017-08-07 at 01 15 26

WiFi should be used to keep correct time

It would be very good if the network connectivity in the WiFi unit could be used to keep correct time in the EVSE. There are a few options that I can think of:

The first two options have some degree of difficulty selecting and managing the many changing time zones, especially with daylight savings time changes. (Both return time in GMT, and must be converted to local time). The third option makes this quite easy (those smarts are on the other end), but it would likely require the user to sign up for another account to get an API key for the service.

We may also want to consider whether EVSE time should be kept in GMT, or in local time.

Another small wrinkle would be how to handle an active scheduled charging session and/or time-limited session if the clock changes underneath it.

Publish state name string and session energy MQTT

Instead of publishing state number (e.g. 1 means not connected) to MQTT it would be more useful to publish the string "Not Connected" to MQTT state topic. This would make integration with other home automation platforms much easier. e.g. the state string could be displayed in openHAB directly from MQTT without having to re-create a lookup.

Likewise having session energy (Kwh) published to MQTT would also be very useful to integrate with other platforms. e.g. display how many Kwh the car has charged in this session in OpenHAB / Home assistant / amazon echo etc.

Should the Vcc display be removed?

Vcc isn't shown in the html today, and this breaks javascript which references a document ID which doesn't exist.

I sent a pull request to fix the ESP.getVcc() call and display it on the status page, but Glyn questioned its usefulness and suggested that maybe it should be removed.

Are there any strong preferences either way? I don't think there's much overhead to collecting it, it's not i.e. a RAPI call with the associated serial overhead. I was originally going to remove it, but I doubt it's impacting performance in any significant way. Just opening the issue to see if there are opinions one way or another, then I'm happy to fix it as desired.

Thanks,
-Eric

Send dummy password

Instead of not sending passwords a known dummy value should be sent in place of the password so it looks like a password is set in the UI. This should also be filtered out when saving the values and leave the existing password unchanged.

Inconsistent use of GFCI/GFI

GFCI/GFI look to both be used interchangeably, should be consistent across the OpenEVSE/OpenEVSE WiFi (which probably means using GFI)

Web page hanging, browser refresh required to fix

Often when trying to load the web page from the ESP the page hangs on "loading", after a browser refresh (sometimes two is required) the page loads. Here is a network activity capture showing the page hanging the subsequently loading after a page refresh:

selection_094

selection_095

Setting defaults

I realised when merging the recent changes to EmonESP that I had inadvertently removed all the default values from the HTML UI and I was considering adding them back when it occurred to me that maybe the best solution is that the defaults should probably only be set in the ESP code (ie config.c) as that is really the only place that can tell an empty string from an unset value, (ok maybe not the only place, but certainly the easiest).

Anyone have an issue with putting the defaults in config.c and leaving the HTML as just a pass through?

Divert UI buttons don't persist state

Just tested #62 , it looks like the solar PV divert buttons don't persist the mode.

e.g. if I select "Eco Mode", eco mode gets correctly set (I can see via serial output).

screenshot 2017-08-06 at 14 05 08

Then if I refresh the web page the divert buttons go back to being unselected:

screenshot 2017-08-06 at 14 05 21

It's also not clear from the colours of the buttons which mode is selected. Currently white = selected and blue/green = not selected. I'm not sure how to improve this, maybe it is clear enough? Ideas welcome, I'm not an UI expert!

Update flashing instructions

Merge updated instructions from stable and update to reflect changes to no longer need SPIFFS.

Also include instructions for v1 -> v2 update (#86)

Web page connection hanging at first load

I've just been testing the latest changes and I find that the webpage seems to hang on "loading please wait" when I try and load the web page for the first time via the captive portal.

If i revert back to c95ef7d this seems to work fine, then moving forward a few commits to e6b65c3 the hanging issue returns. It seems it's just the web server that's hanging. The serial port shows the device is still issuing RAPI commands.

Do you think the increase in EEPROM_SIZE increase to 4096 might be causing an issue? I'm testing on Adafruit Huzzah.

I will debug further tomorrow. Just wanted to quickly confirm with @jeremypoulter that the latest master branch is working fine for you? Maybe it's just me!

Turn off AP / reboot after first connection to WiFi

After connecting to a Wifi network, a reboot seems to be required before I can load the webpage.

This sometimes happens because my laptop / mobile device is still connected to the openevse AP

Could a possible solution be to force an ESP reboot after connecting to Wifi for first time? This would have the added advantage of printing the new IP address of the ESP on the network to the LCD.

Or maybe just turning off AP will fix the issue?

Upgrade path for ESP WiFi V1 users

There is a large users base of OpenEVSE users running @chris1howell WiFi EPS V1 FW:

https://github.com/OpenEVSE/ESP8266_WiFi_v1.x

It would be very useful if users could update from V1 > V2.

  • V1 has a working HTTP update
  • It's acceptable IMO for the config to be lost, therefore the user would need to re-enter their WiFi password and Emoncms API key. Do you agree @chris1howell ?
  • It's acceptable for the update to be a two-part process if required. Most OpenEVSE users should be happy following update instructions.
  • Having to resort to serial update should be avoided if possible

RAPI update loop is painfully slow

When the main loop calls update_rapi_values() every 5s it iterates very slowly through each call:

wait 5s, call
  Issue new RAPI cmd
wait 5s, call
  Parse last RAPI cmd
wait 5s, call
  Issue new RAPI cmd
wait 5s, call
  Parse last RAPI cmd

etc. The main loop has a timer to call it once every 5s, so this means it takes 10s for each RAPI call to be made and and then read/parsed. There are currently 4 RAPI calls made, and that's before my pending patch to add 2 more (to keep energy & fault counts up to date). With 6 unique RAPI calls, that means values are only updated once per minute.

This behavior was introduced by
7cf4a90 fix firmwarware update by slowing down RAPI updates to 5s.
The prior behavior of call/parse/call/parse iteration was done by Chris with:
d1d6c2e Significant improvement to RAPI read/write

write/wait 5s/read/wait 5s/write ... surely seems slower than necessary. What are the limitations here? Clearly delay() for serial comms is undesirable, but 5s intervals must be overkill.

Glyn mentioned that 7cf4a90 was to fix (unspecified) problems with http firmware updates. Some elaboration on that problem would be nice, but perhaps a better solution would be to suspend RAPI updates during the rare case of a http firmware update?

Thanks,
-Eric

Don't save the max current during divert

The dev firmware allows you to specify if the max current is saved.

SC amps [N]- set current capacity
response:
if amps < minimum current capacity, will set to minimum and return $NK amps
if amps > maximum current capacity, will set to maximum and return $NK amps
otherwise return $OK amps
default action is to save new current capacity to EEPROM.
if N is specified, then new current capacity is volatile, and will be
reset to previous value at next reboot

see OEM forum

When changing the max current during divert the value should not be saved.

Question how is this handled in the stable firmware.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.