[Ovmsdev] Setup wizard

[Michael Balzer]

Mark,

radio labels are changed.

Your wifi rework will make the process much more streamlined, I think we can then completely avoid the long reconnect phase on step 2, and of course offer a
selection of wifi networks from a scan.

Btw, I've seen a WPS API, do you think we can use that?

Don't invest too much time in backwards compatibility, the web UI can be changed easily to support separate control of AP/STA modes.

Regards,
Michael


Am 06.05.2018 um 05:45 schrieb Mark Webb-Johnson:
> Michael,
>
> Really good. I had a quick run-through, and it seems to work. I have some factory modules here that I can try this with.
>
> A couple of minor suggestions:
>
>   * Step 3 (Update Firmware): I suggest the labels:
>       o Asia-Pacific (openvehicles.com <http://openvehicles.com>)
>       o Europe (dexters-web.de <http://dexters-web.de>)
>
>   * Step 4 (Vehicle and Server): I suggest the labels:
>       o No server connection
>       o Asia-Pacific (api.openvehicles.com <http://api.openvehicles.com>)
>       o Europe (dexters-web.com <http://dexters-web.com>)
>
>
> The only thing that worries me is the Wifi. I spent this week looking through the code I wrote months ago, and given what I know now, it is really not
> optimal. In particular, the way it works (with one primary mode) does not now seem correct (given what we know about the wifi stack now). I have now re-worked
> the wifi driver to work as follows:
>
>   * The wifi stack is powered up in ESP32 WIFI_MODE_APSTA. That allows us to have a STA, an AP, both, or neither.
>   * The STA settings are set completely independently of AP settings. So, a STA mode is set (off, scan-only, promiscuous (scanning-client), SSID, or SSID+BSSID).
>   * The AP settings are set completely independently of STA settings. So, an AP mode is set (off, or SSID).
>   * We now track the different modes and statuses, independently.
>
>
> This gives us a number of advantages:
>
>  1. We can do a SCAN even when an STA or AP connection is up. This causes about 2 to 3 seconds of loss of connectivity, but doesn’t seem to kick anyone off.
>  2. We can turn on/off a STA connection, without affecting the AP at all.
>  3. We can turn on/off the AP, without affecting the STA connection at all.
>  4. The STA code is much more symmetric, and scanning handled better.
>  5. We can (in theory) have a scanning STA promiscuous client, combined with an active AP. I’m not 100% sure of the practicality of this (as I think the scan
>     will affect the AP while it is ongoing), but it should be possible to some extent.
>
>
> The new code (and modes) is working for me, along with some new commands (wifi client, wifi accesspoint). I am now trying to convert the old commands to
> retain backwards compatibility (but I would like to deprecate those, long-term). The ‘auto’ system also needs conversion (but again, I’m trying to make it
> backwards compatible).
>
> I should be able to get to a level where I can commit (and push) today, for you to have a look at.
>
> Regards, Mark.
>
>> On 6 May 2018, at 2:57 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> I have just pushed the first version of a setup wizard.
>>
>> It currently consists of five steps:
>>
>>  1. Secure module access (configure wifi AP and module password)
>>  2. Connect module to internet (switch to Wifi APCLIENT mode)
>>  3. Update to latest firmware version
>>  4. Configure vehicle type and server
>>  5. Configure modem (if equipped)
>>
>> I tried hard to avoid any dead ends and simplify the process as much as possible, but need your help to test if I really handled all potential screw-ups.
>>
>> I developed and tested the whole process on my 3.0 hardware module, so if you've got an unused 3.0 module you can use that for the test without destroying
>> your car configuration.
>>
>> The wizard state is kept in config module / init, with states "1" … "5" = steps above + sub steps suffixed, and "done" being the final state. There is
>> currently no "back" option, but you can simply set the config variable.
>>
>> You can start at any point, regardless of the configuration already existing. The wizard will also not change configuration options it doesn't need to touch,
>> so you can run it also on an already configured module. But it's really meant to be a first init wizard, and thus won't be a standard menu option.
>>
>> It only shows if module/init is not "done". If you try the new version on an existing module, you won't see the wizard until you do:
>>
>>   * config set module init ""
>>
>> …that's because the previous "password/changed" variable is migrated to "module/init=done".
>>
>> The wizard is offered on the home screen if init is empty. It automatically loads after login and from the home screen when started, but it does not block
>> the UI. You can use all UI pages normally, to return to the wizard, simply click the home icon.
>>
>> Logging is currently maybe a bit excessive, especially as it's on the info level. That is to be able to get some debug info also from modules in default
>> configuration.
>>
>> Regards,
>> Michael
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180506/86a8fa7b/attachment.htm>