[Ovmsdev] Merging in Twizy and Volt/Ampera work

Michael Balzer dexter at expeedo.de
Mon Nov 19 01:55:01 HKT 2012


Fixed: was a ROM/RAM thing.

Not really looking like good code now though:

               {
                 char cmd[5];
                 strcpypgm2ram(cmd, "STAT");
                 net_sms_in(p, cmd, 4);
               }

Maybe there's a common better way for this? If we need more internal 
commands to be routed through the dispatcher, a net_sms_in_rom() 
function could make it nice again.

Regards,
Michael

PS: the first bug fix (previous commit) still makes sense.


Am 18.11.2012 16:56, schrieb Michael Balzer:
> One bug just turned up: I have my module send both SMS and IP alerts. 
> On charge end, the IP stat alert was correct, but the SMS alert was 
> also delivered to my App, and displays as "SMS FROM: <nr> - MSG: 
> <random_char_garbage>.
>
> Regards,
> Michael
>
>
> Am 18.11.2012 14:14, schrieb Michael Balzer:
>> 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
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/d6aac899/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/d6aac899/attachment-0002.vcf>


More information about the OvmsDev mailing list