As announced, last Thursday we went solar!
It took me some time to take that final step and order the solar system, cause I’ve been interested in solar energy for a long time. But now that we finally have 12 solar panels on our roof I’m very satisfied with the end result.
I decided not to do this myself cause I knew that it would take me much too long – much, much longer than the 2 professionals did. They were done in about 6 hours and left me with a fully functional solar system:
4 rows of 3 x JA Solar JAM6-60/280-PR panels and an Omniksol-3k-TL inverter in the garage:
I’m very satisfied with how it all went – from the first contact with Sungevity to the point where the solar system was working.
No loose ends, everything is taken care of for you, from notifying 3rd parties that I’m gonna start producing energy soon and even the VAT refund (the EU considers you as a energy producer) is handled for a small fee.
All I had to do was sign some papers and provide the password of my Wifi Access Point to connect the Omnik inverter to Internet. Great job guys (and gals)!
Now on to the tech part of this post: the Omnik Internal Data Collector and how to use it.
Now that we have 12 solar panels on our roof I’d really like to be able to monitor them – myself, local and not on some portal. Fortunately Sungevity made it a standard procedure to install the Omnik Wifi kit. This kit uploads the performance data to the cloud and can be viewed from the Omnik portal.
But it would be even better if I’d be able to receive this information directly from the Omnik Wifi kit instead of heaving to log in on some portal and probably do some web scraping to get the data.
You can see the Wifi antenna of the kit on the picture to the left, right next to the grey cable. Now the really great part of this Wifi kit is that you can add your own ‘remote servers’ from the web interface – for instance, you can add your PC (bad choice) or a Raspberry Pi (better), or whatever – just enter the right IP address and port number and you’ll receive the same information that you’ll see on the Omnik portal. (you’ll have to do the charting thing yourself though 😉
The information looks like this (this one is invalid for obvious reasons):
68 81 41 b0 77 6f 7e 5f 77 6f 7e 5f 81 02 01 4e h?A°wo~_wo~_?..N 4c 44 4e 33 30 32 30 31 34 35 53 32 33 35 35 00 LDN3020145S2355. 45 08 42 08 3d ff ff 00 00 00 00 ff ff 00 00 ff E.B.=ÿÿ....ÿÿ..ÿ ff ff ff 08 89 ff ff ff ff 13 8b 00 00 ff ff ff ÿÿÿ.?ÿÿÿÿ.?..ÿÿÿ ff ff ff ff ff 00 00 00 00 00 31 00 00 00 17 00 ÿÿÿÿÿ.....1..... 00 00 00 00 00 ff ff 00 00 00 00 00 00 00 00 00 .....ÿÿ......... 00 00 00 00 01 4e 4c 31 2d 56 31 2e 30 2d 30 30 .....NL1-V1.0-00 38 33 2d 34 00 00 00 00 00 56 32 2e 30 2d 30 30 83-4.....V2.0-00 32 38 00 00 00 00 00 00 00 00 00 00 00 6d 16 28...........}.
Having the luxury of knowing what the Omnik Wifi kit uploads to the cloud and being able to see what it results in on the Omnikportal should not make it too hard to figure out the ‘where is what’.
But hey, wait, I’m not the first one that can think of this – let’s do some serious searching – maybe someone already figured it all out? And yes, there are various sources, even with code. With that information I had my NodeJS script running in no-time and saw the information being received. Nice, cause now I have the same information as can be seen on the Omnik portal. But I’m not done yet, cause I wanted some additional checks on the data received from the Omnik Wifi kit.
From the source code made by others I knew that the ‘checksum’ used was just a sum of all the individual bytes in the packet. So it wasn’t so hard to find out that the packets being received used the same method; in the example packet above, the 0x6d at the end is the low byte of the sum of all preceding bytes except the first one (the start-byte, 0x68).
Another thing is that it looks like the packet has a fixed header and always ends with the checksum + stop-byte (0x16). The size of this all is 14 bytes. So with a packet of 143 bytes this leaves 143-14 = 129 (0x81) bytes for the payload – aha, the 2nd byte in the packet is the payload size! Some more validity checks 😉
Right now my NodeJS script is running on a Cubieboard, collecting data and checking if the additional checks really work.