[SolarEdge] Omvormers en optimizers zelf monitoren

[Jerrythafast]

1. Inleiding

Omvormers van SolarEdge hebben de speciale eigenschap dat alle panelen van bijbehorende optimizers worden voorzien. Dit brengt de mogelijkheid met zich mee de opbrengst per paneel bij te houden. SolarEdge biedt haar eigen monitoring portaal om de opbrengst bij te houden. Hierop is de actuele situatie per paneel, per string en per omvormer in te zien. Bovendien zijn er grafieken beschikbaar van spanning, stroom, energie en vermogen van de omvormer en de panelen. Voor programmeurs is er de Monitoring API, waarmee de data van de omvormer (maar niet van de panelen) programmatisch ter beschikking wordt gesteld. De Monitoring API maakt het ook mogelijk om de data van de SolarEdge website rechtstreeks naar PVOutput.org te laten doorsturen.

Er zijn een aantal beperkingen aan de SolarEdge website, de Monitoring API en de koppeling met PVOutput. Zo is informatie per paneel in het geheel niet beschikbaar via de Monitoring API. Op de monitoring website kun je wel gedetailleerde informatie over de panelen krijgen, maar alleen op de grafiekenpagina die niet werkt op smartphones en tablets (en die naar mijn mening sowieso maar matig van kwaliteit is). De koppeling met PVOutput laat ook te wensen over, deze heeft last van herhaaldelijk afronden en het verkeerd toepassen van de 'active power' waarde van de omvormer, waardoor de cijfers op PVOutput behoorlijk afwijken van wat op de SolarEdge monitoring website wordt vermeld.

Om deze beperkingen en tekortkomingen te overwinnen wil de echte Tweaker natuurlijk best de handen uit de mouwen steken en een eigen logging database en website opzetten. Maar dat blijkt met SolarEdge omvormers nog niet zo eenvoudig. Daarom is dit topic er nu!

Tᴡᴇᴇ ʙᴇʟᴀɴɢʀɪᴊᴋᴇ ᴏᴘᴍᴇʀᴋɪɴɢᴇɴ! Het stappenplan in deze post is van toepassing op omvormers met display en zonder SetApp. Dat is CPU versie 1.x, 2.x of 3.x. Heb je een omvormer met SetApp (CPU versie 4.x), dan werkt onderstaande dus NIET. Kijk dan even naar dit andere topic voor een mogelijke workaround. Als je binnenkort een SolarEdge omvormer (met display en zonder SetApp dus) in gebruik neemt en deze met de in dit topic besproken methodes wilt loggen, lees de startpost van dit topic dan goed door voordat je de omvormer aan het internet hangt. Al lezende wordt wel duidelijk waarom. Trek die netwerkkabel er snel even uit!

1.1 Wat kan ik hiermee?

Met dit project (in de staat waarin het zich nu bevindt) kun je het volgende:

• Telemetriedata (van de omvormer en de optimizers) die een SolarEdge omvormer naar de monitoring portal stuurt onderscheppen en opslaan in een MySQL database
• De data van de omvormer automatisch laten uploaden naar PVOutput

Om de data mooi inzichtelijk te maken zou je een leuke website of app kunnen bouwen die uit deze database kan putten, maar dat is een afzonderlijk vervolgproject. @andrerij heeft in deze post zijn monitoring website ter beschikking gesteld. Zelf heb ik intussen ook wat in elkaar gezet, maar dit is nog niet rijp genoeg om te delen. Maar vanwege bovenstaande waarschuwing is het belangrijk dat je op tijd de logging software hebt ingesteld: je kunt het beste vóórdat de omvormer het internet op gaat al met dit project begonnen zijn. Laat je dus niet afschrikken door het gebrek aan een mooie website of app: deze komt wel, zorg nu eerst maar dat je die omvormer kunt afluisteren!

2. Afluisteren versus uitlezen

Er zijn grofweg twee manieren waarmee SolarEdge omvormers hun data beschikbaar kunnen stellen: via een seriële verbinding (RS-232 of RS-485) of via het internet. De keuze hiertussen kan gemaakt worden in het instellingenmenu van de omvormer. Het moge duidelijk zijn dat de meeste SolarEdge omvormers aan het internet worden gehangen, zodat gebruik gemaakt kan worden van de SolarEdge monitoring portal. De in dit topic beschreven methode is bedoeld voor omvormers die op het internet worden aangesloten. De omvormer blijft gewoon met de monitoring portal verbonden, maar de verbinding tussen de omvormer en de servers van SolarEdge zal worden afgeluisterd. De data die de omvormer (elke 5 minuten) verzendt naar de monitoring website kan zo worden onderschept en opgeslagen zodat het in een eigen monitoring website getoond en naar hartenlust geanalyseerd kan worden. Als bonus krijg je zelfs data die op de monitoring website niet te vinden is, zoals de temperatuur van de optimizers!

De verbinding met de servers van SolarEdge is sinds december 2015 beveiligd met AES-128 encryptie. Deze versleuteling is (voor zover bekend) onkraakbaar, dus een met AES-128 beveiligde verbinding kan alleen afgeluisterd worden als je de gebruikte beveiligingssleutel weet. SolarEdge heeft de versleuteling van de verbinding toegevoegd aan recente firmware (vermoedelijk vanaf CPU versie 3.x), maar deze staat bij nieuw geïnstalleerde omvormers standaard uit. Ergens in de eerste 48 uur dat de omvormer contact heeft met de servers van SolarEdge wordt de beveiligingssleutel uitgewisseld en direct daarna wordt de versleuteling aangezet. Het is dus belangrijk dat de verbinding al afgeluisterd wordt wanneer de versleuteling nog niet aan staat!

In het geval dat je de beveiligingssleutel niet hebt weten te onderscheppen (bijvoorbeeld omdat je omvormer er al een tijdje hangt) is het nog mogelijk om deze met een RS-232 verbinding uit te lezen. Hiervoor zul je wel de kap van de omvormer moeten openen, niet iedereen ziet dat zitten. Doe dit alleen als je weet waar je mee bezig bent en zorg voor je eigen veiligheid dat de DC schakelaar aan de onderkant op OFF staat. Als alternatief kun je een 'factory reset' van de omvormer (een optie in het service menu) uitvoeren om de encryptie weer uit te zetten. Let wel: na een factory reset staat de productieteller weer op nul en moet de omvormer opnieuw gepaird worden met de optimizers.

Wellicht dat dit topic in de toekomst wordt uitgebreid met informatie voor het rechtstreeks uitlezen van de omvormer via RS-232 (eventueel over USB) of RS-485. Het voordeel van uitlezen via een seriële verbinding is dat de uitleesfrequentie kan worden verhoogd en er geen gedoe is met encryptie. Het nadeel is dat je de monitoring website niet meer kunt gebruiken en je dus volledig zelf verantwoordelijk bent voor de monitoring.

3. Benodigdheden

Om de verbinding tussen de omvormer en de servers van SolarEdge te kunnen afluisteren en de data op te slaan heb je wel wat spullen nodig. Vooral de opzet van het netwerk is van belang: als je je omvormer en je computer aansluit op een normale switch of router neemt het verkeer gewoon de kortste weg naar buiten en kan de computer de omvormer dus niet afluisteren. Zorg dat je het volgende in huis hebt:

• Een computer die altijd aan staat (mag een server, nas of Raspberry Pi zijn) en waar je MySQL, tcpdump en Python3 scripts op kunt draaien. Als je nog geen spul 24/7 hebt draaien kan ik een pricewatch: Raspberry Pi 3 Model B 1GB aanbevelen. Vanaf nu heet deze computer de logger.
• Een domme ouderwetse ethernet hub (dus géén switch of router) óf een switch met 'port mirroring' functie óf een tweede netwerkaansluiting op je logger. Veel mensen hebben geen van de drie opties in huis. Als je ook nog geen logger had is dit een extra reden voor de Raspberry Pi 3 Model B: die heeft een ethernetpoort én WiFi (dus twee netwerkverbindingen). Als je al een logger hebt kun je eenvoudig een tweede netwerkpoort toevoegen met een USB-naar-Ethernet dongle.

Ik ga er in dit geheel even van uit dat de logger op een Linux distributie draait die systemd gebruikt (ik heb het zelf op Ubuntu 16.04 draaien). Als iemand het op Windows wil installeren moeten we daar gaandeweg een handleiding voor schrijven, wat dan weer hier aan de topicstart kan worden toegevoegd. Waarschijnlijk is het ook mogelijk om het op sommige NAS'en te installeren, maar ook dit zal eerst maatwerk worden voordat we het in de topicstart kunnen zetten.

4. Het netwerk instellen

Het installeren van de logger komt in de volgende sectie aan bod. Eerst moeten we het netwerk op orde krijgen. Ik raad je aan om het eerst te proberen met een andere computer in de plaats van de omvormer zodat je zonder dataverlies kunt checken of de verbinding werkt en of je met tcpdump op de logger het verkeer van de computer kunt zien. Sluit i.v.m. de encryptie de omvormer pas aan op het internet als je zeker weet dat de logger kan meeluisteren!

• Met een domme ethernet hub: Sluit drie netwerkkabels op de hub aan, één naar de omvormer, één naar de logger en één naar de rest van je netwerk voor de internettoegang. De omvormer en de logger ontvangen nu elkaars verkeer. Zo kan de logger dus meeluisteren met de communicatie van de omvormer.
• Met een switch met 'port mirroring' functie: Sluit de logger aan op de 'mirror port' (andere termen: 'analysis port', 'monitoring port'). Op de 'gewone' netwerkpoorten sluit je de kabel naar de omvormer en de kabel naar de rest van het netwerk aan. Stel de switch zo in dat de data op de poort waar de omvormer aan hangt wordt gemirrord naar de mirror port.
• Met twee netwerkpoorten op de logger: Sluit de omvormer aan op de ene netwerkpoort en verbind de andere met de rest van je netwerk. Stel een netwerkbrug in tussen de twee netwerkpoorten (zie sectie 4.1). De omvormer maakt dan verbinding met het netwerk via de logger, wat de logger natuurlijk in staat stelt om hem af te luisteren.
• Met WiFi en een netwerkpoort op de logger: Bijvoorbeeld in het geval van de Raspberry Pi 3 Model B heb je te maken met één ethernetpoort en een WiFi-verbinding, wat de configuratie wat complexer maakt. Als je omvormer een WiFi-module heeft kun je het beste sectie 4.1 volgen. Als je omvormer geen WiFi heeft ga je naar sectie 4.2.

4.1 Omvormer ━┫ kabel of WiFi ┣━ Logger ━┫ kabel ┣━ Internet

Een logger met twee netwerkverbindingen die bekabeld aan het internet hangt is redelijk eenvoudig op te zetten. Met de volgende netwerkconfiguratie kun je twee ethernetpoorten (eth0 en eth1) bridgen. Hiervoor moet bridge-utils geïnstalleerd zijn. Sla deze code op in /etc/network/interfaces. Na een reboot wordt de configuratie actief.

code:

## /etc/network/interfaces
auto lo br0
iface lo inet loopback
iface eth0 inet manual
iface eth1 inet manual

iface br0 inet static
    bridge_ports eth0 eth1
        address 192.168.178.2
        broadcast 192.168.178.255
        netmask 255.255.255.0
        gateway 192.168.178.1
        dns-nameservers 8.8.8.8 8.8.4.4

Pas de IP-adressen in dit voorbeeld eventueel aan zodat ze op jouw netwerk zijn afgestemd. In het voorbeeld is 192.168.178.2 het adres van de logger en 192.168.178.1 het adres van het modem.

Heb je een omvormer met WiFi-module en je logger heeft ook WiFi, dan kun je met 'hostapd' de logger een WiFi-netwerk laten uitzenden. Die kun je dan op dezelfde manier bridgen (verander 'eth1' in 'wlan0' in de code hierboven). Het WiFi netwerk waar de omvormer mee verbindt wordt gebridged met de netwerkpoort die de verbinding naar buiten levert. Op die manier stel je de logger in feite in als draadloos toegangspunt (AP).

Om de logger te testen sluit je even een computer/laptop aan in plaats van de omvormer en draai je het volgende commando op de logger (verander 'eth1' naar 'wlan0' als de testcomputer via WiFi verbinding maakt):

user@logger$  sudo tcpdump -c 25 -i eth1 tcp

Op de testcomputer open je dan een website, waarna je op de logger output moet zien verschijnen. Als dat is gelukt kun je verder bij Sectie 5.

4.2 Omvormer ━┫ kabel ┣━ Logger ━┫ WiFi ┣━ Internet

De meeste mensen zullen geen WiFi module bij hun SolarEdge omvormer hebben. Met een logger met WiFi zoals de Raspberry Pi 3 Model B kom je dan hier op uit: we gebruiken de WiFi om de logger met het internet te verbinden, zodat de omvormer met de netwerkkabel aan de logger kan worden gehangen. We kunnen dan geen netwerkbrug maken zoals bij sectie 4.1; in plaats daarvan stellen we de logger in als router. Dat gaat als volgt.

Installeer 'wpasupplicant' als je WiFi-netwerk met WPA Personal is beveiligd (99% kans...). Je moet je WiFi-wachtwoord omzetten in een 'PSK' (Pre-Shared Key) met het volgende commando:

user@logger$  wpa_passphrase Naam-Van-Jouw-WiFi-Netwerk JouwWachtwoordHier123!

Je krijgt dan als output o.a. een regel die begint met 'psk=' gevolgd door een reeks letters en cijfers. Die letters en cijfers heb je nodig in de volgende stap.

Sla de volgende code op in /etc/network/interfaces en vul hierin de naam van jouw WiFi-netwerk en je PSK in. Zorg ook dat de IP-adressen die onder 'wlan0' staan genoemd kloppen. 192.168.178.2 is in dit voorbeeld het IP-adres van de logger, 192.168.178.1 het IP-adres van je modem.

code:

## /etc/network/interfaces
auto lo
iface lo inet loopback

# Instellingen voor de Wi-Fi verbinding:
auto wlan0
iface wlan0 inet static
    address 192.168.178.2
    broadcast 192.168.178.255
    netmask 255.255.255.0
    gateway 192.168.178.1
    dns-nameservers 8.8.8.8 8.8.4.4
    wpa-ssid Naam-Van-Jouw-WiFi-Netwerk
    wpa-psk a897a679b6b987a665a765c786a8769f876a7856754765f67097d0987a96787d

# Instellingen voor de bedrade verbinding naar de omvormer (deze hoeven niet veranderd te worden):
auto eth0
iface eth0 inet static
    address 192.168.179.1
    network 192.168.179.0
    broadcast 192.168.179.255
    netmask 255.255.255.0

Om de omvormer een IP-adres te geven moeten we een DHCP-server instellen. Installeer 'isc-dhcp-server' om te beginnen. Open dan het bestand /etc/dhcp/dhcpd.conf en zet het volgende erin:

code:

## /etc/dhcp/dhcpd.conf
option domain-name "example.com";
option domain-name-servers 8.8.8.8, 8.8.4.4;

default-lease-time 600;
max-lease-time 7200;

option subnet-mask 255.255.255.0;
option broadcast-address 192.168.179.255;
option routers 192.168.179.1;

subnet 192.168.179.0 netmask 255.255.255.0 {
  range 192.168.179.10 192.168.179.100;
}

Met alleen een IP-adres ben je er nog niet, de omvormer moet ook verbinding kunnen maken met het internet. Hiervoor is Network Address Translation (NAT) nodig, wat we instellen met 'iptables'. We stellen hiermee de logger in als router. Sla het onderstaande script op als /opt/scripts/se-nat.sh:

Bash:

## /opt/scripts/se-nat.sh
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="wlan0"
INTIF="eth0"
echo "   External Interface:  $EXTIF"
echo "   Internal Interface:  $INTIF"

#== Uncomment the lines below if Modbus/TCP is used =======================
#== MODBUS SETUP ==========================================================
#IP="192.168.179.10" # This is the SolarEdge inverter IP connected on $INTIF
#MBPORT="502" # This is the modbus communications port do not change
#MODBUS="$IP:$MBPORT"
#echo "   ==============================="
#echo "   Modbus communication is used"
#echo "   SolarEdge Inverter IP:  $MODBUS"
#echo "   ==============================="
#== END MODBUS SETUP ======================================================
#==========================================================================

echo -en "   loading modules: "
echo "  - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e "   Done loading modules.\n"
echo "   Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "   Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo "   Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
#== Uncomment the lines below if Modbus/TCP is used =======================
#-A PREROUTING -i "$EXTIF" -p tcp --dport "$MBPORT" -j DNAT --to "$MODBUS"
#-A PREROUTING -i "$INTIF" -p tcp --dport "$MBPORT" -j DNAT --to "$MODBUS"
#== END MODBUS ============================================================
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
#== Uncomment the line below if Modbus/TCP is used ========================
#-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate NEW -p tcp --dport "$MBPORT" -j ACCEPT
#== END MODBUS ============================================================
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"

(Mocht je de omvormer ook nog via Modbus/TCP willen uitlezen, dan moet je de gemarkeerde regels even uncommenten en het juiste IP-adres van de omvormer invullen. Met dank aan @Cabbie_86 voor deze bijdrage!)

Maak het script uitvoerbaar en test het ook even:

user@logger$  chmod a+x se-nat.sh
user@logger$  sudo sh se-nat.sh

Als hier geen errors uit naar voren komen werkt het.

Dit script moet automatisch worden uitgevoerd bij het opstarten van de logger. Dit kan door het bestand /etc/systemd/system/se-nat.service te maken, met de volgende inhoud:

code:

## /etc/systemd/system/se-nat.service
[Unit]
Description=This service sets up NAT for the SE side
After=network.target

[Service]
ExecStart=/bin/bash /opt/scripts/se-nat.sh
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process

[Install]
WantedBy=multi-user.target

Vervolgens activeer je de service met het volgende commando:

user@logger$  sudo systemctl enable se-nat.service
user@logger$  sudo systemctl start se-nat.service

Om de logger te testen sluit je even een computer/laptop aan in plaats van de omvormer en draai je het volgende commando op de logger:

user@logger$  sudo tcpdump -c 25 -i eth0 tcp

Op de testcomputer open je dan een website, waarna je op de logger output moet zien verschijnen.

5. De logging software instellen

Nu het netwerk zo is ingesteld dat de omvormer kan worden afgeluisterd, kan begonnen worden met het instellen van de logging software. Hiervoor zijn grofweg drie opties: het project van user jbuehl op GitHub, mijn eigen solaredge-logger project, of het maken van een eigen brouwsel. Vanzelfsprekend zal ik hier de installatie van solaredge-logger bespreken, omdat ik daar het meest bekend mee ben.

Solaredge-logger is als volgt opgebouwd:

• Met behulp van 'tcpdump' wordt de netwerkverbinding van de omvormer afgeluisterd, alle TCP communicatie wordt opgeslagen in PCAP bestanden. De solaredge-logger service wordt elke nacht herstart, zodat er van elke dag een apart PCAP bestand wordt gemaakt.
• Het PCAP bestand wordt tegelijkertijd meegelezen door een script dat de gewenste data hieruit destilleert en opslaat in een eenvoudige MySQL database met een tabel voor omvormer data en een tabel voor optimizer data.
• Een stand-alone PHP script dat de data van de omvormer-tabel uploadt naar PVOutput, wordt d.m.v. een cronjob elke 2 minuten uitgevoerd.
• Los hiervan worden er twee scripts meegeleverd waarmee de beveiligingssleutel van de omvormer verkregen kan worden.

Volg onderstaande stappen om solaredge-logger te installeren:

1. Om te beginnen kan de laatste versie gedownload worden van jerweb.nl/downloads/solaredge-logger. Het project staat ook op GitHub.
2. Zorg dat de volgende pakketten zijn geïnstalleerd: mysql-server, python3-mysqldb, python3-crypto. Als je ook naar PVOutput wilt uploaden, komen daar nog bij: php-cli, php-mysql, php-curl. (Mocht je de melding krijgen dat deze php-pakketten niet bestaan, probeer dan php7- of php5- als prefix.)
3. Maak een MySQL database aan met behulp van de SQL statements in 'database.txt'.
4. Maak de directory '/opt/se-logger' en zet de bestanden 'liveupdate.py', 'pvo-upload.php' en 'se-logger-service.sh' erin.
5. Open 'liveupdate.py' en vul de gebruikersnaam en het wachtwoord van de MySQL database in in het SETTINGS gedeelte bovenaan. Je vindt hier ook de plaats waar de beveiligingssleutel van de omvormer ingevuld moet worden. Als je omvormer nog niet aan het internet is verbonden, of CPU versie lager dan 3.x heeft, heb je de sleutel nog niet nodig. In sectie 6.1 staat meer informatie over hoe je deze kunt achterhalen wanneer je merkt dat er opeens geen data meer de database in gaat. Heeft je omvormer CPU versie 3.x of hoger én hangt hij al langer dan een paar uurtjes aan het internet? Kijk dan even naar sectie 6.2.
6. (Optioneel, voor PVOutput updates) Open 'pvo-upload.php' en vul ook hierin de gebruikersnaam en het wachtwoord van de MySQL database in in het SETTINGS gedeelte bovenaan. Verder vul je hier ook de PVOutput API key en het System ID in, welke je kunt vinden op de Account Settings pagina van PVOutput. (Let op: Als je niet aan PVOutput hebt gedoneerd is de hoeveelheid status updates die tegelijk verzonden kunnen worden gelimiteerd tot 30. In dat geval moet je in pvo-upload.php de 'LIMIT 100' aanpassen naar 'LIMIT 30' om problemen te voorkomen.)
7. Open 'se-logger-service.sh' en zorg dat in het SETTINGS gedeelte 'interface' verwijst naar de netwerkpoort waarop de omvormer is aangesloten. Als je sectie 4.1 hebt gevolgd is het waarschijnlijk 'eth1' of 'wlan0'; als je sectie 4.2 hebt gevolgd is het 'eth0'.
8. Zet het bestand 'se-logger.service' in de '/etc/systemd/system' directory. Draai je Raspbian? Dan moet je de 'KillMode=' regel aanpassen naar 'KillMode=control-group'. Als je sectie 4.2 had gevolgd (logger via WiFi verbonden met het internet) is het aan te raden om /etc/systemd/system/se-nat.service aan te passen en de 'After=' regel te veranderen naar 'After=network.target se-logger.service'. Dit zorgt ervoor dat de omvormer pas toegang krijgt tot internet als de logger service draait.
9. Vervolgens activeer je de service met het volgende commando:
   

   user@logger$  sudo systemctl enable se-logger.service
   user@logger$  sudo systemctl start se-logger.service
   

10. We stellen cronjobs in die de service elke nacht herstarten en elke 2 minuten een update sturen naar PVOutput. Geef hiervoor het commando 'sudo crontab -e' en kopieer dan de inhoud van 'crontab.txt' welke bij de se-logger download inbegrepen was naar jouw crontab. (Als je geen PVOutput uploads wilt, moet je de regel waar 'pvo-upload.php' in staat weglaten.)

Geef de logger eventueel even een reboot. Hierna zou de logging software moeten draaien. Dit is te controleren door te kijken in /opt/se-logger. Hierin vind je de volgende output bestanden:

• tcpdump.log: bevat de 'error' output van tcpdump. Hier hoort één regel in te staan met iets dat lijkt op: "tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes". Als er meer in staat is er mogelijk iets mis, of is de se-logger service gestopt.
• liveupdate.log: bevat de 'error' output van liveupdate.py (het belangrijkste script van se-logger). Wat je hier NIET in wilt lezen is "End of file. Shutting down.", wat betekent dat de service is gestopt. Als je hier veel "Warning! Skipping (getal) mysterious bytes!" in tegen komt betekent dit vrijwel zeker dat je omvormer encryptie gebruikt en dat in het SETTINGS gedeelte van liveupdate.py niet de juiste sleutel is ingevuld. Kijk dan even in sectie 6.1.
• solarege-20160924003000.pcap: bevat alle onderschepte communicatie van de omvormer. De getallen in de bestandsnaam geven de datum en tijd (jaar, maand, dag, uur, minuut, seconde) waarop de se-logger service werd gestart. Doordat de service elke nacht wordt herstart krijg je voor elke dag een aparte capture file. Je kunt deze bestanden openen in een programma als Wireshark. Tip: bewaar deze bestanden als back-up! Hierin zit alle data. Zelfs als je je database verliest kun je hem met deze bestanden weer helemaal vullen.

Wanneer je met een testcomputer in de plaats van de omvormer probeert op het internet te surfen zou je de 'solaredge-xxxx.pcap' file moeten zien groeien. Als dit werkt kun je (eindelijk!) de omvormer aansluiten.

6. De encryptiesleutel achterhalen

Bij solaredge-logger worden twee kleine Python scripts meegeleverd die helpen de encryptiesleutel te achterhalen. Net zoals solaredge-logger zelf, werken deze scripts met Python 3 en dus niet met Python 2.

6.1 De encryptiesleutel achterhalen uit PCAP capture bestanden

Zoals in sectie 2 al is uitgelegd, staat bij nieuw geïnstalleerde omvormers de encryptie standaard uit. Ergens in de eerste 48 uur dat de omvormer contact heeft met de servers van SolarEdge wordt de beveiligingssleutel uitgewisseld en direct daarna wordt de versleuteling aangezet. Als je solaredge-logger hebt opgezet vóórdat de encryptie werd aangezet, zit je encryptiesleutel ergens in de 'solaredge-xxx.pcap' bestanden in de /opt/se-logger directory verscholen. Bij solaredge-logger wordt een script 'find-key-in-pcap.py' meegeleverd, welke je kunt gebruiken om de sleutel op te zoeken in de PCAP bestanden die de se-logger service maakt. Dit kan met het commando:

user@logger$  python3 find-key-in-pcap.py /opt/se-logger/*.pcap

Als het script met succes je beveiligingssleutel weet te vinden wordt hij netjes getoond zodat je hem in liveupdate.py kunt zetten. Ga daarna te werk volgens sectie 6.3.

Als de sleutel niet kan worden gevonden, zul je waarschijnlijk via RS-232 de sleutel van de omvormer moeten opvragen (sectie 6.2). Ook kun je een 'factory reset' van de omvormer (een optie in het service menu) uitvoeren om de encryptie weer uit te zetten (dank @xces voor het proberen). Let wel: na een factory reset staat de productieteller weer op nul en moet de omvormer opnieuw gepaird worden met de optimizers.

6.2 De encryptiesleutel achterhalen via RS-232

Als je omvormer al encryptie gebruikte voordat je se-logger had ingesteld, of als om wat voor reden dan ook de encryptiesleutel toch niet in je PCAP bestanden terecht is gekomen, blijft er altijd nog een plan B. Bij solaredge-logger zit ook een script 'get-key-by-rs232.py', waarmee de sleutel rechtstreeks uit de omvormer uitgelezen kan worden. Hiervoor moet je een computer (dit hoeft niet per se de logger te zijn en kan ook prima op Windows) op de RS-232- of USB-aansluiting die aan de binnenkant van de omvormer zit aansluiten. In het SETTINGS gedeelte bovenaan het script vul je de naam van de seriële poort en (de eerste 8 tekens van) het serienummer van je omvormer in. Vervolgens voer je het script uit (met Python 3) en vertelt het je de encryptiesleutel. De werking van dit script is praktisch gegarandeerd (het is echt een heel simpel script), maar het aansluiten van de omvormer vereist wat extra kennis en bovendien moet hiervoor de kap van de omvormer verwijderd worden, wat sommigen als 'over de grens' kunnen ervaren. Probeer deze situatie dan liever te mijden als het nog niet te laat is!

6.3 De database bijwerken nadat je de encryptiesleutel hebt ingevoerd

Als de solaredge-logger service heeft staan draaien zonder dat je een encryptiesleutel had ingevuld in het SETTINGS gedeelte van 'liveupdate.py' terwijl de omvormer versleutelde gegevens verstuurde, is de versleutelde data niet in de MySQL database terecht gekomen. Met het volgende eenvoudige stappenplan kun je de database weer op orde maken.

• Trek de netwerkkabel van de omvormer eruit om dataverlies te voorkomen
• Stop de se-logger service met het commando:
  

  user@logger$  sudo service se-logger stop

• Je kunt nu de database bijwerken met de versleutelde gegevens door het commando:
  

  user@logger$  python3 /opt/se-logger/liveupdate.py /opt/se-logger/*.pcap

  Dit kan in het begin heel wat 'duplicate key' warnings geven. Als het goed is eindigt dat met een bericht "Setting new 0503 key" waarna het script in relatieve stilte verder gaat. Er moet in ieder geval geen "Warning! Skipping (getal) mysterious bytes!" meer komen.
• Als je PVOutput uploads had aan staan kun je maximaal 2 minuten later zien of de aanpassing is gelukt. Anders kun je eventueel in de database kijken of de data van vandaag er nu in staat.
• Wanneer je hebt geconcludeerd dat dat goed is gegaan, start je de se-logger service weer met het commando:
  

  user@logger$  sudo service se-logger start

7. Tot slot

Zoals je waarschijnlijk wel hebt kunnen merken is het niet zo eenvoudig om een SolarEdge omvormer te loggen. Voel je vrij om in dit topic om hulp te vragen. Er zullen vast delen van deze startpost zijn die duidelijker moeten. Zeker voor mensen zonder ervaring met Linux zal het pittig zijn, maar samen kunnen we vast wel een mooi overzicht van leesvoer maken om de in de startpost gebruikte Linuxdingen toe te lichten. Wat dat betreft is dit topic net zo "under construction" als het project zelf!

Met dank aan Tweaker Aegle voor het meetesten van deze software en GitHub-gebruikers jbuehl en Whizkidzz voor hun onmisbare werk om het SolarEdge protocol te ontcijferen.

[Voor 204% gewijzigd door Jerrythafast op 27-05-2020 07:13]

[Jerrythafast]

Je eigen monitoring website

@andrerij heeft op basis van het solaredge-logger project een monitoring website gebouwd. Hij heeft zijn project gedeeld in deze post, inclusief instructies voor hoe je het voor je eigen SolarEdge systeem kunt installeren.




Heb jij ook een monitoring website gebouwd die je hier wilt delen? Post 'm gerust in dit topic!

[Voor 113% gewijzigd door Jerrythafast op 11-03-2018 08:24]

[Jerrythafast]

In deze post zal ik vragen uit dit topic die regelmatig terugkomen proberen te verzamelen, zodat de antwoorden in het vervolg gemakkelijker terug te vinden zijn.

Veelgestelde vragen

De waarde voor 'e_day' in de database klopt niet
Dat klopt, dit is een bugje in de firmware van SolarEdge. Je kunt de correcte waarde zelf berekenen door alle 'de_day' waardes van die dag tot op dat moment bij elkaar op te tellen. De monitoring website van SolarEdge lijkt het ook op die manier te doen.

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

Ik kan de encryptiesleutel niet uitlezen met get-key-by-rs232.py
Krijg je de foutmelding "TypeError: unsupported operand type(s) for ^: 'int' and 'str'"? Dan draai je het script met de verkeerde Python-versie: je moet het runnen met Python 3, niet Python 2.

Mijn database heeft er even uit gelegen en nu mis ik data in de database
Je kunt de stappen in sectie 6.3 in de openingspost volgen om ervoor te zorgen dat alle data die in .pcap bestanden ligt opgeslagen in de database wordt geplaatst. Dus zolang je van de bewuste tijdspanne nog wel de .pcap bestanden hebt, kun je altijd de database weer compleet maken. Vanwege de gebruikte encryptie is het soms nodig om het .pcap bestand van de dag ervoor ook mee te nemen (de benodigde encryptiesleutel kan in dat bestand staan). Ook vanwege de encryptie kan het nodig zijn om de omvormer pas na een kwartier weer met de netwerkkabel te verbinden (hij zal dan een nieuwe sleutel beginnen gebruiken die se-logger gelijk oppikt).
Als je de PVOutput upload gebruikt, kijk dan ook even naar het volgende...

Er mist data op PVOutput die wel in mijn database staat
Heb je (al dan niet per ongeluk) data van PVOutput verwijderd, of is er door een andere oorzaak een gat in de gegevens ontstaan, dan kun je het PVOutput upload script een stukje terug in de tijd zetten om deze data opnieuw te uploaden (mits het wel in je database staat natuurlijk). Log hiervoor in op de database en draai de volgende SQL-query (waarbij je het tijdstip liefst iets vóór het gat in de data zet, bijvoorbeeld het begin van de betreffende dag):

MySQL:

UPDATE live_update SET pvo_last_live = UNIX_TIMESTAMP("2019-04-29 04:00:00");

Hierna gaat het upload script vanzelf verder vanaf het aangegeven tijdstip.

[Voor 178% gewijzigd door Jerrythafast op 10-05-2020 17:19]

[JeroenTheStig]

Complimenten voor de TS! Ik zal binnenkort kijken of ik met bovenstaande omschrijving de key kan achterhalen. Dit kan ook een leuk subproject worden van mijn domoticaproject, wat zich momenteel nog in de orienterende fase bevindt

Ik heb vorig jaar overigens nog wat geprutst met de destijds onversleutelde data, echter was op dat moment het protocol nog niet helemaal ontcijferd. Ik begrijp dat dit inmiddels geheel onder controle is?

[Jerrythafast]

JeroenTheStig schreef op maandag 26 september 2016 @ 22:15:
Complimenten voor de TS! Ik zal binnenkort kijken of ik met bovenstaande omschrijving de key kan achterhalen. Dit kan ook een leuk subproject worden van mijn domoticaproject, wat zich momenteel nog in de orienterende fase bevindt

Ik heb vorig jaar overigens nog wat geprutst met de destijds onversleutelde data, echter was op dat moment het protocol nog niet helemaal ontcijferd. Ik begrijp dat dit inmiddels geheel onder controle is?

De werking van het protocol is inmiddels volledig ontcijferd. Er zitten wel nog wat vraagtekens in de data zelf, en niet van alle commando's is exact bekend wat ze nou doen.

[ocaj]

@Jerrythafast: Mooie openingspost, uitleg ziet er prima uit!

Wellicht dat dit topic in de toekomst wordt uitgebreid met informatie voor het rechtstreeks uitlezen van de omvormer via RS-232 (eventueel over USB) of RS-485. Het voordeel van uitlezen via een seriële verbinding is dat de uitleesfrequentie kan worden verhoogd en er geen gedoe is met encryptie. Het nadeel is dat je de monitoring website niet meer kunt gebruiken en je dus volledig zelf verantwoordelijk bent voor de monitoring.

Zelf heb ik er voor gekozen om mijn omvormers niet aan de solaredge-portal te koppelen, maar voor een volledige stand-alone oplossing te gaan. Voor mij was dat geen nadeel, maar een feature

Ik heb mijn omvormers (2 stuks) via RS485 aangesloten die middels een RS485-USB converter aan een Raspberry Pi ("logger") hangen. Daarop heb ik de scripts van jbuehl draaien.
De (json)-output die daaruit komt schrijf ik ook in een database.

Mochten mensen over een dergelijke opstelling vragen hebben dan wil ik die met alle plezier in dit topic beantwoorden.

Om gelijk wat toe te lichten: Je geeft als voordeel aan dat de uitleesfrequentie omhoog kan bij serieel uitlezen. Mogelijk kan dat via RS232, maar via RS485 heb je daar niet veel over te zeggen. RS485 werkt volgens een bus-principe waarop er 1 apparaat zich als "Master" gedraagt en de rest is "Slave". Op RS485 mag maar 1 apparaat tegelijk communiceren, dat wordt geregeld door de Master.

Je configureert dan alle omvormers als Slave en de logger gedraagt zich als Master. De Master geeft bij toerbeurt elke omvormer de kans om wat te zeggen, maar heel vaak zegt de omvormer alleen terug dat hij niks te melden heeft. De omvormer zegt pas wat terug als hij zelf weer nieuwe data heeft.

Omvormer-data komt precies elke 5 minuten.
Optimizer-data komt op minder vaste tijdstippen. Ik heb er nog geen patroon in kunnen ontdekken, maar soms komt die vaker, soms ook minder vaak dan 5 minuten. Ik vermoed (heb het nog niet naast elkaar bekeken) dat zodra je de data op het telemetry-schermpje van de omvormer langs ziet komen, dat de omvormer hem vervolgens ook via RS485 ontsluit. Ook op het telemtry-schermpje zie je sommige optimizers zich vaker melden dan andere, mogelijk afhankelijk van de schommelingen in de productie (varieert grofweg tussen de 80 en 140 entries per optimizer per dag).

Omdat de omvormer - net als bij ethernet - zelf bijhoudt welke data al gerapporteerd zijn aan de portal kan hij maar naar 1 apparaat loggen, dus OF ethernet, OF RS485. Je kunt dat instellen in het menu van de omvormer.
Als hij op beide zou kunnen loggen zou hij ook per data moeten bijhouden wat er al gerapporteerd is, dat is blijkbaar te ingewikkeld.

Overigens blijft de omvormer dezelfde data rapporteren totdat hij een bevestiging ontvangen heeft dat het bericht goed aangekomen is. Dat is zowel over ethernet als over RS485 zo. Wel fijn dus dat er op applicatie-niveau een acknowledge is ingebouwd, zodat de kans dat je data kwijt raakt erg klein is.

De omvormer heeft een geheugen van max. 30 dagen, alhoewel ik over de eerste maand veel minder optimizer-data heb dan over latere dagen, dus mogelijk dat de omvormer nog detail-data van meer dan een paar dagen oud weggooit of samenvoegt om ruimte te besparen. Inmiddels lopen mijn scripts 24/7 (nou ja, eigenlijk van 5:00-22:00), dus als het eenmaal draait, dan is de opslagcapaciteit van de omvormer geen issue meer.

[Aegle]

De RS232 aansluiting geeft realtime data uit. Zodra je de Inverter configuration Tool verbind, zie je de data van het display nagenoeg op hetzelfde moment in de tool verschijnen. Hier wordt de data dus veel frequenter uitgezonden (ong. 1 x per seconde) dan de vijf minuten via de RS485- of Ethernet poort.
Voor grafieken niet zo boeiend. Voor realtime wijzertjes op je web pagina of app zou het wel een mooie feature zijn .

Verder weer de complimenten aan Jerry. Niet alleen voor de ontwikkeling, maar ook zijn wijze van uitleggen verdient een dikke thumbs-up !

EDIT: Via de SE-Portal is het display ook op te roepen. Dit geeft met een vertraging van ongeveer een halve minuut de realtime data van het display weer. via de ethernet poort dus. Zal wel een een of andere GET call zijn. die vanuit de portal wordt aangeroepen. Dit houdt dus in dat je actief data uit de ethernet poort kan trekken...



EDIT 2:
Maar laten we ons hier concentreren op de logging zoals door Jerry is beschreven

[Voor 30% gewijzigd door Aegle op 27-09-2016 08:36]

[Jerrythafast]

ocaj schreef op maandag 26 september 2016 @ 23:19:
@Jerrythafast: Mooie openingspost, uitleg ziet er prima uit!


[...]


Zelf heb ik er voor gekozen om mijn omvormers niet aan de solaredge-portal te koppelen, maar voor een volledige stand-alone oplossing te gaan. Voor mij was dat geen nadeel, maar een feature

Ik heb mijn omvormers (2 stuks) via RS485 aangesloten die middels een RS485-USB converter aan een Raspberry Pi ("logger") hangen. Daarop heb ik de scripts van jbuehl draaien.
De (json)-output die daaruit komt schrijf ik ook in een database.

Mochten mensen over een dergelijke opstelling vragen hebben dan wil ik die met alle plezier in dit topic beantwoorden.

Hier hoopte ik al een beetje op

Om gelijk wat toe te lichten: Je geeft als voordeel aan dat de uitleesfrequentie omhoog kan bij serieel uitlezen. Mogelijk kan dat via RS232, maar via RS485 heb je daar niet veel over te zeggen. RS485 werkt volgens een bus-principe waarop er 1 apparaat zich als "Master" gedraagt en de rest is "Slave". Op RS485 mag maar 1 apparaat tegelijk communiceren, dat wordt geregeld door de Master.

Je configureert dan alle omvormers als Slave en de logger gedraagt zich als Master. De Master geeft bij toerbeurt elke omvormer de kans om wat te zeggen, maar heel vaak zegt de omvormer alleen terug dat hij niks te melden heeft. De omvormer zegt pas wat terug als hij zelf weer nieuwe data heeft.

Omvormer-data komt precies elke 5 minuten.
Optimizer-data komt op minder vaste tijdstippen. Ik heb er nog geen patroon in kunnen ontdekken, maar soms komt die vaker, soms ook minder vaak dan 5 minuten. Ik vermoed (heb het nog niet naast elkaar bekeken) dat zodra je de data op het telemetry-schermpje van de omvormer langs ziet komen, dat de omvormer hem vervolgens ook via RS485 ontsluit. Ook op het telemtry-schermpje zie je sommige optimizers zich vaker melden dan andere, mogelijk afhankelijk van de schommelingen in de productie (varieert grofweg tussen de 80 en 140 entries per optimizer per dag).

Vaker dan eens per 5 minuten kan wel degelijk. Als de servers van SolarEdge niet meekijken kun je ongestraft aan ongedocumenteerde instellingen rotzooien. Zoals MERCURY_PARAM_TELEM_AVG_TIME_SEC. Dit is (vermoedelijk, dit is nog niet getest) een parameter van de optimizers, dus hiermee zou je de monitoring op paneelniveau kunnen opschroeven naar eens per x seconden.

Omdat de omvormer - net als bij ethernet - zelf bijhoudt welke data al gerapporteerd zijn aan de portal kan hij maar naar 1 apparaat loggen, dus OF ethernet, OF RS485. Je kunt dat instellen in het menu van de omvormer.
Als hij op beide zou kunnen loggen zou hij ook per data moeten bijhouden wat er al gerapporteerd is, dat is blijkbaar te ingewikkeld.

Overigens blijft de omvormer dezelfde data rapporteren totdat hij een bevestiging ontvangen heeft dat het bericht goed aangekomen is. Dat is zowel over ethernet als over RS485 zo. Wel fijn dus dat er op applicatie-niveau een acknowledge is ingebouwd, zodat de kans dat je data kwijt raakt erg klein is.

Het protocol is inderdaad heerlijk robuust, als ik aan mijn logger ga prutsen trek ik gewoon de Ethernet kabel eruit wetende dat de omvormer de data wel zal bewaren totdat er weer verbinding is.

De omvormer heeft een geheugen van max. 30 dagen, alhoewel ik over de eerste maand veel minder optimizer-data heb dan over latere dagen, dus mogelijk dat de omvormer nog detail-data van meer dan een paar dagen oud weggooit of samenvoegt om ruimte te besparen. Inmiddels lopen mijn scripts 24/7 (nou ja, eigenlijk van 5:00-22:00), dus als het eenmaal draait, dan is de opslagcapaciteit van de omvormer geen issue meer.

Interessant! Jammer dat dit niet te testen is zonder dataverlies

Aegle schreef op dinsdag 27 september 2016 @ 08:16:
De RS232 aansluiting geeft realtime data uit. Zodra je de Inverter configuration Tool verbind, zie je de data van het display nagenoeg op hetzelfde moment in de tool verschijnen. Hier wordt de data dus veel frequenter uitgezonden (ong. 1 x per seconde) dan de vijf minuten via de RS485- of Ethernet poort.
Voor grafieken niet zo boeiend. Voor realtime wijzertjes op je web pagina of app zou het wel een mooie feature zijn .

Verder weer de complimenten aan Jerry. Niet alleen voor de ontwikkeling, maar ook zijn wijze van uitleggen verdient een dikke thumbs-up !

EDIT: Via de SE-Portal is het display ook op te roepen. Dit geeft met een vertraging van ongeveer een halve minuut de realtime data van het display weer. via de ethernet poort dus. Zal wel een een of andere GET call zijn. die vanuit de portal wordt aangeroepen. Dit houdt dus in dat je actief data uit de ethernet poort kan trekken...

[afbeelding]

EDIT 2:
Maar laten we ons hier concentreren op de logging zoals door Jerry is beschreven

Klopt! Er bestaat een commando READ_LCD waarmee je exact de tekst op het scherm van de omvormer krijgt. Als je via RS-232 of RS-485 bent verbonden kun je dat commando spammen om absurd realtime metertjes te maken (Wederom, dit is niet getest. Ik heb zelf mijn omvormer sowieso nooit anders dan via Ethernet verbonden.)

[Voor 15% gewijzigd door Jerrythafast op 27-09-2016 20:46]

[fvandenreek]

Deze ga ik volgen! Mooie post!

[No Hands]

Vooral dat stukje over opt. temp. vind ik erg interessant, ik begrijp echt niet dat ik dat niet met mijn admin tools eruit krijg.

[Aegle]

Hier draaide het een tijdje op een RPi2. Een oud hubje zorgt voor de koppeling tussen omvormer, RPi en router. De RPi draait op Debian Jessie. Tevens draait er een web- en ftp server, een OpenCPN server en verschillende toepassingen, o.a. Domoticz. Verder hing er nog een Netduino en een Youless aan.

Omdat alles op zolder staat en de adsl-router beneden liep alles via de hub met één kabel naar beneden. Inmiddels is er een switchje bij geplaatst en wordt het hubje alleen nog gebruikt om de RPi het verkeer tussen omvormer en SE te sniffen. Hoewel ik een dichtgetimmerd filter in tcpdump gebruik, was ik bang voor verlies aan data dat via het hubje naar omvormer en internet liep. Alle andere gebruikers maakten ook gebruik van de zelfde hub en kon collisions veroorzaken.

Gisteren heb ik de RPi op de schop genomen en er Jessie-Lite op gezet. Headless. Alleen een CLI interface. Middels sqldump een back-up van de database gemaakt. Eerst nog de oude tabellen verwijderd van V0.0.3. Een beetje met zweet in de handen. Nog niet eerder gedaan en om dan meteen je "productie omgeving" te vernaggelen... Maar na de nieuwe installatie schijnt het nu weer goed te draaien. De database wordt verder gevuld en de historie staat er ook weer in . En vanmorgen zie ik dat PVoutput weer wordt gevuld. Dus dat werk ook weer.

Ik gebruik deze RPi2 vanaf nu alleen maar voor het loggen. Inmiddels ligt er een rpi3 in huis om verder in te richten met Openvpn, webserver etc.. .

[Jerrythafast]

Mocht je de pcap files nog hebben, dan kun je veilig je hele database eruit gooien en opnieuw opbouwen met het commando

python liveupdate.py solaredge-*.pcap

Mijn RPi2 draait ook headless, maar dan dus Ubuntu Server 16.04.

[Jerrythafast]

Ik haal deze discussie in het algemene Datalogging topic even hierheen.

Aegle schreef op zaterdag 15 oktober 2016 @ 23:53:
[...]


Ik heb blijkbaar de server gekilled(?). Liveupdate.log gaf de volgende melding:

code:

Reading from -
Traceback (most recent call last):
File "/opt/se-logger/liveupdate.py", line 399, in <module>
telem)
File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in execute
self.errorhandler(self, exc, value)
File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
_mysql_exceptions.OperationalError: (2006, 'MySQL server has gone away')
Exception AttributeError: "'NoneType' object has no attribute 'error'" in <generator object g$

Bleek dat mysql was gestopt . Nu draait weer. Eens kijken of ik de .pcap kan retrieven. Tezamen met het wegvallen van de SE-portal wordt nog wel wat uitzoekwerk. Er staan nu drie .pcpaps van vandaag...
Vanavond geen tijd gehad. Morgen maar eens verder kijken.

Even de LAN-kabel naar de omvormer eruit trekken. Dan:

user@logger$  sudo service se-logger stop
user@logger$  python /opt/se-logger/liveupdate.py /opt/se-logger/solaredge-20161015??????.pcap
user@logger$  sudo service se-logger start

En dan de kabel er weer in. (De vraagtekens in het tweede commando letterlijk overnemen, hiermee gaat hij gewoon alle drie de pcaps van gisteren opnieuw inlezen. Van alle data die al in de database stond ga je een duplicate key warning krijgen, dat geeft niks.)

Om PVOutput weer compleet te krijgen, op je logger de volgende MySQL query uitvoeren:

SQL:

UPDATE live_update SET pvo_last_live = UNIX_TIMESTAMP("2016-10-15");

De PVOutput uploader begint dan gewoon weer bij het begin van gisteren te uploaden.

Aegle schreef op zaterdag 15 oktober 2016 @ 23:53:
Het zou fraai zijn als we de SE-server zouden kunnen emuleren. Dan werkt het geheel onafhankelijk van SE.

Het emuleren van de SE server zou nog niet eens zo moeilijk moeten zijn, het enige wat die hoeft te doen is data van de omvormer ontvangen en af en toe de juiste tijd door te geven. Dit zijn eigenlijk de enige commando's die de omvormer op eigen initiatief stuurt.

Het lastige is dat je, als je de monitoring portal van SE ook wilt kunnen gebruiken, ook de omvormer moet emuleren. Dus als de 'echte' SE server iets van de omvormer vraagt, moet de logging software daar een antwoord op kunnen geven. Je zou natuurlijk de vraag kunnen doorsturen naar de omvormer en dan het ontvangen antwoord weer doorsturen naar de server, maar als er een keer een firmware update, reset commando, of iets anders 'geks' dat je niet verwacht en waarvan we nu het bestaan nog niet weten voorbij komt is het maar de vraag of de logging software er dan niet uit klapt.

Dat gezegd hebbende, de software van jbuehl op Github heeft wel een optie om als SE server op te treden. Ik weet niet of die ook de monitoring portal nog up to date kan houden. (Zo niet, dan is het eigenlijk veel simpeler op te zetten om RS485 logging te gebruiken. Dat geeft hetzelfde resultaat.)

[Voor 31% gewijzigd door Jerrythafast op 16-10-2016 09:59]

[Aegle]

Bedankt weer voor de duidelijke uitleg. Ik ga vanavond e.e.a. uitvoeren.

[Aegle]

Gisteravond getracht de database weer up-to-date te krijgen. Alle .pcap's van de 15e door het liveupdate-script gehaald. Zonder foutmeldingen. Vervolgens de update naar PVoutput gestart. Echter, daar gebeurde niets. Ik heb vanmorgen gechecked op het moment dat PVoutput de nieuw dag begon, maar de zaterdag begint nog steeds om 14:15 .

Wat blijkt? In Wireshark zie ik de data ook pas starten rond 14:00. Die ochtend was de logging dus niet actief. waarom? Ik weet het (nog) niet. Als ik tijd heb zal ik de Linux logbestanden eens doorspitten en eens kijken of ik iets vreemds zie.

[rense]

@Jerrythafast: Dit is nou een top-topic!

Ik snap niet hoe ik deze heb kunnen missen, omdat ik de afgelopen maand me van voor naar achteren heb verdiept in zonnepanelen met SE omvormer en optimizers, en daarnaast elke dag wel even dit forum bezoek. Goede timing dat ik het nu lees, want morgenochtend komen ze de panelen en omvormer installeren .

Ik wacht voorlopig maar even met de ethernetstekker in mijn router te steken. Ik heb de spullen om via RS-485 de omvormer uit te gaan lezen, maar het is goed om te zien dat het afluisteren via ethernet ook lukt. Mijn RPi3 gaat het nog druk krijgen.

Ik hou jullie wel op de hoogte van mijn bevindingen. Bedankt alvast voor het hier zo uitgebreid documenteren van de methode. Voor mij meer dan genoeg detail.

[Jerrythafast]

Haha, dat is inderdaad wel écht last minute! Laat het maar weten als je ergens op vast loopt

De omvormer onthoudt trouwens de telemetriegegevens nog wel een tijdje, dus als je het werkend hebt kun je alsnog vanaf het begin de opbrengst loggen. Hoe lang de gegevens behouden blijven hangt af van hoeveel optimizers je hebt:

ApC_IcE schreef op woensdag 02 november 2016 @ 09:11:
Gevonden:
SolarEdge inverter is capable of storing data for a period of time that is relative to the number of PowerBoxes used in the layout (per inverter). Estimation to the maximum retention time can be carried out as follows:
Number of Days Stored ≈ 700/Number of modules per inverter
Here are a few examples:
If storage space is used up and connection to the monitoring server was not yet made, the inverter will either cease storing data (inverter CPU version 1.xxx) or overwrite out of date data in favor of recent one (inverter CPU version 2.xxx).
Data not transmitted yet is stored locally and can be viewed with SolarEdge configuration tool by connecting a computer to the inverter. This action does not change or stop data storage.
Number of PowerBoxes
Approximate Retention time
12 modules = 2 months
24 modules = 1 month
50 modules = 2 weeks

Ik neem aan dat ze optimizers bedoelen.

Bron:

http://www.solaredge.com/...ring_and_sending_data.pdf

[ApC_IcE]

Jerrythafast schreef op donderdag 03 november 2016 @ 22:46:
Haha, dat is inderdaad wel écht last minute! Laat het maar weten als je ergens op vast loopt

De omvormer onthoudt trouwens de telemetriegegevens nog wel een tijdje, dus als je het werkend hebt kun je alsnog vanaf het begin de opbrengst loggen. Hoe lang de gegevens behouden blijven hangt af van hoeveel optimizers je hebt:

[...]

Ik dacht al, waarom krijg ik een melding van een quote in een voor mij onbekend topic

[Jerrythafast]

ApC_IcE schreef op vrijdag 04 november 2016 @ 09:03:
[...]


Ik dacht al, waarom krijg ik een melding van een quote in een voor mij onbekend topic

Ik had de informatie in je post hier even nodig

[rense]

Dank voor die info. 700/10=70 dagen, zou goed moeten komen.

Ik heb even zitten dubben of ik de omvormer helemaal los zou houden van de Solar Edge server en de originele firmware erop zou laten. Ik heb met de configuratietool wat zitten rondneuzen in de omvormer, maar de info daar lijkt wat karig. Het lijstje van optimizers is bij mij helemaal leeg, dus valt er ook geen opgeslagen data op te roepen. Toch zijn er 10 aangesloten (wat het display wel rapporteert). Helaas heb ik van de installateurs niet de info (streepjescodes bijv) van de optimizers gekregen, zodat ik ze niet zelf alsnog makkelijk kan invoeren. Hoe was dat bij jullie? Of voeren ze dat als installateur in op de Solar Edge site?

Al met al ben ik dan toch nieuwsgierig naar de Solar Edge monitoring site (misschien dat ik daar meer info vind), dus dan toch maar even aansluiten. Dus ik richt nu even een RPi3 in met jouw methode. Mooi uitgeschreven, ik hoef bijna niet zelf na te denken (met gevaar op luiheid ). Even een detail dat ik tegenkwam: je schrijft het commando systemctl (in methode 4.2):

user@logger$  sudo systemctl --now enable se-nat

met de optie ' --now'. Het lijkt erop dat deze extra optie niet bestaat bij de systemctl van Raspbian. Ook heb je in het voorbeeld de service ' se-logger' (eerste regel) genoemd ipv ' se-nat' (maar ik zie nu dat er twee services moeten komen se-nat en se-logger). Ik neem aan dat dezelfde actie dan uitgevoerd kan worden met

user@logger$  sudo systemctl enable se-nat ; sudo systemctl start se-nat

Nu even een extra patchkabeltje vinden om de logger te testen met m'n laptop (wat een heerlijk puzzelklusje op de zondagavond ).

Update: het loggen is begonnen! De telemetry_optimizers tabel vult zich. Morgen ga ik die eens rustig bekijken. Nogmaals bedankt voor het delen van dit puik stukje werk!

[Voor 8% gewijzigd door rense op 06-11-2016 22:23]

[Jerrythafast]

rense schreef op zondag 06 november 2016 @ 20:16:
Dank voor die info. 700/10=70 dagen, zou goed moeten komen.

Ik heb even zitten dubben of ik de omvormer helemaal los zou houden van de Solar Edge server en de originele firmware erop zou laten. Ik heb met de configuratietool wat zitten rondneuzen in de omvormer, maar de info daar lijkt wat karig. Het lijstje van optimizers is bij mij helemaal leeg, dus valt er ook geen opgeslagen data op te roepen. Toch zijn er 10 aangesloten (wat het display wel rapporteert). Helaas heb ik van de installateurs niet de info (streepjescodes bijv) van de optimizers gekregen, zodat ik ze niet zelf alsnog makkelijk kan invoeren. Hoe was dat bij jullie? Of voeren ze dat als installateur in op de Solar Edge site?

Al met al ben ik dan toch nieuwsgierig naar de Solar Edge monitoring site (misschien dat ik daar meer info vind), dus dan toch maar even aansluiten. Dus ik richt nu even een RPi3 in met jouw methode. Mooi uitgeschreven, ik hoef bijna niet zelf na te denken (met gevaar op luiheid ). Even een detail dat ik tegenkwam: je schrijft het commando systemctl (in methode 4.2):

user@logger$  sudo systemctl --now enable se-nat

met de optie ' --now'. Het lijkt erop dat deze extra optie niet bestaat bij de systemctl van Raspbian. Ook heb je in het voorbeeld de service ' se-logger' (eerste regel) genoemd ipv ' se-nat' (maar ik zie nu dat er twee services moeten komen se-nat en se-logger). Ik neem aan dat dezelfde actie dan uitgevoerd kan worden met

user@logger$  sudo systemctl enable se-nat ; sudo systemctl start se-nat

Nu even een extra patchkabeltje vinden om de logger te testen met m'n laptop (wat een heerlijk puzzelklusje op de zondagavond ).

Update: het loggen is begonnen! De telemetry_optimizers tabel vult zich. Morgen ga ik die eens rustig bekijken. Nogmaals bedankt voor het delen van dit puik stukje werk!

Helemaal goed De '--now enable' optie zou inderdaad de service moeten enablen en direct starten.

Nu je data in je database krijgt kun je de serienummers van je optimizers eenvoudig achterhalen met

SQL:

SELECT HEX(op_id) FROM telemetry_optimizers GROUP BY op_id;

Dan moet je alleen nog even uitzoeken welke waar ligt

[adjego]

Heeft er hier iemand die Configuration tool v2 waarmee je op de omvormer kunt kijken? Lijkt me zeer interessant.

[rense]

hier:
https://github.com/Whizkidzz/Solaredge

Ik heb inmiddels antwoord op mijn vraag over de optimizers: vanmiddag kreeg ik per mail een pak informatie van mijn installateur inclusief een foto van de QR-codes van de optimizers. Tevens hebben zij de monitoring site bij SE ingericht. Helaas klopt de oriëntatie van mijn dak niet, maar dat valt als consument niet aan te passen.

Ik ben blij het zelf in de hand te kunnen hebben met het data-sniffen. Ik zag de optimizer-ids inderdaad voorbij komen in de database. Hebben jullie al wel eens de optimizers bij elkaar opgeteld en gecheckt of deze in de buurt liggen van het totaal van de omvormer? Ben daar wel benieuwd naar. Netals of de SE-info overeenkomt met de hoogte van pieken en dalen uit onze slimme meter.

De communicatie is inmiddels ge-encrypted. Binnen 24 uur na inpluggen dus. De key kon prima gevonden worden in de pcap-files.

[Voor 88% gewijzigd door rense op 07-11-2016 21:28]

[Jerrythafast]

rense schreef op maandag 07 november 2016 @ 21:21:
hier:
https://github.com/Whizkidzz/Solaredge

Ik heb inmiddels antwoord op mijn vraag over de optimizers: vanmiddag kreeg ik per mail een pak informatie van mijn installateur inclusief een foto van de QR-codes van de optimizers. Tevens hebben zij de monitoring site bij SE ingericht. Helaas klopt de oriëntatie van mijn dak niet, maar dat valt als consument niet aan te passen.

Ik ben blij het zelf in de hand te kunnen hebben met het data-sniffen. Ik zag de optimizer-ids inderdaad voorbij komen in de database. Hebben jullie al wel eens de optimizers bij elkaar opgeteld en gecheckt of deze in de buurt liggen van het totaal van de omvormer? Ben daar wel benieuwd naar. Netals of de SE-info overeenkomt met de hoogte van pieken en dalen uit onze slimme meter.

De communicatie is inmiddels ge-encrypted. Binnen 24 uur na inpluggen dus. De key kon prima gevonden worden in de pcap-files.

De cumulatieve energie van de panelen bij elkaar opgeteld is iets hoger dan het totaal van de omvormer. Wij zitten hier nu op 99,1% 'efficiency' of hoe je het wilt noemen.

Mooi dat het allemaal volgens verwachting verloopt Jij bent toch een beetje het proefkonijn van dit topic nu, als zijnde de eerste die zonder bemoeienis van mijn kant de boel installeert

[rense]

Haha, mooi. Ik vind het geen probleem proefkonijn te spelen.

Ik heb meteen nog wel een vraag. Gisteravond en vandaag vulde de optimimertabel zich meteen en prima, maar de inverter-tabel blijft tot nog toe leeg. Enig idee of dit normaal is of duidt op een foutje ergens?

[Cranberry]

rense schreef op maandag 07 november 2016 @ 21:21:
hier:
https://github.com/Whizkidzz/Solaredge

.... Hebben jullie al wel eens de optimizers bij elkaar opgeteld en gecheckt of deze in de buurt liggen van het totaal van de omvormer? Ben daar wel benieuwd naar. Netals of de SE-info overeenkomt met de hoogte van pieken en dalen uit onze slimme meter.

Info van SE qua pieken uit slimme meter kan ik niet zeggen (heb niet zo'n meter ), maar als ik de totale opwek zoals SE die rapporteert, vergelijk met de opbrengst die ik zelf meet d.m.v. een pulse-meter in de meterkast, dan is SE tussen de 2 en 3% hoger.

[adjego]

Ik heb zelf de SE2200 en ik weet eigenlijk 100% zeker dat er een flinke afwijking zit in wat de omvormer zegt wat hij opbrengt en wat hij daadwerkelijk opgewekt heeft. Ik ga op dit moment uit van een afwijking van 4% en dat lijkt zeer dicht in de buurt te komen.

Even nog iets anders. Soms wordt er hier gepraat over het uitlezen via USB? Heeft de omvormer echt een USB poort achter de kap en komt daar seriele data uit? Of hoe moet ik dit zien?

[rense]

Cranberry schreef op dinsdag 08 november 2016 @ 07:15:
[...], dan is SE tussen de 2 en 3% hoger.

Ik had niet anders verwacht dan dat het hoger zou liggen, kopers moeten toch tevreden kunnen zijn over hun aangeschafte product. Ik ben dus benieuwd of dit uitzondering of regel blijkt te zijn.

@adjego: Ja, er zit een USB mini B plug als je hem open schroeft. Bij mij loopt er nu een USB-kabeltje aan de onderkant eruit, zodat ik makkelijk even de laptop eraan kan pluggen. De omvormer verschijnt vervolgens als een seriële com-poort op je computer.
Het openschroeven is niet zo heel spannend. Gewoon niets aanraken en pas doen als de omvormer in nachtstand staat. Of dus zelfs even de schakelaar naar het net omzetten.

[Voor 5% gewijzigd door rense op 08-11-2016 09:49]

[adjego]

Ja heb hem laatst al opengehad om een nieuwe UTP kabel aan te sluiten. Maar die usb connectie, is dat een seriele connectie?

[rense]

Ja. Zie ook de uitgebreide conversatie (waar Jerrythafast dezelfde vraag stelde) op
https://github.com/jbuehl/solaredge/issues/8

Als ik de inverter via USB aan m'n Windows-laptop plug, krijg ik er een COM-poort bij (COM12 in mijn geval), net als wanneer je een USB-naar-Seriëel kabeltje in de USB-poort steekt. De SE-conf-tool begint altijd met een selectiemenuutje waar je vervolgens de juiste COM-poort selecteert.

[adjego]

Maar er zijn dus geen seriele commando's bekend waarmee je door middel van USB de omvormer kunt uitlezen?

[rense]

De commando's die je moet sturen zijn in byte-vorm bekend. Als je je eigen seriële communicatie wilt ontwerpen, dan lijkt mij de makkelijkste methode het project van jbuehl te reverse-engineeren. In zijn code wordt steevast gesproken over de 'Datafile', maar onder linux zijn alle poorten (USB/seriëel) ook te beschouwen als files. De code maakt (voor zover ik het zag) verder dan ook geen onderscheid in file/RS485/ethernet en RS232, op wel of niet encryptie na.
De commando's staan in seCommands.py, en het berichten naar de omvormer stuurt hij met de functie sendMsg in de file seMsg.py. Elke message wordt vooraf gegaan door de 'magic' sequence "\x12\x34\x56\x79", wat in Telnet of Hyperterm eruit zou zien als (http://ascii.cl/) <DC2>"Vy. Ook niet echt leesbaar ;-)

[Jerrythafast]

rense schreef op maandag 07 november 2016 @ 21:55:
Haha, mooi. Ik vind het geen probleem proefkonijn te spelen.

Ik heb meteen nog wel een vraag. Gisteravond en vandaag vulde de optimimertabel zich meteen en prima, maar de inverter-tabel blijft tot nog toe leeg. Enig idee of dit normaal is of duidt op een foutje ergens?

Heb je toevallig een 3-fasen omvormer? If not, wat is je CPU version? Ik vermoed dat je een omvormer of versie hebt die net iets meer data meestuurt dan die ik tot nu toe heb gezien. Als dat zo is zou je me kunnen helpen jou te helpen door een PCAP file (liefst een unencrypted exemplaar) toe te sturen. Dan heb ik snel genoeg een nieuwe versie van solaredge-logger paraat die er wat mee kan

[rense]

Jerrythafast schreef op dinsdag 08 november 2016 @ 19:42:
[...]

Heb je toevallig een 3-fasen omvormer? If not, wat is je CPU version?

Het is een 1-fasen omvormer. CPU version 3.1818. Ik denk dat dit nog een unencrypted file is:

pcap-file

Ik ben benieuwd wat er nog meer te vinden is. Of verwacht jouw code op dit moment een vast rijtje met gegevens van de inverter en wanneer dit langer is geworden, skipt hij het?

[Jerrythafast]

rense schreef op dinsdag 08 november 2016 @ 21:00:
[...]


Het is een 1-fasen omvormer. CPU version 3.1818. Ik denk dat dit nog een unencrypted file is:

pcap-file

Ik ben benieuwd wat er nog meer te vinden is. Of verwacht jouw code op dit moment een vast rijtje met gegevens van de inverter en wanneer dit langer is geworden, skipt hij het?

Hij verwacht nu 124 of 174 bytes aan 1-fase-omvormer-data. Als het meer of minder is, of geen 1-fase omvormer, negeert hij het. Dit heb ik zo gedaan om te voorkomen dat er random crap in je database komt.

De PCAP file die je deelde bevat trouwens ook de switch waarbij encryptie werd ingeschakeld. Ik ga even kijken wat jouw omvormer nog meer te vertellen heeft. Hij stuurt inderdaad een paar bytes extra.

Als ik de nieuwe versie klaar heb kun je daarmee trouwens gewoon de PCAP files van de afgelopen dagen opnieuw laten parsen om de data in je database te krijgen


EDIT:
solaredge-logger v0.0.6
Het gedeelte van de data wat ik had ontcijferd en in de database bewaar is hetzelfde bij jouw versie, hij zendt alleen nog wat meer. Simpele fix was dus gewoon om de langere data te accepteren

Update instructie: volg paragraaf 6.3 van de OP. Nadat je de service hebt gestopt kun je liveupdate.py van versie 0.0.6 overnemen en daarmee de database aanvullen (vergeet je settings niet aan te passen in het script )

[Voor 19% gewijzigd door Jerrythafast op 08-11-2016 21:59]

[rense]

check. dat was een snelle fix . Ik druk de pcaps er nog een keer doorheen.

Edit: interessante waarneming bij deze pcap

Reading from solaredge-20161106204009.pcap:
liveupdate.py:399: Warning: Out of range value for column 'temperature' at row 1
  telem)

Verder wat mysterious bytes in latere pcaps, maar ik heb de stekker er ook even uit gehad, denk ik. De invertertabel is nu mooi gevuld. Tijd om te grasduinen.

Edit 2: Ik denk dat er nog een bytje verschoven moet worden bij mij, want de temperatuur komt in de tabel uit op 150.000-200.000. Wat is een normale temperatuur van de omvormer? Met een factor 8192 (2^13) kom ik op een range van 20-36 grC.

[Voor 91% gewijzigd door rense op 08-11-2016 23:05]

[Jerrythafast]

rense schreef op dinsdag 08 november 2016 @ 22:15:
check. dat was een snelle fix . Ik druk de pcaps er nog een keer doorheen.

Edit: interessante waarneming bij deze pcap

Reading from solaredge-20161106204009.pcap:
liveupdate.py:399: Warning: Out of range value for column 'temperature' at row 1
  telem)

Verder wat mysterious bytes in latere pcaps, maar ik heb de stekker er ook even uit gehad, denk ik. De invertertabel is nu mooi gevuld. Tijd om te grasduinen.

Edit 2: Ik denk dat er nog een bytje verschoven moet worden bij mij, want de temperatuur komt in de tabel uit op 150.000-200.000. Wat is een normale temperatuur van de omvormer? Met een factor 8192 (2^13) kom ik op een range van 20-36 grC.

Ehmm.. de out of range values kan ik verklaren. Jouw omvormer blijkt de minimale 32-bit float waarde te sturen als de temperatuur-data niet beschikbaar is. Python converteert die tussendoor naar 64-bits waarbij hij nog net een klein beetje lager wordt. Is nog een kleine fix voor nodig om deze te weren.

Wat ik niet kan verklaren is dat je temperatuur in de range 150.000-200.000 °C in je database aantreft... zijn alle waardes in die range? In de PCAP file zijn ze inderdaad rond de 20-30 °C. Bijvoorbeeld 2016-11-06 11:00:00 UTC was 26.8468 °C.

[rense]

Je hebt gelijk. In de MySQL tabel staan ze in de goede range. Ik had ze daarna eventjes geëxporteerd via phpmyadmin via een csv en even in Excel bekeken. 't Zal in die stap gebeurt zijn. Van die warning lig ik idd niet wakker, want die zijn er goed uit te filteren en te interpoleren. Bedankt voor de code, scheelt veel puzzelen.

[Aegle]

Deze melding

code:

pi@rpi2-solarlogger:/opt/se-logger $ cat liveupdate.log
Reading from -
/opt/se-logger/liveupdate.py:399: Warning: Out of range value for column 'p_reactive' at row 1
  telem)
pi@rpi2-solarlogger:/opt/se-logger $

staat bij mij ook elke dag weer in liveupdate.log. Ik trek me daar verder niks van aan. De database word gewoon gevuld .

PS: hoe krijgen jullie hier die geciteerde code zo mooi in een zwart kader...?

[Jerrythafast]

Aegle schreef op woensdag 09 november 2016 @ 20:16:
Deze melding

code:

pi@rpi2-solarlogger:/opt/se-logger $ cat liveupdate.log
Reading from -
/opt/se-logger/liveupdate.py:399: Warning: Out of range value for column 'p_reactive' at row 1
  telem)
pi@rpi2-solarlogger:/opt/se-logger $

staat bij mij ook elke dag weer in liveupdate.log. Ik trek me daar verder niks van aan. De database word gewoon gevuld .

PS: hoe krijgen jullie hier die geciteerde code zo mooi in een zwart kader...?

Dat zal inderdaad eenzelfde probleem zijn. Ik zal voor de volgende versie eens kijken of ik het heen en weer converteren van 32-bit naar 64-bit float en terug eenvoudig kan verhinderen.

Dit soort zwart-witte vlakken maak je met [cmd]...[/cmd]

[Aegle]

Thanks

Overigens, de website is echt nog wel een uitdaging, hoor. Te veel mogelijkheden en te weinig tijd... .
Maar komt tijd, komt raad .

Overigens #2, ik ben voornemens te kijken of het eenvoudig is een timestamp aan de logfiles toe te voegen. Dat is makkelijker met faultfinding mocht het eens echt misgaan met de logging.

[Voor 37% gewijzigd door Aegle op 09-11-2016 21:39]

[rense]

@Jerrythafast Ik heb je code er nog op doorgeplozen, maar wat doet je script met de pcap-files waardoor hun 'modification time' steeds wordt aangepast (ook van de oudere)? Is readonly lezen niet voldoende voor het script?

[Yoki1985]

Ik heb sinds juni van dit jaar ook een Solaredge opstelling draaien. Deze hangt dus al een paar maanden aan het internet. Als ik het goed begrijp is het niet meer mogelijk om deze uit te lezen (ja via seriële verbinding is het mogelijk, maar ik had graag de upload naar het SE platform behouden)

[rense]

Yoki1985 schreef op donderdag 10 november 2016 @ 14:34:
Ik heb sinds juni van dit jaar ook een Solaredge opstelling draaien. Deze hangt dus al een paar maanden aan het internet. Als ik het goed begrijp is het niet meer mogelijk om deze uit te lezen (ja via seriële verbinding is het mogelijk, maar ik had graag de upload naar het SE platform behouden)

Jawel, het kan nog, maar dan moet je even de RS232(USB)-verbinding gebruiken en dus de kast eventjes openschroeven (en na afloop gewoon weer de data naar het SE platform sturen). Met het project van jbuehl kun je het volgende commando runnen vanuit een linux-omgeving:

python solaredge/semonitor.py -c 12,H239/12,H23a/12,H23b/12,H23c -s 7f101234 -t 2  /dev/ttyUSB0|python solaredge/sekey.py -o 7f101234.key

Uiteraard moeten dan op twee plekken in deze regel het sernienummer van jouw eigen omvormer komen te staan. In de tekstfile met extensie .key staat vervolgens de encryptie-key die je over kunt nemen naar het script van Jerrythafast (hoogstens het formaat even aanpassen).

Ik heb zijn scripts draaien op een Rpi3. De SE omvormer hangt met zijn ethernetkabel aan de Rpi; de RPi slaat het netwerkverkeer op en geeft de SolarEdge-communicatie via zijn Wifi door aan de router richting Israël. Om te zien hoe de scripts van jbuehl werken, heb ik de Rpi even van de ethernetkabel losgekoppeld en via de USB-kabel aan de omvormer gehangen. Daarmee had ik meteen een linux-omgeving voor handen waarop key-extractiescript zonder enig puzzelen kon draaien (anders zit je met Windows en hoe je dan de seriële poort moet benaderen). Zolang je de omvormer hebt losgekoppeld van internet, houdt ie zijn data even vast en heb je later geen gat in je data op de SE-monitoringsite.

[Jerrythafast]

rense schreef op donderdag 10 november 2016 @ 12:54:
@Jerrythafast Ik heb je code er nog op doorgeplozen, maar wat doet je script met de pcap-files waardoor hun 'modification time' steeds wordt aangepast (ook van de oudere)? Is readonly lezen niet voldoende voor het script?

De modification time wordt door mijn scripts niet aangepast. Op het laagste niveau (se-logger-service.sh) is het PCAP bestand het output argument van het programma 'tee'. Dat programma past de modification time aan als er nieuwe data in wordt geschreven. Daarna zou de modification time niet meer moeten veranderen. Als dit wel het geval is is er een ander programma dat er blijkbaar aan zit te morrelen.

Yoki1985 schreef op donderdag 10 november 2016 @ 14:34:
Ik heb sinds juni van dit jaar ook een Solaredge opstelling draaien. Deze hangt dus al een paar maanden aan het internet. Als ik het goed begrijp is het niet meer mogelijk om deze uit te lezen (ja via seriële verbinding is het mogelijk, maar ik had graag de upload naar het SE platform behouden)

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

[rense]

Jerrythafast schreef op donderdag 10 november 2016 @ 20:24:
[...]

De modification time wordt door mijn scripts niet aangepast. Op het laagste niveau (se-logger-service.sh) is het PCAP bestand het output argument van het programma 'tee'. Dat programma past de modification time aan als er nieuwe data in wordt geschreven. Daarna zou de modification time niet meer moeten veranderen. Als dit wel het geval is is er een ander programma dat er blijkbaar aan zit te morrelen.

Hmm, ik moet mijn services dan maar eens bij langs welke er stiekem nog steeds draaien na allerhande experimenteren.

Jouw andere key-scriptje was ik idd vergeten, maar ik had hem dan ook niet nodig gehad. Mooi compleet pakket heb je gemaakt.

Ik kan binnenkort mijn SE-omvormer vs. slimme meter output gaan vergelijken, want daar stroomt sinds gisteren ook de data uit. Had er een tijd mee zitten klooien, maar een ander merk USB-seriëelconverter loste alles op.

[Voor 12% gewijzigd door rense op 11-11-2016 08:57]

[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

Goh zalig, ga ik zeker eens proberen. Ik hou jullie op de hoogte!

[Corn]

Goed werk Jerrythafast! Ik heb zojuist de key eruit gepeuterd met Serial over USB en heb de boel geinstalleerd. Ik zie veel van deze voorbij komen:

code:

Warning! Got 103 mysterious bytes left! (state=0)
f6 79 72 da a0 4e 03 6a 64 1b 82 5a 63 64 3e 2b 3b 78 3e d3 1b 2b ba dd 66 21 5a 40 a6 5b 16 43 98 46 ad ff 63 27 20 c3 5f 04 60 ea 38 ad 87 52 65 7a 01 03 ae c1 e9 2e 28 fd 84 b4 4a 9d 97 f5 6e e7 83 2e 94 57 1e b7 70 45 c3 35 60 4b c0 82 93 e3 59 5c a8 dd 3b f0 29 a0 67 dc da 8b 83 14 e9 5b 41 72 a4 ed 8a
Warning! Got 22 mysterious bytes left! (state=0)
02 44 0d 8d 58 e8 b2 de 8c 52 4e 46 f8 93 ac a7 ef 3d da 97 27 50

Heb 'm nog niet overdag gechecked, dus optimizer data komt er iig niet voorbij. Is het script op dit moment compatible met 3-fase omvormers? Ik heb een SE5k....

[Jerrythafast]

Corn schreef op zaterdag 19 november 2016 @ 23:55:
Goed werk Jerrythafast! Ik heb zojuist de key eruit gepeuterd met Serial over USB en heb de boel geinstalleerd. Ik zie veel van deze voorbij komen:

code:

Warning! Got 103 mysterious bytes left! (state=0)
f6 79 72 da a0 4e 03 6a 64 1b 82 5a 63 64 3e 2b 3b 78 3e d3 1b 2b ba dd 66 21 5a 40 a6 5b 16 43 98 46 ad ff 63 27 20 c3 5f 04 60 ea 38 ad 87 52 65 7a 01 03 ae c1 e9 2e 28 fd 84 b4 4a 9d 97 f5 6e e7 83 2e 94 57 1e b7 70 45 c3 35 60 4b c0 82 93 e3 59 5c a8 dd 3b f0 29 a0 67 dc da 8b 83 14 e9 5b 41 72 a4 ed 8a
Warning! Got 22 mysterious bytes left! (state=0)
02 44 0d 8d 58 e8 b2 de 8c 52 4e 46 f8 93 ac a7 ef 3d da 97 27 50

Heb 'm nog niet overdag gechecked, dus optimizer data komt er iig niet voorbij. Is het script op dit moment compatible met 3-fase omvormers? Ik heb een SE5k....

Erm, ik vrees van niet eerlijk gezegd, jij hebt de primeur Ik weet dat de 3-fase omvormers meer data versturen (diverse zaken aan de AC-kant zijn dan immers in drievoud) dus er zal sowieso iets voor moeten worden aangepast. Ik denk dat ik ook even een 3-fase inverter_telemetry database tabel moet bijmaken.

Zou ik van jou een PCAP capture bestandje mogen hebben (die is gemaakt met licht op de panelen) en de sleutel waarmee je omvormer zijn data scramblet? Dan kan ik even kijken wat voor telemetrie we eruit kunnen halen

[Corn]

Jerrythafast schreef op zondag 20 november 2016 @ 10:17:
[...]

Erm, ik vrees van niet eerlijk gezegd, jij hebt de primeur Ik weet dat de 3-fase omvormers meer data versturen (diverse zaken aan de AC-kant zijn dan immers in drievoud) dus er zal sowieso iets voor moeten worden aangepast. Ik denk dat ik ook even een 3-fase inverter_telemetry database tabel moet bijmaken.

Zou ik van jou een PCAP capture bestandje mogen hebben (die is gemaakt met licht op de panelen) en de sleutel waarmee je omvormer zijn data scramblet? Dan kan ik even kijken wat voor telemetrie we eruit kunnen halen

Cool! Ondertussen is er optimizer data gelogged, dat lijkt in ieder geval goed te werken.

Misschien interessant voor andere tweakerts die Jerry's systeem gaan gebruiken, ik heb gekozen voor een andere 'aansluitmethode'. Ik heb een ESXi box waar gevirtualiseerd alles in draait, ook m'n router (pfSense). Ik heb ik een VM met se-logger gestart en aangesloten op het VLAN waar ook de SolarEdge inverter op zit. Vervolgens voor dat VLAN promiscuous mode enabled, zodat de se-logger VM deze data rechtstreeks op kan pikken.



Omdat er wat meer IoT devices op zitten die ook allemaal hun data uitspuigen op hetzelfde VLAN, heb ik een kleine aanpassing in se-logger-service gemaakt:

code:

/usr/bin/stdbuf -i0 -o0 -e0 /usr/sbin/tcpdump -i $INTERFACE -U -w - -n host 10.0.15.8 2>> ${CAPTDIR}tcpdump.log | \

IP van m'n omvormer is 10.0.15.8 in dit geval. (Je zou 't ook mooi configurable kunnen maken met een variabele, maar ik ben onwijs lui.)

Hierdoor wordt alleen de relevante data opgeslagen in de PCAP, en loopt ie niet vol met MQTT-onzin van m'n wifi temperatuur loggers e.d.

Wie weet heeft iemand er wat aan

Ik PM je zo met de pcap en key!

[Jerrythafast]

Corn schreef op zondag 20 november 2016 @ 11:01:
[...]


Cool! Ondertussen is er optimizer data gelogged, dat lijkt in ieder geval goed te werken.

Misschien interessant voor andere tweakerts die Jerry's systeem gaan gebruiken, ik heb gekozen voor een andere 'aansluitmethode'. Ik heb een ESXi box waar gevirtualiseerd alles in draait, ook m'n router (pfSense). Ik heb ik een VM met se-logger gestart en aangesloten op het VLAN waar ook de SolarEdge inverter op zit. Vervolgens voor dat VLAN promiscuous mode enabled, zodat de se-logger VM deze data rechtstreeks op kan pikken.

[afbeelding]

Omdat er wat meer IoT devices op zitten die ook allemaal hun data uitspuigen op hetzelfde VLAN, heb ik een kleine aanpassing in se-logger-service gemaakt:

code:

/usr/bin/stdbuf -i0 -o0 -e0 /usr/sbin/tcpdump -i $INTERFACE -U -w - -n host 10.0.15.8 2>> ${CAPTDIR}tcpdump.log | \

IP van m'n omvormer is 10.0.15.8 in dit geval. (Je zou 't ook mooi configurable kunnen maken met een variabele, maar ik ben onwijs lui.)

Hierdoor wordt alleen de relevante data opgeslagen in de PCAP, en loopt ie niet vol met MQTT-onzin van m'n wifi temperatuur loggers e.d.

Wie weet heeft iemand er wat aan

Ik PM je zo met de pcap en key!

Wauw, gave set-up! Je had ook je FILTER variabele in se-logger-service.sh op '-n host 10.0.15.8.2 tcp' kunnen zetten

[Corn]

Jerrythafast schreef op zondag 20 november 2016 @ 11:10:
[...]

Wauw, gave set-up! Je had ook je FILTER variabele in se-logger-service.sh op '-n host 10.0.15.8.2 tcp' kunnen zetten

Heh inderdaad dat is eigenlijk beter Wat je in PM ook zei; anders komen alsnog allerlei onzin packets in de capture terecht.

[Corn]

Jerrythafast heeft zijn naam eer aan gedaan en in een bliksemtempo support voor 3-phase SE omvormers toegevoegd! Hulde!

[Aegle]

Hij is inderdaad snel is ook mijn ervaring .
Heb je hem al eens een e-mail gestuurd? Hij is ook nog eens de beste... .

[Pietjebel10]

Mijn petje af , ook maar eens de Raspberry in elkaar gesleuteld, loopt als een zonnetje, ben nu even aan het stoeien met de mysql en de gegevens, lukt aardig alleen de timestamp blijft soms moeilijk mee te rekenen maar gaat goed. Werk hier met de SE3000, wanneer het mij aanstaat zal ik het hier publiceren,
Keep up the great work , mijn dank is groot

[Jerrythafast]

Ik wil het enthousiasme niet temperen, maar toch een kleine disclaimer: solaredge-logger v0.0.7 (welke sinds gisteravond online staat) ondersteunt wel het uitlezen van 3-fase omvormers, maar niet het uploaden van 3-fase omvormerdata naar PVOutput. Hier moet ik nog even aan rommelen.

Pietjebel10 schreef op maandag 21 november 2016 @ 19:58:
Mijn petje af , ook maar eens de Raspberry in elkaar gesleuteld, loopt als een zonnetje, ben nu even aan het stoeien met de mysql en de gegevens, lukt aardig alleen de timestamp blijft soms moeilijk mee te rekenen maar gaat goed. Werk hier met de SE3000, wanneer het mij aanstaat zal ik het hier publiceren,
Keep up the great work , mijn dank is groot

Voor de timestamps zijn in MySQL UNIX_TIMESTAMP(date) en FROM_UNIXTIME(unix_timestamp) erg handig.

[Pietjebel10]

Thanks hier werkte ik al mee, maar was bezig om historie gegevens van voor de registratie in te vullen dat wordt kritisch. Ik vul dan bij voorbeeld de maandopbrengst in van de maanden in met 1 registratie per maand, en daar moet ik iets op vinden dat dit dan ok alleen maar paar maand zichtbaar wordt en ook nog een beetje goed in de grafrieken staat.
Werk trouwens met de highcharts ook erg veel mogelijkheden.
elk advies/idee is welkom natuurlijk

[Quinie]

Bedankt voor dit topic. Er hang net vandaag een systeem 3 fases hier te draaien. Nog 30 dagen dus om de pi af te configureren

[tinka]

Als voorbereiding op mijn installatie ook maar eens aan de slag gegaan.

Voor de installatie procedure heb ik mogelijk een toevoeging. Ik heb het volgende in se-logger-service.sh toegevoegd

code:

#wait for mysql to come alive

while true; do
    response=`/usr/bin/mysqladmin -uUNKNOWN_USER ping 2>&1` && break
    echo "$response" | grep -q "mysqld is alive" && break
    sleep 1
done

Ik had het probleem dat de liveupdate.log een error liet zien ivm het feit dat mysql nog niet klaar was.

Het kan zijn dat er betere oplossingen zijn maar het werkt.

Nu alleen wachten op de omvormer en kijken of de pcap files goed verwerkt worden.

Ik vond je website voorbeeld er al heel aardig uit zien.

[Aegle]

tinka schreef op woensdag 23 november 2016 @ 22:08:
Als voorbereiding op mijn installatie ook maar eens aan de slag gegaan.

Voor de installatie procedure heb ik mogelijk een toevoeging. Ik heb het volgende in se-logger-service.sh toegevoegd

code:

#wait for mysql to come alive

while true; do
    response=`/usr/bin/mysqladmin -uUNKNOWN_USER ping 2>&1` && break
    echo "$response" | grep -q "mysqld is alive" && break
    sleep 1
done

Ik had het probleem dat de liveupdate.log een error liet zien ivm het feit dat mysql nog niet klaar was.

Het kan zijn dat er betere oplossingen zijn maar het werkt.

Nu alleen wachten op de omvormer en kijken of de pcap files goed verwerkt worden.

Ik vond je website voorbeeld er al heel aardig uit zien.

Bedoel je onderstaande error? Die krijg ik heel af en toe op het moment dat de omvormer ontwaakt. waarom dit op onwillekeurige momenten gebeurd ben ik nog niet achter.

PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' in /opt/se-logger/pvo-upload.php:16
Stack trace:
#0 /opt/se-logger/pvo-upload.php(16): PDO->__construct('mysql:host=loca...', 'root', '[your_password]', Array)
#1 {main}
  thrown in /opt/se-logger/pvo-upload.php on line 16
PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[42S02]: Base table or view not found: 1146 Table 'solaredge.telemetry_inverter' doesn't exist' in /opt/se-logger/pvo-upload.php:32
Stack trace:
#0 /opt/se-logger/pvo-upload.php(32): PDO->query('SELECT timestam...')
#1 {main}
  thrown in /opt/se-logger/pvo-upload.php on line 32

[Corn]

It verks! Stats:



Toegegeven; dit zou ook gewerkt hebben met de standaard API. Maar deze grafiekjes zijn geproduceerd zonder tussenkomst van de portal!

[Jerrythafast]

tinka schreef op woensdag 23 november 2016 @ 22:08:
Als voorbereiding op mijn installatie ook maar eens aan de slag gegaan.

Voor de installatie procedure heb ik mogelijk een toevoeging. Ik heb het volgende in se-logger-service.sh toegevoegd

code:

#wait for mysql to come alive

while true; do
    response=`/usr/bin/mysqladmin -uUNKNOWN_USER ping 2>&1` && break
    echo "$response" | grep -q "mysqld is alive" && break
    sleep 1
done

Ik had het probleem dat de liveupdate.log een error liet zien ivm het feit dat mysql nog niet klaar was.

Het kan zijn dat er betere oplossingen zijn maar het werkt.

Nu alleen wachten op de omvormer en kijken of de pcap files goed verwerkt worden.

Ik vond je website voorbeeld er al heel aardig uit zien.

Dank voor je aanvulling. Ben er zelf nooit tegenaan gelopen dat solaredge-logger startte vóór mysqld. Als dit inderdaad een issue is kun je het beste de .service file aanpassen zodat de service niet start zonder mysqld.

Aegle schreef op donderdag 24 november 2016 @ 15:22:
[...]

Bedoel je onderstaande error? Die krijg ik heel af en toe op het moment dat de omvormer ontwaakt. waarom dit op onwillekeurige momenten gebeurd ben ik nog niet achter.

PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' in /opt/se-logger/pvo-upload.php:16
Stack trace:
#0 /opt/se-logger/pvo-upload.php(16): PDO->__construct('mysql:host=loca...', 'root', '[your_password]', Array)
#1 {main}
  thrown in /opt/se-logger/pvo-upload.php on line 16
PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[42S02]: Base table or view not found: 1146 Table 'solaredge.telemetry_inverter' doesn't exist' in /opt/se-logger/pvo-upload.php:32
Stack trace:
#0 /opt/se-logger/pvo-upload.php(32): PDO->query('SELECT timestam...')
#1 {main}
  thrown in /opt/se-logger/pvo-upload.php on line 32

Dat is dan toch een ander probleem, want die error komt uit pvo-upload.php wat los staat van de se-logger service waar tinka problemen mee ondervond. Deze error kan ik echt niet verklaren, het lijkt wel of je mysql server opeens weg is Ik heb hier in 9 maanden tijd trouwens nog nooit een mysql-gerelateerde error in mijn pvo-upload.log gehad. Het enige wat ik daarin kan terugvinden is network outage en PVOutput downtime.

Corn schreef op donderdag 24 november 2016 @ 19:59:
It verks! Stats:

[afbeelding]

Toegegeven; dit zou ook gewerkt hebben met de standaard API. Maar deze grafiekjes zijn geproduceerd zonder tussenkomst van de portal!

Gaaaf!

[Voor 6% gewijzigd door Jerrythafast op 24-11-2016 22:28]

[Aegle]

Deze fout is pas van de laatste paar maanden. Voorheen, toen de RPI2 nog ontelbare andere services draaide, trad dit nooit op. Een paar maanden terug heb ik de RPI2 dedicated ingezet om alleen de SE-logger te draaien. sindsdien is het een keer of 5 voorgekomen. als ik de logger-service stop en weer start, draait ie weer als een zonnetje.

en nu je het zegt, het lijkt inderdaad geen SQL issue. de .pcap wordt ook niet meer geschreven.

Het hinderlijke is dat ik er pas achter kom als PVoutput mij een mailtje stuurt dat ie langer dan een half uur geen data meer ontvangen heeft...

@Corn: hoe heb je die grafiek gegenereerd? komt dat uit een slimme meter of zo? inderdaad gaaf!

[Corn]

Aegle schreef op donderdag 24 november 2016 @ 22:48:
@Corn: hoe heb je die grafiek gegenereerd? komt dat uit een slimme meter of zo? inderdaad gaaf!

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:

[tinka]

Jerrythafast schreef op donderdag 24 november 2016 @ 22:27:
[...]
Dank voor je aanvulling. Ben er zelf nooit tegenaan gelopen dat solaredge-logger startte vóór mysqld. Als dit inderdaad een issue is kun je het beste de .service file aanpassen zodat de service niet start zonder mysqld.
[...]

Probleem was dat ik niet de weet of het bv mysqld.service is of iets anders. Met 'systemctl list-unit-files' kwam ik sql niet tegen. Linux is niet dagelijkse kost voor mij dus daarom maar op deze alternatieve manier.

[Aegle]

@ corn: bedankt voor de "sfeerfoto's" . Dit soort metingen doe ik met een S0-kWh-meter aan een Netduino met DAL en tevens de S0-puls electrisch gekoppeld aan een Youless. Werkt prima.

Terug ontopic:

sindse een tijdje merk ik dat een paar keer week de liveupdate.log de volgende error geeft:

pi@rpi2-solarlogger:/opt/se-logger $ cat liveupdate.log
Reading from -
Traceback (most recent call last):
  File "/opt/se-logger/liveupdate.py", line 399, in <module>
    telem)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in execute
    self.errorhandler(self, exc, value)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
_mysql_exceptions.OperationalError: (2006, 'MySQL server has gone away')
Exception AttributeError: "'NoneType' object has no attribute 'error'" in <generator object get_data_from_pcap at 0x765371c0> ignored
pi@rpi2-solarlogger:/opt/se-logger $

Met mijn beperkte kennis lees ik dat mysql niet draait, maar dat is zeker niet het geval.
De foutmelding doet zich voor zodra de omvormer 's ochtends opstart.

Na het herstarten van de logger service loopt alles weer normaal en logt ie weer.
Het vreemde is dat er niets aan de configuratie gewijzigd is. Voorheen had ik hier nooit last van. Nu controleer ik elke morgen of dit zich voordoet. Niet echt handig .

[Jerrythafast]

Hmm, ik denk dat ik liveupdate.py wat robuuster moet maken wat betreft de database connectie. Schijnbaar gaat dat bij jullie toch niet altijd goed

Ter informatie, ik draai MySQL Server 5.7.16 en MySQLdb versie 1.3.7. De MySQL server draait bij mij op dezelfde RPi die ook solaredge-logger draait.

jerry@logger:~$ mysqld --version
mysqld  Ver 5.7.16-0ubuntu0.16.04.1 for Linux on armv7l ((Ubuntu))
jerry@logger:~$ python -c "from MySQLdb import __version__; print __version__"
1.3.7

[Voor 9% gewijzigd door Jerrythafast op 02-12-2016 12:20]

[Pietjebel10]

Ik heb ongeveer dezelfde configuratie als Jerry, alles op de Raspberry 3 met Rasbian geen enkel probleem alles loopt gewoon door. geen herstart nodig

mysqld Ver 5.5.52-0+deb8u1 for debian-linux-gnu on armv7l ((Raspbian))

[Quinie]

Bedankt voor alle informatie. Ik ben ondertussen als een linux leek de boel aan het installeren.
Paar kleine opmerkingen zover.

installeer isc-dhcp-server (apt-get) was even uitzoeken voor een leek.

sla het script op als se-nat.sh...
test nat.sh
zou moeten zijn test se-nat.sh

activeer de service...
sudo systemctl --no-wall enable se-logger (denk ik)

Verder goed te volgen met een beetje logica.

[Jerrythafast]

Quinie schreef op vrijdag 2 december 2016 @ 12:43:
sla het script op als se-nat.sh...
test nat.sh
zou moeten zijn test se-nat.sh

Fixed, dankjewel

activeer de service...
sudo systemctl --no-wall enable se-logger (denk ik)

Hmm, mijn systemctl heeft geen --no-wall optie, het was echt --now. Is dat zo speciaal dat ik die heb?

[Quinie]

Hier in ieder geval niet.
http://www.ebugg-i.com/te...temctl-linux-command.html

op andere sites zie ik hem wel voorbij komen. Mijn PI kent het niet.
Maar ik begrijp een enable en start voldoet ook ?

ps. zat nog een foutje in de zin sudo systemctl se-nat = se-logger (denk ik)

[Aegle]

Jerrythafast schreef op vrijdag 2 december 2016 @ 12:19:
Hmm, ik denk dat ik liveupdate.py wat robuuster moet maken wat betreft de database connectie. Schijnbaar gaat dat bij jullie toch niet altijd goed

Ter informatie, ik draai MySQL Server 5.7.16 en MySQLdb versie 1.3.7. De MySQL server draait bij mij op dezelfde RPi die ook solaredge-logger draait.

jerry@logger:~$ mysqld --version
mysqld  Ver 5.7.16-0ubuntu0.16.04.1 for Linux on armv7l ((Ubuntu))
jerry@logger:~$ python -c "from MySQLdb import __version__; print __version__"
1.3.7

Dit zijn de versies die op mijn RPi2 draaien. Ook hier draait de logging software op dezelfde RPi als de database server. De RPi is dedicated voor de logging. Ik heb als OS Debian Jessie Lite geinstalleerd.

mysql  Ver 14.14 Distrib 5.5.52, for debian-linux-gnu (armv7l) using readline 6.3
mysqld  Ver 5.5.52-0+deb8u1 for debian-linux-gnu on armv7l ((Raspbian))
root@rpi2-solarlogger:/opt/se-logger# python -c "from MySQLdb import __version__; print __version__"
1.2.3
root@rpi2-solarlogger:/opt/se-logger#

Ik krijg er geen vinger achter onder welke omstandigheden de fout zich voor doet. Het is willekeurig. Soms een paar dagen achter elkaar, soms weer een week niet.
Het is ook iets van pakweg sinds een maand of twee. Daarvoor nergens last van...

Ik gebruik

code:

service se-logger stop

en

code:

service se-logger start

om de logging te stoppen en te starten.

[Voor 4% gewijzigd door Aegle op 02-12-2016 17:07]

[Jerrythafast]

Quinie schreef op vrijdag 2 december 2016 @ 15:24:
Hier in ieder geval niet.
http://www.ebugg-i.com/te...temctl-linux-command.html

op andere sites zie ik hem wel voorbij komen. Mijn PI kent het niet.
Maar ik begrijp een enable en start voldoet ook ?

ps. zat nog een foutje in de zin sudo systemctl se-nat = se-logger (denk ik)

Jep, bij Ubuntu 16.04 heb ik een --now optie, welke enable en start in één commando mogelijk maakt. Ik heb het nu in de OP aangepast naar twee losse commando's.

De systemctl regel moest wel se-nat zijn, maar de NAT service file moest natuurlijk niet se-logger.service maar se-nat.service heten. Dat heb ik wel even gefixt in de tekst.

Aegle schreef op vrijdag 2 december 2016 @ 17:04:
[...]


Dit zijn de versies die op mijn RPi2 draaien. Ook hier draait de logging software op dezelfde RPi als de database server. De RPi is dedicated voor de logging. Ik heb als OS Debian Jessie Lite geinstalleerd.

mysql  Ver 14.14 Distrib 5.5.52, for debian-linux-gnu (armv7l) using readline 6.3
mysqld  Ver 5.5.52-0+deb8u1 for debian-linux-gnu on armv7l ((Raspbian))
root@rpi2-solarlogger:/opt/se-logger# python -c "from MySQLdb import __version__; print __version__"
1.2.3
root@rpi2-solarlogger:/opt/se-logger#

Ik krijg er geen vinger achter onder welke omstandigheden de fout zich voor doet. Het is willekeurig. Soms een paar dagen achter elkaar, soms weer een week niet.
Het is ook iets van pakweg sinds een maand of twee. Daarvoor nergens last van...

Ik gebruik

code:

service se-logger stop

en

code:

service se-logger start

om de logging te stoppen en te starten.

Je start/stop code is prima. Jouw versies zijn wel wat ouder, dat maakt het voor mij erg makkelijk om daar de oorzaak in te zoeken Als je mysql-server en python-mysqldb met apt niet geupdatet krijgt kun je eventueel python-mysqldb removen en via pip de nieuwste installeren:

user@logger$  pip install mysqlclient

Ik zal dit weekend even kijken wat er voor nodig is om hem wat minder gevoelig voor database failures te maken.

[Aegle]

Momenteel draai ik nog V0.0.3 van de SE-logger. Nu heb ik geen tijd, maar zal morgen mysql* eens updaten.

Tevens weer eens verder stoeien met Highcharts...

[Quinie]

Ik denk bijna alles werkend te hebben alleen.. nu crashed hij op de pcap files.
het format zou niet goed zijn. na 4 keer doet hij een shutdown. Iemand een idee ?

Ondertussen van raspberry leek naar beginner gegaan
DHCP kwam ik met de handleiding ook niet helemaal uit maar google heeft geholpen.

[Jerrythafast]

Quinie schreef op zaterdag 3 december 2016 @ 12:42:
Ik denk bijna alles werkend te hebben alleen.. nu crashed hij op de pcap files.
het format zou niet goed zijn. na 4 keer doet hij een shutdown. Iemand een idee ?

Ondertussen van raspberry leek naar beginner gegaan
DHCP kwam ik met de handleiding ook niet helemaal uit maar google heeft geholpen.

Almost there! Het format is verkeerd... dan ben ik even benieuwd hoe jouw PCAP file eruit ziet. Ik neem aan dat je "ERROR! PCAP format not supported! Can only read little-endian PCAP files with microsecond precision!" krijgt? Eventueel zou je het betreffende bestand even door dit commando kunnen halen:

python -c 'import sys;f=open(sys.argv[1],"r");print(" ".join("%02X" % ord(x) for x in f.read(24)));f.close()' /opt/se-logger/solaredge-20161203??????.pcap

Dat geeft de header (eerste 24 bytes) van het PCAP bestand, wellicht is daar al aan te zien wat er loos is. Geeft bij mij:

code:

D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00 00 00 04 00 01 00 00 00

[Voor 5% gewijzigd door Jerrythafast op 03-12-2016 12:53]

[Quinie]

Ga ik zo even doen. Dat is inderdaad de melding die ik krijg.
Maar het moet vandaag even tussen de bedrijven door testen. Ik laat het je weten.

[Quinie]

De pcap files zijn leeg en ik mis de 2 log files. Deze worden niet aangemaakt de liveupdate.l$ daarin tegen wel. Een tip in een richting zou fijn zijn.

found it: de se-logger-service.sh was niet goed overgekomen. Eigen domme schuld was de inhoud hiervan niet helemaal in de file gekomen.

Morgen maar is aan de optimizer inverter hangen

[Voor 39% gewijzigd door Quinie op 03-12-2016 21:24]

[Jerrythafast]

Mooi dat het is gelukt Ik had al een hele troubleshooting post gemaakt, maar je was me dus voor

[Voor 90% gewijzigd door Jerrythafast op 03-12-2016 21:17]

[Quinie]

De tip dat ze leeg waren deed me genoeg zoeken het moest de tcpdump regel zijn.
Maar bedankt voor de moeite.. hou die post achter de hand voor de volgende

Volgende stap is aanpassen naar influxdb maar dat is iets voor later nu eerst de p1 eraan hangen.

[Voor 24% gewijzigd door Quinie op 03-12-2016 21:25]

[tjanssen]

Heeft er iemand ervaring met een USB LAN adapter op een Pi 3? Wil eigenlijk wegblijven van wifi..

[Jerrythafast]

Volgens mij zijn de meeste van die dingen plug-and-play. Je krijgt er dan een eth1 interface bij.

Kleine disclaimer, ik zeg dit dus zonder ervaring. Zelf heb ik geen Pi3 maar een Pi2, geen Raspbian maar Ubuntu en geen USB LAN adapter maar een USB WiFi stick uit het vorige decennium. Voor mijn WiFi stick moest ik alleen nog even linux-firmware-nonfree installeren, want dat ding had blijkbaar een propriëtaire driver nodig.

[tinka]

tjanssen schreef op vrijdag 9 december 2016 @ 19:58:
Heeft er iemand ervaring met een USB LAN adapter op een Pi 3? Wil eigenlijk wegblijven van wifi..

Ik heb het geheel draaien (pi 3) met een bridge br0 op eth0, eth1 en wlan0. Ik weet nog niet of mijn omvormer via eth1 of wlan0 wordt aangesloten.

Ik had behoorlijk wat problemen met met het ip adres. Zie ook https://www.raspberrypi.o...ewtopic.php?f=28&t=111709. Voor mijn gevoel lopen er wat dingen door elkaar heen met definities in /etc/network/interfaces en een dhcpd configuratie. Uiteindelijk maar gekozen voor dhcp met in /etc/network/interfaces manual en ignore voor eth0, eth1 en wlan0 in de dhcpd config file. Het idee is dan lijkt me dat alleen br0 een ip adres krijgt.

Nu draait het goed. Het enige is dat ik in eerste instantie twee ip adressen krijg. Na enige tijd blijft daar 1 van over. Waarschijnlijk heel verklaarbaar maar

[Jerrythafast]

tinka schreef op vrijdag 9 december 2016 @ 21:34:
[...]


Ik heb het geheel draaien (pi 3) met een bridge br0 op eth0, eth1 en wlan0. Ik weet nog niet of mijn omvormer via eth1 of wlan0 wordt aangesloten.

Ik had behoorlijk wat problemen met met het ip adres. Zie ook https://www.raspberrypi.o...ewtopic.php?f=28&t=111709. Voor mijn gevoel lopen er wat dingen door elkaar heen met definities in /etc/network/interfaces en een dhcpd configuratie. Uiteindelijk maar gekozen voor dhcp met in /etc/network/interfaces manual en ignore voor eth0, eth1 en wlan0 in de dhcpd config file. Het idee is dan lijkt me dat alleen br0 een ip adres krijgt.

Nu draait het goed. Het enige is dat ik in eerste instantie twee ip adressen krijg. Na enige tijd blijft daar 1 van over. Waarschijnlijk heel verklaarbaar maar

Als je je netwerkinterfaces bridget en elders in je netwerk al een DHCP server hebt draaien, heb je geen DHCP nodig op je Pi. De omvormer kan dan gewoon een IP-adres krijgen van die andere DHCP-server. (Het is niet de bedoeling dat je sectie 4.1 én sectie 4.2 doet. Daar wordt je netwerkconfiguratie inderdaad een aardige puinhoop van...)

[tinka]

Ik had het idee dat https://www.daemon-systems.org/man/dhcpcd.conf.5.html een client was.
Mijn idee was om een ip aan de bridge te hangen via dhcp.

Echter alleen /etc/network/interfaces te configureren bleek niet genoeg. Ik kwam vervolgens uit bij dhcpcd. Ik heb de indruk dat die nu het ip adres opvraagt.

Ah, 1 link https://www.daemon-systems.org/man/dhcpcd.8.html dieper staat dat het (gelukkig) inderdaad een client is.

En nu zie ik ook de verwarring. Het gaat dus bij mij om dhcpcd en niet dhcpd.

[Voor 76% gewijzigd door tinka op 09-12-2016 22:29]

[Jerrythafast]

Haha, juist. Die extra c staat natuurlijk voor Client Klein maar cruciaal verschilletje

[Voor 3% gewijzigd door Jerrythafast op 09-12-2016 22:49]

[Pietjebel10]

tjanssen schreef op vrijdag 9 december 2016 @ 19:58:
Heeft er iemand ervaring met een USB LAN adapter op een Pi 3? Wil eigenlijk wegblijven van wifi..

Ik gebruik hier de TP-Link UE300 USB 3.0 to Gigabit Ethernet Network Adapter. Deze is plug and play voor de raspberry
Kijk even hier http://elinux.org/RPi_USB_Ethernet_adapters hier staat ook van alles, ik heb ook anderen getest eentje van Dell werkte ook perfect, maar wordt dan gezien als USB1. Zorg in ieder geval dat die Linux ondersteunt succes

[Quinie]

Ondertussen draait het meeste hier alleen het uploaden naar pvoutput werkt nog niet.
De log word niet aangemaakt. Cron job lijkt wel te lopen iedere 2 minuten.

Ideeen ?

[Aegle]

Mmm. Heb je je System-ID en API-key van PVoutput correct ingevuld...?

[Jerrythafast]

Quinie schreef op zaterdag 10 december 2016 @ 17:48:
Ondertussen draait het meeste hier alleen het uploaden naar pvoutput werkt nog niet.
De log word niet aangemaakt. Cron job lijkt wel te lopen iedere 2 minuten.

Ideeen ?

Jerrythafast schreef op maandag 21 november 2016 @ 20:06:
Ik wil het enthousiasme niet temperen, maar toch een kleine disclaimer: solaredge-logger v0.0.7 (welke sinds gisteravond online staat) ondersteunt wel het uitlezen van 3-fase omvormers, maar niet het uploaden van 3-fase omvormerdata naar PVOutput. Hier moet ik nog even aan rommelen.

[Quinie]

Helder

[Aegle]

Hopelijk kom ik van onderstaande melding af als ik m'n good old versie update naar versie 0.0.7. De melding komt steeds vaker voor tijdens het wakker worden van de inverter. Het zorgt er voor dat er niets meer wordt gelogd. Ik moet de logger service handmatig stoppen en weer starten. De rest van de dag blijft het draaien als een zonnetje.

Om database ellende te voorkomen wil ik mijn huidige database blijven gebruiken. Dus zonder de nieuwe 3-fase inverter tabel.
Als ik liveupdate.py goed lees (ik ben geen programmeur...), dan schrijft ie alleen naar de 3-fase inverter tabel wanneer er 3-fase data aanwezig is. Klopt mijn zienswijze? Of sla ik de plank helemaal mis? Mijn enige doel is om van onderstaande foutmelding af te komen:

Reading from -
Traceback (most recent call last):
  File "/opt/se-logger/liveupdate.py", line 399, in <module>
    telem)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in execute
    self.errorhandler(self, exc, value)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
_mysql_exceptions.OperationalError: (2006, 'MySQL server has gone away')
Exception AttributeError: "'NoneType' object has no attribute 'error'" in <generator object get_data_from_pcap at 0x7650d1c0> ignored

Jerrythafast schreef op maandag 21 november 2016 @ 20:06:
Ik wil het enthousiasme niet temperen, maar toch een kleine disclaimer: solaredge-logger v0.0.7 (welke sinds gisteravond online staat) ondersteunt wel het uitlezen van 3-fase omvormers, maar niet het uploaden van 3-fase omvormerdata naar PVOutput. Hier moet ik nog even aan rommelen.

[...]

Voor de timestamps zijn in MySQL UNIX_TIMESTAMP(date) en FROM_UNIXTIME(unix_timestamp) erg handig.

[Quinie]

lijkt me eerder dat je problemen hebt met je mysql server
(2006, 'MySQL server has gone away')

kijk is in de error log van je mysql server

[Jerrythafast]

Aegle schreef op zondag 11 december 2016 @ 16:34:
Hopelijk kom ik van onderstaande melding af als ik m'n good old versie update naar versie 0.0.7. De melding komt steeds vaker voor tijdens het wakker worden van de inverter. Het zorgt er voor dat er niets meer wordt gelogd. Ik moet de logger service handmatig stoppen en weer starten. De rest van de dag blijft het draaien als een zonnetje.

Om database ellende te voorkomen wil ik mijn huidige database blijven gebruiken. Dus zonder de nieuwe 3-fase inverter tabel.
Als ik liveupdate.py goed lees (ik ben geen programmeur...), dan schrijft ie alleen naar de 3-fase inverter tabel wanneer er 3-fase data aanwezig is. Klopt mijn zienswijze? Of sla ik de plank helemaal mis? Mijn enige doel is om van onderstaande foutmelding af te komen:

Reading from -
Traceback (most recent call last):
  File "/opt/se-logger/liveupdate.py", line 399, in <module>
    telem)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in execute
    self.errorhandler(self, exc, value)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
_mysql_exceptions.OperationalError: (2006, 'MySQL server has gone away')
Exception AttributeError: "'NoneType' object has no attribute 'error'" in <generator object get_data_from_pcap at 0x7650d1c0> ignored

[...]

Er zal inderdaad geen "table does not exist" crash/foutmelding komen zolang je geen 3-fase omvormer aansluit, dus je hoeft je database in jouw geval niet aan te passen. Dat gezegd hebbende: het kan geen kwaad om het CREATE TABLE statement van de 3-fasentabel uit te voeren, je huidige tabellen blijven immers onaangeroerd.

Maar net zoals Quinie hierboven verwacht ik niet dat je met een nieuwe versie van se-logger opeens geen last meer hebt van het wegvallen van de MySQL server. Immers zit dat ergens in de onderliggende lagen. Ik ben er nog niet aan toe gekomen liveupdate.py aan te passen om hier clean mee om te kunnen gaan.

[Aegle]

Wel vreemd dat mysql gewoon draait en blijft draaien. Ik hoef alleen de logger te stoppen en te herstarten. /var/log/mysql/error.log is leeg doordat default de logs disabled zijn. Ik heb nu de mysql logs ge-enabled. Morgenochtend maar eens in de gaten houden en kijken wat er in staat.

@ Jerry: Ik zal het netjes doen en de tabel alsnog aanmaken...

[Quinie]

Aegle schreef op zondag 11 december 2016 @ 17:53:
Wel vreemd dat mysql gewoon draait en blijft draaien.

mijn vermoeden is een restart van mysql, ergens die jij niet ziet. Logger is connectie kwijt en bouwt die opnieuw op bij restart.

mysql valt weer weg. restart weer.. connectie drop.. etc

[Jerrythafast]

Dat, of er is een timeout in MySQL ingesteld die verbindingen waar de hele nacht niks op gebeurt eruit gooit. De crash gebeurt schijnbaar bij de eerste query in de ochtend.

Ik ben er intussen even aan aan het rommelen.

[Aegle]

Als het gebeurd is het eenmalig in de ochtend bij het ontwaken van de omvormer. Wat mij bevreemd is dat het niet elke dag gebeurd. Wel heb ik de indruk dat het steeds frequenter voorkomt. Eerst was het een keer in de twee, drie weken. De laatste weken toch wel een paar keer per week en de afgelopen week op één dag na elke dag...

Morgen maar eens zien wat er in de errorlog van mysql staat. die heb ik nu ingeschakeld.

[Voor 20% gewijzigd door Aegle op 11-12-2016 19:41]

[Jerrythafast]

Aegle schreef op zondag 11 december 2016 @ 19:39:
Als het gebeurd is het eenmalig in de ochtend bij het ontwaken van de omvormer. Wat mij bevreemd is dat het niet elke dag gebeurd. Wel heb ik de indruk dat het steeds frequenter voorkomt. Eerst was het een keer in de twee, drie weken. De laatste weken toch wel een paar keer per week en de afgelopen week op één dag na elke dag...

Morgen maar eens zien wat er in de errorlog van mysql staat. die heb ik nu ingeschakeld.

Die ene dag was misschien dinsdag (6 december)? Ik weet nu bijna zeker dat het de MySQL wait_timeout setting is die jou parten speelt. Die staat standaard op 8 uur. De crontab regels die bij solaredge-logger worden gegeven zorgen ervoor dat de service om half 1 's nachts wordt herstart. Dus dat betekent dat je MySQL verbinding door de server wordt verbroken om half 9 's ochtends. Als de omvormer pas daarna wakker wordt heb je een crash.

Waarom overkomt mij dit dan niet? Ik heb mijn Pi op UTC tijd laten staan. Bij mij wordt de service dus om 00:30 UTC == 01:30 CET herstart. Ik zou dit probleem pas krijgen als de omvormer om half 10 pas wakker wordt Zelfs op de recorddag van gisteren was hij om 9:18 CET wakker (het zou nog een uur duren voordat er daadwerkelijk energie uit kwam...)

EDIT: Ik heb v0.0.8 ter testen aan Aegle voorgelegd...

[Voor 15% gewijzigd door Jerrythafast op 11-12-2016 21:10]

[Aegle]

He... dat is een plausibel antwoord. Morgen controleer ik de opstart tijden van afgelopen maand. Ik heb de data genoteerd wanneer ik opnieuw moest opstarten.

Als ik bijtijds thuis ben ga ik je laatste versie straks nog testen. Dank voor het meedenken .

EDIT: het ik half twaalf... Ik ga nu naar bed.. .
ik meld me morgen weer.

[Voor 13% gewijzigd door Aegle op 11-12-2016 23:30]