[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.teslaclub.hk/pipermail/ovmsdev/attachments/20121118/d6aac899/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20121118/d6aac899/attachment.vcf>
More information about the OvmsDev
mailing list