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