update 13/6/2009: check out my new sunnybeamtool command line application.As mentioned in my previous post, I have a "Sunny Beam" appliance that monitors the electricity production of my solar panels. The Beam maintains a wireless connection with the inverter to capture the power data. The clean LCD display offers a nice graph and the module recharges its batteries with solar cells. In addition, the Sunny Beam has a USB connection to send the data to a PC. Unfortunately, the Sunny Beam uses no standard 'USB mass storage' interface, but requires a Windows-only USB-driver. SMA.de responded to my mail stating that "The Sunny Beam can only work on windows operating systems. Windows 2000, XP (32 and 64) and Vista (32)". It is sad to see that succesful companies ignore the fact that other operating systems like MacOS and Linux are becoming increasingly popular. I'm not a Mac-fanboy, but MacOS has around 9% market share according to this site.
Once the USB driver is setup under Windows, you must use the complex Sunny Data Control application to gather the data. It is not a simple program to use, especially for small scaled solar systems. You really need to dive into the manual to get started. SMA informed me that a new, simpler application will be released in the beginning of 2009. According to the sma-america.com site, this new program will probably be called 'Sunny Beam WebConnect'.
I tried to install the Sunny Data Control under the latest version of Wine HQ. By default Ubuntu provides an outdated version of Wine, but upgrading is well documented on the Wine site. The application installs seamingly and starts fine; I even managed to register the USB driver with the following command:
wine rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 Desktop/sbeamdriver/SBeamUSB.inf Next, I found out that SMA provides a C library, YASDI -- 'Yet Another SMA Device Interface' -- for generic low-level access to their inverter interfaces. The Yasdi-API has everything to convince me: it's LGPL, linux is supported out-of-the box, Java JNI wrappers exist and it has a nice layered architecture where the technical drivers are decoupled from higher layers like the protocol-handling. Unfortunatly, Yasdi has no USB driver. I contacted the author of Yasdi, to check if the Sunny Beam fits in the standard Yasdi-API framework concept, so it would be easy to add the USB driver to it. Bad luck, Heiko informed me that the protocol used in SunnyBeam is a little bit different from other -- I suppose older -- devices. In order to add the SunnyBeam module to Yasdi, the protocol-layers will have to be adapted. I suppose the YASDI support and development is frozen at SMA.
The suggestion I got from Heiko is to use VMware or VirtualBox to run a Windows-system. Since my system is dual-boot (Windows is the last -- painful -- option) this doesn't add much value to the setup. Other suggestions are welkom.
The device presents itself to Ubuntu as follows:
$ lsusb -v
Bus 001 Device 002: ID 1587:002d SMA Technologie AG
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1587 SMA Technologie AG
idProduct 0x002d
bcdDevice 2.00
iManufacturer 1 SMA Technologie AG
iProduct 2 Sunny Beam
iSerial 3 00024383
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 Sunny Beam
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
$ dmesg | tail
[ 3100.544038] usb 1-1: new full speed USB device using uhci_hcd and address 2
[ 3100.781392] usb 1-1: configuration #1 chosen from 1 choice
20 comments:
Hi !
Since we are planning to buy solar panels shortly, I was also investigating the use of monitoring devices for the installation.
I work with Apple computers (Mac OSX 10.5.6), and have some basic knowledge of Linux.
It would indeed be nice if the companies that make/sell these monitoring devices would include software also for Mac/Linux !
Too bad, most companies seem still to ignore the growing percentage of non-windows users...
Try to email them. If a lot of people ask for Linux support, there is a chance that they will support it.
I will use a Solarlog 100e from www.solare-datensysteme.eu. This way you don't need a PC to collect your data.
I am also looking for a Linux driver for the Sunny Beam. Any progress on this item yet?
OK, i'm gonna try it, snooping and analyzing windows usb communication, and write a linux driver for it. i can do it, i feel it. it cant be very hard with this document by hand.
Good luck with it ! I've also tried to snoop the commands with a USB-sniffer, you can even see the contents of these packects in Sunny Data Control (Ctrl - p). I've alreay succeed to access the device and receive general information about the chip. But you probably (at least I am now) get stuck when you arrive at the part where you send command to the device to actualy receive data from it.
And since I can't find anything about these commands on the net, I have even mailed them, ... I quited. I don't want to break/erase my Sunny Beam by sending a bad command.
Anyway good luck and I hope you succeed !
Here is an very intersting link !
http://256.com/solar/scripts/smadat-11-ze2203.pdf
greetz kevin
I made some progress, i sniffed data with SnoopyPro and found an unix timestamp in the returned data. When the host wants to have data from the device, it sends the data string:
7e ff 03 40 41 00 00 ff 00 10 00 0b 0f 09 00 07 ac 7e 01 00
This evening a result was:
01 60 7e ff 03 40 41 ff 00 00 00 50 00 0b 0f 09 00 01
01 60 00 64 33 0b 4a 01 00 00 00 00 00 00 00 ec 51 00
01 60 41 33 33 b2 41 68 5e 7e
And Sunny data control output was:
Pac 0 watt
E-Today 8020 Wh
E-Total 22400 Wh
I found out that 64 33 0b 4a = 4a0b3364 HEX = 1242248036 DEC = Wed, 13 May 2009 20:53:56 GMT
However, the date from the device is not interesting, we want Pac and E-Today! I am gonna try to analyze that, if someone could help me, it has to be somewhere in the area:
00 00 00 00 00 00 ec 51 00 41 33 33 b2 41 68 5e
I am not sure if you could destroy this device with wrong commands, i hope not, it was very expensive.
Made some significant progress now and found those Pac, E-today and E-total. There are 3 32bit floating points in the result.
00 00 00 00 = 0
ec 51 00 41 = 8.02
33 33 b2 41 = 22.4
The last 2 bytes is a 16 bit CRC check i think. I have to check that.
Next thing i am gonna do is to try to write a linux driver. Could take a while...
I read the PDF-document you found on the net Kevin. The complete protocol is written in there. The protocol is not as easy as i hoped, but with this document by hand, it can be done.
The thing is that i am a programmer, but not familiar with C and device drivers :(
things i found so far:
data send: 7e ff 03 40 41 00 00 ff 00 10 00 0b 0f 09 00 07 ac 7e
7e = start flag
ff = address byte (broadcast)
03 = a bit coded HDLC control field, 0x03 stands for unnumbered data blocks
40 41 = protocol used (SMA data telegram)
00 00 ff 00 10 00 0b 0f 09 00 = data telegram content:
00 00 = destination address
00 ff = source address
10 = control 'STRINGFILTER'
00 = packet counter
0b = command 'CMD_GET_DATA'
0f 09 00 = content:
09 0f = channel type
00 = channel Idx
ac 0f = frame check sequence, 16 bit check sum
7e = stop flag
data recieved: 7e ff 03 40 41 ff 00 00 00 50 00 0b 0f 09 00 01 00 f1 cb 09 4a 01 00 00 00 00 00 70 42 29 5c d7 40 ae 47 65 41 be d9 7e
7e = start flag
ff = address byte (broadcast)
03 = a bit coded HDLC control field, 0x03 stands for unnumbered data blocks
40 41 = protocol used (SMA data telegram)
ff 00 00 00 50 00 0b 0f 09 00 01 00 f1 cb 09 4a 01 00 00 00 00 00 70 42 29 5c d7 40 ae 47 65 41 = data telegram content
00 ff = destination address
00 00 = source address
50 = control 'ANSWER'
00 = packet counter
0b = command 'CMD_GET_DATA'
0f 09 00 01 00 f1 cb 09 4a 01 00 00 00 00 00 70 42 29 5c d7 40 ae 47 65 41 = content:
09 0f = channel type
00 = channel Idx
00 01 = number of data records: 1
f1 cb 09 4a = time/date in unix format
01 00 00 00 = time basis (1 sec)
00 00 70 42 = Pac (floating point, 60 WATT)
29 5c d7 40 = E-today (floating point, 6.7 kWh)
ae 47 65 41 = E-Total (floating point 14.3 Kwh)
be d9 = frame check sequence, 16 bit check sum
7e = stop flag
I found out that there are several ways to communicate with this USB device:
1. by writing a device driver (kernel module) and a program.
2. with usbserial and PPP (modprobe usbserial vendor=0x1587 product=0x002d).
3. usblib
4. usbfs
I tried option 3. I have written a little Perl program with module Device::USB. I have succeeded to write to and read from the device, but it isn't responding to any of my commands. Dont know why exactly. Still working on it.
I'm not getting any further. I posted my problem here.
I works (finally)!
[root@linux sunnybeam]# ./sbtool.pl
Sunny Beam, SMA Technologie AG
Serial number: 00033467
Pac: 8 Watt
E-Today: 3.56 kWh
E-Total: 93.26 kWh
Soon, i will post i link where to download this program...
My program can be downloaded here.
Hi, I have some questions I would like to ask Stefan, as you seem to have dug deepest into territory with the SMA Net protocols that I am trying to unravel as well.
I am trying to get an embedded controller to talk directly to SMA inverters using SMA Net protocols, and have run into trouble with the Frame Check Sum calcs.
Stefan, do you have a simple pseudo-code explanation of how the FCS is calculated for SMA Net? It looks like it should be a CRC-CCITT-16 algorithm, but when I try this on test data strings, I don't end up with the same FCS values as appear in, say, your recorded data streams.
I'm afraid I'm not a C programmer, and I can't work out the example code they give in the SMA Net data description manual (SMADAT-11-ZE2203) for their calculation of the FCS.
Also, I note you were able to extract out the date and time from the data strings you received from the Sunny Beam. Could you please give a brief description of how you went from the decimal representation to the actual date and time?
Finally, how did you identify what segments of the responses gave you Pac, E-Today and E-Total, etc.?
If you could steer me in the right direction to work these things out, I'd be very appreciative.
Many thanks,
Glen Johnston
Australia
Hi there...
There is an new YASDI patch available to use Sunny Beam with YASDI on Linux.
More here:
http://www.heiko-pruessing.de/projects/yasdi/yasdi.php
Best regards,
Heiko
I was wondering if you ever heard anything further from SMA about the 'webconnect' software. I don't see any information on their website about it, and so I'm wondering if it ever was released. I'm having a solar system installed and am debating between the Sunny Beam and the Sunny WebBox for a monitoring solution.
Hello,
I have a Sunny Beam (on the back: Type BEAM-BT.GR1, Version C1, in the software: Hardware C3, Firmware 01.07.06.R) that in Linux is visible as a usb storage device, but: Only when the beam can connect to the Sunny Boy! In the evening, when I have time to read out the values of the Sunny Beam, neither Linux nor Windows sees it as a usb storage device.
Furthermore, when there IS a connection, it shows up as /dev/sdd without a proper partition like /dev/sdd1. It's not necessary because I can copy the .CSV files anyway but I think normally the "drive" should have a partition.
The strange usb storage behaviour I mentioned was caused by a defect. I got a new Sunny Beam and it works normally.
Stefan,
I'm trying to use your Perl to communicate with a SB3800, but using RS485 serial over a wire rather than Bluetooth. I've tried to amend your code, but my Perl is weak, is there any possibility of a bit of help?
Many thanks,
Lee
Post a Comment