[Ovmsdev] RFC: Battery status MSG protocol

Mark Webb-Johnson mark at webb-johnson.net
Mon Dec 17 14:37:34 HKT 2012


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:

A new "H" record type - not stored in the carmessages table, but inserted with a timestamp into historicalmessages.
A new command 31 - retrieving a summary of what historical data the server has for the vehicle.
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 at 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 at 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 at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at 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 at 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 at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121217/22fbbba4/attachment.htm>


More information about the OvmsDev mailing list