openevse / openevse_esp32_firmware Goto Github PK

Using hostname lookup in a desktop browser e.g http://openevse.local results in the following errors. These errors result in some parameters not being displayed e.g max current

Access to XMLHttpRequest at 'http://192.168.86.20/r?json=1&rapi=$GH' from origin 'http://openevse.local' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Using hostname access:

Using direct IP address (no errors):

I apologize if this request is being worked on already, but if so, I couldn't find it.

I'd like the ability to set schedules for charging by day, and time, multiple times per day (if possible).

I have time-of-use billing and I would rather have the schedule of cheap rates (mostly at night) done on my OpenEVSE rather than my 2014 Volt. I know that right now I can set a daily schedule, but that doesn't help me when my weekend rates are the same as my nightly rates during the week :)

"GUI documentation"

https://github.com/OpenEVSE/ESP32_WiFi_V3.x/blob/master/gui/readme.md

It would be useful if it was possible to enable debug from within the web UI, is this possible?

• Disable root certificate validation per client
• Update root certificates
• HTTPS server certificate/private key (GUI)
• MQTT client certificate/private key

Test using Olimex ES32-gateway with Ethernet to be used instead of Wi-Fi when installation is more suited to wired Ethernet

https://www.olimex.com/Products/IoT/ESP32/ESP32-GATEWAY/open-source-hardware

Enable HTTPS support for the webserver, including changing the certificate and private key.

This is another un-important possible change...

At the moment messages are posted to

<base topic>/

which by default is

openevse-XXXX/

but announce messages are posted to (irregardless of base topic):

openevse/announce/XXXX

(although that may change soon toopenevse/announce).

For consistency does it make sense to have a separate base topic , so messages would be posted too:

openevse/<base topic>

which would then by default be:

openevse/openevse-XXXX

I guess the problem with this is that it isnt backward compatible?

Personally I dont have strong feelings about this. But I thought it would be worth raising it.

In order of priority:

• Don't scan until the user clicks a 'Scan' button, this will avoid scanning for networks if a user wants to continue in standalone mode
• Only scan once, this will avoid the list changing in size while the user is trying to enter their passkey
• Sort SSID'S by RSSI in descending order (less negative RSSI = stronger signal = display first)
• Don't display very weak networks

These seemingly minor tweaks are actually very important, it took many attempts to setup a WiFi in a location with 100's of WiFi networks since the wifi network scan table kept jumping around in size while trying to enter a complex PSK. Most of the WiFi networks where very weak and should not have been displayed. Also if a user wants use to use stand-alone more it's frustrating to have to wait for a wifi scan that is not needed.

Add support for secure MQTT connections, depends on #29

All the info in http://status should be made available via MQTT.

Also ESP chipID should be added to status and also posted to MQTT

We should add some hardware info to the config so we can distinguish between the ESP8622 and ESP32

See: https://github.com/OpenEVSE/openevse_wifi_gui/blob/d33c27fd2e83d8a85ae9f6c69d01e2b29a68879a/src/wifi_portal.htm#L74

After connecting to WiFi network the module suggests browsing to http://openevse/, this should be updated to include the unique string e.g http://openevse-55ad/

If possible the RAPI loop should be non-blocking and if the open evse controller is not detected a message should be displayed:

"OpenEVSE controller not detected, please check connections"

• RAPI comms non-blocking
• Display message in UI when OpenEVSE is not connected

Trying to update via HTTP web interface results in ESP32 rebooting but update is no applied. The firmware file does not seem to uploading correctly. Browser does not register a file upload:

Here is the debug log showing the update process starting them immediately rebooting

Free: 250504
Free: 251192
Free: 251652
Free: 251652
Free: 251652
Update Start: firmware.bin
Update: 0%

0:32
Got 'emonpi' 144 == 144 @ 282:32
Got 'emonpimqtt2016' 137 == 137 @ 314:64
Got 'emon/emontx3/power2' 242 == 242 @ 378:30
Got '' 128 == 128 @ 408:30
Got '' 255 == 128 @ 498:15
Using default ''

I can't seem to compile the latest mater branch. I think the issue could be due to changing the build script to use python3. What are the steps I need to tell Pio to use Python3? I've got python 3.6.8 installed on my machine which in invoked by $ python3 just $python invokes python 2.7.15

We should make each OpenEVSE unique, this will fix the issues of conflicting devices on a single network and help with integration with services that require unique ID e.g home assistant auto config etc. Each device should have a name consisting of openevse- followed by 4 chars representing the 'chip ID`

openevse-<chipID>
openevse-1234

The <chipID> should be the base64 encoded version of the NIC specific part of the MAC address/Chip ID. Each char in Base64 encodes 6 bits, 6x4=24 which just happens to be the number of chars that should be easy to remember and the number of bits of the MAC NIC.

Note: Even though Base64 is case sensitive and some of the context that it will be used (eg host name) are not, it still should be sufficiently unique. Also need to consider the mapping of the '62' and '63'.

We should append ESP Chip ID to the following default strings:

• Wifi AP SSID, currently uses chip-ID but should be reduced to 4 characters for consistency?
• hostname
• MQTT base-topic
• Emoncms node name

In order for other services to discover the openevse and determine the unique ID the MQTT initial connection message and LWT (last will testament) should be published to a fixed topic e.g

• MQTT initial connection message to openevse/announce/<chip ID> topic. The message will be a JSON block of the format:

{
  "state":"connected",
  "name":"openevse-<chipID>",
  "mqtt":"<MQTT base topic>",
  "http":"<HTTP endpoint>"
}

• MQTT LWT (last will testament) disconnection message to openevse/announce/<chip ID> topic
  The message will be a JSON block of the format:

{
  "state":"disconnected",
  "name":"openevse-<chipID>"
}

Both the initial connection message and LWT should have MQTT retain flag set

The 'pilot' and 'temp' metrics posted to Emoncms / MQTT are incorrect on the ESP32. The values for these metrics shown on the webpage are correct.

Temp1 should be the internal temperature sensor. Temp2/3 are not used on the standard OpenEVSE and should be large negative numbers.

Demand shaper uses a day ahead power availability forecast to schedules charging sessions at the lowest cost Octopus Agile / carbon time. The forecast could be grid carbon intensity, of cost e.g Octopus API OpenEVSE/ESP8266_WiFi_v2.x#175

Demand shaper module is available for Emoncms, it would be preferable to run it locally on the ESP: https://github.com/emoncms/demandshaper

• DSR event could be entered into the schedule be setting the forecast signal to a very high cost level for the DSR period
• Multiple forecast signals could be combined e.g grid carbon / cost + DSR event
• EV state of charge could be provided by a MQTT topic or from OVMS #emoncms/demandshaper#7
• Amount of kWh input could be specified with converter to miles

When using on a Raspberry Pi Zero W (which is a pain to get Node.js running on anyway as Pi Zero is armv6. But it's plenty fast for talking serial to the OpenEVSE over Rapi. At any rate...

Node V11.5.0
NPM V 6.4.1

Here's the report...which may entirely be my fault, so feel free to shout me down, call me an idiot and kick-ban me for life. But this is what the freshest of fresh installs yielded.

                      === npm audit security report ===                        
                                                                                
# Run  npm update handlebars --depth 3  to resolve 4 vulnerabilities
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Denial of Service                                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ handlebars                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ nyc [dev]                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ nyc > istanbul-reports > handlebars                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/1300                      │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Arbitrary Code Execution                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ handlebars                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ nyc [dev]                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ nyc > istanbul-reports > handlebars                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/1316                      │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Arbitrary Code Execution                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ handlebars                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ nyc [dev]                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ nyc > istanbul-reports > handlebars                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/1324                      │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ handlebars                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ nyc [dev]                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ nyc > istanbul-reports > handlebars                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/1325                      │
└───────────────┴──────────────────────────────────────────────────────────────┘

Currently, the codacy badge in the readme still points at the ESP8266 version:
https://app.codacy.com/manual/jeremy_poulter/ESP8266_WiFi_v2.x/dashboard

Posting to Emoncms (emonPi) via http / https works great but even when successfully posting the interface still reports Connected: No and debug log reports Emoncms error: {" success": true}

Currently, I'm posting to an emonPi which does not support https, is https only enabled for emoncms.org and data.openevse?

I can't see to get OTA upload to work either am I missing something? I checked that ENABLE_OTA was enabled in the build flags.

Uploading .pioenvs/openevse_huzzah32/firmware.bin
19:34:15 [DEBUG]: Options: {'timeout': 10, 'esp_ip': '192.168.86.20', 'host_port': 33428, 'image': '.pioenvs/openevse_huzzah32/firmware.bin', 'host_ip': '0.0.0.0', 'auth': '', 'esp_port': 8266, 'spiffs': False, 'debug': True, 'progress': True}
19:34:15 [INFO]: Starting on 0.0.0.0:33428
19:34:15 [INFO]: Upload size: 1295600
Sending invitation to 192.168.86.20 ..........
19:35:55 [ERROR]: No response from the ESP
*** [upload] Error 1

Building with 1.10.0 or the ESP32 BSP fails, see https://travis-ci.org/OpenEVSE/ESP32_WiFi_V3.x/builds/585990684

Most likely as a result of espressif/arduino-esp32@56ce580

Based on discussion here: me-no-dev/ESPAsyncWebServer#324 (comment) we are moving the ESP32 port to use the Mongoose via ArduinoMongoose

• Web server
  • Basic web server port
  • Websockets, needs jeremypoulter/ArduinoMongoose#1
  • Web server HTTPS
  • Web server authentication, needs jeremypoulter/ArduinoMongoose#2
  • Caching headers, needs jeremypoulter/ArduinoMongoose#3
• WiFi - needed for OpenEVSE/ESP8266_WiFi_v2.x#182
  • WiFi events
  • Hidden SSIDs ?
  • Set hostname
• HTTP(S) clients
  • EmonCMS HTTPS client
  • OhmConnect HTTPS client
• MQTT client
  • basic MQTT client port, needs jeremypoulter/ArduinoMongoose#4
    • error handling
  • Secure MQTT
• Certificate Management
  • Update root certificates
  • Disable root certificate validation per client
• OTA update
  • Upload firmware via Webserver
  • Upload firmware via Arduino IDE/Platform IO
  • Check for updates and download from GitHub releases?
• Board support - needed for OpenEVSE/ESP8266_WiFi_v2.x#182
  • ESP-WROVER-KIT
  • NodeMCU-32s
  • Huzzah 32
  • Olimex ESP Gateway
  • Custom board
• Release
  • New Repository
    or
  • ESP8266 support
• Misc
  • Async Serial read, report when not connected to OpenEVSE, #1

HTTPS is already supported for ESP32 however the UI needs updating to reflect this:

• Create dropdown box to select protocol HTTP/HTTPS
• Remove SHA1 fingerprint field as this is no longer required. This can can also be removed from EEPROM

A few times recently I have even noticing the car or is not properly being plugged in so in the morning the car has not been charged.

It would be really good if a notification could be sent if the car is not plugged in at some specific time, eg overnight.

Some possible options could be email, SMS, Slack or other web service.

WiFi to control sleep and charging with RAPI commands while on timers and eliminate the RTC chip. The chip and parts add significant cost to every batch of LCDs we make. Also timer functions take up considerable code space on the open_evse controller.

Time could be updated automatically via NTP and held in memory.

I added hooks to facilitate support of OCPP. In the process, RAPI got altered a bit, and became incompatible with existing code. The changes are as follows:

1. $ST async notification replaced with $AT, which has more parameters
2. $AB async notification is now sent on boot
3. $GS has 2 new parameters added to it. Also, the first parameter, state, is now in hexadecimal, instead of decimal, to make it consistent with $AT (and the now deprecated $ST)
   going forwards all async new async notifications will be of form $Ax.

I was going to create a pull request, but then realized that I don't understand your code well enough to fully test it. I've put some changes into the following commit in my own branch:

lincomatic/ESP8266_WiFi_v2.x@da56fea

Please review them, and alter as needed, at your convenience.

Building upon #15 it would be useful for Home Assistant integration for the Carbon Coop OpenDSR project that @beaylott is leading if:

• The OpenEVSE Announce message was periodically published to the announce topic (every 30s) and

• The announce message was published to the bare announce topic e.g openevse/announce rather than an ID sub topic e.g openevse/announce/<id>

What are your thoughts @jeremypoulter? I'm happy to make both these changes, I think it would make it easier for any service to integrate with OpenEVSE MQTT.

The free heap seems to be reducing linearly! After being running for about 24hrs the unit required a rest to become responsive. Since then, I've setup better logging to capture the freeheap to see what value resulted in a crash. I will continue to monitor

On the ESP32 Huzzah holding down GPIO0 for 5s does not force Wifi AP and holding GPIO0 for 10s does not force a hardware reset. Maybe the button for GPIO0 needs to be remapped?

We should write some API documentation on the HTTP API, would probably be a good idea to use OpenAPI and Swagger

Depends on jeremypoulter/ArduinoMongoose#1

After changing MQTT sub-topic RAPI via MQTT does not respond until reboot

e.g changing MQTT sub-topic from openevse-xyz to emon/openevse and posting to emon/openevse/rapi/in/$GS the openevse does not respond on emon/openevse/rapi/out until the ESP32 is rebooted.

Add basic energy savings.

Add ability to turn of LCD back light after x minutes of inactivity with the RAPI command $FB 0.

back light will turn back on automatically with any state change.

Port to the ESP32, primerially targeting the NodeMCU ESP-32S.

Currently we have a very basic random number seed:

  randomSeed(analogRead(0));

While this is kind of ok for ESP8266, on the ESP32 we are using a lot encryption so should improve the seed.

Here are some sources of inspiration:

• https://www.utopiamechanicus.com/article/arduino-better-random-numbers/

As far as I understand a common problem in older Nissan Leafs is that the car charger's firmware might not be fully compliant with SAE J1772. Upgrading that firmware might pose challenges as I've discovered; there seems to be not much interest from dealers and it's also not a high priority for others offering services that dealers do not offer.

It would be great if OpenEVSE would have a RAPI command that changes the default overcurrent threshold and timeout.

#define OVERCURRENT_THRESHOLD 5 // A
​#define OVERCURRENT_TIMEOUT 5000UL // ms

When an over current state is detected the GUI does not pick this up and displays 'invalid'

Clicking the update time button sends the RAPI command but the connection is immediately closed.

Depends on jeremypoulter/ArduinoMongoose#2

Print hostname e.g openevse-55ad to LCD display at startup just after IP address

Hostname lookup e.g htp://openevse does not seem to work on the ESP32

Add Hidden SSID support

The captive portal re-direct currently directs to a page with a link called "OpenEVES" which requires the user to click to forward to the actual landing page.

As a first step towards #5 and negating the need for a hardware RTC, NTP time from the ESP could be used to automatically set the time on the OpenEVSE controller.

We should keep the option to "sync" the time from a web browser for the use case where no web connection is present.

Open Charge Point Protocol: http://www.openchargealliance.org/protocols/ocpp/ocpp-16/

Allow OpenEVSE to integrate easily with other charging networks.

Spec attached:
ocpp-1.6_edition_2.pdf
OCPP_1.6_JSON_Specification.pdf

Wiki page: https://github.com/OpenEVSE/openevse_wifi_server/wiki/Open-Charge-Point-Protocol

It should not be possible to change the max current accidentally. We should add a user confirmation when selecting a current change via the UI.