Author Topic: TED 5000: Parsing Raw Second History Data  (Read 7804 times)

tsmith

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
TED 5000: Parsing Raw Second History Data
« on: July 21, 2011, 04:46:38 AM »
I'm trying to parse the second history data from it's raw base64 representation into a json object. I've written a function that converts it from base64 into an array of bytes. I'm able to parse all the time related bytes into their respective decimal values, but I'm having a difficult time parsing the power, cost and voltage into their decimal values.

Is there any extra steps or implied formats that I'm overlooking? For example, how would i parse these binary representations of voltage and power into their decimal values:

Voltage: 01101010 (indx = 14) 00001001

Power: 10101010 (indx = 6) 00010110 00000000 00000000

Thanks,
Tristan Smith

tsmith

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
Re: TED 5000: Parsing Raw Second History Data
« Reply #1 on: July 22, 2011, 09:19:29 PM »
I used this tool: http://home2.paulschou.net/tools/xlate/ to verify I'm converting the base64 to binary properly. This is the string I tested with: CwcWDQwNGgoAACMAAAB2CQ==. The api states that the 14th and 15th bytes represent the voltage as an unsigned int, but I'm failing to see how the following value can represent a voltage 01110110 00001001. When I convert to decimal I get 30217.

Any ideas?

Thanks,
Tristan Smith
 

rotus8

  • Sr. Member
  • ****
  • Posts: 315
  • Karma: +0/-0
Re: TED 5000: Parsing Raw Second History Data
« Reply #2 on: July 23, 2011, 02:32:00 AM »
Why not use the XML interface instead? It is much easier to parse than base64.

GAR

  • Full Member
  • ***
  • Posts: 131
  • Karma: +0/-0
Re: TED 5000: Parsing Raw Second History Data
« Reply #3 on: August 03, 2011, 08:12:12 PM »
110803-1206 EDT

tsmith:

What voltage do you expect?

01110110 converts to 118.

.

SherlockOhms

  • Full Member
  • ***
  • Posts: 168
  • Karma: +0/-0
  • Sherlock
Re: TED 5000: Parsing Raw Second History Data
« Reply #4 on: August 16, 2011, 12:16:20 AM »
Because raw binary is MUCH faster.


Why not use the XML interface instead? It is much easier to parse than base64.

rotus8

  • Sr. Member
  • ****
  • Posts: 315
  • Karma: +0/-0
Re: TED 5000: Parsing Raw Second History Data
« Reply #5 on: August 16, 2011, 12:34:35 AM »
Agreed, but depending on how much data you are processing, other mechanisms may dominate. If it was me, I would start by making the application work with XML (which I have done), and then convert if it turned out to be too slow or use too much computer power (which I have not done, because it's fast enough).

hnrsoftware

  • Newbie
  • *
  • Posts: 21
  • Karma: +0/-0
Re: TED 5000: Parsing Raw Second History Data
« Reply #6 on: February 17, 2013, 09:49:52 PM »
I know this is an antique thread, but the answer to the problem is that the 2 and 4 byte binary values are presented low byte to high byte.  I spent a few hours pounding my head against the wall, but with a valid base-64 function (it took a while to find one for Delphi 6), I can successfully decode the various RAW formats.

Reason for use - I want to maintain minute history data for periods beyond 48 hours.  The API CSV  retrieval takes roughly 20 seconds (per mtu) to fetch the 48 hours worth of data, but RAW can do it in about 2 seconds.  It appears that the gateway processor bogs down converting large amounts of data, even to csv, but it handles RAW retrievals pretty quickly.

I am puzzled that there does not appear to be any links to the API documentation through the TED website - it is there at http://www.theenergydetective.com/developer-api# but I have to find it through Google.