[Ovmsdev] Merging in Twizy and Volt/Ampera work

Sun Nov 18 21:14:58 HKT 2012

Mark,

merged & checked & flashed & works :-)

Regards,
Michael


Am 18.11.2012 13:38, schrieb Mark Webb-Johnson:
> Michael,
>
> I've just pushed my last set of changes. It seems ok from my end now. 
> The code runs and sms commands function as expected. I've added a 
> capabilities message that is sent car->server->apps and will be useful 
> to tailor the app functions to what the car can do.
>
> Can you merge mine in with yours, and check if it all looks ok to you?
>
> I'm now going to flash this firmware into my car to see how it behaves.
>
> Regards, Mark.
>
> On 18 Nov, 2012, at 8:11 PM, Michael Balzer <dexter at expeedo.de 
> <mailto:dexter at expeedo.de>> wrote:
>
>> Mark,
>>
>> I reworked my command dispatcher according to the new hook:
>>
>> https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/ca453ca07714ec43bc884e9598d781a0e2af4f3f
>>
>> ...it works, but I'm not totally happy with it. To me it looks like 
>> there should be no need for two hooks. Basically the only difference 
>> between them now is, if the vehicle handler has to do the auth check 
>> or not. So I internally already use one dispatcher and a control 
>> parameter for this. If it needs to do the auth check, I use the same 
>> mode control scheme like you do. Please have a look at it, maybe we 
>> can reduce this to one hook.
>>
>> My STAT command drops the charge mode (the Twizy does not have this) 
>> and inserts SOC min+max after current SOC, so that's a replacement 
>> case. But I added another command handler that's clearly an extension 
>> (HELP), and with my new specific DEBUG command we now have all three 
>> cases, and all work as designed (at least in diag mode, have to test 
>> live mode yet).
>>
>> Regards,
>> Michael
>>
>>
>> Am 18.11.2012 09:49, schrieb Mark Webb-Johnson:
>>> Michael,
>>>
>>> I think there is a confusion around the use of vehicle_fn_smshandler 
>>> - that is to override (premsg) or extend (!premsg) an existing SMS 
>>> command. I hadn't thought about the vehicle module wanting its own 
>>> SMS messages.
>>>
>>> We can do this in two ways: (1) expose a vehicle sms handler table 
>>> to the net_sms code and have it look there, or (2) just hook in to 
>>> the vehicle and let it handle sms messages itself. For the moment, 
>>> I've chosen (2) as I think there will be relatively few 
>>> vehicle-specific sms messages. The old way we did this was just 
>>> 'strcmp' for each possible SMS commands. If there are not too many, 
>>> that is fine and probably more efficient than having a dispatch 
>>> table. Anyway, I've added a vehicle_fn_smsextensions now, which is 
>>> called if the incoming sms is not recognised by net_sms and allows 
>>> the vehicle to look.
>>>
>>> Michael B: can you try to migrate your Twizy code to this 
>>> new vehicle_fn_smsextensions framework for Twizy-specific sms 
>>> messages, and vehicle_fn_smshandler for the extension to the STAT 
>>> command? Regarding your vehicle_twizy_sms_handle_stat() function, is 
>>> it not possible to just extend (add a couple of lines) the SMS 
>>> reply, rather than replace the entire command?
>>>
>>> I also tested the new net_sms arrangement, found a few bugs, and 
>>> fixed them. Code is on github now.
>>>
>>> I'm now looking at implementing a registration mechanism so that the 
>>> vehicle modules can register the commands they implement, as well as 
>>> other parameters for what they support, and we can push this in 
>>> net_msg when we connect to the server.
>>>
>>> Regards, Mark.
>>>
>>> On 18 Nov, 2012, at 4:38 AM, Michael Balzer <dexter at expeedo.de 
>>> <mailto:dexter at expeedo.de>> wrote:
>>>
>>>> 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
>>>>
>>
>> -- 
>> 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 <mailto: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/20121118/040ac7d5/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/20121118/040ac7d5/attachment-0002.vcf>