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?
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