Wiki pages for use cases, user task testing, automated testing

[fhteagle]

Split from #401

Need to write three separate Wiki pages at descending levels of abstraction would be useful:

• List of use cases, scenarios, stories that are supported and stable, are in work, are planned for future dev, and are out of scope for OpenEVSE project, with links to relevant issues
• Control task list, items that we should be able to accomplish via GUI, button, HTTP API, maybe a table showing what tasks can be accomplished by what kind of control, therefore can be a checklist for items to manually end-to-end test
• Automated tests info, guide, how to report failures, etc.

[jeremypoulter]

Done, I need to figure out how I can give people access. @chris1howell do I have admin access on this repo? I thought I did but many settings are missing

[jeremypoulter]

@fhteagle in the short term we can do something like this

[chris1howell]

Jeremy, I have added you as an Admin. Your permissions were Maintain.

…

On Sat, Nov 5, 2022 at 3:13 PM Jeremy Poulter ***@***.***> wrote: @fhteagle <https://github.com/fhteagle> in the short term we can do something like this <https://stackoverflow.com/questions/10642928/how-can-i-make-a-pull-request-for-a-wiki-page-on-github/11481887#11481887> — Reply to this email directly, view it on GitHub <#461 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN5QH2JEFMIDR3MUNIVMQTWG2WV3ANCNFSM6AAAAAARRDA5WE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[fhteagle]

Circling back to this after having tried out integrating HomeAssistant with OpenEVSE. I would like to get some feedback from developers and users as to:

1. Whether some use cases should be "in scope" for OpenEVSE, but other use cases referred to third party integrations such as emonCMS, HomeAssistant, OCPP, etc.
2. If yes to 1, then where should the line be drawn between OpenEVSE functionality, automations, smarts, etc vs what should be moved to a recipe of third party integration instead.

At this point, I am leaning towards the following breakdown:

a. All safety related issues need to be solidly within the OpenEVSE and its native GUI
b. All basic functions and single-step use cases in OpenEVSE (i.e. RFID card presented, enable charging for 8 hours)
c. Any "multi-step" automation (i.e. charge the car to a minimum of 20% right away, then resume charging only from local PV production) should probably be handled by third party integration logic.

Thoughts?