Hybrid Car – More Fun with Less Gas

Anyone using the Fronius inverter add-ons? - Page 4

register ::  Login Password  :: Lost Password?
Posted by dold on July 4, 2007, 12:15 am
 

so you need the Fronius card inside the box, and someone else's $00 box.

--
Clarence A Dold - Hidden Valley Lake, CA, USA  GPS: 38.8,-122.5

Posted by Rick F on July 4, 2007, 12:59 am
 
On Jul 3, 5:15 pm, d...@09.usenet.us.com wrote:

Yup.. I did a bit of translating of the pages that were in German
for that device and it apparently has a built-in webserver such that
you can basically plug it into a (fronius) COM card and fire up
your favorite web-browser to see the info in real-time.. The data
can also be downloaded (via the web interface I gather) in CSV
format... I'd prefer to be able to download the RAW data w/o
needing to use a web-browser -- that way I can use a scheduled
task (aka cron job on Linux) to download the data on a daily
basis.  I guess I could use a "wget" command in Linux perhaps
to get the info -- maybe..

At this point, I think I've talked myself into just buying the
Data Logger Pro (since I'll have two inverters) and just
reverse engineering the data stream between the PC
and logger box and then I can ditch the provided software.


Posted by Christian Kaiser on July 4, 2007, 8:39 am
 
If you find out the protocol's internals, PLEASE let me know!!!! I tried
unsuccessfully (and I'm rather experienced at low-level debugging, but maybe
not a hardware manufacturer's way of thinking).

www.sysinternals.com have a serial port logger, if you need one.

Christian





Posted by Rick F on July 6, 2007, 5:20 pm
 
Christian --

Sorry for the late reply.. I haven't checked the groups in
a few days.. Anyway, I don't suppose you might have a
sample data stream to look at would you?  It would also
be very helpful if for the same sample data, you could
provide any info on what the software was displaying when
this info was gathered -- e.g. was it reading some sort
of power values such as 2217w or similar -- something
that I could use to key on something in the data stream.
I think once you can back-port a specific value that the
program spits out to something in the data stream, you
can somewhat go from there and try to extrapolate other
values as well.. I'm assuming there will be some sort of
command block from the computer to the data logger that
indicates what time frame to get the data for and it will
probably have a checksum.. The open protocol uses a
command block which starts with 3 0x80 values at the
front followed by a length field.. You could start by
looking at a data stream to see if you see a set of 3
values every once in a while -- it's unlikely to be a
value of 0x80 though.. I'd be somewhat surprised if
they had a 100% different protocol for the closed
interface vs. the open one.. Anyway, let me know..



Posted by Christian Kaiser on July 6, 2007, 10:40 pm
 Rick,

I can send you as much as you like ;-) The problem is the "current"
values that you also need - as these are updated any 2-3 seconds,
sychronizing data and values is a hard task... I guess when you're
serious, you will need to buy a data logger anyway.

Give me an email address (per PM if you like) and I'll send you some
data from portmon. I have 440 KB text log of the sequence "app startup,
query daily data, shutdown" for example. No 0x80 0x80 0x80 anywhere...

Next problem: the data logger forwards you the raw data that is on the
"RING", that is, any device that is connected to the logger can send
something any time (IG40, sensor card, Fronius software, ...), and some
messages can get mixed - the ring does seems not have any collision
protection. Taking these interleaved messages apart, or even detection
of the problem, is some "magic" with a checksum which is calculated by
an unknown method - so you cannot verify data (needs checksum
verification) or re-query data (unknown checksum creation). I even tried
to disassemble the OCX routines, especially looking for the checksum
code, but it was too much for a simple home project, so I gave up after
several hours. Yet I got to know and like the OllyDebug debugger ;-)))


I know. But unfortunately the internal data does not match the "open
protocol" at all. You're left on your own. I can tell you my heart was
jumping when I saw the docs about that open protocol, and how angry I
got after I saw it does not help at all, it was just a waste of time! It
even does NOT work - at least not when I tried - with the data logger,
just the interface card.

I guess that the coding of floating point values is the same in the open
protocol and the internal one, so there's a small starting point - but
it's just a guess at the moment.

This is why I'm angry at Fronius. It would have been so easy either to
put the protocol details into public, or let client software access the
data either via the Fronius Data Server (sic!) OCX (I snooped some
passwords for the OCX, which has the typical trivial protection agains
using in an IDE, so I can get at the methods and use them, but still
they use a lot of undocumented work and message interna I cannot
reproduce), or by letting their main application being an OLE server.
But NO, they decided to create a new hardware device that has an own
public protocol. Sigh!

Maybe someday I will continue working on my OLE spy, which helped me a
lot, but not enough...

In order to have something to do for your gray cells, let me show you
what I found out so far (actually, today, as I have found some time, and
the last time I looked was more than 2 years ago). Assume the
application on the PC starts, and the protocol starts:

The typical "idle" packet sent from the IG data logger which is repeated
a lot:

r: 31 01 00 00 00 01 FE 71 32

(as you will see later, this also tells us that the device "01" is
sending this, and it's a data logger ("FE"))

Once the PC reads that message, it answers with:

w: 31 01 00 00 00 01 FE 0E 00 10 FC D8 32
w: 31 10 01 FF 97 32

and gets as response:

r: 31 10 01 FF 00 05 01 13 00 0F 49 47 20 2D 39 32     
r: 31 10 01 FF 01 20 44 61 74 61 6C 6F 67 67 A3 32     
r: 31 10 01 FF 02 65 72 03 03 00 00 FC 00 06 69 32     
r: 31 10 01 FF 03 89 0A 44 61 74 61 6C 6F 67 62 32     
r: 31 10 01 FF 04 67 65 72 01 00 00 01 02 00 81 32     
r: 31 10 01 FF 05 00 0A 44 61 74 61 6C 6F 67 73 32     
r: 31 10 01 FF 06 67 65 72 02 00 00 05 01 13 C3 32     
r: 31 10 01 FF 07 00 0A 44 61 74 61 6C 6F 67 A1 32     
r: 31 10 01 FF 08 67 65 72 6D 32
r: 31 10 01 FF 09 0D 32     

(which is pretty much clear text, embedded in some framing and unknown
binary information, decoded and more suggestively layouted:

05 01 13 00 (data logger software has version "5.1.19")
<0F> "IG - DataLogger"
03 03 00 00
FC 00 06 89 (data logger PCB version 252.1673)
<0A> "DataLogger"
01 00 00 01
02 00 00
<0A> "DataLogger"
02 00 00
05 01 13 00
<0A> "DataLogger"
), and then a

r: 31 01 00 00 00 01 FE 71 32

(see the 'idle' message above)

Questions here:

- is the "empty" frame at the end a hint that this is the last entry of
such a group, or do we need to wait for the 'idle' broadcast? if the
latter, how do we know it's from the correct sender on the network?

- what's the binary data? it looks pretty unstructured - no length
information except the text's lengths (put in brackets above) to be seen

- what happens if a "32" would appear in the contents? It must be
escaped somehow! (case solved later, below)

- are binary data "encoded" somehow, as there's no readable length
information?

Then the app writes (just like before, some standard answer for that
'idle' broadcast?):

w: 31 01 00 00 00 01 FE 0E 00 10 FC D8 32

and issues a new command:

w: 31 0E 00 00 00 EC 32     

which gets as answer:

r: 31 0E 00 00 00 01 FE F4 32

and then a happy question and answer game begins....

w: 31 10 01 35 68 32
r: 31 10 01 35 FC 89 06 00 DA 32

w: 31 10 01 33 77 32
r: 31 10 01 33 0A 29 15 06 07 07 05 90 32

(the latter is the date/time: 2007-07-06, 21:41:10)

(This sequence "31 10 01 35 68 32", "31 10 01 33 77 32" is also an
important hint: the checksum is not a trivial "sum", might be some CRC)

w: 31 0E 00 00 00 0E 00 10 FC 45 32
r: 31 0E 00 00 00 0E 00 10 FC 01 FE 5D 32

r: 31 01 00 00 00 01 FE 71 32
w: 31 01 00 00 00 01 FE 0E 00 10 FC D8 32

w: 31 0E 00 00 00 0E 00 10 FC 45 32
r: 31 0E 00 00 00 0E 00 10 FC 01 FE 5D 32

w: 31 0E 00 00 00 0E 00 10 FC 45 32
r: 31 0E 00 00 00 0E 00 10 FC 01 FE 5D 32

I assume that's all some kind of "who's on the bus" message...

"10 FC" means "address 10 is type fc". Which is the PC.
"01 FE" means "address 01 is data logger"
"0E 00" means "address 0e is <...>", again something on the PC. Debugger
interface?

w: 31 10 01 35 68 32  << this was queried above also
r: 31 10 01 35 FC 89 06 00 DA 32 << still the same answer...

r: 31 01 00 00 00 01 FE 71 32
w: 31 01 00 00 00 01 FE 0E 00 10 FC D8 32

w: 31 0E 00 00 00 0E 00 10 FC 45 32
r: 31 0E 00 00 00 0E 00 10 FC 01 FE 5D 32

w: 31 0E 00 00 00 0E 00 10 FC 45 32
r: 31 0E 00 00 00 0E 00 10 FC 01 FE 5D 32

w: 31 10 01 35 68 32
r: 31 10 01 35 FC 89 06 00 DA 32

...

... several times, but here's something new starting: the PC querying
historical data!

w: 31 10 01 2E 07 07 06 D9 32 << again: the current date!

historical data starts with a date (no time can be given!), so it makes
sense to assume that's the command "fetch historical data starting 6th
july 2007")

and the logger answers:

r: 31 01 10 1B 1C 80 98 13 00 00 ED 32
w: 31 01 10 1B 1C 80 1B 1C 32

and now here's a new protocol. The message with the date ("get
historical date since...?") gets no identical answer as usual, but a new
message arrives from the data logger, which again is not (!) repeated in
its entirety (like all other ones), and here also:

r: 31 01 10 1B 1C 81 00 00 80 CC 32
w: 31 01 10 1B 1C 81 00 00 58 32

r: 31 01 10 1B 1C 00 08 00 01 08 00 DC 00 DF 00 77 32
r: 31 01 10 1B 1C 01 5A 00 E6 00 FC 00 06 89 01 FE 32
r: 31 01 10 1B 1C 02 02 00 01 00 0E 00 00 00 00 20 32
r: 31 01 10 1B 1C 03 00 00 00 00 00 00 00 00 00 1E 32
r: 31 01 10 1B 1C 04 00 00 00 00 00 00 00 00 00 68 32
r: 31 01 10 1B 1C 05 00 00 00 00 00 00 00 00 00 01 32
r: 31 01 10 1B 1C 06 00 00 00 00 00 00 00 00 00 BA 32
r: 31 01 10 1B 1C 07 00 00 00 00 00 00 00 00 00 D3 32
r: 31 01 10 1B 1C 08 00 00 00 00 00 00 00 00 00 56 32
r: 31 01 10 1B 1C 09 00 00 00 00 00 00 00 00 00 3F 32
r: 31 01 10 1B 1C 0A 00 00 00 00 00 00 00 00 00 84 32
r: 31 01 10 1B 1C 0B 00 00 00 00 00 00 00     

... and so on ... a lot of data blocks (the above shows the non-trivial
CRC!)

r: 31 01 10 1B 1C 1B 1B FF FF FF FF FF FF FF FF FF 13 32
r: 31 01 10 1B 1C 1C FF FF FF FF FF FF FF FF FF 65 32

...

r: 31 01 10 1B 1C 1B 1C 05 05 05 05 05 05 05 05 05 2B 32
r: 31 01 10 1B 1C 1B 1D 05 05 05 05 05 05 05 05 05 90 32
r: 31 01 10 1B 1C 33 05 05 0F 0F 0F 0F 0F 0F 0F D8 32

...
r: 31 01 10 1B 1C 82 04 00 2E 32
r: 31 01 10 1B 1C 83 13 99 3F 32

and that was all historical data, it seems.

The PC confirms this:

w: 31 01 10 1B 1C 83 8A 32

What do we seem to know or at least assume:

- "31" <ss rr> <xx> [<ii>] ... <cc> "32" is the frame of a message

ss rr = some device address scheme, possibly:
  ss = sender
  rr = receiver (00=broadcast)
  with:
  "01" = IG inverter
  "10" = PC
  "0e" = <yet unknown>
xx most likely a (device-specific?) command.
  "00": "hello... or I'm idling around"
    followed by "00" <id> <type>
  "ff": get some info (configuration?)
  "33" is "get current date and time"
    followed by <ssmmhhddmmyy> "05"
  "35" is <unknown>
  "2e" is "get historical data"
    followed by <yymmdd>
  "31" (encoded "1b 1c") is "info about historical data"
cc = checksum
ii block index (sometimes)

- in the contents, the "31" and "32" are escaped as "1b 1c" and "1b 1d"
respectively, while "1b" is escaped as "1b 1b". Makes sense.

- an answer usually starts with the same bytes as the corresponding
query (up to, but not including the checksum), and adds some more data.
This is most of the times, but not always (see historical query)

- the app is multithreaded, and can query some data in the middle of a
multi-block response

Christian

This Thread
Bookmark this thread:
 
 
 
 
 
 
  •  
  • Subject
  • Author
  • Date
please rate this thread