<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael,<div><br></div><div>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.</div><div><br></div><div>Can you merge mine in with yours, and check if it all looks ok to you?</div><div><br></div><div>I'm now going to flash this firmware into my car to see how it behaves.</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 18 Nov, 2012, at 8:11 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Mark,<br>
<br>
I reworked my command dispatcher according to the new hook:<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/ca453ca07714ec43bc884e9598d781a0e2af4f3f">https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/ca453ca07714ec43bc884e9598d781a0e2af4f3f</a><br>
<br>
...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.<br>
<br>
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).<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 18.11.2012 09:49, schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote cite="mid:75818E41-1A24-4A10-BEBB-212AD57104E7@webb-johnson.net" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Michael,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>I also tested the new net_sms arrangement, found a few bugs,
and fixed them. Code is on github now.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
<div>
<div>On 18 Nov, 2012, at 4:38 AM, Michael Balzer <<a moz-do-not-send="true" href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> Mark,<br>
<br>
I ported my STAT changes to the new framework and tried to
prepare it for my first specific commands as well:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6">https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6</a><br>
<br>
Haven't tested yet, but the vehicle / framework
distinction becomes very clean now I think.<br>
<br>
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.<br>
<br>
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 (?)<br>
<br>
Regards,<br>
Michael<br>
<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</div>
<span><dexter.vcf></span>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>