[Ovmsdev] Setup wizard

Tue May 8 08:22:39 HKT 2018

> If the wifi rework turns up new esp-idf bugs, given the deadline I think we should not include it in the production firmware yet.

It did.

The Espressif documentation shows the flow as (a) init, (b) config, (c) start the wifi. They don’t talk about changing the config after start, at all.

For Station side, I find I can (a) disconnect, (b) re-config, and (c) connect just fine. It works 100% of the time for me. I can also do scans while in connected state (as well as in blank empty client config disconnected state). I think this works so well because we have that connect/disconnect method. If an Access Point is needed, there is no point in using plain AP mode - APSTA seemingly has no drawbacks but has plenty of advantages (such as being able to do scans, and start/stop station connections, even while the access point it up).

But for the Access Point side, there is no connect/disconnect method. The access point is started automatically when the wifi is started, and stopped when the wifi is stopped. Stopping the wifi disconnects the client side (which is undesirable). I find that with an access point running, I can simply re-config it and the wifi stack correctly stops and starts the access point - but it does it in a really messy way (seemingly indicating that this is a side-effect not a deliberate support). Worse, if I bring up wifi in APSTA mode, with a blank access point config, it starts a access point with a blank SSID. Dynamically changing between STA and APSTA mode seemed promising, but it is now randomly crashing for me.

Bottom line is that I need more time to get this right. To work out how best to work-around the idiosyncrasies of the Espressif wifi stack.

Deadline is approaching, so I’ll stash my changes for the moment, and come back to them later when we have more time. We’ll go with the current wifi driver for the 3.1.006 firmware release to factory.

Regards, Mark.

> On 6 May 2018, at 11:11 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> One of "my" testers managed to find a major bug in the wizard, allowing to enter an empty wifi client password, which would lead to a reboot loop. Luckily the user can use a USB terminal.
> 
> Fix is pushed, along with some optimizations and other minor fixes.
> 
> Mark, the wizard currently works with the old wifi implementation.
> 
> If the wifi rework turns up new esp-idf bugs, given the deadline I think we should not include it in the production firmware yet.
> 
> Regards,
> Michael
> 
> 
> Am 06.05.2018 um 16:48 schrieb Mark Webb-Johnson:
>> I think I need at least another 24 to 48 hours for this. Just getting too many edge cases and esp wifi library weird stuff going on. It seems that sometimes we can change the mode easily, but other times not.
>> 
>> Regards, Mark.
>> 
>>> On 6 May 2018, at 11:45 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>> 
>>> 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:
>>> Asia-Pacific (openvehicles.com <http://openvehicles.com/>)
>>> Europe (dexters-web.de <http://dexters-web.de/>)
>>> 
>>> Step 4 (Vehicle and Server): I suggest the labels:
>>> No server connection
>>> Asia-Pacific (api.openvehicles.com <http://api.openvehicles.com/>)
>>> 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:
>>> 
>>> 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.
>>> We can turn on/off a STA connection, without affecting the AP at all.
>>> We can turn on/off the AP, without affecting the STA connection at all.
>>> The STA code is much more symmetric, and scanning handled better.
>>> 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:
>>>> Secure module access (configure wifi AP and module password)
>>>> Connect module to internet (switch to Wifi APCLIENT mode)
>>>> Update to latest firmware version
>>>> Configure vehicle type and server
>>>> 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 <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> 
> -- 
> 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
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180508/4a9d5642/attachment.htm>