That wasn't me.

Whoops. Michael Jochum...

ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?

The Microchip compiler has an 'overlay' facility. We can put them in the same memory bank so they all overlay each other. You are correct - RAM is the concern.

So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.

I think the existing model should work for the EVs I've seen. There are some problems that will need to be fixed (e.g.; imperial-only units for ranges), and some extensions made (e.g.; 2 extra doors for saloon style cars), but those are pretty small.

For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added).

l (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled)

Yes, I've noticed that. From what I can see, it is just garbage tacked on the end but I've been meaning to convert this to a better document. We have full revision control on this.

The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support).

I think that stuff like this is going to be _very_ hard to fit in ram, but does it actually need to be stored? Say we have 16 can bus messages to send out. We could just use a 2byte bit array with a bit high indicating we need the figure. If the message arrives on the can bus, and the corresponding bit it high, it can get queued for transmission directly, then the bit cleared. I'm not sure if that is clear (hard to explain it in writing), but what I'm saying is have a mechanism for the can driver to be able to queue stuff for transmission directly from the incoming can message. So, rather than storing 16 messages for transmission, we don't need to store any - just have a flag to say 'transmit the values when it next comes off the bus'.

So, maybe the data and protocol models need to be generalized first?

I think it just needs to be documented better, and expanded as necessary. Let's then see how things fit into that. I'll work on this now, as both Michael's need this urgently.

Regards, Mark.

On 4 Nov, 2012, at 8:37 PM, Michael Balzer <dexter@expeedo.de> wrote:

Am 04.11.2012 04:11, schrieb Mark Webb-Johnson:

...

A while ago, Michael Balzer suggested to me that it would be best to have one firmware supporting all cars.

That wasn't me. The idea sounds good, but...

• car platforms to be supported will increase steadily now, there are lots to come in the next years
• even cars with decent builtin online monitoring systems lack some functionality for nerds like us
• there will be a need for custom product configuration per car anyway, as cabling and antenna configuration will be different

ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?

Also, not only the CAN module may need car specific adaption. I've not yet completely read into the server protocol (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled), but got the impression it contains some common and some Tesla specific data. If we have to integrate specific data from every model supported, the data stream can become quite fat. So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.

Example: one of my next ideas is a cell monitor to get a history of the cell voltage levels, so I can detect and alert about cell failures early. The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support). The Tesla has an 11S 9S 69P configuration (?), so that would need much more history RAM + possibly another data layout -- if the voltages are on CAN at all.

Another example I already stumbled on: the car_doors1 flag 0x04 (charge port open) is currently used by net_sms_stat(), if it's not set, it assumes "not charging". So even some standard functions rely on Tesla specific data.

So, maybe the data and protocol models need to be generalized first? Or am I missing something?

Regards, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Hi,

i ask in the german Ampera Forum about the SOC. The iPhone App shows minimum 21% to max. 87%. This is the usable Batterie window. Now they would have 0-100% in the App. As a "quick and dirty" fix i do this in the App: car_soc = ([[lparts objectAtIndex:0] intValue]-21)*(100.0/66.0); // 21 - 87% = 0 - 100% 1,515151515151515 MJ //car_soc = [[lparts objectAtIndex:0] intValue]; org in the ovmsAppDelegate.m Yes i know i can divide by 1.515. But for showing what i do, i do it this way. It was faster to change it in the App, but i think it is better to do it in the Module. One Problem can occur: If the SOC reaches 21% the car switches to the RangeExtender (RE). BUT the SOC can fall to 18%. At the other end, when the batterie is fully charged (SOC 87%) and the car goes downhill the SOC can go to nearly 90% (or more, i don't know). What happend with the App? The 21% (0%) i can test tomorow, but i have no so big hill near me. :)

BTW: the iPad App don't shows any car Pics on the main screen.

Bye michael

Am 04.11.2012 um 14:21 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:

...

That wasn't me.

Whoops. Michael Jochum...

...

ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?

The Microchip compiler has an 'overlay' facility. We can put them in the same memory bank so they all overlay each other. You are correct - RAM is the concern.

...

So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.

I think the existing model should work for the EVs I've seen. There are some problems that will need to be fixed (e.g.; imperial-only units for ranges), and some extensions made (e.g.; 2 extra doors for saloon style cars), but those are pretty small.

For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added).

...

l (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled)

Yes, I've noticed that. From what I can see, it is just garbage tacked on the end but I've been meaning to convert this to a better document. We have full revision control on this.

...

The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support).

I think that stuff like this is going to be _very_ hard to fit in ram, but does it actually need to be stored? Say we have 16 can bus messages to send out. We could just use a 2byte bit array with a bit high indicating we need the figure. If the message arrives on the can bus, and the corresponding bit it high, it can get queued for transmission directly, then the bit cleared. I'm not sure if that is clear (hard to explain it in writing), but what I'm saying is have a mechanism for the can driver to be able to queue stuff for transmission directly from the incoming can message. So, rather than storing 16 messages for transmission, we don't need to store any - just have a flag to say 'transmit the values when it next comes off the bus'.

...

So, maybe the data and protocol models need to be generalized first?

I think it just needs to be documented better, and expanded as necessary. Let's then see how things fit into that. I'll work on this now, as both Michael's need this urgently.

Regards, Mark.

On 4 Nov, 2012, at 8:37 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Am 04.11.2012 04:11, schrieb Mark Webb-Johnson:

...

A while ago, Michael Balzer suggested to me that it would be best to have one firmware supporting all cars.

That wasn't me. The idea sounds good, but...

• car platforms to be supported will increase steadily now, there are lots to come in the next years
• even cars with decent builtin online monitoring systems lack some functionality for nerds like us
• there will be a need for custom product configuration per car anyway, as cabling and antenna configuration will be different

ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?

Also, not only the CAN module may need car specific adaption. I've not yet completely read into the server protocol (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled), but got the impression it contains some common and some Tesla specific data. If we have to integrate specific data from every model supported, the data stream can become quite fat. So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.

Example: one of my next ideas is a cell monitor to get a history of the cell voltage levels, so I can detect and alert about cell failures early. The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support). The Tesla has an 11S 9S 69P configuration (?), so that would need much more history RAM + possibly another data layout -- if the voltages are on CAN at all.

Another example I already stumbled on: the car_doors1 flag 0x04 (charge port open) is currently used by net_sms_stat(), if it's not set, it assumes "not charging". So even some standard functions rely on Tesla specific data.

So, maybe the data and protocol models need to be generalized first? Or am I missing something?

Regards, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Hi mark,

This should definitely be done in the module.

yes, of course, best it is done in the module.

One suggestion: can we store the smallest seen raw SOC value > 0, and the largest seen raw SOC value, and default these to 13524 (64400*0.21) and 56028 (64400*0.87) at start up. Yes and No! The lowest usable SOC IS (!) 21%. When the RE comes in, it COULD be that the SOC falls to 17-18%. But the RE charge the Batterie to SOC 21%. This means that you normaly dont have this SOC for a long time. And the highest usable SOC IS 87%. Above this is never shown anywhere. It is of course usable. I think we cut the SOC at 21 and 87%.

Like this:

v = (can_databuffer[1]+(unsigned int) can_databuffer[0] << 8); if ((v<soc_smallest)&&(v>0)) v=soc_smallest; if (v>soc_largest) v=soc_largest; car_SOC = (char)((v-soc_smallest)/((soc_largest-soc_smallest)/100));

Here is a Pic with a SOC 17% shown as -4 in my mod iPhone App:

Funnyiest is that there is no underflow.

Here is the pic from the iPad:

i check the selected car. It was a "gray out" colored car. ????

i select an other car and it works.

Bye michael

Am 05.11.2012 um 01:50 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:

Michael,

This should definitely be done in the module.

One suggestion: can we store the smallest seen raw SOC value > 0, and the largest seen raw SOC value, and default these to 13524 (64400*0.21) and 56028 (64400*0.87) at start up.

Then, the formula in the module can be:

SOC% = (value-smallest)/((biggest-smallest)/100)

That would auto-scale and adjust itself as necessary. As SOC is only 0-100, unsigned int16 maths should be sufficient.

The code would be something like:

unsigned int soc_largest = 56028; unsigned int soc_smallest = 13524; unsigned int v;

...

v = (can_databuffer[1]+(unsigned int) can_databuffer[0] << 8); if ((v<soc_smallest)&&(v>0)) soc_smallest=v; if (v>soc_largest) soc_largest=v; car_SOC = (char)((v-soc_smallest)/((soc_largest-soc_smallest)/100));

Regards, Mark.

P.S. Not sure what you mean about the iPad App pictures. Please send a screendump to illustrate. Also, please check you have the right picture selected on the car detail screen.

On 4 Nov, 2012, at 11:38 PM, mikeljo@me.com wrote:

...

Hi,

i ask in the german Ampera Forum about the SOC. The iPhone App shows minimum 21% to max. 87%. This is the usable Batterie window. Now they would have 0-100% in the App. As a "quick and dirty" fix i do this in the App: car_soc = ([[lparts objectAtIndex:0] intValue]-21)*(100.0/66.0); // 21 - 87% = 0 - 100% 1,515151515151515 MJ //car_soc = [[lparts objectAtIndex:0] intValue]; org in the ovmsAppDelegate.m Yes i know i can divide by 1.515. But for showing what i do, i do it this way. It was faster to change it in the App, but i think it is better to do it in the Module. One Problem can occur: If the SOC reaches 21% the car switches to the RangeExtender (RE). BUT the SOC can fall to 18%. At the other end, when the batterie is fully charged (SOC 87%) and the car goes downhill the SOC can go to nearly 90% (or more, i don't know). What happend with the App? The 21% (0%) i can test tomorow, but i have no so big hill near me. :)

BTW: the iPad App don't shows any car Pics on the main screen.

Bye michael

Am 04.11.2012 um 14:21 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:

...

...

That wasn't me.

Whoops. Michael Jochum...

...

ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?

The Microchip compiler has an 'overlay' facility. We can put them in the same memory bank so they all overlay each other. You are correct - RAM is the concern.

...

So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.

I think the existing model should work for the EVs I've seen. There are some problems that will need to be fixed (e.g.; imperial-only units for ranges), and some extensions made (e.g.; 2 extra doors for saloon style cars), but those are pretty small.

For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added).

...

l (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled)

Yes, I've noticed that. From what I can see, it is just garbage tacked on the end but I've been meaning to convert this to a better document. We have full revision control on this.

...

The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support).

I think that stuff like this is going to be _very_ hard to fit in ram, but does it actually need to be stored? Say we have 16 can bus messages to send out. We could just use a 2byte bit array with a bit high indicating we need the figure. If the message arrives on the can bus, and the corresponding bit it high, it can get queued for transmission directly, then the bit cleared. I'm not sure if that is clear (hard to explain it in writing), but what I'm saying is have a mechanism for the can driver to be able to queue stuff for transmission directly from the incoming can message. So, rather than storing 16 messages for transmission, we don't need to store any - just have a flag to say 'transmit the values when it next comes off the bus'.

...

So, maybe the data and protocol models need to be generalized first?

I think it just needs to be documented better, and expanded as necessary. Let's then see how things fit into that. I'll work on this now, as both Michael's need this urgently.

Regards, Mark.

On 4 Nov, 2012, at 8:37 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Am 04.11.2012 04:11, schrieb Mark Webb-Johnson:

...

A while ago, Michael Balzer suggested to me that it would be best to have one firmware supporting all cars.

That wasn't me. The idea sounds good, but...

• car platforms to be supported will increase steadily now, there are lots to come in the next years
• even cars with decent builtin online monitoring systems lack some functionality for nerds like us
• there will be a need for custom product configuration per car anyway, as cabling and antenna configuration will be different

ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?

Also, not only the CAN module may need car specific adaption. I've not yet completely read into the server protocol (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled), but got the impression it contains some common and some Tesla specific data. If we have to integrate specific data from every model supported, the data stream can become quite fat. So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.

Example: one of my next ideas is a cell monitor to get a history of the cell voltage levels, so I can detect and alert about cell failures early. The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support). The Tesla has an 11S 9S 69P configuration (?), so that would need much more history RAM + possibly another data layout -- if the voltages are on CAN at all.

Another example I already stumbled on: the car_doors1 flag 0x04 (charge port open) is currently used by net_sms_stat(), if it's not set, it assumes "not charging". So even some standard functions rely on Tesla specific data.

So, maybe the data and protocol models need to be generalized first? Or am I missing something?

Regards, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

I think the general approach here is correct.

It is a fine line between allowing the vehicle modules to do more, and duplicating common functionality in each module. But, your suggestion to implement the core functions centrally, then allow the vehicle modules to either override or extend those core functions, is a good solution. It can also be extended to SMS messages.

I'm not sure about using command/response ("C", "c") to allow the Apps to query the module capabilities. Those are quite expensive for the Apps to issue: App->Server->Car->Server->App latency can be 1, 2 or more seconds over GPRS - doing that each time the App starts up is going to be expensive. We can do this just as easily by a published message type giving the capabilities of the car - and that message could be issued just once on module startup (with the application receiving a copy each time it connected to the server).

This also fits in with my email a while ago about restructuring to include a single firmware with multiple vehicle modules switchable at runtime. I'm very interested in getting a generic ODBII module working as well (which could show speed, fuel tank pressure, ODBII fault codes, etc).

We need to maintain the stability of the v1 system, as we have so many users using it at the moment. So, what I've just done is commit the last major change to v1 code - I've update the protocol manual formatting to make it clearer - and created two new branches ("v1" and "v2). Let's work in the "v2" branch to create a single unified firmware supporting Roadster, Twizy, Volt and generic ODBII on v2 hardware. For v1 hardware users (Roadster), we can always back-port new features as necessary.

I can work on this now, so give me a few days to try to build the framework for this re-structure.

Regards, Mark.

On 10 Nov, 2012, at 10:10 PM, Michael Balzer <dexter@expeedo.de> wrote:

Am 04.11.2012 14:21, schrieb Mark Webb-Johnson:

...

For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added).

Mark, List,

for the Twizy, it's not so much about extending but about reducing, as many current standard commands do not make sense on the Twizy. Some could also use slightly different implementations (STAT SMS as seen).

I've thought about that last night and had fun reading into the net code. Cool stuff. I stumbled about a very simple way to not only enable routing of special commands to the car, but to also enable overloading of builtin commands. Seems you had something like that already in mind when writing that code :-)

So the system net modules could implement just the common standard commands while the car modules would dynamically extend those with just their specific commands. Using a message passing scheme to mimic an OO sub class approach, a car module will be able to...

• either leave a command handling to the system
• or use and extend the system handling
• or completely implement a command itself, possibly replacing a system handler.

Current car specific hook calls like can_tx_setchargemode() can then be removed from the common net framework.

To configure themselves accordingly, servers and apps may want to know the type and version of the car module, and a list of the commands supported by the firmware. To enable this, I would introduce two new msg commands:

• 6 = car module type + version => reply scheme: "MP-0 c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>"

• 7 = list of commands supported => reply scheme: "MP-0 c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..." More than one list of each class can be sent, clients should collect and join all. I think IDs are sufficient, otherwise the reply scheme could be extended.

Maybe a third one will make sense for the...

• 8 = list of car data properties supported => reply scheme: "MP-0 c8,0,..." (todo? can make life easier for the App)

Due to the structural beauty of the net code, this extension should be quite easy to implement. Please take a look at my implementation draft below and give me some feedback. The SMS part should be able to use the same approach.

AFAIS this extension would require no immediate change to the existing server and apps, it just offers an opportunity for the next releases.

Regards, Michael

// ------------------- net_msg module ----------------------

// REPLACE: void net_msg_cmd_do(void) { /**************************************************************** * MSG COMMAND DISPATCHER * Called by: net_msg_cmd_in() & net_state_ticker1() * * GLOBAL PARAMS: * net_msg_cmd_code = int command id * net_msg_cmd_msg = char * to first parameter */

delay100(2);

// commands 40-49 are special AT commands, thus, disable net_msg here if ((net_msg_cmd_code < 40) || (net_msg_cmd_code > 49)) net_msg_start();

// Execute cmd: ask car module to execute first: if( !car_msg_cmd_exec() ) { // Car module does not feel responsible, fall back to standard: if( !net_msg_cmd_exec() ) { // No standard as well => return "unimplemented" sprintf(net_scratchpad, (rom far char*)"MP-0 c%d,3",net_msg_cmd_code); net_msg_encode_puts(); } }

// terminate IPSEND by Ctrl-Z (should this be disabled for commands 40-49 as well?) net_msg_send();

// clear command net_msg_cmd_code = 0; net_msg_cmd_msg[0] = 0;

}

// ADD: bool net_msg_cmd_exec(void) { /**************************************************************** * IMPLEMENTATION OF STANDARD MSG COMMANDS * Called by: net_msg_cmd_do() & car specific cmd handlers * * GLOBAL PARAMS: * net_msg_cmd_code = int command id * net_msg_cmd_msg = char * to first parameter * * RETURNS: * true if cmd has been handled */

int k; char *p;

switch (net_msg_cmd_code) { // ...std cmds 1-5 to be inserted here if compiler does no jump table optimization...

   case 7:
       // List commands supported (for peer configuration):
       // standard commands:
       sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,STD,1,2,3,4,5,40,41,49" );
       net_msg_encode_puts();
       // (can be extended if clients need more than the cmd ids)
       return true;

   // ...std cmds to be inserted here...

   default:
       // unhandled cmd_code:
       return false;

} }

// ------------------- can_<model> or maybe separate car_<model> module ----------------------

// ADD: bool car_msg_cmd_exec(void) { /**************************************************************** * HOOK to integrate CAR SPECIFIC MSG command handlers * May overlay and/or extend the standard command set * Called by: net_msg_cmd_do() * * GLOBAL PARAMS: * net_msg_cmd_code = int command id * net_msg_cmd_msg = char * to first parameter * * RETURNS: * true : cmd has been handled completely * false: fallback to net_msg_cmd_exec() * * OUTPUT SCHEME: * sprintf(net_scratchpad, (rom far char*)"MP-..."); * net_msg_encode_puts(); * * CALL SPECIFIC STANDARD FUNCTION n: (rare case) * [save net_msg_cmd_* if needed later on] * net_msg_cmd_code = n; * strcpy( net_msg_cmd_msg, "arg1,arg2,..." ); * if( net_msg_cmd_exec() ) {...success...} * */

/* Command dispatcher: */ switch( net_msg_cmd_code ) { case 6: // Echo CAR TYPE + MODULE VERSION: sprintf( net_scratchpad, (rom far char*)"MP-0 c6,0,RT,Renault Twizy,1,2,0" ); net_msg_encode_puts(); return true;

   case 7:
       // List commands supported (for peer configuration):
       // a) standard commands:
       net_msg_cmd_exec();
       // b) car specific commands / overloads:
       sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,CAR,6,7,10" );
       net_msg_encode_puts();
       // (can be extended if clients need more than the cmd ids)
       return true;

/************************************************************ * CAR SPECIFIC COMMANDS */

   case 10:
       // EXAMPLE FROM TESLA MODULE: Set charge mode (params: 0=standard, 1=storage,3=range,4=performance)
       if (sys_features[FEATURE_CANWRITE]==0)
       {
           sprintf(net_scratchpad, (rom far char*)NET_MSG_NOCANWRITE,net_msg_cmd_code);
       }
       else
       {
           can_tx_setchargemode(atoi(net_msg_cmd_msg));
           sprintf(net_scratchpad, (rom far char*)NET_MSG_OK,net_msg_cmd_code);
       }
       net_msg_encode_puts();
       return true;

   // ...more...

   default:
       // Not handled, fall back to standard:
       return false;

}

}

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

I've just committed my work-in-progress for this to the github v2 branch.

Best I can say about it is that it compiles and links without error.

It would be a miracle if it actually ran. I doubt it. I haven't had a chance to test it on real hardware yet.

The framework for multiple cars is there, and seems to work ok. I can't get the overlay data section working (yet) - it is there but doesn't seem to be overlaying the different vehicle data and saving ram like it should. I re-worked the 100 byte net_msg_cmd_msg to be a pointer, saving a lot of ram but possibly breaking more advanced commands like "AT", "MMI/USSD" and "SMS" - I'll test them when I get a chance to run this on real hardware.

I followed Michael B's suggestion for the net_msg_cmd handlers, and the hooks in general. So far, the can hooks are there, as well as the re-work of the net_msg_cmd stuff to hook through to the vehicle. I haven't had a chance to remove some of the old stub functions yet.

The overall approach is that I've moved the old common can code to vehicle.h and vehicle.c. This defines a series of hooks, for vehicle initialisation. When the system starts up, a PARAM_VEHICLETYPE is now used to define the type of vehicle, and initialise that one vehicle module. During initialisation, the vehicle module hooks itself in to other functions it requires. If it doesn't hook in, the function is handled by the default handler. Once this part is working well, I intend to add hooks for SMS messages as well.

To create a new vehicle, we would need to create a vehicle_* module, add the #define for it, and change vehicle.c initialisation to detect the vehicle type and initialise the module. It would be nice to have a better plugin architecture for this, but we're (a) limited by c (not c++), and (b) any such architecture would need ram space which is at a premium compared to rom.

I've still got a bit of work to go to tidy this up, but as it is now the vehicle modules certainly look neater and have a lot less stub functions. The current approach now lets arbitrary commands make it through the the individual vehicle modules for action - which will provide amazing opportunities for expansion, as well as avoiding having stub functions in the Twizy module for locking and unlocking the non-existent doors.

Feel free to have a look at the code, and let me know what you think and if there is anything obviously wrong.

Regards, Mark.

On 13 Nov, 2012, at 11:37 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

I've got the framework for this 70% done. So far, it builds and looks good. Code size for experimental v2 branch has gone from 50% of flash to 55% - including all vehicle modules for tesla roadster, twizy, volt/ampera, basic odbii and a null vehicle stub. RAM has gone up about 30 bytes, but that is part of the 30% not yet done.

I've merged in all Michael B's recent changes (including stuff that may need to be looked at in light of this re-work).

I'm going to do one more night on it, then commit what I have to the v2 branch for others to look at.

Regards, Mark.

On 11 Nov, 2012, at 10:13 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

I think the general approach here is correct.

It is a fine line between allowing the vehicle modules to do more, and duplicating common functionality in each module. But, your suggestion to implement the core functions centrally, then allow the vehicle modules to either override or extend those core functions, is a good solution. It can also be extended to SMS messages.

I'm not sure about using command/response ("C", "c") to allow the Apps to query the module capabilities. Those are quite expensive for the Apps to issue: App->Server->Car->Server->App latency can be 1, 2 or more seconds over GPRS - doing that each time the App starts up is going to be expensive. We can do this just as easily by a published message type giving the capabilities of the car - and that message could be issued just once on module startup (with the application receiving a copy each time it connected to the server).

This also fits in with my email a while ago about restructuring to include a single firmware with multiple vehicle modules switchable at runtime. I'm very interested in getting a generic ODBII module working as well (which could show speed, fuel tank pressure, ODBII fault codes, etc).

We need to maintain the stability of the v1 system, as we have so many users using it at the moment. So, what I've just done is commit the last major change to v1 code - I've update the protocol manual formatting to make it clearer - and created two new branches ("v1" and "v2). Let's work in the "v2" branch to create a single unified firmware supporting Roadster, Twizy, Volt and generic ODBII on v2 hardware. For v1 hardware users (Roadster), we can always back-port new features as necessary.

I can work on this now, so give me a few days to try to build the framework for this re-structure.

Regards, Mark.

On 10 Nov, 2012, at 10:10 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Am 04.11.2012 14:21, schrieb Mark Webb-Johnson:

...

For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added).

Mark, List,

for the Twizy, it's not so much about extending but about reducing, as many current standard commands do not make sense on the Twizy. Some could also use slightly different implementations (STAT SMS as seen).

I've thought about that last night and had fun reading into the net code. Cool stuff. I stumbled about a very simple way to not only enable routing of special commands to the car, but to also enable overloading of builtin commands. Seems you had something like that already in mind when writing that code :-)

So the system net modules could implement just the common standard commands while the car modules would dynamically extend those with just their specific commands. Using a message passing scheme to mimic an OO sub class approach, a car module will be able to...

• either leave a command handling to the system
• or use and extend the system handling
• or completely implement a command itself, possibly replacing a system handler.

Current car specific hook calls like can_tx_setchargemode() can then be removed from the common net framework.

To configure themselves accordingly, servers and apps may want to know the type and version of the car module, and a list of the commands supported by the firmware. To enable this, I would introduce two new msg commands:

• 6 = car module type + version => reply scheme: "MP-0 c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>"

• 7 = list of commands supported => reply scheme: "MP-0 c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..." More than one list of each class can be sent, clients should collect and join all. I think IDs are sufficient, otherwise the reply scheme could be extended.

Maybe a third one will make sense for the...

• 8 = list of car data properties supported => reply scheme: "MP-0 c8,0,..." (todo? can make life easier for the App)

Due to the structural beauty of the net code, this extension should be quite easy to implement. Please take a look at my implementation draft below and give me some feedback. The SMS part should be able to use the same approach.

AFAIS this extension would require no immediate change to the existing server and apps, it just offers an opportunity for the next releases.

Regards, Michael

// ------------------- net_msg module ----------------------

// REPLACE: void net_msg_cmd_do(void) { /****************************************************************

• MSG COMMAND DISPATCHER
• Called by: net_msg_cmd_in() & net_state_ticker1()
• GLOBAL PARAMS:
• net_msg_cmd_code = int command id
• net_msg_cmd_msg = char * to first parameter */

delay100(2);

// commands 40-49 are special AT commands, thus, disable net_msg here if ((net_msg_cmd_code < 40) || (net_msg_cmd_code > 49)) net_msg_start();

// Execute cmd: ask car module to execute first: if( !car_msg_cmd_exec() ) { // Car module does not feel responsible, fall back to standard: if( !net_msg_cmd_exec() ) { // No standard as well => return "unimplemented" sprintf(net_scratchpad, (rom far char*)"MP-0 c%d,3",net_msg_cmd_code); net_msg_encode_puts(); } }

// terminate IPSEND by Ctrl-Z (should this be disabled for commands 40-49 as well?) net_msg_send();

// clear command net_msg_cmd_code = 0; net_msg_cmd_msg[0] = 0;

}

// ADD: bool net_msg_cmd_exec(void) { /****************************************************************

• IMPLEMENTATION OF STANDARD MSG COMMANDS
• Called by: net_msg_cmd_do() & car specific cmd handlers
• GLOBAL PARAMS:
• net_msg_cmd_code = int command id
• net_msg_cmd_msg = char * to first parameter
• RETURNS:
• true if cmd has been handled */

int k; char *p;

switch (net_msg_cmd_code) { // ...std cmds 1-5 to be inserted here if compiler does no jump table optimization...

 case 7:
     // List commands supported (for peer configuration):
     // standard commands:
     sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,STD,1,2,3,4,5,40,41,49" );
     net_msg_encode_puts();
     // (can be extended if clients need more than the cmd ids)
     return true;

 // ...std cmds to be inserted here...

 default:
     // unhandled cmd_code:
     return false;

} }

// ------------------- can_<model> or maybe separate car_<model> module ----------------------

// ADD: bool car_msg_cmd_exec(void) { /****************************************************************

• HOOK to integrate CAR SPECIFIC MSG command handlers
• May overlay and/or extend the standard command set
• Called by: net_msg_cmd_do()
• GLOBAL PARAMS:
• net_msg_cmd_code = int command id
• net_msg_cmd_msg = char * to first parameter
• RETURNS:
• true : cmd has been handled completely
• false: fallback to net_msg_cmd_exec()
• OUTPUT SCHEME:
• sprintf(net_scratchpad, (rom far char*)"MP-...");
• net_msg_encode_puts();
• CALL SPECIFIC STANDARD FUNCTION n: (rare case)
• [save net_msg_cmd_* if needed later on]
• net_msg_cmd_code = n;
• strcpy( net_msg_cmd_msg, "arg1,arg2,..." );
• if( net_msg_cmd_exec() ) {...success...}
• */

/* Command dispatcher: */ switch( net_msg_cmd_code ) { case 6: // Echo CAR TYPE + MODULE VERSION: sprintf( net_scratchpad, (rom far char*)"MP-0 c6,0,RT,Renault Twizy,1,2,0" ); net_msg_encode_puts(); return true;

 case 7:
     // List commands supported (for peer configuration):
     // a) standard commands:
     net_msg_cmd_exec();
     // b) car specific commands / overloads:
     sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,CAR,6,7,10" );
     net_msg_encode_puts();
     // (can be extended if clients need more than the cmd ids)
     return true;

/************************************************************ * CAR SPECIFIC COMMANDS */

 case 10:
     // EXAMPLE FROM TESLA MODULE: Set charge mode (params: 0=standard, 1=storage,3=range,4=performance)
     if (sys_features[FEATURE_CANWRITE]==0)
     {
         sprintf(net_scratchpad, (rom far char*)NET_MSG_NOCANWRITE,net_msg_cmd_code);
     }
     else
     {
         can_tx_setchargemode(atoi(net_msg_cmd_msg));
         sprintf(net_scratchpad, (rom far char*)NET_MSG_OK,net_msg_cmd_code);
     }
     net_msg_encode_puts();
     return true;

 // ...more...

 default:
     // Not handled, fall back to standard:
     return false;

}

}

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Mark,

I followed your branch naming, "v2" on my repository adds my latest Twizy changes to the new framework.

Stunningly, V2 worked out of the box :-) Great job!

I will look into integrating the internal GPS flag so we don't need a compiler switch for this as well. Does it make sense to couple this to the car type or could someone with a GPS equipped car have some reason to occasionally use the OVMS GPS instead?

I'll also port my specific STAT? version to the new framework ASAP.

I have one concern for the overlaying of the vehicle RAM sections: I now changed most of my state variables to uninitialized to harden against crash resets (we've got SRAM after all). That works quite well with the old framework. I had no reset with V2 up to now -- my concern is, that an initialized overlay from another vehicle will initialize my variables as well. As all vehicle modules exist side by side now, can we introduce two data sections, one explicitly being uninitialized? #pragma idata seems to be meant for something like that, but everything's now in udata, even initialized vars...

Regards, Michael

Am 15.11.2012 14:52, schrieb Mark Webb-Johnson:

I've just committed another night's work on this. Looks good and now runs on actual hardware.

I've extended the MODULE and MODULE? SMS commands with a fourth parameter - the car type - to allow this to be set. Also SMS VERSION now shows the car type being used.

I've ported the SMS commands over to the new vehicle module framework, and they look good.

I've bumped the version to 2.1.1, to reflect the major restructuring that this is.

This will still only run on v2 hardware at present. No reason we can't support v1 (and will) - just need to tidy up the build configurations.

Regards, Mark.

On 14 Nov, 2012, at 10:57 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

I've just committed my work-in-progress for this to the github v2 branch.

Best I can say about it is that it compiles and links without error.

It would be a miracle if it actually ran. I doubt it. I haven't had a chance to test it on real hardware yet.

The framework for multiple cars is there, and seems to work ok. I can't get the overlay data section working (yet) - it is there but doesn't seem to be overlaying the different vehicle data and saving ram like it should. I re-worked the 100 byte net_msg_cmd_msg to be a pointer, saving a lot of ram but possibly breaking more advanced commands like "AT", "MMI/USSD" and "SMS" - I'll test them when I get a chance to run this on real hardware.

I followed Michael B's suggestion for the net_msg_cmd handlers, and the hooks in general. So far, the can hooks are there, as well as the re-work of the net_msg_cmd stuff to hook through to the vehicle. I haven't had a chance to remove some of the old stub functions yet.

The overall approach is that I've moved the old common can code to vehicle.h and vehicle.c. This defines a series of hooks, for vehicle initialisation. When the system starts up, a PARAM_VEHICLETYPE is now used to define the type of vehicle, and initialise that one vehicle module. During initialisation, the vehicle module hooks itself in to other functions it requires. If it doesn't hook in, the function is handled by the default handler. Once this part is working well, I intend to add hooks for SMS messages as well.

To create a new vehicle, we would need to create a vehicle_* module, add the #define for it, and change vehicle.c initialisation to detect the vehicle type and initialise the module. It would be nice to have a better plugin architecture for this, but we're (a) limited by c (not c++), and (b) any such architecture would need ram space which is at a premium compared to rom.

I've still got a bit of work to go to tidy this up, but as it is now the vehicle modules certainly look neater and have a lot less stub functions. The current approach now lets arbitrary commands make it through the the individual vehicle modules for action - which will provide amazing opportunities for expansion, as well as avoiding having stub functions in the Twizy module for locking and unlocking the non-existent doors.

Feel free to have a look at the code, and let me know what you think and if there is anything obviously wrong.

Regards, Mark.

On 13 Nov, 2012, at 11:37 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

I've got the framework for this 70% done. So far, it builds and looks good. Code size for experimental v2 branch has gone from 50% of flash to 55% - including all vehicle modules for tesla roadster, twizy, volt/ampera, basic odbii and a null vehicle stub. RAM has gone up about 30 bytes, but that is part of the 30% not yet done.

I've merged in all Michael B's recent changes (including stuff that may need to be looked at in light of this re-work).

I'm going to do one more night on it, then commit what I have to the v2 branch for others to look at.

Regards, Mark.

On 11 Nov, 2012, at 10:13 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

I think the general approach here is correct.

It is a fine line between allowing the vehicle modules to do more, and duplicating common functionality in each module. But, your suggestion to implement the core functions centrally, then allow the vehicle modules to either override or extend those core functions, is a good solution. It can also be extended to SMS messages.

I'm not sure about using command/response ("C", "c") to allow the Apps to query the module capabilities. Those are quite expensive for the Apps to issue: App->Server->Car->Server->App latency can be 1, 2 or more seconds over GPRS - doing that each time the App starts up is going to be expensive. We can do this just as easily by a published message type giving the capabilities of the car - and that message could be issued just once on module startup (with the application receiving a copy each time it connected to the server).

This also fits in with my email a while ago about restructuring to include a single firmware with multiple vehicle modules switchable at runtime. I'm very interested in getting a generic ODBII module working as well (which could show speed, fuel tank pressure, ODBII fault codes, etc).

We need to maintain the stability of the v1 system, as we have so many users using it at the moment. So, what I've just done is commit the last major change to v1 code - I've update the protocol manual formatting to make it clearer - and created two new branches ("v1" and "v2). Let's work in the "v2" branch to create a single unified firmware supporting Roadster, Twizy, Volt and generic ODBII on v2 hardware. For v1 hardware users (Roadster), we can always back-port new features as necessary.

I can work on this now, so give me a few days to try to build the framework for this re-structure.

Regards, Mark.

On 10 Nov, 2012, at 10:10 PM, Michael Balzer <dexter@expeedo.de> wrote:

...

Am 04.11.2012 14:21, schrieb Mark Webb-Johnson:

...

For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added). Mark, List,

for the Twizy, it's not so much about extending but about reducing, as many current standard commands do not make sense on the Twizy. Some could also use slightly different implementations (STAT SMS as seen).

I've thought about that last night and had fun reading into the net code. Cool stuff. I stumbled about a very simple way to not only enable routing of special commands to the car, but to also enable overloading of builtin commands. Seems you had something like that already in mind when writing that code :-)

So the system net modules could implement just the common standard commands while the car modules would dynamically extend those with just their specific commands. Using a message passing scheme to mimic an OO sub class approach, a car module will be able to...

• either leave a command handling to the system
• or use and extend the system handling
• or completely implement a command itself, possibly replacing a system handler.

Current car specific hook calls like can_tx_setchargemode() can then be removed from the common net framework.

To configure themselves accordingly, servers and apps may want to know the type and version of the car module, and a list of the commands supported by the firmware. To enable this, I would introduce two new msg commands:

• 6 = car module type + version => reply scheme: "MP-0 c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>"

• 7 = list of commands supported => reply scheme: "MP-0 c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..." More than one list of each class can be sent, clients should collect and join all. I think IDs are sufficient, otherwise the reply scheme could be extended.

Maybe a third one will make sense for the...

• 8 = list of car data properties supported => reply scheme: "MP-0 c8,0,..." (todo? can make life easier for the App)

Due to the structural beauty of the net code, this extension should be quite easy to implement. Please take a look at my implementation draft below and give me some feedback. The SMS part should be able to use the same approach.

AFAIS this extension would require no immediate change to the existing server and apps, it just offers an opportunity for the next releases.

Regards, Michael

// ------------------- net_msg module ----------------------

// REPLACE: void net_msg_cmd_do(void) { /****************************************************************

• MSG COMMAND DISPATCHER
• Called by: net_msg_cmd_in() & net_state_ticker1()
• GLOBAL PARAMS:
• net_msg_cmd_code = int command id
• net_msg_cmd_msg = char * to first parameter */

delay100(2);

// commands 40-49 are special AT commands, thus, disable net_msg here if ((net_msg_cmd_code < 40) || (net_msg_cmd_code > 49)) net_msg_start();

// Execute cmd: ask car module to execute first: if( !car_msg_cmd_exec() ) { // Car module does not feel responsible, fall back to standard: if( !net_msg_cmd_exec() ) { // No standard as well => return "unimplemented" sprintf(net_scratchpad, (rom far char*)"MP-0 c%d,3",net_msg_cmd_code); net_msg_encode_puts(); } }

// terminate IPSEND by Ctrl-Z (should this be disabled for commands 40-49 as well?) net_msg_send();

// clear command net_msg_cmd_code = 0; net_msg_cmd_msg[0] = 0;

}

// ADD: bool net_msg_cmd_exec(void) { /****************************************************************

• IMPLEMENTATION OF STANDARD MSG COMMANDS
• Called by: net_msg_cmd_do() & car specific cmd handlers
• GLOBAL PARAMS:
• net_msg_cmd_code = int command id
• net_msg_cmd_msg = char * to first parameter
• RETURNS:
• true if cmd has been handled */

int k; char *p;

switch (net_msg_cmd_code) { // ...std cmds 1-5 to be inserted here if compiler does no jump table optimization...

 case 7:
     // List commands supported (for peer configuration):
     // standard commands:
     sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,STD,1,2,3,4,5,40,41,49" );
     net_msg_encode_puts();
     // (can be extended if clients need more than the cmd ids)
     return true;

 // ...std cmds to be inserted here...

 default:
     // unhandled cmd_code:
     return false;

} }

// ------------------- can_<model> or maybe separate car_<model> module ----------------------

// ADD: bool car_msg_cmd_exec(void) { /****************************************************************

• HOOK to integrate CAR SPECIFIC MSG command handlers
• May overlay and/or extend the standard command set
• Called by: net_msg_cmd_do()
• GLOBAL PARAMS:
• net_msg_cmd_code = int command id
• net_msg_cmd_msg = char * to first parameter
• RETURNS:
• true : cmd has been handled completely
• false: fallback to net_msg_cmd_exec()
• OUTPUT SCHEME:
• sprintf(net_scratchpad, (rom far char*)"MP-...");
• net_msg_encode_puts();
• CALL SPECIFIC STANDARD FUNCTION n: (rare case)
• [save net_msg_cmd_* if needed later on]
• net_msg_cmd_code = n;
• strcpy( net_msg_cmd_msg, "arg1,arg2,..." );
• if( net_msg_cmd_exec() ) {...success...}
• */

/* Command dispatcher: */ switch( net_msg_cmd_code ) { case 6: // Echo CAR TYPE + MODULE VERSION: sprintf( net_scratchpad, (rom far char*)"MP-0 c6,0,RT,Renault Twizy,1,2,0" ); net_msg_encode_puts(); return true;

 case 7:
     // List commands supported (for peer configuration):
     // a) standard commands:
     net_msg_cmd_exec();
     // b) car specific commands / overloads:
     sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,CAR,6,7,10" );
     net_msg_encode_puts();
     // (can be extended if clients need more than the cmd ids)
     return true;

/************************************************************ * CAR SPECIFIC COMMANDS */

 case 10:
     // EXAMPLE FROM TESLA MODULE: Set charge mode (params: 0=standard, 1=storage,3=range,4=performance)
     if (sys_features[FEATURE_CANWRITE]==0)
     {
         sprintf(net_scratchpad, (rom far char*)NET_MSG_NOCANWRITE,net_msg_cmd_code);
     }
     else
     {
         can_tx_setchargemode(atoi(net_msg_cmd_msg));
         sprintf(net_scratchpad, (rom far char*)NET_MSG_OK,net_msg_cmd_code);
     }
     net_msg_encode_puts();
     return true;

 // ...more...

 default:
     // Not handled, fall back to standard:
     return false;

}

}

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

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

...

I'll also port my specific STAT? version to the new framework ASAP.

This is a little more involved. I need to re-work the SMS framework to hook in to the vehicle modules nicely, and that will require quite a bit o structural rework. Let me handle this - I'll get it done in the next hour or two.

I've done the structural work for this, and committed to github.

There is now a vehicle module hook for SMS commands, that are run pre-command (allowing a vehicle module to completely override an SMS command), and post-command (allowing a vehicle module to add stuff onto the end of an standard sms command).

I haven't re-worked Michael's Twizy STAT extensions, yet, but the hooks are now there.

The changes were quite drastic, and I've probably broken a lot. It builds, but completely untested. I just wanted to get it in so you could have a look at it.

I'll test it tomorrow, and fix as necessary.

Regards, Mark.

On 17 Nov, 2012, at 9:24 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

I will look into integrating the internal GPS flag so we don't need a compiler switch for this as well. Does it make sense to couple this to the car type or could someone with a GPS equipped car have some reason to occasionally use the OVMS GPS instead?

Its ok. I've handled this. Just add a bitmap flag set to net.h/net.c and controlled it by that. It defaults to OFF (in vehicle.c initialisation), and the none, obdii, Volt/Ampera and Twizy modules enable it.

...

I'll also port my specific STAT? version to the new framework ASAP.

This is a little more involved. I need to re-work the SMS framework to hook in to the vehicle modules nicely, and that will require quite a bit o structural rework. Let me handle this - I'll get it done in the next hour or two.

...

I have one concern for the overlaying of the vehicle RAM sections:

I'll have to think about this and have a look at how it is initialised at the moment. My guess is we're linking to the c library version that wipes all user ram to zero on reboot.

Regards, Mark.

On 17 Nov, 2012, at 3:52 AM, Michael Balzer <dexter@expeedo.de> wrote:

...

Mark,

I followed your branch naming, "v2" on my repository adds my latest Twizy changes to the new framework.

Stunningly, V2 worked out of the box :-) Great job!

I will look into integrating the internal GPS flag so we don't need a compiler switch for this as well. Does it make sense to couple this to the car type or could someone with a GPS equipped car have some reason to occasionally use the OVMS GPS instead?

I'll also port my specific STAT? version to the new framework ASAP.

I have one concern for the overlaying of the vehicle RAM sections: I now changed most of my state variables to uninitialized to harden against crash resets (we've got SRAM after all). That works quite well with the old framework. I had no reset with V2 up to now -- my concern is, that an initialized overlay from another vehicle will initialize my variables as well. As all vehicle modules exist side by side now, can we introduce two data sections, one explicitly being uninitialized? #pragma idata seems to be meant for something like that, but everything's now in udata, even initialized vars...

Regards, Michael

Am 15.11.2012 14:52, schrieb Mark Webb-Johnson:

...

I've just committed another night's work on this. Looks good and now runs on actual hardware.

I've extended the MODULE and MODULE? SMS commands with a fourth parameter - the car type - to allow this to be set. Also SMS VERSION now shows the car type being used.

I've ported the SMS commands over to the new vehicle module framework, and they look good.

I've bumped the version to 2.1.1, to reflect the major restructuring that this is.

This will still only run on v2 hardware at present. No reason we can't support v1 (and will) - just need to tidy up the build configurations.

Regards, Mark.

On 14 Nov, 2012, at 10:57 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

I've just committed my work-in-progress for this to the github v2 branch.

Best I can say about it is that it compiles and links without error.

It would be a miracle if it actually ran. I doubt it. I haven't had a chance to test it on real hardware yet.

The framework for multiple cars is there, and seems to work ok. I can't get the overlay data section working (yet) - it is there but doesn't seem to be overlaying the different vehicle data and saving ram like it should. I re-worked the 100 byte net_msg_cmd_msg to be a pointer, saving a lot of ram but possibly breaking more advanced commands like "AT", "MMI/USSD" and "SMS" - I'll test them when I get a chance to run this on real hardware.

I followed Michael B's suggestion for the net_msg_cmd handlers, and the hooks in general. So far, the can hooks are there, as well as the re-work of the net_msg_cmd stuff to hook through to the vehicle. I haven't had a chance to remove some of the old stub functions yet.

The overall approach is that I've moved the old common can code to vehicle.h and vehicle.c. This defines a series of hooks, for vehicle initialisation. When the system starts up, a PARAM_VEHICLETYPE is now used to define the type of vehicle, and initialise that one vehicle module. During initialisation, the vehicle module hooks itself in to other functions it requires. If it doesn't hook in, the function is handled by the default handler. Once this part is working well, I intend to add hooks for SMS messages as well.

To create a new vehicle, we would need to create a vehicle_* module, add the #define for it, and change vehicle.c initialisation to detect the vehicle type and initialise the module. It would be nice to have a better plugin architecture for this, but we're (a) limited by c (not c++), and (b) any such architecture would need ram space which is at a premium compared to rom.

I've still got a bit of work to go to tidy this up, but as it is now the vehicle modules certainly look neater and have a lot less stub functions. The current approach now lets arbitrary commands make it through the the individual vehicle modules for action - which will provide amazing opportunities for expansion, as well as avoiding having stub functions in the Twizy module for locking and unlocking the non-existent doors.

Feel free to have a look at the code, and let me know what you think and if there is anything obviously wrong.

Regards, Mark.

On 13 Nov, 2012, at 11:37 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

I've got the framework for this 70% done. So far, it builds and looks good. Code size for experimental v2 branch has gone from 50% of flash to 55% - including all vehicle modules for tesla roadster, twizy, volt/ampera, basic odbii and a null vehicle stub. RAM has gone up about 30 bytes, but that is part of the 30% not yet done.

I've merged in all Michael B's recent changes (including stuff that may need to be looked at in light of this re-work).

I'm going to do one more night on it, then commit what I have to the v2 branch for others to look at.

Regards, Mark.

On 11 Nov, 2012, at 10:13 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

I think the general approach here is correct.

It is a fine line between allowing the vehicle modules to do more, and duplicating common functionality in each module. But, your suggestion to implement the core functions centrally, then allow the vehicle modules to either override or extend those core functions, is a good solution. It can also be extended to SMS messages.

I'm not sure about using command/response ("C", "c") to allow the Apps to query the module capabilities. Those are quite expensive for the Apps to issue: App->Server->Car->Server->App latency can be 1, 2 or more seconds over GPRS - doing that each time the App starts up is going to be expensive. We can do this just as easily by a published message type giving the capabilities of the car - and that message could be issued just once on module startup (with the application receiving a copy each time it connected to the server).

This also fits in with my email a while ago about restructuring to include a single firmware with multiple vehicle modules switchable at runtime. I'm very interested in getting a generic ODBII module working as well (which could show speed, fuel tank pressure, ODBII fault codes, etc).

We need to maintain the stability of the v1 system, as we have so many users using it at the moment. So, what I've just done is commit the last major change to v1 code - I've update the protocol manual formatting to make it clearer - and created two new branches ("v1" and "v2). Let's work in the "v2" branch to create a single unified firmware supporting Roadster, Twizy, Volt and generic ODBII on v2 hardware. For v1 hardware users (Roadster), we can always back-port new features as necessary.

I can work on this now, so give me a few days to try to build the framework for this re-structure.

Regards, Mark.

On 10 Nov, 2012, at 10:10 PM, Michael Balzer <dexter@expeedo.de> wrote:

> Am 04.11.2012 14:21, schrieb Mark Webb-Johnson: >> For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added). > Mark, List, > > for the Twizy, it's not so much about extending but about reducing, as many current standard commands do not make sense on the Twizy. Some could also use slightly different implementations (STAT SMS as seen). > > I've thought about that last night and had fun reading into the net code. Cool stuff. I stumbled about a very simple way to not only enable routing of special commands to the car, but to also enable overloading of builtin commands. Seems you had something like that already in mind when writing that code :-) > > So the system net modules could implement just the common standard commands while the car modules would dynamically extend those with just their specific commands. Using a message passing scheme to mimic an OO sub class approach, a car module will be able to... > - either leave a command handling to the system > - or use and extend the system handling > - or completely implement a command itself, possibly replacing a system handler. > > Current car specific hook calls like can_tx_setchargemode() can then be removed from the common net framework. > > To configure themselves accordingly, servers and apps may want to know the type and version of the car module, and a list of the commands supported by the firmware. To enable this, I would introduce two new msg commands: > > - 6 = car module type + version > => reply scheme: "MP-0 c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>" > > - 7 = list of commands supported > => reply scheme: "MP-0 c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..." > More than one list of each class can be sent, clients should collect and join all. > I think IDs are sufficient, otherwise the reply scheme could be extended. > > Maybe a third one will make sense for the... > > - 8 = list of car data properties supported > => reply scheme: "MP-0 c8,0,..." (todo? can make life easier for the App) > > Due to the structural beauty of the net code, this extension should be quite easy to implement. Please take a look at my implementation draft below and give me some feedback. The SMS part should be able to use the same approach. > > AFAIS this extension would require no immediate change to the existing server and apps, it just offers an opportunity for the next releases. > > Regards, > Michael > > > // ------------------- net_msg module ---------------------- > > // REPLACE: > void net_msg_cmd_do(void) > { > /**************************************************************** > * MSG COMMAND DISPATCHER > * Called by: net_msg_cmd_in() & net_state_ticker1() > * > * GLOBAL PARAMS: > * net_msg_cmd_code = int command id > * net_msg_cmd_msg = char * to first parameter > */ > > delay100(2); > > // commands 40-49 are special AT commands, thus, disable net_msg here > if ((net_msg_cmd_code < 40) || (net_msg_cmd_code > 49)) > net_msg_start(); > > // Execute cmd: ask car module to execute first: > if( !car_msg_cmd_exec() ) > { > // Car module does not feel responsible, fall back to standard: > if( !net_msg_cmd_exec() ) > { > // No standard as well => return "unimplemented" > sprintf(net_scratchpad, (rom far char*)"MP-0 c%d,3",net_msg_cmd_code); > net_msg_encode_puts(); > } > } > > // terminate IPSEND by Ctrl-Z (should this be disabled for commands 40-49 as well?) > net_msg_send(); > > // clear command > net_msg_cmd_code = 0; > net_msg_cmd_msg[0] = 0; > > } > > > // ADD: > bool net_msg_cmd_exec(void) > { > /**************************************************************** > * IMPLEMENTATION OF STANDARD MSG COMMANDS > * Called by: net_msg_cmd_do() & car specific cmd handlers > * > * GLOBAL PARAMS: > * net_msg_cmd_code = int command id > * net_msg_cmd_msg = char * to first parameter > * > * RETURNS: > * true if cmd has been handled > */ > > int k; > char *p; > > switch (net_msg_cmd_code) > { > // ...std cmds 1-5 to be inserted here if compiler does no jump table optimization... > > case 7: > // List commands supported (for peer configuration): > // standard commands: > sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,STD,1,2,3,4,5,40,41,49" ); > net_msg_encode_puts(); > // (can be extended if clients need more than the cmd ids) > return true; > > // ...std cmds to be inserted here... > > default: > // unhandled cmd_code: > return false; > } > } > > > // ------------------- can_<model> or maybe separate car_<model> module ---------------------- > > // ADD: > bool car_msg_cmd_exec(void) > { > /**************************************************************** > * HOOK to integrate CAR SPECIFIC MSG command handlers > * May overlay and/or extend the standard command set > * Called by: net_msg_cmd_do() > * > * GLOBAL PARAMS: > * net_msg_cmd_code = int command id > * net_msg_cmd_msg = char * to first parameter > * > * RETURNS: > * true : cmd has been handled completely > * false: fallback to net_msg_cmd_exec() > * > * OUTPUT SCHEME: > * sprintf(net_scratchpad, (rom far char*)"MP-..."); > * net_msg_encode_puts(); > * > * CALL SPECIFIC STANDARD FUNCTION n: (rare case) > * [save net_msg_cmd_* if needed later on] > * net_msg_cmd_code = n; > * strcpy( net_msg_cmd_msg, "arg1,arg2,..." ); > * if( net_msg_cmd_exec() ) {...success...} > * > */ > > /* Command dispatcher: */ > switch( net_msg_cmd_code ) > { > case 6: > // Echo CAR TYPE + MODULE VERSION: > sprintf( net_scratchpad, (rom far char*)"MP-0 c6,0,RT,Renault Twizy,1,2,0" ); > net_msg_encode_puts(); > return true; > > case 7: > // List commands supported (for peer configuration): > // a) standard commands: > net_msg_cmd_exec(); > // b) car specific commands / overloads: > sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,CAR,6,7,10" ); > net_msg_encode_puts(); > // (can be extended if clients need more than the cmd ids) > return true; > > > /************************************************************ > * CAR SPECIFIC COMMANDS > */ > > case 10: > // EXAMPLE FROM TESLA MODULE: Set charge mode (params: 0=standard, 1=storage,3=range,4=performance) > if (sys_features[FEATURE_CANWRITE]==0) > { > sprintf(net_scratchpad, (rom far char*)NET_MSG_NOCANWRITE,net_msg_cmd_code); > } > else > { > can_tx_setchargemode(atoi(net_msg_cmd_msg)); > sprintf(net_scratchpad, (rom far char*)NET_MSG_OK,net_msg_cmd_code); > } > net_msg_encode_puts(); > return true; > > // ...more... > > default: > // Not handled, fall back to standard: > return false; > } > > } > > > > -- > Michael Balzer * Paradestr. 8 * D-42107 Wuppertal > Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 > > <dexter.vcf>_______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

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

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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

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

Am 17.11.2012 19:20, schrieb Michael Balzer:

Mark,

man, you're fast! :-)

...ok, that looks good for extending and replacing existing SMS commands.

Next step will be to split the command table in standard + vehicle commands. That could be done by simply calling vehicle_fn_smshandler() before checking the standard cmdtable and leave everything else to the vehicle module, but I like the concept of net_sms_in() doing the common caller authentication for all commands.

I assume you intend to use this for the vehicle commands as well? So the vehicle module will hook in a specific cmdtable+hfntable to be used by net_sms_in()?

Thinking about auth... maybe I'm missing something, but why is there a need for the three auth modes? Couldn't it just be mode 3 for every command?

Regards, Michael

Am 17.11.2012 16:03, schrieb Mark Webb-Johnson:

...

...

...

I'll also port my specific STAT? version to the new framework ASAP. This is a little more involved. I need to re-work the SMS framework to hook in to the vehicle modules nicely, and that will require quite a bit o structural rework. Let me handle this - I'll get it done in the next hour or two. I've done the structural work for this, and committed to github.

There is now a vehicle module hook for SMS commands, that are run pre-command (allowing a vehicle module to completely override an SMS command), and post-command (allowing a vehicle module to add stuff onto the end of an standard sms command).

I haven't re-worked Michael's Twizy STAT extensions, yet, but the hooks are now there.

The changes were quite drastic, and I've probably broken a lot. It builds, but completely untested. I just wanted to get it in so you could have a look at it.

I'll test it tomorrow, and fix as necessary.

Regards, Mark.

On 17 Nov, 2012, at 9:24 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

...

I will look into integrating the internal GPS flag so we don't need a compiler switch for this as well. Does it make sense to couple this to the car type or could someone with a GPS equipped car have some reason to occasionally use the OVMS GPS instead? Its ok. I've handled this. Just add a bitmap flag set to net.h/net.c and controlled it by that. It defaults to OFF (in vehicle.c initialisation), and the none, obdii, Volt/Ampera and Twizy modules enable it.

...

I'll also port my specific STAT? version to the new framework ASAP. This is a little more involved. I need to re-work the SMS framework to hook in to the vehicle modules nicely, and that will require quite a bit o structural rework. Let me handle this - I'll get it done in the next hour or two.

...

I have one concern for the overlaying of the vehicle RAM sections: I'll have to think about this and have a look at how it is initialised at the moment. My guess is we're linking to the c library version that wipes all user ram to zero on reboot.

Regards, Mark.

On 17 Nov, 2012, at 3:52 AM, Michael Balzer <dexter@expeedo.de> wrote:

...

Mark,

I followed your branch naming, "v2" on my repository adds my latest Twizy changes to the new framework.

Stunningly, V2 worked out of the box :-) Great job!

I will look into integrating the internal GPS flag so we don't need a compiler switch for this as well. Does it make sense to couple this to the car type or could someone with a GPS equipped car have some reason to occasionally use the OVMS GPS instead?

I'll also port my specific STAT? version to the new framework ASAP.

I have one concern for the overlaying of the vehicle RAM sections: I now changed most of my state variables to uninitialized to harden against crash resets (we've got SRAM after all). That works quite well with the old framework. I had no reset with V2 up to now -- my concern is, that an initialized overlay from another vehicle will initialize my variables as well. As all vehicle modules exist side by side now, can we introduce two data sections, one explicitly being uninitialized? #pragma idata seems to be meant for something like that, but everything's now in udata, even initialized vars...

Regards, Michael

Am 15.11.2012 14:52, schrieb Mark Webb-Johnson:

...

I've just committed another night's work on this. Looks good and now runs on actual hardware.

I've extended the MODULE and MODULE? SMS commands with a fourth parameter - the car type - to allow this to be set. Also SMS VERSION now shows the car type being used.

I've ported the SMS commands over to the new vehicle module framework, and they look good.

I've bumped the version to 2.1.1, to reflect the major restructuring that this is.

This will still only run on v2 hardware at present. No reason we can't support v1 (and will) - just need to tidy up the build configurations.

Regards, Mark.

On 14 Nov, 2012, at 10:57 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

...

I've just committed my work-in-progress for this to the github v2 branch.

Best I can say about it is that it compiles and links without error.

It would be a miracle if it actually ran. I doubt it. I haven't had a chance to test it on real hardware yet.

The framework for multiple cars is there, and seems to work ok. I can't get the overlay data section working (yet) - it is there but doesn't seem to be overlaying the different vehicle data and saving ram like it should. I re-worked the 100 byte net_msg_cmd_msg to be a pointer, saving a lot of ram but possibly breaking more advanced commands like "AT", "MMI/USSD" and "SMS" - I'll test them when I get a chance to run this on real hardware.

I followed Michael B's suggestion for the net_msg_cmd handlers, and the hooks in general. So far, the can hooks are there, as well as the re-work of the net_msg_cmd stuff to hook through to the vehicle. I haven't had a chance to remove some of the old stub functions yet.

The overall approach is that I've moved the old common can code to vehicle.h and vehicle.c. This defines a series of hooks, for vehicle initialisation. When the system starts up, a PARAM_VEHICLETYPE is now used to define the type of vehicle, and initialise that one vehicle module. During initialisation, the vehicle module hooks itself in to other functions it requires. If it doesn't hook in, the function is handled by the default handler. Once this part is working well, I intend to add hooks for SMS messages as well.

To create a new vehicle, we would need to create a vehicle_* module, add the #define for it, and change vehicle.c initialisation to detect the vehicle type and initialise the module. It would be nice to have a better plugin architecture for this, but we're (a) limited by c (not c++), and (b) any such architecture would need ram space which is at a premium compared to rom.

I've still got a bit of work to go to tidy this up, but as it is now the vehicle modules certainly look neater and have a lot less stub functions. The current approach now lets arbitrary commands make it through the the individual vehicle modules for action - which will provide amazing opportunities for expansion, as well as avoiding having stub functions in the Twizy module for locking and unlocking the non-existent doors.

Feel free to have a look at the code, and let me know what you think and if there is anything obviously wrong.

Regards, Mark.

On 13 Nov, 2012, at 11:37 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

> I've got the framework for this 70% done. So far, it builds and > looks good. Code size for experimental v2 branch has gone from > 50% of flash to 55% - including all vehicle modules for tesla > roadster, twizy, volt/ampera, basic odbii and a null vehicle > stub. RAM has gone up about 30 bytes, but that is part of the > 30% not yet done. > > I've merged in all Michael B's recent changes (including stuff > that may need to be looked at in light of this re-work). > > I'm going to do one more night on it, then commit what I have to > the v2 branch for others to look at. > > Regards, Mark. > > On 11 Nov, 2012, at 10:13 PM, Mark Webb-Johnson > <mark@webb-johnson.net> wrote: > >> I think the general approach here is correct. >> >> It is a fine line between allowing the vehicle modules to do >> more, and duplicating common functionality in each module. But, >> your suggestion to implement the core functions centrally, then >> allow the vehicle modules to either override or extend those >> core functions, is a good solution. It can also be extended to >> SMS messages. >> >> I'm not sure about using command/response ("C", "c") to allow >> the Apps to query the module capabilities. Those are quite >> expensive for the Apps to issue: App->Server->Car->Server->App >> latency can be 1, 2 or more seconds over GPRS - doing that each >> time the App starts up is going to be expensive. We can do this >> just as easily by a published message type giving the >> capabilities of the car - and that message could be issued just >> once on module startup (with the application receiving a copy >> each time it connected to the server). >> >> This also fits in with my email a while ago about restructuring >> to include a single firmware with multiple vehicle modules >> switchable at runtime. I'm very interested in getting a generic >> ODBII module working as well (which could show speed, fuel tank >> pressure, ODBII fault codes, etc). >> >> We need to maintain the stability of the v1 system, as we have >> so many users using it at the moment. So, what I've just done >> is commit the last major change to v1 code - I've update the >> protocol manual formatting to make it clearer - and created two >> new branches ("v1" and "v2). Let's work in the "v2" branch to >> create a single unified firmware supporting Roadster, Twizy, >> Volt and generic ODBII on v2 hardware. For v1 hardware users >> (Roadster), we can always back-port new features as necessary. >> >> I can work on this now, so give me a few days to try to build >> the framework for this re-structure. >> >> Regards, Mark. >> >> On 10 Nov, 2012, at 10:10 PM, Michael Balzer >> <dexter@expeedo.de> wrote: >> >>> Am 04.11.2012 14:21, schrieb Mark Webb-Johnson: >>>> For major new feature specific to a particular vehicle, I was >>>> hoping we can handle those by the command protocol. We could, >>>> for instance, route commands 100-200 directly through to the >>>> vehicle modules for response. We could also add hooks for the >>>> vehicle modules to directly transmit messages out (the >>>> protocol itself is extensible and new message types can be >>>> easily added). >>> Mark, List, >>> >>> for the Twizy, it's not so much about extending but about >>> reducing, as many current standard commands do not make sense >>> on the Twizy. Some could also use slightly different >>> implementations (STAT SMS as seen). >>> >>> I've thought about that last night and had fun reading into >>> the net code. Cool stuff. I stumbled about a very simple way >>> to not only enable routing of special commands to the car, but >>> to also enable overloading of builtin commands. Seems you had >>> something like that already in mind when writing that code :-) >>> >>> So the system net modules could implement just the common >>> standard commands while the car modules would dynamically >>> extend those with just their specific commands. Using a >>> message passing scheme to mimic an OO sub class approach, a >>> car module will be able to... >>> - either leave a command handling to the system >>> - or use and extend the system handling >>> - or completely implement a command itself, possibly replacing >>> a system handler. >>> >>> Current car specific hook calls like can_tx_setchargemode() >>> can then be removed from the common net framework. >>> >>> To configure themselves accordingly, servers and apps may want >>> to know the type and version of the car module, and a list of >>> the commands supported by the firmware. To enable this, I >>> would introduce two new msg commands: >>> >>> - 6 = car module type + version >>> => reply scheme: "MP-0 >>> c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>" >>> >>> - 7 = list of commands supported >>> => reply scheme: "MP-0 >>> c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..." >>> More than one list of each class can be sent, clients should >>> collect and join all. >>> I think IDs are sufficient, otherwise the reply scheme could >>> be extended. >>> >>> Maybe a third one will make sense for the... >>> >>> - 8 = list of car data properties supported >>> => reply scheme: "MP-0 c8,0,..." (todo? can make life easier >>> for the App) >>> >>> Due to the structural beauty of the net code, this extension >>> should be quite easy to implement. Please take a look at my >>> implementation draft below and give me some feedback. The SMS >>> part should be able to use the same approach. >>> >>> AFAIS this extension would require no immediate change to the >>> existing server and apps, it just offers an opportunity for >>> the next releases. >>> >>> Regards, >>> Michael >>> >>> >>> // ------------------- net_msg module ---------------------- >>> >>> // REPLACE: >>> void net_msg_cmd_do(void) >>> { >>> /**************************************************************** >>> * MSG COMMAND DISPATCHER >>> * Called by: net_msg_cmd_in() & net_state_ticker1() >>> * >>> * GLOBAL PARAMS: >>> * net_msg_cmd_code = int command id >>> * net_msg_cmd_msg = char * to first parameter >>> */ >>> >>> delay100(2); >>> >>> // commands 40-49 are special AT commands, thus, disable >>> net_msg here >>> if ((net_msg_cmd_code < 40) || (net_msg_cmd_code > 49)) >>> net_msg_start(); >>> >>> // Execute cmd: ask car module to execute first: >>> if( !car_msg_cmd_exec() ) >>> { >>> // Car module does not feel responsible, fall back to >>> standard: >>> if( !net_msg_cmd_exec() ) >>> { >>> // No standard as well => return "unimplemented" >>> sprintf(net_scratchpad, (rom far char*)"MP-0 >>> c%d,3",net_msg_cmd_code); >>> net_msg_encode_puts(); >>> } >>> } >>> >>> // terminate IPSEND by Ctrl-Z (should this be disabled for >>> commands 40-49 as well?) >>> net_msg_send(); >>> >>> // clear command >>> net_msg_cmd_code = 0; >>> net_msg_cmd_msg[0] = 0; >>> >>> } >>> >>> >>> // ADD: >>> bool net_msg_cmd_exec(void) >>> { >>> /**************************************************************** >>> * IMPLEMENTATION OF STANDARD MSG COMMANDS >>> * Called by: net_msg_cmd_do() & car specific cmd handlers >>> * >>> * GLOBAL PARAMS: >>> * net_msg_cmd_code = int command id >>> * net_msg_cmd_msg = char * to first parameter >>> * >>> * RETURNS: >>> * true if cmd has been handled >>> */ >>> >>> int k; >>> char *p; >>> >>> switch (net_msg_cmd_code) >>> { >>> // ...std cmds 1-5 to be inserted here if compiler does no >>> jump table optimization... >>> >>> case 7: >>> // List commands supported (for peer configuration): >>> // standard commands: >>> sprintf( net_scratchpad, (rom far char*)"MP-0 >>> c7,0,STD,1,2,3,4,5,40,41,49" ); >>> net_msg_encode_puts(); >>> // (can be extended if clients need more than the cmd >>> ids) >>> return true; >>> >>> // ...std cmds to be inserted here... >>> >>> default: >>> // unhandled cmd_code: >>> return false; >>> } >>> } >>> >>> >>> // ------------------- can_<model> or maybe separate >>> car_<model> module ---------------------- >>> >>> // ADD: >>> bool car_msg_cmd_exec(void) >>> { >>> /**************************************************************** >>> * HOOK to integrate CAR SPECIFIC MSG command handlers >>> * May overlay and/or extend the standard command set >>> * Called by: net_msg_cmd_do() >>> * >>> * GLOBAL PARAMS: >>> * net_msg_cmd_code = int command id >>> * net_msg_cmd_msg = char * to first parameter >>> * >>> * RETURNS: >>> * true : cmd has been handled completely >>> * false: fallback to net_msg_cmd_exec() >>> * >>> * OUTPUT SCHEME: >>> * sprintf(net_scratchpad, (rom far char*)"MP-..."); >>> * net_msg_encode_puts(); >>> * >>> * CALL SPECIFIC STANDARD FUNCTION n: (rare case) >>> * [save net_msg_cmd_* if needed later on] >>> * net_msg_cmd_code = n; >>> * strcpy( net_msg_cmd_msg, "arg1,arg2,..." ); >>> * if( net_msg_cmd_exec() ) {...success...} >>> * >>> */ >>> >>> /* Command dispatcher: */ >>> switch( net_msg_cmd_code ) >>> { >>> case 6: >>> // Echo CAR TYPE + MODULE VERSION: >>> sprintf( net_scratchpad, (rom far char*)"MP-0 >>> c6,0,RT,Renault Twizy,1,2,0" ); >>> net_msg_encode_puts(); >>> return true; >>> >>> case 7: >>> // List commands supported (for peer configuration): >>> // a) standard commands: >>> net_msg_cmd_exec(); >>> // b) car specific commands / overloads: >>> sprintf( net_scratchpad, (rom far char*)"MP-0 >>> c7,0,CAR,6,7,10" ); >>> net_msg_encode_puts(); >>> // (can be extended if clients need more than the cmd >>> ids) >>> return true; >>> >>> >>> /************************************************************ >>> * CAR SPECIFIC COMMANDS >>> */ >>> >>> case 10: >>> // EXAMPLE FROM TESLA MODULE: Set charge mode (params: >>> 0=standard, 1=storage,3=range,4=performance) >>> if (sys_features[FEATURE_CANWRITE]==0) >>> { >>> sprintf(net_scratchpad, (rom far >>> char*)NET_MSG_NOCANWRITE,net_msg_cmd_code); >>> } >>> else >>> { >>> can_tx_setchargemode(atoi(net_msg_cmd_msg)); >>> sprintf(net_scratchpad, (rom far >>> char*)NET_MSG_OK,net_msg_cmd_code); >>> } >>> net_msg_encode_puts(); >>> return true; >>> >>> // ...more... >>> >>> default: >>> // Not handled, fall back to standard: >>> return false; >>> } >>> >>> } >>> >>> >>> >>> -- >>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal >>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 >>> >>> <dexter.vcf>_______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

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

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

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

Mark,

I reworked my command dispatcher according to the new hook:

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

...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@expeedo.de <mailto:dexter@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/7b050c4dd9...

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

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@expeedo.de <mailto:dexter@expeedo.de>> wrote:

...

Mark,

I reworked my command dispatcher according to the new hook:

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

...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@expeedo.de <mailto:dexter@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/7b050c4dd9...

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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

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

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@expeedo.de <mailto:dexter@expeedo.de>> wrote:

...

Mark,

I reworked my command dispatcher according to the new hook:

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

...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@expeedo.de <mailto:dexter@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/7b050c4dd9...

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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

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

Michael,

I'll first need cmd codes for...

DEBUG RANGE CA For vehicle specific cmds you wrote earlier we could just use arbitrary codes 200+, can I still do so or do you want to directly assign standard codes for some of them?

I think we can say everything in the range 200-255 is private, per vehicle module. Allocate them as you require.

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

Regards, Mark.

On 19 Nov, 2012, at 3:32 AM, Michael Balzer <dexter@expeedo.de> wrote:

Am 18.11.2012 13:38, schrieb Mark Webb-Johnson:

...

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.

As everything so far seems to be working pretty well, I'll next add the msg cmd handlers for my commands, to see how that fits.

I'll first need cmd codes for...

DEBUG RANGE CA

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

For vehicle specific cmds you wrote earlier we could just use arbitrary codes 200+, can I still do so or do you want to directly assign standard codes for some of them?

...if some cmd later becomes standard, we can just add that code to the dispatcher switch: case 7: // standard cmd: DEBUG case 200: // obsolete specific cmd: DEBUG do_alert(...); ...at least if the arguments match the standard :-)

Regards, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Mark,

I've implemented it, please review:

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

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

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/9eaa71c1e6...

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/70b770fff2...

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

Michael,

Server logs for PUSH notifications:

2012-11-20 14:52:21.050617 -0500 info main: #37 C DEXZE85 rx msg P ACharging, Topping off 2012-11-20 14:56:13.216180 -0500 info main: #37 C DEXZE85 rx msg P ACharging, Topping off 2012-11-20 15:28:37.549081 -0500 info main: #37 C DEXZE85 rx msg P ACharging, Topping off 2012-11-20 15:40:48.776406 -0500 info main: #80 C DEXZE85 rx msg P ACharging, Topping off Range: 46 - 66 km SOC: 83% (8194 - 8302) ODO: 3730 Km 2012-11-20 16:00:15.659214 -0500 info main: #53 C DEXZE85 rx msg P ACharging, Topping off Range: 51 - 74 km SOC: 93% (8696 - 9304) ODO: 3730 Km

Times are EST.

Regards, Mark.

On 21 Nov, 2012, at 5:25 AM, Michael Balzer wrote:

Am 20.11.2012 20:47, schrieb Michael Balzer:

...

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

Ok, this is getting strange now... everything else works, calling cmd 6 in diag mode, SMS alerts etc., just the App wouldn't alert me. I found a "PA" entry in the Apps "TCP log" output that was cut down to the charge state line, so I thought maybe it's the "\r\n" I had put into the alert text to structure it.

I removed all of the line breaks and the first two alerts again did not come through to the App -- but the third one just did, in perfect shape!?

But for that one I now do not find any TCP log entry... is the Android App reliable concerning the TCP log function?

Mark, I'm stuck. Could you please check the server log for this? Vehicle name now is "DEXZE85".

Thanks, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Mark,

I have begun implementing my battery monitoring as mentioned earlier, and it consumes a lot of RAM, as expected. I'm now down to 6% free RAM, or 193 bytes.

Am I about to get into trouble with this? I.e. does the framework need some dynamic memory, or can we theoretically use the entire remaining RAM for vehicle stuff?

As far as I understood the C18 docs right, the software stack will by default be limited to one bank, and all variables are fixed at compile time. So it seems we can use up all RAM?

(Besides reserving some for future framework extensions of course...)

Thanks, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

Just to share you the pics of the new diag cable for Model S.

One side is Ethernet, the other seems to be proprietary.

Regards Oliver

Michael B,

I see the code for push notification charge alerts net_prep_stat() now contains:

... s = stp_i(s, "\r SOC: ", car_SOC); s = stp_rom(s, "%"); ...

which produces messages like:

rx msg P ANot charging^M Range: 59 - 59 km^M SOC: 100%^M ODO: 0 km

Your vehicle_twizy_ca_msgp() function doesn't seem to have those ^M.

Your message below seems to indicate you've seen this as a problem (having embedded carriage returns in the alerts). Or, is it the \n (not \r) that caused the problem?

That said, I just tested with my car (using cmd.pl to send a msg 6), and got:

rx msg P ANot charging^M Range: 218 - 234 km^M SOC: 75%^M ODO: 19408 km

and the push notification came through to both iOS and Android Apps (even though it contained ^M).

Thoughts?

Regards, Mark.

On 22 Nov, 2012, at 3:10 AM, Michael Balzer wrote:

Mark,

that shed some light, thanks.

It now seems it was not a bug but a combination of a) my poor garage GPRS connectivity, b) the MSG protocol and/or App not allowing for "\n" within alert text and c) me not remembering to put the App to background in time so the notification would really be displayed by Android.

So, everything's working now, I get the same alerts from the App now as via SMS :-)

https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commits/v2

Regarding cr2lf(): I think it would be nice if we could just use one kind of line break throughout all texts without having to recode them according to the transport. I thought about modifying the transport layer functions to recode text accordingly, but that's quite lowlevel, so I now introduced this utility as a workaround. Maybe we can eliminate that later.

Regards, Michael

Am 21.11.2012 02:38, schrieb Mark Webb-Johnson:

...

Michael,

Server logs for PUSH notifications:

2012-11-20 14:52:21.050617 -0500 info main: #37 C DEXZE85 rx msg P ACharging, Topping off 2012-11-20 14:56:13.216180 -0500 info main: #37 C DEXZE85 rx msg P ACharging, Topping off 2012-11-20 15:28:37.549081 -0500 info main: #37 C DEXZE85 rx msg P ACharging, Topping off 2012-11-20 15:40:48.776406 -0500 info main: #80 C DEXZE85 rx msg P ACharging, Topping off Range: 46 - 66 km SOC: 83% (8194 - 8302) ODO: 3730 Km 2012-11-20 16:00:15.659214 -0500 info main: #53 C DEXZE85 rx msg P ACharging, Topping off Range: 51 - 74 km SOC: 93% (8696 - 9304) ODO: 3730 Km

Times are EST.

Regards, Mark.

On 21 Nov, 2012, at 5:25 AM, Michael Balzer wrote:

...

Am 20.11.2012 20:47, schrieb Michael Balzer:

...

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

Ok, this is getting strange now... everything else works, calling cmd 6 in diag mode, SMS alerts etc., just the App wouldn't alert me. I found a "PA" entry in the Apps "TCP log" output that was cut down to the charge state line, so I thought maybe it's the "\r\n" I had put into the alert text to structure it.

I removed all of the line breaks and the first two alerts again did not come through to the App -- but the third one just did, in perfect shape!?

But for that one I now do not find any TCP log entry... is the Android App reliable concerning the TCP log function?

Mark, I'm stuck. Could you please check the server log for this? Vehicle name now is "DEXZE85".

Thanks, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

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 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

I just got off the phone with Telenor Telematics and they were very willing to help with telematics SIM card for the OVMS. Questions came up about the traffic used and number of SMSes.  I remember I read some statistics for couple of days of usage, but I need some very rough averages per month.  Can some of you guys that have been using the system for some time put some KB numbers, and if you like comment on your usage. Thanks, Nikolay

For an end-user, I would estimate around 500KB to 1MB a month nowadays.

It really depends on the cellular coverage, and rounding-up of the cellular provider. The way it works is that a GPRS connection behaves like a VPN tunnel. The module creates the connection, and sends/receives traffic over that connection. If the connection dies, the cellular provider rounds-up and charges per chunk of data (e.g. 10KB, 100KB or in some cases 1MB!), with a minumum of 1 chunk.

So, if you are in poor cellular coverage area, the module makes a GPRS connection, sends perhaps 100 bytes of data, then the connection is lost (and the cellular provider who gave you the poor coverage, rounds up that 100 bytes to 10KB!).

[ As an aside, that is why OVMS now has lots of code in net.c to try to maintain a GPRS connection and only give up on it after several minutes of trying. We used to just tear down GPRS and bring up a new connection, but that consumed too much cellular data. ]

The server tracks protocol-level data, and that is typically 10KB a day (perhaps 310KB a month). Actual cellular-level data is some multiple of that - perhaps 2 to 5 would be reasonable to expect for most users.

Regards, Mark.

On 19 Jan, 2013, at 8:09 PM, Michael Balzer <dexter@expeedo.de> wrote:

Nikolay,

I normally have about 2-3 MB per month now, I guess my maximum would be around 5 MB.

Note: that includes GPS logging (streaming) activated, and I'm driving about 600-700 km per month.

I also currently use about 50-100 SMS per month, but I could already cut that down to near 0 by disabling the SMS channel, as I send all important notifications to the App as well.

Regards, Michael

Am 18.01.2013 17:04, schrieb Nikolay Shishkov:

...

I just got off the phone with Telenor Telematics and they were very willing to help with telematics SIM card for the OVMS. Questions came up about the traffic used and number of SMSes. I remember I read some statistics for couple of days of usage, but I need some very rough averages per month. Can some of you guys that have been using the system for some time put some KB numbers, and if you like comment on your usage. Thanks, Nikolay

---

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 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

The auth modes directly map to the three ways of doing it in the old code. Just standardised them and implemented in one place to save space, and reduce the amount of work needed to be done in the handlers.

Some commands can ONLY work with a password (things like REGISTER used to change the registered phone - which can obviously not work with a caller id).

Some commands can work with EITHER a password OR a registered phone (things like STAT).

Other commands can ONLY work with a registered phone (normally commands used to set settings like SERVER, MODULE, etc - where the presence of a password could be confused with the parameter itself).

Regards, Mark

On 18 Nov, 2012, at 6:08 AM, Michael Balzer <dexter@expeedo.de> wrote:

Am 17.11.2012 19:20, schrieb Michael Balzer:

...

Thinking about auth... maybe I'm missing something, but why is there a need for the three auth modes? Couldn't it just be mode 3 for every command?

Ok, thinking about it a bit more (I'm getting old...), a caller id obviously can be faked, so mode 1 definitely makes sense.

But it still looks like mode 2 is included in mode 3...?

Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Michael,

I'll have to think about this. Not so easy, and it has security implications.

I am aware that caller ID can be faked, but not too worried about it for anything other than the PASS command.

To be successful, the 'hacker' must know your register mobile number (to fake), as well as the number of your car module. If he then fakes your caller id (registered phone) to send a GPS message to the car module, the car module will reply with GPS position of your car to YOU (not him). Faking the sender's caller id doesn't mean he gets messages intended for you.

The main issue is the PASS command. If he does know both telephone numbers, he can fake your registered phone to change the password. Then, he can send messages directly, and get replies. That is a possible issue, and the only protection is that _both_ numbers must be known. Also note that YOU will get a message saying the password has been changed, so you will know about it. The only solution is to make the PASS command require the old as well as new password, but then he is in trouble if he ever forgets the old password.

Slightly concerning also is he can mess with your params, but for each of these YOU will receive an SMS message back showing you the new parameters the hacker has set.

Let me think about it.

Regards, Mark.

P.S. v2.1.1 now running in my car. Looking good.

On 18 Nov, 2012, at 8:51 PM, Michael Balzer <dexter@expeedo.de> wrote:

Mark,

I haven't understood completely yet why there could be confusion on the command parameters.

For example, "PASS" now is in mode 2. If it's called as "PASS <newpw>", net_sms_checkpassarg() would not touch the args. If it's called "PASS <oldpw> <newpw>", net_sms_checkpassarg() will authorize the call and remove <newpw> from the args -- for the PASS handler, everything looks the same. "PASS <oldpw>" would result in clearing the module password, but a check for a non empty <newpw> makes sense there anyway.

Is there a case where the first argument could be identical to the module password? And couldn't we just tell the users they need to choose a secure password (i.e. not one identical to the module or server name)?

I also think it's important for us to remember considering all commands in auth modes "2" and "3" as insecure, as they can be called from anyone just by faking the caller id. I guess that's not a real problem yet, but it could become one. For example, my DEBUG command now outputs the current GPS position, so someone trying to spy me out could easily track me using that output.

...*lol*, there're already even web services available for caller id faking: http://calleridfaker.com/

=> It would be nice for a handler to know the auth level of the call. So my DEBUG handler could output GPS position only if it's been called with the module password.

This could be done by changing the net_sms_checkauth() result to a char reflecting the auth level reached, i.e. 0=auth failure, 1=caller id, 2=password, and passing that through to the handlers.

Regards, Michael

Am 18.11.2012 09:21, schrieb Mark Webb-Johnson:

...

The auth modes directly map to the three ways of doing it in the old code. Just standardised them and implemented in one place to save space, and reduce the amount of work needed to be done in the handlers.

Some commands can ONLY work with a password (things like REGISTER used to change the registered phone - which can obviously not work with a caller id).

Some commands can work with EITHER a password OR a registered phone (things like STAT).

Other commands can ONLY work with a registered phone (normally commands used to set settings like SERVER, MODULE, etc - where the presence of a password could be confused with the parameter itself).

Regards, Mark

On 18 Nov, 2012, at 6:08 AM, Michael Balzer <dexter@expeedo.de> wrote:

...

Am 17.11.2012 19:20, schrieb Michael Balzer:

...

Thinking about auth... maybe I'm missing something, but why is there a need for the three auth modes? Couldn't it just be mode 3 for every command? Ok, thinking about it a bit more (I'm getting old...), a caller id obviously can be faked, so mode 1 definitely makes sense.

But it still looks like mode 2 is included in mode 3...?

Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

---

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

<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

Mark,

I misunderstood...

I've ported the SMS commands over to the new vehicle module framework, and they look good. ...to cover the complete SMS command handling, but you only meant the charge commands for now.

Anyway, this looks like a bug:

 if (vehicle_fn_commandhandler == NULL)
   vehicle_fn_commandhandler(FALSE, 11, NULL);

-- same pattern for all of these. Should be "!=" I think?

Regards, Michael

-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26