Closed jeremypoulter closed 5 years ago
For anyone interested in following this, see https://github.com/jeremypoulter/ESP8266_WiFi_v2.x/tree/esp32_port
Would this make it possible to communicate with a bluetooth OBDII dongle to monitor state of charge?
Probably yes, but in practice range may be an issue as well as big metal boxes separating the the two devices... Worth raising a separate ticket for it though.
On 1 Jun 2018 04:42, "Eric Sandeen" notifications@github.com wrote:
Would this make it possible to communicate with a bluetooth OBDII dongle to monitor state of charge?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/182#issuecomment-393749188, or mute the thread https://github.com/notifications/unsubscribe-auth/AF1WgBhliRDzIDQCyGBZ2OCMSYq32wcmks5t4LgQgaJpZM4T9YPJ .
Would this make it possible to communicate with a bluetooth OBDII dongle to monitor state of charge?
A WiFi dongle would be a better choice, in terms of required range. My friend @davehun is working on exactly this. He has managed far to extract CAN bus info using open-source software on his laptop from a Nissan LEAF. Open-source project happy leaf lists the CAN bus addresses for SOH
Codes sent to the OBD are defined here: https://github.com/blandman/HappyLeaf/blob/master/app/services/flow-manager.js
Then are parsed here: https://github.com/blandman/HappyLeaf/blob/master/app/services/data-manager.js
This is an exciting development, best start a new issue for continued discussion.
Embedded Linux (Node J.S) port is currently the preferred choice over ESP32, see https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/issues/183. I will close this issue since it's not currently being worked on.
Adafruit has releases a clone of the Huzzah ESP8266, the Huzzah ESP32 is a plug in replacement. OpenEVSE is now working on a few ESP32 boards in a couple form factors. This issue is going to be reopened. Most ESP8266 libraries have ESP32 replacements, some of the replacements are compatible with both ESP32 and ESP8266. Best case would be a single codebase to support both.
I have begun working on a port, starting first with the Tesla API client I wrote for the ESP8266. The port was easy ant took a few minutes. Obviously this port is a lot more complex.
The basic port requires:
Improvements:
-Implement HTTPS on the local admin server with a self signed cert. -Change WiFiClientSecure to use Root CA instead of fingerprint (or use HTTPClient with https?) -Adding the Root CA for HTTPS
Future: -Move the LCD control and button UI over to the ESP32. This will allow much more control and more useful display of data. -Get time from NTP -Move timers over to ESP32 and additional functionality via EmonCMS.
I have a branch with the code ported:https://github.com/jeremypoulter/ESP8266_WiFi_v2.x/tree/esp32_port however the biggest problem was the AsyncWebServer library, it is not very stable on the ESP32 so we didn't continue with it. Probably we need to look at OpenEVSE/ESP32_WiFi_V3.x#2 first.
@jeremypoulter Is your port more stable than the asyncwebserver?
Not really, I have however started on OpenEVSE/ESP32_WiFi_V3.x#2 which we hope will lead to a stable ESP32 build.
AsyncTCP was updated with a new version with improved stability, updated the my fork/branch with and it kind of works a bit better, now no longer crashes but hits a watchdog reset.
E (188784) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (188784) task_wdt: - async_tcp (CPU 0/1)
E (188784) task_wdt: Tasks currently running:
E (188784) task_wdt: CPU 0: IDLE0
E (188784) task_wdt: CPU 1: loopTask
E (188784) task_wdt: Aborting.
abort() was called at PC 0x400f9238 on core 0
Backtrace: 0x4008cbcc:0x3ffbe160 0x4008cdfd:0x3ffbe180 0x400f9238:0x3ffbe1a0 0x40081b59:0x3ffbe1c0 0x4017a3a7:0x3ffbce80 0x400f7746:0x3ffbcea0 0x4008aa69:0x3ffbcec0 0x40088b69:0x3ffbcee0
@glynhudson I think this can be closed now
Port to the ESP32, primerially targeting the NodeMCU ESP-32S.