July 2020 - OvmsDev - Open Vehicles

Debugging the task watchdog triggers
by Michael Balzer 18 Jul '20

18 Jul '20

Everyone, the remaining crashes I have seen in quite a while were all due to the task watchdog triggering. I have now added capturing the names of the tasks that failed feeding the dog and capturing the event that was processed at the time of the crash/wdt to the RTC boot data. If set, it's shown by the "boot" command and transmitted to a v2 server via the "*-OVM-DebugCrash" records. Example: OVMS# boot status Last boot was 10 second(s) ago Time at boot: 2020-07-18 11:53:07 CEST This is reset #1 since last power cycle Detected boot reason: Crash (12/12) Reset reason: *Task watchdog* (6) Crash counters: 1 total, 0 early Last crash: abort() was called on core 0 Backtrace: 0x4008e627 0x4008e8c1 0x400e6100 0x40083f6a * Event: ticker.1@module 64 secs** ** WDT tasks: OVMS Events* Version: 3.2.013-303-gfc79b92f/factory/edge (build idf v3.3.2-879-g0137aef47 Jul 18 2020 11:29:45) This was a test trigger by "module trigger twdt". DebugCrash record structure is now: // H type "*-OVM-DebugCrash" // ,<firmware_version> // ,<bootcount>,<bootreason_name>,<bootreason_cpu0>,<bootreason_cpu1> // ,<crashcnt>,<earlycrashcnt>,<crashtype>,<crashcore>,<registers>,<backtrace> // ,<resetreason>,<resetreason_name> // ,<curr_event_name>,<curr_event_handler>,<curr_event_runtime> // ,<wdt_tasknames> Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

PSRAM fix in esp-idf release v3.3
by Michael Balzer 17 Jul '20

17 Jul '20

Mark, it seems the fix has finally arrived in the official release 3.3 branch: https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913 https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4b… Btw: > In the v3 silicon, the issue has been fixed, and the workaround is no > longer required. > I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

4 8

debugging CAN bus error flags
by Derek Caudwell 16 Jul '20

16 Jul '20

On my Nissan Leaf I am getting the following error irqs repeating on CAN bus 2. The error flags appear to be set in esp32can.cpp but I could use some pointers on how to interpret their meaning and hence how to handle the interrupts (assuming they are not real errors): 1970-01-01 13:01:41 NZDT E (89501) can: can2: intr=93510 rxpkt=127559 txpkt=14 errflags=0x23000001 rxerr=0 txerr=0 rxovr=0 txovr=0 txdelay=0 wdgreset=0 errreset=0 1970-01-01 13:01:41 NZDT E (89511) can: can2: intr=93511 rxpkt=127564 txpkt=14 errflags=0x23400401 rxerr=0 txerr=0 rxovr=0 txovr=0 txdelay=0 wdgreset=0 errreset=0 1970-01-01 13:01:41 NZDT E (89531) can: can2: intr=93525 rxpkt=127592 txpkt=14 errflags=0x22400402 rxerr=0 txerr=0 rxovr=0 txovr=0 txdelay=0 wdgreset=0 errreset=0

2 1

Would like to update Dev-Docs
by Soko 15 Jul '20

15 Jul '20

Hey guys, I was able to get everything working and compiling as "portable" installation of ESP-IDF, Visual Studio Code, Git, etc. on Windows. I would like to share it so the next guy doesn't have to go through all the hassle :) I think the best place would be updating https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWE… Can someone grant me access to it? Or should I put it somewhere else? Soko

2 2

Unusual simcom hang
by Craig Leres 15 Jul '20

15 Jul '20

My simcom lost its connection between two stops this morning. I happened to check the app when leaving the second stop and it showed the car a few blocks from the first stop. Now that it's back on my home wifi I can see the gps is happy (locked on 10 sats) and the simcom has signal but is in DeniedRegistration state... Looking at https://status.hologram.io/ I see they had an outage today. Ah, checking my other module I see it also says DeniedRegistration. So more accurately: they are *having* an outage today. Craig

2 2

Re: [Ovmsdev] Plugin Repository
by Derek Caudwell 15 Jul '20

15 Jul '20

I had to have a few attempts to get he existing plugins working, so a simple repo and install system would be great. May be worth considering the following features from the Kodi addon repo system: - in the root folder there is a consistent name for initial script eg plugin.js - lib folder for including other scripts (could have web folder for html elements) - plugin folder tar/zipped for easy delivery and install https://kodi.wiki/view/Add-on_structure Cheers Derek Date: Tue, 14 Jul 2020 13:45:55 +0200 > From: Michael Balzer <dexter(a)expeedo.de> > To: ovmsdev(a)lists.openvehicles.com > Subject: Re: [Ovmsdev] Plugin Repository > Message-ID: <40cce917-3366-a6e5-1189-a28dc89578d3(a)expeedo.de> > Content-Type: text/plain; charset="utf-8" > > Mark, > > full ack, has been on my list as well. I'll handle the web UI side. > > I don't think we need to migrate/change the folder structure, we should > be able to just add the meta data. I tried to define the structure to be > usable as a public repository. Did I miss something? > > Btw, I used the naming "module" plugins instead of "script" plugins, as > web plugins also consist mostly of scripts. I thought that would clear > things for users, but I'm not sure now. > > Regarding the plugin structure and meta data, we should decide wether to > split plugins into their elements or keep them bundled. You seem to opt > for bundles ("web subdirectory"). I would second that, but we then need > to take into account a plugin may consist of multiple module and/or web > plugins (see Edimax plugin for an example). Normally it's just one > module plugin, but we should not restrict the system in that way. So the > JSON file should allow to define an array of plugin elements / options. > > Currently there's a version on each element, and but we could/should > simplify this to a central overall version for the plugin. > > To automatically install plugins, the meta data also needs to define the > types and default setups for web/frontend plugins. > > Draft: edimax.json: > > { > ? name: "edimax", > ? title: "Edimax: Smart Plug Control", > ? description: "Smart Plug control for Edimax models SP-1101W, SP-2101W > et al", > ? group: "Home Automation", > ? info: "https://docs.openvehicles.com/en/latest/plugin/edimax/README.html > ", > ? maintainer: "Michael Balzer <dexter(a)dexters-web.de>", > ? version: "2.1", > ? prerequisites: ["ovms>=3.2.010"], > ? elements: [{ > ??? type: "script", > ??? path: "edimax.js", > ??? name: "edimax" // optional, defaults to plugin name > ? },{ > ??? type: "webpage", > ??? path: "edimax.htm", > ??? page: "/usr/edimax", > ??? label: "Edimax Smart Plug", > ??? menu: "Config", > ??? auth: "Cookie" > ? },{ > ??? type: "webhook", > ??? path: "edimax-status.htm", > ??? page: "/status", > ??? hook: "body.post" > ? }] > } > > A method to easily disable/enable installed plugins would also be nice, > i.e. as subcommands "plugin disable" / "plugin enable". > > Regards, > Michael > > > Am 14.07.20 um 07:55 schrieb Mark Webb-Johnson: > > > > I feel that our plugin system offers a missed opportunity. By making > > small extensions to available functionality, we can use this system to > > do so much - and with a much lower complexity and barrier to entry > > compared to C++ ESP IDF development. > > > > There are a couple of things I would like to now do: > > > > 1. Implement a mechanism for plugins to directly extend the console > > command language (other than the current ?script exec PLUGIN.fn?). > > > > 2. Implement a plugin repository, and command line tools for managing > > plugins. We simply need to have a store and directory of available > > plugins, a way of searching/listing those, and a uniform way to > > install/remove plugins. Once this is done, perhaps someone can > > handle the web UI side of this, and perhaps that can even be done > > as a plugin :-) > > > > > > I?m already working on #1. Just an extension to the existing script > > system to allow plugins to register commands, and to have the command > > register/deregister done automatically on plugin load/unload. > > > > However, #2 is a little more tricky and I?m looking for feedback on > > the design of this. My idea is: > > > > * Store the plugins in a new > > github/openvehicles/Open-Vehicle-Monitoring-System-3/plugins > > folder. Eventually the /plugin folder will all be migrated to here. > > > > * Each plugin has a unique name; the directory in /plugins. > > > > * Within each plugin directory, there is a <name>.json file (JSON > > format) with defined tags to describe the plugin. If the plugin > > delivers a web extension, that is in the ?web? subdirectory. If > > the plugin delivered a script extension, that is in the ?script? > > directory. Documentation (in rst format) is in the ?docs' > > directory. The JSON file would need the following, at a minimum: > > > > o Name: The plugin ID > > o Title: One line title > > o Group: Group for the plugin > > o Version: The version string of the plugin > > o Description: Longer textual description of the plugin > > o Prerequisites: Prerequisites to be checked > > (Each plugin installed provides name=version, the system > > provides system-level ones such as the version of firmware, > > and then the prerequisites is simple a list of > > <name><operator><version> as required) > > > > * We can automatically build the documentation, and list, for all > > plugins for our docs.openvehicles.com > > <http://docs.openvehicles.com>?(in a similar way to how it is done > > for /plugin now). > > > > * On a repository server, as part of a nightly build job, we can > > automatically build a single directory JSON file from the > > <name>,json descriptors. We can publish this, as well as a git > > export/checkout of the plugins, on a http download site. > > > > * On the module, we can store a list of repository servers (allowing > > the user to add/remove as they require). > > > > * Contributors/authors of plugins simply GitHub clone our > > repository, and issue pull requests as appropriate. They can also > > have their own private repository servers (just need to host the > > directory json file and associated code files) and add it to their > > modules. > > > > * The ?plugin? command tree on the module will provide commands for: > > > > o List installed repositories > > o Add a new repository > > o Remove a repository > > o List installed plugins > > o List/Search available plugins > > o Install a plugin > > o Remove a plugin > > o Update a plugin > > > > * I would like to try to unify the web and script plugin systems a > > bit more closely. They are really two sides of the same coin (with > > some plugins providing both). > > > > > > Does that make sense? Any suggestions/comments? > > > > Regards, Mark. > > > > > > _______________________________________________ > > OvmsDev mailing list > > OvmsDev(a)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 > >

1 0

Att: esp-idf update necessary
by Michael Balzer 15 Jul '20

15 Jul '20

Everyone, I've added event and watchdog debug info to our crash records. This needed a change to the esp-idf, so please update. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Hologram outage
by Mark Webb-Johnson 14 Jul '20

14 Jul '20

Craig has let me know of an outage at Hologram. https://status.hologram.io <https://status.hologram.io/> Investigating - We are investigating possible issues connecting to the cellular network for some customers. Jul 12, 18:27 UTC Identified - An issue has been identified with a cellular gateway provider affecting all network connectivity routed out of their global point of presence. Hologram has escalated the issue and is actively monitoring for service recovery. We will further update here. Hologram customers using Indigo SIM connectivity are unaffected. Jul 12, 18:47 UTC Update - Hologram Engineering and Customer Success are monitoring 2G/3G connection/authentication delays due to an increase in reconnection load on those radio access technologies (RATs). Our affected global gateway partner is continuing work to increase signaling capacity for 2G/3G connection/authentication. Jul 13, 22:21 UTC I haven’t had any customer reports of this (other than Craig’s), but be aware of the issue. Regards, Mark.

1 0

K-Line and TPMS
by Mark Webb-Johnson 13 Jul '20

13 Jul '20

The K-Line boards are done. Will be available on Fasttech within a day or two. Should also be available in EU and US within a week or two. For the Tesla Roadster, our full write-up of the Baolong TPMS system is here: http://api.openvehicles.com/downloads/TeslaRoadster2_TPMS_Baolong_Engineeri… <http://api.openvehicles.com/downloads/TeslaRoadster2_TPMS_Baolong_Engineeri…> A lot of people put in a lot of work to get this done. I would like to, in particular, single out: Christian for the loan of a TPMS tool Scott for his comprehensive work on LIN bus decoding Peter for advise and pictures of the ECU unit Shawn for his work on the K-line bus decoding Charles for arranging loan of ECU and Antennas Brent for loan of ECU and Antennas Mark for integration to OVMS and adding the K-line option Regards, Mark.

1 0

Re: [Ovmsdev] Wifi setup
by Derek Caudwell 12 Jul '20

12 Jul '20

Thanks for the fix! Switching between my APs (all unique ssids, so not tested bssid) works on loss of signal or reboot as expected with the exception that on one running OpenWrt as an extender, so goes back to main router for Dhcp, it is not getting an IP after the switch/gw/dns. I will enable verbose logging later and see if provides more detail on what is happening. Reboot of OpenWrt device is probably a good starting point. > Date: Sat, 11 Jul 2020 00:15:18 +0300 > From: Jaunius Kapkan <jaunius(a)gmx.com> > To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> > Subject: Re: [Ovmsdev] Wifi setup > Message-ID: <75886DAD-F082-4EFC-9509-2A565B1C9121(a)gmx.com> > Content-Type: text/plain; charset="utf-8" > > Really appreciate you guys taking the time to fix this. I also use the > module in wifi only mode and was constantly getting disconnects. I blamed > this on the poor wifi connection in the parking spot, but as it turns out > the problem was far deeper. > > Regards, > Jaunius Kapkan [Sent from cellphone] > > > On 2020-07-10, at 23:42, Michael Balzer <dexter(a)expeedo.de> wrote: > > > > ? *sigh* Found it? it turned out my main router needed a reboot. I > assume somehow a faulty ARP cache entry got stuck. > > > > https://www.youtube.com/watch?v=nn2FB1P_Mn8 > > > > So, no fault or bug on the module side. > > > > Checking the code once again I nevertheless found one remaining > potential bug, fix is pushed. > > > > Regards, > > Michael > > > > > > Am 10.07.20 um 20:53 schrieb Michael Balzer: > >> Sorry for not including the examples. The Edimax does not have a host > name, it's addressed using the IP, no DNS involved. > >> > >> Linux host request example working the same way with both the old & new > version: > >> > >> HTTP.Request({ > >> url: "http://192.168.2.108/f/test.json", > >> always: function() { JSON.print(this, false); } > >> }); > >> > >> (OK, no output) > >> D (42703) script: DuktapeHTTPRequest: started ' > http://192.168.2.108/f/test.json' > >> D (42913) script: DuktapeHTTPRequest: MG_EV_CONNECT err=0/Success > >> D (42933) script: DuktapeHTTPRequest: MG_EV_HTTP_REPLY status=200 > bodylen=20 > >> D (42943) script: DuktapeHTTPRequest: MG_EV_CLOSE status=200 > >> D (42963) script: DuktapeHTTPRequest: done status=200 bodylen=20 url=' > http://192.168.2.108/f/test.json' > >> D (42973) script: DuktapeHTTPRequest: calling method 'always' nargs=0 > >> I (43173) script: [eval:3:] {"url":"http://192.168.2.108/f/test.json","always":function > () { [ecmascript code] > },"redirectCount":0,"error":"","response":{"statusCode":200,"statusText":"OK","body":"{ > \"das\": \"klappt?\" }","headers":[{"Date":"Fri, 10 Jul 2020 17:03:18 > GMT"},{"Server":"Apache"},{"Last-Modified":"Sun, 29 Dec 2019 11:01:41 > GMT"},{"ETag":"\"14-59ad5a6d190da\""},{"Accept-Ranges":"bytes"},{"Content-Length":"20"},{"Cache-Control":"max-age=0"},{"Expires":"Fri, > 10 Jul 2020 17:03:18 GMT"},{"Content-Type":"application/json"}]}} > >> > >> ?vs. Edimax working with the old version: > >> > >> HTTP.Request({ > >> url: "http://192.168.2.106/", > >> always: function() { JSON.print(this, false); } > >> }); > >> > >> (OK, no output) > >> D (533720) script: DuktapeHTTPRequest: started 'http://192.168.2.106/' > >> D (533920) script: DuktapeHTTPRequest: MG_EV_CONNECT err=104/Connection > reset by peer > >> D (533930) script: DuktapeHTTPRequest: MG_EV_CLOSE status=0 > >> D (533950) script: DuktapeHTTPRequest: failed error='Connection reset > by peer' url='http://192.168.2.106/' > >> D (533950) script: DuktapeHTTPRequest: calling method 'always' nargs=0 > >> I (533990) script: [eval:3:] {"url":"http://192.168.2.106/","always":function > () { [ecmascript code] },"redirectCount":0,"error":"Connection reset by > peer"} > >> > >> (connection reset = expected result here, as connecting w/o credentials > to the default port -- to show it's host related) > >> > >> ?but not with the new version: > >> > >> (OK, no output) > >> D (151953) script: DuktapeHTTPRequest: started 'http://192.168.2.106/' > >> ?18 seconds? > >> D (170273) script: DuktapeHTTPRequest: MG_EV_CONNECT err=113/Software > caused connection abort > >> D (170273) script: DuktapeHTTPRequest: MG_EV_CLOSE status=0 > >> D (170293) script: DuktapeHTTPRequest: failed error='Software caused > connection abort' url='http://192.168.2.106/' > >> D (170303) script: DuktapeHTTPRequest: calling method 'always' nargs=0 > >> I (170333) script: [eval:3:] {"url":"http://192.168.2.106/","always":function > () { [ecmascript code] },"redirectCount":0,"error":"Software caused > connection abort"} > >> > >> > >> Regards, > >> Michael > >> > >> > >> Am 10.07.20 um 20:03 schrieb David Corrigan: > >>> Sounds like a DNS issue. I?m really foggy on the details but you can > probably look this stuff up easily enough. Local stuff is resolved a bit > differently, it?s something like your home router keeps track of the names > that get DHCP reservations and append .local so somehow when looking for > devices the client needs to query that as well as the main DNS IPs given to > it by the DHCP server. It might be that the same DHCP server automatically > appends it?s own up IP to the list. There?s a discussion on it here that > might yield some ideas > >>> > >>> > https://superuser.com/questions/591863/how-to-resolve-local-domain-name > >>> > >>> > >>> On Fri, Jul 10, 2020 at 12:47 PM Michael Balzer <dexter(a)expeedo.de> > wrote: > >>>> It seems I've found a real issue with the new implementation, I don't > know how to explain: > >>>> > >>>> With the new implementation, mongoose fails to establish a HTTP > connection to my Edimax smart plug. Just that device, every other host > works correctly, also with SSL. > >>>> > >>>> The mg_connect_http_opt() call fails after 18 seconds with error 113 > "Software caused connection abort" ? which may be a timeout or the LWIP > error code 113 "No route to host" passed through by mongoose. > >>>> > >>>> Same behaviour in both client & apclient mode, fixed & scanning. > >>>> > >>>> The Edimax is on the same network as the module (connected to the > same AP) and perfectly reachable from all other stations (and the build > before). Netmask and gateway are correct. Also the wifi connect is still > done by the esp_wifi_connect() call, so there should be no difference?? > >>>> > >>>> I'm puzzled. Any ideas? Any other hosts that cannot be connected to > with the new version? > >>>> > >>>> To test a host, use this JS snippet in the editor with a URL of a > small page or non existent file on the host: > >>>> > >>>> HTTP.Request({ > >>>> url: "http://?", > >>>> always: function() { JSON.print(this, false); } > >>>> }); > >>>> > >>>> Regards, > >>>> Michael > >>>> > >>>> > >>>> Am 10.07.20 um 15:21 schrieb Michael Balzer: > >>>>> The dhcps log messages aren't new, I've had these all the time > before, also sometimes repeating for some period. > >>>>> > >>>>> Also not new are these messages: > >>>>> > >>>>> I (8771413) wifi: ampdu: ignore deleting tx BA0 > >>>>> I (8774723) wifi: ampdu: ignore deleting tx BA0 > >>>>> I (8784043) wifi: ampdu: ignore deleting tx BA0 > >>>>> I (8787253) wifi: ampdu: ignore deleting tx BA0 > >>>>> I (8793673) wifi: ampdu: ignore deleting tx BA0 > >>>>> I (8797813) wifi: ampdu: ignore deleting tx BA0 > >>>>> > >>>>> They now start consistently after doing a scan from a web client > connected via the AP. They stop when the client disconnects. Seem to be > coupled to the websocket somehow. I've found these in my log archives as > well, no clue about the trigger. No issue other than annoying log spam > though, everything works normally. > >>>>> > >>>>> Regards, > >>>>> Michael > >>>>> > >>>>> > >>>>> Am 10.07.20 um 14:36 schrieb Mark Webb-Johnson: > >>>>>> Working for me on my test bench device. I?m building EDGE now. > >>>>>> > >>>>>> Only strange thing so far is I am seeing this message repeatedly in > apclient mode: > >>>>>> > >>>>>> dhcps: send_nak>>udp_sendto result 0 > >>>>>> > >>>>>> Can?t work out the timing, as it seems to be random. I?ll keep > looking... > >>>>>> > >>>>>> Regards, Mark > >>>>>> > >>>>>>> On 10 Jul 2020, at 7:42 PM, Michael Balzer <dexter(a)expeedo.de> > wrote: > >>>>>>> > >>>>>>> Everyone, > >>>>>>> > >>>>>>> the wifi rework is pushed: > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1… > >>>>>>> ?and the new edge build is on my server. > >>>>>>> > >>>>>>> This now allows to scan for networks in all modes without > disruption of a running wifi network. > >>>>>>> > >>>>>>> I've used this to also add a network selection dialog to the setup > wizard & wifi config. > >>>>>>> > >>>>>>> The apclient mode can now be started without a client SSID to let > the module automatically connect to any network configured. The autostart > config page now allows this setup. The special "scanning client" mode has > been removed. > >>>>>>> > >>>>>>> The wifi manager will still stick to an established connection, > even if a new network with higher signal strength becomes available. I > thought about automatically switching networks if the signal gets poor, but > for now decided against it to avoid frequent network reconfigurations in > edge cases. If you want the module to explicitly scan for a better network, > issue "wifi reconnect". > >>>>>>> > >>>>>>> Of course this has involved some changes to the wifi manager, so > please test & report. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Michael > >>>>>>> > >>>>>>> > >>>>>>> Am 10.07.20 um 08:57 schrieb Michael Balzer: > >>>>>>>> TL;DR: yes, I'm currently also going towards not letting > esp_wifi_connect() decide which AP to connect to. > >>>>>>>> > >>>>>>>> More precisely, exactly the first (!) call to esp_wifi_connect() > after a reboot/power up seems to do a round robin scheme among all > reachable access points of a network regardless of their signal strength. > This even applies to the first connect() immediately after a scan. > >>>>>>>> > >>>>>>>> Example: > >>>>>>>> > >>>>>>>> D (5034) events: Signal(system.wifi.scan.done) > >>>>>>>> V (5034) esp32wifi: ScanDone: #01 ssid='WLAN-214677' > bssid='7c:ff:4d:15:2f:86' chan=11 rssi=-64 > >>>>>>>> V (5034) esp32wifi: ScanDone: #02 ssid='WLAN-214677' > bssid='94:4a:0c:c3:9e:63' chan=11 rssi=-77 > >>>>>>>> I (5044) esp32wifi: Found SSID WLAN-214677 - trying to connect > >>>>>>>> I (7564) esp32wifi: STA connected with SSID: WLAN-214677, BSSID: > 94:4a:0c:c3:9e:63, Channel: 11, Auth: WPA2 > >>>>>>>> > >>>>>>>> The next reboot will connect to 7c:ff (despite unchanged signal > strengths), the next again to 94:4a and so on. I've only got two access > points, so I can't test if it's really round-robin, but it's wrong anyway. > >>>>>>>> > >>>>>>>> On all following reconnects on the running system it will > correctly pick the 7c:ff AP, also if wifi is stopped & restarted. > >>>>>>>> > >>>>>>>> This AP switching behaviour also persists powering off the > module, so the wifi blob seems to do this on purpose and even use some > persistent storage to implement it. Totally undocumented and I've found no > way to disable this and no workaround so far. > >>>>>>>> > >>>>>>>> There may be a fix for this in the current esp-idf wifi blob, but > I've found no issues on this, and esp-idf commit comments are mostly not > useful. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Michael > >>>>>>>> > >>>>>>>> > >>>>>>>> Am 10.07.20 um 02:55 schrieb Mark Webb-Johnson: > >>>>>>>>> FYI: > >>>>>>>>> > >>>>>>>>> I?ve recently done some work with the esphome system (based on > platformio on top of esp idf), for home automation. They don?t seem to > trust the ESP libraries identifying the strongest signal (in the case of > two APs broadcasting the same SSID). They don?t blindly connect to a SSID, > but instead first do a scan to produce an ordered list and then connect to > the SSID+AP-MAC-Address of the AP with the strongest signal. > >>>>>>>>> > >>>>>>>>> That approach might help with your other issue (recently raised > in mantis). > >>>>>>>>> > >>>>>>>>> Regards, Mark. > >>>>>>>>> > >>>>>>>>>> On 10 Jul 2020, at 5:43 AM, Michael Balzer <dexter(a)expeedo.de> > wrote: > >>>>>>>>>> > >>>>>>>>>> ? Welcome Derek, > >>>>>>>>>> > >>>>>>>>>> I've got a rework of the wifi component near done that allows > to use scanning mode in apclient configuration. I think I can push the > changes tomorrow & suggest you'll be my beta tester ;-) > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Michael > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Am 09.07.20 um 20:50 schrieb Derek Caudwell: > >>>>>>>>>>> Hi devs, > >>>>>>>>>>> > >>>>>>>>>>> I recently received the ovms hardware and have been trying to > setup the unit so I can solely use the wifi AP+client. In NZ 3G is soon to > be sunset and for my needs I don't really need a connection when I'm > driving (and want to make sure everything is behaving nicely on the can bus > before I do). > >>>>>>>>>>> > >>>>>>>>>>> I realise AP+client brings it limitations however hopefully > some of these can be worked around as I want to be able to use the > dashboard/plugins as well as the mobile app. I am new to C/ESP32 > programming and the code base so I thought it best to ask a few questions > before I begin tinkering with it. > >>>>>>>>>>> > >>>>>>>>>>> Ideally I want the unit on loss of connection to an AP to try > and find another AP that has been set in the wifi config and connect. The > parts I am not too sure are as follows: > >>>>>>>>>>> - on boot the code uses the default wifi ssid, if the default > is not available how does the code try and switch to one of the other saved > APs? > >>>>>>>>>>> - can multiple APs be saved to the wifi config memory and > handled by ESP32? or do they need to be retrieved from ovms config, wifi > client details set, try connect and enumerated through? > >>>>>>>>>>> - I assume EventTimer10 is the logical place to add extra > code if required to enumerate through APs and try to connect? similar to > EventScanWifiDone when in SClient mode > >>>>>>>>>>> - What is the reason scanning mode is unavailable for > AP+client mode in auto init, from the ESP32 documentation it appeared to be > usable still but with limitations? > >>>>>>>>>>> > >>>>>>>>>>> Thanks in advance for any pointers and background. > >>>>>>>>>>> > >>>>>>>>>>> Cheers Derek > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> OvmsDev mailing list > >>>>>>>>>>> OvmsDev(a)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(a)lists.openvehicles.com > >>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> OvmsDev mailing list > >>>>>>>>> OvmsDev(a)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(a)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(a)lists.openvehicles.com > >>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OvmsDev mailing list > >>>>>> OvmsDev(a)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(a)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(a)lists.openvehicles.com > >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > >>> > >>> > >>> _______________________________________________ > >>> OvmsDev mailing list > >>> OvmsDev(a)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(a)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(a)lists.openvehicles.com > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev >

1 0