[Ovmsdev] Merging in Twizy and Volt/Ampera work

Michael Balzer dexter at expeedo.de
Sun Nov 18 04:38:00 HKT 2012


Mark,

I ported my STAT changes to the new framework and tried to prepare it 
for my first specific commands as well:

https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6

Haven't tested yet, but the vehicle / framework distinction becomes very 
clean now I think.

Regarding hooking in the vehicle cmdtable: I now think that was 
nonsense, as the vehicle dispatcher will need to parse the command 
itself. I'll wait for your thoughts on if/how to integrate the common 
auth stuff with this.

To get internal net_sms_stat() calls to use the overloaded function, I 
suggest to inject the call through the SMS dispatcher as shown in my 
commit. There's only one call outside net_sms, and that's not time 
critical and using fixed (no) arguments. I also think STAT is the only 
SMS we need to route like this (?)

Regards,
Michael


Am 17.11.2012 19:20, schrieb Michael Balzer:
> Mark,
>
> man, you're fast! :-)
>
> ...ok, that looks good for extending and replacing existing SMS commands.
>
> Next step will be to split the command table in standard + vehicle 
> commands. That could be done by simply calling vehicle_fn_smshandler() 
> before checking the standard cmdtable and leave everything else to the 
> vehicle module, but I like the concept of net_sms_in() doing the 
> common caller authentication for all commands.
>
> I assume you intend to use this for the vehicle commands as well? So 
> the vehicle module will hook in a specific cmdtable+hfntable to be 
> used by net_sms_in()?
>
> Thinking about auth... maybe I'm missing something, but why is there a 
> need for the three auth modes? Couldn't it just be mode 3 for every 
> command?
>
> Regards,
> Michael
>
>
> Am 17.11.2012 16:03, schrieb Mark Webb-Johnson:
>>>> I'll also port my specific STAT? version to the new framework ASAP.
>>> This is a little more involved. I need to re-work the SMS framework 
>>> to hook in to the vehicle modules nicely, and that will require 
>>> quite a bit o structural rework. Let me handle this - I'll get it 
>>> done in the next hour or two.
>> I've done the structural work for this, and committed to github.
>>
>> There is now a vehicle module hook for SMS commands, that are run 
>> pre-command (allowing a vehicle module to completely override an SMS 
>> command), and post-command (allowing a vehicle module to add stuff 
>> onto the end of an standard sms command).
>>
>> I haven't re-worked Michael's Twizy STAT extensions, yet, but the 
>> hooks are now there.
>>
>> The changes were quite drastic, and I've probably broken a lot. It 
>> builds, but completely untested. I just wanted to get it in so you 
>> could have a look at it.
>>
>> I'll test it tomorrow, and fix as necessary.
>>
>> Regards, Mark.
>>
>> On 17 Nov, 2012, at 9:24 PM, Mark Webb-Johnson 
>> <mark at webb-johnson.net> wrote:
>>
>>>> I will look into integrating the internal GPS flag so we don't need 
>>>> a compiler switch for this as well. Does it make sense to couple 
>>>> this to the car type or could someone with a GPS equipped car have 
>>>> some reason to occasionally use the OVMS GPS instead?
>>> Its ok. I've handled this. Just add a bitmap flag set to net.h/net.c 
>>> and controlled it by that. It defaults to OFF (in vehicle.c 
>>> initialisation), and the none, obdii, Volt/Ampera and Twizy modules 
>>> enable it.
>>>
>>>> I'll also port my specific STAT? version to the new framework ASAP.
>>> This is a little more involved. I need to re-work the SMS framework 
>>> to hook in to the vehicle modules nicely, and that will require 
>>> quite a bit o structural rework. Let me handle this - I'll get it 
>>> done in the next hour or two.
>>>
>>>> I have one concern for the overlaying of the vehicle RAM sections:
>>> I'll have to think about this and have a look at how it is 
>>> initialised at the moment. My guess is we're linking to the c 
>>> library version that wipes all user ram to zero on reboot.
>>>
>>> Regards, Mark.
>>>
>>> On 17 Nov, 2012, at 3:52 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>
>>>> Mark,
>>>>
>>>> I followed your branch naming, "v2" on my repository adds my latest 
>>>> Twizy changes to the new framework.
>>>>
>>>> Stunningly, V2 worked out of the box :-) Great job!
>>>>
>>>> I will look into integrating the internal GPS flag so we don't need 
>>>> a compiler switch for this as well. Does it make sense to couple 
>>>> this to the car type or could someone with a GPS equipped car have 
>>>> some reason to occasionally use the OVMS GPS instead?
>>>>
>>>> I'll also port my specific STAT? version to the new framework ASAP.
>>>>
>>>> I have one concern for the overlaying of the vehicle RAM sections: 
>>>> I now changed most of my state variables to uninitialized to harden 
>>>> against crash resets (we've got SRAM after all). That works quite 
>>>> well with the old framework. I had no reset with V2 up to now -- my 
>>>> concern is, that an initialized overlay from another vehicle will 
>>>> initialize my variables as well. As all vehicle modules exist side 
>>>> by side now, can we introduce two data sections, one explicitly 
>>>> being uninitialized? #pragma idata seems to be meant for something 
>>>> like that, but everything's now in udata, even initialized vars...
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 15.11.2012 14:52, schrieb Mark Webb-Johnson:
>>>>> I've just committed another night's work on this. Looks good and 
>>>>> now runs on actual hardware.
>>>>>
>>>>> I've extended the MODULE and MODULE? SMS commands with a fourth 
>>>>> parameter - the car type - to allow this to be set. Also SMS 
>>>>> VERSION now shows the car type being used.
>>>>>
>>>>> I've ported the SMS commands over to the new vehicle module 
>>>>> framework, and they look good.
>>>>>
>>>>> I've bumped the version to 2.1.1, to reflect the major 
>>>>> restructuring that this is.
>>>>>
>>>>> This will still only run on v2 hardware at present. No reason we 
>>>>> can't support v1 (and will) - just need to tidy up the build 
>>>>> configurations.
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>> On 14 Nov, 2012, at 10:57 PM, Mark Webb-Johnson 
>>>>> <mark at webb-johnson.net> wrote:
>>>>>
>>>>>> I've just committed my work-in-progress for this to the github v2 
>>>>>> branch.
>>>>>>
>>>>>> Best I can say about it is that it compiles and links without error.
>>>>>>
>>>>>> It would be a miracle if it actually ran. I doubt it. I haven't 
>>>>>> had a chance to test it on real hardware yet.
>>>>>>
>>>>>> The framework for multiple cars is there, and seems to work ok. I 
>>>>>> can't get the overlay data section working (yet) - it is there 
>>>>>> but doesn't seem to be overlaying the different vehicle data and 
>>>>>> saving ram like it should. I re-worked the 100 byte 
>>>>>> net_msg_cmd_msg to be a pointer, saving a lot of ram but possibly 
>>>>>> breaking more advanced commands like "AT", "MMI/USSD" and "SMS" - 
>>>>>> I'll test them when I get a chance to run this on real hardware.
>>>>>>
>>>>>> I followed Michael B's suggestion for the net_msg_cmd handlers, 
>>>>>> and the hooks in general. So far, the can hooks are there, as 
>>>>>> well as the re-work of the net_msg_cmd stuff to hook through to 
>>>>>> the vehicle. I haven't had a chance to remove some of the old 
>>>>>> stub functions yet.
>>>>>>
>>>>>> The overall approach is that I've moved the old common can code 
>>>>>> to vehicle.h and vehicle.c. This defines a series of hooks, for 
>>>>>> vehicle initialisation. When the system starts up, a 
>>>>>> PARAM_VEHICLETYPE is now used to define the type of vehicle, and 
>>>>>> initialise that one vehicle module. During initialisation, the 
>>>>>> vehicle module hooks itself in to other functions it requires. If 
>>>>>> it doesn't hook in, the function is handled by the default 
>>>>>> handler. Once this part is working well, I intend to add hooks 
>>>>>> for SMS messages as well.
>>>>>>
>>>>>> To create a new vehicle, we would need to create a vehicle_* 
>>>>>> module, add the #define for it, and change vehicle.c 
>>>>>> initialisation to detect the vehicle type and initialise the 
>>>>>> module. It would be nice to have a better plugin architecture for 
>>>>>> this, but we're (a) limited by c (not c++), and (b) any such 
>>>>>> architecture would need ram space which is at a premium compared 
>>>>>> to rom.
>>>>>>
>>>>>> I've still got a bit of work to go to tidy this up, but as it is 
>>>>>> now the vehicle modules certainly look neater and have a lot less 
>>>>>> stub functions. The current approach now lets arbitrary commands 
>>>>>> make it through the the individual vehicle modules for action - 
>>>>>> which will provide amazing opportunities for expansion, as well 
>>>>>> as avoiding having stub functions in the Twizy module for locking 
>>>>>> and unlocking the non-existent doors.
>>>>>>
>>>>>> Feel free to have a look at the code, and let me know what you 
>>>>>> think and if there is anything obviously wrong.
>>>>>>
>>>>>> Regards, Mark.
>>>>>>
>>>>>> On 13 Nov, 2012, at 11:37 PM, Mark Webb-Johnson 
>>>>>> <mark at webb-johnson.net> wrote:
>>>>>>
>>>>>>> I've got the framework for this 70% done. So far, it builds and 
>>>>>>> looks good. Code size for experimental v2 branch has gone from 
>>>>>>> 50% of flash to 55% - including all vehicle modules for tesla 
>>>>>>> roadster, twizy, volt/ampera, basic odbii and a null vehicle 
>>>>>>> stub. RAM has gone up about 30 bytes, but that is part of the 
>>>>>>> 30% not yet done.
>>>>>>>
>>>>>>> I've merged in all Michael B's recent changes (including stuff 
>>>>>>> that may need to be looked at in light of this re-work).
>>>>>>>
>>>>>>> I'm going to do one more night on it, then commit what I have to 
>>>>>>> the v2 branch for others to look at.
>>>>>>>
>>>>>>> Regards, Mark.
>>>>>>>
>>>>>>> On 11 Nov, 2012, at 10:13 PM, Mark Webb-Johnson 
>>>>>>> <mark at webb-johnson.net> wrote:
>>>>>>>
>>>>>>>> I think the general approach here is correct.
>>>>>>>>
>>>>>>>> It is a fine line between allowing the vehicle modules to do 
>>>>>>>> more, and duplicating common functionality in each module. But, 
>>>>>>>> your suggestion to implement the core functions centrally, then 
>>>>>>>> allow the vehicle modules to either override or extend those 
>>>>>>>> core functions, is a good solution. It can also be extended to 
>>>>>>>> SMS messages.
>>>>>>>>
>>>>>>>> I'm not sure about using command/response ("C", "c") to allow 
>>>>>>>> the Apps to query the module capabilities. Those are quite 
>>>>>>>> expensive for the Apps to issue: App->Server->Car->Server->App 
>>>>>>>> latency can be 1, 2 or more seconds over GPRS - doing that each 
>>>>>>>> time the App starts up is going to be expensive. We can do this 
>>>>>>>> just as easily by a published message type giving the 
>>>>>>>> capabilities of the car - and that message could be issued just 
>>>>>>>> once on module startup (with the application receiving a copy 
>>>>>>>> each time it connected to the server).
>>>>>>>>
>>>>>>>> This also fits in with my email a while ago about restructuring 
>>>>>>>> to include a single firmware with multiple vehicle modules 
>>>>>>>> switchable at runtime. I'm very interested in getting a generic 
>>>>>>>> ODBII module working as well (which could show speed, fuel tank 
>>>>>>>> pressure, ODBII fault codes, etc).
>>>>>>>>
>>>>>>>> We need to maintain the stability of the v1 system, as we have 
>>>>>>>> so many users using it at the moment. So, what I've just done 
>>>>>>>> is commit the last major change to v1 code - I've update the 
>>>>>>>> protocol manual formatting to make it clearer - and created two 
>>>>>>>> new branches ("v1" and "v2). Let's work in the "v2" branch to 
>>>>>>>> create a single unified firmware supporting Roadster, Twizy, 
>>>>>>>> Volt and generic ODBII on v2 hardware. For v1 hardware users 
>>>>>>>> (Roadster), we can always back-port new features as necessary.
>>>>>>>>
>>>>>>>> I can work on this now, so give me a few days to try to build 
>>>>>>>> the framework for this re-structure.
>>>>>>>>
>>>>>>>> Regards, Mark.
>>>>>>>>
>>>>>>>> On 10 Nov, 2012, at 10:10 PM, Michael Balzer 
>>>>>>>> <dexter at expeedo.de> wrote:
>>>>>>>>
>>>>>>>>> Am 04.11.2012 14:21, schrieb Mark Webb-Johnson:
>>>>>>>>>> For major new feature specific to a particular vehicle, I was 
>>>>>>>>>> hoping we can handle those by the command protocol. We could, 
>>>>>>>>>> for instance, route commands 100-200 directly through to the 
>>>>>>>>>> vehicle modules for response. We could also add hooks for the 
>>>>>>>>>> vehicle modules to directly transmit messages out (the 
>>>>>>>>>> protocol itself is extensible and new message types can be 
>>>>>>>>>> easily added).
>>>>>>>>> Mark, List,
>>>>>>>>>
>>>>>>>>> for the Twizy, it's not so much about extending but about 
>>>>>>>>> reducing, as many current standard commands do not make sense 
>>>>>>>>> on the Twizy. Some could also use slightly different 
>>>>>>>>> implementations (STAT SMS as seen).
>>>>>>>>>
>>>>>>>>> I've thought about that last night and had fun reading into 
>>>>>>>>> the net code. Cool stuff. I stumbled about a very simple way 
>>>>>>>>> to not only enable routing of special commands to the car, but 
>>>>>>>>> to also enable overloading of builtin commands. Seems you had 
>>>>>>>>> something like that already in mind when writing that code :-)
>>>>>>>>>
>>>>>>>>> So the system net modules could implement just the common 
>>>>>>>>> standard commands while the car modules would dynamically 
>>>>>>>>> extend those with just their specific commands. Using a 
>>>>>>>>> message passing scheme to mimic an OO sub class approach, a 
>>>>>>>>> car module will be able to...
>>>>>>>>> - either leave a command handling to the system
>>>>>>>>> - or use and extend the system handling
>>>>>>>>> - or completely implement a command itself, possibly replacing 
>>>>>>>>> a system handler.
>>>>>>>>>
>>>>>>>>> Current car specific hook calls like can_tx_setchargemode() 
>>>>>>>>> can then be removed from the common net framework.
>>>>>>>>>
>>>>>>>>> To configure themselves accordingly, servers and apps may want 
>>>>>>>>> to know the type and version of the car module, and a list of 
>>>>>>>>> the commands supported by the firmware. To enable this, I 
>>>>>>>>> would introduce two new msg commands:
>>>>>>>>>
>>>>>>>>> - 6 = car module type + version
>>>>>>>>> => reply scheme: "MP-0 
>>>>>>>>> c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>"
>>>>>>>>>
>>>>>>>>> - 7 = list of commands supported
>>>>>>>>> => reply scheme: "MP-0 
>>>>>>>>> c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..."
>>>>>>>>> More than one list of each class can be sent, clients should 
>>>>>>>>> collect and join all.
>>>>>>>>> I think IDs are sufficient, otherwise the reply scheme could 
>>>>>>>>> be extended.
>>>>>>>>>
>>>>>>>>> Maybe a third one will make sense for the...
>>>>>>>>>
>>>>>>>>> - 8 = list of car data properties supported
>>>>>>>>> => reply scheme: "MP-0 c8,0,..." (todo? can make life easier 
>>>>>>>>> for the App)
>>>>>>>>>
>>>>>>>>> Due to the structural beauty of the net code, this extension 
>>>>>>>>> should be quite easy to implement. Please take a look at my 
>>>>>>>>> implementation draft below and give me some feedback. The SMS 
>>>>>>>>> part should be able to use the same approach.
>>>>>>>>>
>>>>>>>>> AFAIS this extension would require no immediate change to the 
>>>>>>>>> existing server and apps, it just offers an opportunity for 
>>>>>>>>> the next releases.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // ------------------- net_msg module ----------------------
>>>>>>>>>
>>>>>>>>> // REPLACE:
>>>>>>>>> void net_msg_cmd_do(void)
>>>>>>>>> {
>>>>>>>>> /****************************************************************
>>>>>>>>> * MSG COMMAND DISPATCHER
>>>>>>>>> *   Called by: net_msg_cmd_in() & net_state_ticker1()
>>>>>>>>> *
>>>>>>>>> * GLOBAL PARAMS:
>>>>>>>>> *   net_msg_cmd_code = int command id
>>>>>>>>> *   net_msg_cmd_msg = char * to first parameter
>>>>>>>>> */
>>>>>>>>>
>>>>>>>>> delay100(2);
>>>>>>>>>
>>>>>>>>> // commands 40-49 are special AT commands, thus, disable 
>>>>>>>>> net_msg here
>>>>>>>>> if ((net_msg_cmd_code < 40) || (net_msg_cmd_code > 49))
>>>>>>>>>     net_msg_start();
>>>>>>>>>
>>>>>>>>> // Execute cmd: ask car module to execute first:
>>>>>>>>> if( !car_msg_cmd_exec() )
>>>>>>>>> {
>>>>>>>>>     // Car module does not feel responsible, fall back to 
>>>>>>>>> standard:
>>>>>>>>>     if( !net_msg_cmd_exec() )
>>>>>>>>>     {
>>>>>>>>>         // No standard as well => return "unimplemented"
>>>>>>>>>         sprintf(net_scratchpad, (rom far char*)"MP-0 
>>>>>>>>> c%d,3",net_msg_cmd_code);
>>>>>>>>>         net_msg_encode_puts();
>>>>>>>>>     }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> // terminate IPSEND by Ctrl-Z (should this be disabled for 
>>>>>>>>> commands 40-49 as well?)
>>>>>>>>> net_msg_send();
>>>>>>>>>
>>>>>>>>> // clear command
>>>>>>>>> net_msg_cmd_code = 0;
>>>>>>>>> net_msg_cmd_msg[0] = 0;
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // ADD:
>>>>>>>>> bool net_msg_cmd_exec(void)
>>>>>>>>> {
>>>>>>>>> /****************************************************************
>>>>>>>>> * IMPLEMENTATION OF STANDARD MSG COMMANDS
>>>>>>>>> *   Called by: net_msg_cmd_do() & car specific cmd handlers
>>>>>>>>> *
>>>>>>>>> * GLOBAL PARAMS:
>>>>>>>>> *   net_msg_cmd_code = int command id
>>>>>>>>> *   net_msg_cmd_msg = char * to first parameter
>>>>>>>>> *
>>>>>>>>> * RETURNS:
>>>>>>>>> *   true if cmd has been handled
>>>>>>>>> */
>>>>>>>>>
>>>>>>>>> int k;
>>>>>>>>> char *p;
>>>>>>>>>
>>>>>>>>> switch (net_msg_cmd_code)
>>>>>>>>> {
>>>>>>>>>     // ...std cmds 1-5 to be inserted here if compiler does no 
>>>>>>>>> jump table optimization...
>>>>>>>>>
>>>>>>>>>     case 7:
>>>>>>>>>         // List commands supported (for peer configuration):
>>>>>>>>>         // standard commands:
>>>>>>>>>         sprintf( net_scratchpad, (rom far char*)"MP-0 
>>>>>>>>> c7,0,STD,1,2,3,4,5,40,41,49" );
>>>>>>>>>         net_msg_encode_puts();
>>>>>>>>>         // (can be extended if clients need more than the cmd 
>>>>>>>>> ids)
>>>>>>>>>         return true;
>>>>>>>>>
>>>>>>>>>     // ...std cmds to be inserted here...
>>>>>>>>>
>>>>>>>>>     default:
>>>>>>>>>         // unhandled cmd_code:
>>>>>>>>>         return false;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> // ------------------- can_<model> or maybe separate 
>>>>>>>>> car_<model> module ----------------------
>>>>>>>>>
>>>>>>>>> // ADD:
>>>>>>>>> bool car_msg_cmd_exec(void)
>>>>>>>>> {
>>>>>>>>> /****************************************************************
>>>>>>>>> * HOOK to integrate CAR SPECIFIC MSG command handlers
>>>>>>>>> *   May overlay and/or extend the standard command set
>>>>>>>>> *   Called by: net_msg_cmd_do()
>>>>>>>>> *
>>>>>>>>> * GLOBAL PARAMS:
>>>>>>>>> *   net_msg_cmd_code = int command id
>>>>>>>>> *   net_msg_cmd_msg = char * to first parameter
>>>>>>>>> *
>>>>>>>>> * RETURNS:
>>>>>>>>> *   true : cmd has been handled completely
>>>>>>>>> *   false: fallback to net_msg_cmd_exec()
>>>>>>>>> *
>>>>>>>>> * OUTPUT SCHEME:
>>>>>>>>> *   sprintf(net_scratchpad, (rom far char*)"MP-...");
>>>>>>>>> *   net_msg_encode_puts();
>>>>>>>>> *
>>>>>>>>> * CALL SPECIFIC STANDARD FUNCTION n: (rare case)
>>>>>>>>> *   [save net_msg_cmd_* if needed later on]
>>>>>>>>> *   net_msg_cmd_code = n;
>>>>>>>>> *   strcpy( net_msg_cmd_msg, "arg1,arg2,..." );
>>>>>>>>> *   if( net_msg_cmd_exec() ) {...success...}
>>>>>>>>> *
>>>>>>>>> */
>>>>>>>>>
>>>>>>>>> /* Command dispatcher: */
>>>>>>>>> switch( net_msg_cmd_code )
>>>>>>>>> {
>>>>>>>>>     case 6:
>>>>>>>>>         // Echo CAR TYPE + MODULE VERSION:
>>>>>>>>>         sprintf( net_scratchpad, (rom far char*)"MP-0 
>>>>>>>>> c6,0,RT,Renault Twizy,1,2,0" );
>>>>>>>>>         net_msg_encode_puts();
>>>>>>>>>         return true;
>>>>>>>>>
>>>>>>>>>     case 7:
>>>>>>>>>         // List commands supported (for peer configuration):
>>>>>>>>>         // a) standard commands:
>>>>>>>>>         net_msg_cmd_exec();
>>>>>>>>>         // b) car specific commands / overloads:
>>>>>>>>>         sprintf( net_scratchpad, (rom far char*)"MP-0 
>>>>>>>>> c7,0,CAR,6,7,10" );
>>>>>>>>>         net_msg_encode_puts();
>>>>>>>>>         // (can be extended if clients need more than the cmd 
>>>>>>>>> ids)
>>>>>>>>>         return true;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /************************************************************
>>>>>>>>>      * CAR SPECIFIC COMMANDS
>>>>>>>>>      */
>>>>>>>>>
>>>>>>>>>     case 10:
>>>>>>>>>         // EXAMPLE FROM TESLA MODULE: Set charge mode (params: 
>>>>>>>>> 0=standard, 1=storage,3=range,4=performance)
>>>>>>>>>         if (sys_features[FEATURE_CANWRITE]==0)
>>>>>>>>>         {
>>>>>>>>>             sprintf(net_scratchpad, (rom far 
>>>>>>>>> char*)NET_MSG_NOCANWRITE,net_msg_cmd_code);
>>>>>>>>>         }
>>>>>>>>>         else
>>>>>>>>>         {
>>>>>>>>> can_tx_setchargemode(atoi(net_msg_cmd_msg));
>>>>>>>>>             sprintf(net_scratchpad, (rom far 
>>>>>>>>> char*)NET_MSG_OK,net_msg_cmd_code);
>>>>>>>>>         }
>>>>>>>>>         net_msg_encode_puts();
>>>>>>>>>         return true;
>>>>>>>>>
>>>>>>>>>     // ...more...
>>>>>>>>>
>>>>>>>>>     default:
>>>>>>>>>         // Not handled, fall back to standard:
>>>>>>>>>         return false;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>>>>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>>>>>>>
>>>>>>>>> <dexter.vcf>_______________________________________________
>>>>>>>>> OvmsDev mailing list
>>>>>>>>> OvmsDev at lists.teslaclub.hk
>>>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.teslaclub.hk
>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>> -- 
>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>>
>>>> <dexter.vcf>_______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121117/b1e6642b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121117/b1e6642b/attachment-0002.vcf>


More information about the OvmsDev mailing list