- OvmsDev - Open Vehicles

Checking mailing list manager
by Mark Webb-Johnson 01 Apr '18

01 Apr '18

Please could one member (the first to get this) please confirm receipt, so we know the mailing list is working properly (after server move)? Thanks, Mark

3 3

Schematics and Layouts
by Mark Webb-Johnson 01 Apr '18

01 Apr '18

FYI: I’ve uploaded the schematics and board layouts for the v1.1 modem and v3.1 main boards, to GitHub. Regards, Mark.

1 0

Migration of lists.teslaclub.hk to new server
by Mark Webb-Johnson 31 Mar '18

31 Mar '18

I am migrating this lists.teslaclub.hk to a new server, over the next hour or two. During that time, mailing list posts will be queued and not delivered. Delivery should resume after the migration is complete. Regards, Mark

1 1

Webserver "status" crash
by Greg D. 30 Mar '18

30 Mar '18

2 2

Time spent in ticker event handlers / new use for housekeeping task
by Michael Balzer 30 Mar '18

30 Mar '18

A question to the FreeRTOS gurus: How much time may we spend in a ticker event handler, or generally a software timer callback, without risking system stability? The FreeRTOS manual explicitly warns about using any kind of blocking calls within the timer service task, as all software timer callbacks are executed in that context: https://freertos.org/RTOS-software-timer.html /"//Timer callback functions execute in the context of the timer service task. It is therefore// /*/essential/*/ //that timer callback functions never attempt to block. For example, a timer callback function must not call vTaskDelay(), vTaskDelayUntil(), or specify a non zero block time when accessing a queue or a semaphore.//"/ The timer service queue currently has 10 slots. That's tunable, but I'm also worried about other system components possibly relying on regular timer periods of higher frequency. My specific issue: I'm producing the notifications from my ticker1 handler. I now found out a simple standard info notification needs already around 10 ms, and my battery status update (15 data messages) needs 60-70 ms. I thought these would run faster, not sure where the time is spent. I'm using the command notifications, nice to use but with quite some overhead of course. So if for example the wifi or bluetooth stack needs a 50 ms timer, that may already be a problem. But do system components use software timers for time critical tasks? The solution would be moving the notification generator to a separate task. A new task would need RAM, but there's also the housekeeping task, which could generally be made available for such needs. It's basically idle after the init process and already has a large stack. I think about adding a callback execution queue to it, so my ticker handler would simply queue the notification generator call there. Thanks, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 5

Website Migration
by Mark Webb-Johnson 30 Mar '18

30 Mar '18

FYI: I will be moving the main www.openvehicles.com and api.openvehicles.com to a new server, tomorrow (30th March 2018) between 01:00UTC and 11:00UTC. During that time window there may be some short periods of unreachability for both www and api services. I will do what I can to minimise that. Regards, Mark.

1 2

Mongoose crash on wifi disconnect
by Michael Balzer 29 Mar '18

29 Mar '18

I just had a wifi disconnect resulting in a mongoose crash. Not sure what disconnect reason 200 is, I don't recall having seen this before. I (724433) wifi: bcn_timout,ap_probe_send_start I (726943) wifi: ap_probe_send over, resett wifi status to disassoc I (726943) wifi: state: run -> init (1) I (726943) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 I (726943) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (726953) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (726953) time: Network was reconfigured: restarting SNTP client I (726953) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (726953) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (726963) esp32wifi: STA disconnected with reason 200 I (726963) ovms-server-v2: Status: Disconnected I (746153) ovms-server-v2: Connection is ovms.dexters-web.de:6867 test1 I (746153) ovms-server-v2: Status: Connecting...Guru Meditation Error: Core 1 panic'ed (StoreProhibited) . Exception was unhandled. Core 1 register dump: PC : 0x400f7ee6 PS : 0x00060330 A0 : 0x800f8090 A1 : 0x3ffe8a00 0x400f7ee6: mg_send_dns_query at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 A2 : 0x3fff55a8 A3 : 0x3fffbb90 A4 : 0x00000001 A5 : 0x00000000 A6 : 0x00000014 A7 : 0x3ffb10b0 A8 : 0x000000a2 A9 : 0x3ffe89e0 A10 : 0x3ffe8a00 A11 : 0x00000040 A12 : 0x3f40c298 A13 : 0x081d0000 A14 : 0x87725000 A15 : 0x00000000 SAR : 0x00000001 EXCCAUSE: 0x0000001d EXCVADDR: 0x0000000a LBEG : 0x40145ccc LEND : 0x40145ceb LCOUNT : 0x00000000 0x40145ccc: __divdf3 at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libgcc/config/xtensa/ieee754-df.S:1454 0x40145ceb: __divdf3 at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libgcc/config/xtensa/ieee754-df.S:1481 Backtrace: 0x400f7ee6:0x3ffe8a00 0x400f808d:0x3ffe8a30 0x400f5eff:0x3ffe8a70 0x400f61c6:0x3ffe8aa0 0x400f74b1:0x3ffe8ad0 0x400f775d:0x3ffe8b10 0x400f3f25:0x3ffe8b60 0x400eb47a:0x3ffe8b80 0x400eb4b9:0x3ffe8bd0 0x400f7ee6: mg_send_dns_query at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f808d: mg_resolve_async_eh at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f5eff: mg_call at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f61c6: mg_if_connect_cb at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f74b1: mg_mgr_handle_conn at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f775d: mg_socket_if_poll at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f3f25: mg_mgr_poll at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400eb47a: OvmsNetManager::MongooseTask() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:382 0x400eb4b9: MongooseRawTask(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:370 Entering gdb stub now. $T0b#e6GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 7.10 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=xtensa-esp32-elf". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf...done. Remote debugging using /dev/ttyUSB0 0x400f7ee6 in mg_send_dns_query (nc=0x3fff55a8, name=0x3fffbb90 "ovms.dexters-web.de", query_type=1) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11172 11172 msg->transaction_id = ++mg_dns_tid; (gdb) bt #0 0x400f7ee6 in mg_send_dns_query (nc=0x3fff55a8, name=0x3fffbb90 "ovms.dexters-web.de", query_type=1) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11172 #1 0x400f8090 in mg_resolve_async_eh (nc=0x3fff55a8, ev=<optimized out>, data=<optimized out>) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11629 #2 0x400f5f02 in mg_call (nc=0x3fff55a8, ev_handler=0x400f800c <mg_resolve_async_eh>, user_data=<optimized out>, ev=2, ev_data=0x3ffe8aa0) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2285 #3 0x400f61c9 in mg_if_connect_cb (nc=0x3fff55a8, err=0) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2824 #4 0x400f74b4 in mg_mgr_handle_conn (nc=0x3fff55a8, fd_flags=2, now=1522337922.4471409) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3705 #5 0x400f7760 in mg_socket_if_poll (iface=<optimized out>, timeout_ms=250) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3922 #6 0x400f3f28 in mg_mgr_poll (m=0x3ffb411c <MyNetManager+12>, timeout_ms=250) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2451 #7 0x400eb47d in OvmsNetManager::MongooseTask (this=0x3ffb4110 <MyNetManager>) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:382 #8 0x400eb4bc in MongooseRawTask (pvParameters=0x3ffb4110 <MyNetManager>) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:370 (gdb) -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Duktape handling of blank metrics?
by Greg D. 28 Mar '18

28 Mar '18

Hi folks, Does anyone know how DukTape scripting handles math with a metric that hasn't been updated yet? I have a short example script in the OBDII ECU documentation which (should) calculate a power-per-speed metric for display on a HUD. Seems like it would be a useful example, and wanted to verify that it actually works. OVMS> vfs cat /store/obd2ecu/10 ret1=OvmsMetricFloat("v.p.speed"); ret2=OvmsMetricFloat("v.b.power"); out = 0.0; if(ret1 > 0) { out=ret2/ret1; } out; I have the module in the my Roadster, and the v.p.speed metric comes up as 0 kph (that's good - it's parked), but the power metric isn't provided by the car, so is blank when listing the metrics. I expected the code to return zero. Instead, executing the script by asking for 'obdii ecu list' causes an immediate crash with a stack overflow in task AsyncConsole. If I initialize the power metric by hand (metric set v.b.power 0), the script runs just fine, returning 0 for the metric. Oddly, when I first set it up on the desk (sans vehicle), so both of the metrics were blank, executing the script didn't cause crash. Is there a way to make the code "Roadster safe", without dummying up the metric in, say, a startup script? Better, is there a fix for DukTape to handle this, or should I just increase the stack size in AsyncConsole? Thanks, Greg

2 9

Hologram Promo Code
by Mark Webb-Johnson 28 Mar '18

28 Mar '18

I’m pleased to announce that Hologram have provided us a promo code, for the OVMS community. It doesn’t require a new account to use (so open for existing users as well as new). Code: OVMS Enter it at checkout to get US$5 of usage free. Please feel free to share this within the OVMS community (I have added it to the www.openvehicles.com <http://www.openvehicles.com/> site, under Account/Vehicles just next to the Fasttech coupon code), but as usual don’t publicly post it. Thanks, Hologram! Regards, Mark.

1 0

v3 hardware disconnecting from v2 server
by Tom Parker 26 Mar '18

26 Mar '18

Hi, I've been struggling for some time with intermittent disconnections from the v2 server. I've switched from hologram to a local cellular provider's sim card, to match my v2 hardware which is very stable and the problem persists. With the car stationary, the connection seems very solid, but on the move, it usually disconnects within half an hour. I'm running 98169d8862db2bbc4bea14d013883f26ee6afb4e (from 2018-01-19) with idf 5bf85d06d8c402fe30ecb1bf9c09d5e69b923b2f and xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz. I tried logging to the sdcard and on my desk powered by USB that seemed to work well, but it didn't work very well (only a few lines logged to the sdcard and then the whole system seemed to crash) when powered from the OBD2 port. I haven't tried to debug that. With the sdcard logging turned off, and logging with minicom I can get good diagnostics. It would appear that the v3 hardware thinks it is still connected and continues to send data, but the v2 server thinks the client has disconnected. I've got ovms logs which have regular lines quoting the local time from the modem, and server logs from the dexters-web server which I think are not UTC. Anyway, 05:47 in the server log corresponds to 17:47 in the ovms v3 log. The relevant lines of the logs are below. On the server log the ovms v3 hardware client is #72 and then #94. We can see the client sent and the server received S messages at :47:15 and :47:32. The client sent more messages that were not received by the server, more than I've transcribed here (full log attached). The server recorded a disconnect at :48:29, but the client recorded the transmission of messages in it's log for minutes after that. I did a simcom status command which reports that everything is connected, and then I pressed the button to reboot the module. The server records a new connection at :54:07 and the messages logged as transmitted on the client start to correspond with the messages logged as received on the server start again. Thoughts on how to proceed? Another oddity not shown here but included in the full logs is that the client sent a lot of D messages shortly after reconnecting. Server Log: 2018-01-26 05:47:15,36664,'#72 C rx msg S 90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96' 2018-01-26 05:47:15,36665,'#72 C rx msg D 128,0,5,0,0,33,0,0,0,79663,32,1,1,1,12.9231,0,0,128,0,0' 2018-01-26 05:47:15,36666,'#72 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2018-01-26 05:47:15,36667,'#72 C rx msg F 3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,6,1,NL,2degrees' 2018-01-26 05:47:32,36717,'#72 C rx msg S 90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,387.00,96' 2018-01-26 05:48:29,36926,'#72 C got error: Connection reset by peer' 2018-01-26 05:50:08,37206,'#93 A got login' 2018-01-26 05:51:24,37485,'#36 A rx msg A ' 2018-01-26 05:52:53,37742,'#93 A got error: Broken pipe' 2018-01-26 05:52:54,37745,'#72 A got login' 2018-01-26 05:54:07,37937,'#94 C got login' 2018-01-26 05:54:13,37957,'#94 C rx msg S 87,K,0,0,stopped,standard,73,0,0,0,0,0,13,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,385.50,0' 2018-01-26 05:54:13,37958,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,59,28,1,0,0,13.011,0,0,128,0,0' 2018-01-26 05:54:13,37959,'#94 C rx msg L 0,0,0,0,0,0,104,0,0,0,0' 2018-01-26 05:54:13,37960,'#94 C rx msg W 0,0,0,0,0,0,0,0,0' 2018-01-26 05:54:13,37961,'#94 C rx msg F 3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,1,1,NL,2degrees' 2018-01-26 05:54:15,37964,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,60,28,1,0,0,13.011,0,0,128,0,0' 2018-01-26 05:54:15,37965,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,61,28,1,0,0,13.011,0,0,128,0,0' Serial Console Log: OVMS > I (79663340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96 I (79663340) ovms-server-v2: Send MP-0 D128,0,5,0,0,33,0,0,0,79663,32,1,1,1,12.9231,0,0,128,0,0 I (79663340) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,0,0,0,0,0 I (79663350) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,6,1,NL,2degrees OVMS > D (79665360) simcom: rx line ch=3 len=11 : +CSQ: 10,99 D (79665360) simcom: rx line ch=4 len=11 : +CSQ: 10,99 OVMS > D (79674380) simcom: rx line ch=3 len=11 : +CSQ: 13,99 D (79674390) simcom: rx line ch=4 len=11 : +CSQ: 13,99 OVMS > D (79678420) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79678420) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:47:26+52" D (79678420) simcom: rx line ch=3 len=11 : +CSQ: 13,99 D (79678420) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79678420) simcom: rx line ch=3 len=2 : OK OVMS > I (79681340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,387.00,96 OVMS > D (79683370) simcom: rx line ch=3 len=10 : +CSQ: 9,99 D (79683370) simcom: rx line ch=4 len=10 : +CSQ: 9,99 OVMS > D (79692410) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79692420) simcom: rx line ch=4 len=10 : +CSQ: 3,99 OVMS > D (79708420) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79708420) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:47:56+52" D (79708420) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79708420) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79708420) simcom: rx line ch=3 len=2 : OK OVMS > D (79713470) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79713470) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > D (79716420) simcom: rx line ch=3 len=10 : +CSQ: 0,99 D (79716420) simcom: rx line ch=4 len=10 : +CSQ: 0,99 OVMS > I (79724340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96 I (79724340) ovms-server-v2: Send MP-0 D128,0,5,0,0,33,0,0,55,79724,30,1,1,1,13.022,0,0,128,0,0 I (79724350) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,55,0,0,0,0 I (79724350) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,0,1,NL,2degrees OVMS > D (79738360) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79738360) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:48:26+52" D (79738360) simcom: rx line ch=3 len=10 : +CSQ: 0,99 D (79738360) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79738360) simcom: rx line ch=3 len=2 : OK OVMS > D (79740490) simcom: rx line ch=3 len=10 : +CSQ: 4,99 D (79740500) simcom: rx line ch=4 len=10 : +CSQ: 4,99 OVMS > I (79741340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,388.50,96 OVMS > D (79764490) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79764490) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > D (79768360) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79768360) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:48:56+52" D (79768360) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79768360) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79768360) simcom: rx line ch=3 len=2 : OK OVMS > D (79773490) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79773500) simcom: rx line ch=4 len=10 : +CSQ: 3,99 OVMS > D (79779500) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79779500) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > I (79785340) ovms-server-v2: Send MP-0 S89,K,0,0,stopped,standard,75,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.00,96 ... OVMS > simcom status SIMCOM Network Registration: RegisteredHome State: NetMode Ticker: 25111 User Data: 0 Mux Open Channels: 4 PPP Connected on channel: #2 PPP Last Error: None GPS: disabled GPS time: disabled NMEA (GPS/GLONASS) Not Connected ... I rebooted the module and it did the normal connection dance ... D (48359) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:53:57+52" ... I (57609) ovms-server-v2: Status: Connecting... OVMS > I (58219) ovms-server-v2: Connection successful I (58219) ovms-server-v2: Status: Logging in... I (58219) ovms-server-v2: Sending server login: MP-C 0 pwLSijW/3qAZ6z0LOBHbGS rnkkhqHUA6zeZqLx1q1Tow== NZLV3 OVMS > I (58889) ovms-server-v2: Got server response: MP-S 0 QTjRAp8ZQPJQV1UXnepldQ w1vWpIrRR9+eot9z3uslgw== I (58889) ovms-server-v2: Server token is QTjRAp8ZQPJQV1UXnepldQ and digest is w1vWpIrRR9+eot9z3uslgw== I (58899) ovms-server-v2: Status: Server auth ok. Now priming crypto. I (58899) ovms-server-v2: Shared secret key is QTjRAp8ZQPJQV1UXnepldQpwLSijW/3qAZ6z0LOBHbGS (44 bytes) I (58899) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established OVMS > I (59189) ovms-server-v2: Incoming Msg: MP-0 Z4 I (59189) ovms-server-v2: One or more peers have connected I (59339) ovms-server-v2: Send MP-0 S87,K,0,0,stopped,standard,73,0,0,0,0,0,13,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,385.50,0

6 72