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