[SolarEdge] Omvormers en optimizers zelf monitoren

[Aegle]

Ik hanteer dezelfde methode als @Jerrythafast . Alleen dan naar de cloud. Één keer per week kopieer ik de laatste .pcap naar https://www.transip.nl/stack/.

Bij mij draait de software van Jerry sinds mei, juni vorig jaar. Het SD-kaartje heeft het nog niet begeven (klop klop)...

[jacovn]

Ik heb ook ooit een stack account genomen toen die gratis was, inderdaad handige backup.
Wel nog een samsung extreme 32'gb kaartje liggen, dan ga ik die wel gebruiken eerst. Staat op een website onder de juiste types als ik sorteer op een pi 2.

[ Voor 17% gewijzigd door jacovn op 17-04-2017 13:44 ]

[Jerrythafast]

Ik heb zojuist versie 0.0.9 van solaredge-logger online gezet. Drie fixes hierin:
- Af en toe kreeg je in liveupdate.py de melding 'Data loss: 0 bytes'. Dat sloeg natuurlijk nergens op.
- Het issue dat Yoki1985 had met pvo-upload.php vanwege de tijdzone op het westelijk halfrond is opgelost.
- Deze versie werkt ook met de firmware van de 3-fasenomvormer van andrerij.

Ik ben de afgelopen dagen ook weer bezig geweest met de monitoring website. Ik hoop deze maand een wat meer toekomstgerichte versie te hebben die op GitHub kan zodat we er samen aan verder kunnen klussen. Ik denk erover om in navolging van @ocaj ook de historische data apart te verzamelen (in aparte database tabellen of in losse bestandjes, daar twijfel ik nog over). Dan hoef je geen 'moeilijke' queries op de database te doen om de data van een bepaalde dag eruit te vissen. Of erger: de totalen van elke dag.

[ Voor 21% gewijzigd door Jerrythafast op 17-04-2017 22:44 ]

[jacovn]

Hoe zie zo een querie op MySQL er uit ?

[andrerij]

@jacovn de query kan er als volgt uitzien:

PHP:

<?php
$d1 = '2017-04-17 20:30:00';
$mysqli = new mysqli('localhost', 'USER', 'PASSWORD', 'solaredge');
$b = strptime($d1, '%Y-%m-%d');
$today_timestamp = mktime(0,0,0,$b['tm_mon']+1, $b['tm_mday'], $b['tm_year']+1900) - 3600*(1+date("I",mktime(0,0,0,$b['tm_mon']+1, $b['tm_mday'], $b['tm_year']+1900)));
$tomorrow_timestamp = mktime(0,0,0,$b['tm_mon']+1,  $b['tm_mday']+1, $b['tm_year']+1900) -3600*(1+date("I",mktime(0,0,0,$b['tm_mon']+1, $b['tm_mday']+1, $b['tm_year']+1900)));
$query = sprintf("SELECT
            Max(`e_day`) AS `solaredge`
            FROM telemetry_inverter_3phase
            WHERE `timestamp` >= %s AND `timestamp` <= %s", $today_timestamp, $tomorrow_timestamp);
$result = $mysqli->query($query);
$row = mysqli_fetch_assoc($result);
echo $query . '<BR>';
echo number_format($row['solaredge']/1000, 3, ',', '.') .  '&nbspkWh<BR><BR>' ;
$query = sprintf("SELECT
            Max(`e_day`) AS `solaredge`,
            `timestamp` AS `datum`
            FROM telemetry_inverter_3phase
            WHERE `timestamp` >= %s AND `timestamp` <= %s
            GROUP BY (`timestamp`) DIV 300
            ORDER BY (`timestamp`) DIV 300 ASC", $today_timestamp, $tomorrow_timestamp);
$result = $mysqli->query($query);
echo $query . '<BR>';
while ($row = mysqli_fetch_assoc($result)) {
    echo date("Y-m-d H:i",$row['datum']+ 3600*(1+date("I",$row['datum'])))  . '&nbsp&nbsp' . number_format($row['solaredge']/1000, 3, ',', '.') . '&nbspkWh<BR>';
}
?>
 

Als eerste wordt de database geopend.
Daarna wordt de locale datum omgezet naar UTC waarbij rekening gehouden wordt met de zomer- en wintertijd (...... - 3600*(1+date("I", ......). $today_timestamp is om 0:00:00 uur op de gekozen dag en $tomorrow_timestamp is de volgende dag om 0:00:00 uur.
Vervolgens wordt de query voor de maximale productiewaarde van de betreffende dag opgehaald.
De tweede query geeft de productiewaarde per 5 minuten over de gekozen dag.
De tabel 'telemetry_inverter_3phase' kun je vervangen door 'telemetry_inverter' voor een 1 fase inverter.

[Jerrythafast]

andrerij schreef op dinsdag 18 april 2017 @ 20:00:
@jacovn de query kan er als volgt uitzien:

PHP:

<?php
$d1 = '2017-04-17 20:30:00';
$mysqli = new mysqli('localhost', 'USER', 'PASSWORD', 'solaredge');
$b = strptime($d1, '%Y-%m-%d');
$today_timestamp = mktime(0,0,0,$b['tm_mon']+1, $b['tm_mday'], $b['tm_year']+1900) - 3600*(1+date("I",mktime(0,0,0,$b['tm_mon']+1, $b['tm_mday'], $b['tm_year']+1900)));
$tomorrow_timestamp = mktime(0,0,0,$b['tm_mon']+1,  $b['tm_mday']+1, $b['tm_year']+1900) -3600*(1+date("I",mktime(0,0,0,$b['tm_mon']+1, $b['tm_mday']+1, $b['tm_year']+1900)));
$query = sprintf("SELECT
            Max(`e_day`) AS `solaredge`
            FROM telemetry_inverter_3phase
            WHERE `timestamp` > %s AND `timestamp` <= %s", $today_timestamp, $tomorrow_timestamp);
$result = $mysqli->query($query);
$row = mysqli_fetch_assoc($result);
echo $query . '<BR>';
echo number_format($row['solaredge']/1000, 3, ',', '.') .  '&nbspkWh<BR><BR>' ;
$query = sprintf("SELECT
            Max(`e_day`) AS `solaredge`,
            `timestamp` AS `datum`
            FROM telemetry_inverter_3phase
            WHERE `timestamp` > %s AND `timestamp` <= %s
            GROUP BY (`timestamp`) DIV 300
            ORDER BY (`timestamp`) DIV 300 ASC", $today_timestamp, $tomorrow_timestamp);
$result = $mysqli->query($query);
echo $query . '<BR>';
while ($row = mysqli_fetch_assoc($result)) {
    echo date("Y-m-d H:i",$row['datum']+ 3600*(1+date("I",$row['datum'])))  . '&nbsp&nbsp' . number_format($row['solaredge']/1000, 3, ',', '.') . '&nbspkWh<BR>';
}
?>
 

Als eerste wordt de database geopend.
Daarna wordt de locale datum omgezet naar UTC waarbij rekening gehouden wordt met de zomer- en wintertijd (...... - 3600*(1+date("I", ......). $today_timestamp is om 0:00:00 uur op de gekozen dag en $tomorrow_timestamp is de volgende dag om 0:00:00 uur.
Vervolgens wordt de query voor de maximale productiewaarde van de betreffende dag opgehaald.
De tweede query geeft de productiewaarde per 5 minuten over de gekozen dag.

Klein tipje met datums, tijden en unix timestamps. PHP doet al die conversies vanzelf voor je

PHP:

//Unix timestamp van middernacht:
$t_midnight_today = (new DateTime("today 00:00:00"))->getTimestamp();

//Unix timestamp van middernacht morgen:
$t_midnight_tomorrow = (new DateTime("tomorrow 00:00:00"))->getTimestamp();

//Unix timestamp omzetten naar datum+tijd in de lokale tijdzone:
$datetimestring = date("Y-m-d H:i", $timestamp);

De queries zijn in principe correct, maar SolarEdge maakt het ons niet gemakkelijk: de e_day waarde begint weer bij 0 te tellen als halverwege de dag de omvormer wordt gereset, dus dan krijg je een te lage waarde voor de betreffende dag als je MAX(e_day) doet. De oplossing (als je het in een MySQL query wilt oplossen) is een gruwelijk ingewikkelde query. Ziehier een voorbeeld om van elke dag in april de minimum- en maximumtemperatuur (t_min/t_max in °C), de maximum 5-minutenoutput (de_max in Wh), maximum vermogen (p_max in W) en totaal energie (e_day in Wh) te krijgen:

MySQL:

SELECT date, MIN(temperature) t_min, MAX(temperature) t_max, MAX(de_day) de_max, MAX(p_active) p_max, MAX(se_day) e_day
FROM (
  SELECT
    IF(temperature = 0, NULL, temperature) temperature, de_day, p_active,
    @curdate := FROM_UNIXTIME(timestamp, "%Y%m%d") date,
    @prevsum := IF(@prevdate = @curdate, @prevsum + de_day, de_day) se_day,
    @prevdate := @curdate date2
  FROM telemetry_inverter
  JOIN (SELECT @prevsum := 0, @curdate := NULL, @prevdate := NULL) vars
  WHERE timestamp BETWEEN UNIX_TIMESTAMP("2017-04-01") AND UNIX_TIMESTAMP("2017-05-01")
  ORDER BY timestamp
) x
GROUP BY date;

Ik overweeg sterk om een tabel aan de database toe te voegen waar resultaat van bovenstaande query in staat. Het alternatief zou zijn om gewoon alle 5-minutendata op te vragen en in bijvoorbeeld PHP te verwerken. Dat bespaart opslag, maar kost wel wat meer bandbreedte tussen de MySQL server en PHP. En bij elke query moet die hele verwerking weer worden gedaan.

Het probleem met weer beginnen bij 0 is trouwens nog driedubbel zo erg bij de optimizers. Die resetten namelijk hun tellers als ze net effe te weinig licht op hun paneel krijgen om wakker te blijven.

[jacovn]

SQL is lang geleden toe ik op de HTS zat. De code eromheen zal ik ook wel uit gaan komen denk ik, alleen heb ik niet zo veel tijd en ik wil zo veel

[rense]

Jerrythafast schreef op dinsdag 18 april 2017 @ 21:26:
[...]
Ziehier een voorbeeld om van elke dag in april de minimum- en maximumtemperatuur (t_min/t_max in °C), de maximum 5-minutenoutput (de_max in Wh), maximum vermogen (p_max in W) en totaal energie (e_day in Wh) te krijgen:

Dat zijn de beter queries . Ik ben bezig met de database naar de NAS verhuizen, en dan uitleven op de getalletjes.

Ik heb mijn panelen begin november gekregen, de donkere dagen, dus ik begin nu eindelijk te zien wat ze kunnen met de langere dagen.

[3ssen]

Key uit de pcap file halen is uiteindelijk niet goed gegaan. Had na enkele uren een gedeeltelijke sleutel gevonden. Daarna was ik zo slim om de pi te herstarten en een nieuwe tcpdump te starten. Eerste gedeelte van de tcpdump werd dus overschreven.

Nu dan de optie geprobeerd om via usb aan te sluiten en dan de sleutel op te vragen. Hierbij heb ik de volgende uitdaging (of een nieuwe bril nodig). Ik kan namelijk nergens de usb aansluiting vinden. Begreep van een post van @tsjoender dat deze naast de ethernet aansluiting zou zitten bij de 3000H. Maar kan hem dus niet vinden.

Heb wel enkele foto's gemaakt van de binnenkant. Dus als iemand zo lief zou willen zijn om hem aan te wijzen hoor ik dat graag.

http://www.rick-annelies.nl/nieuwbouw/se/SE3000H_1.jpg
http://www.rick-annelies.nl/nieuwbouw/se/SE3000H_2.jpg
http://www.rick-annelies.nl/nieuwbouw/se/SE3000H_3.jpg
http://www.rick-annelies.nl/nieuwbouw/se/SE3000H_4.jpg
http://www.rick-annelies.nl/nieuwbouw/se/SE3000H_5.jpg
http://www.rick-annelies.nl/nieuwbouw/se/SE3000H_6.jpg

[tsjoender]

Ik kan die connector zo ook niet vinden. Het lijkt erop dat er een andere revisie van dat communicatieboard is waarop de micro USB connector weggelaten is (en misschien nog wel wat USB-serieel onderdelen). Hier jouw foto nog een keer met daarop omcirkeld waar die volgens mij had moeten zitten:

[3ssen]

tsjoender schreef op donderdag 20 april 2017 @ 13:38:
Ik kan die connector zo ook niet vinden. Het lijkt erop dat er een andere revisie van dat communicatieboard is waarop de micro USB connector weggelaten is (en misschien nog wel wat USB-serieel onderdelen). Hier jouw foto nog een keer met daarop omcirkeld waar die volgens mij had moeten zitten:

[afbeelding]

Fijn om te lezen dat ik dus geen nieuwe bril nodig heb.

Mocht er iemand nog een andere manier weten om de omvormer uit te kunnen lezen, dan hoor ik het graag.

[Aegle]

De oudere versies van het comm-board heeft blijkbaar geen USB-aansluiting op de print. De elektronica hiervoor schijnt wel aanwezig te zijn, echter is er geen connector op de PCB gesoldeerd. Hierbij een foto van mijn PCB in de SE3000:

[Jerrythafast]

Ai, dat is niet zo mooi Al lijkt het erop dat je er wel zo een terminal op zou kunnen solderen

Ik zie wel nog RS-485 aanduidingen op het PCB. Ik zou even de handleiding erbij moeten zoeken om te kijken hoe de installateur RS-485 zou moeten aansluiten op deze omvormer. Het moet toch sowieso kunnen zonder al te veel gerommel.....

[3ssen]

Jerrythafast schreef op donderdag 20 april 2017 @ 20:13:
Ai, dat is niet zo mooi Al lijkt het erop dat je er wel zo een terminal op zou kunnen solderen

Ik zie wel nog RS-485 aanduidingen op het PCB. Ik zou even de handleiding erbij moeten zoeken om te kijken hoe de installateur RS-485 zou moeten aansluiten op deze omvormer. Het moet toch sowieso kunnen zonder al te veel gerommel.....

Had inderdaad ook al wat gevonden over RS-485. Als ik dan de key maar kan achterhalen ben ik blij. Wordt dan denk ik sowieso spullen aanschaffen om te kunnen koppelen.

[Jerrythafast]

Ik vrees het wel inderdaad (hoewel er meer spul in de wereld is dat op RS-485 werkt, dus misschien gaat er wel een wondere wereld voor je open als je daar spullen voor in huis hebt ).

Laatste optie die ik kan bedenken (die is nog nooit geprobeerd, dus niet zeker of het werkt) is de omvormer terug te zetten naar fabrieksinstellingen. Dit is een optie in het installateursmenu en zal hoogstwaarschijnlijk tot gevolg hebben dat je lifetime opbrengstteller weer bij 0 begint te tellen. De hoop is dat de omvormer daarmee ook weer naar niet-encrypted communicatie terugschakelt. Dat is immers hoe hij af-fabriek wordt geleverd.

[Aegle]

Maar je kan via de seriele poort de key toch wel achterhalen? Daar heb je de USB-poort niet voor nodig.
Of heb ik iets gemist...?

[Jerrythafast]

Er staat me iets van bij dat hij via de RS-485 verbinding geen sleutel wilde prijsgeven, maar proberen kan sowieso geen kwaad (mits je niks sloopt natuurlijk ). Als factory default niet werkt is dit de enige hoop.

Hiervoor moet je het onderdeel waar BAGBAG op staat er even uit halen en aders van een seriële kabel in de linker BAG gaatjes steken en de linker switch op foto 4 omhoog zetten. Zie pagina 45 en verder van de handleiding.

[ Voor 6% gewijzigd door Jerrythafast op 21-04-2017 12:16 ]

[Aegle]

Ik ben al even aan het pielen geweest, maar krijg het niet voor elkaar om een query te maken om te bepalen welk van de panelen het best presteren sinds ik gestart ben met de logging volgens de methode "Jerry" .

Moet toch niet zo heel moeilijk zijn? Men neme de MAX per paneel over een bepaalde tijd reeks. Helaas krijg kan ik er geen chocola van maken. Mijn SQL skills blijven achter bij mijn eigen verwachting... .

[Jerrythafast]

Aegle schreef op zaterdag 22 april 2017 @ 17:28:
Ik ben al even aan het pielen geweest, maar krijg het niet voor elkaar om een query te maken om te bepalen welk van de panelen het best presteren sinds ik gestart ben met de logging volgens de methode "Jerry" .

Moet toch niet zo heel moeilijk zijn? Men neme de MAX per paneel over een bepaalde tijd reeks. Helaas krijg kan ik er geen chocola van maken. Mijn SQL skills blijven achter bij mijn eigen verwachting... .

Is inderdaad ook weer geen gemakkelijke. Hier een query om per paneel de totale opbrengst in Wh te berekenen:

MySQL:

SELECT HEX(op_id) optimizer, SUM(de_day*0.25) energy
FROM (
  SELECT
  op_id,
  IF(op_id = @prevop AND uptime > @prevup, e_day - @prevval, e_day) de_day,
  @prevval := e_day,
  @prevup := uptime,
  @prevop := op_id
  FROM telemetry_optimizers
  JOIN (SELECT @prevval := 0, @prevup := 0, @prevop := 0) vars
  ORDER BY op_id, timestamp
) x 
GROUP BY op_id;

Strategie die ik toepas: bereken eerst (inner query) de verschillen in opgewekte energie tussen opeenvolgende datapunten van elk paneel (e_day - @prevval). Hierbij zijn twee valkuilen te omzeilen: de overgang naar de volgende optimizer (op_id = @prevop) en een herstart van dezelfde optimizer (uptime > @prevup). Vervolgens (outer query) tel ik alle aldus berekende verschillen behorend bij dezelfde optimizer bij elkaar op.

Het is ook geen snelle query geworden...

+-----------+-----------+
| optimizer | energy    |
+-----------+-----------+
| 1043xxxx  | 270896.5  |
| 1052xxxx  | 331992.5  |
| 1061xxxx  | 290062.5  |
| 1063xxxx  | 330801.5  |
| 1065xxxx  | 343457.75 |
| 1065xxxx  | 324668.75 |
| 1065xxxx  | 321871.5  |
| 1065xxxx  | 328013    |
| 1065xxxx  | 342041.5  |
| 1065xxxx  | 324238    |
| 1066xxxx  | 338860    |
| 10BCxxxx  |   1416.75 |
+-----------+-----------+
12 rows in set (16.90 sec)

Mogelijk is de query nog niet helemaal goed, want ik kan hem maar één keer uitvoeren. Daarna moet ik opnieuw verbinden voordat hij hem weer slikt.

Hier is gisteren een brakke optimizer verangen. Onderste regel is de nieuwe optimizer, vandaar de lage score daarvoor. Gaat om deze mafkees. Het betreffende paneel had altijd, elke dag, steevast de laagste opbrengst. Vandaag gaat het erom spannen of hij de hoogste opbrengst haalt of 2e wordt. Een optimizer-wissel kan dus een behoorlijk verschil in opbrengst geven! De oude optimizer van dat paneel is trouwens de bovenste regel.

[ Voor 1% gewijzigd door Jerrythafast op 22-04-2017 19:04 . Reden: Handmatig kommaatjes uitgelijnd ]

[Aegle]

Bedank weer voor je onvolprezen programmeer kunst .
precies wat ik bedoelde. Op deze wijze was ik er nooit uitgekomen.. .

Overigens doet ie er op mijn RPi2 er "slechts" 5,87 seconden over :

+-----------+-------------+
| optimizer | energy      |
+-----------+-------------+
| 101BXXXX  | 12653709    |
| 101BXXXX  | 12453177    |
| 101CXXXX  | 12399313.75 |
| 101CXXXX  | 12435376    |
| 101CXXXX  | 12462475.75 |
| 101CXXXX  | 12622279.25 |
| 101CXXXX  | 12089904    |
| 101CXXXX  | 11971700    |
| 101CXXXX  | 12319516.5  |
| 101CXXXX  | 12444420.75 |
+-----------+-------------+
10 rows in set (5.87 sec)

[ Voor 52% gewijzigd door Aegle op 22-04-2017 23:20 ]

[Raldnor]

Super script! Bedankt voor de heldere uitleg!

Na het installeren had ik problemen met de database gevuld krijgen, en dat bleek te liggen aan een controle op het adres van de inverter.
In de code van liveupdate.py staat deze regel:

code:

if etherhdr[6:9] == "\x00\x27\x02":  # Inverter speaking.

Op basis van de headers in mijn pcap heb ik die regel toen veranderd naar:

code:

if etherhdr[6:9] == "\x00\x40\x9d":  # Inverter speaking.

Hierna kreeg ik wel keurig data in de database.
Kan het zijn dat er verschillende types communicatiemodules zijn?

[andrerij]

Jerrythafast schreef op zaterdag 22 april 2017 @ 19:00:
[...]

Is inderdaad ook weer geen gemakkelijke. Hier een query om per paneel de totale opbrengst in Wh te berekenen:

MySQL:

SELECT HEX(op_id) optimizer, SUM(de_day*0.25) energy
FROM (
  SELECT
  op_id,
  IF(op_id = @prevop AND uptime > @prevup, e_day - @prevval, e_day) de_day,
  @prevval := e_day,
  @prevup := uptime,
  @prevop := op_id
  FROM telemetry_optimizers
  JOIN (SELECT @prevval := 0, @prevup := 0, @prevop := 0) vars
ORDER BY op_id, timestamp
) x 
GROUP BY op_id;

@Jerrythafast ik heb de query aangepast voor de energy per dag en ziet er als volgt uit:

MySQL:

SELECT HEX(op_id) optimizer, FORMAT(SUM(de_day*0.25),2,'pt_BR') energy
FROM (
  SELECT
  op_id,
  IF(op_id = @prevop AND uptime > @prevup, e_day - @prevval, e_day) de_day,
  @prevval := e_day,
  @prevup := uptime,
  @prevop := op_id
  FROM telemetry_optimizers
  JOIN (SELECT @prevval := 0, @prevup := 0, @prevop := 0) vars
  WHERE `timestamp` > 1492992000 AND `timestamp` < 1493078400
  ORDER BY op_id, timestamp 
) x 
GROUP BY op_id;

De gekregen waarden wijken echter af van de waarden die op de monitorwebsite van Solaredge staan.

code:

op_id        website     query       verschil
               Wh          Wh         Wh
2020xxxx     840,00      830,50      9,50 
2020xxxx     832,00      825,00      7,00 
2020xxxx     852,00      844,75      7,25 
2020xxxx     838,75      838,75      -   
2020xxxx     823,75      815,25      8,50 
2020xxxx     831,50      826,50      5,00 
2020xxxx     864,50      857,50      7,00 
2020xxxx     832,50      832,50      -   
2020xxxx     823,50      823,50      -   
2020xxxx     804,25      804,25      -   
2020xxxx     886,00      877,00      9,00 
2020xxxx     823,25      823,25      -   
2020xxxx     840,50      834,25      6,25 
2020xxxx     865,00      865,00      -   
2020xxxx     804,25      799,75      4,50 
2020xxxx     847,00      842,50      4,50 
2020xxxx     872,25      859,75      12,50 
2020xxxx     824,50      824,50      -   
2020xxxx     851,75      842,75      9,00 
2020xxxx     884,50      873,25      11,25 
2021xxxx     890,75      885,75      5,00 
2021xxxx     877,00      877,00      -   
2021xxxx     874,50      874,50      -   
2021xxxx     876,00      871,75      4,25

Waardoor ontstaan deze verschillen. Ik heb mijn database gecontroleerd en de gekregen waarden staan in mijn database en ik kan niet de waarden van de monitorwebsite uit de database halen.

[ Voor 6% gewijzigd door andrerij op 25-04-2017 18:20 ]

[Jerrythafast]

Raldnor schreef op maandag 24 april 2017 @ 22:59:
Super script! Bedankt voor de heldere uitleg!

Na het installeren had ik problemen met de database gevuld krijgen, en dat bleek te liggen aan een controle op het adres van de inverter.
In de code van liveupdate.py staat deze regel:

code:

if etherhdr[6:9] == "\x00\x27\x02":  # Inverter speaking.

Op basis van de headers in mijn pcap heb ik die regel toen veranderd naar:

code:

if etherhdr[6:9] == "\x00\x40\x9d":  # Inverter speaking.

Hierna kreeg ik wel keurig data in de database.
Kan het zijn dat er verschillende types communicatiemodules zijn?

Die drie bytes komen mij bekend voor! Heb jij toevallig een SolarEdge WiFi module in je omvormer zitten? If so, dan ben je de tweede die ik tref met deze 3 bytes als begin van het MAC-adres en zal ik deze inderdaad maar 's officieel gaan laten herkennen als SolarEdge-related netwerk spul.

[Jerrythafast]

andrerij schreef op dinsdag 25 april 2017 @ 10:53:
[...]

@Jerrythafast ik heb de query aangepast voor de energy per dag en ziet er als volgt uit:

MySQL:

SELECT HEX(op_id) optimizer, FORMAT(SUM(de_day*0.25),2,'pt_BR') energy
FROM (
  SELECT
  op_id,
  IF(op_id = @prevop AND uptime > @prevup, e_day - @prevval, e_day) de_day,
  @prevval := e_day,
  @prevup := uptime,
  @prevop := op_id
  FROM telemetry_optimizers
  JOIN (SELECT @prevval := 0, @prevup := 0, @prevop := 0) vars
  WHERE `timestamp` > 1492992000 AND `timestamp` < 1493078400
  ORDER BY op_id, timestamp 
) x 
GROUP BY op_id;

De gekregen waarden wijken echter af van de waarden die op de monitorwebsite van Solaredge staan.

code:

op_id        website     query       verschil
               Wh          Wh         Wh
2020xxxx     840,00      830,50      9,50 
2020xxxx     832,00      825,00      7,00 
2020xxxx     852,00      844,75      7,25 
2020xxxx     838,75      838,75      -   
2020xxxx     823,75      815,25      8,50 
2020xxxx     831,50      826,50      5,00 
2020xxxx     864,50      857,50      7,00 
2020xxxx     832,50      832,50      -   
2020xxxx     823,50      823,50      -   
2020xxxx     804,25      804,25      -   
2020xxxx     886,00      877,00      9,00 
2020xxxx     823,25      823,25      -   
2020xxxx     840,50      834,25      6,25 
2020xxxx     865,00      865,00      -   
2020xxxx     804,25      799,75      4,50 
2020xxxx     847,00      842,50      4,50 
2020xxxx     872,25      859,75      12,50 
2020xxxx     824,50      824,50      -   
2020xxxx     851,75      842,75      9,00 
2020xxxx     884,50      873,25      11,25 
2021xxxx     890,75      885,75      5,00 
2021xxxx     877,00      877,00      -   
2021xxxx     874,50      874,50      -   
2021xxxx     876,00      871,75      4,25

Waardoor ontstaan deze verschillen. Ik heb mijn database gecontroleerd en de gekregen waarden staan in mijn database en ik kan niet de waarden van de monitorwebsite uit de database halen.

Je query lijkt te kloppen, bij mij komt de uitkomst van de query exact overeen met wat op de website staat. Ik zou niet kunnen verklaren waarom het bij jou niet uitkomt.

[Aegle]

Mmm, voortbordurend op de laatste query kun je op deze wijze een tabel/grafiek samenstellen met de onderlinge performance van de panelen/optimizers. Voer voor codekloppers !

Wat me bij een andere gedachte brengt:
Het valt me op dat door de dag heen er grote spreiding in vermogen is tussen de panelen/optimizers onderling.
Bij mijn panelen van 260Wp geeft het ene paneel bijvoorbeeld 42W en een ander paneel 250W. Dit wordt natuurlijk veroorzaakt door de verschillende tijdstippen van de samples, maar dit maakt "moment-vergelijkingen" wel lastig.

[Raldnor]

Jerrythafast schreef op dinsdag 25 april 2017 @ 19:58:
[...]

Die drie bytes komen mij bekend voor! Heb jij toevallig een SolarEdge WiFi module in je omvormer zitten? If so, dan ben je de tweede die ik tref met deze 3 bytes als begin van het MAC-adres en zal ik deze inderdaad maar 's officieel gaan laten herkennen als SolarEdge-related netwerk spul.

Yup, er zit inderdaad een SolarEdge WiFi module in. Mijn hack was een beetje quick and dirty, als die vaker voorkomt is het inderdaad wel handig om een check op te doen

[Jerrythafast]

@Raldnor, jouw 'hack' was 50% van mijn definitieve fix. Ik ga er zoiets van maken:

Python:

if etherhdr[6:9] in ("\x00\x27\x02", "\x00\x40\x9d"):  # Inverter speaking.

[Raldnor]

Jerrythafast schreef op woensdag 26 april 2017 @ 18:34:
@Raldnor, jouw 'hack' was 50% van mijn definitieve fix. Ik ga er zoiets van maken:

Python:

if etherhdr[6:9] in ("\x00\x27\x02", "\x00\x40\x9d"):  # Inverter speaking.

Top . Is dat andere mac adres soms van de vaste netwerkaansluiting?

Ik ben in php een frontend aan het bouwen en kwam iedere nacht een vreemde temperatuurwaarde tegen. Deze wordt verstuurd door de inverter wanneer het al lang donker is en geeft een temperatuurwaarde van -3.40282e38. Is het mogelijk om deze in het script te negeren (bijv. alle temperatuurwaardes onder de -20)? Grafieken worden een beetje messed up hierdoor. Ik kan dat ook wel in het frontend afvangen, maar vanuit het script lijkt me handiger.

[Jerrythafast]

Raldnor schreef op donderdag 27 april 2017 @ 14:49:
[...]

Top . Is dat andere mac adres soms van de vaste netwerkaansluiting?

You guessed it right!

Ik ben in php een frontend aan het bouwen en kwam iedere nacht een vreemde temperatuurwaarde tegen. Deze wordt verstuurd door de inverter wanneer het al lang donker is en geeft een temperatuurwaarde van -3.40282e38. Is het mogelijk om deze in het script te negeren (bijv. alle temperatuurwaardes onder de -20)? Grafieken worden een beetje messed up hierdoor. Ik kan dat ook wel in het frontend afvangen, maar vanuit het script lijkt me handiger.

Allereerst, de juiste waarde is -3.4028234e+38. Er is omtrent deze waarde al wat logica ingebakken in liveupdate.py. Als je er iets anders van wilt maken (geen idee wat dan ) kun je dat heel gemakkelijk in regel 60 pluggen:

Python:

REROUND = lambda x: JouwMagischeWaardeHier if x == -3.4028234663852886e+38 else x

Misschien zou je het datamodel van de database tabel kunnen aanpassen en hier een None/NULL waarde in kunnen gooien. De frontend zal er dan wel nog steeds iets mee moeten, dus of je hier veel mee op schiet is de vraag. Om die reden heb ik er voor gekozen om gewoon deze sentinel waarde over te nemen.

[ Voor 5% gewijzigd door Jerrythafast op 27-04-2017 15:48 ]

[marco0305]

Ik heb dit topic met veel interesse gelezen vermits ik ook graag mijn data lokaal wil opslaan en via mijn KNX visualisatie te gebruiken.

Mijn router is een cisco RV325 dus ik kan een locale DNS server toewijzen. Zoals ik begrijp moet ik dus "prod.solaredge.com" toewijzen aan het IP van mijn NAS zodat alle data van de inverter via de LAN interface van mijn NAS gaat.

Ik wil dus mijn Qnap NAS gebruiken om de python scripts te draaien en de mysql database gebruiken om de gegevens op te slaan.

Ik heb stappen 5.1 tem 5.7 uitgevoerd behalve de "key" die ik nog uit het toestel zal moeten halen via de USB interface.
Nu, stap 5.8 geeft mij een probleem vermits ik " '/etc/systemd/system' directory" niet kan vinden op mijn Qnap (firmware 4.3.3). De folder "systemd" bestaat niet ook al is het een linux distri?!

Is er iemand die dit werkende heeft gekregen op een Qnap NAS?

[Jerrythafast]

Lijkt erop dat Qnap geen Systemd gebruikt dan. Hebben die dingen geen mooie configuratie interface waarin je services/achtergrondtaken kunt instellen? Dan zou je het daarmee wel aan de praat moeten kunnen krijgen. Waar het om gaat is dat je het bash script /opt/se-logger/se-logger-service.sh automatisch laat starten bij het opstarten van de NAS.

Houd er trouwens wel rekening mee dat de data van de omvormer uiteindelijk wel bij de 'echte' prod.solaredge.com moet aankomen. De omvormer verwacht namelijk ook reactie terug.

[ Voor 20% gewijzigd door Jerrythafast op 28-04-2017 21:32 ]

[marco0305]

Ik kan ook een port mirroring doen op mijn router zodat alle data die via de WAN gaat ook op poort LAN1 gaat. LAN1 wordt dan aangesloten op de NAS of op een managed switch.
Op deze manier blijft de communicatie tussen het solaredge portaal en de inverter in takt.

Ik moet eens even kijken of ik via die "mooie" interface iets kan instellen?!

[Jerrythafast]

Aan de mensen met een HD Wave omvormer, @NL1PSR bijvoorbeeld, zouden jullie eens kunnen kijken naar de omvormertemperatuur? Is die de afgelopen dagen/weken erg hoog (zeg meer dan 45 °C) geweest? Deze vraag naar aanleiding van de post van @Rouske in Elektriciteit opwekken met zonnepanelen (PV) Deel 5...

[tjanssen]

Jerrythafast schreef op zaterdag 29 april 2017 @ 09:36:
Aan de mensen met een HD Wave omvormer, @NL1PSR bijvoorbeeld, zouden jullie eens kunnen kijken naar de omvormertemperatuur? Is die de afgelopen dagen/weken erg hoog (zeg meer dan 45 °C) geweest? Deze vraag naar aanleiding van de post van @Rouske in Elektriciteit opwekken met zonnepanelen (PV) Deel 5...

Op een HD Wave 3680, de uitkomst van deze query:

code:

SELECT CAST(t.temperature as SIGNED) AS `temperature`, COUNT(*) AS `count`, MIN(t.p_active) AS `min`, MAX(t.p_active) AS `max`, ROUND(AVG(t.p_active), 2) AS `avg` FROM telemetry_inverter t
GROUP BY CAST(t.temperature as SIGNED)

temperature	count	min	max	avg
14	1	0	0	0
17	10	0	0	0
18	76	0	0	0
19	128	0	0	0
20	166	0	0	0
21	185	0	14,6046	0,08
22	224	0	27,7285	0,55
23	290	0	69,7	4,28
24	329	0	716,005	17,99
25	414	0	612,406	38,09
26	580	0	760,507	70,08
27	825	0	810,632	135,02
28	1136	0	1109,79	197,89
29	1422	0	1448,55	246,5
30	1661	0	1655,51	286,91
31	1530	0	2038,19	398,89
32	1442	0	2169,11	522,48
33	1163	0	3491,86	625,29
34	1034	0	3006,27	737,59
35	747	0	3455,59	788,64
36	586	0	3247,91	875,72
37	486	0	3632,89	1036,67
38	367	0	3148,09	1211,68
39	264	39,0773	3111,88	1305,43
40	267	144,327	3552,56	1597,41
41	222	136,493	3678,62	1731,7
42	195	246,257	3682,52	1889,22
43	180	223,167	3680,23	2011,66
44	174	219,065	3682,26	2174,21
45	168	269,328	3676,61	2308,56
46	136	214,906	3679,85	2405,4
47	116	452,332	3683,17	2557,61
48	130	553,311	3681,97	2690,49
49	94	766,443	3685,93	2853,93
50	99	896,338	3682,69	2877,06
51	85	631,27	3684,41	2948,74
52	42	2636,83	3683,53	3135,61
53	34	2843,52	3681,97	3283,1
54	15	2797,12	3680,64	3422,76
55	7	3294,81	3678,65	3523,95
56	2	3634,56	3676,97	3655,77

[Jerrythafast]

tjanssen schreef op zaterdag 29 april 2017 @ 11:16:
[...]


Op een HD Wave 3680, de uitkomst van deze query:

code:

SELECT CAST(t.temperature as SIGNED) AS `temperature`, COUNT(*) AS `count`, MIN(t.p_active) AS `min`, MAX(t.p_active) AS `max`, ROUND(AVG(t.p_active), 2) AS `avg` FROM telemetry_inverter t
GROUP BY CAST(t.temperature as SIGNED)

temperature	count	min	max	avg
14	1	0	0	0
17	10	0	0	0
18	76	0	0	0
19	128	0	0	0
20	166	0	0	0
21	185	0	14,6046	0,08
22	224	0	27,7285	0,55
23	290	0	69,7	4,28
24	329	0	716,005	17,99
25	414	0	612,406	38,09
26	580	0	760,507	70,08
27	825	0	810,632	135,02
28	1136	0	1109,79	197,89
29	1422	0	1448,55	246,5
30	1661	0	1655,51	286,91
31	1530	0	2038,19	398,89
32	1442	0	2169,11	522,48
33	1163	0	3491,86	625,29
34	1034	0	3006,27	737,59
35	747	0	3455,59	788,64
36	586	0	3247,91	875,72
37	486	0	3632,89	1036,67
38	367	0	3148,09	1211,68
39	264	39,0773	3111,88	1305,43
40	267	144,327	3552,56	1597,41
41	222	136,493	3678,62	1731,7
42	195	246,257	3682,52	1889,22
43	180	223,167	3680,23	2011,66
44	174	219,065	3682,26	2174,21
45	168	269,328	3676,61	2308,56
46	136	214,906	3679,85	2405,4
47	116	452,332	3683,17	2557,61
48	130	553,311	3681,97	2690,49
49	94	766,443	3685,93	2853,93
50	99	896,338	3682,69	2877,06
51	85	631,27	3684,41	2948,74
52	42	2636,83	3683,53	3135,61
53	34	2843,52	3681,97	3283,1
54	15	2797,12	3680,64	3422,76
55	7	3294,81	3678,65	3523,95
56	2	3634,56	3676,97	3655,77

Dank! Ter vergelijking onze 'ouderwetse' SE3000:

+-------------+-------+-------+--------+---------+
| temperature | count | min   | max    | avg     |
+-------------+-------+-------+--------+---------+
|           0 |   497 |     0 |      0 |    0.00 |
|          19 |    63 |     0 |  333.5 |    5.29 |
|          20 |   615 |     0 |  416.5 |    2.51 |
|          21 |   971 |     0 |   1184 |   13.01 |
|          22 |  1736 |     0 | 1690.5 |   45.53 |
|          23 |  3233 |     0 |    792 |  101.45 |
|          24 |  5627 |     0 | 1500.5 |  153.45 |
|          25 |  7373 |     0 | 2171.5 |  199.61 |
|          26 |  5876 |     0 | 2163.5 |  279.14 |
|          27 |  4584 |     0 | 2971.5 |  397.34 |
|          28 |  4804 |     0 |   2526 |  461.11 |
|          29 |  4784 |     0 |   3126 |  548.52 |
|          30 |  4073 |     0 |   3474 |  656.90 |
|          31 |  3325 |     0 | 3402.5 |  739.75 |
|          32 |  2965 |     0 |   3581 |  868.69 |
|          33 |  2697 |     0 | 3279.5 | 1030.34 |
|          34 |  2123 |     0 |   3446 | 1203.63 |
|          35 |  1857 |     0 |   3137 | 1378.04 |
|          36 |  1450 |     0 | 3272.5 | 1512.64 |
|          37 |  1365 |     0 |   3268 | 1624.77 |
|          38 |  1348 |  47.5 | 3249.5 | 1733.12 |
|          39 |  1277 |  74.5 | 3104.5 | 1748.67 |
|          40 |  1001 | 272.5 |   3035 | 1804.42 |
|          41 |   812 |   363 | 3079.5 | 1924.08 |
|          42 |   678 | 285.5 |   2942 | 1969.33 |
|          43 |   491 | 274.5 |   2721 | 2037.11 |
|          44 |   236 |   556 |   2602 | 2049.03 |
|          45 |    39 |  1188 |   2528 | 2154.54 |
|          46 |    12 |  1928 |   2328 | 2230.96 |
+-------------+-------+-------+--------+---------+

Dit is data van iets meer dan een jaar. Lijkt erop dat de HD Wave inderdaad iets warmer wordt bij jou, maar geen hele hoge uitschieters.

[Aegle]

Dit is de uitkomst van de query van mijn SE3000. Ook een stuk lager dan de HD:

+-------------+-------+------+------+---------+
| temperature | count | min  | max  | avg     |
+-------------+-------+------+------+---------+
|          18 |    35 |    0 |    0 |    0.00 |
|          19 |   236 |    0 |   81 |    2.90 |
|          20 |   575 |    0 |  371 |   15.51 |
|          21 |  1120 |    0 |  967 |   52.20 |
|          22 |  1773 |    0 | 1287 |  110.59 |
|          23 |  2386 |    0 | 1646 |  159.79 |
|          24 |  3672 |    0 | 1725 |  181.20 |
|          25 |  3397 |    0 | 2625 |  232.17 |
|          26 |  2976 |    0 | 3004 |  311.82 |
|          27 |  2975 |    0 | 2343 |  377.91 |
|          28 |  3189 |    0 | 2506 |  477.44 |
|          29 |  2706 |    0 | 2677 |  625.72 |
|          30 |  2080 |    0 | 3002 |  807.11 |
|          31 |  1703 |    0 | 2762 | 1004.94 |
|          32 |  1828 |    0 | 2749 | 1105.57 |
|          33 |  1405 |   25 | 2816 | 1271.57 |
|          34 |  1147 |   75 | 2813 | 1431.55 |
|          35 |  1034 |  222 | 2684 | 1615.21 |
|          36 |   876 |  221 | 2651 | 1739.05 |
|          37 |   522 |  413 | 2552 | 1760.80 |
|          38 |   209 |  581 | 2486 | 1703.78 |
|          39 |   129 |  882 | 2235 | 1745.37 |
|          40 |    28 | 1672 | 1978 | 1839.96 |
+-------------+-------+------+------+---------+

[tjanssen]

Mijn ervaring met temperaturen meten op PCBs is dat je meting doet op een plek waar je een mogelijke correlatie kunt leggen. Dit hoeft niet persé de hotspot op het PCB te zijn, maar kan ook de temperatuur van een ander kritisch component zijn. De temperaturen vergelijken van verschillende producten heeft als je het mij vraagt ook niet zoveel zin. Vergelijken tussen HD waves onderling zou wel iets kunnen zeggen.

[Rouske]

@Jerrythafast bedankt voor de oproep
Hierbij het overzicht van onze SE3680H sinds 5 April, helaas via de 5-minuten data en wat gedoe in Excel

Wat me wel al meteen op valt is dat de SE3680H van ons bij het opstarten al ~10 graden warmer is dan @tjanssen, de omvormer hangt bij ons op zolder aan de betonnen buitenmuur, het is daar ~20 graden. En de centrale afzuiging hangt er boven, dus warmte wordt ook nog eens meteen afgevoerd.

temp     aantal           min             max          gem
30           38           0,0             0,0           0,0
31           14          12,5            12,5           0,9
32           23           0,0          1707,2         120,6
33           52           0,1          1149,3          56,8
34           96           6,2           926,7          90,8
35          128          19,9          1148,7         147,2
36          104          25,8          1383,9         259,7
37          132          56,3          1503,9         366,8
38          163           1,2          2025,3         403,0
39          357           0,1          2157,0         305,2
40          494           1,1          2532,5         344,9
41          419          88,4          2881,5         643,1
42          236         194,3          2463,5         810,3
43          160         286,1          3682,5         993,3
44          107         201,9          3425,1        1085,4
45          119         412,9          2971,9        1216,6
46          118         296,7          3624,6        1295,5
47          120         409,6          3681,7        1423,9
48          126         374,0          3605,9        1609,8
49          118         408,2          3681,5        1903,0
50          100         340,3          3683,3        1869,9
51           73         743,2          3683,7        2138,0
52           89         308,2          3681,3        2138,5
53           63         162,5          3684,9        2283,2
54           75         498,2          3683,0        2446,0
55           79         444,1          3684,1        2562,4
56           45         546,0          3683,6        2597,1
57           43         810,6          3684,0        2953,6
58           46         590,7          3681,9        2924,6
59           44         761,4          3683,4        3051,7
60           39         833,9          3681,5        2839,9
61           45         945,7          3684,3        3030,3
62           40        2734,6          3683,8        3395,4
63           32        1798,2          3684,6        3285,5
64           28        1951,3          3680,7        3261,7
65           23        2296,2          3683,5        3433,0
66           27        3114,1          3682,0        3448,1
67           20        2330,6          3678,9        3407,6
68           20        2824,9          3678,0        3458,0
69           12        3431,0          3681,5        3556,9

[Jerrythafast]

@Rouske, zie ik het nou goed dat jouw SE3680H nog nooit lager dan 30°C heeft gerapporteerd? En zodra hij ook maar het minimale aan vermogen geeft (lees: meer dan 0,0) zit je al op 31°C of hoger. Ik vind het maar gek. Voelt hij ook warm aan van buiten? Lijkt me dat als hij vanbinnen 60°C is dat aan de buitenkant wel merkbaar moet zijn.

[tsjoender]

Hier van de SE3000HD (gemeten sinds december):

temp	count	min 	max 	avg 
6 	2 	0 	0 	0.00
7 	32 	0 	0 	0.00
8 	143 	0 	0 	0.00
9 	433 	0 	53.5507 	0.23
10 	546 	0 	92.7424 	0.65
11 	480 	0 	154.403 	1.71
12 	824 	0 	254.202 	4.51
13 	697 	0 	470.957 	9.90
14 	956 	0 	703.756 	14.97
15 	1204 	0 	908.563 	19.91
16 	1491 	0 	1035.63 	28.73
17 	1318 	0 	1145.43 	64.79
18 	969 	0 	1541.29 	101.87
19 	1149 	0 	1485.99 	129.27
20 	1256 	0 	1821.35 	156.19
21 	1237 	0 	1997.17 	190.85
22 	1296 	0 	1808.14 	242.12
23 	1558 	0 	1792.76 	269.97
24 	1765 	0 	1765.21 	276.32
25 	1714 	0 	1897.72 	293.13
26 	1765 	0 	1837.53 	362.01
27 	1669 	0 	2461.17 	382.32
28 	1472 	0 	1923.14 	443.14
29 	1523 	0 	2825.99 	501.69
30 	1392 	0 	2418.63 	518.91
31 	1323 	0 	2747.2 	557.95
32 	1261 	0 	2944.51 	654.87
33 	1336 	0 	2574.89 	693.42
34 	1042 	0 	2716.42 	783.60
35 	980 	0 	3070.19 	899.14
36 	721 	0 	3014.55 	1074.28
37 	652 	0 	3070.76 	1153.47
38 	528 	0 	3057.54 	1308.47
39 	419 	0 	2963.68 	1642.82
40 	242 	201.022 	2990.42 	1749.42
41 	192 	377.456 	3043.7 	1918.56
42 	135 	410.084 	2739.86 	1833.54
43 	86 	640.793 	3176.87 	1924.50
44 	59 	776.928 	2935.97 	1988.82
45 	37 	1852.19 	2328.34 	2119.44

De omgevingstemperatuur schommelt de afgelopen weken tussen de 5-15 graden (garage, niet geisoleerd). Aankomende zomer zullen de temperaturen vast hoger liggen.

[Rouske]

Jerrythafast schreef op zaterdag 29 april 2017 @ 20:00:
@Rouske, zie ik het nou goed dat jouw SE3680H nog nooit lager dan 30°C heeft gerapporteerd? En zodra hij ook maar het minimale aan vermogen geeft (lees: meer dan 0,0) zit je al op 31°C of hoger. Ik vind het maar gek. Voelt hij ook warm aan van buiten? Lijkt me dat als hij vanbinnen 60°C is dat aan de buitenkant wel merkbaar moet zijn.

Er zijn wel waarden van onder de 30°C in de 5-min data, maar die zijn allemaal met 0,0 totalActivePower en dcVoltage <370V. Laagste waarde is 28,2°C.
Ik zal bij het naar bed gaan eens checken welke temperatuur er op het display staat.
Edit1: in de nightmode 28,8°C

Bij +60°C is dat zeker goed te voelen op de koelribben en bovenop de omvormer.

Edit2: Zag net in PVoutput om 11:25 de hoogst gemeten waarde ooit: 70,4°C naar zolder toe gelopen daar 72,4°C , meteen even een PC ventilatortje met adapter onder de omvormer geplaatst... ben benieuwd hoeveel dat gaat schelen.
Morgen maar weer even bellen met de installateur!

[ Voor 16% gewijzigd door Rouske op 30-04-2017 11:58 ]

[Raldnor]

Hoe bereken ik de actuele opbrengst per paneel in watt op een bepaald tijdstip? Als ik een volgende query gebruik:

code:

SELECT v_out, v_in, i_in, temperature, e_day, timestamp FROM telemetry_optimizers WHERE op_id=" . hexdec($op_id) . " AND timestamp BETWEEN " . $startdate . " AND " . $enddate . " ORDER BY timestamp DESC LIMIT 1

Kan ik dan v_in * i_in gebruiken? Het lijkt me niet, want dan krijg ik soms waardes die hoger zijn dan de watt-piek per paneel.

[ocaj]

Vermogen is inderdaad v_in * i_in, de watt-piek waarde van je paneel is het vermogen bij STC (standaard test conditions) en geen absoluut maximum of zo.

De afgelopen weken zijn met name op de half-bewolkte dagen met af en toe felle zon de omstandigheden gunstig voor veel hogere pieken. Ik heb hier de afgelopen weken regelmatig pieken boven de 390Watt met 335Wp-panelen.

Niks aan de hand dus met je berekening!

[ Voor 3% gewijzigd door ocaj op 02-05-2017 09:58 ]

[Yoki1985]

ocaj schreef op dinsdag 2 mei 2017 @ 09:57:
Vermogen is inderdaad v_in * i_in, de watt-piek waarde van je paneel is het vermogen bij STC (standaard test conditions) en geen absoluut maximum of zo.

De afgelopen weken zijn met name op de half-bewolkte dagen met af en toe felle zon de omstandigheden gunstig voor veel hogere pieken. Ik heb hier de afgelopen weken regelmatig pieken boven de 390Watt met 335Wp-panelen.

Niks aan de hand dus met je berekening!

Als ik die query bij mij uitvoer krijg ik het volgende te zien:


Volgens die query zou mijn paneel dus 902 watt moeten leveren (voor een paneel van 327WP)

Dit is de exacte query wat ik uitvoer:

SQL:

SELECT v_out, v_in, i_in, v_in*i_in, temperature, e_day, timestamp FROM telemetry_optimizers WHERE timestamp BETWEEN 1483863000 AND 1483863100 ORDER BY timestamp DESC LIMIT 1

[Rouske]

Vraag verplaatst naar: Rouske in "Elektriciteit opwekken met zonnepanelen (PV) Deel 5"

[ Voor 127% gewijzigd door Rouske op 03-05-2017 10:32 ]

[Raldnor]

Yoki1985 schreef op dinsdag 2 mei 2017 @ 12:03:
[...]


Als ik die query bij mij uitvoer krijg ik het volgende te zien:
[afbeelding]

Volgens die query zou mijn paneel dus 902 watt moeten leveren (voor een paneel van 327WP)

Dit is de exacte query wat ik uitvoer:

SQL:

SELECT v_out, v_in, i_in, v_in*i_in, temperature, e_day, timestamp FROM telemetry_optimizers WHERE timestamp BETWEEN 1483863000 AND 1483863100 ORDER BY timestamp DESC LIMIT 1

Ik kan het mis hebben, maar ik denk dat je de uitkomst door 1000 moet delen. Waarschijnlijk wordt in milliwatt gerekend? Dat is in ieder geval wat ik momenteel doe. Wat ik dan wel soms tegenkom is dat een paneel op een zonnig moment bijv. 330 watt zou leveren, terwijl de piek van het paneel 270 is. Ook wanneer ik de waardes van alle panelen bij elkaar optel kom ik honderden watts hoger uit dan de actuele productie die de omvormer weergeeft. De waardes in het portaal van Solaredge komen ook niet overeen en lijken anders te worden berekend.

[ocaj]

Yoki1985 schreef op dinsdag 2 mei 2017 @ 12:03:
[...]

Volgens die query zou mijn paneel dus 902 watt moeten leveren (voor een paneel van 327WP)

Hmmm, ik was even vergeten dat het tool van @Jerrythafast de ruwe data in de database stopt en die heeft wat onhandige eenheden. Ik gooi zelf de spanning in Volt en de stroomsterkte in Ampère in mijn database en dan is het vermogen inderdaad zo simpel als vermenigvuldigen van die twee.

Als ik de kolom-header in jouw screenshot moet geloven, dan zou je dus de V_in met 0,125 moeten vermenigvuldigen en de I_in met 0,00625, maar dat zou in dit voorbeeld weer een heel erg laag vermogen opleveren. Of is dit een entry aan begin/eind van de dag?

[andrerij]

Yoki1985 schreef op dinsdag 2 mei 2017 @ 12:03:
[...]


Als ik die query bij mij uitvoer krijg ik het volgende te zien:
[afbeelding]

Volgens die query zou mijn paneel dus 902 watt moeten leveren (voor een paneel van 327WP)

Dit is de exacte query wat ik uitvoer:

SQL:

SELECT v_out, v_in, i_in, v_in*i_in, temperature, e_day, timestamp FROM telemetry_optimizers WHERE timestamp BETWEEN 1483863000 AND 1483863100 ORDER BY timestamp DESC LIMIT 1

@Yoki1985 volgens de timestamp is deze query van 8 jan 2017 9:11:18. Dan is de productie nog heel laag omdat de zon dan pas om ongeveer 8:42 uur op komt.

Je moet dus 902 met 0,125 en 0,00625 vermenigvuldigen. Dit wordt dan 0,704 W

[Yoki1985]

andrerij schreef op woensdag 3 mei 2017 @ 18:10:
[...]


@Yoki1985 volgens de timestamp is deze query van 8 jan 2017 9:11:18. Dan is de productie nog heel laag omdat de zon dan pas om ongeveer 8:42 uur op komt.

Je moet dus 902 met 0,125 en 0,00625 vermenigvuldigen. Dit wordt dan 0,704 W

Als ik een punt uitkies waar mijn panelen aan het maximum van de omvormer werken krijg ik de volgende resultaten:

5216w


Hoogste piek van de dag om 14 uur


Query

SQL:

SELECT op_id, power, datetime FROM `vw_PowerPerPanel` WHERE datetime BETWEEN "2017-05-03 13:55" AND "2017-05-03 14:00" ORDER BY datetime

View

SQL:

select `SolarEdge`.`telemetry_optimizers`.`op_id` AS `op_id`,`SolarEdge`.`telemetry_optimizers`.`v_out` AS `v_out`,`SolarEdge`.`telemetry_optimizers`.`v_in` AS `v_in`,`SolarEdge`.`telemetry_optimizers`.`i_in` AS `i_in`,round(((`SolarEdge`.`telemetry_optimizers`.`v_in` * 0.125) * (`SolarEdge`.`telemetry_optimizers`.`i_in` * 0.00625)),2) AS `power`,`SolarEdge`.`telemetry_optimizers`.`temperature` AS `temperature`,`SolarEdge`.`telemetry_optimizers`.`e_day` AS `e_day`,`SolarEdge`.`telemetry_optimizers`.`timestamp` AS `timestamp`,from_unixtime(`SolarEdge`.`telemetry_optimizers`.`timestamp`) AS `datetime` from `SolarEdge`.`telemetry_optimizers` order by `SolarEdge`.`telemetry_optimizers`.`timestamp` desc

De code om de power te berekenen is de volgende

SQL:

round(((`SolarEdge`.`telemetry_optimizers`.`v_in` * 0.125) * (`SolarEdge`.`telemetry_optimizers`.`i_in` * 0.00625)),2)

Uitvoer


Ik heb 20 panelen van 327WP en het totaal van mijn installatie is 6540WP.

De power waarde lijken mij aan de lage kant om toch 5000+ watt te genereren

[tinka]

Zijn er meer mensen waarbij de logging niet meer werkt?

Dus niet met SELogger maar ook niet via de SolarEdge website?

[Yoki1985]

tinka schreef op vrijdag 5 mei 2017 @ 12:47:
Zijn er meer mensen waarbij de logging niet meer werkt?

Dus niet met SELogger maar ook niet via de SolarEdge website?

Hier lijkt alles gewoon te werken

[Aegle]

Ik zie nu pas dat mij lokaal om 07:10 de logging is gestopt . Ben nu niet thuis, maar straks even naar kijken .
Zowel de Portal als PVoutput-API werken gelukkig wel...

UPDATE:
Heel vreemd... Het loggen is vandaag gestart om 06:57:49 uur en spontaan gestopt 07:09:41 uur. pvo-upload.log geeft eerst een heleboel cURL-errors (503, service unavailable). Vervolgens:

PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)' in /opt/se-logger/pvo-upload.php:15
Stack trace:
#0 /opt/se-logger/pvo-upload.php(15): PDO->__construct('mysql:host=loca...', 'root', 'xxxxxxxx', Array)
#1 {main}
  thrown in /opt/se-logger/pvo-upload.php on line 15

(password vervangen door 'xxxxxxxx')
In de andere logfiles staan geen ongebruikelijke meldingen. MySQL draait ook gewoon door. Evenals de SolarEdge-portal. Helaas is de .pcap niet aangevuld .

se-logger herstart en draait nu weer... .

[ Voor 71% gewijzigd door Aegle op 05-05-2017 18:03 ]

[Jerrythafast]

@Aegle, vreemd gedrag van je MySQL server. Schijnbaar kon PHP er geen contact meer mee leggen
Had je nog gecheckt of liveupdate.log gekke meldingen bevatte? Ik vraag me af wat se-logger in deze situatie gedaan heeft. Dat de .pcap niet is aangevuld lijkt erop te duiden dat hier een zwakte in zit. Mijn hoogste prioriteit bij het ontwikkelen van de scripts was om ervoor te zorgen dat de .pcap altijd wordt gevuld. Ik wil de data op dat niveau 100% volledig hebben; als MySQL begint te stuiteren kun je dan immers altijd nog je database weggooien en opnieuw opbouwen.

[unrealbe]

Hoi,

Binnenkort komen ze bij mij ook zonnepanelen icm een solaredge omvormer plaatsen.
Nu heb ik geen 3 maar wel een raspberry pi 2 liggen. Die heeft geen wifi chip dus wat zou ik er nog bij moeten kopen (goedkoop) om dit werkend te krijgen?
Installatie binnen de x uren moet mogelijk zijn, ik maak wel dat ik thuis ben dan. Wat gebeurd er als men raspberry pi niet meer werkt, geen logging meer mogelijk of worden de waarden ook gewoon nog doorgestuurd naar de servers van solaredge?

[Aegle]

Het loggen zoals beschreven in dit topic gaat uitstekend met een RPi2. Bij mij draait het sinds het voorjaar van vorig jaar zonder noemenswaardige problemen op een RPi2 zonder WiFi. WiFi is niet persé noodzakelijk.
Tevens draait er ook nog een webservertje op voor de grafische weergave van de verzamelde data. De RPi2 kan dit makkelijk behappen.

Mocht de RPi er mee stoppen, dan draait de logging naar SolarEdge gewoon door. Zoals je in de uitstekend omschreven openingspost kunt lezen tap je als het ware het verkeer tussen de omvormer en SolarEdge af.

[ Voor 16% gewijzigd door Aegle op 08-05-2017 22:32 ]

[unrealbe]

Aegle schreef op maandag 8 mei 2017 @ 22:30:
Het loggen zoals beschreven in dit topic gaat uitstekend met een RPi2. Bij mij draait het sinds het voorjaar van vorig jaar zonder noemenswaardige problemen op een RPi2 zonder WiFi. WiFi is niet persé noodzakelijk.
Tevens draait er ook nog een webservertje op voor de grafische weergave van de verzamelde data. De RPi2 kan dit makkelijk behappen.

Mocht de RPi er mee stoppen, dan draait de logging naar SolarEdge gewoon door. Zoals je in de uitstekend omschreven openingspost kunt lezen tap je als het ware het verkeer tussen de omvormer en SolarEdge af.

Ok bedankt

[Pietjebel10]

Jerrythafast schreef op zaterdag 6 mei 2017 @ 11:17:
@Aegle, vreemd gedrag van je MySQL server. Schijnbaar kon PHP er geen contact meer mee leggen
Had je nog gecheckt of liveupdate.log gekke meldingen bevatte? Ik vraag me af wat se-logger in deze situatie gedaan heeft. Dat de .pcap niet is aangevuld lijkt erop te duiden dat hier een zwakte in zit. Mijn hoogste prioriteit bij het ontwikkelen van de scripts was om ervoor te zorgen dat de .pcap altijd wordt gevuld. Ik wil de data op dat niveau 100% volledig hebben; als MySQL begint te stuiteren kun je dan immers altijd nog je database weggooien en opnieuw opbouwen.

Jerry hierbij liveupdate.log staan inderdaad wat vreemde meldingen in.
Misschien dat je hier iets aan hebt, key 503 wordt wel steeds geladen dus alles loopt wel door

ld not connect to database: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)"); retrying...
Warning: Could not connect to database: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)"); retrying...
Warning: Could not connect to database: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)"); retrying...
Reading from -
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
56ce0816 Out of order packet! SEQ=02581471 expect=0258145e (Gap size 19)
56ce0816 DATA LOSS 19 bytes!
56ce0816 Gap closed after 119.158639 seconds
56ce0816 Stream is contiguous again
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
56ce0ebb Out of order packet! SEQ=028fb183 expect=028fb170 (Gap size 19)
56ce0ebb DATA LOSS 19 bytes!
56ce0ebb Gap closed after 119.291004 seconds
56ce0ebb Stream is contiguous again
Setting new 0503 key
Setting new 0503 key
56ce0e36 Out of order packet! SEQ=013bea2b expect=013bea18 (Gap size 19)
56ce0e36 DATA LOSS 19 bytes!
56ce0e36 Gap closed after 119.235929 seconds
56ce0e36 Stream is contiguous again
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key
Setting new 0503 key

[Jerrythafast]

@Pietjebel10 Als ik dit zo lees is er bij jou niet zo veel aan de hand. De se-logger service moest 3 seconden wachten voordat je MySQL server wakker was (waarschijnlijk na een reboot van je Pi?) en daarna heeft de omvormer vooral een hele hoop keren opnieuw verbinding gemaakt. Het lijkt erop dat er af en toe wat informatie op de lijn verloren gaat en opnieuw verzonden moet worden.

[andrerij]

Ik heb geconstateerd dat er elke dag een nieuwe .pcap wordt aangemaakt maar alle voorgaande blijven gevuld worden met de recente data. in het taakoverzicht blijven de oude tcpdump actief.
Hoe kan ik automatisch de oude tcdump processen stoppen.

[Jerrythafast]

@andrerij
Probeer in se-logger.service eens 'KillMode=control-group' in te stellen. Er was hier eerder iemand met hetzelfde probleem die het daarmee wist op te lossen. Ik moet nog eens uitzoeken waarom dat bij mijn Ubuntu installatie niet werkt.

Als dit het voor jou oplost, dan graag even een bevestiging. Dan zet ik deze informatie ook even in de startpost.

Ik was er trouwens niet meer aan toe gekomen je e-mail te beantwoorden, excuses. Je monitoring pagina ziet er spectaculair uit; als we 'm ergens live op internet kunnen zien zou dat echt tof zijn

[andrerij]

Jerrythafast schreef op vrijdag 12 mei 2017 @ 23:33:
@andrerij
Probeer in se-logger.service eens 'KillMode=control-group' in te stellen. Er was hier eerder iemand met hetzelfde probleem die het daarmee wist op te lossen. Ik moet nog eens uitzoeken waarom dat bij mijn Ubuntu installatie niet werkt.

Als dit het voor jou oplost, dan graag even een bevestiging. Dan zet ik deze informatie ook even in de startpost.

@Jerrythafast
Ik heb de se-logger.service aangepast en nu werkt het wel goed.

[Yoki1985]

@Jerrythafast
Kan het zijn dat de omvormer na een tijd van encryptie sleutel veranderd?
Ik krijg ineens namelijk veel mysterious bytes left errors:


//Edit:

Ik krijg veel Barker meldingen:

liveupdate v0.0.8.py:370: Warning: Duplicate entry '1494671340-539844519' for key 'PRIMARY'
  self.cursor.execute(*args)
Setting new 0503 key
Warning! Checksum failure, skipping over barker...
Warning! Skipping 532 mysterious bytes!
1d 02 e2 fd 3c 02 4e 3a 1a 7f fe ff ff ff 3d 00 00 04 ca e1 81 46 29 6a 46 fc 8c 82 d6 ff 88 65 9b 2a 5a 4b dc dd f8 45 0f 54 3e 89 ba b3 75 f6 7f 0a 15 c3 a4 8b bd 2f d0 eb f1 d8 61 14 dc fb ff 5a c5 5e ba 45 61 b4 cb bd 7d 49 55 3e 44 4d 17 4f bc 3d 0f 1e e1 9f d5 3b a6 f3 cc 34 d6 1a 84 b9 d3 a2 eb f2 f5 54 84 9a ef bd 8a 3b 83 a6 03 35 51 97 dc ae 78 90 77 b2 16 33 53 83 cd 18 e6 bd 20 32 78 10 9d 78 2b 3d 2d 55 4d ff b4 a6 ca 33 ad 5a 10 40 00 d1 12 05 71 ea 2d 1f d0 63 9f 5c 35 30 d4 05 fc 90 34 74 61 66 ea a4 ea dd 41 5a 58 34 d4 23 90 33 b7 68 4d 89 0c 34 0d 70 92 c9 61 4a 9b 47 d7 aa ba 5a b0 1e cd ec 69 b2 82 ad 7d d0 c4 a4 53 54 db f8 61 34 5d 1f 21 b7 98 79 e5 9e 7e 32 1b 1b 19 0e cf 50 2c f5 ac 93 f2 df cb fc 3c 03 a7 02 98 ae 78 68 4c 57 3c cf 64 70 02 bb 4a d4 6c 70 c0 bb e9 26 39 b2 70 77 e3 e6 b6 0e 2f 31 8c f4 b9 a4 d9 3b 68 65 6a 2d 0d eb 03 d6 89 e5 54 6b 57 37 dc ad 46 9a 80 22 71 c9 c1 58 b5 33 72 fa de e7 16 4f e8 41 e6 ca 3b b8 35 fd a5 43 f0 e3 56 73 db 6a a0 81 d5 01 8e 5b 44 90 32 80 99 43 8a c8 61 69 a4 64 a7 6c 57 ea 24 c7 fb 03 3e 59 75 13 ee 64 8f 5e b3 f6 d4 a6 c8 a1 08 78 e2 1d 25 d1 ba c3 5e 93 0a 63 1e 32 e1 6c c4 49 30 30 8b f8 53 35 dd 18 6c fb 03 65 db ee c7 95 94 dd ab da 4b c1 3d 71 15 ec 71 e6 d7 d6 67 35 a3 9c c1 55 be c1 fe ef e0 42 3e 30 ad 7b 3d 6e 82 b0 03 34 92 45 af de c6 69 99 ae 30 5d 99 a6 96 03 87 f2 37 6b 33 53 10 7a 91 12 ad 73 95 8c 5c 87 21 a3 33 dc 87 1c 2a 58 7e 26 4d f5 7d a4 fe f1 b2 f0 07 71 19 4a e3 5b 95 eb 94 b3 ef 81 c6 17 14 0d 2f 19 b6 62 0b 6d e9 5f 60 57 fd 67 d9 7f e3 a8 e5 18 f0 4c 96 ff 8f a7 bd 55
Setting new 0503 key
Warning! Got 536 mysterious bytes left! (state=7)
12 34 56 79 1d 02 e2 fd 42 02 4e 3a 1a 7f fe ff ff ff 3d 00 10 7d fa c7 02 eb 7e 68 b0 e1 53 ef 77 9f 83 97 94 b6 aa dd 8d 66 42 16 b8 f2 ec 14 ff cf 34 29 08 96 a3 23 d3 38 0f 86 14 4b c2 09 10 50 0e c1 83 ac 7d 33 25 00 f9 33 3f bf 01 a7 9e de a4 9c 94 7a 3e e9 85 b8 b6 0b db 5a eb 32 25 21 d1 a4 ed 6e f7 34 1a d4 73 9c 8a 45 33 3b 51 85 31 79 2f 1b 02 97 a9 72 1e 93 2f 27 23 7c 05 bc 69 6f 78 33 46 e4 27 bb e0 e5 1e 9a c6 68 e5 71 30 40 83 d7 dd b8 0c 22 fd 12 bd 5e e0 c2 25 1b 27 3b d9 e4 b9 86 f0 06 32 05 36 68 fa ec 9c 56 c1 24 f2 ba 6d 03 4e 51 ee 3f 22 85 8a d1 1e 19 f9 a4 c0 5b 47 14 50 7e 6f 61 ad a4 1e 55 bc 13 e6 68 80 3b ab 05 80 67 dc 13 3b 73 6c 08 2a 77 a4 2f 63 ae 15 5a a1 01 fa 9e cf 75 99 8c 11 a2 4d 16 63 27 cc 1a 07 68 44 9e ff 16 d1 80 a7 c2 ed e9 77 a7 78 4f d2 7f 6f 22 37 42 7c a1 1a 44 63 62 9f 11 58 83 02 5e 83 b4 54 b1 8b 11 c6 e7 65 2c b0 d9 28 aa ce b5 6c 2a 4d c2 05 40 f0 af f3 02 5e 3f d8 af da 61 e4 47 7a 05 8e 7a 91 32 17 e2 93 96 48 d0 30 0b 5f 06 67 f9 72 e2 88 cf 23 7a 58 77 8d 58 c6 a2 0e 59 16 60 0c eb d2 8d 40 06 9f b3 1a 9e ba 78 5e f2 de 43 29 4f 75 15 03 f8 f6 41 80 55 9a cd 31 35 71 ff 10 47 47 8b c4 dd c2 62 1e c0 72 fe 57 9c 15 b2 23 7a 58 6c 64 90 8d 91 93 db ae b2 ee 9f 92 dd 3f 0c 05 a5 62 17 06 3a ec 2d 3e b0 c8 78 d5 1c 38 a1 e8 72 e8 73 46 73 88 da d3 dc bf 24 8f 65 57 f2 da 9e 6e fe b1 06 ee 0b 22 b2 d9 7a 21 a1 a1 18 bc ee 96 a6 d6 2f 70 17 8b 2f c2 a2 f1 e4 6b 19 8a 3a eb cb ed c5 a7 a1 7b a3 f0 a0 87 53 a4 8a ac 58 0c b2 d9 63 14 94 80 37 94 04 06 d9 97 9f bd 05 74 cf db 74 45 7e 57 e3 89 ce 1a a7 46 16 70 1e 6a 7b 85 22 cc 94
Reading from solaredge-20170513111207.pcap
Warning! Checksum failure, skipping over barker...
Warning! Skipping 532 mysterious bytes!
1d 02 e2 fd 44 02 4e 3a 1a 7f fe ff ff ff 3d 00 f2 d2 c6 d1 38 97 51 67 2a 59 c2 8e 2f bf 06 c3 6a 61 6f 3c fa f5 a3 29 eb ea 14 69 e8 f6 97 92 d2 12 9b 78 d1 bf 47 b1 3a 1b 38 5e 09 aa 0f 91 35 2c 80 93 32 99 fe 73 02 f9 8f 28 15 8b f0 d3 9e aa 2a aa fc bb cd 79 c4 95 fd 91 4b 79 a4 f5 3b ba 9f 91 b8 99 0a 37 46 06 0a 2b 04 13 4c 6c b6 f1 6c d1 15 75 60 0a 9e 0d cc bc c8 09 b3 b8 1a e3 a2 81 8b d6 85 f7 b8 9f 36 9f 69 9e 3d eb 69 2a 07 e1 d4 a8 3d 76 7f 42 9b e3 23 93 4c 20 3c 5e 58 26 c2 6d 5a 57 47 3b 24 b8 ca 58 41 05 31 25 80 d6 35 2f 7a 57 3e 63 99 3f e3 3f 29 a4 b0 0f 33 6a ce ff e5 8e 6f 92 9b 92 99 27 1e 23 8c 6b b5 74 24 59 13 e5 71 0f 6f 10 27 06 e0 cf 62 ee 38 8c d0 51 21 2e 62 b9 71 49 ce 1b 87 5c 26 55 48 92 7f 32 9f 09 58 a9 25 a8 4b 27 f2 84 1f 4e b0 a2 69 26 59 02 df 34 32 00 02 42 7a fc f8 85 5d 12 0b e4 1d 81 02 2a be 3b f8 6e d9 0e 5e 72 79 b3 84 f6 89 7f 71 ac 07 0b 58 57 d1 85 86 ac 11 0e 26 f8 22 0b 11 01 90 02 c8 64 5e ed d2 f8 3b f3 cf 5b 92 b4 5b 5c e8 ab ee e0 eb b8 d3 c2 2f 28 89 4b e3 0e f5 2e e4 0d 32 ba bc c5 43 ea 51 f3 fc ce ac 8a 05 97 bb 1f ee 18 d4 1e 96 e8 c2 10 9b 92 48 1c 0c 1e 60 e3 1a fb 5d f1 f2 ee d8 64 15 93 e8 5b 21 51 55 f9 a1 e4 1e 7e 96 9e 78 75 99 bc 12 e1 19 ab 64 d8 a4 2d 4e 33 18 ac de cc 7a 8f 14 92 e0 92 44 8c 60 05 c1 c8 0a aa 44 8c ee 73 56 c3 b5 28 e3 11 21 4d 9f 3b 65 ed 5e 24 d8 9d 4a eb 3f 54 be ee 30 56 95 69 40 73 4b 22 82 98 5b d3 2d 92 e5 20 ea 38 48 ad cf 1e 8c 43 f9 87 9e 11 7c 13 33 87 00 12 b0 5f b4 5d eb 60 b9 8a 8c 08 fb 58 51 12 71 35 61 7e 0f 67 22 78 ee 3c a1 4b 49 d7 5b 3c 3d 1a 3b 4c 0b f0 96 03
Setting new 0503 key
Warning! Checksum failure, skipping over barker...
Warning! Skipping 532 mysterious bytes!
1d 02 e2 fd 45 02 4e 3a 1a 7f fe ff ff ff 3d 00 99 88 84 9e 0e 9c b1 1a 33 24 44 a5 85 69 5c 0d 5d b4 12 17 37 2b 5a 7b a8 65 96 60 04 cb 72 da 41 a4 e5 d7 46 fc 16 73 2c 6c ca ce f5 cc 20 38 25 56 3b 0c b7 29 89 99 4f e5 50 56 c6 b3 22 7b e7 f5 2a c2 09 b8 33 dc 28 05 6a 29 46 36 70 60 7e ed 99 7e 1a 53 91 3a 61 d1 49 97 e7 0f e7 f7 a3 ff 4a 82 ac 24 86 63 00 4f d9 34 7d e6 25 af 85 e6 13 5f 5b e6 d3 80 b7 fa e7 fc 8f 94 a2 88 69 2e 79 e4 b2 b8 18 13 b9 c6 bf 90 ec c7 90 37 19 8f b4 af 69 ca 24 9c 2a 36 0a fc e0 8d bd e3 ad 72 6e ef be 3b 29 bb b2 a0 49 3c 68 5a 08 d9 f8 d6 87 85 2c 86 e9 6e 21 0c 39 ad cf 60 23 bb 6b 93 49 91 cd dd fa ee e0 8b 51 64 d3 56 62 03 6d 84 b6 24 55 52 66 52 43 14 dd 69 4b 24 6f 7a 05 93 3a 44 32 5a fa b2 87 33 c7 c3 a7 50 1c c9 3b c9 4a f4 9a f6 05 82 d0 f3 95 51 68 f9 5f 2d 19 34 f7 41 f9 66 c4 6a 32 8d b9 c2 ec 88 68 47 c5 60 a5 53 38 ac ea e6 a9 a1 34 30 94 5e 3b 83 f5 e6 30 e0 66 73 fd 5a 13 8d 2b 1d c9 88 8a 97 75 d7 5f 47 8a ba 36 08 2f 41 0c 29 bc c6 42 11 c3 5e c8 bb 0f fe 45 ca ce 4b e6 02 71 80 a2 b9 1b 43 4d b7 f0 74 f5 e9 0a d0 c5 7d f2 e3 02 bd 5e b3 a6 d9 d8 0d 84 1a 45 a0 08 43 16 5b 02 b8 aa b3 c5 31 98 54 65 b4 77 9f ce 34 9a 12 99 da e1 d3 38 3e cc 3e 35 31 9c da cf 40 7c b9 db 8b 1c 49 78 33 87 b0 83 ae cb 9d 67 10 38 6f f8 97 ca cf e4 70 16 f8 c1 f8 5a ca 29 d1 23 dc d6 0b 20 1e b1 e2 48 33 52 c5 1a 7a 6f 7b 1b d1 d9 3c 6c 7c ea 46 8e 6c 07 dc c1 91 9f f9 60 37 91 8e 2f be 1a 50 15 88 32 b5 16 00 fb 5c d5 55 38 ff 57 f8 bf 6e b0 b6 19 40 c7 c7 f1 69 12 0e 7f 5f 6c 5b 8f 65 a6 0a 36 a3 21 e4 e8 50 c5 c4 31 46 f8 27 18 99
Setting new 0503 key
Warning! Checksum failure, skipping over barker...
Warning! Skipping 532 mysterious bytes!
1d 02 e2 fd 4c 02 4e 3a 1a 7f fe ff ff ff 3d 00 4d 6e ff 03 15 e5 e0 d9 93 19 fe c9 a7 5c d2 d9 67 ce c9 b9 6a 28 7f 20 29 fc c4 9e 1e ad e3 a5 99 47 4a c8 e4 b4 7d d0 03 34 da b2 26 98 a3 86 65 a9 64 fc ad 07 1e 51 a2 de e7 d5 7b fc 2b 2b a9 77 59 7d 47 1a 1d af a8 76 1a 2d fa e3 31 67 f9 d9 bb 82 71 44 a4 d7 5d 6e 80 ea 83 0b c3 72 a4 19 5b bc 9b c3 cd fc bd 7e 6b de 5f d4 1a 0c 46 5b f5 4c 2d 27 07 8f 1d 56 8b cb 52 e5 23 7a 78 07 4a 70 40 5c 2e 09 5b 11 19 ac a0 68 a7 1f 94 50 7e 0e 43 2a 34 4d 96 a5 25 22 12 8d 86 19 76 e1 d6 24 8a 6d 93 d6 e0 94 a9 ef 14 40 07 5d f1 d4 04 07 14 bb aa 7e fd 55 94 56 d6 21 84 54 71 19 ce db 51 4a 52 3f 12 ed 5f 8a bd 34 38 b5 64 6a 7f a5 54 72 9d 9c a6 92 1f c3 57 ea 19 0e c7 97 ff 47 e3 0c 6b 8e bd 31 b1 e8 74 2d 7c 10 24 f0 ac 2e df db c8 aa 96 36 43 06 a4 18 dd 03 53 ff 03 71 3c f4 ec db 52 8d 90 88 c5 63 46 9e 97 83 02 47 27 a8 47 b1 ce 81 33 62 48 f9 d4 c0 c7 f0 bc b8 e7 cf 54 1b 1b b9 14 ac e0 98 d5 3a 26 b0 62 67 40 2d 73 ad d7 f3 d8 b0 58 75 05 50 e7 1a f8 e7 cf 2f fd 86 23 46 cc f7 a3 49 79 80 86 39 4f ba dc ff 30 68 f0 55 d6 2b 79 3e 68 fb 57 60 38 67 ee 4e 53 8b ad 4f 6e 1c a9 5c b4 30 68 b0 18 16 69 0e 79 a2 74 ca 94 c7 ae 03 5d c0 ea a5 63 00 e3 4c ea 90 7a 12 0b b1 94 68 b6 12 fc fa 9e 9a e6 a4 18 13 21 d6 b4 c4 61 2d 29 d7 a8 d3 90 b3 d1 47 27 d6 1c 09 84 ad 32 29 2d 20 33 76 4d 76 2f 3c 2f 4b ef d5 fa 7e 50 22 03 eb 9b 0b 32 ef ba 05 6c d3 95 81 2e 85 05 14 1c d0 2c e6 b0 3b fd de e4 cb 2f a1 41 ed c6 32 59 18 e3 2e e4 c2 1f 86 b3 65 42 1b c0 b2 01 f6 4b 37 2f 1c ee a7 95 7c 57 6e fd 68 c6 0c 8f 80 6b db b4 17 10 30
Setting new 0503 key
Warning! Checksum failure, skipping over barker...
Warning! Skipping 532 mysterious bytes!
1d 02 e2 fd 53 02 4e 3a 1a 7f fe ff ff ff 3d 00 2f bd 25 96 65 0c 85 c5 97 92 2e d2 67 a8 06 9f 6a d5 8f 3f c8 98 97 52 78 d3 7f c5 9f 0d 5d e7 0d 53 a8 d4 e2 40 0f de 5d 04 6d df 0b dd 23 9f 9a d4 1b c8 bc 20 80 66 36 ea f0 14 c4 83 2a b0 81 b6 8a eb cf 59 7f 5e 5a aa d9 6a 0d 00 51 60 5e 22 1d 31 d5 35 6f 3a 66 16 da 52 6c 64 63 24 cb 02 98 61 52 69 96 18 92 ef 7f c0 a5 19 59 7f af 43 03 18 7f cf d2 f5 ea 6c be 32 65 a8 17 30 d7 0a 60 08 dd d8 bb b6 e5 00 91 11 b6 8e a7 2d 40 6f cf a5 d1 7b dc be de 1c e8 f1 7b 64 b8 a5 97 9e cc 14 dd 62 c0 ec 07 62 bd 23 32 78 96 e4 78 52 b4 66 6c b1 41 bb 8b 36 cf 8a 57 7c 65 7e df ad 6f 06 8f a3 73 32 c4 71 ac f0 4d 47 38 67 19 5c f7 62 db a6 3a f1 63 fe 87 e8 f9 6a d6 77 19 6d 4c 76 c6 0f 40 c0 00 3c d5 2d 67 92 95 49 9a 5b ac 63 dc 0f be 25 19 ca 7d a3 bd ea 7b 28 ce 7f c6 f1 6a 83 8d 6f 4f c6 c2 ef 3f 84 a8 29 95 1d db f6 a0 88 78 cb e7 ce 8d 0d 7e 4a 83 aa 38 6c ea 63 e0 e9 d0 1e 74 62 2e 93 55 3c 3b f4 8d 80 2a a6 af cb 15 7c c9 2e 48 9e 59 3c 64 a0 15 8b 5a a1 39 3c c7 4a 8c 2d d4 32 7b 43 27 0a 79 0e d7 78 0a 32 85 58 e8 6b 11 2c 77 0c 88 5f e0 3f 21 a9 bb 33 15 ad 50 ae b5 a6 24 0b ec 21 42 ef ec 9f 1c e5 c0 82 82 f7 dd bc df 47 94 91 cf e0 e2 d1 b7 9a af 25 34 c9 b3 60 0a 91 70 a5 ee 13 ba 2a eb dd ae 60 3d 1d e5 89 86 4d c5 42 bc a9 67 67 22 67 19 2b 7f 8f 15 fe 69 9b 42 e0 ce 1a c4 15 33 de 0f d6 b3 cb 7b 3b 4a e4 44 e7 54 ec c6 78 57 04 e5 4b 3e ec 53 89 65 b1 e2 f1 a3 9a 96 84 ce 44 e8 db 15 cb 50 6a 71 c2 ea f3 1f 22 6d 86 6d 42 dd 75 fb 25 8b dc e4 b8 6b b0 6d 40 6f 0d f7 d2 63 49 88 e8 58 a4 0a 26 a2 cf e3 50 8c a9
End of file. Shutting down.

Edit2

Een reboot van de pi en even wachten heeft het dus opgelost

[ Voor 98% gewijzigd door Yoki1985 op 13-05-2017 14:30 ]

[Jerrythafast]

Ziet eruit als een haperende verbinding tussen de omvormer en SolarEdge. De omvormer stuurt het eerste deel van de telemetrie data, maar daarna wordt de verbinding gereset en wordt er een nieuwe '0503 key' ingesteld voor de nieuwe verbinding. Omdat liveupdate/se-logger het uiteinde van die telemetriedata niet voorbij ziet komen geeft hij deze warnings. Daarna slaat hij het wel ontvangen stukje data over (de ruwe data zie je erbij staan).

[Yoki1985]

@Jerrythafast ]
Heb jij ook afwijkende waarden tussen de logging en het SE-portaal? Dit is wat ik zie:

Website:


SE-portaal:


Zoals je ziet is op de eerste rij het 3de laatste paneel afwijkend. Volgens mij klopt het SE-portaal wel.
In de database zie ik dezelfde waardes als op de website.

[Jerrythafast]

@Yoki1985 Deze afwijking kan ontstaan als de optimizer halverwege de dag even uit gaat. Dan begint hij weer bij 0 te tellen. Ik gebruik de volgende query i.c.m. een beetje PHP post-processing om hier omheen te werken. Sinds ik dit zo doe heb ik 100% exact hetzelfde getal als op de portal.

PHP:

$e_diff = 0;
$prevrow = ["op_id" => 0, "e_day" => 0, "uptime" => 0];
foreach($_DB->query(
        'SELECT op_id, timestamp, uptime, v_in, v_out, i_in, e_day, temperature ' .
        'FROM telemetry_optimizers ' .
        'WHERE timestamp >= ' . $t_today . ' ' .
        'ORDER BY op_id, timestamp') as $j => $row){
    if($row["op_id"] != $prevrow["op_id"])
        $e_diff = 0;
    elseif($row["uptime"] <= $prevrow["uptime"])
        $e_diff = $prevrow["e_day"];
    $row["e_day"] += $e_diff;
    $prevrow = $row;
    if($j) echo ",";
    echo json_encode($row);
}

[ Voor 4% gewijzigd door Jerrythafast op 15-05-2017 22:28 ]

[Yoki1985]

Hier krijgt de solaredge omvormer WEERAL geen verbinding. Nog iemand last hiervan?

[Aegle]

Uhh. Nee. Hier werkt het prima...

[Vinales]

Solaredge wifi.
In verband met problemen van ethernet over het stroomnet wil ik een wifi module plaatsen id de solaredge. Is dat mogelijk en is deze eenvoudig zelf te monteren (ik ben geen electricien).

[Rouske]

@Vinales zelf heb ik geen ervaring met SE wifi, maar op de SolarEdge download pagina zijn meerdere guides te vinden over wifi. https://www.solaredge.com/downloads#/?cb=495

[Atomic2005]

Vraagje:
Ik heb een foto van de zijkant van een SolarEdge SE2200 omvormer. Kan ik met dat PN of SN nummer publiekelijk zien wat deze heeft opgeleverd afgelopen jaar? ( Omvormer hangt niet bij mij thuis)

[ Voor 9% gewijzigd door Atomic2005 op 15-06-2017 16:54 ]

[Aegle]

@Atomic2005: Volgens mij alleen als de eigenaar of installateur een public account heeft aangemaakt in de portal.

EDIT: zie screenshot hieronder. In Admin -> Site Toegang -> Toegangsbeheer vindt je de mogelijkheid om een installatie publiekelijk zichtbaar te maken:

[ Voor 51% gewijzigd door Aegle op 16-06-2017 15:06 ]

[Jerrythafast]

Inderdaad. Bovendien is er voor zover ik weet is er geen publieke (of publiek bekende...) API waarmee je een PN of SN nummer kunt omzetten in een 'site ID' zoals op het monitoring portaal wordt gebruikt. Dus aan alleen die foto heb je dan nog niet zoveel.

[lemonade]

Hier gaat de setup van @Jerrythafast volgende week ergens draaien, alles klaar om de omvormer in te prikken alleen wil ik de capture limiteren tot alleen de data van de omvormer.
Ik heb nu:

code:

FILTER=-n host 192.168.0.19 tcp

Maar in de pcap zie ik nog steeds andere data langskomen.

Iemand een idee?

[Jerrythafast]

@lemonade Het makkelijkste is om hem te filteren op MAC-adres. Dus zo:

code:

FILTER="tcp && ether host 00:27:02:aa:bb:cc"

(Let op: aa:bb:cc even veranderen zodat het klopt met het MAC-adres van jouw omvormer )

Voordeel hiervan is voornamelijk dat het MAC-adres echt niet gaat veranderen en het IP-adres misschien wel.

[ Voor 19% gewijzigd door Jerrythafast op 16-06-2017 10:37 ]

[lemonade]

Als ik deze run:

code:

tcpdump -i eth0 -U -w - -n "tcp && src host 192.168.0.19"

krijg ik te zien wat ik wil zien.
Maar als ik dit filter toepas:

code:

FILTER=-n "tcp && src host 192.168.0.19"

krijg ik meer resultaten dan alleen van .19.

Mis ik iets?

@Jerrythafast Het IP adres kan ik al configureren, het MAC niet En het IP adres wordt wat ik nu configureer dus dat is geen probleem.

[Jerrythafast]

@lemonade, volgens mij kun je niet 2 opties tegelijk ("-n" en "tcp ...") via dezelfde variabele ($FILTER in dit geval) opgeven. Misschien de -n optie (als die al nodig is in combinatie met -w ) gewoon rechtstreeks bij het tcpdump commando zetten?

[ Voor 5% gewijzigd door Jerrythafast op 16-06-2017 11:59 ]

[lemonade]

Het is deze geworden, verwacht dat dit goed gaat werken.

code:

FILTER="tcp && src host 192.168.0.19 && !dst net 192.168.0.0/24"

De database draait extern en ik wil dat lokale verkeer niet in de dump hebben.

Nu nog even iets maken zodat ook m'n verbruik richting PVOutput gaat.

[CubicQ]

Vorige week zijn bij ons zonnepanelen geplaatst, SE omvormer, dus week ervoor m'n HP Microserver met Ubuntu 16.4 LTS met 2 netwerkpoorten in bridge gezet.

Paar 'problemen' gehad:
- Doordat ik ook een eigen DNS draaide (pihole) op die machine werkte die niet meer omdat de interface van eno1 naar br0 ging - aanpassing van pihole config (binding interface aanpassen) had geen effect. Daardoor werkte tcpdump ook niet lekker: die probeert standaard een DNS lookup te doen, en dat timede de hele tijd uit. Oplossing: pihole uitzetten, en DNS in DHCP server weer terug naar de oude waaren zetten...
- Om een of andere reden werkt de statische configuratie van de br0 niet... ip adres blijft heen en weer gekoppeld worden aan br0 en aan eno1 - terwil eno1 in config op manual staat. Uiteindelijk omgezet naar DHCP, toen werkte opeens alles wel (?). Nog vreemder: na een herstart staat de configuratie op DHCP, maar heeft br0 het oude statische ip adres (wat buiten de DHCP range ligt, en wat dus nergens in de configuratie staat...)
Al met al: volgens mij klopt er nog iets niet in de netwerkconfiguratie Maar het werkt iig wel

Monitoring software werkte in helemaal perfect (draait nu nog onder root... - ook nog een keer aanpassen...). Moest wel 'KillMode=control-group' gebruiken. Toen de omvormer aangesloten werd werd de database netjes gevuld.

Wat wel bijzonder is: inmiddels draait het meer dan week, maar het verkeer is nog steeds niet encrypted...

Jerrythafast, bedankt!

[Jerrythafast]

@CubicQ mooi om te horen dat de logging software zelf in ieder geval niet één van je problemen was Misschien heeft SolarEdge de encryptie maar weer opgegeven Welke omvormer heb je eigenlijk? Misschien is het ook wel leuk om wat foto's in Elektriciteit opwekken met zonnepanelen (PV) Deel 6 te zetten

[CubicQ]

Een SolarEdge 3000 HD: https://pvoutput.org/list.jsp?userid=59167

Het idee was om even te wachten met het klooien aan m'n software (als eigen user draaien, bestanden meenemen in geautomatiseerde backup, en toch nog eens kijken naar de netwerksettings), tot ik iig de encryptiekey heb kunnen bemachtigen... maar het duurt zo wel heel lang

Edit:
Op dit moment backup is de bestanden helemaal niet De Microserver is ook NAS, die ik op twee manieren beckup: 1x via een snapshot mechanisme naar een lokale schijf (a la timemachine - om bestanden terug te krijgen), 1x via rclone naar b2 (huidige snapshot, retentie van oude versies op 180d via b2 - als disaster recovery). Eigenlijk moet ik gewoon met rsync de /opt/se-logger directory kopieren naar een directory die ik backup, en dan ben ik klaar.... kost minder tijd dan het editen van deze post...

snapshot mechanisme:

code:

#!/bin/sh
date=`date "+%Y%m%d%H%M%S"`
rsync -aP --link-dest=/backup/data/snapshot-current /data /backup/data/snapshot-$date
rm -f /backup/data/snapshot-current
ln -s /backup/data/snapshot-$date /backup/data/snapshot-current

backup:

code:

root@microserver:~# cd /data/shared/
root@microserver:/data/shared# mkdir se-logger
root@microserver:/data/shared# chown back:users se-logger/
root@microserver:/data/shared# chmod 775 se-logger
back@microserver:/data/shared/se-logger$ crontab -l
...
# m h  dom mon dow   command
10 16 * * * rsync /opt/se-logger /data/shared/se-logger
15 16 * * * /home/back/make-snapshot.sh
34 19 * * 2 /usr/sbin/rclone sync --log-file /home/back/b2.log /data remote-b2:<naam>

[ Voor 65% gewijzigd door CubicQ op 18-06-2017 18:32 ]

[RTB]

CubicQ schreef op zondag 18 juni 2017 @ 12:27:

Wat wel bijzonder is: inmiddels draait het meer dan week, maar het verkeer is nog steeds niet encrypted...

Ik zit hier inmiddels al op 12 dagen en nog geen encryptie gezien... Ik had in eerste instantie enkel TCPDump draaien en checkte meerdere keren per dag met het script van Jerry of er een key in de dump voorkwam. Toen dat na 48 uur nog steeds niet het geval was had ik het bange vermoeden dat ik "het" moment gemist had (zelfs nog met de hand in de dump gezocht omdat ik dacht dat het script dan wel niet zou functioneren ofzo ;-) )

Toen toch maar de rest van de PVOutput setup geconfigureerd en die setup draait nog steeds zonder aanpassingen (lees: encryption key)

[Aegle]

@CubicQ: hoe back-up jij je .pcap? Ik doe het nu nog één keer per week handmatig naar Stackstorage, maar nog niet geautomatiseerd. Ik zit zelf aan rsync te denken...

EDIT: wel off-topic.... .

[ Voor 8% gewijzigd door Aegle op 18-06-2017 17:01 ]

[Atomic2005]

@Jerrythafast @Aegle
Het was bedoeld om een inschatting te maken van de jaaropbrengst van die omvormer.Heb verder geen contact met de eigenaar. Maar dank voor info.

[Jerrythafast]

RTB schreef op zondag 18 juni 2017 @ 15:38:
(zelfs nog met de hand in de dump gezocht omdat ik dacht dat het script dan wel niet zou functioneren ofzo ;-) )

Bedankt voor het gestelde vertrouwen

Maar wel interessant dat encryptie bij jullie zo lang op zich laat wachten. Ik ben heel benieuwd of het nog gaat komen (en in welke vorm dan...)

[Aegle]

Op mijn RPi2 waar de logging software en SQL-database op draait, draait ook de website om het e.e.a. te visualiseren. De website wil ik hier echter vanaf halen zodat ie alleen dedicated voor de logging wordt gebruikt.

Nu heb ik de website op m'n RPi3, die in hetzelfde netwerk zit, geïnstalleerd. Dat was niet zo moeilijk. Echter, hoe benader ik nu de database? Met MySQL kan ik de database met geen mogelijkheid benaderen vanaf de RPi3.
O.a op Stackoverflow e.e.a. uitgevoerd, zoals poort 3306 openzetten en "grand all privileges", etc. Maar nog steeds zonder resultaat. SQL draait wel gewoon onder "root". Nier de veiligste manier, maar dat moet toch niet uitmaken. Vanaf buiten benader ik mijn thuisnetwerk toch via OpenVPN op dezelfde RPI3.

Ik zie ongetwijfeld iets over het hoofd. Komt misschien wel door het warme weer... .

Help?

[ocaj]

Je moet het script aanpassen. De connect-string maakt standaard verbinding met de lokale computer waar het script op draait. Heb je een aparte databaseserver, dan moet er een "host = hostname" veld aan het connect-commando toegevoegd worden.

[Aegle]

@ocaj: bedankt voor je reactie. Eindelijk weer eens wat tijd om te "pielen".

Die host had ik al toegevoegd in de connect-string, maar voordat ik met de webpagina aan de gang wilde gaan, wilde ik met MySQL op de RPi3 de database kunnen benaderen. Pas toen dat lukte ben ik verder gegaan met het "migreren" (... ) van de webpagina naar de RPi3.

Ik bleef maar error 2003 (can't connect to database) krijgen. Het probleem was simpel: Om voor mij onduidelijke reden was in my.cnf bind-address = 127.0.0.1 niet uit ge-comment. Ik was er van overtuigd dat dat wel zo was

De website draait nu via de RPi3 .

Storm in een glas water dus... .

Toch bedankt voor het meedenken .

EDIT: Ontopic maar weer...

[serienummer]

3ssen schreef op donderdag 20 april 2017 @ 13:32:

Nu dan de optie geprobeerd om via usb aan te sluiten en dan de sleutel op te vragen. Hierbij heb ik de volgende uitdaging (of een nieuwe bril nodig). Ik kan namelijk nergens de usb aansluiting vinden. Begreep van een post van @tsjoender dat deze naast de ethernet aansluiting zou zitten bij de 3000H. Maar kan hem dus niet vinden.

Hoi,
Hier heb ik een vaag over.
Deze week zijn er bij mij ook zonnepanelen geinstaleerd met de SolarEdge SE4000H. Hier zit geen RS232 aansluiting op, althans niet aan de buitenkant. Helaas heb ik dit forum te laat gevonden anders had ik het een en ander voor bereid. (Als het goed is) loopt er nu een TCP dump van de UTP interface van de SolarEdge. Ik hoop dat hier de key bij zit. Maar mocht dit nu niet lukken. is er dan nog een andere manier om deze key te achterhalen? Zijn er al mensen die het gelukt is?

groeten
Palermo

[3ssen]

Heb zelf al wel een usb -> rs485 module aangeschaft, maar in verband met een nieuwe baan nog niet de tijd gevonden om deze aan te sluiten en dan proberen uit te lezen.

[serienummer]

3ssen schreef op vrijdag 30 juni 2017 @ 08:54:
Heb zelf al wel een usb -> rs485 module aangeschaft, maar in verband met een nieuwe baan nog niet de tijd gevonden om deze aan te sluiten en dan proberen uit te lezen.

Hoi,
Heb je er ook een voorbeeld van?

Groeten
Palermo

[3ssen]

serienummer schreef op vrijdag 30 juni 2017 @ 08:57:
[...]


Hoi,
Heb je er ook een voorbeeld van?

Groeten
Palermo

Deze module is het https://www.antratek.com/usb-rs485-module
Meer info en scripts kan je ook vinden bij https://github.com/jbuehl/solaredge

[ocaj]

Of zoiets: http://www.dx.com/p/usb-to-rs-485-adapter-8504 natuurlijk, waarmee je RS485 makkelijk aan een USB-poort van een raspberry pi o.i.d. kunt hangen.

[serienummer]

Zou inderdaad ook kunnen, Is er ook een pinout beschikbaar hoe aan te sluiten op de BAGBAG pinnen?
Ik heb ook begrepen dat het niet zeker is dat de Key via de RS485 poort verzonden wordt.

Iemand een idee?

Hier ook nog een paar alternatieven:
https://www.banggood.com/search/rs485-adapter.html

[ Voor 18% gewijzigd door serienummer op 30-06-2017 10:59 ]

[Jerrythafast]

Het is niet zeker omdat nog niemand het op een HD Wave heeft geprobeerd...

[ocaj]

En ik gebruik wel RS485, maar mijn omvormers hangen niet aan het Internet, dus die hebben nooit de opdracht gekregen om te gaan versleutelen

[Jerrythafast]

@ocaj jij zou ze natuurlijk wel kunnen proberen te vragen naar hun sleutels

[RTB]

serienummer schreef op vrijdag 30 juni 2017 @ 07:57:
[...]
(Als het goed is) loopt er nu een TCP dump van de UTP interface van de SolarEdge. Ik hoop dat hier de key bij zit. Maar mocht dit nu niet lukken. is er dan nog een andere manier om deze key te achterhalen? Zijn er al mensen die het gelukt is?

Verbaas je in ieder geval niet als je helemaal geen key aantreft in de dump. Omdat ik overal las dat de encryptie binnen 48 uur zou starten, ging ik zelfs twijfelen aan Jerry's script om de key te achterhalen ;-) Ik had namelijk enkel de TCPDump opgezet en verder nog niets (geen mySQL,geen PVOutput logging etc), maar controleerde wel steeds met het script of er een key in de dumps voorkwam.

Inmiddels draait de setup hier vanaf 6 juni en nog steeds zonder encryptie...

[Jerrythafast]

Ik heb goede hoop dat ze er maar gewoon mee gekapt zijn! Kijken wat er bij @serienummer gebeurt...

[ocaj]

Jerrythafast schreef op vrijdag 30 juni 2017 @ 19:30:
@ocaj jij zou ze natuurlijk wel kunnen proberen te vragen naar hun sleutels

Wat ik er van begrepen heb (maar dat weet jij vast veel beter dan ik) is dat de sleutels aangemaakt door de solaredge-server en dan opgestuurd naar de omvormer. Of is het andersom en vraagt de solaredge-server aan de omvormer om een sleutel te maken en op te sturen naar de server?

Ik neem geen risico, ik heb geen enkele behoefte aan encryptie op mijn RS485-kabel, dus ga er ook niet om vragen...

[serienummer]

Hoi RTB,
Heb heb de dump een 12uur later aangezet. Maar er zit inderdaad geen Key bij (Volgens het script).
Hij kan al geweest zijn. Maar uit jou antwoord las ik dat je gewoon valid data hebt en het niet versleuteld is.
Interpreteer ik dat goed? Heb jij ook een SolarEdge SE3/4000H?

Groeten
Palermo