Omniksol communication, nearly there

[Gerardz]

I am using the Omniksol ("beta'/"in testing") communication. It is nearly there, but not completely. Specifically the "AVG Omnisol" is either 0 Watt, with irregular 1200 Watt values. This is also the value being send to PVoutput, e.g.: 0 ... 0.. 1200 ... 0 ... 0 ... 0 ... 0 ... 1200 ... 0... 0... 0... 0... 0...0... 0... 0... 1200...

Tests with the Omnik-Data-Logger/LiveStats.py seem to be working fine. The output seems correct too:

Id,Temp,VPV1,VPV2,VPV3,IPV1,IPV2,IPV3,IAC1,IAC2,IAC3,VAC1,VAC2,VAC3,FAC1,PAC1,FAC2,PAC2,FAC3,PAC3,ETODAY,ETOTAL,HTOTAL
NLDN2020XXXXXXXX,26.2,244.6,0.0,-1,4.0,18.1,-1,3.5,-1,-1,228.8,-1,-1,50.05,821,-1,-1,-1,-1,1.23,5.2,38

The AVG Omnisol amount it should retrieve there should to be "224.6". But is is not picking up that value. How can I correct that?

Regardz,
Gerardz

[Gerardz]

Laat ik er nog wat meer details van geven, in het kader van 'bump'

Op het moment dat er naar PVoutput zo'n average power van 1200 Watt gaat, wordt er dit in de database gekrast:

INSERT INTO "history" VALUES(598,1,1,1414593900,9.7,'20141029-15:45:00',302,244.2,1,244.2,100,0,18.1,0,0,0,0,0,0,229.6,0.8,205,0,0,0,0,0,0,0,0,50.05,0,0,20.8,1,0,1,1414593913);

Het door PVoutput ontvangen record ziet er voor dat tijdstip zo uit:

Date     Time   Energy   Efficiency  Power Average Normalised Temperature Voltage Energy Used Power Used
29/10/14 3:45PM 0.900kWh 0.450kWh/kW 205W  1,200W  0.600kW/kW 12.9C       229.6V  2.890kWh    10W

Bizar, want ik zie in het history record allemaal andere waardes, het is hier 18.1 graden in de history, en 12.9 volgens PVoutput. Waar komt toch die 1200 Watt Average vandaan? En welk stukje van mijn lokale history zou ik moeten vinden waar de bovenstaande PVoutput mee werd 'gecomponeerd'? Zit ik op een verkeerde plek te kijken? Want ook de history van vijf minuten ervoor en vijf minuten erna is het 18.1 graden in de sqlite database van WSL.

[Marco]

A quick response;

Temp = the temp that the inverter reports and not the outside temp. (where is your inverter located? outside? in a shed?)

Avg Power = calculate by PVo based on the power generated between two records. See this link for more info; http://pvoutput.org/help.html#intraday-defs

[Gerardz]

These are the four records in the WSL sqlite history table around that time:

INSERT INTO "history" VALUES(597,1,1,1414593600,9.6,'20141029-15:40:00',302,232.9,0.6,139.74,100,0,18.1,0,0,0,0,0,0,227.2,0.4,112,0,0,0,0,0,0,0,0,50.05,0,0,20.6,1,0,1,1414593622);

INSERT INTO "history" VALUES(598,1,1,1414593900,9.7,'20141029-15:45:00',302,244.2,1,244.2,100,0,18.1,0,0,0,0,0,0,229.6,0.8,205,0,0,0,0,0,0,0,0,50.05,0,0,20.8,1,0,1,1414593913);

INSERT INTO "history" VALUES(599,1,1,1414594200,9.7,'20141029-15:50:00',302,233.1,0.8,186.48,100,0,18.1,0,0,0,0,0,0,232.1,0.7,174,0,0,0,0,0,0,0,0,50.02,0,0,20.8,1,0,1,1414594219);
INSERT INTO "history" VALUES(600,1,1,1414594500,9.7,'20141029-15:55:00',302,242.4,0.9,218.16,100,0,18.1,0,0,0,0,0,0,230.4,0.8,206,0,0,0,0,0,0,0,0,50.04,0,0,20.9,1,0,1,1414594513);

These are the PVoutput records from those timestamps:
29/10/14    15:40    0.800kWh    0.400kWh/kW    112W    0W    0.000kW/kW    12.9C    227.2V    2.880kWh    100W   
29/10/14    15:45    0.900kWh    0.450kWh/kW    205W    1,200W    0.600kW/kW    12.9C    229.6V    2.890kWh    10W   
29/10/14    15:50    0.900kWh    0.450kWh/kW    174W    0W    0.000kW/kW    12.9C    232.1V    2.898kWh    40W   
29/10/14    15:55    0.900kWh    0.450kWh/kW    206W    0W    0.000kW/kW    12.9C    230.4V    2.901kWh    10W  

It all makes so little sense to me. And it is not just the communication towards PVoutput, my local graphs follow suit. Below image is pointed towards the 1200 Watt spike at 14:55, but the spike after that one pointed out, is the 15:45 spike.

[Marco]

The image is not working and could you share the link to your PVoutput page?

[Marco]

This looks like a rounding issue on the KWHT values reported by the inverter.

Could you take a look in your database in the table History and the column KWHT and see how many digits there are behind the comma?

It looks like the system produced on that particular day about 8-9kWh. The inverter reports only whole kWh's and after every produced kWh WSL spikes.

In that case we can't change this and there are a few other brands that has the same problem....

[Gerardz]

From what I see in the database, it is one digit behind the comma. I posted the database snippet around that time before, it is stripped here:

INSERT INTO "history" VALUES(597,1,1,1414593600,9.6,'20141029-15:40:00'

INSERT INTO "history" VALUES(598,1,1,1414593900,9.7,'20141029-15:45:00'

INSERT INTO "history" VALUES(599,1,1,1414594200,9.7,'20141029-15:50:00'

INSERT INTO "history" VALUES(600,1,1,1414594500,9.7,'20141029-15:55:00'

... so: KWHT (KiloWattHourTotal) is at 9.6 at 15:40, 9.7 at 15:45 (and now I see the relation: it produces the 1200 Watt spike), then 9.7 at both 15:50 and 15:55

In terms of resolution: if the convertor switches from a KWHT of "0.9" to the next level, it reports "1", and the next value would be "1.1", and basically reports all 'round' figures without a decimal. I mean, it is never like "2.0" or "14.0". I think I would be able to tinker the LiveStats.py into presenting 1.0 instead of "1" with a python equivalent of printf(""%.1f",$kwht), but if the rounding is also an issue switching from 9.6 to 9.7 I don't know how to prevent that.


[Marco]

Some inverter brands only report kWh and not Wh. 

For example;

Effekta only reports the whole kWh 1,2,3,1001,2034, etc on the RS485 interface...

And the webinterface of some models display all the data..

I noticed the data snipped, but there are no column names and that makes the very hard to read.

I Tried to add it to a test database, but that didn't work;

I/We can't make this work and the best way to solve this, is contacting the developer of the python script and see if he or she has a solution.|
maybe its a inverter model specific problem, maybe its a bug or ....

So please contact the developer and let u known if we can do something for you!

 

[Gerardz]

I'll try to explain it in a different way, on a different method. Here's the output from livestats.py --wsl:

Id,Temp,VPV1,VPV2,VPV3,IPV1,IPV2,IPV3,IAC1,IAC2,IAC3,VAC1,VAC2,VAC3,FAC1,PAC1,FAC2,PAC2,FAC3,PAC3,ETODAY,ETOTAL,HTOTAL
NLDN2020146S2070,21.6,236.0,0.0,-1,1.0,18.1,-1,0.8,-1,-1,220.8,-1,-1,50.02,197,-1,-1,-1,-1,0.72,22.4,100

Etoday in this request is 0.72 (today is a crappy day for being a PV). I recon this Etoday is what we talked about in the previous messages (KWHT). In any case, Etoday is two decimal points, Etotal is one decimal point. How would that give a rounding error? What needs to be changed to LiveStats.py for WSL being happy?

[Marco]

WSL needs a 3 decimal point KWHT (kWh Total) counter and at the moment thats the only way to make WSL happy.

Unfortunately that's the way we choose to develop WSL and allot of calculations are based on this counter.

Of course we could make something smart to workaround this "bug" and/or strange behavior of this type/brand of inverter. But that makes allot of simple calculation very complex.

[Gerardz]

So, the average production figure is solely dependant on what the inverter tells us. And WSL sees at 10:45 9.6 kW, and at 10.50 9.7 kW, hence in the last five minutes the production is supposedly 100 Watts. And 100 Watt every five minutes would be a 1.2 kWh production (12 times five minutes for the hourly rate). Right. And if you happen to have an Effekta inverter, it would show a 12 kWh production average in that single 5 minute slot where it shifts from 3 kW to 4 kW for instance.

I understand why it would be nice to have the inverter giving us a more precise value every five minutes. I checked the code, and it doesn't look like Wouterrr is simplifying the data LiveStats.py gets from the inverter. And don't know an email address from Wouter to verify my assumption.

However... we _do_ have production figures every 5 minutes with a rather decent resolution. How about if the inverter is only giving production averages in kW or 100 Watt increments, WSL would calculate the average instead? If we would simply take the production results from the last 6 or 12 measurements, and divide that by 6 or 12 and come up with our very 'own' calculated average? Or skew the average towards the last measurements: count Production_current 6 times, Production-5_minutes_ago 5 times, P-10 4 times, P-15 3 times, P-20 2 times, P-25 1 time, totalize and divide by 21 for an average skewed towards the recent production measurements. Wouldn't that be a great work around to resolution challenged inverters like the Omniksol, Effekta and the like?

[Marco]

Your first paragraph is a good description of the problem!

The second one is something i can't help with.

The the last and most tricky one;

Making assumptions are not OK.... In the past we tried allot with the Effektra inverters and that resulted in figures that were not 100% OK.

And when figures are not OK, users are complaining that figures are not ok and the make the assumption that we can and should fix it.

I know people with calibrated meters on the grid cable so the can check the figures reported by the Inverter and WSL. 

The problem lies in the inverter and i(!) think we should not try to fix that, because it results in more confusion because calculations and figures could get off.

[Gerardz]

I am merely suggesting to "do" something with the average, in case the inverter doesn't provide the means to give a decent insight. It is not like it would interfere with the actula production results. The only thing that people might argue about is how the average is calculated. The most defendable value (in case the inverter doesn't provide a sufficiently granualated one) would be: Production-current + Production-5_minutes_ago divided by two. That would beautify the locally created WSL graph. I did not figure out yet how to turn the average line in my graph to off by default, that would be another way to approach the issue.

[Gerardz]

Oh, by the way, there is another way to improve the resolution to PVoutput. The Omniksol has two counters:

EToday: 0.53 (2 decimals)
ETotal: 23.1 (1 decimal)

WSL sends its data for Energy generation using the c1=1 option (lifetime generation) and the amount ETotal provides. The resolution could be improved by not sending ETotal but EToday instead and omit c1=1.

[Gerardz]

I sort of hacked this in my current install. I'm not really proud of it and the change would not survive a WSL update (since it would be overwritten), but for the moment it serves my purpose. I changed:

usr/share/nginx/www/websolarlog/addon/PvOutputAddon.php

  // $v1 = $live->KWHT;//v1       Energy Generation       No1     number  watt hours      10000   r1 (replaced by next line)
   $v1 = $live->KWHToday;//v1      Energy Generation       No1     number  watt hours      10000   r1
and
  // $vars['c1'] = '1'; not lifetime here, 0 would be telling PVoutput we use the 'produced today' setting from PVoutput.
  $vars['c1'] = '0';

The KWHToday needs to be defined in /usr/share/nginx/www/websolarlog/classes/converters/OmnikConverter.php. I added just before the KWHT definition:

  // KWHToday from inverter
  if (!empty($data[20])) {
     $live->KWHToday = $data[20];
  }

With these two changes, WSL sends the EToday (the one with two decimals) to PVoutput.

Furthermore, I installed phpliteadmin.googlecode.com/ on my Raspberry, to be able to view and hack the wsl.sdb database file. Specifically, I wanted to turn of the Omniksol Average graph in the graphs WSL itself produces (since that is still based on my flaky 1200 W spikes). Here's what my graphs_series table looks like in phpliteadmin. With these settings, the Gas totals (no measurements available) are hidden alltogether, and the Omniksol Average is shown in the legend, but marked "do not graph". Again, I'm not pretending this is very nice work, but I wanted to get this lined up. And I thought somebody else might be able to retrace my steps. Or I myself revisit this page once 1.2.0 stable comes out and I need to redo the work :)

[Gerardz]

Hmm, well it is not all hunky-dory with this suggested change. PVoutput stopped processing my uploaded records after receiving 25 of them. WSL is claiming they are delivered (with an OK 200). It's not easy to debug what information exactly is being send to PVoutput (what string is leaving the system with the http://pvoutput.org/service/r2/addstatus.jsp request) and it is not easy to figure out what PVoutput received from their end. Sigh.It's hard not to become too dejected or unreasonably sad about all of this. Back to the drawing board. Sorry about the diary like addition to this forum.