<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix"><a class="moz-txt-link-abbreviated" href="mailto:chip@cangmag.com">chip@cangmag.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:15c408946e4f641075ad904ca4e97e1f@cangmag.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Reference: Tesla Roadster 2.0 Sport</p>
<p>OVMS Firmware— Server: 2.1.1-20121216 Car: 3.1.004/ota_0/main
App: 1.6.6 (20150821)</p>
<p>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]. </p>
<p>Successfully operating: Remote door lock and unlock, remote
Homelink, remotely change charging mode [Standard, Storage,
Range].</p>
<p>Today, for the first time, and while <span
style="text-decoration: underline;">communicating over the
cellular modem</span>, 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.</p>
<p>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).</p>
<p>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.</p>
<p>Chip C.</p>
<p><br>
</p>
<div> </div>
<p><br>
</p>
<p>On 2018-04-18 9:46 am, Greg D. wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->Michael
Balzer wrote:<br>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0">
<pre>Am 16.04.2018 um 22:16 schrieb Michael Balzer:
</pre>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0">
<pre>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.
</pre>
</blockquote>
<pre>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
</pre>
</blockquote>
<br>
Hi Michael,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...)<br>
<br>
Also, the first time you connect to the AP, the phone <em>blocks</em>
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.<br>
<br>
Greg<br>
<br>
<!-- html ignored --><br>
<div class="pre" style="margin: 0; padding: 0; font-family:
monospace">_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
rel="noreferrer" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" rel="noreferrer" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a></div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>