New version, tagged and in the repository now: 2018-03-05 MWJ 3.0.991 OTA release support OTA updates over HTTP - Update ovms_module to use new API for per-task heap info. - Commands "time status" and "time set" for access to real-time clock. - Time zone support in config vehicle/timezone See GNU LIBC documentation for details on format https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html - Auto start/init for wifi, modem, vehicle type, server v2 & v3 - Fix to SDCARD component to free SD_DATA1, SD_DATA2, and SD_DATA3 in 1-line mode (in particular so SD_DATA1/GPIO4 and SD_DATA3/GPIO13 can be used for UART to simcom modem for OVMS v3.1 hardware). https://www.esp32.com/viewtopic.php?f=13&t=4838 - Record statistics for CAN bus interrupts (per controller) and show in status. - Don't issue network.reconfigured event when network is down. - Auto start for ext12v & obd2ecu - Web config for timezone & distance units - Twizy web UI for features, battery properties & charge control - Support ESP IDF v3 style OTA updates over http This version is available via OTA (for both 3.0 and 3.1), but unfortunately you’ll need this version running to be able to do an http OTA ;-) If you want to try, then first flash it (as normal), then start wifi, then do ‘ota flash http’. Next version will be 3.0.992. Example: OVMS > ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3.1/main/ovms3.bin to ota_0 Expected file size is 1970944 Preparing flash partition... Downloading... (100208 bytes so far) Downloading... (200216 bytes so far) Downloading... (300324 bytes so far) Downloading... (400744 bytes so far) Downloading... (500752 bytes so far) Downloading... (600960 bytes so far) Downloading... (701068 bytes so far) Downloading... (801388 bytes so far) Downloading... (901396 bytes so far) Downloading... (1001604 bytes so far) Downloading... (1102024 bytes so far) Downloading... (1202132 bytes so far) Downloading... (1302140 bytes so far) Downloading... (1402248 bytes so far) Downloading... (1502668 bytes so far) Downloading... (1603088 bytes so far) Downloading... (1703296 bytes so far) Downloading... (1803304 bytes so far) Downloading... (1903724 bytes so far) Setting boot partition... OTA flash was successful Flashed 1970944 bytes from api.openvehicles.com/firmware/ota/v3.1/main/ovms3.bin Next boot will be from ‘ota_0' OVMS > ota status Firmware: 3.0.991-dirty/factory/main build (idf v3.1-dev-453-g0f978bcb) Mar 5 2018 13:34:10 Running partition: factory Boot partition: ota_0 OVMS > metrics list m.ve m.version 3.0.991-dirty/factory/main build (idf v3.1-dev-453-g0f978bcb) Mar 5 2018 13:34:10 This is using the ESP IDF v3.x way of doing OTA binary images. The last 32 bytes of the image contains a sha256 checksum of the image (up to but not including the last 32bytes). The ESP IDF bootloader checks that. Seems to work, but a little bit flaky. Sometimes I can’t get DNS resolution. Anyway, OTA updates are available now, and I’ll try to improve on it over the next few days. Longer term, we want this to happen automatically, so long as module is on wifi. Perhaps once a day. We can worry about that later; for the moment, connect to the web interface then run ‘ota flash http’ from the console there. Regards, Mark.
Why should wifi auto-start in AP mode if wifi.ssid is already configured? Is auto-start supposed to serve the role of starting the module in its normal mode of operation to avoid having the enable password in a script? (I thought I read something like that in earlier discussion.) -- Steve
Steve, Am 05.03.2018 um 08:03 schrieb Stephen Casner:
Why should wifi auto-start in AP mode if wifi.ssid is already configured?
Is auto-start supposed to serve the role of starting the module in its normal mode of operation to avoid having the enable password in a script? (I thought I read something like that in earlier discussion.)
-- Steve
Yes, that's the intended main purpose. The wifi auto start mode is configurable, you can choose AP mode or client mode and which SSID to use (or no SSID for scanning client mode). I'll use AP mode in my car, let my phone connect to it automatically and start the web UI to have it work as a dashboard and console. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On Mon, 5 Mar 2018, Michael Balzer wrote:
I'll use AP mode in my car, let my phone connect to it automatically and start the web UI to have it work as a dashboard and console.
I decided to try out this AP mode with my iPhone. After finding the IP address using the async console I used Safari on the iPhone to connect to OVMS. I then went to the shell page and logged in. I entered the "help" command and that executed as expected. I did not do anything else with the phone or async console for a minute or two when out of the blue the system crashed: OVMS > wifi status WiFi Power: on Mode: Access point mode SSID: OVMS MAC: 30:ae:a4:37:1b:85 IP: 192.168.4.1 Stations: 1 1: MAC: 98:00:c6:b1:90:ca, IP: 192.168.4.2 W (530733) webserver: HandleLogin: auth failure for username '' OVMS > Guru Meditation Error: Core 0 panic'ed (StoreProhibited) . Exception was unhandled. Core 0 register dump: PC : 0x4000c291 PS : 0x00060b30 A0 : 0x800f4664 A1 : 0x3ffd1290 A2 : 0x00000016 A3 : 0x3ffd1321 A4 : 0x00000002 A5 : 0x00000016 A6 : 0x00000081 A7 : 0x0000002e A8 : 0x00000000 A9 : 0x3ffd152c A10 : 0x00000000 A11 : 0x00000001 A12 : 0x8008b383 A13 : 0x3ffe5180 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000016 EXCCAUSE: 0x0000001d EXCVADDR: 0x00000016 LBEG : 0x4000c28c LEND : 0x4000c296 LCOUNT : 0x00000001 [snip] Remote debugging using /dev/cu.SLAB_USBtoUART 0x4000c291 in ?? () (gdb) (gdb) bt #0 0x4000c291 in ?? () #1 0x400f4664 in mbuf_insert (a=0x3fff8d24, off=22, buf=0x3ffd1320, len=2) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1511 #2 0x400f46e1 in mbuf_append (a=0x3fff8d24, buf=0x3ffd1320, len=2) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1532 #3 0x400f46f7 in mg_socket_if_tcp_send (nc=0x3fff8cec, buf=0x3ffd1320, len=2) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3525 #4 0x400f54b8 in mg_send (nc=0x3fff8cec, buf=0x3ffd1320, len=2) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2765 #5 0x400f55d7 in mg_send_ws_header (nc=0x3fff8cec, op=<optimized out>, len=57, ctx=0x3ffd1350) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:9796 #6 0x400f66ad in mg_send_websocket_frame (nc=0x3fff8cec, op=1, data=0x3fff808c, len=57) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:9813 #7 0x4011dd46 in OvmsWebServer::WebsocketBroadcast (msg=...) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:483 #8 0x4011ef4c in OvmsWebServer::BroadcastMetrics (this=<optimized out>, update_all=<optimized out>) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:526 #9 0x4011ef73 in OvmsWebServer::UpdateTicker (timer=<optimized out>) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:536 #10 0x4008d73d in prvProcessExpiredTimer (xNextExpireTime=67165, xTimeNow=67165) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:523 #11 0x4008d770 in prvProcessTimerOrBlockTask (xNextExpireTime=67165, xListWasEmpty=<optimized out>) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:570 #12 0x4008d87f in prvTimerTask (pvParameters=0x0) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:543 (gdb) This is with OVMS code updated last night, but then it occurred to me that I had not updated esp-idf since 2/23, so this crash may be due to some incompatibilty. I have now updated esp-idf and the crash did not repeat in the several minutes that I waited. Therefore the crash above may be invalid, but I record it here for posterity. -- Steve
Steve, the IP address is fixed to 192.168.4.1 for the AP. Zeroconf / mDNS allows to address the module using the name "<moduleid>.local", but is not supported on all systems. It should work on iOS, but I can't test that. It doesn't work on Android 7, so is not usable as a general solution. Thanks for the crash report. It's not related to the esp-idf version. It occurs frequently if you're running low on memory (i.e. with many metrics and/or multiple web clients open in parallel), plus there's currently a race condition between metrics and event transfers. I'm already working on a solution for both. Regards, Michael Am 06.03.2018 um 03:31 schrieb Stephen Casner:
On Mon, 5 Mar 2018, Michael Balzer wrote:
I'll use AP mode in my car, let my phone connect to it automatically and start the web UI to have it work as a dashboard and console. I decided to try out this AP mode with my iPhone. After finding the IP address using the async console I used Safari on the iPhone to connect to OVMS. I then went to the shell page and logged in. I entered the "help" command and that executed as expected. I did not do anything else with the phone or async console for a minute or two when out of the blue the system crashed:
OVMS > wifi status WiFi Power: on Mode: Access point mode SSID: OVMS MAC: 30:ae:a4:37:1b:85 IP: 192.168.4.1 Stations: 1 1: MAC: 98:00:c6:b1:90:ca, IP: 192.168.4.2 W (530733) webserver: HandleLogin: auth failure for username '' OVMS > Guru Meditation Error: Core 0 panic'ed (StoreProhibited) . Exception was unhandled. Core 0 register dump: PC : 0x4000c291 PS : 0x00060b30 A0 : 0x800f4664 A1 : 0x3ffd1290 A2 : 0x00000016 A3 : 0x3ffd1321 A4 : 0x00000002 A5 : 0x00000016 A6 : 0x00000081 A7 : 0x0000002e A8 : 0x00000000 A9 : 0x3ffd152c A10 : 0x00000000 A11 : 0x00000001 A12 : 0x8008b383 A13 : 0x3ffe5180 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000016 EXCCAUSE: 0x0000001d EXCVADDR: 0x00000016 LBEG : 0x4000c28c LEND : 0x4000c296 LCOUNT : 0x00000001
[snip]
Remote debugging using /dev/cu.SLAB_USBtoUART 0x4000c291 in ?? () (gdb) (gdb) bt #0 0x4000c291 in ?? () #1 0x400f4664 in mbuf_insert (a=0x3fff8d24, off=22, buf=0x3ffd1320, len=2) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1511 #2 0x400f46e1 in mbuf_append (a=0x3fff8d24, buf=0x3ffd1320, len=2) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1532 #3 0x400f46f7 in mg_socket_if_tcp_send (nc=0x3fff8cec, buf=0x3ffd1320, len=2) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3525 #4 0x400f54b8 in mg_send (nc=0x3fff8cec, buf=0x3ffd1320, len=2) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2765 #5 0x400f55d7 in mg_send_ws_header (nc=0x3fff8cec, op=<optimized out>, len=57, ctx=0x3ffd1350) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:9796 #6 0x400f66ad in mg_send_websocket_frame (nc=0x3fff8cec, op=1, data=0x3fff808c, len=57) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:9813 #7 0x4011dd46 in OvmsWebServer::WebsocketBroadcast (msg=...) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:483 #8 0x4011ef4c in OvmsWebServer::BroadcastMetrics (this=<optimized out>, update_all=<optimized out>) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:526 #9 0x4011ef73 in OvmsWebServer::UpdateTicker (timer=<optimized out>) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:536 #10 0x4008d73d in prvProcessExpiredTimer (xNextExpireTime=67165, xTimeNow=67165) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:523 #11 0x4008d770 in prvProcessTimerOrBlockTask (xNextExpireTime=67165, xListWasEmpty=<optimized out>) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:570 #12 0x4008d87f in prvTimerTask (pvParameters=0x0) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:543 (gdb)
This is with OVMS code updated last night, but then it occurred to me that I had not updated esp-idf since 2/23, so this crash may be due to some incompatibilty. I have now updated esp-idf and the crash did not repeat in the several minutes that I waited. Therefore the crash above may be invalid, but I record it here for posterity.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, I trying to figure out how Zeroconf is supposed to work, given the networking services that the module currently supports. Perhaps I don't understand mDNS well enough, but don't we need some means to broadcast our presence, separate from the network? I was able to run the ZeroConf Browser on my Android phone (Google Pixel2, latest code), and it did discover the module. But that was only when the module and phone were both connected by wifi to the home network. When it was running in AP mode, with the phone connected to the home network, there is no way for the phone to see the mDNS service announcement packets. I did a wireless trace of the wifi beacons, thinking it might be broadcast in there, but didn't find anything service-oriented other than the usual stuff. The only wifi adapter that I could get to cooperate with me today was a really old one (11b-only), so perhaps there's something at an 11g/n level that I can't see? I'm thinking we need some out-of-band channel for the broadcasts, for example, Bluetooth. Isn't there a service there for this purpose? How is this supposed to work? Greg Michael Balzer wrote:
Zeroconf / mDNS allows to address the module using the name "<moduleid>.local", but is not supported on all systems. It should work on iOS, but I can't test that. It doesn't work on Android 7, so is not usable as a general solution.
From my understanding, Zeroconf / mDNS rely on a pre-existing IP network. They don’t address the wifi side of things at all. There are some approaches to dealing with simplifying wifi configuration (involving flashing lights, bluetooth adverts, etc), but they are all proprietary. Espressif has one called ESP-TOUCH (aka Smart Config): https://www.espressif.com/en/products/software/esp-touch/overview <https://www.espressif.com/en/products/software/esp-touch/overview> Regards, Mark.
On 7 Mar 2018, at 7:24 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Michael,
I trying to figure out how Zeroconf is supposed to work, given the networking services that the module currently supports. Perhaps I don't understand mDNS well enough, but don't we need some means to broadcast our presence, separate from the network?
I was able to run the ZeroConf Browser on my Android phone (Google Pixel2, latest code), and it did discover the module. But that was only when the module and phone were both connected by wifi to the home network. When it was running in AP mode, with the phone connected to the home network, there is no way for the phone to see the mDNS service announcement packets.
I did a wireless trace of the wifi beacons, thinking it might be broadcast in there, but didn't find anything service-oriented other than the usual stuff. The only wifi adapter that I could get to cooperate with me today was a really old one (11b-only), so perhaps there's something at an 11g/n level that I can't see?
I'm thinking we need some out-of-band channel for the broadcasts, for example, Bluetooth. Isn't there a service there for this purpose? How is this supposed to work?
Greg
Michael Balzer wrote:
Zeroconf / mDNS allows to address the module using the name "<moduleid>.local", but is not supported on all systems. It should work on iOS, but I can't test that. It doesn't work on Android 7, so is not usable as a general solution.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
It does work on my iOS devices. For the module in my car, I’m currently using an iPad. I join the Access Point, then ssh to <vehicleid>.local. Web browsing to that address works as well. Regards, Mark.
On 7 Mar 2018, at 10:29 AM, Greg D. <gregd2350@gmail.com> wrote:
Yeah, probably more complicated and proprietary than we need. Just need to put 192.168.4.1 in the manual, after all. Done.
Greg
Mark Webb-Johnson wrote:
From my understanding, Zeroconf / mDNS rely on a pre-existing IP network. They don’t address the wifi side of things at all.
There are some approaches to dealing with simplifying wifi configuration (involving flashing lights, bluetooth adverts, etc), but they are all proprietary. Espressif has one called ESP-TOUCH (aka Smart Config):
https://www.espressif.com/en/products/software/esp-touch/overview <https://www.espressif.com/en/products/software/esp-touch/overview>
Regards, Mark.
On 7 Mar 2018, at 7:24 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Michael,
I trying to figure out how Zeroconf is supposed to work, given the networking services that the module currently supports. Perhaps I don't understand mDNS well enough, but don't we need some means to broadcast our presence, separate from the network?
I was able to run the ZeroConf Browser on my Android phone (Google Pixel2, latest code), and it did discover the module. But that was only when the module and phone were both connected by wifi to the home network. When it was running in AP mode, with the phone connected to the home network, there is no way for the phone to see the mDNS service announcement packets.
I did a wireless trace of the wifi beacons, thinking it might be broadcast in there, but didn't find anything service-oriented other than the usual stuff. The only wifi adapter that I could get to cooperate with me today was a really old one (11b-only), so perhaps there's something at an 11g/n level that I can't see?
I'm thinking we need some out-of-band channel for the broadcasts, for example, Bluetooth. Isn't there a service there for this purpose? How is this supposed to work?
Greg
Michael Balzer wrote:
Zeroconf / mDNS allows to address the module using the name "<moduleid>.local", but is not supported on all systems. It should work on iOS, but I can't test that. It doesn't work on Android 7, so is not usable as a general solution.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Greg, so you did get it to work on Android 7 & 8? Or was it just the ZeroConf App that showed the mDNS registry info? ZeroConf shows the device on my Android phone (7) and tablet (6) as well, but both are unable to resolve the host name in all other Apps. Have you installed something along with the App or done some additional config? Without a moduleid, the mDNS hostname defaults to "ovms.local", which is of course much easier to type than an IP address. We need to mention both options in the user guide, but we could recommend first trying "ovms.local" for the platforms supporting ZeroConf. Regards, Michael Am 07.03.2018 um 05:28 schrieb Greg D.:
Ha! Change what I said... Must not have waited long enough. As you did, simply joining the AP, the 'Service Browser' app eventually did discover the module at 192.168.4.1, with my car's ID. The 'ZeroConf Browser' app had a problem with it (said there was something there, but no information). This on both my phone (Android 8.1) and tablet (Android 7.0).
Of course, since my phone got a 192.168.4.2 IP Address, it wasn't too hard to guess where the module was.
Greg
Mark Webb-Johnson wrote:
It does work on my iOS devices.
For the module in my car, I’m currently using an iPad. I join the Access Point, then ssh to <vehicleid>.local. Web browsing to that address works as well.
Regards, Mark.
On 7 Mar 2018, at 10:29 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Yeah, probably more complicated and proprietary than we need. Just need to put 192.168.4.1 in the manual, after all. Done.
Greg
Mark Webb-Johnson wrote:
From my understanding, Zeroconf / mDNS rely on a pre-existing IP network. They don’t address the wifi side of things at all.
There are some approaches to dealing with simplifying wifi configuration (involving flashing lights, bluetooth adverts, etc), but they are all proprietary. Espressif has one called ESP-TOUCH (aka Smart Config):
https://www.espressif.com/en/products/software/esp-touch/overview
Regards, Mark.
On 7 Mar 2018, at 7:24 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Michael,
I trying to figure out how Zeroconf is supposed to work, given the networking services that the module currently supports. Perhaps I don't understand mDNS well enough, but don't we need some means to broadcast our presence, separate from the network?
I was able to run the ZeroConf Browser on my Android phone (Google Pixel2, latest code), and it did discover the module. But that was only when the module and phone were both connected by wifi to the home network. When it was running in AP mode, with the phone connected to the home network, there is no way for the phone to see the mDNS service announcement packets.
I did a wireless trace of the wifi beacons, thinking it might be broadcast in there, but didn't find anything service-oriented other than the usual stuff. The only wifi adapter that I could get to cooperate with me today was a really old one (11b-only), so perhaps there's something at an 11g/n level that I can't see?
I'm thinking we need some out-of-band channel for the broadcasts, for example, Bluetooth. Isn't there a service there for this purpose? How is this supposed to work?
Greg
Michael Balzer wrote:
Zeroconf / mDNS allows to address the module using the name "<moduleid>.local", but is not supported on all systems. It should work on iOS, but I can't test that. It doesn't work on Android 7, so is not usable as a general solution.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Greg, there are better Apps than ZeroConf browser to list mDNS services, that also offer opening in a browser without needing to copy&paste the IP. For example: https://play.google.com/store/apps/details?id=jp.deci.tbt.andro.bonjoursearc... Actually mDNS _is_ supported by the Android libs, it's just not in the resolver, so is not available for Apps that don't implement it explicitly. Stupid decision. Regards, Michael Am 07.03.2018 um 22:43 schrieb Greg D.:
Hi Michael,
Yes. ZeroConf Browser used to be my default mDNS scanner, but I thought to try another, and that one worked. The app is "Service Browser" by Andriy Druk. And, it's open source. But, I wouldn't call the system all that robust; tried it again today, and it took a long time for the new software to stop spinning and to reveal something. During that time, the old software was reporting no services, as it did when I first tried it. Overall, a lot quicker and more reliable to read the (presumed) OVMS documentation and follow the instructions to 192.168.4.1...
But when it finally worked, it worked on both Android 7 & 8.1. I didn't try to go to the text name, only the revealed IP address, which the app conveniently can copy to the phone's clipboard for pasting into the browser address line. Trying"ovms.local" today didn't work at all, with either Chrome or Firefox. Neither could find it, and both ran off to search for it on the Web. {sigh}
Greg
Michael Balzer wrote:
Greg,
so you did get it to work on Android 7 & 8? Or was it just the ZeroConf App that showed the mDNS registry info?
ZeroConf shows the device on my Android phone (7) and tablet (6) as well, but both are unable to resolve the host name in all other Apps. Have you installed something along with the App or done some additional config?
Without a moduleid, the mDNS hostname defaults to "ovms.local", which is of course much easier to type than an IP address. We need to mention both options in the user guide, but we could recommend first trying "ovms.local" for the platforms supporting ZeroConf.
Regards, Michael
Am 07.03.2018 um 05:28 schrieb Greg D.:
Ha! Change what I said... Must not have waited long enough. As you did, simply joining the AP, the 'Service Browser' app eventually did discover the module at 192.168.4.1, with my car's ID. The 'ZeroConf Browser' app had a problem with it (said there was something there, but no information). This on both my phone (Android 8.1) and tablet (Android 7.0).
Of course, since my phone got a 192.168.4.2 IP Address, it wasn't too hard to guess where the module was.
Greg
Mark Webb-Johnson wrote:
It does work on my iOS devices.
For the module in my car, I’m currently using an iPad. I join the Access Point, then ssh to <vehicleid>.local. Web browsing to that address works as well.
Regards, Mark.
On 7 Mar 2018, at 10:29 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Yeah, probably more complicated and proprietary than we need. Just need to put 192.168.4.1 in the manual, after all. Done.
Greg
Mark Webb-Johnson wrote:
From my understanding, Zeroconf / mDNS rely on a pre-existing IP network. They don’t address the wifi side of things at all.
There are some approaches to dealing with simplifying wifi configuration (involving flashing lights, bluetooth adverts, etc), but they are all proprietary. Espressif has one called ESP-TOUCH (aka Smart Config):
https://www.espressif.com/en/products/software/esp-touch/overview
Regards, Mark.
> On 7 Mar 2018, at 7:24 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote: > > Hi Michael, > > I trying to figure out how Zeroconf is supposed to work, given the > networking services that the module currently supports. Perhaps I don't > understand mDNS well enough, but don't we need some means to broadcast > our presence, separate from the network? > > I was able to run the ZeroConf Browser on my Android phone (Google > Pixel2, latest code), and it did discover the module. But that was only > when the module and phone were both connected by wifi to the home > network. When it was running in AP mode, with the phone connected to > the home network, there is no way for the phone to see the mDNS service > announcement packets. > > I did a wireless trace of the wifi beacons, thinking it might be > broadcast in there, but didn't find anything service-oriented other than > the usual stuff. The only wifi adapter that I could get to cooperate > with me today was a really old one (11b-only), so perhaps there's > something at an 11g/n level that I can't see? > > I'm thinking we need some out-of-band channel for the broadcasts, for > example, Bluetooth. Isn't there a service there for this purpose? How > is this supposed to work? > > Greg > > > > > Michael Balzer wrote: >> Zeroconf / mDNS allows to address the module using the name "<moduleid>.local", but is not supported on all systems. It should work on iOS, but I can't >> test >> that. It doesn't work on Android 7, so is not usable as a general solution. > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Am 06.03.2018 um 08:35 schrieb Michael Balzer:
Thanks for the crash report. It's not related to the esp-idf version. It occurs frequently if you're running low on memory (i.e. with many metrics and/or multiple web clients open in parallel), plus there's currently a race condition between metrics and event transfers. I'm already working on a solution for both.
I've pushed the update for the webserver to solve these issues. I've added some memory usage debug logs that can be activated by "log level debug webserver". The verbose level will give more detail but be a bit noisy now with a websocket running. It's harder now, but I still can crash it running out of memory by issueing a full "metrics list" in Twizy mode if hitting the right moment. The Twizy metrics dump needs ~9.4 kB: I (1699644) webserver: HTTP POST /api/execute I (1699644) webserver: HandleCommand: 31756 bytes free, executing: metrics list D (1699774) webserver: HandleCommand: 22300 bytes free, output size: 9383 bytes D (1699774) webserver: Serve /api/execute: 9672 bytes used, 22084 free This is now sent in 1K chunks, but the 22 kB free is a bit misleading. The command execution temporarily needs about double the size (once for the LogBuffers, once for the Dump() destination string). The 22 kB free is _after_ the Dump(), so LogBuffers already have been freed. At or below 20 kB of free RAM, the crash on "metrics list" is almost certain. I assume most of you don't get that low on free RAM and have smaller metrics sets, so this version should be stable for you. Please tell me if you're still encountering crashes. To avoid the second buffer of the command execution, I can add a chunked sender that directly reads the LogBuffers, so no Dump(string) is needed. But maybe there is a way to avoid even the LogBuffers. I'm thinking about an OvmsWriter that can write directly to a mongoose connection. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
All passwords are in the config store (and write-only so not visible). Regards, Mark
On 5 Mar 2018, at 3:03 PM, Stephen Casner <casner@acm.org> wrote:
Why should wifi auto-start in AP mode if wifi.ssid is already configured?
Is auto-start supposed to serve the role of starting the module in its normal mode of operation to avoid having the enable password in a script? (I thought I read something like that in earlier discussion.)
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (4)
-
Greg D. -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner