[Ovmsdev] Initial OTA update

[Michael Balzer]

Greg,

Am 16.04.2018 um 19:19 schrieb Greg D.:
> So, I'm trying to play "customer" with the 3.1 module, and have confirmed :) the issue with killing off WiFi by enabling client + AP mode.  Tried to recover
> by using the USB console and issuing a module factory reset command, but that didn't enable wifi because the ssid passkey wasn't set up.  Fixed that (again,
> usb console) and got back to what I think was "factory" state. 
>
> Also got stuck trying to navigate an OTA update.  Can't connect to the Internet with an AP-only WiFi config.  Trying to configure AP+Client killed things off,
> so a bit gun-shy there.  If I play customer without a means to play with an SD card, I can't apparently do the update.

OTA updates are possible in AP mode via modem or from your station. I'm running a web server on my PC so can download the firmware from 192.168.4.2 in AP mode.

> The key to both of these is to actively configure a client wifi network before messing around with practically anything else, but that's not obvious in the
> normal workflow of setting up the module.  Can we clarify that in either the documentation, or (preferably) in the Webserver UI?  I think the key here is that
> configuring AP+Client needs to /first/ have the Client config set, because one never has a wide-open WiFi network at home (for scan "any" to work).

Please test my commits on the wifi config & init issues. Tell me if you still see a chance for a faulty config with the current build.

The config menu was loosely meant to be done top down / left to right. The autostart page will now check the wifi setup, but the recommended way still is to
configure Wifi first.

> Topic #2, once I did get the module on the home network and hit the OTA Flash button, it seemed to never complete (looking just at the web page).  As a
> developer, I had a USB console running on the side, and saw the reason was a continuous stream of queue overflow messages.  Rebooted (ignoring the warning not
> to do so) the module and tried again; same result, though apparently the updates actually did work (it shows I'm on version 3.1.003).  Rebooting the module
> stopped the queue overflows, i.e. they weren't associated with normal operation.  Is something not getting cleaned up after the OTA process completes?

I have seen the queue overflow problem once on the current build, so it isn't solved. But it wasn't related to any action, it happened while the module was idle.

To clarify, it's no problem if it resolves after some seconds, that may be due to a temporary mongoose lock / overload. If we can trigger that reliably by some
action, that would help to track this down.

I'll add a detection for "stuck in queue overflow" and try to resolve that by closing the websocket connection. Not sure if that will be sufficient though, it
may be some deeper mongoose issue.

Regards,
Michael


> Greg
>
>
>
>
>
> _______________________________________________
> 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/20180416/edef6015/attachment.htm>