<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
Fix is pushed, along with some optimizations and other minor fixes.<br>
<br>
Mark, the wizard currently works with the old wifi implementation.<br>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 06.05.2018 um 16:48 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:E6C7D767-00DE-4055-B3F2-B5D1BC0BECBE@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
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.
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 6 May 2018, at 11:45 AM, Mark
Webb-Johnson <<a href="mailto:mark@webb-johnson.net"
class="" moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;"
class="">Michael,
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">A couple of minor suggestions:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Step 3 (Update Firmware): I suggest
the labels:</li>
<ul class="">
<li class="">Asia-Pacific (<a
href="http://openvehicles.com/" class=""
moz-do-not-send="true">openvehicles.com</a>)</li>
<li class="">Europe (<a
href="http://dexters-web.de/" class=""
moz-do-not-send="true">dexters-web.de</a>)<br
class="">
<br class="">
</li>
</ul>
<li class="">Step 4 (Vehicle and Server): I
suggest the labels:</li>
<ul class="">
<li class="">No server connection</li>
<li class="">Asia-Pacific (<a
href="http://api.openvehicles.com/" class=""
moz-do-not-send="true">api.openvehicles.com</a>)</li>
<li class="">Europe (<a
href="http://dexters-web.com/" class=""
moz-do-not-send="true">dexters-web.com</a>)</li>
</ul>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">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:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">The wifi stack is powered up in ESP32
WIFI_MODE_APSTA. That allows us to have a STA,
an AP, both, or neither.</li>
<li class="">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).</li>
<li class="">The AP settings are set completely
independently of STA settings. So, an AP mode is
set (off, or SSID).</li>
<li class="">We now track the different modes and
statuses, independently.</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">This gives us a number of advantages:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">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.</li>
<li class="">We can turn on/off a STA connection,
without affecting the AP at all.</li>
<li class="">We can turn on/off the AP, without
affecting the STA connection at all.</li>
<li class="">The STA code is much more symmetric,
and scanning handled better.</li>
<li class="">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.</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class="">I should be able to get to a level where
I can commit (and push) today, for you to have a
look at.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 6 May 2018, at 2:57 AM, Michael
Balzer <<a href="mailto:dexter@expeedo.de"
class="" moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
I have just pushed the first version of a
setup wizard.<br class="">
<br class="">
It currently consists of five steps:<br
class="">
<ol class="">
<li class="">Secure module access
(configure wifi AP and module password)<br
class="">
</li>
<li class="">Connect module to internet
(switch to Wifi APCLIENT mode)</li>
<li class="">Update to latest firmware
version</li>
<li class="">Configure vehicle type and
server</li>
<li class="">Configure modem (if equipped)</li>
</ol>
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.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
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:<br class="">
<ul class="">
<li class=""><tt class="">config set
module init ""</tt><br class="">
</li>
</ul>
…that's because the previous
"password/changed" variable is migrated to
"module/init=done".<br class="">
<br class="">
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.<br
class="">
<br class="">
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.<br
class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a
href="mailto:OvmsDev@lists.openvehicles.com"
class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
class="" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>