openevse / esp8266_wifi_v2.x Goto Github PK
View Code? Open in Web Editor NEWESP8266 WiFi for OpenEVSE Version 2.x
Home Page: https://openevse.openenergymonitor.org
ESP8266 WiFi for OpenEVSE Version 2.x
Home Page: https://openevse.openenergymonitor.org
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
All the controls on the OpenEVSE LCD should be available on the web UI with a focus on;
OpenEVSE WiFi now gets the state via the Async event so should also be pushed to MQTT immediately rather than when polled.
The current method for saving the config is not very flexible or future proof. As the ESP8266 has 4K of just saving a JSON block would allow for a bit more flexibility, eg https://github.com/jeremypoulter/SmartPlug/blob/master/src/config.cpp
Merge updated instructions from stable and update to reflect changes to no longer need SPIFFS.
Also include instructions for v1 -> v2 update (#86)
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
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.Did something go wrong on recent commits to master?
Currently port 80 is hard coded for the HTTP web server:
https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/blob/master/src/web_server.cpp#L18
Is there any room left in the EEPROM to have the HTTP port a configurable option? This would be useful when running alongside other servers on the same domain. e.g. accessing openevse externally via dynamic DNS
Pushing updates over MQTT blocks for around 160ms so it would be ideal to move to async-mqtt-client
I noticed the time was incorrect on the OpenEVSE, the update button does not seem to work to set the time either automatically for manually, see screen-cast:
https://drive.google.com/file/d/0B9yLIKTN3csqdUdyVDdMQ2VXdGs/view
Can you replicate this issue? I'm running latest master with PR #83
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.
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?
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.
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!
Sean has reported that the safety errors don't get recorded in the UI
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.
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 👍
Sean Fosberry has reported that the web page does not load on Microsoft Edge:
Would probably help with setup to implement a version of the Ammeter Calibrator in the web UI.
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?
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 .
Partly due to the changes to add defaults to the config and partly to resolve #14 it is desirable to have an explicit option to enable/disable the each of the services, MQTT, EmonCMS and Ohm.
like Level 2 Maximum: 80^29
fimrware D4.6.0
protocol 3.0.1
OpenEVSE 2.1.0
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.
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 👍
GFCI/GFI look to both be used interchangeably, should be consistent across the OpenEVSE/OpenEVSE WiFi (which probably means using GFI)
Is you have multiple access points with the same name the last on in the list will always be selected. Does not cause any problems, just bad UX.
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?
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
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
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
To summarise my discussion with @jeremypoulter this afternoon. Solar PV divert should:
OpenEVSE
tab and the Mode
button should be removedAfter 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
The Git version of the ESP Arduino Core now supports certificate validation; esp8266/Arduino#3271
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
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.
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.
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).
Then if I refresh the web page the divert buttons go back to being unselected:
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!
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.
If the charging timer (start / stop time) is set via the web UI or LCD then the web page is refreshed the UI does not display the current set start stop time.
It would be useful to have a JavaScript version of the Python RAPI library, initially for use by #34 but will also be generally useful outside of this, eg for a Node-RED node.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.