Mark,

I did some debugging but I did not find the bug yet -- if it is one. I now assume it's because the module had to reset the gprs connection due to my weak connectivity situation, just when I had requested the SMS. So the "AT+CIPSHUT" from the net state change just happened to get into the SMS. Does that make sense?

My debug session resulted in some more changes, pls have a look:

https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/9eaa71c1e6ccae21cf9dcfe8fd8a4e22666830ba

The extension of the diag mode to call MSG commands as well was an attempt to produce the bug, but I find it also quite useful for other debugs and for pre-provisioning the module. That also led to the can_capabilities type change.

I'm currently charging my Twizy to see if the alert is functional now.

Regards,
Michael

Am 19.11.2012 22:08, schrieb Michael Balzer:

My test just showed I've implemented a bug as well ;-): I now occasionally get SMS replies containing "AT+CIPSHUT" instead of the last character of the message, so somehow the buffers seem to get confused.

It's late, I'll debug tomorrow.

Regards,
Michael

Am 19.11.2012 20:52, schrieb Michael Balzer:
Mark,

I've implemented it, please review:

https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/70b770fff2268c84100a0bef30965f1c0cd58106

I have included the necessary changes to the framework, as there are few.

As both charge alerts are the same now I could also factor out the text preparation, saving some ROM space. I intend to reuse the other command functions as well, if the parameters can use the same syntax I can just switch the argument separator char.

Regards,
Michael

Am 19.11.2012 19:40, schrieb Michael Balzer:
Mark,

Am 19.11.2012 14:34, schrieb Mark Webb-Johnson:

...plus a new common code for "ALERT", if you agree on routing the net_msg_alert() function through the dispatcher as well to allow vehicle control over this.

Can you explain more what you require here?

I would like to change the text for charge alerts to the App the same way I did with the SMS alerts, especially to get the SOC min/max and odometer.

So I would basically overload net_msg_alert() with my vehicle specific version. That will require either a specific hook for just this function, or -- my suggestion -- the introduction of a msg command "ALERT", so the existing cmd overloading framework can simply be used. I tend to the cmd solution because that's nice in line with the SMS way. I know the command now would not be needed by the Apps, but it wouldn't hurt either.

So instead of calling net_msg_alert() directly (which happens only at one place now), we would call net_msg_cmd_do() with i.e. net_msg_cmd_code=NET_CMD_ALERT and let the net and vehicle dispatchers decide which alert function to execute. May sound a bit complicated first, but would IMO also provide clean and clear extendability for maybe other future notifications sent from the module to the App.

I can prepare a Twizy implementation of this if you like to have a look at the application side first.

Regards,
Michael
_______________________________________________
OvmsDev mailing list
OvmsDev@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@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@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