Solar Freaks

Also, not sure why... but there is an EToday displayed on the LCD off the inverters , but not being outputted via serial ??

Maybe this might help

http://whirlpool.net.au/wiki/solar_software

Sunteams
The software is available from http://www.microsolar.at/Datenblaetter/SunteamsCOM.rar
This inverter may be identical to the CMS-2000. See cms2000-inverter-rs232-serial-port-hack-cms-2000-rs232-t271.html

Yeah , seen that post too.. have tried a few different versions, think ive tried that one too..

not sure but i suspect procontrol isnt too friendly, when it comes to running from a windows virtual machine... will need to uncomplicate things and set it up on a lappy, wired direct to inverter.

(mind you the perl script is also on an ubuntu virtal machine and it seems to be able to communicate ok via 'virtual serial'

* Version info:
substr outside of string at ./inverter.pl line 680.
Use of uninitialized value $hexData in pack at ./inverter.pl line 680.
CAPACITY : 002000
FIRMWARE : A4.14 M
MANUF : Inverter 2000
MODEL : odel: 2.0 KW


odel: ?

lol

Yeah I'm working on that now

Your RECV Data Format packet is different to CMS2000 & seems your RECV Version is also different

Here you go... you might need to play around with the Data Format though

Thanks i'll ive it a shot in a little while (got babies to put down for afternoon sleep , first..

umm what do i do with the protocol_tests.pl , doesnt seem to have references to com port etc ??

That's just what I've been using to plug in the 'version', 'data format' and 'data' hex protocol RECV strings for several inverters... to see how they match & whether they can be implemented in the inverter.pl script


Serial Communication Protocol files can be created per this post page2...
(PS only costs $ if u want to order the CD, otherwise free to download, just copy paste from 'output' window into your own text file & save it)

Ingmar wrote:Hi Matt ,

I was looking for the communication log.
There is a free program from HHD software that runs in parallel with the ProControl (or SunEzy Control). You can download it from http://www.serial-port-monitor.com/.

You need to start the program first, then the Control software, log some stuff, then close the Control program and finally the monitor software. It leaves the port open. The window you need is the Request view. Self explaining when you run the program.

The output is like attached to this post.

Cheers.. Looks pretty clean now..


root@ubuntu904server:/opt/solar/S0# ./inverter.pl
Running on linux
logfile = /opt/solar/S0/log/inverter.txt
Starting up...
Send -> req init: aaaa010000000004000159
Send -> req serial: aaaa010000000000000155
Recv <- aaaafe00000000800a413246534131333035340526
Send -> confirm serial: aaaa0100000000010c41324653413133303534000103ad
Recv <- aaaafe0100000081010602db
Send -> req version: aaaa01000001010300015a
Recv <- aaaafe0100000183303130303230303041342e313420204d6f64656c3a20322e30204b57202020496e766572746572203230303020333530300eb8
* Version info:
asciiVers=ªªþ01002000A4.14 Model: 2.0 KW Inverter 2000 3500¸
CAPACITY : 002000
FIRMWARE : A4.14
MANUF : Inverter 2000
MODEL : Model: 2.0 KW
OTHER :
SERIAL :
Send -> req data format: aaaa010000010100000157
Recv <- aaaafe0100000180011502ea
* Data Format:
dataToFollow = hex(01) = 1
* Data Format1:
TEMP 0
VPV 1
LAC 2
VAC 3
FAC 4
PAC 5
ZAC 6
UNK1 7
ETOTAL 8
UNK2 9
HTOTAL 10
UNK3 11
UNK4 12
UNK5 13
UNK6 14
UNK7 15
UNK8 16
UNK9 17
UNK10 18
UNK11 19
Send -> req data: aaaa010000010102000159
Recv <- aaaafe01000001822800c00e17002009ae138c032400000000001e0000000431010000000000000000000000000000000005d4
* Data:
TEMP : 19.2 deg C
VPV : 360.7 V
LAC : 3.2 A
VAC : 247.8 V
FAC : 50.04 Hz
PAC : 804 W
ZAC : 0 mOhm
UNK1 : 0
ETOTAL : 3 kWh
UNK2 : 0
HTOTAL : 4 hrs
UNK3 : 1254.5
UNK4 : 0
UNK5 : 0
UNK6 : 0
UNK7 : 0
UNK8 : 0
UNK9 : 0
UNK10 : 0
UNK11 : 0
Send -> req data: aaaa010000010102000159
Recv <- aaaafe01000001822800c30e1c001f09ae1390031100000000001e0000000431010000000000000000000000000000000005cc
* Data:
TEMP : 19.5 deg C
VPV : 361.2 V
LAC : 3.1 A
VAC : 247.8 V
FAC : 50.08 Hz
PAC : 785 W
ZAC : 0 mOhm
UNK1 : 0
ETOTAL : 3 kWh
UNK2 : 0
HTOTAL : 4 hrs
UNK3 : 1254.5
UNK4 : 0
UNK5 : 0
UNK6 : 0
UNK7 : 0
UNK8 : 0
UNK9 : 0
UNK10 : 0
UNK11 : 0
Send -> req data: aaaa010000010102000159
Recv <- aaaafe01000001822800c30e02002009a4138d02f200000000001e000000043101000000000000000000000000000000000686
* Data:
TEMP : 19.5 deg C
VPV : 358.6 V
LAC : 3.2 A
VAC : 246.8 V
FAC : 50.05 Hz
PAC : 754 W
ZAC : 0 mOhm
UNK1 : 0
ETOTAL : 3 kWh
UNK2 : 0
HTOTAL : 4 hrs
UNK3 : 1254.5
UNK4 : 0
UNK5 : 0
UNK6 : 0
UNK7 : 0
UNK8 : 0
UNK9 : 0
UNK10 : 0
UNK11 : 0
Send -> req data: aaaa010000010102000159
Recv <- aaaafe01000001822800c30dfe001e09a4138b02d100000000001e00000004310100000000000000000000000000000000075c
* Data:
TEMP : 19.5 deg C
VPV : 358.2 V
LAC : 3 A
VAC : 246.8 V
FAC : 50.03 Hz
PAC : 721 W
ZAC : 0 mOhm
UNK1 : 0
ETOTAL : 3 kWh
UNK2 : 0
HTOTAL : 4 hrs
UNK3 : 1254.5
UNK4 : 0
UNK5 : 0
UNK6 : 0
UNK7 : 0
UNK8 : 0
UNK9 : 0
UNK10 : 0
UNK11 : 0
^C
root@ubuntu904server:/opt/solar/S0#

Awesome

Huy guys, finally got a serial-port capture of what is happening via PVInverterCOM.exe..

Note , PVInverterCOM.exe.. seems to immediately be able to poll the inverter and pull back the EToday figure which i believe should therefore be in this capture, or somehow calculated from other values within.

Hope this helps better understand this inverter , and possibly the CMS2000 Series 2...

(See Next post.)

So what i did was this , started up serial-monitor.. launched PVInverter.COM , and 'connect' to inverter, which showed an EToday of 0.2 , and waited until it incremented to 0.3 .. 'disconnected' from the inverter.. took scrrenshot , and exited PVInverterCOM. performed the export from serial-monitor , and grabbed the log from PVInverterCOM, so all SHOULD be from same time period of test, and should correlate.

Hope it all helps...

Hi Garfin

Your EToday is output at bytes 21/22 - just after Pac (Power to grid)
On my inverter I just get FFFF here - which matches the 65535 Pro Control gives me for grid impedance.

Please see the latest script attached with this changed for you. You will need to uncomment the ST2000 specific values again.

Also, in your latest logs your data packet has the header aaaaff01, as opposed to aaaafe01 which you had earlier - so you may need to tweak that in the script also (RECV_QRY)

- Matt

Thanks for that.. i'll give it a shot, once the sun comes up

& your ETODAY uses 'DIVIDEBY' 10 instead of 100 too

Mmmm.... ??


./inverter_110214.pl
Running on linux
logfile = /opt/solar/S1/log/inverter.txt
Starting up...
Send -> req init: aaaa010000000004000159
Send -> req serial: aaaa010000000000000155
Recv <-
Send -> req serial: aaaa010000000000000155
Recv <-
Send -> req serial: aaaa010000000000000155
Recv <-
Match NOT FOUND ( aaaafe00000000800a ) after 2 tries.
Send -> req init: aaaa010000000004000159
Send -> req serial: aaaa010000000000000155
Recv <-
Send -> req serial: aaaa010000000000000155
Recv <-
Match NOT FOUND ( aaaafe00000000800a ) after 2 tries.



I used PVInverterCOM to 'talk' to the device , to get it back online again.. (still a mystery what it says that is different)

Now back online, i get..

Running on linux
logfile = /opt/solar/S1/log/inverter.txt
Starting up...
Send -> req init: aaaa010000000004000159
Send -> req serial: aaaa010000000000000155
Recv <- aaaafe00000000800a413246534131393039370533
Send -> confirm serial: aaaa0100000000010c41324653413139303937000103ba
Recv <- aaaafe0100000081010602db
Send -> confirm serial: aaaa0100000000010c41324653413139303937000103ba
Recv <-
Send -> confirm serial: aaaa0100000000010c41324653413139303937000103ba
Recv <-
Match NOT FOUND ( aaaaff0100000081 ) after 2 tries. Starting again.

So script believes its an aaaafe01 , but we saw an aaaaff01 in the Serial monitor of PVInverterrCOM , doing the same thing.

all too wierd...

Hi Garfin

As Matt suggested, your latest post using PVinverterCom shows different RECV_INIT & RECV_QRY strings... so you may need to edit the strings in the perl script for it to work

Code: Select all

#
# hex packet codes - COMMON
#
use constant {
    PKT_START             => "aaaa",
    # PKT_START_2           => "435a",                              # ST2000    SEND
    SEND_INIT             => "01000000",      # SRC_ADDR   + BCAST_ADDR
    SEND_QRY              => "01000001",      # SRC_ADDR   + DEST_ADDR
    RECV_INIT             => "00000100",      # BCAST_ADDR + SRC_ADDR
    # RECV_INIT             => "fe000000",                          # ST2000
    # RECV_INIT             => "ff007f00",                          # ST2000
    RECV_QRY              => "00010100",      # DEST_ADDR  + SRC_ADDR
    # RECV_QRY              => "fe010000",                          # ST2000
    # RECV_QRY              => "ff017f00",                          # ST2000
};


Extracts of your latest protocols (export.txt) shows RECV_INIT as 'ff007f00' (previously 'fe000000') and RECV_QRY as 'ff017f00' (previously 'fe010000') however the SEND strings are also different (eg: PKT_START for SEND is '435a' & 'aaaa' for RECV instead of 'aaaa' for both)

Code: Select all

initialise...
SEND -> 435A00007F00000300011F

get serial...
SEND -> 435A00007F00000000011C
RECV <- AAAAFF007F0000800A...etc...

confirm serial...
SEND -> 435A00007F0100010B...etc...
RECV <- AAAAFF017F000081...etc...

get data format...

get version info...
SEND -> 435A0000010101030000A3
RECV <- AAAAFF0101000183...etc...

get data...
SEND -> 435A0000010101020000A2
RECV <- AAAAFF0101000182...etc...


Extracts from your previous protocol:

Code: Select all

initialise...
Send -> aaaa010000000004000159

get serial...
Send -> aaaa010000000000000155
Recv <- aaaafe00000000800a...etc...

confirm serial...
Send -> aaaa0100000000010c...etc...
Recv <- aaaafe0100000081...etc...

get version info...
Send -> aaaa01000001010300015a
Recv <- aaaafe0100000183...etc...

get data format...
Send -> aaaa010000010100000157
Recv <- aaaafe0100000180...etc...

get data...
Send -> aaaa010000010102000159
Recv <- aaaafe0100000182...etc...


Regards
Shell

Try this instead... just uncomment the ST2000 constants (theres alot more now) & comment out their duplicate constant

shell_l_d wrote:Try this instead... just uncomment the ST2000 constants (theres alot more now) & comment out their duplicate constant

Thanks.. So excude my n00bness... but...

the 'default'
PKT_START_RECV => "aaaa",
and
REQUEST_DATAFMT => PKT_START_SEND . SEND_QRY . "0100000157",

i leave enabled, but comment out the other 'default' constants , uncommenting the ST2000 equivalents? (well thats what i assumed and did..) and got this..


Running on linux
logfile = /opt/solar/S1/log/inverter.txt
Starting up...
Send -> req init: 435a00007f00000300011f
Send -> req serial: 435a00007f00000000011c
Recv <- aaaaff007f0000800a4132465341313930393705b3
Send -> confirm serial: 435a00007f0100010b4132465341313930393700010381
Recv <-
Send -> confirm serial: 435a00007f0100010b4132465341313930393700010381
Recv <-
Send -> confirm serial: 435a00007f0100010b4132465341313930393700010381
Recv <-
Match NOT FOUND ( aaaaff0101000081 ) after 2 tries. Starting again.
Send -> req init: 435a00007f00000300011f
Send -> req serial: 435a00007f00000000011c
Recv <- aaaaff007f0000800a4132465341313930393705b3
Send -> confirm serial: 435a00007f0100010b4132465341313930393700010381
Recv <-


also , this is inverter 2... inverter 1, is now so dazed and confused, it wont talkserial at all.. will need to give it a full poweroff/reboot i think to get it back online again...

what i'll attempt to do tomorrow, is run a further PVInverterCOM / Serial-monitor capture, of BOTH inverters... just incase they do operate differently, somehow... (same Firmware rev. so dont understand why (other than serial no.) their comms should be different.)

That's right... but looks like it needs "01" (your current protocol) instead of "0001" (your old protocol)
for REQUEST_CONF_SERIAL_2

REQUEST_CONF_SERIAL_2 => "01",
# REQUEST_CONF_SERIAL_2 => "0001", # ST2000 - dont need this now

As it's sending this:
435A 00007F01 00010B [20charSerialNum] 0001 [cksum]

but really wants this:
435A 00007F01 00010B [20charSerialNum] 01 [cksum]