[Ovmsdev] Initial OTA update

Thu Apr 19 12:29:54 HKT 2018

Mark, 

The vehicle id is TRS0879 and I tried to do the remote charge multiple
times today beginning at ~12:40p PDT through to ~4:30p PDT [using the
cellular modem].  This evening, beginning ~9:15p PDT, I've tried to
start a charge remotely over Wifi.  So far for all attempts, no joy. 
I've tried using both the Mobile app [iPhone], as well as the web app
contained in the v3.  All tries appear to timeout without starting the
charge. 

I'm wondering if the "Timed Charge" status of the car, is overriding the
request to "Start Charge" [immediately]. 

Thanks for your kind help with this. 

Chip

On 2018-04-18 4:47 pm, Mark Webb-Johnson wrote:

> Chip, 
> 
> If you can let me know the vehicle ID and the date+time (UTC would be helpful) you did this action, then I can check server logs for what was seen. 
> 
> Regards, Mark
> 
> On 19 Apr 2018, at 4:31 AM, chip at cangmag.com wrote: 
> 
> Greg, 
> 
> I have the car permanently in Debug mode, and nothing came up on the VDS.  I'll check the log later today when I get back to the car---I may not be able to report back until tomorrow. 
> 
> Chip
> 
> On 2018-04-18 1:25 pm, Greg D. wrote: Were there any errors / alerts reported by the car?  They might be buried in the car's logs, and not displayed on the VDS unless you were in diagnostc or debug mode.
> 
> Greg
> 
> chip at cangmag.com wrote: 
> 
> Reference:  Tesla Roadster 2.0 Sport 
> 
> OVMS Firmware-- Server: 2.1.1-20121216 Car: 3.1.004/ota_0/main App: 1.6.6 (20150821) 
> 
> I've been running the new v3 since Sunday 15 Apr without fault [updated to build 3.004 on Mon 16 Apr].  I've successfully used a variety of capabilities using the iPhone Mobile app [1.6.6].   
> 
> Successfully operating: Remote door lock and unlock, remote Homelink, remotely change charging mode [Standard, Storage, Range]. 
> 
> Today, for the first time, and while communicating over the cellular modem, I COULD NOT remotely start a charging cycle, I then tested other remote functions [door lock and change of charging mode both worked], but when I went back to remotely start a charging cycle, again it didn't engage.  On the app screen that charge "slider" slides over to the right, but just stays there and ultimately times out. 
> 
> I will test this again tonight at home when I am on Wifi (which I seem to recall may have been working on Sunday, so it may be related to communicating over the cellular network). 
> 
> This may also be a just a non-repeatable gremlin, but I thought I'd notify this group to get the observation out there, and see if maybe anyone else is seeing it. 
> 
> Chip C. 
> 
> On 2018-04-18 9:46 am, Greg D. wrote: Michael Balzer wrote:
> 
> Am 16.04.2018 um 22:16 schrieb Michael Balzer:
> 
> I have seen the queue overflow problem once on the current build, so it isn't solved. But it wasn't related to any action, it happened while
> the module was idle.
> 
> To clarify, it's no problem if it resolves after some seconds, that may be due to a temporary mongoose lock / overload. If we can trigger that
> reliably by some action, that would help to track this down.
> 
> Short update: I could trigger it again now multiple times on the OTA page. It seems to be happening due to the update check running over the
> modem line, it does not happen with modem disabled. I need to check in Wifi client mode.
> 
> Regards,
> Michael

Hi Michael,

Interesting...  I was going to write back and say that the 3.003 to
3.004 update went very smoothly, with no queue overflows being reported,
and that all was well.  I don't recall if the modem was connected at the
time, however.

A side note for anyone having trouble connecting to AP mode with their
cell phone...  I've always had a lot of trouble with timeouts and such,
and finally tracked it down to a similar issue as above.  If the phone
has both an LTE and AP connection, the http request to 192.168.4.1 often
goes out over the LTE path, and is therefore doomed.  Disabling LTE
"fixes" that, but of course, also disables your phone.(or at least the
data part).  I haven't found a good way to beat some (routing) sense
into the phone otherwise.

This was with my new Google Pixel2, so it's not a matter of an old buggy
device.  (Ok, so it's a new buggy device...)

Also, the first time you connect to the AP, the phone _blocks_ all
communications with it until you answer the annoying notification
(usually hidden in the background) that says "Hey, we can't get to the
Internet with that AP.  Are you sure you want to stay connected to it?",
or words to that effect.  Me thinks they have taken this always
connected Internet meme a bit too far.

Greg

_______________________________________________
OvmsDev mailing list
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

_______________________________________________
OvmsDev mailing list
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 
_______________________________________________
OvmsDev mailing list
OvmsDev at lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180418/60f9b612/attachment.htm>