This a bit off-topic and a bit questionable, but I found interesting the comment about Node.js vs Go for the backend implementation:ato̧̕m̀͡i̴̷̛c̨͝t͝҉͡h̷҉u̵̶m͜͞b͏͝s̀́ on Twitter | | | | | | | | | | | ato̧̕m̀͡i̴̷̛c̨͝t͝҉͡h̷҉u̵̶m͜͞b͏͝s̀́ on Twitter “A former Tesla employee, who worked on their IT infrastructure, is posting in a subforum of a subforum, a littl... | | | On Monday, August 27, 2018, 2:53:52 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: 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