<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Mark,<br>
    <br>
    that's an even better idea, reduces server complexity as no type
    switch will be needed.<br>
    <br>
    Just one addition: to be able to store and retrieve multiple records
    within one type (e.g. multiple cells for type "cell data"), an
    "address" or "recno" field could be added after the type. That would
    be part of the primary key, so the server ensures there's at most
    one record no. x of type y.<br>
    <br>
    I think that's necessary to keep the xfer data volumes low,
    otherwise all blob data of a type would need to be updated if just a
    part of it changes.<br>
    <br>
    So that would be:<br>
    <div>
      <ul class="MailOutline">
        <li>MP-0
          H,<type>,<recno>,<lifetime>,<data></li>
        <ul>
          <li>type (integer type code)</li>
          <li>recno (integer record number)<br>
          </li>
          <li>lifetime (storage lifetime requested, in seconds)</li>
          <li>data (a blob of data to be dealt with by the application
            however it wants)</li>
        </ul>
      </ul>
    </div>
    <br>
    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...<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 04.12.2012 06:14, schrieb Mark
      Webb-Johnson:<br>
    </div>
    <blockquote
      cite="mid:4B8F0243-53D1-41BB-889A-2F1EF2F8F2C3@webb-johnson.net"
      type="cite">Michael,
      <div><br>
      </div>
      <div>I really like this, but think it best to use a generic
        message type for historical data that can be supported in the
        server, and retrieved from the clients in a standardised way.</div>
      <div><br>
      </div>
      <div>Perhaps just:</div>
      <div><br>
      </div>
      <div>
        <ul class="MailOutline">
          <li>MP-0 H,<type>,<lifetime>,<data></li>
          <ul>
            <li>type (integer type code)</li>
            <li>lifetime (storage lifetime requested, in seconds)</li>
            <li>data (a blob of data to be dealt with by the application
              however it wants)</li>
          </ul>
        </ul>
      </div>
      <div><br>
      </div>
      <div>We can maintain a registry of 'types' - as they are just
        numbers, they can be vehicle specific, or general purpose.</div>
      <div><br>
      </div>
      <div>The server could then just store that in a special table. It
        can timestamp it when it receives the data, and generate an
        expiry date based on NOW()+<lifetime-seconds>, so that it
        can be auto-purged. It would be keyed by the vehicleid, type,
        and timestamp.</div>
      <div><br>
      </div>
      <div>So, not using carmessages, but cardata (or something like
        that).</div>
      <div><br>
      </div>
      <div>For access, we can just use the existing command/response
        functions (C/c).</div>
      <div><br>
      </div>
      <div>Does that make sense? If so, I can get server support for
        this quite easily and quickly?</div>
      <div><br>
      </div>
      <div>Regards, Mark.</div>
      <div><br>
        <div>
          <div>On 2 Dec, 2012, at 4:00 AM, Michael Balzer wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <div>Hi Mark,<br>
              <br>
              this is my first draft of a battery data protocol as
              implemented in the Twizy module 2.0 (see
              vehicle_twizy_battstatus_msgp()).<br>
              <br>
              For each battery pack (min 1), a message of type "B"
              transports the current state and collected min/max values:<br>
              <br>
                 // Output pack status:<br>
                 // MP-0 B,<packnr>,<nr_of_cells><br>
                 //  ,<volt_alertstatus>,<temp_alertstatus><br>
                 //  ,<soc>,<soc_min>,<soc_max><br>
                 //  ,<volt_act>,<volt_act_cellnom><br>
                 //  ,<volt_min>,<volt_min_cellnom><br>
                 //  ,<volt_max>,<volt_max_cellnom><br>
                 //  ,<temp_act>,<temp_min>,<temp_max><br>
              <br>
              The units now are 1/100 % for the SOCs, 1/100 V for the
              voltages and 1 °C for the temperatures. Maybe floats are
              more readable / standard for SOC & V?<br>
              <br>
              Alert status are enums of...<br>
                 0 = unknown<br>
                 1 = nominal<br>
                 2 = suspicious<br>
                 3 = alert<br>
                 4 = fail<br>
              <br>
              For each cell in each pack, a message of type "H"
              transports the cell details accordingly:<br>
              <br>
                     // Output cell status:<br>
                     // MP-0 H,<packnr>,<cellnr><br>
                     //
               ,<volt_alertstatus>,<temp_alertstatus>,<br>
                     //
              ,<volt_act>,<volt_min>,<volt_max>,<volt_maxdev><br>
                     //
              ,<temp_act>,<temp_min>,<temp_max>,<temp_maxdev><br>
              <br>
              Numbering of packs and cells begins at "1" to reserve "0"
              for an "all" selector.<br>
              Alert status uses the same enum scheme as on the pack
              level.<br>
              Voltages on the cell level are in unit mV, temperatures in
              °C. The maximum deviations are signed to reflect the
              direction of the deviation.<br>
              <br>
              Of course, a cell need not be a physical cell, it's just
              the smallest monitorable unit in a pack. Monitoring huge
              packs will not be possible with the current OVMS hardware,
              unless we consider streaming all sensor data to the
              server.<br>
              <br>
              I thought about how much could be stored in the server now
              and had a first look at the current server implementation.
              The primary key of table "ovms_carmessages" would need to
              be changed, as it currently is bound to just the message
              type character (and also case insensitive, reducing the
              number of possible message types). The key would need to
              be extended by the packnr on "B" messages and the pack +
              cellnr on "H" messages.<br>
              <br>
              So, generally speaking, we could introduce 2-3 key
              extension columns that can be used dynamically based on
              the message type. That would also enable storing of other
              historical records. To keep the database clean, an expire
              mechanism could drop all rows older than e.g. 24 hours.<br>
              <br>
              Please comment.<br>
              <br>
              Regards,<br>
              Michael<br>
              <br>
              -- <br>
              Michael Balzer * Paradestr. 8 * D-42107 Wuppertal<br>
              Fon 0202 / 272 2201 * Handy 0176 / 206 989 26<br>
              <br>
              <span><dexter.vcf></span>_______________________________________________<br>
              OvmsDev mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
              <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>