Monday, 28 January 2013

Continuation of SAMIL update

1 comment:

Continuation of an update to:

My experience of Networking to our
SAMIL River 5200TL-D Solar Inverter 

I was having trouble publishing the graphics in the last post
so decided to start a new post to continue my findings

As you can see from this example, a recent file does in-fact have a value in the starting data row for the "Daily Energy[KW.Hr]" yet it appears to have accurately started recording the days data when the generator came online
Now we have the Daily file successfully loaded in Excel we can do all sorts of things with it like recalculating wrong values, manually updating or removing figures etc, SO LONG AS WE MAINTAIN THE CORRECT FORMAT in every row, column and cell and at the end of the day the cells must all have text-only data in them

When it comes to saving the file, there is one more trick.
We need it as Text yet in CSV format.
If you ask Excel to save it as Text it will tab-delimit it
If you ask it for CSV it will mess with the date format.
Choose File - Save As - Other Formats - CSV (MS-DOS) ( *.csv)
Give it a Name and choose Save
Answer Yes to the format warning
Exit the SolarPower Browser (if loaded)
Ensure the modified file is correctly named back to your-generator-name.csv
Copy the modified file back into the respective daily directory
Restart the SolarPower browser

If you did everything right the browser should load and you should be able to navigate to that modified day's graph without the browser throing an exception and crashing!
If it does, then you can always copy back in the unmodified original file.

A couple of other notes:

If the final generated value of  "Daily Energy[KW.Hr]" is not carried down to the last row, no value will be transferred to the daily history .csv in the Power folder and there will be a 0.00 entry for that day which you will then have to anually correct.

It does seem to do this occassionally

The thing to watch out for with the Power version of your-generator-name.csv, is that the date format is different!
In this one it is yyy-mm-dd and no time (as opposed to the yyy-m-d h:m:s format)

One last note is that the value for the cumulative graph appears to come from the total of the values maintained in this Power version of your-generator-name.csv so if the daily values in that are wrong, so too will be the cumulative total graph

I hope someone finds this useful.
If it proves helpful, please leave me a comment so I know my time was worthwhile.

An Update to: My expierence with our SAMIL 5200TL-D Solar Inverter


As of the 26th January, I have had no response to the inquiry I sent to
on the 3rd January
In the meantime, I have been running over CAT5, with no communication difficulties whatsoever.
What I HAVE had difficulties with however, has been the reliability of the logging software in the SolarPower Browser software!
The Software has four primary views:
 Daily generation:
Daily History
Cumulative Total

 I first noticed something amiss when the Daily History view showed we had generated 59KWh in one day!
To cut the long story short, the software downloads the data from the Samil at the intervals you choose under  Settings -- Data Record


and stores them at the location specified therein under the Daily and Power folders
Every Daily folder has a file named the same as every other day using the-name-of-your-inverter.csv 
which is terribly unhelpful when troubleshooting, as I will explain.

The Power folder also contains a csv ... of the same name ... BUT with a different internal format and content (DONT get them muddled up or you've lost all your historic data)
Note: The Fault Info folder follows the same Daily structure though fortunately we seem to have almost no entries in there except when we lost power

Each of those Daily directories contains the noted csv for the named generator(s) and those csv's are essentailly a flat-file history database and they have a VERY specific format.
If you mess with that format even slightly, the Power Browser won't load or crashes when you move to a particular day's data.
Daily csv files MUST have the following:
  • all fields are comma delimited except the last field in each data row which is terminated by a CR
  • only one CR after the last entry in the last row of data (no blank rows)
  • the correct number formats in the fields i.e. 0 or 0.0 or 0.00 as the case may be
  • NOTE: even though the number formats must be exact ... THEY ARE STORED AS TEXT not numeric fields
  • there must be no leading or trailing blanks either side of a comma delimiter
  • the date time format must explicitly be yyyy-m-d(1 space)h:m:s
    e.g. 2013-1-25 1:2:8  (which represents 25th Jan 2013 at 01:02:08 am)
  • the "Total energy[KW.Hr]" value in the last data row must be the starting value for the next day
  • the same for "Total operation hours[Hr]"
  • It doesn't seem to matter if the first row of "Daily Energy[KW.Hr]" has a value or not, so long as the highest accrued value for the day in that column is then carried all the way to the last row after the generator goes offline AND so long as it doesn't try to accrue the new day's data to the previous day's total
So each day the "Total energy[KW.Hr]" and the "Total operation hours[Hr]" values are supposed to carry forward from the previous day but the "Daily Energy[KW.Hr]" is supposed to start afresh at the time the generator comes online each day.
As noted above, it does not normally seem to matter if there is a value in this field as it appears to nearly always start at the first sample value and accrue from there throughout the day.
EXCEPT on these particular days when it carried the previous day's value forward and for some reason accrued the day's values onto the total of the previous day!
At the same time, this messes with it's Total energy[KW.Hr] count as that is based on the running total of what is generated at each sample throughout each day.

So when the data gets messed up, the only option that I've found so far is to manually rebuild the damaged file(s) ... and it pays to do it when first noticed so the erroneous figures don't get propagated to too many daily data files !
 Opening these files in a text editor and attempting to fix them that way, is a right royal pain, because the field columns all stagger according to what data is in them, yet to put them into readable columns using Excel or Word or Textpad or anything which formats them in any way, breaks the format of the file and it will no longer load.
For example, opening the file as a csv in Excel changes the date format when you import it and puts space padding around  the comma delimiters when you save it ... unless you do it this way;
The trick is:
  1. Before doing anything with the file, MAKE AN UNTOUCHED and RENAMED COPY !!!!
  2. Make a further copy of the file, this is the one you will try and fix
  3. ULTRA important! ... RENAME the file copy from .csv to .txt
  4. Load Excel
  5. Choose File - Open
  6. Select Files Of Type: Text Files
  7. Browse to and open the the renamed daily .txt file copy you made at steps 2 & 3
  8. Now because it is seen as a .txt file and not a .csv file, Excel will allow yo to manipulate the fields as they are loaded, so on the first dialog just accept the defaults of Delimited, Start at row 1, MS-DOS (PC-8) then Next
  9. For delimiters, un-tick Tab and tick Comma then Next
  10. On the next dialog select the first General heading (Time column will highlight)
  11. Scroll all the way to the right-most column, press and hold the Shift key and click the heading of that right-most column (all columns should now be highlighted)
  12. In the Column data format radio button group, select the Text radio button then Next
You are good to edit the file.
... continued in next post due to formatting and publishing errors .....


Thursday, 3 January 2013

My experience of Networking our SAMIL River 5200TL-D Solar Inverter

The SAMIL has a variety of network connectivity methods and my objective was to get it connected to my LAN using WiFi

At the time of writing this blog entry, there are entries on many different forums describing the various difficulties experienced in attempting to get the WiFi communications working.

To date I have been partially successful so will document my findings here in the hope that they may help others attempting the same process.
Inverter model: As per title 
Software: Samil Power Co - SolarPower Browser V2.9.2.6
* Type: 10/100 Ethernet with two WiFi routers 
* LAN subnet address is 192.168.0.x
* Billion Router BiPAC 7800N serving DHCP for LAN and WiFi using WPA/WPA2-PSK Mixed 802.11 b/g/n on Channel 8 with ESSID visible and shared key
* D-Link Router DIR-615 WiFi using Auto (WPA or WPA2) TKIP and AES Mixed 802.11 b/g/n on Channel 8 with SSID visible and shared key
  1. Connected SAMIL to Billion router via RJ45 Ethernet cable (referred to as netting twine in the SAMIL manual!) 
  2. On SAMIL Esc to Home menu
  3. Down arrow to Settings then OK
  4. Right arrow and Down arrow to Network then OK
  5. Up arrow for "1" then Right arrow for next password digit - repeat for all digits then OKi.e. 1 1 1 1 1 1 OK
  6. For Ethernet Interface I initially tried Auto-IP/DHCP but could not get a connection
    Note1: I could find no trace of a DHCP request in the router Syslog for any unidentifiable MAC address
    Note2: The MAC address being used by the SAMIL LAN interface was NOT that shown in the SAMIL System Info screen but does belong to the same address-space owner (see below)
    Interesting side-note: The System Info screen shows a MAC address of 24:08:28:02:03:00 which when searched on sites like are unknown
    IF HOWEVER you invert the MAC address as I've seen some commercial Router interface cards do, you get 00:03:02:etc which co-incidentally returns the address-space owner as Charles Industries which further research shows as " ... Heavy-duty use inverters for sensitive electronics"
    Further side-note: The MAC address eventually displayed (via ARP -a) once the browser was connected and working over the LAN cable, was another unknown address ...
    18-08-1C-02-03-00, yet once again, if you invert that MAC you again get 00:03:02:etc which obviously resolves to Charles Industries again.
  7. Went back in and set to Manual IP, setting the device to along with all other other IP values such as subnet, gateway, DNS etc
  8. This time when I saved the settings the SAMIL appeared to reboot its software, after which I could effortlessly load and connect to the device using the SolarPower browser
  9. Doing an ARP - a on the PC with the browser running I ascertained the cabled MAC address as noted in (6) above.
  10. Next I selected the inverter name under the expanded "Inverters" list in the LH frame of the SolarPower Browser
  11. Selected the "Parameters" tab in the main frame of the browser
  12. Under Module Flag WIFI, I entered the SSID of my primary WiFi router (the D-Link DIR-615) and the Password (Shared Key) for that router SSID  then selected SAVE
  13. By the time I walked to the inverter, it appeared to be rebooting the software ... which it proceeded to do again and again and again (I thought I had stuffed it and it had gone into perpetual reboot!) then it stopped and returned to stable state.
  14. As soon as I got to the inverter I had unplugged the LAN cable but after the reboots stopped and I returned to my PC, I could not connect to the device.
    The hard-coded IP address ( was no longer reachable and I could find no trace of a DHCP request to issue an alternate IP.
  15. Back to the SAMIL and changed the IP setting to Auto-IP/DHCP. The SAMIL rebooted (once) but still no WiFi Connectivity
  16. Back to the SAMIL and changed the IP setting to WIFI, leaving the Ethernet settings untouched (Auto-IP/DHCP). The WIFI setting showed the correct SSID. The SAMIL the went into it's multiple reboot scenario again!
  17. When the rebooting finished, still no WiFi connectivity so reconnected the LAN cable but could not get to the device
  18. Reset the SAMIL to the Manual IP settings (incidentally, settings were still retained even after setting to use DHCP). SAMIL rebooted. I could again get to the device on the .40 IP address
  19. I then entered the ESSID of the Billion router and it's passkey and upon SAVE the SAMIL again did it's multi-reboot thing!
  20. Disconnecting the LAN cable and reloading the browser I now had WIFI connectivity BUT ...
    I could find no trace of a new MAC address in the tables or logs of EITHER of the routers!!

    I got called away from my testing.
  21. Returning several hours later there was no longer any WiFi connectivity.!!
  22. To cut a long story short ... going through the process of connecting the LAN cable, assigning a static IP, connecting the browser and re-saving the SSID which forces the SAMIL reboot process, seems to establish WIFI connectivity SOMETIMES but then always for only a short time.
    Unproven at this stage, but I suspect the WIFI connection is dropped when a WIFI group key handshake occurs!

In Summary

It looks like the SAMIL will only connect the WIFI following it's reboot cycle after updating the WIFI settings. Any subsequent disruption of the WIFI communication (pairwise group handshaking etc) seems to break the connection and it does not re-establish.

It also appears that the wired LAN connection will ONLY work with all IP details specified and will NOT acquire a DHCP address despite DHCP being alive and well for other devices on the network.

If you have any comments or feedback please do add to my findings here.

Update to this post here