Sunny Beam under Ubuntu: SunnyBeamTool v0.6.0

http://sourceforge.net/projects/sunnybeamtool/

The sbtool Perl script of Stefan Arts provides a nice basic setup for accessing the Sunny Beam under Linux. But the Perl solution has some drawbacks: it is quite complex to set up and the codebase, with low-level hex-manipulations, is rather complex to extend, at least for an occasional Perl-developer like me...

With this in mind I translated the sbtool into C language and put it on sourceforge:

http://sourceforge.net/projects/sunnybeamtool/

The basic functionalities are included, but additional feedback, testing and extensions are welcome. Of course use at your own risk ! :-).

$ sudo ./sunnybeamtool
Dev #6: 1587 - 002D -SMA Technologie AG -
Serial Number: 00024383
pac: 0.00 W
e-today: 12.37 kWh
e-total: 1551.83 kWh

$ sudo ./sunnybeamtool -l
Dev #6: 1587 - 002D -SMA Technologie AG -
Serial Number: 00024383
pac: 0.00 W
e-today: 12.37 kWh
e-total: 1551.83 kWh

today:
...
2009-06-11 13:00:00: 756 W
2009-06-11 13:10:00: 888 W
2009-06-11 13:20:00: 569 W
2009-06-11 13:30:00: 205 W
...

last month:
...
2009-06-07: 11.790 kWh
2009-06-08: 10.060 kWh
2009-06-09: 8.480 kWh
2009-06-10: 12.370 kWh

This commandline is much easier and cleaner than running the full blown complex Sunny Data Control application under windows.

If your Sunny Beam doesn't respond to the USB-communication, try this: unplug the USB cable, switch a few times between daily graph and monthly graph, go to the menu and select 'exit', plug the USB cable. This should 'unfreeze' the USB buffer of the Sunny Beam. I never had to remove the batteries from my Sunny Beam device during all my experiments.

If you're still having trouble, send the output of 'sudo sunnybeamtool -l -v' in your bug-reports on sourceforge.

Other background info: I kept the libusb approach, as this allows the application to run in user mode, outside of the kernel. The development is done wih Netbeans 6.5 and Subversion as development platform.

Using the Sunny Beam under Linux: first steps!

update 13/6/2009: check out my new sunnybeamtool command line application.

In an earlier post, I discussed the missing Linux drivers for the Sunny Beam device. In the 'comments' section of that post, Stefan Arts dug deeper into the Sunny Beam protocol by 'snooping' the USB-communication with SnoopyPro. His findings were put in a very basic perl script on sourceforge. In order to run it I had to add some packages to my ubuntu 9.04 install:

sudo perl -MCPAN -e 'install +YAML'
sudo perl -MCPAN -e 'install Inline::MakeMaker'
sudo apt-get install libusb-dev
sudo perl -MCPAN -e 'install Device::USB'
sudo perl -MCPAN -e 'install Digest::CRC'

running:

sudo ./sbtool

Unfortunately, I didn't get any data back.

Update 1/6/2009:
The messages sent to the Sunny Beam have a device-dependent 'destination' field. Stefan suggested me to replace one line in the sbtool script:

my $CMD_GET_DATA="\x7e\xff\x03\x40\x41\x00\x00\xd4\xf5\x10\x00\x0b\x0f\x09\x00\x69\xda\x7e";

And, I get a successful response now:

$ sudo ./sbtool
Sunny Beam, SMA Technologie AG
Serial number: 00024383

Pac: 270 Watt
E-Today: 16.38 kWh
E-Total: 1427.98 kWh

3/6/2009:
Stefan now added CRC support and 'destination parsing' to his '0.0.4' version, so his sbtool script should work on any sunny beam device.

Cool, isn't it? Next steps:add the 'get daily details' and 'get last 31 days' calls to the script.Update

On a parallel track, I also noted that Alexander Morozov provided some USB-support to wine. This could potentially allow a Windows driver to be emulated in Wine. The fix isn't merged into the git source repositories and I couldn't evaluate it with the Sunny Beam USB driver yet.

Great to see this area moving forward :-).

background info:

• Details of the SMA protocol: http://256.com/solar/scripts/smadat-11-ze2203.pdf
• recap of stefans' findings:
• data sent: 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 received: 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
  
  
• 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
  
• 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
  
• where
  
• 64 33 0b 4a = 4a0b3364 HEX = 1242248036 DEC = Wed, 13 May 2009 20:53:56 GMT
• 00 00 00 00 = 0
  ec 51 00 41 = 8.02
  33 33 b2 41 = 22.4