This has been completed, and is now live on both tmc and development OVMS servers.

Server identifies itself as 2.1.1-20121216.

It was implemented in three places:

  1. A new "H" record type - not stored in the carmessages table, but inserted with a timestamp into historicalmessages.
  2. A new command 31 - retrieving a summary of what historical data the server has for the vehicle.
  3. A new command 32 - retrieving detailed historical data records of the specified type.

I haven't implement data expunging yet. It is actually a one-liner, but I've left it out on purpose, since I want to see what data is added to make sure everything works correctly.

Michael: Can you try to send your battery data with this new "H" type, and let me know when done so I can check server storage.

It is a pretty simple change to the sample client_app.pl code to retrieve the summary and/or detailed historical records, if you want to see for yourself.

Regards, Mark.

On 16 Dec, 2012, at 10:28 AM, Mark Webb-Johnson wrote:

Ok.

But, lets keep the *- prefix for generic. Easier to split the fields later in the database, and only 2 bytes extra per record.

I'll try to get the server side of this done today.

Regards, Mark

On 15 Dec, 2012, at 7:19 PM, Michael Balzer <dexter@expeedo.de> wrote:

Too fast... regarding the class definitions, to achieve readability here as well I would then suggest using a 3 letter abbreviation.

...main classes:
   
    Power                PWR
    Engine                ENG
    Transmission        TRX
    Chassis                CHS
    Body                BDY
    Electrics            ELC
   
...auxiliary classes?
   
    Safety                SAF        (Chassis, Body, Electrics)
    Security            SEC        (Power?, Body, Electrics)
    Comfort                CMF        (Chassis, Body, Electrics)
    Entertainment        ENT        (Body, Electrics)
    Communication        COM        (Body, Electrics)
   

Also I would prefer "-" as a separator over ".".

For my current application (battery pack + cell data), that would result in type codes...

    RT-PWR-BattPack
    RT-PWR-BattCell

...or general form

    *-PWR-BattPack
    *-PWR-BattCell

Btw: general purpose codes could be written without "*-" prefix as well? That would be...

    PWR-BattPack
    PWR-BattCell

Regards,
Michael


Am 15.12.2012 12:01, schrieb Michael Balzer:
Silly me just assumed you'd prefer integer... I'm using text codes in my own DB designs whenever possible due to readability.

In other words: of course! :-)

I'll modify my code now accordingly.


Am 15.12.2012 11:48, schrieb Mark Webb-Johnson:
The coding looks good, and sensible.

How about we just make it a text string, rather than integer. Much clearer to read, and almost no impact on size.

VV.C.P

VV the normal vehicle types, or '*' for generic.
C your class
P your property

On 15 Dec, 2012, at 6:53 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark, List,

Am 04.12.2012 20:43, schrieb Michael Balzer:
    • type (integer type code)
For general purpose type codes, maybe some classification scheme would make sense? Maybe adopt some standard scheme already defined for automotive data? ...if there is one...

It seems there is none suitable, so here's my attempt at defining one. Please comment.

Regards,
Michael


Type classification scheme:
    id size: 32 bit integer

Generic / standard props:

    0x 0000 C PPP

Vehicle specific props:

    0x VVVV C PPP

    VVVV = Vehicle ID
        0001 = Tesla Roadster
        0002 = Tesla Model S
        0003 = GM Volt / Opel Ampera
        0004 = Renault Twizy
        ...

C = Class:

...main classes:
   
    0 = Power               
    1 = Engine               
    2 = Transmission       
    3 = Chassis               
    4 = Body               
    5 = Electrics           
   
...auxiliary classes?
   
    6 = Safety                (Chassis, Body, Electrics)
    7 = Security            (Power?, Body, Electrics)
    8 = Comfort                (Chassis, Body, Electrics)
    9 = Entertainment        (Body, Electrics)
    a = Communication        (Body, Electrics)
   
   
    b = reserved
    c = reserved
    d = reserved
    e = reserved
    f = reserved
   

PPP = Property
    ...allowing for 4096 properties per class.




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


_______________________________________________
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