[Ovmsdev] Auto start/init (was Re: Crash / reboot loop with log level Info)

Mon Mar 5 09:18:31 HKT 2018

> The auto init settings that Michael implemented are for when you plug the module in, so I'm thinking it would probably be good to turn the ext12v on so you can see the HUD device come alive.  Key on then off would put the HUD to sleep with the scripts, completing the product installation checkout.  This is what I had in my system.start script, which has been replaced by the auto init process.

The problem would be that would also happen if module was rebooted.

I think it is fine if the ‘auto’ control only copes with the basic use cases. Anything more sophisticated, and it should be turned off and manual scripts used.

Simplest ‘auto’ solution is to turn on and off, with the car.

Regards, Mark

> On 4 Mar 2018, at 1:11 PM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> Right.  Forgot I have 1-line event scripts for vehicle.on and vehicle.off to do the runtime control of ext12v.  This works very well with a HUD-type device, but not so much if you're driving the SyncUp Drive dongle (Wifi hotspot), as you would want it on when the car is awake but not on, e.g. while charging.  I have not figured out a good algorithm for the dongle, as not all of the useful triggers appear to be connected.  vehicle.asleep isn't for the Roadster, for example, so it never turns off.  This means that there's no way to implement an automatic ext12v power control.  The best solution may be hardware (electrical) instead of software, by driving the 12v into the OBDII connector from the 12v accessory port instead of from the OBMS module, as on the Roadster it's on whenever the car is awake (including charging).  The OVMS module would remain powered from the diagnostic connector, which has 12v on continuously.
> 
> The auto init settings that Michael implemented are for when you plug the module in, so I'm thinking it would probably be good to turn the ext12v on so you can see the HUD device come alive.  Key on then off would put the HUD to sleep with the scripts, completing the product installation checkout.  This is what I had in my system.start script, which has been replaced by the auto init process.
> 
> Greg
> 
> 
> 
> 
> Mark Webb-Johnson wrote:
>> For the ext12v auto, I suggest it would be best to control this from the CarOn metric (v.e.on). Turn on ext12v when the car is switched on, and turn it off when the car is switched off.
>> 
>> Regards, Mark.
>> 
>>> On 4 Mar 2018, at 11:47 AM, Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>> wrote:
>>> 
>>> Hi Michael,
>>> 
>>> Looks good!  
>>> 
>>> The order for starting the obdii ecu task and the vehicle it draws data from isn't critical; nothing bad will happen if by some chance the OBDII device starts requesting information before the vehicle task makes it available.  I suppose, the "most correct" sequence would start the vehicle task, then the obdii ecu task, then enable the ext12v power last, but in practice and by design there is no issue with starting any of them in pretty much any order.  Worst case, the device it would get zeros if it wins the race, but I catch those internally and prevent the apparent lack of a running ICE engine from causing the device to shut down by supplying dummy information.
>>> 
>>> The only thing missing in the web server, I suppose, would be a way to customize the PID-to-Metric mapping.  I supply a default for the most common ones, but there are many more possible if you are using, say, an ELM 327 dongle with Torque-like application.  Changing the mapping is easily done through the shell (unless you want to tackle that with the web server too).  'config set obd2ecu.map <pid> <metric>' to set the mapping, and 'obdii ecu list' to display the mapping and current values.
>>> 
>>> Thanks for doing this!
>>> 
>>> Greg
>>> 
>>> 
>>> Michael Balzer wrote:
>>>> Greg,
>>>> 
>>>> I've just added ext12v and obd2ecu to the auto init system & web config.
>>>> 
>>>> So except for the metric set command, you should now be able to start your module without a script.
>>>> 
>>>> The autostart sequence is slightly different from yours, the obd2ecu init is done after the vehicle module init, as I see the vehicle module as the data provider for the obd2ecu module -- correct me if I'm wrong.
>>>> 
>>>> Can you please verify the start sequence is working as expected?
>>>> 
>>>> Regards,
>>>> Michael
>>>> 
>>>> 
>>>> Am 25.02.2018 um 22:08 schrieb Greg D.:
>>>>> 
>>>>> Here's my system.start event file:
>>>>> OVMS > vfs cat /store/events/system.start/mystartup
>>>>> obdii ecu start can3
>>>>> power ext12v on
>>>>> wifi mode client gregnet3
>>>>> # power simcom on
>>>>> vehicle module TR
>>>>> server v2 start
>>>>> metric set v.b.soc 55
>>>>> OVMS > 
>>>>> (Before you ask, the setting of the soc metric is so that I can see the server is actually talking to the module, when the module's on the bench.)
>>>> 
>>>> -- 
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180305/abe22612/attachment.htm>