Anyone using the Fronius inverter add-ons?

Thx!

It may have changed, but the Fronius interface card and proprietary
software cost $700, and never worked on either of my PCs. I even did a
clean install on a second disk drive. Then it communicated, but never
captured data, although I could see real time monitoring.

The data kept on the PC is in Access, so you could get at that data via
ODBC or some other MS-Access interface, but it isn't common serial data at
any point. It travels via RS422, if I recall correctly, to a USB converter
at the PC.

Support was not helpful. The answer was pretty much "it works here".

In retrospect, unless the system is remote, there is nothing to be gained
via software verses a pencil and paper.

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

Clarence -- I'm not sure what has changed completely with them, but
the protocol is wide-open now
and any program or system that follows that protocol should be able to
download the data. The data
does travel from the inverters to the data logger box in RS485 format,
but the connection between the
PC and the data logger is in RS232 according to this link:
http://tinyurl.com/2mjup8

Below is the link to the protocol documentation on their site -- the
first half of it is written in German(?)
but the 2nd half is in English. According to the spec sheet above,
there's capacity for ~1000 days in their
data logger module -- you might have some good data to download if you
wanted to tinker with writing a
program I guess.. In my case, my data will be sucked out of the data
logger on a daily basis by a Linux
server I've got and I'm thinking that I'll have a set of web-pages
updated in real-time showing output,etc..
Mostly because I've got to run this server anyway for a side-project
and I might as well be able to see
what the inverters are up to.. Should be interesting..

Protocol Docs:
http://tinyurl.com/359rty

I disagree. Without logging, and seeing unexpected spikes or other
unexplainable curve forms, I would not have found ot that the inverter
shuts down sometimes due to the varying frequency of the public grid.
Support was very helpful in THAT case, and we did solve the problem by
widening the acceptable frequency range. Maybe they are not good for
Software installation problems.

The software itself is - eh - very primitive. It does not

- report errors (unless you add a modem, AFAIK)
- show a daily curve, just the rough data (but in detail including
resistance etc.)
- allow external access, apart from the Access database (which contains
just the historical data, not the current one... and the software does
only fetch and write the historical data once a day...)

The protocol is proprietary, so you're stuck with their software.

You can get the new "Interface card", which allows you to program an own
application, but which does not give you access to stored (historical)
data, so the thing is not well thought through (mildly put).

There's some third-party software around for about $300 that claims to
be able to read the data. Well, it's just not worth for one small solar
system to buy this software, just to have the fun to look at the curves
in the internet...

I wouldn't buy Fronius again unless they solve this user-unfriendly
software chaos. Sunny seems much better, at least in that respect.

But then, I do have the IG40, and it works. Why complain for the
"inconvenience" not to be able to create nice online graphics...

Christian

This is ONLY for the interface card, which suffers from not supplying
the historical data, so it's not a real option ;-(

The example program's source code is not at all written by a
professional software developer, which explains a lot. They are hardware
manufacturer, not software developers.

It would have been enough to add new software to the data logger that
supports some new commands, or even publish the ActiveX control's
interface - both would not have needed the developement of a new device
(the "interface card"), and would not have published the protocol.

When I read your posting, I really hoped they would have finally
published it, but they don't as "it's a proprietary protocol also used
in all their other (welding?) machines, so it cannot be published"
(rough quote from what I was told).

Ch.

Ok.. You got me on that one.. I guess I hadn't noticed that their
'open' protocol
setup was only for "daily", yearly and whatnot sort of values which is
not
what I'm after.. You just saved me some money.. (8->

I have an idea though.. Why not run a USB port sniffer to monitor the
binary traffic between the device and the program? Something like :

http://benoit.papillault.free.fr/usbsnoop/

I've seen other hardware hackers pull this trick off before to reverse
engineer protocols that were 'closed'.. One nice thing is that more
than likely the protocol that flows over the USB port is probably very
close
to what is described in the open protocol manual -- they may have
expanded
or added a field to specify a date.. I don't suppose you'd be
interested
in giving that program a try to see what it sees? While I've never
written
any software that talks over USB, it's really just a fancy serial port
and not
much else. Their manuals even talk about using a USB->serial adapter
for
some applications.. Once we have some data, we should be able to
figure
out what the commands and data are.. Anyway, let me know if you're
game
or not..

[...]

I should note that if would be much easier to use a serial port
sniffer instead since the above mentioned program would also
spit out the raw USB protocol crap -- something we're not
interested in.. If the program supports communication over a
plain old serial port instead (using a USB-->serial adapter), that
would remove most of the initial pain.. Do you recall if it allows
a plain old serial port for communication?

If so, you could probably use something like this to sniff the data
stream:

http://www.serial-port-monitor.com/

That would be new. Mine was USB, and it didn't work.

Now that you've installed that, you will be pleased to find that error
messages from other programs will be auf deutsch, even after you uninstall
the Fronius software.

You're correct -- I was referring to the data logger/interface
(the combo box) -- it's got the proprietary USB crap but also has the
open protocol stuff that goes over the RS232 port..

Ahh.. I only downloaded their PDF -- no install for me.. I'll keep
that
in mind though IF I try their software.. I mostly run Mac's and Linux
at home..

I should have said $700 worth. If there were a free solution available, I
would use it. I spent many man hours trying to get the Fronius solution to
work, and it just didn't.

I thought it fetched fairly often, but only posted to the web site once
per day... but I forget. It was over a year ago. You could use their live
monitor, or you could tell it to fetch on demand, so the Access would be
fresh... but that never worked for me, so I can't really say.

I think so.

The problem is that no one wants to hack the Fronius protocol.
It costs $700 to get the hardware and software.

It's easier to buy a SunnyBoy that already offers a more open reporting
package... for free, as I recall.

Based on what I have read, it seems like it's
somewhat configurable in terms of how often
the data is fetched and "snapshotted" to the
data logger -- I specifically saw 30 minute
increments mentioned somewhere.

One other alternative (if someone can find the
technical specs in English) is the following device
for a bit under $500 -- the SolarLog for Fronius
(they also make them for other inverter mfg's
as well -- such as the SunnyBoy series)

http://tinyurl.com/2js5so

It basically plugs into the Fronius internal RS485
network and gathers the data from what I can tell
and then you can snarf that data via ethernet in
the form of CSV data.. I just wish I could read
german!

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

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.

Christian

I could help you there - what do you need?

Christian

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

Not the software I have. I can only give the day's time.

Ch.

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..

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

My email address on this post should work if my spam filter doesn't
kick you out.. (8->

Rings.. We've got something like that at work using fiber.. Ok..

[ ... ]

I figured it would be too easy if the protocol might be too close..

I'd be surprised if they messed w/ floating point values -- they're
pretty
standardized..

This way they can sell another piece of hardware that does a subset
of the data that actually flows across the interface..

Notice that ALL of these reply packets end in "32" which is an ASCII
space (not sure that is note worthy or not).. Seems like an
interesting
data point to me..

I think the "31 10 01" is probably some sort of fixed
string that is unit specific..

Cool.. Some of the work is done here (8->

I *think* that each response probably has the sender's details
embedded in it (see my comment above about the first 3 bytes)..
How many inverters do you have installed? My guess is that you've
got only one? My setup will have two inverters and I'd assume that
if there were multiple inverters, that you'd see another 3 byte
pattern in there -- perhaps something like : 31 10 02...?

Interestingly enough, the text string encoding is what the Pascal
language uses to encode strings -- back from my TurboPascal
days.. (8->.. They put a single byte in front of the string to
indicate
how long the string was.. Of course, C/C++ use null (zero) terminated
strings there..

[ ... ]

The "2e" above may be a command field perhaps?

The boxes may be setup to echo their input commands I guess
perhaps in a slightly more terse manner..

I guess we don't know if it's a truncated CRC, checksum
or something else..

I think it would be interesting if you could unplug the USB cable and
programmatically (or via a serial program) generate commands by hand
to their software.. You could feed it slightly different data blocks
to
see how the software responds.. I'll have to stare at some
of the data some more to see if something jumps out at me..

That's what I'm just doing at the moment. The program is communicationg
nicely - still I need a checksum algorithm first to be able to SEND data
that should be understood...

Might need to set up some brute-force testing application implementing
some CRC tests.

Christian

One must presume that they think it needs to remain proprietary to protect
their other property that uses the same protocol, I guess the welding
equipment. The open protocol must be a new development from scratch to
avoid conflict with the welding protocol. Why it needs to be proprietary
is unknown, but it's their equipment.

I decided after the fact that $700 was too much for me to spend for
monitoring, but I would like some monitoring. I don't know how much I want
to spend, especially for something bundled into competitive products.

pop the champagne! ;)

Big breakthrough today. I have found the checksum calculation
function!!! ;-) In disassembly, it's a horrendous complicated function,
but when deobfuscated (yes, they use an obfuscator!) it's quite trivial.

So now I can respond to the messages, and at the moment (my test
routine) I can query the configuration.

Enough of this phantastic feeling, back to the earth... I still have a
lot to find out, decipher, guess, ... but now I can start testing!

Chrisian

Of course I did notice that ;-) What remains unclear how the PC knows
that a sequence is finished.

Christian

Excellent news! I guess being patient and staring incessantly at bits
pays off sometimes.. (8->

They may either suck up data until some very short timeout occurs
(perhaps
a handful of milliseconds?) or perhaps they embed a value before they
start
sending the "bunch" which tells the PC how many replies to expect
with
increasing sequence #'s in each record sent.. I'd be tempted to lean
towards
the embedded side.. Let me know if you want some help staring at the
bits!

This unfortunately means that I have at most half an hour to log the
data exchange, correct and verify the code that communicates with the
inverter, after that time it's getting dark and the inverter does not
respond any more. I will improve the code reliability and the logger
interface, meaning historical data for example.

I can now also get and set the date and time in the inverter. I know a
bit of the "current inverter state" data, but it's a rather strange byte
stream, so when I have enough data - I guess it will be friday evening I
have time again early enough to commmunicate with the inverter - I might
ask you for some ideas about the internal data structure of the
"inverter display" state.

I'm glad I'm not in the US and I need not care about DCMA - here in
Germany it's even explicitly allowed to reverse-engineer code if it's
for the purpose of data exchange and interoperability, which is exactly
what I do it for.

Fronius should have read some security books first before relying on
code obfuscation. "Security by obscurity does not work". If the only way
to get the data is reverse-engineering, someone will do it. If they
would have offered an acceptable way to get at the data (current data as
well as historical), no one would care about their "proprietary" protocol.

Christian

I agree with your comments -- all they do is waste other people's time
by making them do the additional "work" to reverse engineer.. As I
live
in the states, I'm not sure if there's some paperwork I'll be signing
my
life away on which states that I'll not try to reverse engineer any of
this
sort of thing -- care of Fronius.. I'll keep my eye's peeled for that
sort
of thing.. I suspect not though since I'm just buying a really
expensive
consumer electronics device that comes w/ special installation
requirements et-al.

Regarding the lack of communication at night -- does the inverter just
refuse to communicate after a certain point in the day (or evening)?
That just seems odd -- I would think it would do the same thing it
does during the day but basically say that it's generating no power
and whatnot.. Hmm.. Interesting..

With the old proprietary card, the inverter did not stop responding at the
end of the sun day. The card continued to receive line power to maintain
the clock and volatile memory. I could get the "real time" readings,
everything from the front panel, including daily and yearly maximums and
totals, well after dark. After that card was removed, "year" totals were
no longer available, and the daily totals would restart after any outage.

I can communicate with the DataLogger, but not the Inverter, which is shut
off. This makes sense, as this saves some energy, and it does not have
anything new to tell me anyway as there are no "actual" values to report.

Christian

If I recall correctly, and I have really tried to purge most of my memory
of this abomination, the datalogger receives line power via the inverter
interface card, so that it continues to function when your PC is off.

That I would expect to see happen I guess and it makes sense since
it's
effectively playing the role of the archiver of data

As long as you use it with their inverters, it's probably fine..
I didn't see anything indicating their data logger would work with
anything but their inverter -- certainly not the Fronius.. (8-<
>

Logger Config :
Software=5.1.19,
'IG - Datalogger', ID=252.1673
Net date/time : 14.07.2007 10:04:19 (unk=6)
Inverter CUR : state 2
AC Power : 625 W
AC Curr : 2.83 A
AC Voltage : 221 V
AC Freq : 49.97 Hz
DC Power : 3.22 A
DC Curr : 210 V
R1 : 0.56 Ohm
R2 : >10000000000000 Ohm
Inverter DAY : state 2
PowMax : 650 W
AC Max : 227 V
AC Min : 220 V
DC Max : 248 V
RunTime : 4:29 h
Energy Tot : 0 kWh
Inverter YEAR : state 2
PowMax : 4334 W
AC Max : 231 V
AC Min : 16 V
DC Max : 304 V
RunTime : 2317:18 h
EnergyTotal: 2329 kWh
Inverter TOTAL : state 2
PowMax : 4336 W
AC Max : 233 V
AC Min : 16 V
DC Max : 312 V
RunTime : 8904:52 h
EnergyTotal: 8480 kWh

Greetz,

Christian

Christian -- is this from your own program or is this from the Fronius
s/w?
It sounds like you're on the right track!

Of course it's from my own!

Christian

Excellent.. I guess you're well on your way to ditching
the Fronius s/w altogether? Keep us posted please!

Is there some free visualization software for solar systems around, that can
deal with "foreign" data in some special format, for example XML, or a
database? I don't want to re-invent the wheel if I have an easy way for the
"display" part. Maybe I can hook to that...

Otherwise I will use RRDTOOL, which is just perfect except the fact that
changing the structure of a RRD database after it's created is very hard.

Christian

"Rick F." <ri...@dev.null> wrote in message
news:469dc4f0$0$4644$4c36...@roadrunner.com...

Well.. We're going to have 2 inverters later this summer (perhaps late August?),
but I'm not sure if I'll have the data logger right off the get-go or not due
to funding issues.. (we're over budget)..

I've not seen anything like that floating around, but I think that RRD is
a good choice at this point -- I've used it before and you're correct that
your info may be lost if you recreate or reconfigure the database..

Anyway, if I get my inverters with the datalogger, I'll drop you a note
later this summer if you're still stuck..

Look at www.invest-tools.com/pub/solsys, click "PV System > Graphs" at the
left side ;-)

This does not yet include the historical data stored in the DataLogger
(unimportant for anyone whose computer is always running), but it also shows
the public net's voltage and frequency deviations, which is fun to watch,
and a computed power of direct sunlight to compare scattered and direct
light's influence (the interests of a physicists...) ;-)))

There's still a lot of road ahead (monthly overview, ...), but I see the
path now.

Christian

Excellent! Very slick if you ask me! I ordered the other day a few of the
COM cards for our two inverters that will be installed in the middle of August..
I'll probably be ordering the Data Logger Pro and sensor box next week, so
you'll have a guinea pig to test the dual-inverter setup sometime in October
after we move back into the house.. I'll be taking lots of photos of the
work and can post a weblink if anyone is interested in the Solar panel install
& setup..

> Excellent! Very slick if you ask me! I ordered the other day a few of

Yes, I need these guinea pigs ;-)

I found someone with multiple inverters who sent me a comm protocol and
already included that feature - inverters should be automatically found and
added right now, but handled individually (possibly one feature will be a
comparison chart of all the local installations, let's see). I am also
thinking of simulating SolarLog data, so that applications like SunnyReport
can process these also.

For each installation you can give information about the azimuth and tilt of
the panels, so that the theoretical solar energy curve can be calculated
(which is of limited use, but fun). Also you can tell the program a "safety
time interval" from sunset and sundown which will prevent the program to
inform you about an inverter failure during that time, as these inverters
tend to send lots of errors in the morning and the evening. Sunset and
sundown are already calculated for the locality (given longitude and
latitude) automatically.

That's it for now. I'll keep you informed.

Christian

Christian,

Is it possible to share the software that you wrote to get the data
out of the datalogger? Currently I set up a computer macro to
download the detailed information every 5 minutes to a .csv file to
read into a database. If there is another solution to get the same
data without having that macro running it would be great benefit.

FYI: I have one Fronius IG 2500-LV with a com card and datalogger easy
box.

Thanks,

Mark