[SolarEdge] Omvormers en optimizers zelf monitoren

[Jerrythafast]

Gelukkig, ik zag vanmorgen dat de mijne was gecrasht door een klein foutje. Heb v0.0.8 opnieuw geupload voor je

[Aegle]

Ik heb je een DM gestuurd .
Vanmorgen gedownload en geïnstalleerd. Tot nu toe geen errors. Even afwachten wat morgen brengt...

[Pietjebel10]

Jerry,
het uitlezen van de optimizer temperaturen is niet erg precies of vergis ik me daar in.
Er wordt gelogd tussen de -3 en de 14 hoe moet ik dit lezen/omzetten ?

[Jerrythafast]

De getallen die uit de optimizers komen moet je x2 doen. Die dingen meten nou eenmaal niet preciezer dan op 2 graden celsius nauwkeurig...

[Aegle]

Ik heb een tijdje terug een .php scriptje geschreven (met dank aan Jerry) om, heel redumentair, de waarden via een web pagina weer te geven. De SQL-data heb ik volgens onderstaande regels ontsloten:

code:

........
try {
    $conn = new PDO("mysql:host=$servername;dbname=$dbname", $username, $password);
    $conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $stmt = $conn->prepare("SELECT HEX(op_id), FROM_UNIXTIME(timestamp), v_in/8, i_in/160, v_in*i_in/1280, v_out/8, e_day/4, temperature*2 FROM telemetry_optimizers ORDER BY op_id DESC, timestamp DESC LIMIT 250");
........

Zoals je ziet is de temperatuur maal 2.

EDIT: tot nu toe geen meldingen in de errorlogs van mysql. Toch moest ik vanmorgen weer de logger stoppen en herstarten. Vanmorgen meteen maar de nieuwste versie van liveupdate.py geïnstalleerd. Als het goed is mag het stoppen van mysql nu niet meer voor komen. we gaan het morgen meemaken .

[ Voor 18% gewijzigd door Aegle op 12-12-2016 22:31 ]

[Jerrythafast]

Vanmorgen was dan zeker nog met v0.0.7? In v0.0.8 moet dat nu echt opgelost zijn...

[Aegle]

Nadat ik gistermorgen de service opnieuw had moeten starten, heb ik, om precies te zijn om 08:46 LT, de service weer gestopt en liveupdate.py vervangen. tot nu toe zijn alle foutmeldingen uitgebleven, maar de zon moet nog op komen...

EDIT: Om 09:23 verschijnt de volgend melding in liveupdate.log:

Reading from -
Warning: Connection to database failed: (2006, 'MySQL server has gone away'); retrying...

Het vreemde is dat mysql wel werkt. PCAP's worden gevuld en PVoutput wordt ook ge-update...

[ Voor 38% gewijzigd door Aegle op 13-12-2016 10:02 ]

[Quinie]

Geen error log mysql ?
Zelfde machine Mysql en logger ?

@Jerry: ondertussen bezig met ombouw naar influxdb. belang bij de code als het klaar is ? daarna wil ik even kijken naar het uploaden van 3 phase.

[Aegle]

Nee en ja: Geen foutmelding in de logs te bekennen en, ja, de logger en Mysql draaien op dezelfde RPi2.

[Quinie]

Dan kunnen we netwerk ook uitsluiten.
http://dev.mysql.com/doc/refman/5.7/en/gone-away.html

Ik denk nog even met je mee maar ben ook even leeg. Zou haast zeggen, waar woon je want deze jeukt

[Aegle]

Bedankt voor het meedenken .

Op dit moment wordt hier niets meer gelogd. De SE-portal wordt sinds 12:55 niet meer geupdate en, uiteraard, daardoor de lokale logging ook niet. PVoutput via de API wordt ook niet meer geupdate... .
Alleen de s0-kWh meter logt vrolijk door .

[Quinie]

Je kunt nog even in de link kijken voor eventuele oplossingen of mogelijke oorzaken. Andere optie is, denk ik, het script aanpassen om connectie iedere keer op te bouwen en te sluiten.

[Jerrythafast]

Aegle schreef op dinsdag 13 december 2016 @ 08:05:
Nadat ik gistermorgen de service opnieuw had moeten starten, heb ik, om precies te zijn om 08:46 LT, de service weer gestopt en liveupdate.py vervangen. tot nu toe zijn alle foutmeldingen uitgebleven, maar de zon moet nog op komen...

EDIT: Om 09:23 verschijnt de volgend melding in liveupdate.log:

Reading from -
Warning: Connection to database failed: (2006, 'MySQL server has gone away'); retrying...

Het vreemde is dat mysql wel werkt. PCAP's worden gevuld en PVoutput wordt ook ge-update...

Hmm, misschien is de waarschuwing niet duidelijk. Wat hier gebeurt is de gebruikelijke time-out van de verbinding (wel gek dat die gebeurt terwijl je de service herstart hebt?). Het feit dat je een warning krijgt in plaats van een dikke crash geeft aan dat liveupdate.py deze gebeurtenis heeft herkend en opnieuw verbindt ("retrying..."). Het feit dat je daarna niet alsnog een dikke crash krijgt betekent dus dat het nu prima werkt

Quinie schreef op dinsdag 13 december 2016 @ 11:01:
@Jerry: ondertussen bezig met ombouw naar influxdb. belang bij de code als het klaar is ? daarna wil ik even kijken naar het uploaden van 3 phase.

Graag, als de verschillen tussen MySQL en influxdb niet zo groot zijn kunnen we het misschien samenvoegen in een nieuwe versie van liveupdate.py.

Ik heb zondag ook een beginnetje om pvo-upload.php aan te passen voor 3-fase omvormers. Het voornaamste probleem waar ik tegenaan loop is dat de "de_day" kolom (hoeveelheid geproduceerde energie in de laatste 5 minuten) bij jouw 3-fase omvormer afgeronde data bevat. Ik denk dat ik de uptime van de omvormer aan de tabel moet gaan toevoegen zodat ik de "e_day" kolom (geproduceerde energie sinds de laatste keer dat de omvormer opstartte) kan gebruiken i.p.v. de "de_day" kolom. Ik heb de uptime van de omvormer hierbij dan wel nodig omdat de "e_day" kolom midden op de dag op 0 kan springen als je je omvormer even uit zet en dat vindt PVOutput niet leuk...

Houd er dus rekening mee dat in ieder geval de 3-fase tabel mogelijk aangepast gaat worden in de volgende versie. Als je de nieuwe kolom toevoegt met alleen een ALTER TABLE query wordt voor alles wat er nu al in staat een uptime van 0 ingevuld. Zolang je alle pcap files bewaart heb je een mooier alternatief: dan kun je met een simpel "python liveupdate.py solaredge-*.pcap" commando de hele database opnieuw vullen, inclusief de nieuwe kolom.

[Aegle]

Vanmorgen om 08:50 dezelfde melding als gisteren:

Reading from -
Warning: Connection to database failed: (2006, 'MySQL server has gone away'); retrying...

Volgens de manual stopt de Mysql-server na 8 uur inactiviteit. Blijkbaar lukt het liveupdate.py om de Mysql server weer wakker te schudden, want de logging start zonder problemen.
In de Mysql logfiles zie ik echter geen enkele melding.

[Pietjebel10]

Momenteel geen logging meer volgens my ligt SE-server eruit of vergis ik me.

[Aegle]

Hier logt zowel de logging software, de SE-portal alswel PVoutput. Als de portal niet meer werkt, zou de rest ook niet meer werken.
_{OT: Wordt het niet eens tijd om een mooie naam te verzinnen voor de logging software..?}

[Pietjebel10]

Het loopt weer raspberry gereset had geen foutmeldingen.

[Jerrythafast]

Aegle schreef op woensdag 14 december 2016 @ 12:17:
Hier logt zowel de logging software, de SE-portal alswel PVoutput. Als de portal niet meer werkt, zou de rest ook niet meer werken.
_{OT: Wordt het niet eens tijd om een mooie naam te verzinnen voor de logging software..?}

De naam "solaredge-logger" is zeker te simpel? Als je een fancy naam weet zal ik hem in overweging nemen

De update naar v0.0.8 heeft bij jou het probleem dus adequaat aangepakt. De verbinding met de MySQL server valt dus inderdaad weg doordat hij de hele nacht (lees: meer dan 8 uur achtereen) niet wordt gebruikt, maar na een reconnect gaat hij nu vrolijk verder met loggen

[Aegle]

Mooi. De melding neem ik verder voor lief en beschouw dat puur als melding en niet als error.
Nogmaals, in de mysql logs zie ik niets vreemds.

Ik ga mee met de naam "SolarEdge-logger" .

Nu weer verder sleutelen aan de grafieken en gauges... .

[Domokoen]

Het nadeel van SolarEdge-logger is dat je dan de handelsnaam van SolarEdge gebruikt - die kunnen daar tegen optreden...

[Jerrythafast]

Domokoen schreef op donderdag 15 december 2016 @ 10:18:
Het nadeel van SolarEdge-logger is dat je dan de handelsnaam van SolarEdge gebruikt - die kunnen daar tegen optreden...

Dat is inderdaad wel een risico, al lijkt het me niet waarschijnlijk dat het ze iets aantrekt dat een eenvoudig scriptje dat hun omvormers uitleest een verwijzing naar de naam van de betreffende omvormers bevat. Ik gebruik in ieder geval geen logo's enzo, en houd het verder lower case om het er niet te dik op te leggen.

[tsjoender]

Is SoEdMon anders iets voor de naam? Of SoEdLog? Of SEdLog/SEdMon?

[ Voor 15% gewijzigd door tsjoender op 16-12-2016 09:17 ]

[Jerrythafast]

tsjoender schreef op vrijdag 16 december 2016 @ 09:15:
Is SoEdMon anders iets voor de naam? Of SoEdLog? Of SEdLog/SEdMon?

Ik wil hem wel graag lowercase houden conform de conventies (je wilt niet weten hoe vaak ik al "ImportError: No module named mysqldb" heb gehad ) en dan lijkt me soedmon/soedlog/sedmon/sedlog mij ook niet heel knap eerlijk gezegd Als ik die lijn zou volgen zou ik kiezen voor selog (of misschien toch selogger?). Oftewel, de huidige naam maar dan afgekort.

[tjanssen]

Werkt de logger met alle omvormers van SolarEdge? Ook met de nieuwe HD Wave?

[Jerrythafast]

tjanssen schreef op vrijdag 16 december 2016 @ 17:48:
Werkt de logger met alle omvormers van SolarEdge? Ook met de nieuwe HD Wave?

Heb ik nog niet kunnen testen. Volgens mij is het aantal HD Waves in Nederland nog op je vingers te tellen. Zodra iemand met een HD Wave omvormer achter de solaredge-logger zich in dit topic meldt weten we het Ik verwacht dat het wel gaat werken maar die verwachting is verder totaal nergens op gebaseerd.

[ Voor 10% gewijzigd door Jerrythafast op 16-12-2016 23:53 ]

[tjanssen]

Gaan we daar binnenkort achter komen dan. Heb de keus om deze nieuwe omvormer te laten hangen namelijk. Heb de logger klaar staan.

[ Voor 15% gewijzigd door tjanssen op 17-12-2016 07:52 ]

[Aegle]

tjanssen schreef op zaterdag 17 december 2016 @ 07:09:
Gaan we daar binnenkort achter komen dan. Heb de keus om deze nieuwe omvormer te laten hangen namelijk. Heb de logger klaar staan.

ik ben wel benieuwd. Nog even en dan kan de software de gehele SE omvormer reeks aan...

[rense]

Ik had vanacht een stroomstoring (twee hoofdzekeringen eruit en een slimme meter op zwart). Sindsdien krijg ik het loggen niet meer op de rit. met sudo systemctl status se-nat, zegt hij steeds dat deze service na opstarten meteen op in-actief is gegaan (hoort dat wel?). En se-logger blijft maar wachten (rapporteert wel actief).
Ik heb de dchp leases opgeschoond, want het leek of de omvormer meerdere leases had gekregen. Dat is nu weer 1, maar nog steeds radiostilte op het netwerk.

Hebben jullie nog suggesties hoe de communicatie weer een schop te geven? Misschien dat er een settingsfile corrupt is geraakt door de plotselinge reboot door de stroomstoring?

[Jerrythafast]

Heb hier ooit wel gehad dat de pcap file waar op dat moment naar werd geschreven corrupt is geraakt (eindigt met een half packet). Voor de rest doet se-logger alleen schrijfacties naar log files en de MySQL database. De logs leest hij niet, dus dat zou hem niet kunnen tegenhouden. Dus als het al iets met corruptie is, dan is het je database...

sudo service se-logger stop
sudo service se-logger start

En als dat niet werkt:

cat /opt/se-logger/liveupdate.log
cat /opt/se-logger/tcpdump.log

En dan de output even hier posten

[ Voor 44% gewijzigd door Jerrythafast op 18-12-2016 18:13 ]

[rense]

De log-files bleven leeg, helaas. De pcap-files werden maar niet gevuld in the first place. Heb de hele dag geklooid en het niet aan de praat gekregen; keek net een paar uur later weer: eindelijk toch weer data in de pcap file :-S.

Heb inderdaad daarna alle corrupte, praktisch lege pcaps weggegooid, en nu is mijn dagprofiel weer helemaal aangevuld :-).

[Jerrythafast]

Typisch, ik zou je niet kunnen vertellen wat dan het probleem is geweest

[Yoki1985]

Corn schreef op vrijdag 25 november 2016 @ 14:09:
[...]


Moet er eens een projectpaginatje van maken; het is een intens domme draaischijfmeter met twee reflectiesensoren. Deze zitten weer op een chinese fake-duino, en die zit weer op een ESP8266.

Door gebruik te maken van 2 sensoren en een simpele state-machine kan de arduino vaststellen welke kant de meter op draait. Verder zitten er wat trucjes in om de drempelwaarden voor de comparator bij te stellen, maar verder doet ie niet veel. Iedere rotatie en richting worden via een NodeMCU scriptje op de MQTT queue gegooid, en een PHP scriptje aan de andere kant haalt deze er weer af. Het scriptje houdt via een sql-db de kWh-meters bij, en deze worden weer door een RRD scriptje achter een cronjob uitgelezen.

Daarnaast timed ie de passage van de 'zwarte streep', zodat ie redelijke nauwkeurigheid het gebruik op dit moment kan weergeven.

De zwarte lijn is actueel metering gebaseerd op de tijd tussen het passeren van de zwarte streep. Ik heb een beetje onhandige kWh meter hiervoor, want hij heeft 'slechts' 120 rotaties per kWh. Hierdoor verlies ik samples rond de 0-lijn, en treedt er aliasing op.

De milka-kleurige balken is het actuele gebruik, op basis van de SQL-kWh meter die iedere 5 minuten gesampled wordt. De 5-minuten samples van de inverter via Jerry's scripts worden hier vanaf getrokken, zodat je altijd actueel gebruik kunt aflezen.

Als ik ooit eens tijd heb zal ik eens een guide schrijven

Wat sfeerfotos:
[afbeelding][afbeelding][afbeelding][afbeelding][afbeelding]

Welke sensors gebruik je precies? Hoever hangen de sensors van de schijf af? Ik was hetzelfde aan het proberen maar volgens mij hangen bij mij de sensors te ver van de schijf (2 tal cm) om deze goed te detecteren.
De sensors die ik gebruik zijn deze: https://www.aliexpress.com/snapshot/7230118126.html?orderId=72065802193257&productId=32432727899

[tjanssen]

De SE3680H is geinstalleerd, en hangt aan de logger.

Ik zie een paar regels in de tabel telemetry_inverter, maar de tabel telemetry_optimizers blijft leeg. Dit zal wel normaal zijn omdat het donker is? Ik zie de pcap wel iedere 5 minuten groeien.

[Pietjebel10]

Even geduld tot de paneeltjes stroom gaan leveren.

[tsjoender]

Allereerst grote complimenten voor het maken van deze logger en de zeer uitgebreide topic start!

Sinds dinsdag zijn wij de trotse bezitters van twee SE3000H omvormers. Bij de installatie wilden ze deze meteen aan het internet hangen om dingen te checken en toen had ik nog niet de tijd gehad (genomen eigenlijk) om de managed switch voor te bereiden en een mirror port te configureren. Na een uur of 6 online geweest te zijn (korter waarschijnlijk) heb ik die mirror port alsnog geconfigureerd en tcpdump aangezet om pcap's te genereren. Van een omvormer heb ik nu een key, maar ik vroeg me af of de tweede key nu mogelijk genegeerd wordt omdat het script welke de pcap's afspeurt op keys er meteen mee stopt bij het vinden van een key. Voor de zekerheid heb ik tcpdump in een nieuwe file laten beginnen, dus als die uitwisseling later alsnog komt dan haal ik de key daar wel uit.

Mijn programmeer kennis is erg basaal en daarom zie ik zo niet wat ik in het find-key-in-pcap.py script aan zou moeten passen om door te blijven zoeken na het vinden van een key. Iemand een tip? Dan weet ik zeker dat ik de tweede key niet mis als ze kort na elkaar uitgewisseld zijn.

EDIT: Regel 89 aanpassen en daar de sys.exit(0) vervangen met state = 0 lijkt de hele file te parsen tot het eind.

Als iemand weet hoe ik na kan gaan welke key bij welke omvormer hoort, dan is dat ook wel handig, al is er met twee een 50/50 kans dat ik meteen de juiste match maak, dus als ik eerst verkeerd gok is dat nog wel te overzien.

Verder vroeg ik me af hoe ik de logger zelf het beste kan configureren. Ik wil van twee omvormers data uitlezen, maar de pcap bevat de data welke van beide omvormers komt doorelkaar. Zou dat moeten kunnen werken?

[ Voor 3% gewijzigd door tsjoender op 22-12-2016 19:22 ]

[Jerrythafast]

tsjoender schreef op donderdag 22 december 2016 @ 19:09:
Allereerst grote complimenten voor het maken van deze logger en de zeer uitgebreide topic start!

Sinds dinsdag zijn wij de trotse bezitters van twee SE3000H omvormers. Bij de installatie wilden ze deze meteen aan het internet hangen om dingen te checken en toen had ik nog niet de tijd gehad (genomen eigenlijk) om de managed switch voor te bereiden en een mirror port te configureren. Na een uur of 6 online geweest te zijn (korter waarschijnlijk) heb ik die mirror port alsnog geconfigureerd en tcpdump aangezet om pcap's te genereren. Van een omvormer heb ik nu een key, maar ik vroeg me af of de tweede key nu mogelijk genegeerd wordt omdat het script welke de pcap's afspeurt op keys er meteen mee stopt bij het vinden van een key. Voor de zekerheid heb ik tcpdump in een nieuwe file laten beginnen, dus als die uitwisseling later alsnog komt dan haal ik de key daar wel uit.

Mijn programmeer kennis is erg basaal en daarom zie ik zo niet wat ik in het find-key-in-pcap.py script aan zou moeten passen om door te blijven zoeken na het vinden van een key. Iemand een tip? Dan weet ik zeker dat ik de tweede key niet mis als ze kort na elkaar uitgewisseld zijn.

EDIT: Regel 89 aanpassen en daar de sys.exit(0) vervangen met state = 0 lijkt de hele file te parsen tot het eind.

Als iemand weet hoe ik na kan gaan welke key bij welke omvormer hoort, dan is dat ook wel handig, al is er met twee een 50/50 kans dat ik meteen de juiste match maak, dus als ik eerst verkeerd gok is dat nog wel te overzien.

Verder vroeg ik me af hoe ik de logger zelf het beste kan configureren. Ik wil van twee omvormers data uitlezen, maar de pcap bevat de data welke van beide omvormers komt doorelkaar. Zou dat moeten kunnen werken?

Voor alles is een eerste keer... Je bent zelf nét te laat om de eerste te zijn met een HD Wave omvormer (bedankt tjanssen, het werkt dus de optimizers gaan morgen bij daglicht vanzelf meedoen). Maar je bent wel de eerste met twee omvormers die dit logging project wil gaan gebruiken. Dat wordt voor mij weer programmeren met kerst

Even voor de duidelijkheid, hoe zijn je omvormers aangesloten?
Optie 1: Beide omvormers hebben een ethernetkabel waarmee ze aan je managed switch hangen. De logger kan het verkeer van beide afluisteren (het verkeer van beide komt 'door elkaar' in één pcap file te staan).
Optie 2: De twee omvormers zijn met elkaar verbonden via een RS485-verbinding en slechts één van beide heeft een ethernetkabel (master-slave configuratie). De omvormer met de ethernetkabel uploadt de data van beide omvormers en de logger hoeft dus alleen die omvormer af te luisteren.

[tsjoender]

Jerrythafast schreef op donderdag 22 december 2016 @ 19:47:
[...]

Maar je bent wel de eerste met twee omvormers die dit logging project wil gaan gebruiken. Dat wordt voor mij weer programmeren met kerst

Even voor de duidelijkheid, hoe zijn je omvormers aangesloten?
Optie 1: Beide omvormers hebben een ethernetkabel waarmee ze aan je managed switch hangen. De logger kan het verkeer van beide afluisteren (het verkeer van beide komt 'door elkaar' in één pcap file te staan).
Optie 2: De twee omvormers zijn met elkaar verbonden via een RS485-verbinding en slechts één van beide heeft een ethernetkabel (master-slave configuratie). De omvormer met de ethernetkabel uploadt de data van beide omvormers en de logger hoeft dus alleen die omvormer af te luisteren.

Voordat je je familie uit gaat leggen dat je deze kerst niet komt, moet ik bekennen dat ik nog niet precies weet hoe ik jouw project in ga zetten. Uiteindelijk wil ik alleen realtime weten hoeveel Watt er geproduceerd wordt en hoeveel Wh er al geproduceerd is. Zodoende kan ik het werkelijke stroomverbruik berekenen door die gegevens met de gegevens van de slimme meter te combineren en mooie staatjes te maken voor dag/week/maand/jaaropbrengst en -verbruik. Upload naar pvoutput zal dan vast ook komen. Via de portal van SolarEdge kan ik dan wel de optimiser data bekijken (en ook weer staatjes voor opbengst). Ik begreep dat de data bij de SolarEdge portal altijd iets "verouderd" is en de slimme meter nagenoeg realtime, dus dat het niet eerlijk rekenen is als ik die gegevens van de portal haal voor dit doel.

Qua opstelling heb ik nu de situatie van optie 1. Ik had me niet gerealiseerd dat optie 2 ook een mogelijkheid is. Dat zou ik eigenlijk ook wel prima vinden om het zo aan te sluiten als dat het meeluisteren eenvoudiger maakt.

[tjanssen]

Ik neem aan dat de logger niet afhankelijk is van het ip adres van de omvormer? Wat gebeurt er als deze tijdens het loggen anders wordt?

[Jerrythafast]

tsjoender schreef op donderdag 22 december 2016 @ 19:58:
[...]


Voordat je je familie uit gaat leggen dat je deze kerst niet komt, moet ik bekennen dat ik nog niet precies weet hoe ik jouw project in ga zetten. Uiteindelijk wil ik alleen realtime weten hoeveel Watt er geproduceerd wordt en hoeveel Wh er al geproduceerd is. Zodoende kan ik het werkelijke stroomverbruik berekenen door die gegevens met de gegevens van de slimme meter te combineren en mooie staatjes te maken voor dag/week/maand/jaaropbrengst en -verbruik. Upload naar pvoutput zal dan vast ook komen. Via de portal van SolarEdge kan ik dan wel de optimiser data bekijken (en ook weer staatjes voor opbengst). Ik begreep dat de data bij de SolarEdge portal altijd iets "verouderd" is en de slimme meter nagenoeg realtime, dus dat het niet eerlijk rekenen is als ik die gegevens van de portal haal voor dit doel.

Qua opstelling heb ik nu de situatie van optie 1. Ik had me niet gerealiseerd dat optie 2 ook een mogelijkheid is. Dat zou ik eigenlijk ook wel prima vinden om het zo aan te sluiten als dat het meeluisteren eenvoudiger maakt.

Optie 2 is wel iets minder storingsgevoelig voor solaredge-logger. Bij optie 1 bestaat er een hele kleine kans dat de twee omvormers tegelijk 'praten' en er een bericht van de ene omvormer midden in het bericht van de andere omvormer terecht komt. (Voorwaarde hiervoor is wel dat het bericht van die andere omvormer zo lang is dat het over meerdere TCP segments wordt verdeeld). In dit geval zul je met de huidige versie wat data in je database kunnen missen. Maar het lijkt me niet nodig om de set-up hiervoor om te bouwen.

De data die je met solaredge-logger krijgt is exact de data die naar de SolarEdge portal wordt gestuurd. Deze data is dus ook niet 100% live, over het algemeen krijg je elke 5 minuten de actuele data van elk onderdeel in het systeem (omvormer, optimizer).

Er is wel een hypothetische mogelijkheid dat je je omvormers rechtstreeks via RS485 uitleest en hierbij de frequentie van de telemetrie kunt verhogen; er lijkt een commando te bestaan waarmee je die interval van 5 minuten op elk gewenst aantal seconden kunt instellen... Je mist dan alleen wel de SolarEdge portal.

tjanssen schreef op donderdag 22 december 2016 @ 20:28:
Ik neem aan dat de logger niet afhankelijk is van het ip adres van de omvormer? Wat gebeurt er als deze tijdens het loggen anders wordt?

De logger is inderdaad niet afhankelijk van het IP-adres van de omvormer. Het IP-adres wordt zelfs volledig genegeerd. In feite wordt al het opgevangen TCP verkeer dat afkomstig is van SolarEdge netwerkkaarten (dit is te zien aan het MAC adres) geanalyseerd en samengevoegd tot één datastroom waarin SolarEdge datapakketjes worden opgespoord en verwerkt.

[ocaj]

Jerrythafast schreef op donderdag 22 december 2016 @ 19:47:
[...]
. Maar je bent wel de eerste met twee omvormers die dit logging project wil gaan gebruiken. Dat wordt voor mij weer programmeren met kerst

Ik verwacht eigenlijk dat dat "vanzelf" goed gaat. In de pakketjes die de omvormer(s) opsturen zit nl. ook het "inverter-id", oftewel het serienummer van de omvormer. De tool van Jerrythafast logt in principe alle velden in de database, en daar zit ook het inverter-id bij.

Wel moet je dus iets slimmere queries maken om de data er per omvormer weer uit te halen. Geen rocket-science als je wat sql kent.

Ik heb iets vergelijkbaars in mijn eigen oplossing (op basis van de scripts van jbuehl), waar ik ook 2 omvormers heb. Daar heb ik in mijn database nog een extra vertaaltabel voor gemaakt waar ik niet alleen de serienummers map naar herkenbare namen, maar ook alle optimizers in heb zitten met een mapping op welke omvormer ze zitten aangesloten. En daarnaast ook de positie op het dak, zodat ik niet al die serienummers hoef te interpreteren, maar in queries gewoon een logische naam zie staan als paneel "O-5", voor de 5e op Oost etc. ipv een serienummer

In de pakketjes van de omvormers zit weliswaar ook een optimizer-id, maar geen inverter-id. Die staan dus door elkaar heen. Dat is niet erg, als je een beetje handig bent met mysql queries om het eruit te halen zoals je het wil hebben.

Kortom: Ik vermoed dat Jerrythafast niet met Kerst hoeft door te werken. Ook met 2 omvormers komt alles gewoon in de database terecht.

[Jerrythafast]

ocaj schreef op donderdag 22 december 2016 @ 22:29:
[...]


Ik verwacht eigenlijk dat dat "vanzelf" goed gaat. In de pakketjes die de omvormer(s) opsturen zit nl. ook het "inverter-id", oftewel het serienummer van de omvormer. De tool van Jerrythafast logt in principe alle velden in de database, en daar zit ook het inverter-id bij.

Wel moet je dus iets slimmere queries maken om de data er per omvormer weer uit te halen. Geen rocket-science als je wat sql kent.

Ik heb iets vergelijkbaars in mijn eigen oplossing (op basis van de scripts van jbuehl), waar ik ook 2 omvormers heb. Daar heb ik in mijn database nog een extra vertaaltabel voor gemaakt waar ik niet alleen de serienummers map naar herkenbare namen, maar ook alle optimizers in heb zitten met een mapping op welke omvormer ze zitten aangesloten. En daarnaast ook de positie op het dak, zodat ik niet al die serienummers hoef te interpreteren, maar in queries gewoon een logische naam zie staan als paneel "O-5", voor de 5e op Oost etc. ipv een serienummer

In de pakketjes van de omvormers zit weliswaar ook een optimizer-id, maar geen inverter-id. Die staan dus door elkaar heen. Dat is niet erg, als je een beetje handig bent met mysql queries om het eruit te halen zoals je het wil hebben.

Kortom: Ik vermoed dat Jerrythafast niet met Kerst hoeft door te werken. Ook met 2 omvormers komt alles gewoon in de database terecht.

Je weet dat je nu tegen mij praat in de 3e persoon he?

Er zijn twee onderdeeltjes van mijn monitoring tool die niet lekker werken met meerdere omvormers en dat zijn find-key-in-pcap.py en pvo-upload.php. Daar doelde ik dus op Voor het eerste heeft hij intussen een oplossing gevonden (al is het nog niet direct duidelijk welke omvormer bij welke sleutel hoort). Het tweede is triviaal op te lossen door het een en ander te dupliceren.

[ocaj]

Ja, die onderdelen hebben er inderdaad wel last van.
Ik had alleen naar het loggen zelf gekeken.

Voor mij is het het belangrijkste dat alle data goed in een database terecht komt. Het eruit halen en op het scherm toveren in mooie grafiekjes/overzichtjes is van een tweede orde.

Als je in pvo_upload een lijstje met omvormer-id's toevoegt, dan kun je het omvormer-id aan je query toevoegen en dat dan voor het hele lijstje doen. Met een leeg lijstje (default) doe je de huidige query, zodat alleen de mensen die meer dan 1 omvormer hebben dat hoeven te configureren.

(en als je echt niks te doen hebt met Kerst kun je altijd nog het lijstje van alle aanwezige omvormer-id's dynamisch uit de database ophalen, dan gaat het zelfs nog goed als je de omvormer vervangt)

[tjanssen]

Tabellen worden nu inderdaad gevuld. Ik zie verder nu ook twee tcpdump processen draaien. Het proces van gisteren lijkt niet gekilled te zijn. Met als gevolg dat er nu ook 2 pcap bestanden blijven groeien...

[tsjoender]

Jerrythafast schreef op donderdag 22 december 2016 @ 20:50:
[...]

De data die je met solaredge-logger krijgt is exact de data die naar de SolarEdge portal wordt gestuurd. Deze data is dus ook niet 100% live, over het algemeen krijg je elke 5 minuten de actuele data van elk onderdeel in het systeem (omvormer, optimizer).

Er is wel een hypothetische mogelijkheid dat je je omvormers rechtstreeks via RS485 uitleest en hierbij de frequentie van de telemetrie kunt verhogen; er lijkt een commando te bestaan waarmee je die interval van 5 minuten op elk gewenst aantal seconden kunt instellen... Je mist dan alleen wel de SolarEdge portal.

Goed om te weten dat de omvormer iedere vijf minuten updates geeft, Ik dacht dat dat vaker zou zijn, maar iedere vijf minuten lijkt me ook prima. De slimme meter doet updates iedere 10 seconden, dus als ik bij de update van de omvormer op dat moment de waarden van de slimme meter erbij zoek, dan heb ik een redelijke nauwkeurigheid en liggen de metingen hooguit 10 seconden uit elkaar. Ik ga de data niet wetenschappelijk publiceren, dus zo'n meetfout/marge voor thuis kan ik wel mee leven.

Via RS485 heb ik ook bekeken (en een adapter ervoor gekocht), maar had ook al begrepen dat het of/of is en niet en/of qua communicatie mogelijkheden. Eerst maar eens spelen met het loggen naar de portal en meeluisteren naar de voor mij relevante data.

Het lijkt er overigens op (als ik de handleiding bekijk) dat de HD Wave omvormers geen RS232 aansluiting meer hebben. Plan B om de keys te achterhalen, lijkt hier dan niet mogelijk. Ik heb de tweede key nog niet binnen, dus spannend of die nog volgt of dat ik die gemist heb... In mijn geval zou ik dan nog met een master /slave opstelling kunnen werken toch en de omvormer waarvoor ik de key wel heb kunnen onderscheppen de upload van de data laten verzorgen? Een factory reset zou ook nog een optie zijn natuurlijk al was die optie niet getest en ik weet niet of de installateur dan nog moeilijk gaat doen.

[Pietjebel10]

Voor mij is het het belangrijkste dat alle data goed in een database terecht komt. Het eruit halen en op het scherm toveren in mooie grafiekjes/overzichtjes is van een tweede orde.

Moet er interesse zijn voor grafiekjes en uitlezen van de database heb een ontwerp draaien.
Mocht hier interesse voor zijn mail maar even, zal ik het beschikbaar stellen

[Jerrythafast]

tjanssen schreef op vrijdag 23 december 2016 @ 10:10:
Tabellen worden nu inderdaad gevuld. Ik zie verder nu ook twee tcpdump processen draaien. Het proces van gisteren lijkt niet gekilled te zijn. Met als gevolg dat er nu ook 2 pcap bestanden blijven groeien...

Lijkt erop dat je service niet goed stopt. Er was eerder ook iemand die dit meldde maar ik kan het even niet meer terugvinden.

Zou je dit willen proberen/testen?
- even de kabel van de omvormer eruit kunnen trekken (zodat je geen data mist)
- sudo service se-logger stop (misschien een paar keer herhalen? geen idee of dat uitmaakt )
- daarna eventuele overgebleven tcpdump processen handmatig killen
- sudo service se-logger start
- sudo service se-logger stop
- sudo service se-logger start
- Draaien er nu twee tcpdump processen? Dan is er toch wat loos In dat geval zou je in het .service bestand de KillMode eens kunnen proberen veranderen naar control-group en dan bovenstaande nog eens proberen.

tsjoender schreef op vrijdag 23 december 2016 @ 10:25:
Het lijkt er overigens op (als ik de handleiding bekijk) dat de HD Wave omvormers geen RS232 aansluiting meer hebben. Plan B om de keys te achterhalen, lijkt hier dan niet mogelijk. Ik heb de tweede key nog niet binnen, dus spannend of die nog volgt of dat ik die gemist heb... In mijn geval zou ik dan nog met een master /slave opstelling kunnen werken toch en de omvormer waarvoor ik de key wel heb kunnen onderscheppen de upload van de data laten verzorgen? Een factory reset zou ook nog een optie zijn natuurlijk al was die optie niet getest en ik weet niet of de installateur dan nog moeilijk gaat doen.

Hmm, misschien heeft hij nog wel een USB-poort aan de binnenkant zitten? Of ze zeggen er gewoon niks over in de handleiding omdat het voor 99,999% van de mensen toch niet interessant is.

[tsjoender]

Jerrythafast schreef op vrijdag 23 december 2016 @ 11:40:
[...]
Hmm, misschien heeft hij nog wel een USB-poort aan de binnenkant zitten? Of ze zeggen er gewoon niks over in de handleiding omdat het voor 99,999% van de mensen toch niet interessant is.

Die kap gaat er bij mij vast nog wel een keer af een dezer dagen, dus ik kan dan wel eens kijken of ik ergens een USB aansluiting tegenkom.

[tjanssen]

Jerrythafast schreef op vrijdag 23 december 2016 @ 11:40:
[...]

Lijkt erop dat je service niet goed stopt. Er was eerder ook iemand die dit meldde maar ik kan het even niet meer terugvinden.

Zou je dit willen proberen/testen?
- even de kabel van de omvormer eruit kunnen trekken (zodat je geen data mist)
- sudo service se-logger stop (misschien een paar keer herhalen? geen idee of dat uitmaakt )
- daarna eventuele overgebleven tcpdump processen handmatig killen
- sudo service se-logger start
- sudo service se-logger stop
- sudo service se-logger start
- Draaien er nu twee tcpdump processen? Dan is er toch wat loos In dat geval zou je in het .service bestand de KillMode eens kunnen proberen veranderen naar control-group en dan bovenstaande nog eens proberen.

Er draaien dan inderdaad 2 processen. De KillMode veranderen does the job. Wel vreemd, heb de logger ook een paar nachten laten draaien zonder omvormer eraan, toen werkte alles prima...

Is het misschien een mogelijkheid om een optie toe te voegen welke de hele interface waar de omvormer aanhangt down te gooien in geval het tcpdump proces niet meer draait? Dan mis je nooit gegevens.

[Jerrythafast]

tjanssen schreef op vrijdag 23 december 2016 @ 13:35:
[...]


Er draaien dan inderdaad 2 processen. De KillMode veranderen does the job. Wel vreemd, heb de logger ook een paar nachten laten draaien zonder omvormer eraan, toen werkte alles prima...

Is het misschien een mogelijkheid om een optie toe te voegen welke de hele interface waar de omvormer aanhangt down te gooien in geval het tcpdump proces niet meer draait? Dan mis je nooit gegevens.

Dat zou inderdaad een handige optie zijn, ik weet alleen niet precies hoe het moet. Er moet dan iets van een system-wide instelling zijn die zegt: als proces X niet bestaat, mag interface Y niet gebruikt worden. Als iemand weet of dit mogelijk is laat ik me graag voorlichten over hoe dit moet

[tinka]

Iemand enig idee waarom ik

root@es-logger:/opt/se-logger# /usr/bin/php pvo-upload.php
cURL error, exiting: The requested URL returned error: 400 Bad Request
root@es-logger:/opt/se-logger#

zou kunnen krijgen?

Als ik een echo van de data (die naar pvouput gaat) krijg ik een hele reeks aan waarden. Het lijkt me dat dan de toegang tot de mysql kant ok is. PVoutput id en api key triple checked.

[Jerrythafast]

tinka schreef op vrijdag 23 december 2016 @ 21:58:
Iemand enig idee waarom ik

root@es-logger:/opt/se-logger# /usr/bin/php pvo-upload.php
cURL error, exiting: The requested URL returned error: 400 Bad Request
root@es-logger:/opt/se-logger#

zou kunnen krijgen?

Als ik een echo van de data (die naar pvouput gaat) krijg ik een hele reeks aan waarden. Het lijkt me dat dan de toegang tot de mysql kant ok is. PVoutput id en api key triple checked.

Heb je aan PVOutput gedoneerd? If not: verander LIMIT 100 in LIMIT 30 in pvo-upload.php.

[tinka]

Ja, het is wel het tweede systeem onder mijn account. Maar zelfs als ik de LIMIT op 10 zet komt er dezelfde fout.

[Jerrythafast]

tinka schreef op vrijdag 23 december 2016 @ 22:14:
Ja, het is wel het tweede systeem onder mijn account. Maar zelfs als ik de LIMIT op 10 zet komt er dezelfde fout.

Zet anders RETURNTRANSFER eens op false, als je 'm dan runt zou je HTTP blaat op je terminal moeten krijgen. Misschien staat daar een meer verhelderende foutmelding in.

[tinka]

Nope, geen verschil.

root@es-logger:/opt/se-logger# nano pvo-upload.php

...
$c = curl_init("http://pvoutput.org/service/r2/addbatchstatus.jsp");
curl_setopt_array($c, [
CURLOPT_RETURNTRANSFER => false,
CURLOPT_FAILONERROR => true,
...

root@es-logger:/opt/se-logger# /usr/bin/php pvo-upload.php
cURL error, exiting: The requested URL returned error: 400 Bad Request
root@es-logger:/opt/se-logger#

[Jerrythafast]

tinka schreef op vrijdag 23 december 2016 @ 22:24:
Nope, geen verschil.

root@es-logger:/opt/se-logger# nano pvo-upload.php

...
$c = curl_init("http://pvoutput.org/service/r2/addbatchstatus.jsp");
curl_setopt_array($c, [
CURLOPT_RETURNTRANSFER => false,
CURLOPT_FAILONERROR => true,
...

root@es-logger:/opt/se-logger# /usr/bin/php pvo-upload.php
cURL error, exiting: The requested URL returned error: 400 Bad Request
root@es-logger:/opt/se-logger#

Ah stom, dat had ik kunnen verwachten Behalve RETURNTRANSFER op false, moet je ook FAILONERROR even op false zetten. En even de $db query aan het einde weg //commenten. Dan zou je wél duidelijkere output moeten krijgen.

[tinka]

ah

root@es-logger:/opt/se-logger# /usr/bin/php pvo-upload.php
Bad request 400: Date is older than 90 days [20160821]root@es-logger:/opt/se-logger#

Weet je hoe ik de database kan schoonmaken en opnieuw vullen vanuit de pcap files?

>aanvulling

Ok database gedelete en opnieuw gemaakt. De eerste pcap file heeft blijkbaar een datum die PVoutput niet kan waarderen. Ik heb nu alles behalve deze eerste file verwerkt.

Het lijkt nu te werken. Morgen controleren of het ook online werkt.

[ Voor 58% gewijzigd door tinka op 24-12-2016 01:21 ]

[Jerrythafast]

tinka schreef op zaterdag 24 december 2016 @ 00:06:
ah

root@es-logger:/opt/se-logger# /usr/bin/php pvo-upload.php
Bad request 400: Date is older than 90 days \[20160821]root@es-logger:/opt/se-logger#

Weet je hoe ik de database kan schoonmaken en opnieuw vullen vanuit de pcap files?

>aanvulling

Ok database gedelete en opnieuw gemaakt. De eerste pcap file heeft blijkbaar een datum die PVoutput niet kan waarderen. Ik heb nu alles behalve deze eerste file verwerkt.

Het lijkt nu te werken. Morgen controleren of het ook online werkt.

Mooi! Nu willen we natuurlijk wel een PVOutput linkje om het resultaat te aanschouwen

[tsjoender]

Jerrythafast schreef op vrijdag 23 december 2016 @ 19:08:
[...]

Dat zou inderdaad een handige optie zijn, ik weet alleen niet precies hoe het moet. Er moet dan iets van een system-wide instelling zijn die zegt: als proces X niet bestaat, mag interface Y niet gebruikt worden. Als iemand weet of dit mogelijk is laat ik me graag voorlichten over hoe dit moet

Waarschijnlijk kun je Monit gebruiken hiervoor. Die kun je allerhande zaken laten controleren en daar weer acties aan koppelen als de status veranderd.

Omgekeerd zou volgens mij ook kunnen als de interface exclusief gebruikt wordt om met de omvormer te verbinden. Je zou dan een script toe kunnen voegen aan /etc/network/if-up.d en / of /etc/network/if-down.d. Daarbij zou je dan niet tcpdump herstarten, maar de interface down brengen (en via een if-down script tcpdump stoppen) en de interface weer up brengen (en een tcpdump starten op die interface).

https://wiki.ubuntu.com/OnNetworkConnectionRunScript

[tinka]

Mooi! Nu willen we natuurlijk wel een PVOutput linkje om het resultaat te aanschouwen

bij deze http://pvoutput.org/intraday.jsp?id=53302&sid=49539.

Het is nu alleen wachten op mooier weer.

[Aegle]

gefeliciteerd!

Als we zo doorgaan kunnen we straks een eigen team aanmaken bij PVoutput .

[tsjoender]

Vandaag de kap van de SE3000H gehad en er is inderdaad een micro-USB aansluiting net naast de ethernet aansluiting. Als ik daar een laptop aankoppel, dan wordt er een serial-USB device aangemaakt (FTDI). Het lukte me alleen niet om de key op te vragen met het get-key-by-rs232-verbose.py script. Bij het invullen van het serienummer worden alleen Hex waarden geaccepteerd en bij mij is het serienummer niet volledig Hex. Als ik de niet Hex letters weglaat werkt het ook niet. Moet de omvormer ook ingesteld worden op RS232 communicatie voordat ik de key opvraag? Waren de serienummers van de voorgaande omvormers helemaal in Hex of klopt het dat je alleen het tweede blok invult (die is wel volledig Hex bij mij).

[Pietjebel10]

tsjoender schreef op zaterdag 24 december 2016 @ 14:08:
Vandaag de kap van de SE3000H gehad en er is inderdaad een micro-USB aansluiting net naast de ethernet aansluiting. Als ik daar een laptop aankoppel, dan wordt er een serial-USB device aangemaakt (FTDI). Het lukte me alleen niet om de key op te vragen met het get-key-by-rs232-verbose.py script. Bij het invullen van het serienummer worden alleen Hex waarden geaccepteerd en bij mij is het serienummer niet volledig Hex. Als ik de niet Hex letters weglaat werkt het ook niet. Moet de omvormer ook ingesteld worden op RS232 communicatie voordat ik de key opvraag? Waren de serienummers van de voorgaande omvormers helemaal in Hex of klopt het dat je alleen het tweede blok invult (die is wel volledig Hex bij mij).

Ik heb het met de get key by rs232 gedaan op de SE3000

Bij aansluiten zie je welke com wordt aangemaakt, dit invullen in file + inverter_id

serial_port ="com9"
inverter_id = 0x7xxxxxxx

[Jerrythafast]

tsjoender schreef op zaterdag 24 december 2016 @ 14:08:
Vandaag de kap van de SE3000H gehad en er is inderdaad een micro-USB aansluiting net naast de ethernet aansluiting. Als ik daar een laptop aankoppel, dan wordt er een serial-USB device aangemaakt (FTDI). Het lukte me alleen niet om de key op te vragen met het get-key-by-rs232-verbose.py script. Bij het invullen van het serienummer worden alleen Hex waarden geaccepteerd en bij mij is het serienummer niet volledig Hex. Als ik de niet Hex letters weglaat werkt het ook niet. Moet de omvormer ook ingesteld worden op RS232 communicatie voordat ik de key opvraag? Waren de serienummers van de voorgaande omvormers helemaal in Hex of klopt het dat je alleen het tweede blok invult (die is wel volledig Hex bij mij).

Het serienummer van je omvormer is iets dat lijkt op "7F10269C-A9". Mogelijk staat er op de sticker nog een stukje voor, dit kun je weglaten. De twee tekens en het streepje aan het einde kun je ook weglaten. In het script zet je dan 0x7F10269C.

[tsjoender]

Jerrythafast schreef op zaterdag 24 december 2016 @ 16:10:
[...]

Het serienummer van je omvormer is iets dat lijkt op "7F10269C-A9". Mogelijk staat er op de sticker nog een stukje voor, dit kun je weglaten. De twee tekens en het streepje aan het einde kun je ook weglaten. In het script zet je dan 0x7F10269C.

Okee gelukt! Die com poort stond wel goed, maar blijkbaar moet je dus alles voor de eerste 7 in het serienummer vergeten (twee letters en vijf cijfers in mijn geval). De instruktie in de topicstart had het over de eerste acht tekens gebruiken en daarmee kwam ik er niet helemaal uit, maar nu blijkt dat op de SE3000H dus ook prima met RS232 als plan B de key achterhaald kan worden. Top!

[Jerrythafast]

tsjoender schreef op zaterdag 24 december 2016 @ 16:37:
[...]

Okee gelukt! Die com poort stond wel goed, maar blijkbaar moet je dus alles voor de eerste 7 in het serienummer vergeten (twee letters en vijf cijfers in mijn geval). De instruktie in de topicstart had het over de eerste acht tekens gebruiken en daarmee kwam ik er niet helemaal uit, maar nu blijkt dat op de SE3000H dus ook prima met RS232 als plan B de key achterhaald kan worden. Top!

Super! De reden dat in de TS "de eerste 8 tekens" staat is omdat behalve op de grote sticker aan de zijkant van de omvormer eigenlijk nergens die andere letters en cijfers erbij staan. Niet op de barcode sticker, niet op het LCD, niet in de monitoring portal... zelfs in de data in mijn PCAP bestanden heb ik dat eerste stukje niet terug kunnen vinden Tezamen met het "0x7f10..." voorbeeld dat in het script staat hoopte ik maar dat het duidelijk was

[tjanssen]

Heeft iemand ooit meegemaakt dat (oude) data niet meer te importeren is op pvoutput? Mis een dag, afgelopen vrijdag. Via het php script gebeurt er niks. Geen foutmeldingen, maar de data verschijnt nergens. Ook met de "CSV loader" op de website gebeurt hetzelfde. De data wordt wel geaccepteerd, en ik krijg de melding "Your data was uploaded and is scheduled for loading in the next 2-3 minutes". Echter, ik zie de data nooit verschijnen.

Iemand een idee?

[Aegle]

Vreemd. Misschien een overbodige vraag, maar staat er van vrijdag wel data in je ..pcap-file?

[tjanssen]

Alles staat er in ja. Staat ook gewoon in de tabel telemetry_inverter. Heb alleen zaterdag de output naar pvoutput pas aangezet. Heb van de tabel data een CSV gemaakt, maar dit maakt dus ook niet uit. Op dezelfde manier heb ik 24/12 en 25/12 ook gedaan, en deze gingen gewoon goed...

[Jerrythafast]

Als je data per 5 minuten wilt uploaden moet je de Live Loader hebben. De CSV loader is alleen voor gegevens aan het einde van de betreffende dag.

Je kunt ook deze query runnen:

SQL:

UPDATE live_update SET pvo_last_live = UNIX_TIMESTAMP("2016-12-23");

Dan zou het upload script alle data van vrijdag tot en met nu weer opnieuw moeten gaan uploaden.

[tjanssen]

Jerrythafast schreef op maandag 26 december 2016 @ 10:26:
Als je data per 5 minuten wilt uploaden moet je de Live Loader hebben. De CSV loader is alleen voor gegevens aan het einde van de betreffende dag.

Inderdaad, mijn fout. Ik had ook de Live Loader ook gebruikt, en dus niet de CSV loader.

Met de pvo_last_live heb ik gisteren ook al zitten spelen, nu nogmaals geprobeerd. Data blijft er vreemd uitzien. Heb ook het idee dat er bij pvoutput op de achtergrond een aantal import processen ofzo door elkaar aan het lopen zijn. Zo worden nu de laatste twee regels van 24/12 op 23/12 gezet. Heb alle data bij pvoutput verwijderd, en ff mijn cronjob uitgezet. Probeer het over een aantal uurtjes nog wel een keer...

Nu eerst Kerstdiner...

[Aegle]

tjanssen schreef op maandag 26 december 2016 @ 10:51:
[...]

Nu eerst Kerstdiner...

Huh? Om 10:51?

[Jerrythafast]

Aegle maakt onbedoeld een hele goede opmerking: Hoe staat het met de tijdzone-instelling op PVOutput en op je logger? Als die niet overeenkomen gaat het natuurlijk niet werken. Als je nu aan je kerstdiner gaat zitten, heb je in ieder geval een andere tijdzone dan wij

[Aegle]

Als de tijdzone verkeerd zou staan zou de data nog steeds zichtbaar moeten zijn, toch? Alleen in tijd verschoven.
Zoals ik in juli had, weet je nog? Ik had toen de timezone in php.ini aangepast, maar die bleek in de verkeerde directory te staan...

[Jerrythafast]

Klopt... Tjanssen zei ook "Zo worden nu de laatste twee regels van 24/12 op 23/12 gezet." wat mij toch doet vermoeden dat er iets geks met de tijd aan de hand is.

Aan de andere kant, PVOutput ligt er nu helemaal uit... dus misschien is er toch iets aan hun kant dat rammelt.

[ Voor 26% gewijzigd door Jerrythafast op 26-12-2016 13:32 ]

[Aegle]

Inderdaad. Misschien dan toch een tijdzone verschil.

PVoutput logt nog momenteel nog wel mijn RPi . Laatste logging om 14:25.
De API van SE logt niet meer. Die is gestopt om 12:35. De SE-portal zelf doet het nog wel.

[Jerrythafast]

Heeee, zie databeestje in "Elektriciteit opwekken met zonnepanelen (PV) Deel 5"

[Aegle]

Jerrythafast schreef op maandag 26 december 2016 @ 21:02:
Heeee, zie databeestje in "Elektriciteit opwekken met zonnepanelen (PV) Deel 5"

Zie ook "het grote jou productie topic"...de logging software deed het wel gewoon. Ook naar PVoutput wegschrijven...

[ Voor 12% gewijzigd door Aegle op 26-12-2016 21:19 ]

[tjanssen]

Goede morgen allemaal,

Ik zit ook gewoon in de CET tijdzone, dus daar zit het probleem niet. Had gisteren eigenlijk een Kerstbrunch, en niet echt diner.

De data upload blijft mis gaan bij pvoutput. De panelen zijn de 22ste geinstalleerd. Heb pas de 24ste ofzo de upload naar pvoutput aangezet, maar hier klopte vanaf het begin dus ook al niets van. Omdat de timezone van mijn Pi nog niet goed stond, heb ik alle data verwijderd, en opnieuw laten uploaden. Blijft dus fout gaan...

[Aegle]

Mmm. Even ter controle. Wat geeft je RPi als je onderstaand commando geeft? Tijdens wintertijd zou dat UTC+1 moeten zijn:

pi@rpi2-solarlogger:~ $ date +%:z
+01:00
pi@rpi2-solarlogger:~

[tjanssen]

Geeft ook gewoon +01:00. Het gaat van kwaad tot erger, nu worden de gegevens van 25/12 en 26/12 ook niet meer geaccepteerd. Heb nu de LIMIT 30 eens op 1 gezet, kijken of dat verschil gaat maken.

Edit: de LIMIT 1 maakt ook niet uit.

[ Voor 9% gewijzigd door tjanssen op 27-12-2016 12:57 ]

[Jerrythafast]

tjanssen schreef op dinsdag 27 december 2016 @ 12:30:
Geeft ook gewoon +01:00. Het gaat van kwaad tot erger, nu worden de gegevens van 25/12 en 26/12 ook niet meer geaccepteerd. Heb nu de LIMIT 30 eens op 1 gezet, kijken of dat verschil gaat maken.

Edit: de LIMIT 1 maakt ook niet uit.

Tijdzone is dus goed. Had je de data verwijderd door op de daily lijst op de vinkjes en dan de prullenbak te klikken of ben je naar de afzonderlijke intraday pagina's gegaan en heb je daar op de prullenbak gedrukt?

Indien het eerste: probeer het tweede eens Je kunt nog naar de intraday pagina's door in de URL jouw id, sid en de datum (dt) in te vullen:

code:

http://pvoutput.org/intraday.jsp?id=48021&sid=43748&dt=20161227

[Yoki1985]

Jerrythafast schreef op donderdag 10 november 2016 @ 20:24:

[...]

Het is nog steeds mogelijk hoor. Je zult alleen je omvormer open moeten schroeven en even via USB of RS-232 aan een computer moeten hangen om de encryptie sleutel uit te lezen. Zie paragraaf 6.2: 'De encryptiesleutel achterhalen via RS-232'.

Hiervoor heb je het project van jbuehl dat rense hierboven linkt helemaal niet nodig. Bij solaredge-logger zit een heel simpel scriptje dat je hiervoor kunt gebruiken. Dit werkt zelfs nog op Windows. Je moet in het script even het serienummer van je omvormer en de naam van de seriële poort (COM-poort op Windows) invullen in het SETTINGS gedeelte en dan is het simpelweg:

python get-key-by-rs232.py

Het script roept dan "Your key is: '....'". Die key vul je in in liveupdate.py en klaar is Kees

Ik ben dit nu aan het proberen maar als ik het python script uitvoer dan krijg ik de volgende error boodschap:

\Downloads\solaredge-logger-v0.0.8\get-encryption-key>Python get-key-by-rs232.py
Traceback (most recent call last):
  File "get-key-by-rs232.py", line 75, in <module>
    getKeyPart(connection, i+1, inverter_id)) + "'")
  File "get-key-by-rs232.py", line 75, in <genexpr>
    getKeyPart(connection, i+1, inverter_id)) + "'")
  File "get-key-by-rs232.py", line 68, in getKeyPart
    struct.pack("<H", 0x238 + seq))))
  File "get-key-by-rs232.py", line 60, in calcCrc
    crc = crcTable[(crc ^ ord(d)) & 0xff] ^ (crc >> 8)
TypeError: ord() expected string of length 1, but int found

Enig idee wat ik misdoe?

Edit:

Dit zijn mijn com instellingen van de solaredge


Edit 2:

Ik heb ook volgende tutorial gevolgd want windows herkende niet standaard de solaredge:
http://www.usb-drivers.org/ft232r-usb-uart-driver.html

[ Voor 7% gewijzigd door Yoki1985 op 27-12-2016 14:14 ]

[Jerrythafast]

Yoki1985 schreef op dinsdag 27 december 2016 @ 14:10:
[...]


Ik ben dit nu aan het proberen maar als ik het python script uitvoer dan krijg ik de volgende error boodschap:

\Downloads\solaredge-logger-v0.0.8\get-encryption-key>Python get-key-by-rs232.py
Traceback (most recent call last):
  File "get-key-by-rs232.py", line 75, in <module>
    getKeyPart(connection, i+1, inverter_id)) + "'")
  File "get-key-by-rs232.py", line 75, in <genexpr>
    getKeyPart(connection, i+1, inverter_id)) + "'")
  File "get-key-by-rs232.py", line 68, in getKeyPart
    struct.pack("<H", 0x238 + seq))))
  File "get-key-by-rs232.py", line 60, in calcCrc
    crc = crcTable[(crc ^ ord(d)) & 0xff] ^ (crc >> 8)
TypeError: ord() expected string of length 1, but int found

Enig idee wat ik misdoe?

Edit:

Dit zijn mijn com instellingen van de solaredge
[afbeelding]

Edit 2:

Ik heb ook volgende tutorial gevolgd want windows herkende niet standaard de solaredge:
http://www.usb-drivers.org/ft232r-usb-uart-driver.html

I see, weer zo'n nasty verschil tussen Python2 en Python3. Het script verwacht dat je op Python2 draait.

[tjanssen]

Jerrythafast schreef op dinsdag 27 december 2016 @ 13:31:
[...]

Tijdzone is dus goed. Had je de data verwijderd door op de daily lijst op de vinkjes en dan de prullenbak te klikken of ben je naar de afzonderlijke intraday pagina's gegaan en heb je daar op de prullenbak gedrukt?

Indien het eerste: probeer het tweede eens Je kunt nog naar de intraday pagina's door in de URL jouw id, sid en de datum (dt) in te vullen:

code:

http://pvoutput.org/intraday.jsp?id=48021&sid=43748&dt=20161227

Dit heeft zeker geholpen! Middels een directe link waren ook de dagen te benaderen die niet in het lijstje van outputs stonden. Hier stond allemaal rare (verschoven) data in. Na op deze manier echt alles verwijderd te hebben heeft de import wel gewerkt!

Sturen jullie inverters trouwens midden in de nacht ook data? Heb ongeveer 1 keer per nacht een mode 2 bericht. Tijdstip hiervan lijkt willekeurig te zijn. Heb het vermoeden dat het hier ergens fout gegaan is.

[tsjoender]

Vandaag geprobeerd om de verzamelde pcap data uit te lezen en in MySQL op te slaan. Dankzij de goede uitleg in de topicstart had ik dat snel voorelkaar (eerst voor een omvormer). Nu leek het mij handig als meteen na het updaten van de data in MySQL ook een http call gedaan wordt naar mijn Domoticz instance vanuit liveupdate.py. Hier blijkt alleen dat mijn programmeer skills tekort schieten, dus graag wat hulp.

Ik heb al uitgevonden hoe ik met urllib2 een http call kan doen naar Domoticz toe en daar zie ik dan een device bijgewerkt worden. Maar voor mij werkt dit alleen als ik steeds eenzelfde URL gebruik. Als ik variabelen wil gebruiken in de URL dan krijg ik allemaal foutmeldingen over de verkeerde syntax, verkeerde type (string, list, tuple etc). Ik begrijp dat de waarden welke naar MySQL geschreven worden een tuple is, maar hoe kan ik daar een aantal waarden uit destileren? Dat wordt me niet duidelijk. Het eerste deel van de URL is altijd gelijk en het laatste deel bevat de waarden welke variabel zijn. Ik zie voorbeelden dat ik zo'n URL dan samen kan stellen:

code:

        url_data = <lijstje variabelen met puntcomma gescheiden>
        url = "http://<hostname>:8080/json.htm?type=command&param=udevice&idx=123&nvalue=0&svalue=" + url_data
        urllib2.urlopen(url)

Maar ik krijg het maar niet voorelkaar om uit die lijst met waarden een paar specifieke te pakken en als string te presenteren met de naam url_data. Wie kan mij op weg helpen? Het gaat voor nu specifiek om p_active en e_total waarmee de uiteindelijke totale URL er zo ongeveer uit zou komen te zien:

code:

http://<hostname>:8080/json.htm?type=command&param=udevice&idx=123&nvalue=0&svalue=123.456;2345

[Jerrythafast]

tjanssen schreef op dinsdag 27 december 2016 @ 19:18:
[...]


Dit heeft zeker geholpen! Middels een directe link waren ook de dagen te benaderen die niet in het lijstje van outputs stonden. Hier stond allemaal rare (verschoven) data in. Na op deze manier echt alles verwijderd te hebben heeft de import wel gewerkt!

Sturen jullie inverters trouwens midden in de nacht ook data? Heb ongeveer 1 keer per nacht een mode 2 bericht. Tijdstip hiervan lijkt willekeurig te zijn. Heb het vermoeden dat het hier ergens fout gegaan is.

Hier is dat alleen 2x voorgekomen doordat ik de omvormer 's avonds laat een reset had gegeven (powercycle). Normaal gesproken blijft hij stil in de nacht.

tsjoender schreef op dinsdag 27 december 2016 @ 19:52:
Vandaag geprobeerd om de verzamelde pcap data uit te lezen en in MySQL op te slaan. Dankzij de goede uitleg in de topicstart had ik dat snel voorelkaar (eerst voor een omvormer). Nu leek het mij handig als meteen na het updaten van de data in MySQL ook een http call gedaan wordt naar mijn Domoticz instance vanuit liveupdate.py. Hier blijkt alleen dat mijn programmeer skills tekort schieten, dus graag wat hulp.

Ik heb al uitgevonden hoe ik met urllib2 een http call kan doen naar Domoticz toe en daar zie ik dan een device bijgewerkt worden. Maar voor mij werkt dit alleen als ik steeds eenzelfde URL gebruik. Als ik variabelen wil gebruiken in de URL dan krijg ik allemaal foutmeldingen over de verkeerde syntax, verkeerde type (string, list, tuple etc). Ik begrijp dat de waarden welke naar MySQL geschreven worden een tuple is, maar hoe kan ik daar een aantal waarden uit destileren? Dat wordt me niet duidelijk. Het eerste deel van de URL is altijd gelijk en het laatste deel bevat de waarden welke variabel zijn. Ik zie voorbeelden dat ik zo'n URL dan samen kan stellen:

code:

        url_data = <lijstje variabelen met puntcomma gescheiden>
        url = "http://<hostname>:8080/json.htm?type=command&param=udevice&idx=123&nvalue=0&svalue=" + url_data
        urllib2.urlopen(url)

Maar ik krijg het maar niet voorelkaar om uit die lijst met waarden een paar specifieke te pakken en als string te presenteren met de naam url_data. Wie kan mij op weg helpen? Het gaat voor nu specifiek om p_active en e_total waarmee de uiteindelijke totale URL er zo ongeveer uit zou komen te zien:

code:

http://<hostname>:8080/json.htm?type=command&param=udevice&idx=123&nvalue=0&svalue=123.456;2345

Python:

url = "http://<hostname>:8080/json.htm?type=command&param=udevice&idx=123&nvalue=0&svalue=%(p_active)s;%(e_total)s" % telem

[tjanssen]

tsjoender schreef op dinsdag 27 december 2016 @ 19:52:
Vandaag geprobeerd om de verzamelde pcap data uit te lezen en in MySQL op te slaan. Dankzij de goede uitleg in de topicstart had ik dat snel voorelkaar (eerst voor een omvormer). Nu leek het mij handig als meteen na het updaten van de data in MySQL ook een http call gedaan wordt naar mijn Domoticz instance vanuit liveupdate.py. Hier blijkt alleen dat mijn programmeer skills tekort schieten, dus graag wat hulp.

Ik heb al uitgevonden hoe ik met urllib2 een http call kan doen naar Domoticz toe en daar zie ik dan een device bijgewerkt worden. Maar voor mij werkt dit alleen als ik steeds eenzelfde URL gebruik. Als ik variabelen wil gebruiken in de URL dan krijg ik allemaal foutmeldingen over de verkeerde syntax, verkeerde type (string, list, tuple etc). Ik begrijp dat de waarden welke naar MySQL geschreven worden een tuple is, maar hoe kan ik daar een aantal waarden uit destileren? Dat wordt me niet duidelijk. Het eerste deel van de URL is altijd gelijk en het laatste deel bevat de waarden welke variabel zijn. Ik zie voorbeelden dat ik zo'n URL dan samen kan stellen:

code:

        url_data = <lijstje variabelen met puntcomma gescheiden>
        url = "http://<hostname>:8080/json.htm?type=command&param=udevice&idx=123&nvalue=0&svalue=" + url_data
        urllib2.urlopen(url)

Maar ik krijg het maar niet voorelkaar om uit die lijst met waarden een paar specifieke te pakken en als string te presenteren met de naam url_data. Wie kan mij op weg helpen? Het gaat voor nu specifiek om p_active en e_total waarmee de uiteindelijke totale URL er zo ongeveer uit zou komen te zien:

code:

http://<hostname>:8080/json.htm?type=command&param=udevice&idx=123&nvalue=0&svalue=123.456;2345

Kun je hier niet beter een apart script van maken? Mocht je in de toekomst liveupdate.py moeten / willen updaten, dan moet je naar alle delta's tussen jouw aangepaste versie en de nieuwe versie gaan zoeken. Het beste lijkt me een aparte cronjob hiervoor aanmaken, of desnoods vanuit liveupdate.py een ander script aanroepen. In dit laatst genoemde script kun je dan je eigen code stoppen.

[Jerrythafast]

tjanssen schreef op dinsdag 27 december 2016 @ 20:31:
[...]


Kun je hier niet beter een apart script van maken? Mocht je in de toekomst liveupdate.py moeten / willen updaten, dan moet je naar alle delta's tussen jouw aangepaste versie en de nieuwe versie gaan zoeken. Het beste lijkt me een aparte cronjob hiervoor aanmaken, of desnoods vanuit liveupdate.py een ander script aanroepen. In dit laatst genoemde script kun je dan je eigen code stoppen.

Inderdaad, dat is wel een goed punt. Het kan ook in (of in de plaats van) pvo_upload.php bijvoorbeeld:

PHP:

//REPLACE THIS (1 line):
while($row = $q->fetch()){

//WITH THIS (3 lines):
$lastrow = false;
while($row = $q->fetch()){
  $lastrow = $row;

//ADD TO END OF SCRIPT (1 line):
file_get_contents(sprintf("http://<hostname>:8080/json.htm?type=command&param=udevice&idx=123&nvalue=0&svalue=%s;%s", $lastrow["p_active"], $lastrow["se_day"]));

[tsjoender]

Jerrythafast schreef op dinsdag 27 december 2016 @ 20:16:
[...]

Python:

url = "http://<hostname>:8080/json.htm?type=command&param=udevice&idx=123&nvalue=0&svalue=%(p_active)s;%(e_total)s" % telem

Thanks! Nu werkt het. Voor het makkelijker upgraden is het inderdaad beter om het los toe te voegen, maar op deze manier heb ik de data vrijwel meteen als het beschikbaar komt uit de omvormer en hoef ik niet te pollen voor updates. Bovendien zitten er toch al een paar customizations in dat liveupdate.py script (gebruikersnaam, wachtwoord, key) waarmee ik bij een upgrade toch wat dingen over moet nemen en dan is twee regels code ook te overzien. Voor nu is eerst de focus op iets werkends opleveren. Straks komen de puntjes op de i.

UPDATE: Logging naar Domoticz werkt prima. Het systemd start stop script lijkt niet op Ubuntu 14.04 te werken, dus daar moet ik nog een alternatief voor maken, maar daar kom ik wel uit. Ik heb voor beide omvormers een kopie van de se-logger-service.sh en liveupdate.py scripts met daarin de specifieke details voor die omvormer (encryptie key en prefix bijvoorbeeld). Als tcpdump filter gebruik ik "ether host 00:27:02:11:22:33" zodat ik alleen pakketten specifiek van dat MAC adres pak. Het draait op mijn NAS dus als ik grote files heen en weer kopieer, hoeft dat niet allemaal terug te vinden te zijn in een pcap file

Nu nog iets vinden om die mist op te doen trekken en de zon weer zijn werk te laten doen, want de opbrengst is op dit moment karig:

[ Voor 35% gewijzigd door tsjoender op 29-12-2016 10:43 ]

[tinka]

@Jerrythafast, had jij nog plannen om je export to web pagina te delen?
(voor dat ik als totale leek zelf aan de slag ga.)

[Jerrythafast]

tinka schreef op donderdag 5 januari 2017 @ 18:05:
@Jerrythafast, had jij nog plannen om je export to web pagina te delen?
(voor dat ik als totale leek zelf aan de slag ga.)

Ik zou je kunnen sturen wat ik op http://jerweb.nl/pv/ heb draaien, maar wel met een dikke disclaimer dat het echt work in progress is. Zitten ook een aantal dingen hardcoded in (o.a. dagtarget, panelen). Stuur even een DM als je ermee wilt klooien.

[Yoki1985]

@Jerrythafast: Ik heb jouw SeLogger draaien bij mij nu. Ik krijg data te zien in mijn mysql-database.
Echter als ik de query in het php bestand uitvoer dan krijg ik 0 rijen terug, hierdoor wordt er dus ook niets gestuurd naar pvoutput.

Ik heb het probleem kunnen traceren tot het volgende stuk:

MySQL:

SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(pvo_last_live, "%Y%m%d")) FROM live_update

deze retourneerd "NULL". Dit komt omdat pvo_last_live altijd op 0 blijft staan volgens mij.


Enig idee wat er mis is?

[Pietjebel10]

Ik heb dat even vergeleken met mijn db maar er staat gewoon een timestamp ingevuld dus daar gaat wat niet lekker. even terugkijken wanneer en waar hij die data logt.

pvo_last_live => 1483956311

Yoki1985 schreef op maandag 9 januari 2017 @ 10:21:
@Jerrythafast: Ik heb jouw SeLogger draaien bij mij nu. Ik krijg data te zien in mijn mysql-database.
Echter als ik de query in het php bestand uitvoer dan krijg ik 0 rijen terug, hierdoor wordt er dus ook niets gestuurd naar pvoutput.

Ik heb het probleem kunnen traceren tot het volgende stuk:

MySQL:

SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(pvo_last_live, "%Y%m%d")) FROM live_update

deze retourneerd "NULL". Dit komt omdat pvo_last_live altijd op 0 blijft staan volgens mij.
[afbeelding]

Enig idee wat er mis is?

[Yoki1985]

Pietjebel10 schreef op maandag 9 januari 2017 @ 11:09:
Ik heb dat even vergeleken met mijn db maar er staat gewoon een timestamp ingevuld dus daar gaat wat niet lekker. even terugkijken wanneer en waar hij die data logt.

pvo_last_live => 1483956311


[...]

Ik heb nog wat verder gezocht en als ik de 1ste keer zelf een datum invul dan werkt alles naar behoren.
Mss in de PHP file nog een check inbouwen dat als pvo_last_live 0 is dat dan alles geupload word.

[Yoki1985]

Jerrythafast schreef op donderdag 5 januari 2017 @ 20:55:
[...]

Ik zou je kunnen sturen wat ik op http://jerweb.nl/pv/ heb draaien, maar wel met een dikke disclaimer dat het echt work in progress is. Zitten ook een aantal dingen hardcoded in (o.a. dagtarget, panelen). Stuur even een DM als je ermee wilt klooien.

PS: je mag mij je WIP ook eens doorsturen als je wil. Als ik wat tijd vind zal ik ook eens zien wat ik ermee kan doen.

[Pietjebel10]

Ik heb ook een eigen ontwerp draaien met allerlei grafiekjes etc heb hem al gedeeld met Eagle denk wanneer we samen eens gaan stoeien en de "knowhow" gaan samenbrengen we een heel eind komen.
Mocht je interesse hebben stuur dan even een pm

Yoki1985 schreef op maandag 9 januari 2017 @ 12:01:
[...]


PS: je mag mij je WIP ook eens doorsturen als je wil. Als ik wat tijd vind zal ik ook eens zien wat ik ermee kan doen.

[Jerrythafast]

Yoki1985 schreef op maandag 9 januari 2017 @ 10:21:
@Jerrythafast: Ik heb jouw SeLogger draaien bij mij nu. Ik krijg data te zien in mijn mysql-database.
Echter als ik de query in het php bestand uitvoer dan krijg ik 0 rijen terug, hierdoor wordt er dus ook niets gestuurd naar pvoutput.

Ik heb het probleem kunnen traceren tot het volgende stuk:

MySQL:

SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(pvo_last_live, "%Y%m%d")) FROM live_update

deze retourneerd "NULL". Dit komt omdat pvo_last_live altijd op 0 blijft staan volgens mij.
[afbeelding]

Enig idee wat er mis is?

Thanks! Is jouw tijdzone toevallig ingesteld op iets ten westen van GMT?

Here's the fix:

MySQL:

SELECT IFNULL(UNIX_TIMESTAMP(FROM_UNIXTIME(pvo_last_live, "%Y%m%d")), 0) FROM live_update

Wat betreft de logging pagina, ik overweeg om hem op GitHub te gooien. Dan kunnen we er met zijn allen aan rommelen Het enige nare is dat mijn panelen en maandtarget er hardcoded in staan, maar daar valt wel een tijdelijke oplossing voor te bedenken in de vorm van een kleine config file.

[ Voor 14% gewijzigd door Jerrythafast op 09-01-2017 21:06 ]

[Aegle]

Ik ben benieuwd.. . In mijn spaarzaam vrije tijd ben ik met de code van Pietjebel10 aan het stoeien. Echt leuk!
Jerry, jou code om de paneel kleur afhankelijk te laten zijn van de opbrengst werkt bij mij nog niet. Ik krijg er nog geen vinger achter wat ik verkeerd doe. Zoals ik je al mailde, de variabele $color is en blijft FF4600 (= RGB255,70,0). Overigens wel heel slim verzonnen code. T.z.t. nog even mee verder stoeien. Inmiddels heeft Pietjebel10 een eenvoudigere versie geschreven. Die werkt prima.

[Yoki1985]

Jerrythafast schreef op maandag 9 januari 2017 @ 21:00:
[...]
Wat betreft de logging pagina, ik overweeg om hem op GitHub te gooien. Dan kunnen we er met zijn allen aan rommelen Het enige nare is dat mijn panelen en maandtarget er hardcoded in staan, maar daar valt wel een tijdelijke oplossing voor te bedenken in de vorm van een kleine config file.

Count me in! Als je de code op github geplaatst hebt mag je mij de link eens sturen. Eens zien wat ik in mijn vrije tijd kan doen

[arnnold]

Beste mensen,
Ik heb een Solaredge installatie van 18 panelen in één string. Mijn dak ligt ongunstig voor de beste opbrengst. West gericht.
Vraag aan jullie:
Als ik de huidige string ombouw naar 2 strings van 9 panelen. Zal dit een rendement verbetering geven?