[SolarEdge] Omvormers en optimizers zelf monitoren

[MO1234]

Ik weet niet of dit het juiste topic is maar ga de vraag hier toch stellen:
Vorige maand zelf de volgende installatie geïnstalleerd:
- 4.5 kWp
-Omvormer SE5K
-ZO/ZW 7/8
-15x P404 optimizers.

Momenteel gebruik ik het Solar Edge dashboard om mijn panelen te monitoren.
Nu lijkt het erop dat als ik som van mijn layout pak (per paneel) en deze vergelijk met wat de omvormer aangeeft er een verschil is tussen de 10-20% en bij een bewolkte dag zelfs 50% meer.

Voorbeeld:
Zonnige dag: omvormer 10kWh Som van panelen = 11,3kWh
Bewolkte dag: omvormer 300Wh Som van panelen = 665 Wh

Wat heb ik al gedaan:
-Omvormer gereset.
-Opnieuw opgestart.
-Contact opgezocht met de leverancier.

Is de meting van de afzonderlijke panelen niet betrouwbaar?
Is er tussen de panelen en output naar net zoveel verlies?

[Tomba]

Tomba schreef op woensdag 31 oktober 2018 @ 16:11:
@Jerrythafast (of anderen binnen dit topic ), binnenkort (lees over 1.5 maand) wordt er een SolarEdge bij ons opgehangen en ik wil deze uiteraard ook gaan loggen. In je topicstart verwijs je (terecht ) naar een RaspBerry. Ik heb nog een originele Pi B (de eerste dus met 256MB geheugen) Denk je dat ik daarmee toekom? (Zou het mooi vinden als ik m hiervoor in kon zetten)

Inmiddels heb ik e.e.a. draaien (of ja ik kan een aangesloten laptop sniffen op de Pi de SolarEdge komt pas medio december....) maar het heeft wat kruim gekost.
Mijn doel was om (omdat ik toch een managed switch heb) de ethernet poort van de RasPi op te splitsen in een Untagged (op internet aangesloten) interface en een Tagged VLAN interface. De SolarEdge komt dan Untagged in hetzelfde VLAN als de Tagged interface van de RasPi. Hoef ik niet te kloten met een USB netwerkkaart met ditto hoge load.

Verder heb ik de installatie gevolgd zoals in de (geweldige!) topicstart sectie 4.1 beschreven staat. Met Raspbian Stretch liep ik er tegenaan dat de VLAN interface niet automatisch opkwam na een reboot. (alleen na een ifup of een networking stack herstart)
Tot mijn verbazing kreeg ik weinig hulp in het door mij op Tweakers geopende topic maar gelukkig heb ik via het Raspberry forum toch een oplossing kunnen vinden, zie Tomba in "VLAN interface op Raspbian Stretch" voor de korte samenvatting. Wellicht heeft iemand anders er nog wat aan

@Jerrythafast kan ik (buiten een TCPDump test op de interface) nog andere zaken testen zonder SolarEdge? (Bv de connectie naar de database die op een andere machine draait)

[ Voor 3% gewijzigd door Tomba op 04-11-2018 11:46 ]

[Jerrythafast]

Staatslot schreef op vrijdag 2 november 2018 @ 08:38:
Hallo allemaal,

Mijn inverter is na een goeie 2 weken nog steeds niet encrypted, vreemd genoeg..
De data gaat netjes de MySQL database in.

Wat ik alleen niet goed begrijp, ik zie al vrij snel de kolom e_day naar 500 gaan, en die blijft dat de rest vd dag 500. Ik zie wel de e_total en de de_day blijven oplopen.

Zie hieronder
[Afbeelding: Solaredge 500eday max]

Doe ik iets niet goed, of begrijp ik iets niet goed? Thanks!

Nee hoor, dat zie je goed. Dit is een bug in de SolarEdge firmware. Je kunt de waardes van de_day van die dag tot op dat moment bij elkaar optellen om de correcte waarde te krijgen. De monitoring website lijkt het ook op die manier op te lossen.

MO1234 schreef op zondag 4 november 2018 @ 11:28:
Ik weet niet of dit het juiste topic is maar ga de vraag hier toch stellen:
Vorige maand zelf de volgende installatie geïnstalleerd:
- 4.5 kWp
-Omvormer SE5K
-ZO/ZW 7/8
-15x P404 optimizers.

Momenteel gebruik ik het Solar Edge dashboard om mijn panelen te monitoren.
Nu lijkt het erop dat als ik som van mijn layout pak (per paneel) en deze vergelijk met wat de omvormer aangeeft er een verschil is tussen de 10-20% en bij een bewolkte dag zelfs 50% meer.

Voorbeeld:
Zonnige dag: omvormer 10kWh Som van panelen = 11,3kWh
Bewolkte dag: omvormer 300Wh Som van panelen = 665 Wh

Op een zonnige dag zou je misschien 1% verschil moeten zien tussen panelen en omvormer, op een bewolkte dag kan dat wel oplopen naar 10%. 665 Wh op een bewolkte dag uit 4500 Wp is ook maar slecht; ter vergelijking: bij mijn ouders leverden 2925 Wp panelen 562 Wh op afgelopen 30 oktober.

Zou het kunnen zijn dat je panelen in twee parallele strings zijn aangesloten? Immers, een SE5K wil 750 Volt hebben. In de datasheet van de P404 optimizer staat dat die maximaal 85 Volt leveren en er daarom minimaal 13 in serie moeten volgens SolarEdge. Dat zou de beroerde efficiency kunnen verklaren (al had ik dan eigenlijk verwacht dat het hele zaakje zelfs bij goed weer niks zou doen).

Tomba schreef op zondag 4 november 2018 @ 11:42:
[...]

@Jerrythafast kan ik (buiten een TCPDump test op de interface) nog andere zaken testen zonder SolarEdge? (Bv de connectie naar de database die op een andere machine draait)

Mooie setup! Om de connectie naar de database te testen zou je het makkelijkst mysql-client kunnen installeren. Of nog beter: probeer se-logger te starten, als alles goed werkt zou die gewoon "Reading from -" in /opt/se-logger/liveupdate.log moeten zetten en dan stilletjes moeten wachten op SolarEdge verkeer. Als hij de database niet kan bereiken zal hij voordat hij daar überhaupt komt al op zijn gat zijn gegaan met een error.

[ Voor 62% gewijzigd door Jerrythafast op 04-11-2018 13:15 ]

[Tomba]

Jerrythafast schreef op zondag 4 november 2018 @ 13:11:
[...]

Mooie setup! Om de connectie naar de database te testen zou je het makkelijkst mysql-client kunnen installeren. Of nog beter: probeer se-logger te starten, als alles goed werkt zou die gewoon "Reading from -" in /opt/se-logger/liveupdate.log moeten zetten en dan stilletjes moeten wachten op SolarEdge verkeer. Als hij de database niet kan bereiken zal hij voordat hij daar überhaupt komt al op zijn gat zijn gegaan met een error.

Tx
Heb de service gestart en krijg netjes:

code:

Reading from -

in /opt/se-logger/liveupdate.log

Ook wordt de pcap gevuld als ik een website open op de laptop die voorlopig als 'SE Emulator' geldt

code:

-rw-r--r-- 1 root root 1660108 Nov  4 14:29 solaredge-20181104132715.pcap

hartstikke bedankt voor je mooie werk en positieve attitude @Jerrythafast

[Aanvulling]
@Jerrythafast klopt het dat pvo-output.log leeg blijft als hij niets heeft om door te sturen?

[ Voor 5% gewijzigd door Tomba op 04-11-2018 14:38 ]

[Jerrythafast]

Tomba schreef op zondag 4 november 2018 @ 14:31:
[Aanvulling]
@Jerrythafast klopt het dat pvo-output.log leeg blijft als hij niets heeft om door te sturen?

Jep, hier komen alleen eventuele errors in te staan. (Als je twijfels hebt of die netjes periodiek runt zou je de query in het begin van het PHP script even kunnen slopen en kijken of je elke 2 minuten een error krijgt )

[Tomba]

Jerrythafast schreef op zondag 4 november 2018 @ 16:22:
[...]

Jep, hier komen alleen eventuele errors in te staan. (Als je twijfels hebt of die netjes periodiek runt zou je de query in het begin van het PHP script even kunnen slopen en kijken of je elke 2 minuten een error krijgt )

Hahaha, komt helemaal goed dan Super bedankt voor de reactie. Als we live zijn (panelen worden 17 december geplaatst) zal ik me weer melden

[ocaj]

Jerrythafast schreef op zondag 4 november 2018 @ 13:11:
[...]

Nee hoor, dat zie je goed. Dit is een bug in de SolarEdge firmware. Je kunt de waardes van de_day van die dag tot op dat moment bij elkaar optellen om de correcte waarde te krijgen. De monitoring website lijkt het ook op die manier op te lossen.

Weet je dat zeker @Jerrythafast ?
Zoals je weet gebruik ik de jbuehl-software en daar komt de E_day van de inverter gewoon al 2,5 jaar lang correct uit, die stopt niet bij 500, maar eindigt op een waarde die vergelijkbaar is mijn kwh-meter (SE een beetje optimistischer).
Een hele enkele keer valt de E_day (net als de optimizers) terug naar 0, maar dan moet je echt zo'n donkere winterse regenbui hebben dat de omvormer denkt dat het nacht geworden is.

Het zou ook kunnen dat het een firmware-bug die alleen optreed op de HTTP-interface? (Ik gebruik alleen RS485). Maar dat kun je vast in je pcap-bestanden napluizen....

[MO1234]

Jerrythafast schreef op zondag 4 november 2018 @ 13:11:
[...]

Nee hoor, dat zie je goed. Dit is een bug in de SolarEdge firmware. Je kunt de waardes van de_day van die dag tot op dat moment bij elkaar optellen om de correcte waarde te krijgen. De monitoring website lijkt het ook op die manier op te lossen.

[...]

Op een zonnige dag zou je misschien 1% verschil moeten zien tussen panelen en omvormer, op een bewolkte dag kan dat wel oplopen naar 10%. 665 Wh op een bewolkte dag uit 4500 Wp is ook maar slecht; ter vergelijking: bij mijn ouders leverden 2925 Wp panelen 562 Wh op afgelopen 30 oktober.

Zou het kunnen zijn dat je panelen in twee parallele strings zijn aangesloten? Immers, een SE5K wil 750 Volt hebben. In de datasheet van de P404 optimizer staat dat die maximaal 85 Volt leveren en er daarom minimaal 13 in serie moeten volgens SolarEdge. Dat zou de beroerde efficiency kunnen verklaren (al had ik dan eigenlijk verwacht dat het hele zaakje zelfs bij goed weer niks zou doen).

[...]

Mooie setup! Om de connectie naar de database te testen zou je het makkelijkst mysql-client kunnen installeren. Of nog beter: probeer se-logger te starten, als alles goed werkt zou die gewoon "Reading from -" in /opt/se-logger/liveupdate.log moeten zetten en dan stilletjes moeten wachten op SolarEdge verkeer. Als hij de database niet kan bereiken zal hij voordat hij daar überhaupt komt al op zijn gat zijn gegaan met een error.

Bedankt voor je antwoord.
30 okt gaven mijn panelen +900 Wh aan (wat zou overeen komen met je ouders) echter omvormer geeft 362Wh aan.
Panelen zijn aangesloten als 1 string.

Hier onder de voltages van het systeem.



Eerst grafiek 30-10 362 Wh
Tweede grafiek 31-10 9,3kWh
Zoals je ziet is voltage (groen) +/- 750 VDC. Moet zeggen dat eerste grafiek heeft een paar uitschieters na +800DC
Rood is Wh

[Jerrythafast]

ocaj schreef op zondag 4 november 2018 @ 16:59:
[...]


Weet je dat zeker @Jerrythafast ?
Zoals je weet gebruik ik de jbuehl-software en daar komt de E_day van de inverter gewoon al 2,5 jaar lang correct uit, die stopt niet bij 500, maar eindigt op een waarde die vergelijkbaar is mijn kwh-meter (SE een beetje optimistischer).
Een hele enkele keer valt de E_day (net als de optimizers) terug naar 0, maar dan moet je echt zo'n donkere winterse regenbui hebben dat de omvormer denkt dat het nacht geworden is.

Het zou ook kunnen dat het een firmware-bug die alleen optreed op de HTTP-interface? (Ik gebruik alleen RS485). Maar dat kun je vast in je pcap-bestanden napluizen....

Yep, 100% zeker. Het zit gewoon zo in de pcap!

MO1234 schreef op zondag 4 november 2018 @ 17:16:
[...]


Bedankt voor je antwoord.
30 okt gaven mijn panelen +900 Wh aan (wat zou overeen komen met je ouders) echter omvormer geeft 362Wh aan.
Panelen zijn aangesloten als 1 string.

Hier onder de voltages van het systeem.

[Afbeelding]

Eerst grafiek 30-10 362 Wh
Tweede grafiek 31-10 9,3kWh
Zoals je ziet is voltage (groen) +/- 750 VDC. Moet zeggen dat eerste grafiek heeft een paar uitschieters na +800DC
Rood is Wh

Heb je toevallig ook een grafiek van de optimizer spanning van alle optimizers? Die zouden met 15 panelen in serie allemaal zo rond de 50 Volt moeten zitten. Alleen in de ochtend verwacht ik dat de panelen op zuidoost wat hoger zitten en die op zuidwest wat lager en aan het einde van de middag andersom. Uiteraard zouden optimizers van panelen in de schaduw op die betreffende momenten lagere spanning moeten geven dan de anderen.

[MO1234]

Jerrythafast schreef op zondag 4 november 2018 @ 19:06:
[...]

Yep, 100% zeker. Het zit gewoon zo in de pcap!

[...]

Heb je toevallig ook een grafiek van de optimizer spanning van alle optimizers? Die zouden met 15 panelen in serie allemaal zo rond de 50 Volt moeten zitten. Alleen in de ochtend verwacht ik dat de panelen op zuidoost wat hoger zitten en die op zuidwest wat lager en aan het einde van de middag andersom. Uiteraard zouden optimizers van panelen in de schaduw op die betreffende momenten lagere spanning moeten geven dan de anderen.

Dag met weinig zon alles rond de 50VDC. Met veel zon is het zoals je beschrijft.

[stormfly]

Tomba schreef op zondag 4 november 2018 @ 11:42:
[...]

Inmiddels heb ik e.e.a. draaien (of ja ik kan een aangesloten laptop sniffen op de Pi de SolarEdge komt pas medio december....) maar het heeft wat kruim gekost.
Mijn doel was om (omdat ik toch een managed switch heb) de ethernet poort van de RasPi op te splitsen in een Untagged (op internet aangesloten) interface en een Tagged VLAN interface. De SolarEdge komt dan Untagged in hetzelfde VLAN als de Tagged interface van de RasPi. Hoef ik niet te kloten met een USB netwerkkaart met ditto hoge load.
[Afbeelding]
Verder heb ik de installatie gevolgd zoals in de (geweldige!) topicstart sectie 4.1 beschreven staat. Met Raspbian Stretch liep ik er tegenaan dat de VLAN interface niet automatisch opkwam na een reboot. (alleen na een ifup of een networking stack herstart)
Tot mijn verbazing kreeg ik weinig hulp in het door mij op Tweakers geopende topic maar gelukkig heb ik via het Raspberry forum toch een oplossing kunnen vinden, zie Tomba in "VLAN interface op Raspbian Stretch" voor de korte samenvatting. Wellicht heeft iemand anders er nog wat aan

@Jerrythafast kan ik (buiten een TCPDump test op de interface) nog andere zaken testen zonder SolarEdge? (Bv de connectie naar de database die op een andere machine draait)

Heb je met een pc getest of het werkt, browsen etc? Zonder NAT regels in je OS krijgt het van 113 geen internet. Je hebt nat nodig van vlan 113 naar vlan 12 (internet). Omdat de SE naar de server moet communiceren, anders heb je niets te onderscheppen

Heb dezelfde setup alleen dan in een VM met Ubuntu.

EDIT lees net dat je al getest hebt met een laptop.

[Jerrythafast]

MO1234 schreef op zondag 4 november 2018 @ 20:36:
[...]


Dag met weinig zon alles rond de 50VDC. Met veel zon is het zoals je beschrijft.

[Afbeelding]

[Afbeelding]

Dat ziet er inderdaad wel uit zoals ik had verwacht voor een goed werkend systeem, daar lijkt toch niet echt iets mis te zitten. Zou het dan echt de efficiency van de optimizers en omvormer zijn? Je omvormer is wel aardig overgedimensioneerd, maar dan nog zou ik toch zeggen dat het hoger moet kunnen uitvallen op basis van de efficiency grafieken

Als je installateur het ook niet weet zou je misschien rechtstreeks naar SolarEdge support kunnen mailen, misschien dat zij er iets zinnigs over kunnen zeggen.

Het enige probeersel dat ik zou kunnen verzinnen: een kleinere omvormer eraan hangen, om hem in een hoger efficiency-bereik te krijgen. Als dat de situatie oplost is mijn conclusie dat een SE5K (of in ieder geval die van jou) een beroerde efficiency heeft. En als dat niet helpt weet ik het eigenlijk ook niet meer

[ Voor 12% gewijzigd door Jerrythafast op 04-11-2018 20:52 ]

[Rouske]

@MO1234 als ik de Wh waarden van mijn panelen op tel, dan is dat zeker ook meer dan wat de omvormer als levering aangeeft. Dat is wel de DC kant en je hebt natuurlijk nog wel het DC/AC omzet verlies.

Vandaag bij mij 10,118 kWh bij optellen panelen, omvormer zegt 9,88 kWh.
Een DC/AC efficiency van 97,65?

[MO1234]

Jerrythafast schreef op zondag 4 november 2018 @ 20:48:
[...]

Dat ziet er inderdaad wel uit zoals ik had verwacht voor een goed werkend systeem, daar lijkt toch niet echt iets mis te zitten. Zou het dan echt de efficiency van de optimizers en omvormer zijn? Je omvormer is wel aardig overgedimensioneerd, maar dan nog zou ik toch zeggen dat het hoger moet kunnen uitvallen op basis van de efficiency grafieken

Als je installateur het ook niet weet zou je misschien rechtstreeks naar SolarEdge support kunnen mailen, misschien dat zij er iets zinnigs over kunnen zeggen.

Bedankt voor het mee denken.
Vraag staat ondertussen al uit bij SolarEdge. Systeem aangeschaft op de toekomst zullen waarschijnlijk nog meer panelen bijkomen.

[Jerrythafast]

Rouske schreef op zondag 4 november 2018 @ 20:53:
@MO1234 als ik de Wh waarden van mijn panelen op tel, dan is dat zeker ook meer dan wat de omvormer als levering aangeeft. Dat is wel de DC kant en je hebt natuurlijk nog wel het DC/AC omzet verlies.

Vandaag bij mij 10,118 kWh bij optellen panelen, omvormer zegt 9,88 kWh.
Een DC/AC efficiency van 97,65?

Zulke cijfers scoort het systeem bij mijn ouders ook, maar bij MO1234 hebben we het over 88% op een goede dag... dat is toch andere koek!

[ocaj]

Jerrythafast schreef op zondag 4 november 2018 @ 19:06:
[...]

Yep, 100% zeker. Het zit gewoon zo in de pcap!

Bijzonder, dat is dan dus een HTTP-only bug. Ook bijzonder dat ze dat niet fixen middels een firmware-upgrade.
Zoals gezegd: Op RS485 klopt de data gewoon....

[Rouske]

@MO1234 welke uitbreidingen heb je voor ogen, aan beide kanten extra panelen?
Of hoeveel panelen kan je op elk dakvlak kwijt?

Want ik weet bijna zeker dat SolarEdge gaat zeggen, dat het minimale aantal op elk dakvlak te laag is voor een goede werking met een 3 fase omvormer.

Zoals @Jerrythafast al zegt een 1-fase omvormer toepassen, aangezien daar maar 6x een P404 voor nodig is. Voor elk dakvlak 1?

[MO1234]

Rouske schreef op zondag 4 november 2018 @ 21:54:
@MO1234 welke uitbreidingen heb je voor ogen, aan beide kanten extra panelen?
Of hoeveel panelen kan je op elk dakvlak kwijt?

Want ik weet bijna zeker dat SolarEdge gaat zeggen, dat het minimale aantal op elk dakvlak te laag is voor een goede werking met een 3 fase omvormer.

Zoals @Jerrythafast al zegt een 1-fase omvormer toepassen, aangezien daar maar 6x een P404 voor nodig is. Voor elk dakvlak 1?

Uiteindelijk wil ik per kant 10 tot 11 stuks dus 6000 tot 6600 wp totaal.

[Jerrythafast]

ocaj schreef op zondag 4 november 2018 @ 21:07:
[...]


Bijzonder, dat is dan dus een HTTP-only bug. Ook bijzonder dat ze dat niet fixen middels een firmware-upgrade.
Zoals gezegd: Op RS485 klopt de data gewoon....

Dat verbaast mij inderdaad ook! Ik denk dat ze hem niet fixen omdat die waarde toch al niet werd gebruikt door de monitoring website. Immers kan die teller als hij wél goed werkt ook nog halverwege de dag terug naar 0 springen wanneer er een donkere bui over trekt. Toen ik met se-logger begon in 2016 was deze bug er ook nog niet, maar was wel al snel duidelijk dat de monitoring website zelf de de_day waardes bij elkaar optelt voor het juiste totaal. De bug is er pas later in geslopen, maar ik vermoed dat niemand dat door heeft gehad omdat het toch een ongebruikt ding is.

Het is niettemin inderdaad wel weird dat dit via RS-485 blijkbaar wel gewoon goed gaat!


@MO1234 ik ben eigenlijk wel benieuwd wat het hoogste AC vermogen is dat je tot nu toe hebt gehaald. Omdat de panelen niet gelijktijdig pieken, zou het mij niks verbazen als je de 3500 Watt nog niet bent gepasseerd.

[ Voor 10% gewijzigd door Jerrythafast op 05-11-2018 09:52 ]

[stormfly]

Nu we hier toch een beetje afdwalen naar meer SE gerelateerde vragen en bugchat, weet iemand hoe het zit met firmware versies?

Wat is nu de laatste versie, en zijn er releasenotes?

Dit geeft mijn 3680HD aan van augustus dit jaar.

Versie DSP2
2.0.405
Versie DSP1
1.0.451
Versie communicatieplaat (CPU)
3.2221.0

[kvandt]

Mijn 2200HD, van begin dit jaar, geeft
DSP1 1.0000.0338
DSP2 2.0000.0205
CPU 3.2016.0000

Nog nooit een update gehad...

[ Voor 14% gewijzigd door kvandt op 05-11-2018 15:50 ]

[MO1234]

Jerrythafast schreef op maandag 5 november 2018 @ 09:50:
[...]

Dat verbaast mij inderdaad ook! Ik denk dat ze hem niet fixen omdat die waarde toch al niet werd gebruikt door de monitoring website. Immers kan die teller als hij wél goed werkt ook nog halverwege de dag terug naar 0 springen wanneer er een donkere bui over trekt. Toen ik met se-logger begon in 2016 was deze bug er ook nog niet, maar was wel al snel duidelijk dat de monitoring website zelf de de_day waardes bij elkaar optelt voor het juiste totaal. De bug is er pas later in geslopen, maar ik vermoed dat niemand dat door heeft gehad omdat het toch een ongebruikt ding is.

Het is niettemin inderdaad wel weird dat dit via RS-485 blijkbaar wel gewoon goed gaat!


@MO1234 ik ben eigenlijk wel benieuwd wat het hoogste AC vermogen is dat je tot nu toe hebt gehaald. Omdat de panelen niet gelijktijdig pieken, zou het mij niks verbazen als je de 3500 Watt nog niet bent gepasseerd.

Ik draai pas sinds 18-10-2018 hoogste vermogen was 3200 Watt. Weet niet of dit in de zomer veel meer zou zijn? Anders zal ik toch versnelt naar 6000wp moeten. Dan zou ik rond de 4700 Watt uitkomen (6000/4500=1,33 +10% efficiënter ). Eerst maar eens afwachten wat SolarEdge heeft te zeggen.

**Update: Net contact gehad met leverancier die navraag heeft gedaan bij SolarEdge. Jullie vermoeden lijkt te kloppen hoewel 15 panelen voldoende is voor P404 komt de ZW kant net 1 paneel te kort . Gelukkig aan die kant nog plaats voor 2 panelen. Systeem zal dan wel efficiënt moeten werken.

[ Voor 10% gewijzigd door MO1234 op 05-11-2018 17:43 ]

[jacovn]

@MO1234 wat zijn je graden dakhoek ?

Ik krijg 16x panelen op plat dak met 13 graden oost/west (oost = noord/oost, west = zuid/west) met p404 units.
Optioneel nog wel 7 panelen op zuid/west op 60 graden schuin dak. Dan zal het wel beter werken omdat het dan 23 panelen zijn. Dan kan het met p500 units.

[stormfly]

MO1234 schreef op maandag 5 november 2018 @ 16:37:
[...]

Ik draai pas sinds 18-10-2018 hoogste vermogen was 3200 Watt. Weet niet of dit in de zomer veel meer zou zijn? Anders zal ik toch versnelt naar 6000wp moeten. Dan zou ik rond de 4700 Watt uitkomen (6000/4500=1,33 +10% efficiënter ). Eerst maar eens afwachten wat SolarEdge heeft te zeggen.

**Update: Net contact gehad met leverancier die navraag heeft gedaan bij SolarEdge. Jullie vermoeden lijkt te kloppen hoewel 15 panelen voldoende is voor P404 komt de ZW kant net 1 paneel te kort . Gelukkig aan die kant nog plaats voor 2 panelen. Systeem zal dan wel efficiënt moeten werken.

- 4.5 kWp
-Omvormer SE5K
-ZO/ZW 7/8
-15x P404 optimizers.

Je hebt dan 1 paneel extra nodig aan de ZW zijde volgens SE. Juist de zijde waar je al het hoge aantal panelen hebt liggen. Daar zal de theorie van toepassing zijn dat je aan die zijde zoveel mogelijk opwekt qua stroom (power)? Dat geeft aan één zijde 300x 9 = 2700 WP. Als je de grafieken van Jerry bekijkt stijg je dan van 97,5% naar 97,6%...https://www.solaredge.com/sites/default/files/application_note_solaredge_inverters_efficiency.pdf Je hebt ook de oostzijde er nog bij, maar die laat ik voor het gemak even buiten beschouwing. Stel dat je daar 1000watt extra voor zou rekenen kom je op 97,8% uit oid.

Ik wil je niet ontmoedigen, ik wil het gewoon snappen. Maar dat is nog niet de stap welke jij zoekt, toch? Jij wilt van 88% op 97% komen

Zelf ben ik benieuwd of iemand anders een andere mening heeft of dat ene paneel het verschil gaat maken?

[ocaj]

Jerrythafast schreef op maandag 5 november 2018 @ 09:50:
Toen ik met se-logger begon in 2016 was deze bug er ook nog niet, maar was wel al snel duidelijk dat de monitoring website zelf de de_day waardes bij elkaar optelt voor het juiste totaal. De bug is er pas later in geslopen, maar ik vermoed dat niemand dat door heeft gehad omdat het toch een ongebruikt ding is.

Het is niettemin inderdaad wel weird dat dit via RS-485 blijkbaar wel gewoon goed gaat!

O, maar dan zit het misschien anders. Mijn omvormers zijn ook uit 2016, maar hangen niet aan Internet en hebben dus nooit een firmware-update gehad.
Mogelijk is het dus geen RS485/HTTP-verschil, maar simpelweg iets dat in nieuwere firmware fout is gegaan.

Wellicht gaat het met de nieuwe firmware dan ook met RS485 fout?

(en ik weet gelijk weer waarom ik mijn omvormers niet aan internet heb hangen, zodat dingen "ineens" semi-spontaan stuk kunnen gaan door een firmware-update...)

[Jerrythafast]

ocaj schreef op maandag 5 november 2018 @ 19:35:
[...]


O, maar dan zit het misschien anders. Mijn omvormers zijn ook uit 2016, maar hangen niet aan Internet en hebben dus nooit een firmware-update gehad.
Mogelijk is het dus geen RS485/HTTP-verschil, maar simpelweg iets dat in nieuwere firmware fout is gegaan.

Wellicht gaat het met de nieuwe firmware dan ook met RS485 fout?

(en ik weet gelijk weer waarom ik mijn omvormers niet aan internet heb hangen, zodat dingen "ineens" semi-spontaan stuk kunnen gaan door een firmware-update...)

Hahaha goed punt! Dat zal inderdaad de verklaring zijn. Ik neem eigenlijk wel aan dat het via RS-485 ook niet klopt met de huidige firmware.

Overigens lijkt het erop dat die dingen zelden pro-actief geupdatet worden, daarvoor moet echt iemand op het knopje drukken zo lijkt het.

[MO1234]

stormfly schreef op maandag 5 november 2018 @ 19:11:
[...]


Je hebt dan 1 paneel extra nodig aan de ZW zijde volgens SE. Juist de zijde waar je al het hoge aantal panelen hebt liggen. Daar zal de theorie van toepassing zijn dat je aan die zijde zoveel mogelijk opwekt qua stroom (power)? Dat geeft aan één zijde 300x 9 = 2700 WP. Als je de grafieken van Jerry bekijkt stijg je dan van 97,5% naar 97,6%...https://www.solaredge.com/sites/default/files/application_note_solaredge_inverters_efficiency.pdf Je hebt ook de oostzijde er nog bij, maar die laat ik voor het gemak even buiten beschouwing. Stel dat je daar 1000watt extra voor zou rekenen kom je op 97,8% uit oid.

Ik wil je niet ontmoedigen, ik wil het gewoon snappen. Maar dat is nog niet de stap welke jij zoekt, toch? Jij wilt van 88% op 97% komen

Zelf ben ik benieuwd of iemand anders een andere mening heeft of dat ene paneel het verschil gaat maken?

Vandaag had het systeem een goede dag 93%

Mijn excuses je hebt gelijk dit is nu ZO/ZW 8/7. In theorie zou 8/8 dan "goed" moeten werken. Echter met de leverancier overgehad om dan voor 9/9 te gaan (dit ligt ook mooier op het dak). Was niet van plan om al zo vroeg uit te bereiden maar vind het toch zonden om X% per dag te laten verdampen....

Volgens mij ligt het probleem ook voor een groot gedeelte in stabiliteit van voltage. Zoals te zien is het systeem continu aan het regelen.
Dit is ook deels terug te zien in de DC van omvormer. Zelfs bij een sample tijd van 10min.

Met meer panelen zou dit beter moeten worden.

[Aegle]

Jerrythafast schreef op maandag 5 november 2018 @ 19:46:
[...]

Hahaha goed punt! Dat zal inderdaad de verklaring zijn. Ik neem eigenlijk wel aan dat het via RS-485 ook niet klopt met de huidige firmware.

Overigens lijkt het erop dat die dingen zelden pro-actief geupdatet worden, daarvoor moet echt iemand op het knopje drukken zo lijkt het.

Mijn SE3000 is van begin 2014 en in juni van dat jaar in bedrijf gesteld. Tevens is ie toen aan het grote boze internet gekoppeld... Maar van firmware updates heeft ie nog nooit gehoord... .

[stormfly]

Jerrythafast schreef op maandag 5 november 2018 @ 19:46:
[...]
Overigens lijkt het erop dat die dingen zelden pro-actief geupdatet worden, daarvoor moet echt iemand op het knopje drukken zo lijkt het.

Firmwareupdates, volgens mij moet de installateur dat doen maar die is liever bezig met nieuwe klanten aansluiten en wil vast en zeker geen geneuzel " if it aint broke dont fix it " Volgens mij kan de SE support ook firmwareupdates klaarzetten op verzoek.

Nog met SE support gemaild ze hebben de paneel nummering aangepast, dat kan inderdaad gewoon met de hand.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 3% gewijzigd door stormfly op 06-11-2018 07:52 ]

[stormfly]

MO1234 schreef op maandag 5 november 2018 @ 21:49:
[...]


Vandaag had het systeem een goede dag 93%

Mijn excuses je hebt gelijk dit is nu ZO/ZW 8/7. In theorie zou 8/8 dan "goed" moeten werken. Echter met de leverancier overgehad om dan voor 9/9 te gaan (dit ligt ook mooier op het dak). Was niet van plan om al zo vroeg uit te bereiden maar vind het toch zonden om X% per dag te laten verdampen....

Volgens mij ligt het probleem ook voor een groot gedeelte in stabiliteit van voltage. Zoals te zien is het systeem continu aan het regelen. [Afbeelding]
Dit is ook deels terug te zien in de DC van omvormer. Zelfs bij een sample tijd van 10min.

Met meer panelen zou dit beter moeten worden.

Dit is per optimizer gemeten, en je hebt een O-W opstelling. Waarbij je mag aannemen dat de zon over de twee rijen er "overheen" draait waardoor je de X krijgt te zien. Die andere dag lijkt een niet zonnige dag te zijn?

Wat nog interessanter kan zijn is de DC spanning, ik heb een 3680HD met 8 P404's op 96cell 56volt panelen. Er liggen er 4 in oost west (2x2) en 4 pal op zuid west, zie hieronder mijn DC spanning. Dat is een blok vorm hoe is deze bij jou?

[ocaj]

@MO1234 Waar je vooral aan kan zien dat het systeem niet optimaal werkt is aan de "platte" stukjes in je DC-grafiek per optimizer. Je hebt 's ochtends en 's avonds een aantal optimizers die de maximale 85 Volt produceren. Hier kun je aan zien dat het systeem tegen de grens van zijn regelruimte aanloopt. De optimizers in de zon produceren dan minder dan ze zouden kunnen. Je kan dat ook zien ook aan de paneel-spanning (heb je daar ook een plaatje van?), die wordt dan hoger dan de Vmpp waar hij idealiter op draait.)

Dit is het typische gedrag van solaredge met weinig panelen per richting. Hoe meer panelen/optimizers je hebt in je string, hoe langer het duurt voor je hier tegenaan loopt. In jouw geval heb je al de P404-optimizers, dat is goed, maar betekent ook dat je voor een 3-fase omvormer eigenlijk iets meer panelen nodig hebt.

Overigens is het nou ook weer niet zo heel erg als dit even een half uurtje/uurtje aan het begin/eind van de dag is, maar in jouw plaatje lijkt het echte urenlang te zijn (kan het niet heel goed zien hoe lang precies?). Dat is niet optimaal.

[rvdven]

Jerrythafast schreef op zondag 28 oktober 2018 @ 11:48:
[...]
That said, misschien is het inderdaad wel handig als ik een officiële Git repo voor se-logger maak waar anderen features als setuptools en mqtt aan kunnen toevoegen. Ik zou er dan een GPLv3 license aan hangen (maar het nog steeds niet waarderen als het dan alsnog op PyPI wordt gezet )

Laat maar weten mocht het zover komen, dan heb ik gelijk een PR voor je

Net de omvormer aangesloten, maar er kwam maar niets in de database. Bleek dat het adres van mijn omvormer anders is dan de twee opties in liveupdate.py: 00:04:f3 Waarschijnlijk heb ik een nieuwe serie WiFi-modules?

Hoe dan ook, dit fixt het:

Python: liveupdate.py

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

Dank voor de code @Jerrythafast!

[Jerrythafast]

rvdven schreef op dinsdag 6 november 2018 @ 14:21:
[...]


Laat maar weten mocht het zover komen, dan heb ik gelijk een PR voor je

Net de omvormer aangesloten, maar er kwam maar niets in de database. Bleek dat het adres van mijn omvormer anders is dan de twee opties in liveupdate.py: 00:04:f3 Waarschijnlijk heb ik een nieuwe serie WiFi-modules?

Hoe dan ook, dit fixt het:

Python: liveupdate.py

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

Dank voor de code @Jerrythafast!

Ik zal het laten weten, zal proberen er binnenkort even wat tijd voor vrij te maken. Alvast bedankt, ik neem je MAC adres update alvast mee

[stormfly]

Iemand al ervaring met de scripts op ubuntu 18 LTS? Als je upgrade vanaf 16 naar 18, blijft het dan werken of heb je avonden werk aan herstel?

[Wiley99]

<knip> ging over Youless en niet SE

[ Voor 92% gewijzigd door Wiley99 op 08-11-2018 17:05 ]

[Jerrythafast]

stormfly schreef op woensdag 7 november 2018 @ 08:11:
Iemand al ervaring met de scripts op ubuntu 18 LTS? Als je upgrade vanaf 16 naar 18, blijft het dan werken of heb je avonden werk aan herstel?

se-logger zal wel blijven werken, maar ik heb mijn Raspberry Pi 2B nog niet durven upgraden naar 18.04 LTS. De upgrade van 14.04 LTS naar 16.04 LTS was een ware nachtmerrie (vrij letterlijk) door de introductie van systemd. Van 16.04 LTS naar 18.04 LTS verwacht ik zelf minder problemen, maar ik heb de sprong nog niet genomen. Laat me weten hoe het is gegaan

[stormfly]

Jerrythafast schreef op donderdag 8 november 2018 @ 19:29:
[...]

se-logger zal wel blijven werken, maar ik heb mijn Raspberry Pi 2B nog niet durven upgraden naar 18.04 LTS. De upgrade van 14.04 LTS naar 16.04 LTS was een ware nachtmerrie (vrij letterlijk) door de introductie van systemd. Van 16.04 LTS naar 18.04 LTS verwacht ik zelf minder problemen, maar ik heb de sprong nog niet genomen. Laat me weten hoe het is gegaan

Ik bedacht vandaag, als ik in VMware een snapshot maak ben ik in 15 seconden weer terug bij het oude. Denk dat ik het maar gewoon moet durven

[basvn]

Ik heb een vraagje,

Ik heb nu 3 weken 10 panelen op mijn dak liggen, met SE eronder.

Het was afgelopen 2 dagen echt prachtig weer, en ik had toen 2.37kw en 2.08kw
vandaag is het een stuk meer bewolking, maar ik haal gewoon meer binnen!

nu tot 14.35 al 1.92kw, en momenteel 400w

hoe kan het dat ik met bewolking meer binnen haal als een heldere dag?

[BlueTooth76]

basvn schreef op maandag 19 november 2018 @ 14:35:
Ik heb een vraagje,

Ik heb nu 3 weken 10 panelen op mijn dak liggen, met SE eronder.

Het was afgelopen 2 dagen echt prachtig weer, en ik had toen 2.37kw en 2.08kw
vandaag is het een stuk meer bewolking, maar ik haal gewoon meer binnen!

nu tot 14.35 al 1.92kw, en momenteel 400w

hoe kan het dat ik met bewolking meer binnen haal als een heldere dag?

Wat is de dakhoek?

[basvn]

BlueTooth76 schreef op maandag 19 november 2018 @ 14:38:
[...]


Wat is de dakhoek?

zo'n 25°

[Wiley99]

Zou kunnen dat de bewolking meer reflecteert (dan blauwe lucht) en je vlakkere hoek dan net wat meer energie opvangt. Maar hou er ook rekening mee dat het snel naar beneden gaat vanaf 14:30u, ik trek dan deze dagen nog maar zo'n 1 kWh binnen in de resterende tijd (3240 Wp op zuid)

[Wiley99]

stormfly schreef op donderdag 8 november 2018 @ 19:42:
[...]


Ik bedacht vandaag, als ik in VMware een snapshot maak ben ik in 15 seconden weer terug bij het oude. Denk dat ik het maar gewoon moet durven

Gelukt?

[Aegle]

basvn schreef op maandag 19 november 2018 @ 14:47:
[...]


zo'n 25°

Dat verklaart veel. Mijn dakhoek is ca 45° en doet het in het voor- en najaar relatief beter dan in de zomer.

Aan het eind van een zomerse dag als de zon vrij westelijk staat, heb ik geen direct zonlicht meer op de panelen. Als het dan onbewolkt is heb ik veel minder opbrengst dan bij bewolking. dat komt door de reflectie van de zon tegen de wolken.

Maar misschien dat je dit soort algemene vragen beter in het Electriciteit opwekken met zonnepanelen (PV) deel 7 -topic kan stellen...?

[MikeyMan]

stormfly schreef op dinsdag 6 november 2018 @ 07:52:
[...]


Firmwareupdates, volgens mij moet de installateur dat doen maar die is liever bezig met nieuwe klanten aansluiten en wil vast en zeker geen geneuzel " if it aint broke dont fix it " Volgens mij kan de SE support ook firmwareupdates klaarzetten op verzoek.

Nog met SE support gemaild ze hebben de paneel nummering aangepast, dat kan inderdaad gewoon met de hand.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Dat irriteert mij ook mateloos. Zelfs de API aan zetten was al teveel werk voor de installateur.
Vertrouw mijn installatie ook niet helemaal, opbrengst van sommige panelen valt tegen.

[basvn]

Aegle schreef op maandag 19 november 2018 @ 15:33:
[...]

Dat verklaart veel. Mijn dakhoek is ca 45° en doet het in het voor- en najaar relatief beter dan in de zomer.

Aan het eind van een zomerse dag als de zon vrij westelijk staat, heb ik geen direct zonlicht meer op de panelen. Als het dan onbewolkt is heb ik veel minder opbrengst dan bij bewolking. dat komt door de reflectie van de zon tegen de wolken.

Maar misschien dat je dit soort algemene vragen beter in het Electriciteit opwekken met zonnepanelen (PV) deel 7 -topic kan stellen...?

Naja als het klopt prima! vond het alleen zo raar

En dacht dat het een gerelateerd iets was met solar egde.. vandaar dat ik het hier vroeg

[stormfly]

Wiley99 schreef op maandag 19 november 2018 @ 15:16:
[...]


Gelukt?

Jeps alleen php verliest relatie met apache. Vandaag na een normale apt upgrade moest ik e.a handmatig starten 😕 even in de gaten houden

[Japie.G]

Heb ook een klein SolarEdge PV systeem. Recent geinstalleerd en bewust niet aan het internet gekoppeld. Ben behoorlijk linux noob of zeg maar gerust geen linux kennis. En aangezien de startpost geen copy past regeltjes zijn zal de installatie lastig voor mij worden.

Wat krijg ik met deze methode meer te zien dan dat ik alleen het SE portal zou gebruiken? Ik ken het portal ook niet dus dat is me niet geheel duidelijk. Het gaat om de info per paneel?

Ik ga zometeen maar eens aan de slag met een pi3 om een logger te bouwen.. ben benieuwd waar ik ga stranden😜😜

edit:

en bij het starten van de DHCP server stopt he

code:

● isc-dhcp-server.service - LSB: DHCP server
   Loaded: loaded (/etc/init.d/isc-dhcp-server; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2018-11-25 15:01:00 GMT; 3min 46s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1088 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
   CGroup: /system.slice/isc-dhcp-server.service
           └─566 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf

Nov 25 15:01:00 raspberrypi systemd[1]: Starting LSB: DHCP server...
Nov 25 15:01:00 raspberrypi isc-dhcp-server[1088]: Launching both IPv4 and IPv6 servers (please configure INTERFACES in /etc/default/isc-dhcp-server if you only want one or the other).
Nov 25 15:01:00 raspberrypi isc-dhcp-server[1088]: Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid currenty exists) ... failed!
Nov 25 15:01:00 raspberrypi systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Nov 25 15:01:00 raspberrypi systemd[1]: Failed to start LSB: DHCP server.
Nov 25 15:01:00 raspberrypi systemd[1]: isc-dhcp-server.service: Unit entered failed state.
Nov 25 15:01:00 raspberrypi systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.

iemand een idee?

edit2

gelukt inmiddels :-)

[ Voor 56% gewijzigd door Japie.G op 25-11-2018 18:05 ]

[Japie.G]

Dat allemaal opgelost. Service en DB draaien. Echter in pvoutput.log blijf ik problemen houden. Rechten probleem? Iemand?

code:

PHP Fatal error:  Uncaught PDOException: SQLSTATE[HY000] [1698] Access denied for user 'Pi'@'localhost' in /opt/se-logger/pvo-upload.php:15
Stack trace:
#0 /opt/se-logger/pvo-upload.php(15): PDO->__construct('mysql:host=loca...', 'Pi', 'raspberry', Array)
#1 {main}
  thrown in /opt/se-logger/pvo-upload.php on line 15

ik zag dit probleem eerder voorkomen in dit topic echter de oplossing staat er niet...

[ Voor 8% gewijzigd door Japie.G op 25-11-2018 21:26 ]

[Aegle]

Het lijkt alsof je de database niet kan benaderen. Iets met credentials bij PVoutput?
Met een aan zekerheid grenzende waarschijnlijkheid kan @Jerrythafast er wel een verklaring voor geven... .

[Japie.G]

als ik het script nu los draai krijg ik dit

code:

se-logger $ php pvo-upload.php
PHP Fatal error:  Uncaught PDOException: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' in /opt/se-logger/pvo-upload.php:15
Stack trace:
#0 /opt/se-logger/pvo-upload.php(15): PDO->__construct('mysql:host=loca...', 'root', '', Array)
#1 {main}
  thrown in /opt/se-logger/pvo-upload.php on line 15

[tsjoender]

Japie.G schreef op maandag 26 november 2018 @ 11:55:
als ik het script nu los draai krijg ik dit

code:

se-logger $ php pvo-upload.php
PHP Fatal error:  Uncaught PDOException: SQLSTATE\[HY000] [1698] Access denied for user 'root'@'localhost' in /opt/se-logger/pvo-upload.php:15
Stack trace:
#0 /opt/se-logger/pvo-upload.php(15): PDO->__construct('mysql:host=loca...', 'root', '', Array)
#1 {main}
  thrown in /opt/se-logger/pvo-upload.php on line 15

Het lijkt erop dat je het de vorige keer uitvoerde als gebruiker pi en nu als gebruiker root (of als pi, maar dan met sudo ervoor). In het pvo-output.php script kun je in de eerste regels de details opgeven van jouw MySQL database waar de logging gegevens opgeslagen zijn. Ik vermoed dat in ieder geval de username nu leeg is en dan wordt de MySQL client gestart met de op dat moment actieve gebruiker.

Loop de instellingen in dat script maar eens langs zodat je succesvol in kan loggen op de database.

[Japie.G]

Bednkat voor je antwoord! ik heb root als gebruiker staan en leeg als passsword. net zoals in het logging script. maar helaas werkt het bij het logging script wel, maar bij het php script niet.

als ik de boel gewoon bekijk krijg ik acces denied voor Pi, en als ik met php het script uitvoer krijg ik Access denied voor Root

[ Voor 32% gewijzigd door Japie.G op 26-11-2018 13:18 ]

[_-= Erikje =-_]

is het niet veel makkelijker om de IP config op de omvormer statisch te doen en gewoon het IP van je raspberry als default GW op te geven? IP forwarding in linux zorgt er dan wel voor dat het naar het internet gaat en je kan sniffen wat je wilt met maar 1 kabel...

[rjhilbrink]

MikeyMan schreef op maandag 19 november 2018 @ 15:38:
[...]


Dat irriteert mij ook mateloos. Zelfs de API aan zetten was al teveel werk voor de installateur.
Vertrouw mijn installatie ook niet helemaal, opbrengst van sommige panelen valt tegen.

Ik snap ook niet dat je niet gewoon zelf de SolarEdge aanmeld? Ik betaal ervoor dus hang ik hem zelf wel aan internet/portal. Als ik het formuliertje maar krijg met alle serienummers van de Optimizers. Helemaal makkelijk als e.e.a. van te voren wordt geleverd, snel zelf een account aanmaken en de SolarEdge registreren.

[MikeyMan]

rjhilbrink schreef op donderdag 29 november 2018 @ 11:20:
[...]

Ik snap ook niet dat je niet gewoon zelf de SolarEdge aanmeld? Ik betaal ervoor dus hang ik hem zelf wel aan internet/portal. Als ik het formuliertje maar krijg met alle serienummers van de Optimizers. Helemaal makkelijk als e.e.a. van te voren wordt geleverd, snel zelf een account aanmaken en de SolarEdge registreren.

Kan dat dan? De serie nummers zijn bij mij gewoon toegankelijk,dus kan er zo bij...

[rjhilbrink]

MikeyMan schreef op donderdag 29 november 2018 @ 11:48:
[...]


Kan dat dan? De serie nummers zijn bij mij gewoon toegankelijk,dus kan er zo bij...

Je kan jezelf toch als installateur registreren bij SolarEdge? Collega heeft zelf de installatie gedaan en dus ook zelf de registratie gedaan.

[MikeyMan]

rjhilbrink schreef op donderdag 29 november 2018 @ 12:38:
[...]

Je kan jezelf toch als installateur registreren bij SolarEdge? Collega heeft zelf de installatie gedaan en dus ook zelf de registratie gedaan.

Dat is waar, Zou ik mezelf nu alsnog kunnen aanmelden om de installatie te kapen?

[Jerrythafast]

@MikeyMan als je installatie al is geregistreerd gaat dat niet zo makkelijk, je moet dan jouw installateur én SolarEdge support overtuigen het naar jou persoonlijk over te laten zetten.

[Bramster]

Ze zijn nu druk bezig met het installeren van mijn zonnepanelen, yey!
Gelukkig wel op tijd dit topic gevonden en de eerste data is al van de omvormer afgeluisterd en het uploaden naar PVOutput lijkt ook te werken, bedankt @Jerrythafast!

alleen het herstarten van de se-logger-service lijkt niet helemaal goed te werken, ik krijg wel een nieuwe output file maar de oude blijft ook gevuld worden met (neem ik aan) dezelfde data.

[Jerrythafast]

Bramster schreef op woensdag 5 december 2018 @ 12:18:
Ze zijn nu druk bezig met het installeren van mijn zonnepanelen, yey!
Gelukkig wel op tijd dit topic gevonden en de eerste data is al van de omvormer afgeluisterd en het uploaden naar PVOutput lijkt ook te werken, bedankt @Jerrythafast!

alleen het herstarten van de se-logger-service lijkt niet helemaal goed te werken, ik krijg wel een nieuwe output file maar de oude blijft ook gevuld worden met (neem ik aan) dezelfde data.

Gefeliciteerd! Ik heb het volgende even toegevoegd aan de veelgestelde vragen aan het begin van dit topic. Je bent niet de eerste die hier tegenaan is gelopen. Laat maar even weten of dit helpt

Het stoppen/herstarten van se-logger gaat niet goed; het oude .pcap bestand blijft groeien
In het bestand '/etc/systemd/system/se-logger.service' kun je proberen de 'KillMode=' regel aan te passen naar 'KillMode=control-group'. Dit is in ieder geval nodig op Raspbian; als je een ander OS draait op jouw logger kan het misschien ook helpen. In dat geval wordt het gewaardeerd als je even een bericht in dit topic plaatst met welk OS je draait en of het probleem hiermee is opgelost of niet

[Wiley99]

Het is nog steeds zo dat, als je er niet op tijd bij was, je nooit meer direct aan die SE logging komt, nietwaar?

[Bramster]

Heb het aangepast, lijkt nu wel goed gerestart te worden, thx! (op basis van wat zie in de output van "ps -aux")

ik draai trouwens Armbian op een Orange Pi Zero.

maar het werkt echt super! had het al een paar dagen draaien en toen net de omvormer voor het eerst aan ging zag ik gelijk data verschijnen in de telemetry_inverter tabel, nadat de optimizers zijn gekoppeld gelijk data in de optimizer tabel en op PVOutput. Nu wachten op de key

alleen viel me nog op dat de temperatuur die geupload wordt naar PVOutput de omvormer temperatuur is maar het lijkt op de PVOutput site meer bedoeld als de omgevingstemperatuur?

[Jerrythafast]

Wiley99 schreef op woensdag 5 december 2018 @ 15:24:
Het is nog steeds zo dat, als je er niet op tijd bij was, je nooit meer direct aan die SE logging komt, nietwaar?

Zeg nooit nooit Het wordt wel een stuk bewerkelijker, de eenvoudigste manier wordt dan een factory reset, of je moet met draadjes in de weer om een seriële verbinding op te zetten.

Bramster schreef op woensdag 5 december 2018 @ 15:33:
Heb het aangepast, lijkt nu wel goed gerestart te worden, thx! (op basis van wat zie in de output van "ps -aux")

ik draai trouwens Armbian op een Orange Pi Zero.

maar het werkt echt super! had het al een paar dagen draaien en toen net de omvormer voor het eerst aan ging zag ik gelijk data verschijnen in de telemetry_inverter tabel, nadat de optimizers zijn gekoppeld gelijk data in de optimizer tabel en op PVOutput. Nu wachten op de key

alleen viel me nog op dat de temperatuur die geupload wordt naar PVOutput de omvormer temperatuur is maar het lijkt op de PVOutput site meer bedoeld als de omgevingstemperatuur?

Mooi! Temperatuur is inderdaad van de omvormer. Next best thing dat ik kan bedenken is een gemiddelde van de temperatuur van de optimizers te pakken, maar dat wordt een stukje moeilijker omdat die best wel onregelmatig zijn met het doorgeven van data. En die temperatuur klopt vaak in de middag ook niet helemaal doordat alles lekker op ligt te warmen. Als je zelf een thermometer hebt die je kunt uitlezen zou je voor jezelf het pvo-upload script kunnen aanpassen zodat hij die data gebruikt

[Japie.G]

Ik heb de key ook achterhaald nu. Even voor mijn idee, die verandert nooit meer toch? Heb de boel nog steeds niet werkend met pvoutput enzo dus wil een keer opnieuw beginnen...

[Bramster]

Hier is de key net voorbij gekomen, net buiten de 48 uur na eerste powerup.

[Jerrythafast]

@Japie.G key verandert in principe nooit, nee. (Als is dat technisch wel mogelijk, maar dan zou je een eventuele nieuwe key ook weer voorbij moeten zien komen in de data.)

[Tomba]

@Jerrythafast inmiddels is de SolarEdge geplaatst maar ik loop met se-logger tegen een vaag probleem aan. Na de restart van de se-logger service lijkt tcpdump niet meer te werken (bestand blijft 24 bytes) Bij een reboot van de hele RasPi gaat alles wel goed. Kan ik controleren of ik de key toevallig al gemist heb nu?

[...]
-rw-r--r-- 1 root root 45257 Dec 17 17:19 solaredge-20181217135718.pcap
-rw-r--r-- 1 root root 24 Dec 18 00:30 solaredge-20181217233002.pcap
-rw-r--r-- 1 root root 8542 Dec 18 07:30 solaredge-20181218062713.pcap
[...]

(RasPi is gisteren om 1719 en vanochtend om 7:30 herstart)

[MDKlapwijk]

@Tomba , is de logger om 06:27 niet gewoon verder gegaan in solaredge-20181218062713.pcap?

[Tomba]

MDKlapwijk schreef op dinsdag 18 december 2018 @ 10:36:
@Tomba , is de logger om 06:27 niet gewoon verder gegaan in solaredge-20181218062713.pcap?

Dat bestand werd pas aangemaakt na een reboot van de Pi, tot dat moment helemaal niks dus...

[MDKlapwijk]

@Tomba, echter is solaredge-20181218062713.pcap wel al 8k groot, dus er wordt wel in geschreven. Je zou eens een cat kunnen doen op het bestand:

code:

cat solaredge-20181218062713.pcap

Of het bestand downloaden en in wireshark inlezen.

Edit: Hmmm, lezen is ook een vak; Als ie bij een reboot wel netjes start, dan blijft bij een restart of een process draaien, of hij start niet alles (of je hebt niet voldoende rechten).

Je zou iets als het volgende kunnen gebruiken om te testen:

code:

ps aux| grep -P "USER|se-logger|tcpdump"

Dit zou je de PID van de processen moeten geven. Dus als je dit na een reboot doet, se-logger herstart en dan nog eens, dan kan je de PIDs vergelijken en zien welk proces niet herstart is of ontbreekt.

[ Voor 50% gewijzigd door MDKlapwijk op 18-12-2018 11:05 ]

[Tomba]

MDKlapwijk schreef op dinsdag 18 december 2018 @ 10:58:
@Tomba, echter is solaredge-20181218062713.pcap wel al 8k groot, dus er wordt wel in geschreven. Je zou eens een cat kunnen doen op het bestand:

code:

cat solaredge-20181218062713.pcap

Of het bestand downloaden en in wireshark inlezen.

Ik snap even niet waar je naar toe wil vrees ik.
Issue is dus dat na se-logger service restart er iets mis gaat waardoor er geen tcpdump plaats vindt. De file die je me vraagt te bekijken wordt pas aangemaakt na een volledige reboot van de Pi (waarna alles goed lijkt te werken)

[MDKlapwijk]

Sorry, zie edit....

[Tomba]

MDKlapwijk schreef op dinsdag 18 december 2018 @ 11:05:
Sorry, zie edit....

Check, dank je! Ik ga er vanavond mee aan de slag!

[Update]
Geen tijd meer gehad om te testen maar de key is er inmiddels

Found it! Your key is '****'

Nu nog een werkende omvormer (de eikels die mijn zonnepanelen zijn komen plaatsen kwamen er pas toen alles lag achter dat een S5K niet met slechts 12 optimizers/panelen werkt....)

[ Voor 45% gewijzigd door Tomba op 20-12-2018 08:24 ]

[MaikelK.]

Goedemiddag,

Ik probeer de sleutel te achterhalen van mij SE3500H.
Helaas heeft deze geen USB en geen RS232 aansluiting, ik zal het dus moeten proberen met de RS485 aansluiting.

Iemand hier al succes mee gehad?
Deze output krijg ik als ik het RS232 script probeer:
\x23\x5d\x01\x4c\x91\x7c\x46\x73\x42\xc5\xfc\x12\x97\xaf\xxx\xxx

Iemand enig idee of dit ergens op slaat of dit evt. om te zetten is? De laatste twee heb ik even aangepast zodat niet direct de hele sleutel op straat ligt.

[stormfly]

MaikelK. schreef op vrijdag 28 december 2018 @ 16:03:

\x23\x5d\x01\x4c\x91\x7c\x46\x73\x42\xc5\xfc\x12\x97\xaf\xxx\xxx

Iemand enig idee of dit ergens op slaat of dit evt. om te zetten is? De laatste twee heb ik even aangepast zodat niet direct de hele sleutel op straat ligt.

Jeps dat is hem, prima in orde

[ Voor 26% gewijzigd door stormfly op 28-12-2018 20:40 ]

[MaikelK.]

Ik probeer nu de oude PCAP bestanden in te lezen, en krijg nu heel veel van de volgende meldingen.

Setting new 0503 key
/opt/se-logger/liveupdate.py:375: Warning: Duplicate entry '1539714897-1930878291' for key 'PRIMARY'
self.cursor.execute(*args)
End of file. Shutting down.

[MDKlapwijk]

@MaikelK., dat is omdat dat record al in de database staat. (Weet even niet hoe de primary is samengesteld, maar ik vermoed optimizer-id of paneel-id samen met de timestamp)

[Jerrythafast]

@MaikelK.: Wat @MDKlapwijk zegt klopt, de duplicate entry meldingen krijg je omdat hij data in de database probeert te stoppen die er al in staat. Niets aan de hand dus, het ziet er goed uit!

De key bestaat inderdaad uit timestamp + serienummer van de optimizer/omvormer.

[MaikelK.]

Oke, bedankt voor de info, is het raar als hij deze ook nog geeft vanuit bestanden die een maand nieuwer zijn bijvoorbeeld?

[Jerrythafast]

Als daar nog niet-versleutelde informatie in stond kan dat. En als je hem nu nog eens alles laat doorspitten zul je natuurlijk voor alles die melding krijgen, omdat alle data nu al in de database staat.

[MaikelK.]

@Jerrythafast ik heb nu alles verwerkt, de bestanden die te groot waren, ik kreeg meerdere malen MemoryError en iets met Python number to long ofzo, weggegooid.

Echter gemiddeld zijn de PCAP bestanden 36MB. Enig idee of ik die met Wireshark kan omzetten naar alleen maar de data van de omvormer?

Ik zou je ook willen aanraden om een MAC filter optie toe te voegen aan de begin post. Mijn bestand van vandaag is nog maar onder de 200 kB, dat scheelt behoorlijk!

Verder @Jerrythafast en @andrerij bedankt voor de effort! Alle andere die mij tot nu toe geholpen hebben uiteraard ook bedankt!

[ocaj]

@MaikelK. Je kunt in Wireshark een MAC-filter toepassen en vervolgens de gefilterde pakketten weer opslaan.

Als het er veel zijn, dan kun je volgens mij dat ook gescript via tcpdump doen, laten lezen uit een file, filteren en weer schrijven naar een andere file.

[Jerrythafast]

Kun je tcpdump laten filteren op (evt meerdere) halve MAC-adressen? Dan kan ik de bekende SolarEdge prefixes er wel in stoppen

[ocaj]

Filteren op 1 of enkele MAC-adressen is in tcpdump vrij triviaal (middels de "ether host <MAC>"-parameter). Hoe je een range of prefix kunt filteren kan vast ook wel, maar zie ik niet zo 1-2-3 .

Je kunt overwegen om het MAC-adres als optionele setting bovenaan in je se-logger-service op te nemen?

Optioneel, zodat het ook werkt zonder opgegeven MAC-adres (je wil het configureren van je script niet ingewikkelder maken dan nodig lijkt me. voor sommigen is het opzoeken van een MAC-adres triviaal, voor anderen is het abracadabra).
Als die optie niet gezet is, dan dump je alles. Is het MAC-adres wel ingevuld dan filter je dat MAC-adres in de capture-files.

[jacovn]

Jerrythafast schreef op dinsdag 1 januari 2019 @ 19:41:
Kun je tcpdump laten filteren op (evt meerdere) halve MAC-adressen? Dan kan ik de bekende SolarEdge prefixes er wel in stoppen

Zie hier voor filteren van een deel van de mac adressen (de vendor kant)
https://stackoverflow.com...c-addresses-using-tcpdump

Zou dan iets moeten zijn als:
tcpdump ‘ether[0,6] == 0x002702’

Voor het vendor stuk (als 002702 de enige vendor range is)

Man page: https://www.tcpdump.org/manpages/tcpdump.1.html

[Jerrythafast]

Dat is inderdaad een goed 'plan B' @ocaj! Maar zoals @jacovn aangeeft blijkt het inderdaad mogelijk om een stukje MAC-adres te testen, dus ik denk dat het behulpzaam is om dat de default te maken

Het enige waar ik wel nog rekening mee moet houden is dat er nieuwe MAC-adressen kunnen opdoemen, dus een makkelijke manier om het te configureren (inclusief uitzetten) is alsnog nodig natuurlijk

[jacovn]

@Jerrythafast
SolarEdge lijkt maar 1 vendor ID te gebruiken.
Zie ook: https://udger.com/resourc...me=solaredge_technologies

Device stuk is 24 bit, dus in theory 2^24 minus een paar.(16,777,216 = 2^24)

Geen idee hoe veel inverters ze verkopen en verkocht hebben, maar het houd een keer op met 16 miljoen.

Uit hun investor document: http://investors.solaredg...0b-412d-8b6d-1c2d1c130eff

"Over 750.000 monitored systems worldwide"
en op pagina 6 de trend van het aantal en de verdeling maar 2018 = 100.000 en in 2022 verwachten ze 140.000 te doen.

In dat tempo kunnen ze even vooruit met de huidige 16 miljoen denk ik..

Aan de andere kant is het variabel maken van een filter we handig.
Ik zie in de uitleg staan dat een AND toegepast kan worden. Dan lijkt me een OR operatie ook mogelijk.
Dan zou je daarmee een 2e en 3e vendor blok toe kunnen voegen.

[Jerrythafast]

@jacovn
In dit topic zijn er al 3 prefixes voorbij gekomen, waaronder inderdaad die ene van SolarEdge zelf, maar die gebruiken ze alleen voor de ingebouwde LAN-poort. Als je een WiFi-module hebt hangt daar een MAC-adres van een ander bedrijf aan, en dat blijken dus al minimaal twee verschillende te zijn.

[jacovn]

Jerrythafast schreef op woensdag 2 januari 2019 @ 11:09:
@jacovn
In dit topic zijn er al 3 prefixes voorbij gekomen, waaronder inderdaad die ene van SolarEdge zelf, maar die gebruiken ze alleen voor de ingebouwde LAN-poort. Als je een WiFi-module hebt hangt daar een MAC-adres van een ander bedrijf aan, en dat blijken dus al minimaal twee verschillende te zijn.

Dat is inderdaad de uitdaging dan.
Digi Xbee lijken ze te gebruiken (digiboard, 1 entry: 00409D)

Gewoon die OR operatie maar proberen dan lijkt me.

[MaikelK.]

ocaj schreef op woensdag 2 januari 2019 @ 06:59:
Filteren op 1 of enkele MAC-adressen is in tcpdump vrij triviaal (middels de "ether host <MAC>"-parameter). Hoe je een range of prefix kunt filteren kan vast ook wel, maar zie ik niet zo 1-2-3 .

Je kunt overwegen om het MAC-adres als optionele setting bovenaan in je se-logger-service op te nemen?

Optioneel, zodat het ook werkt zonder opgegeven MAC-adres (je wil het configureren van je script niet ingewikkelder maken dan nodig lijkt me. voor sommigen is het opzoeken van een MAC-adres triviaal, voor anderen is het abracadabra).
Als die optie niet gezet is, dan dump je alles. Is het MAC-adres wel ingevuld dan filter je dat MAC-adres in de capture-files.

@Jerrythafast Je zou de begin post aan kunnen passen met iets als: Je kunt het MAC adres van je omvormer achterhalen, vul deze in in de filter regel waar FILTER="tcp && ether host FF:FF:FF:FF:FF:FF" staat, haal het # weg en zet een # voor FILTER=tcp
Ik heb het volgende toegevoegd in se-loger-service.sh:

#FILTER=tcp
FILTER="tcp && ether host FF:FF:FF:FF:FF:FF"

Volgens mij, ik het het nu nog niet boven gecontroleerd, staat het MAC adres gewoon in het display van de omvormer. Lijkt mij dus vrij gemakkelijk te achterhalen.

[Jerrythafast]

MaikelK. schreef op donderdag 3 januari 2019 @ 20:33:
[...]

Volgens mij, ik het het nu nog niet boven gecontroleerd, staat het MAC adres gewoon in het display van de omvormer. Lijkt mij dus vrij gemakkelijk te achterhalen.

Als ik weer bij mijn ouders ben ga ik daar eens even naar kijken, dat zou wel een mooie vinding zijn!

[MaikelK.]

Heb het even gechecked, op het display van onze SE3500H staat het vermeld op het zelfde scherm waar het IP adres staat.

[jacovn]

Jerrythafast schreef op donderdag 3 januari 2019 @ 20:53:
[...]

Als ik weer bij mijn ouders ben ga ik daar eens even naar kijken, dat zou wel een mooie vinding zijn!

Staat gewoon in de pagina beeldje op unit waar IP address, gateway etc ook staat.
Tenminste bij mijn SE8K die ik ethernet bedraad heb aangesloten.

[ Voor 3% gewijzigd door jacovn op 05-01-2019 08:50 ]

[MDKlapwijk]

Je kan ook een 'ping' naar de unit doen en dan met 'arp' het MAC-address opvragen:

code:

root@domoticz-01:~# ping 192.168.0.45
PING 192.168.0.45 (192.168.0.45) 56(84) bytes of data.
64 bytes from 192.168.0.45: icmp_seq=1 ttl=64 time=0.972 ms
64 bytes from 192.168.0.45: icmp_seq=2 ttl=64 time=0.531 ms
64 bytes from 192.168.0.45: icmp_seq=3 ttl=64 time=0.500 ms
64 bytes from 192.168.0.45: icmp_seq=4 ttl=64 time=0.481 ms
^C
--- 192.168.0.45 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3055ms
rtt min/avg/max/mdev = 0.481/0.621/0.972/0.203 ms

code:

root@domoticz-01:~# arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.0.76             ether   00:17:88:29:ca:55   C                     eth1
192.168.0.45             ether   00:27:02:12:24:78   C                     eth1
192.168.0.77             ether   44:39:c4:5a:d5:7a   C                     eth1

Of als je nmap geinstalleerd hebt:

code:

root@domoticz-01:~# nmap 192.168.0.45

Starting Nmap 6.47 ( http://nmap.org ) at 2019-01-05 11:00 CET
Nmap scan report for 192.168.0.45
Host is up (0.00046s latency).
All 1000 scanned ports on 192.168.0.45 are closed
MAC Address: 00:27:02:12:24:78 (SolarEdge Technologies)

Nmap done: 1 IP address (1 host up) scanned in 101.64 seconds

[ Voor 17% gewijzigd door MDKlapwijk op 05-01-2019 11:03 ]

[Tomba]

Nou, de zonnepanelen werken sinds een uurtje Helaas werkt noch de website noch de PVO-output. Ik heb in pvoutput.php exact dezelfde gegevens staan als in liveupdate.py. In de log zie ik:

PHP Fatal error: Uncaught PDOException: SQLSTATE[HY000] [2002] No route to host in /opt/se-logger/pvo-upload.php:15
Stack trace:
#0 /opt/se-logger/pvo-upload.php(15): PDO->__construct('mysql:host=dian...', 'selogger', 'xxxxxxxxxx...', Array)
#1 {main}
thrown in /opt/se-logger/pvo-upload.php on line 15
PHP Fatal error: Uncaught PDOException: SQLSTATE[HY000] [2002] No route to host in /opt/se-logger/pvo-upload.php:15
Stack trace:
#0 /opt/se-logger/pvo-upload.php(15): PDO->__construct('mysql:host=dian...', 'selogger', 'xxxxxxxxxx...', Array)
#1 {main}
thrown in /opt/se-logger/pvo-upload.php on line 15

De database ziet er voor mij ook heel gek uit:

mysql> select * from live_update
-> ;
+---------------+------------------------------------+----------------+
| pvo_last_live | last_0503 | last_telemetry |
+---------------+------------------------------------+----------------+
| 0 | ©4▒Va▒u▒▒A▒▒▒zԈ$vut▒v▒▒▒Q | 1547026799 |
+---------------+------------------------------------+----------------+
1 row in set (0.00 sec)

De website van @andrerij geeft dit:

@Jerrythafast enig idee wat hier mis gaat/hoe ik dit kan fixen?

[Update]
Nog wat verder zitten koekeloeren, ik ben gewoon een slaapkop, heb dus een 3fase omvormer dus dan moet ik wel de juiste PHP gebruiken natuurlijk....

Helaas werkt het evengoed nog steeds niet

/usr/bin/php /opt/se-logger/pvo-upload-3phase.php
Bad request 400: Date is older than 14 days

Hoe omzeil ik dit issue? Panelen zijn vandaag pas geplaatst, hoe forceer ik dat alleen de data van vandaag wordt geupload?

mysql> select pvo_last_live FROM live_update;
+---------------+
| pvo_last_live |
+---------------+
| 1545124496 |
+---------------+
1 row in set (0.00 sec)

Is een

code:

update live_update set pvo_last_live='1546905600' where last_telemetry='1547042232';

hier de oplossing wellicht? (das ENOCH 8-1-2019 0:00:00)
_{Daarnaast werkt de website van @andrerij overigens evengoed nog steeds niet, maar dat vind ik minder spannend voor nu}

[Update2]
Ja dus:

/usr/bin/php /opt/se-logger/pvo-upload-3phase.php
20190108,03:34,1;20190108,03:39,1;20190108,03:44,1;20190108,03:49,1;20190108,03:54,1;20190108,03:57,1;20190108,03:59,1;20190108,04:04,1;20190108,04:09,1;20190108,04:14,1;20190108,04:19,1;20190108,04:24,1;20190108,04:29,1;20190108,04:34,1;20190108,04:39,1;20190108,04:44,1;20190108,04:49,1;20190108,04:54,1;20190108,04:59,1;20190108,05:04,1;20190108,05:09,1;20190108,05:14,1;20190108,05:19,1;20190108,05:24,1;20190108,05:29,1;20190108,05:34,1;20190108,05:39,1;20190108,05:44,1;20190108,05:49,1;20190108,05:54,1

Hij heeft nu netjes geregistreerd dat ik gisteren 0 kWh heb opgewekt. Komt de data van vandaag morgen pas online?
Dedoiiii, LIMIT = 30 dus ik moet even geduld hebben.

[Update3]
En daar is ie dan Geen slechte opbrengst voor een december januari dag dunkt me
https://pvoutput.org/list.jsp?userid=70665

Blijft de vraag waarom de website van @andrerij niet wil werken, iemand dit al eens gezien/een oplossing?

[Update4]

En we blijven lekker bezig, als je libapache2-mod-php niet installeert ondersteunt apache natuurlijk geen PHP pagina's

@andrerij ziet er echt top uit; heb nog 1 vraag. Hoe achterhaal ik het id van de optimizer?
De waardes die ik uit:

select distinct op_id from telemetry_optimizers;

krijg geven in ieder geval geen resultaat.

[ Voor 59% gewijzigd door Tomba op 10-01-2019 05:37 ]

[Rouske]

@Tomba December dag?

[stormfly]

Tomba schreef op woensdag 9 januari 2019 @ 10:46:
Nou, de zonnepanelen werken sinds een uurtje Helaas werkt noch de website noch de PVO-output. Ik heb in pvoutput.php exact dezelfde gegevens staan als in liveupdate.py. In de log zie ik:


[...]


De database ziet er voor mij ook heel gek uit:

[...]


De website van @andrerij geeft dit:
[Afbeelding]
@Jerrythafast enig idee wat hier mis gaat/hoe ik dit kan fixen?

[Update]
Nog wat verder zitten koekeloeren, ik ben gewoon een slaapkop, heb dus een 3fase omvormer dus dan moet ik wel de juiste PHP gebruiken natuurlijk....

Helaas werkt het evengoed nog steeds niet


[...]

Hoe omzeil ik dit issue? Panelen zijn vandaag pas geplaatst, hoe forceer ik dat alleen de data van vandaag wordt geupload?


[...]


Is een

code:

update live_update set pvo_last_live='1546905600' where last_telemetry='1547042232';

hier de oplossing wellicht? (das ENOCH 8-1-2019 0:00:00)
_{Daarnaast werkt de website van @andrerij overigens evengoed nog steeds niet, maar dat vind ik minder spannend voor nu}

[Update2]
Ja dus:


[...]

Hij heeft nu netjes geregistreerd dat ik gisteren 0 kWh heb opgewekt. Komt de data van vandaag morgen pas online?
Dedoiiii, LIMIT = 30 dus ik moet even geduld hebben.

[Update3]
En daar is ie dan Geen slechte opbrengst voor een december januari dag dunkt me
https://pvoutput.org/list.jsp?userid=70665

Blijft de vraag waarom de website van @andrerij niet wil werken, iemand dit al eens gezien/een oplossing?

[Update4]

En we blijven lekker bezig, als je libapache2-mod-php niet installeert ondersteunt apache natuurlijk geen PHP pagina's

@andrerij ziet er echt top uit; heb nog 1 vraag. Hoe achterhaal ik het id van de optimizer?
De waardes die ik uit:

[...]

krijg geven in ieder geval geen resultaat.

SELECT HEX(op_id) FROM telemetry_optimizers GROUP BY op_id;

Ik heb die site van Andre nooit werkend gekregen als je daar nog de clue kan vertellen dan wil ik die ook wel proberen te herstellen.

[ Voor 5% gewijzigd door stormfly op 10-01-2019 07:22 ]

[Tomba]

stormfly schreef op donderdag 10 januari 2019 @ 07:18:
[...]

SELECT HEX(op_id) FROM telemetry_optimizers GROUP BY op_id;

Ik heb die site van Andre nooit werkend gekregen als je daar nog de clue kan vertellen dan wil ik die ook wel proberen te herstellen.

Super man! Dank je voor je hulp Gaan we proberen, heb 1 van de 16 panelen aangepast naar de bovenste waarde maar omdat de zon nog niet genoeg op is weet ik niet of het al werkt.
Ik heb e.e.a. op Ubuntu 16.04 LTS draaien met apache2 met daarop libapache2-mod-php geinstalleerd. In principe werkt de website want de energie grafieken worden netjes gevuld. Helaas blijven in ieder geval de volgende waarden altijd 0/null:

Inverter:
D:   null
Mode: null
P:    0 W
Pmax: 0 W
E:    0.000 kWh
T:    0.0 °C
Tmin:  0.0 °C
Tmax: 0.0 °C

@stormfly Wat werkt er voor jou precies niet?

[Update]
En het werkt Krijg nu data per paneel. (nu alleen nog de layout kloppend maken want ik heb een andere layout)

[ Voor 9% gewijzigd door Tomba op 10-01-2019 09:48 ]

[MaikelK.]

@andrerij ik wil ook graag de layout aanpassen maar heb zitten proberen maar kom er helaas niet uit.

Ik wil de panelen 90 graden draaien, dus ze horizontaal leggen. Dit lukt door in zonnepanelen.css
-webkit-transform:rotate(0deg);
transform:rotate(0deg);

op 90 deg te zetten. Echter staat de tekst dan verticaal, ik zou graag de opbrengst tekst horizontaal krijgen.
Waar moet ik dit aanpassen?

Ik heb deze screenshot gevonden van jou eigen installatie.


Ik zou ook graag de import/export en huis verbruik weergeven in de website.
Ik log al deze gegevens in de database van Domoticz, enig idee hoe ik dit kan implementeren?

[ Voor 27% gewijzigd door MaikelK. op 12-01-2019 00:28 ]

[stormfly]

Nu we het toch over de site van Andre hebben, ik krijg geen output weet ik vanuit testen een half jaar terug.

Hoe hebben jullie het format hier ingevuld, met name de inverter en optimizers?

EDIT: het lijkt te werken nu, ff aankijken

PHP:

// gegevens van het zonnepanelensysteem
$inverter = 1; // 1 voor enkel fase en 3 voor 3 fase inverter
$naam = "SolarEdge SE3680HD"; //naam van de inverter
$aantal = 8; // aantal zonnepanelen dat in database is opgenomen (max = 33)
// optimizer id en positie paneel
$op_id[1] = ['2056knip', '1.0.1']; //$op_id[id optimizer][inverter.string.paneelnummer]
$op_id[2] = ['2054knip', '1.0.2'];
$op_id[3] = ['2053knip', '1.0.3'];
$op_id[4] = ['2056knip', '1.0.4'];
$op_id[5] = ['2056knip', '1.0.5'];
$op_id[6] = ['2056knip', '1.0.6'];
$op_id[7] = ['2053knip', '1.0.7'];
$op_id[8] = ['2054knip', '1.0.8'];
$op_id[9] = ['0', '1.1.1'];
$op_id[10] = ['0', '1.1.1'];
$op_id[11] = ['0', '1.1.1'];
$op_id[12] = ['0', '1.1.1'];
$op_id[13] = ['0', '1.1.1'];
$op_id[14] = ['0', '1.1.1'];
$op_id[15] = ['0', '1.1.1'];
$op_id[16] = ['0', '1.1.1'];
$op_id[17] = ['0', '1.1.1'];
$op_id[18] = ['0', '1.1.1'];
$op_id[19] = ['0', '1.1.1'];
$op_id[20] = ['0', '1.1.1'];
$op_id[21] = ['0', '1.1.1'];
$op_id[22] = ['0', '1.1.1'];
$op_id[23] = ['0', '1.1.1'];
$op_id[24] = ['0', '1.1.1'];
$op_id[25] = ['0', '1.1.1'];
$op_id[26] = ['0', '1.1.1'];
$op_id[27] = ['0', '1.1.1'];
$op_id[28] = ['0', '1.1.1'];
$op_id[28] = ['0', '1.1.1'];
$op_id[30] = ['0', '1.1.1'];
$op_id[31] = ['0', '1.1.1'];
$op_id[32] = ['0', '1.1.1'];
$op_id[33] = ['0', '1.1.1'];
?>