[Ovmsdev] New web setup
Michael Balzer
dexter at expeedo.de
Mon May 14 02:09:43 HKT 2018
I also doubt it's related to the hardware version, and as the crash was consistent during the run and over two reboots I also don't think it's an interrupt
timing issue.
The crash occured on starting server v2 from the events task:
I (5287) webserver: CfgInitTicker: step 4: start server v2 for host 'ovms.***ERROR*** A stack overflow in task OVMS Events has been detected.
abort() was called at PC 0x4009045c on core 1
0x4009045c: vApplicationStackOverflowHook at /home/balzer/esp/esp-idf/components/esp32/panic.c:669
Backtrace: 0x4009026c:0x3ffbe030 0x40090443:0x3ffbe050 0x4009045c:0x3ffbe070 0x4008cd54:0x3ffbe090 0x4008e734:0x3ffbe0b0 0x4008e6ea:0x01010101
0x4009026c: invoke_abort at /home/balzer/esp/esp-idf/components/esp32/panic.c:669
0x40090443: abort at /home/balzer/esp/esp-idf/components/esp32/panic.c:669
0x4009045c: vApplicationStackOverflowHook at /home/balzer/esp/esp-idf/components/esp32/panic.c:669
0x4008cd54: vTaskSwitchContext at /home/balzer/esp/esp-idf/components/freertos/tasks.c:4840
0x4008e734: _frxt_dispatch at /home/balzer/esp/esp-idf/components/freertos/portasm.S:406
0x4008e6ea: _frxt_int_exit at /home/balzer/esp/esp-idf/components/freertos/portasm.S:206
Rebooting...
With 8K stack, the crash disappeared. Maybe we can reduce the stack usage of the server v2 start or move the start to another context, but I think we can afford
the extra 1K for the events task.
Regards,
Michael
Am 13.05.2018 um 19:21 schrieb Stephen Casner:
> It's hard to see how running on a 3.0 module would affect the stack
> usage unless some configuration difference caused an activity into the
> events task that would otherwise have been in a different task. If
> you're right on the hairy edge, perhaps the timing of an interrupt
> could be the difference between crash or not, but I think the
> interrupts switch to a separate stack. If there is some conditional
> activity that can be invoked either from a higher level function or
> from a lower level function, then timing of that condition might
> affect stack usage.
>
> -- Steve
>
> On Sun, 13 May 2018, Michael Balzer wrote:
>
>> I just did another setup run to also catch a firmware update screenshot.
>>
>> I got a stack overflow in the events task when starting the step 4 test (loading vehicle module and server v2). The crash persisted over reboot, so the setup
>> wizard reverted to factory defaults (good to know that works).
>>
>> This may be because I'm testing on a 3.0 module, but I've just pushed a stack change to 8K just to be sure.
>>
>> Regards,
>> Michael
>>
>>
>> Am 13.05.2018 um 17:54 schrieb Michael Balzer:
>>> Pushed.
>>>
>>> Strangely enough, during my tests I once had the same effect as you, but with the Cloudflare DNS.
>>>
>>> I couldn't reproduce it though.
>>>
>>> Please try again.
>>>
>>> I also captured screenshots of the process for the user guide -- is that necessary? I took care to add a lot of info to the process itself.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 13.05.2018 um 16:44 schrieb Michael Balzer:
>>>> With the Google/Cloudflare DNS you can finish the setup?
>>>>
>>>> I was hoping we could omit the DNS question now from the setup, as users likely don't know what that is.
>>>>
>>>> I'll add it to step 2 for now, but with a fixed & labeled selection.
>>>>
>>>>
>>>>
>>>> Am 13.05.2018 um 16:36 schrieb Michael Balzer:
>>>>> My boot without a fixed DNS looks like yours with a fixed one:
>>>>>
>>>>> I (5066) event: sta ip: 192.168.2.109, mask: 255.255.255.0, gw: 192.168.2.1
>>>>> I (5066) netmanager: Interface priority is st1 (192.168.2.109/255.255.255.0 gateway 192.168.2.1)
>>>>> I (5076) netmanager: Set DNS#0 192.168.2.1
>>>>> I (5076) netmanager: Set DNS#1 192.168.2.1
>>>>> I (5076) netmanager: Set DNS#2 0.0.0.0
>>>>> I (5076) netmanager: WIFI client up (with MODEM down): starting network with WIFI client
>>>>> I (5076) esp32wifi: STA got IP with SSID: WLAN-214677, MAC: 30:ae:a4:37:25:88, IP: 192.168.2.109, mask: 255.255.255.0, gw: 192.168.2.1
>>>>> I (5076) time: Starting SNTP client
>>>>> I (5076) ovms-server-v2: Status: Network is up, so attempt network connection
>>>>> I (6286) ovms-server-v2: Connection is ovms.dexters-web.de:6867 Test1
>>>>> I (6286) ovms-server-v2: Status: Connecting...
>>>>> I (6516) ovms-server-v2: Connection successful
>>>>> I (6516) ovms-server-v2: Status: Logging in...
>>>>>
>>>>>
>>>>> Is your DNS in the router or behind? The IP and masking looks like it's on another net. If it's on another net, is it possible the first query after the
>>>>> wifi connect is blocked or fails due to some firewall delay?
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 13.05.2018 um 16:07 schrieb Mark Webb-Johnson:
>>>>>> Definitely something timing related. Even with auto wifi.mode=client, the wifi client comes up on boot, but v2 server can't connect on first try (but
>>>>>> second try works).
>>>>>>
>>>>>> This is what I get:
>>>>>>
>>>>>> I (7316) event: sta ip: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64
>>>>>> I (7326) netmanager: Interface priority is st1 (10.10.41.203/255.255.248.0 gateway 10.10.40.64)
>>>>>> I (7326) netmanager: Set DNS#0 10.10.40.64
>>>>>> I (7326) netmanager: Set DNS#1 0.0.0.0
>>>>>> I (7326) netmanager: Set DNS#2 0.0.0.0
>>>>>> I (7326) netmanager: WIFI client up (with MODEM down): starting network with WIFI client
>>>>>> I (7326) esp32wifi: STA got IP with SSID: HIGHWAYS, MAC: 30:ae:a4:43:92:c4, IP: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64
>>>>>> I (7326) time: Starting SNTP client
>>>>>> I (7326) ovms-server-v2: Status: Network is up, so attempt network connection
>>>>>> I (7336) webserver: Launching Web Server
>>>>>> I (7376) ssh: Launching SSH Server
>>>>>> I (7386) ovms-server-v2: Status: Network is up, so attempt network connection
>>>>>> I (8396) ovms-server-v2: Connection is api.openvehicles.com:6867 <http://api.openvehicles.com:6867> DEVBENCH
>>>>>> I (8396) ovms-server-v2: Status: Connecting...
>>>>>> I (10396) housekeeping: System considered stable (RAM: 8b=94792-95652 32b=23608)
>>>>>> W (25696) ovms-server-v2: Connection failed
>>>>>> E (25696) ovms-server-v2: Status: Error: Connection failed
>>>>>> I (25696) ovms-server-v2: Status: Disconnected
>>>>>>
>>>>>>
>>>>>> But, if I config set network dns '8.8.8.8 1.1.1.1', I get:
>>>>>>
>>>>>> I (7087) event: sta ip: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64
>>>>>> I (7097) netmanager: Interface priority is st1 (10.10.41.203/255.255.248.0 gateway 10.10.40.64)
>>>>>> I (7097) netmanager: Set DNS#0 8.8.8.8
>>>>>> I (7097) netmanager: Set DNS#1 1.1.1.1
>>>>>> I (7107) netmanager: WIFI client up (with MODEM down): starting network with WIFI client
>>>>>> I (7107) esp32wifi: STA got IP with SSID: HIGHWAYS, MAC: 30:ae:a4:43:92:c4, IP: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64
>>>>>> I (7107) time: Starting SNTP client
>>>>>> I (7107) ovms-server-v2: Status: Network is up, so attempt network connection
>>>>>> I (7117) webserver: Launching Web Server
>>>>>> I (7137) ssh: Launching SSH Server
>>>>>> I (7157) ovms-server-v2: Status: Network is up, so attempt network connection
>>>>>> I (8387) ovms-server-v2: Connection is api.openvehicles.com:6867 <http://api.openvehicles.com:6867> DEVBENCH
>>>>>> I (8387) ovms-server-v2: Status: Connecting...
>>>>>> I (8617) ovms-server-v2: Connection successful
>>>>>> I (8617) ovms-server-v2: Status: Logging in...
>>>>>>
>>>>>>
>>>>>> I'm guessing this new 'stored dns' is the root of the problem, but really not sure what is going on. The delay is long enough to allow your test to timeout.
>>>>>>
>>>>>> Regards, Mark.
>>>>>>
>>>>>>> On 13 May 2018, at 2:18 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Am 12.05.2018 um 18:21 schrieb Mark Webb-Johnson:
>>>>>>>>> Did you apply the sdkconfig changes regarding SO_REUSE? I had none such problems after fixing that in my sdkconfig -- I also fixed the defaults in some
>>>>>>>>> commit a few days before.
>>>>>>>>>
>>>>>>>>> CONFIG_LWIP_SO_REUSE=y
>>>>>>>>> CONFIG_LWIP_SO_REUSE_RXTOALL=y
>>>>>>>> Just double-checked, and yes they are there.
>>>>>>>>
>>>>>>>> It seems that after connecting to SSID, the attempt to run 'Ota status' is immediate, but the wifi client hasn't settled down yet. I've looked in
>>>>>>>> web_cfg_init, but having trouble working out how it works. In the 'if (step == "2.test.connect")', it just seems to try to MyOTA.GetStatus as soon as the
>>>>>>>> ssid matches? But it doesn't check that the wifi client is actually up (the reception of IP address may be a second or two after the SSID is connected,
>>>>>>>> and anyway GetSSID() just returns the configured SSID, not the connected one). Or, maybe I'm missing something?
>>>>>>> The state ticker does not check yet if it can abort a scheduled timeout. So it doesn't do the test as soon as GetSSID() returns the network.
>>>>>>>
>>>>>>> The test is done fixed 20 seconds after StartAccessPointClientMode(). That is normally plenty of time for everything to settle. In my runs, the client
>>>>>>> network was normally fully functional in ~10 seconds.
>>>>>>>
>>>>>>> How long does your APClient switch take? You can try raising the 20 second timeout in line 226.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>>> Regards, Mark
>>>>>>>>
>>>>>>>>> On 12 May 2018, at 11:14 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 12.05.2018 um 15:42 schrieb Mark Webb-Johnson:
>>>>>>>>>> Works better, but still causing me issues. I had a couple of times where it took down the whole housekeeping task (with red alerts saying event
>>>>>>>>>> delivery queue was full so ticker.1 messages couldn't be delivered). I guess it is doing the wifi connectivity test in the main event task?
>>>>>>>>> Yes, the most time consuming task in there is the OTA.GetStatus() fetching the server version info. But I didn't get any problems from that in all my tests...
>>>>>>>>>
>>>>>>>>>> The other problem is that the bringing up/down of the APCLIENT vs AP mode doesn't seem to work properly, so I lose connection to the station. Also, my
>>>>>>>>>> iPad keeps switching back to home wifi, every time the OVMS reconfigures the network. APCLIENT mode really sucks.
>>>>>>>>> Did you apply the sdkconfig changes regarding SO_REUSE? I had none such problems after fixing that in my sdkconfig -- I also fixed the defaults in some
>>>>>>>>> commit a few days before.
>>>>>>>>>
>>>>>>>>> CONFIG_LWIP_SO_REUSE=y
>>>>>>>>> CONFIG_LWIP_SO_REUSE_RXTOALL=y
>>>>>>>>>
>>>>>>>>> If these are missing, both the webserver and ssh cannot rebind after the switch from AP to APCLIENT.
>>>>>>>>>
>>>>>>>>> The switching takes some seconds, but my tablets (all Androids) only switched back to my home network during tests with issues. The normal process is
>>>>>>>>> fast enough to keep them on the AP.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I'll have another look at the wifi driver. Maybe I can improve the API a bit (based on what we have). Perhaps configure a STAtion even in AP mode
>>>>>>>>>> (which is what I did with my alternative approach before).
>>>>>>>>>>
>>>>>>>>>> Regards, Mark.
>>>>>>>>>>
>>>>>>>>>>> On 12 May 2018, at 12:52 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Added another fix.
>>>>>>>>>>>
>>>>>>>>>>> Or more sort of a workaround: I just had an empty server status display on step 4 test after successful connect. I'm not sure how this can happen, I
>>>>>>>>>>> guess it's due to five events being processed at once after the connect (server v2 blocks the mongoose task there) and some race condition in the
>>>>>>>>>>> javascript code in that case.
>>>>>>>>>>>
>>>>>>>>>>> The three event based status displays now again also do periodic updates every 5 seconds, so if this happens, the status gets updated again after 5
>>>>>>>>>>> seconds.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Michael
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 11.05.2018 um 18:19 schrieb Michael Balzer:
>>>>>>>>>>>> OK. I really should wait for config.mounted before reading from MyConfig.
>>>>>>>>>>>>
>>>>>>>>>>>> Fix is pushed, please try.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am 11.05.2018 um 17:49 schrieb Mark Webb-Johnson:
>>>>>>>>>>>>> I tried a restart. Here is what I get:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Firmware: 3.1.005-72-g8cd4d07/ota_0/main
>>>>>>>>>>>>> Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1
>>>>>>>>>>>>>
>>>>>>>>>>>>> I (1465) webserver: Launching Web Server
>>>>>>>>>>>>> I (1465) ssh: Launching SSH Server
>>>>>>>>>>>>> I (4185) wifi: ap channel adjust o:1,1 n:6,2
>>>>>>>>>>>>> I (4185) wifi: n:6 0, o:1 0, ap:6 2, sta:6 0, prof:1
>>>>>>>>>>>>> I (4945) wifi: state: init -> auth (b0)
>>>>>>>>>>>>> I (4945) wifi: state: auth -> assoc (0)
>>>>>>>>>>>>> I (4955) wifi: state: assoc -> run (10)
>>>>>>>>>>>>> I (5055) wifi: connected with HIGHWAYS, channel 6
>>>>>>>>>>>>> I (5375) sdcard: SD CARD has been inserted
>>>>>>>>>>>>> I (5465) sdcard: mount done
>>>>>>>>>>>>> I (6025) wpa: PTK has been installed, it may be an attack, ignor it.
>>>>>>>>>>>>> I (6025) wpa: GTK has been installed, it may be an attack, ignor it.
>>>>>>>>>>>>> I (8515) wifi: n:6 0, o:6 0, ap:6 2, sta:6 0, prof:6
>>>>>>>>>>>>> I (8515) wifi: station: cc:44:63:89:b2:f4 join, AID=1, g, 20
>>>>>>>>>>>>> I (8525) esp32wifi: AP station connected: id: 1, MAC: cc:44:63:89:b2:f4
>>>>>>>>>>>>> I (9455) event: sta ip: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64
>>>>>>>>>>>>> I (9455) netmanager: Interface priority is st1 (10.10.41.203/255.255.248.0 gateway 10.10.40.64)
>>>>>>>>>>>>> I (9455) netmanager: Set DNS#0 10.10.40.64
>>>>>>>>>>>>> I (9455) netmanager: Set DNS#1 0.0.0.0
>>>>>>>>>>>>> I (9455) netmanager: Set DNS#2 0.0.0.0
>>>>>>>>>>>>> I (9455) netmanager: WIFI client up (with MODEM down): starting network with WIFI client
>>>>>>>>>>>>> I (9455) esp32wifi: STA got IP with SSID: HIGHWAYS, MAC: 30:ae:a4:43:92:c4, IP: 10.10.41.203, mask: 255.255.248.0, gw: 10.10.40.64
>>>>>>>>>>>>> I (9455) time: Starting SNTP client
>>>>>>>>>>>>> I (10375) housekeeping: System considered stable (RAM: 8b=106112-106940 32b=23608)
>>>>>>>>>>>>> I (13565) webserver: HTTP GET /
>>>>>>>>>>>>> I (13575) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (14825) webserver: HTTP GET /
>>>>>>>>>>>>> I (15135) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (15375) simcom: State timeout, transition to 13
>>>>>>>>>>>>> I (15375) simcom: State: Enter PoweredOff state
>>>>>>>>>>>>> I (15375) gsm-mux: Stop MUX
>>>>>>>>>>>>> I (16695) webserver: HTTP GET /
>>>>>>>>>>>>> I (16705) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (16735) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>> I (16905) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>> I (16905) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>> I (17345) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (28045) webserver: HTTP POST /cfg/init
>>>>>>>>>>>>> I (28045) webserver: HandleLogin: 'admin' logged in, sid 98faaa06ed8f1574
>>>>>>>>>>>>> I (28085) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (28085) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>> I (28085) webserver: HTTP GET /menu
>>>>>>>>>>>>> I (40025) webserver: HTTP GET /
>>>>>>>>>>>>> I (40035) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (40035) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>> I (40045) webserver: HTTP GET /
>>>>>>>>>>>>> I (40075) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>> I (40085) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>> I (40185) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>> I (40355) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (40355) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>> OVMS> enable
>>>>>>>>>>>>> Password:
>>>>>>>>>>>>> Secure mode
>>>>>>>>>>>>>
>>>>>>>>>>>>> I (50425) webserver: HTTP GET /
>>>>>>>>>>>>> I (50425) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (50425) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>> I (50465) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>> I (50475) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>> I (50555) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>> I (50675) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (50675) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>> OVMS# ota status
>>>>>>>>>>>>> Running partition: ota_0
>>>>>>>>>>>>> Boot partition: ota_0
>>>>>>>>>>>>> Firmware: 3.1.005-72-g8cd4d07/ota_0/main (build idf v3.1-dev-454-gdaef4b5c May 11 2018 20:00:05)
>>>>>>>>>>>>> Server Available: 3.1.005
>>>>>>>>>>>>>
>>>>>>>>>>>>> OTA release providing minor improvements and fixes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Vehicle: 12V battery monitoring
>>>>>>>>>>>>> vehicle [12v.alert] = 1.6 Voltage drop alert threshold in V vs. reference
>>>>>>>>>>>>> - OTA: automatic daily firmware updates (wifi only)
>>>>>>>>>>>>> auto [ota] = yes Enable/disable
>>>>>>>>>>>>> ota [auto.hour] = 2 Hour for daily check
>>>>>>>>>>>>> - Logging: persistent configuration, file cycling, web config UI:
>>>>>>>>>>>>> log [file.enable] = no Enable/disable file logging
>>>>>>>>>>>>> log [file.maxsize] = 1024 Max log file size in kB, 0 = no cycling
>>>>>>>>>>>>> log [file.path] = "" Log path, if on /sd watches sd.mounted
>>>>>>>>>>>>> log [level] Default level
>>>>>>>>>>>>> log [level.<tag>] Component levels
>>>>>>>>>>>>> - Reverse Engineering Tools enhancements
>>>>>>>>>>>>> - Tesla Roadster CAC support
>>>>>>>>>>>>> - Miscellaneous bug fixes and enhancements
>>>>>>>>>>>>>
>>>>>>>>>>>>> I (61705) webserver: HTTP GET /
>>>>>>>>>>>>> I (61715) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (61715) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>> I (61745) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>> I (61755) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>> I (61845) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>> I (61965) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (61965) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>> I (72035) webserver: HTTP GET /
>>>>>>>>>>>>> I (72045) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (72045) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>> I (72085) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>> I (72095) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>> I (72175) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>> I (73485) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>> I (73495) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>
>>>>>>>>>>>>> OVMS# config list auto
>>>>>>>>>>>>> auto (readable writeable)
>>>>>>>>>>>>> wifi.mode: apclient
>>>>>>>>>>>>> wifi.ssid.ap: DEVBENCH
>>>>>>>>>>>>> wifi.ssid.client: HIGHWAYS
>>>>>>>>>>>>>
>>>>>>>>>>>>> OVMS# config list module
>>>>>>>>>>>>> module (readable writeable)
>>>>>>>>>>>>> init: 2.test.connect
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards, Mark
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11 May 2018, at 10:42 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you have the earlier log, especially of the CfgInit ticker messages?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is the auto config correct and matching the "HIGHWAY" network?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please try a reboot. The ticker should take on step "2.test.connect" and proceed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 11.05.2018 um 16:28 schrieb Mark Webb-Johnson:
>>>>>>>>>>>>>>> Trying the new web setup, but not getting very far...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I (503580) webserver: HTTP GET /
>>>>>>>>>>>>>>> I (503590) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (503590) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (503610) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>>>> I (503610) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>>>> I (503730) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>>>> I (503880) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (503880) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (513960) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (513960) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (513960) webserver: HTTP GET /
>>>>>>>>>>>>>>> I (514000) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>>>> I (514000) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>>>> I (514090) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>>>> I (514220) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (514220) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (524280) webserver: HTTP GET /
>>>>>>>>>>>>>>> I (524290) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (524290) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (524320) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>>>> I (524340) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>>>> I (524420) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>>>> I (524590) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (524590) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (534620) webserver: HTTP GET /
>>>>>>>>>>>>>>> I (534630) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (534630) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (534660) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>>>> I (534660) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>>>> I (534760) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>>>> I (534890) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (534890) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (544940) webserver: HTTP GET /
>>>>>>>>>>>>>>> I (544950) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (544950) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (544980) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>>>> I (544990) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>>>> I (545080) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>>>> I (545250) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (545250) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OVMS# wifi status
>>>>>>>>>>>>>>> WiFi
>>>>>>>>>>>>>>> Power: on
>>>>>>>>>>>>>>> Mode: Access-Point + Client mode
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> STA SSID: HIGHWAYS
>>>>>>>>>>>>>>> MAC: 30:ae:a4:43:92:c4
>>>>>>>>>>>>>>> IP: 10.10.41.203/255.255.248.0
>>>>>>>>>>>>>>> GW: 10.10.40.64
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> AP SSID: DEVBENCH
>>>>>>>>>>>>>>> MAC: 30:ae:a4:43:92:c5
>>>>>>>>>>>>>>> IP: 192.168.4.1
>>>>>>>>>>>>>>> AP Stations: 1
>>>>>>>>>>>>>>> 1: MAC: cc:44:63:89:b2:f4, IP: 192.168.4.2
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OVMS# ota status
>>>>>>>>>>>>>>> Running partition: ota_0
>>>>>>>>>>>>>>> Boot partition: ota_0
>>>>>>>>>>>>>>> Firmware: 3.1.005-72-g8cd4d07/ota_0/main (build idf v3.1-dev-454-gdaef4b5c May 11 2018 20:00:05)
>>>>>>>>>>>>>>> Server Available: 3.1.005
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I (1141850) webserver: HTTP GET /
>>>>>>>>>>>>>>> I (1141860) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (1141860) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>> I (1141890) webserver: HTTP GET /apple-touch-icon.png
>>>>>>>>>>>>>>> I (1141890) webserver: HTTP GET /assets/style.css
>>>>>>>>>>>>>>> I (1141990) webserver: HTTP GET /assets/script.js
>>>>>>>>>>>>>>> I (1142120) webserver: HTTP GET /cfg/init
>>>>>>>>>>>>>>> I (1142120) webserver: CfgInit enter 2.test.connect
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can't get out of that 2.test.connect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any ideas?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards, Mark.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> 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
More information about the OvmsDev
mailing list