lincomatic / open_evse

Firmware for Open EVSE
GNU General Public License v3.0
114 stars 163 forks source link

Menu/UX: Indicate that SAE Service Level 1 is meant for 120V connections only #60

Closed borhub closed 6 years ago

borhub commented 8 years ago

To help steer non-American users away from selecting Level 1 and having their Wh calculations wrong (due to VOLTS_FOR_L1 that's used in KWH_RECORDING being hardcoded to 120V). I.e. people who select Level 1 but are running off 240V mains are presented with kWh display that's half of the actual usage.

http://www.sae.org/smartgrid/chargingspeeds.pdf

borhub commented 8 years ago

Another thing I was looking at... I have a board I purchased a month ago running 3.11.3. Contrary to what I would expect from reading the code, it allows me to select L2 current from 6A (rather than from 10A as in the #define). I wonder where this 6A is coming from? Don't get me wrong, I actually like this flexibility to select the low current, as I am on 240V and want to have my energy calculations right at the same time. I don't think the boards are shipping with a custom version of the FW, so puzzled as to why my L2 range is 6A to 80A...

And a third thing: had I not experimented with the RAPI, I would have never found out about the time limit and kwh limit setting. I think it would be much better UX if the menu entries for these were available by default - but perhaps have an equivalent of being "greyed out" when car is not connected, for example by displaying a message [Plug car to set...] or similar.

lincomatic commented 6 years ago

sorry for taking so long to merge this.. I didn't see it until just now

glynhudson commented 6 years ago

I wonder where this 6A is coming from?

6A is the correct J1772 lowest power that all EV's should support. The 10A minimum was an error in 4.8.0. It's now been fixed in later versions see: https://github.com/lincomatic/open_evse/issues/73

And a third thing: had I not experimented with the RAPI, I would have never found out about the time limit and kwh limit setting. I think it would be much better UX if the menu entries for these were available by default - but perhaps have an equivalent of being "greyed out" when car is not connected, for example by displaying a message [Plug car to set...] or similar.

True, also I see no reason why the energy/time limit could not be set before the car was plugged in. Or set persistently e.g. private charger only allowing XX Kwh or time limit per session. I accept this is a non-standard use case and not a priority.

LCD menu is always going to be limited. Better to use the WiFi gateway for easier interface access: https://github.com/openevSE/ESP8266_WiFi_v2.x/

lincomatic commented 6 years ago

In an ideal world, everything would be perfect. We have extremely limited resources in the EVSE. Making the menus fancier is possible, but would waste precious space for something more important. I can't remember why I implemented the charge/time limits such that they are only available during charging. Some possibilities are that I wanted to avoid having a limit set by accident, and having a very unpleasant surprise upon returning to the car, and/or it was just easier that way, and I wanted to get the features in ASAP. Also, when limits were implemented, we were literally out of space. A later version of the compilers optimized better, and gave us back some breathing room for minor tweaks, but anything that's not a core function should really be done externally, either through the ESP, as glynhudson suggested, or perhaps with a Raspberry Pi connected to a fancy touchscreen. Future major enhancements, such as OCPP are going to need to be implemented with an external processor, speaking RAPI to the EVSE.

There used to be a few other active developers who would contribute code. For a long time, I have become the sole maintainer again. As such, I contribute my limited time to implement things as best I can. It's open source. The code isn't that hard to understand. If there's some obscure tweak anyone wants, they are always free to implement it themselves.