[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