[Ovmsdev] Merging in Twizy and Volt/Ampera work

[Michael Balzer]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121118/f55361bb/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/f55361bb/attachment-0002.vcf>