The new proposal sounds like a good idea
(in spite of putting OBD2ECU at the bottom
{sniff} ). If we someday get the ability
to configure the module from the Modem,
would it be a good idea to move SIMCOM up
in the priority chain, to allow for remote
repair if either of the servers is causing
the trouble? The V2 server has been
pretty stable for a long time, but I
wonder about V3.
Curious why you put External 12v above
OBD2ECU. I'd move 12v to the bottom, so
you don't turn on the external device
until the server is running. What else is
dependent on the external 12v supply?
Greg
Last week’s 3.1.009 issue with Tesla
Roadsters was interesting. Looking at
the car I saw with the problem, it was
booting, crashing when the vehicle
module received a certain CAN bus
message (triggering the issue), and
rebooting. It would do this 5 times,
until it his
the AUTO_INIT_INHIBIT_CRASHCOUNT count,
and then AutoInit inhibit would kick in,
and it would end up sitting idle with
nothing loaded (and no network
connection). The approach worked very
well, and prevented an endless reboot
loop.
However, we ended up
with a car unable to connect to the
network, and requiring a console
cable and laptop to recover. I’ve
been thinking about bluetooth (which
is intended to provide a smartphone
connection irrespective of wifi
configuration), how that might work
with a completely unconfigured
module (for initial configuration),
and I can suggest a workaround to
try to improve this…
At the moment, the order
of autoinit is:
- External 12V
- Wifi
- Modem SIMCOM
- Vehicle
- OBD2ECU
- Server V2
- Server V3
None of those run if the
early crash count >
AUTO_INIT_INHIBIT_CRASHCOUNT (coded as
a constant 5).
My suggestion is to change
this as follows:
- Wifi
- Bluetooth
- Server V2
- Server V3
- Modem SIMCOM
- External 12V
- Vehicle
- ODB2ECU
But also to change that
logic that:
- #8 will start if early
crash count >
AUTO_INIT_INHIBIT_CRASHCOUNT
- #7 will start if early
crash count >
AUTO_INIT_INHIBIT_CRASHCOUNT+1
- #6 will start if early
crash count >
AUTO_INIT_INHIBIT_CRASHCOUNT+2
- etc.
This will mean that once
we hit the
AUTO_INIT_INHIBIT_CRASHCOUNT limit, we
turn off the least required module
(OBD2ECU), then continue to see if
that solves the problem. If not (ie;
we crash and reboot), then we try
turning off the Vehicle module and
OBD2ECU, then continue to see if that
solves the problem. etc.
In the example case of the
Tesla Roadster vehicle module causing
the issue, this revised approach would
leave us up and running with Wifi and
a Server Connection (but no vehicle
data). Checking the module would
identify the problem quite quickly
(and remotely). Starting the vehicle
module manually would presumably
result in a crash and we would pretty
quickly get an idea of the cause
(especially if we added a command to
show the status of AutoInit, what was
started, and what wasn’t because it is
causing a crash). I think we could
even issue an Alert notification in
the case where autoinit recovered
after inhibiting certain modules (but
not all).
The disadvantage is that
we would crash more (up to 13 times,
vs 5) in the case the system is badly
messed up.
What do people think? Does
this make sense?
Regards, Mark.
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev