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.
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