[SolarEdge] Omvormers en optimizers zelf monitoren

[charlygolf]

Niek_ schreef op woensdag 18 juli 2018 @ 16:21:
Kan je trouwens met de modbusmeter per fase de belasting zien? In de grafieken kan ik dit onderscheid volgens mij niet maken, wellicht in de data wel?

Op het display van mijn InePro Pro380 Mod wel data per fase, of het in de modbus communicatie voorbij komt weet ik niet, maar ik denk van wel.

Op het display van mijn omvormer niet (alleen totaalverbruik) en ook in de datastroom tussen mijn omvormer en SE heb ik alleen totaalverbruiksdata over alle fases samen kunnen vinden.

Mijn modbus meter is geconfigureerd als verbruiksmeter.

De eigen SolarEdge modbus meter heeft geen display, hetgeen voor mij reden was om de enige andere supported modbusmeter te kiezen.

[Niek_]

charlygolf schreef op woensdag 25 juli 2018 @ 09:02:
[...]


Op het display van mijn InePro Pro380 Mod wel data per fase, of het in de modbus communicatie voorbij komt weet ik niet, maar ik denk van wel.

Op het display van mijn omvormer niet (alleen totaalverbruik) en ook in de datastroom tussen mijn omvormer en SE heb ik alleen totaalverbruiksdata over alle fases samen kunnen vinden.

Mijn modbus meter is geconfigureerd als verbruiksmeter.

De eigen SolarEdge modbus meter heeft geen display, hetgeen voor mij reden was om de enige andere supported modbusmeter te kiezen.

He bah, kan niet altijd mee zitten

[stefxx]

Ik heb een SolarEdge omvormer uit 2013. CPU versie is 2.1049. Ik log al jaren via RS485 (naast de normale SolarEdge monitoring via internet), er bestond in 2013 nog niet eens een API. Maar het stoort me al jaren dat ik geen paneel informatie heb...

Dus ik vond dit geweldige project! Gelijk aan de slag gegaan, en alles werkt... totdat het lijkt dat mijn verkeer, ondanks CPU 2.x toch encrypted is. Ik zie namelijk dit in liveupdate.log:

code:

Warning! Got 22 mysterious bytes left! (state=0)
e6 79 0a 5c f8 b3 4d df 01 23 92 05 6e a4 4e 1e 6b 37 b7 12 9f dc
Warning! Got 22 mysterious bytes left! (state=0)
77 b8 5a 12 07 bd d7 e5 af 3b 71 92 a4 02 e9 44 5a 49 18 7c ef cb
Warning! Got 22 mysterious bytes left! (state=0)
7f 1d 0d c8 66 7f e3 28 25 44 c9 69 e5 d6 81 3d 94 5a fe 5c ec c1
Warning! Got 230 mysterious bytes left! (state=0)
59 d3 58 52 ac 3c 69 b7 80 08 b7 f6 93 fd 52 62 2e 3b db 34 04 df 98 ef 22 cc 8e 8f 43 df e1 0b a5 99 c5 3a 63 00 ec 17 9e b7 f2 73 c0 ... etc

Geen paniek, dan moeten we dus de key uitlezen. USB in de omvormer en gaan met die banaan... dacht ik dus. Dit is de output:

code:

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

En nu zit ik dus een beetje vast. Kan iemand me een zetje geven?

Dank!

[Jerrythafast]

stefxx schreef op zondag 29 juli 2018 @ 21:25:
Ik heb een SolarEdge omvormer uit 2013. CPU versie is 2.1049. Ik log al jaren via RS485 (naast de normale SolarEdge monitoring via internet), er bestond in 2013 nog niet eens een API. Maar het stoort me al jaren dat ik geen paneel informatie heb...

Dus ik vond dit geweldige project! Gelijk aan de slag gegaan, en alles werkt... totdat het lijkt dat mijn verkeer, ondanks CPU 2.x toch encrypted is. Ik zie namelijk dit in liveupdate.log:

code:

Warning! Got 22 mysterious bytes left! (state=0)
e6 79 0a 5c f8 b3 4d df 01 23 92 05 6e a4 4e 1e 6b 37 b7 12 9f dc
Warning! Got 22 mysterious bytes left! (state=0)
77 b8 5a 12 07 bd d7 e5 af 3b 71 92 a4 02 e9 44 5a 49 18 7c ef cb
Warning! Got 22 mysterious bytes left! (state=0)
7f 1d 0d c8 66 7f e3 28 25 44 c9 69 e5 d6 81 3d 94 5a fe 5c ec c1
Warning! Got 230 mysterious bytes left! (state=0)
59 d3 58 52 ac 3c 69 b7 80 08 b7 f6 93 fd 52 62 2e 3b db 34 04 df 98 ef 22 cc 8e 8f 43 df e1 0b a5 99 c5 3a 63 00 ec 17 9e b7 f2 73 c0 ... etc

Geen paniek, dan moeten we dus de key uitlezen. USB in de omvormer en gaan met die banaan... dacht ik dus. Dit is de output:

code:

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

En nu zit ik dus een beetje vast. Kan iemand me een zetje geven?

Dank!

Gebruik python2 ipv python3

[stefxx]

Jerrythafast schreef op zondag 29 juli 2018 @ 23:09:
[...]

Gebruik python2 ipv python3

Top, dat werkt wel!

[stefxx]

Alles werkt, wat een geweldige info hier te vinden. Nu alleen nog een knappe site bouwen.

Ik zie de site van andrerij uitgelegd in dit topic, maar volgens mij mis ik die van Jerrythafast, die me net iets meer aanspreekt. Heb je ooit tijd gezien deze op github te zetten of wil je hem op een andere manier wellicht delen?

Dank!!

[Gasschuif]

Vanmorgen zag ik op mijn SE 5 k HD wave het display om een uur of 12 een dag kWh stand die niet klopt met de werkelijkheid, veel minder.... er stonden nog Wh getallen.

Op de omvormer nu 11 kWh, op de SE portal de werkelijke stand 27,1 as we speak. Meer tweekers met dit probleem. ?

[ocaj]

Zowel de optimizers als de omvormer hebben af en toe een hikje dat ze denken dat er een nieuwe dag begonnen is. Maar in mijn beleving gebeurt dat alleen bij extreme regen waarbij het zo donker wordt dat je binnen de lampen aan gaat doen. Bij de optimizers gebeurt het wat sneller, omdat die geen geheugen hebben, zodra het paneel te weinig stroom levert voor de optimizer, dan gaat de optimizer gewoon uit.
Ik kan me niet zo goed voorstellen dat dat vandaag rond een uur of 12 zo was (of er was een hele lokale zonsverduistering?), dus misschien is er iets anders aan de hand?
Kan het zijn dat je omvormer even uit is geweest, misschien vanwege te hoge spanning aan de AC-kant?

(ik verwerk 's nachts de dag-resultaten in een aparte tabel met de dagtotalen, maxima etc. Daarbij liep ik ook aan tegen dit probleem, wat je vrij simpel kunt oplossen door bij te houden of je op dezelfde dag ineens een lagere waarde krijgt voor het dagtotaal en dan gewoon door te tellen. Iets vergelijkbaar zal de solaredge-portal ook doen)

[Verwijderd]

Goede dag allemaal,

Ik lees al een tijdje mee en heb een vraag.
Ik heb de configuratie tool van SolarEdge en nu lukt het niet om via rs485 de optimizers uit te lezen. Kan iemand opweg helpen?

Vergeet te vertellen welke omvormers

Beide zijn HD Wave versie.

[ Voor 15% gewijzigd door Verwijderd op 02-08-2018 10:58 ]

[ocaj]

Je kunt maar via 1 kanaal de monitorings-data uitlezen. Dus als je hem hebt ingesteld op de monitorings-portal via IP/ethernet, dan reageert de omvormer niet op RS485 voor de monitoringsdata.

Heb je hem wel ingesteld op RS485, of lees je hem ook via ethernet en de solaredge-app/portal uit?

[Verwijderd]

Ik heb inderdaad het portaal aan over ethernet.

[ocaj]

En als je de Server op RS485 zet? Krijg je dan wel de data binnen via RS485?

Overigens kun je voor RS485 ook nog een protocol kiezen. Via Solaredge-protocol krijg je alle data, via SunSpec alleen de inverter-data, geen optimizer-data.

(maar je moet inderdaad een keuze maken, als je RS485 wil gebruiken dan werkt ethernet niet meer en omgekeerd)

[Verwijderd]

De solaredge configuratie tool blijft maar zeggen dat de omvormer offline is en krijg geen optimizers data binnen.

Ps: er zit geen usb connector gesoldeerd.

[ Voor 16% gewijzigd door Verwijderd op 05-08-2018 08:25 ]

[ocaj]

@Verwijderd Maar hoe heb je hem nu aangesloten dan? RS485 is niet hetzelfde als USB. Waar heb je de RS485-connector op aangesloten? Via een USB-RS485 converter? Op en raspberry o.i.d.? Of gewoon op je computer met solaredge config tool?
(ik heb zelf overigens geen ervaring met het SE config tool, draait meen ik alleen onder windows)

[stefxx]

Ik probeer ook mijn verbruik te loggen naar pvoutput.org. Ik heb hiervoor een extra table aangemaakt (telemetry_smartmeter) in de solaredge MySQL database. Deze vul ik o.a. met het meter_id, timestamp en uiteraard de diverse meterstanden, welke ik vul vanuit de P1 port van mijn slimme meter.

Nou probeer ik de pvo-upload-3phase.php aan te passen om ook deze velden mee te kunnen nemen. Maar ik kom er niet uit, mijn SQL kennis schiet te kort.

Dit is de oorsponkelijke query:

code:

$q = $db->query(
  'SELECT timestamp, p_active, temperature, v_dc, se_day ' .
  'FROM (' .
    'SELECT ' .
      'timestamp, p_active1+p_active2+p_active3 p_active, temperature, v_dc, ' .
      '@curdate := FROM_UNIXTIME(timestamp, "%Y%m%d") date, ' .
      '@prevsum := IF(@prevdate = @curdate, @prevsum + de_day, de_day) se_day, ' .
      '@prevdate := @curdate date2 ' .
    'FROM telemetry_inverter_3phase ' .
    'JOIN (SELECT @prevsum := 0, @curdate := NULL, @prevdate := NULL) vars ' .
    'WHERE timestamp >= (SELECT IFNULL(UNIX_TIMESTAMP(FROM_UNIXTIME(pvo_last_live, "%Y%m%d")), 0) FROM live_update) ' .
    'ORDER BY timestamp' .
  ') x ' .
  'WHERE timestamp > (SELECT pvo_last_live FROM live_update) ' .
  'LIMIT 30');

Iermand enig idee hoe ik deze al ingewikkelde query kan uitbreiden met een extra join op nearest timestamp uit de smartmeter tabel? Er zal iets bij moeten als:

code:

SELECT TOP 1 * FROM telemetry_smartmeter
ORDER BY ABS(timestamp - telemetry_inverter_3phase.timestamp)

Dank!

[stormfly]

Hoe doen jullie dat met de grootte van de pcap files? Tijdens het testen had ik even een poort van een pc gemonitoord, een pc in rust. Maar dat liep zover op, dat de disk van de server vol liep. (VM met 2.5 G vrij).

Hebben jullie een schatting hoeveel data e.a. op gaat leveren als je de SE omgeving uitleest?

[jacovn]

Het zal niet heel veel zijn omdat de meeste mensen het op kaartjes draaien.
8, 16, 32 gigabyte of zo denk ik.
Zelf voor een WD Pidrive (300 gb) gekozen, maar die is niet meer te koop.

[MDKlapwijk]

Ik heb m'n SE-6000 een vast IP via DHCP gegeven en filter op dat IP adres:

code:

root@domoticz-01:/opt/se-logger# cat se-logger-service.sh
#!/bin/bash

# SETTINGS
INTERFACE=eth0
FILTER=tcp
CAPTDIR=/opt/se-logger/
PREFIX=solaredge-


rm ${CAPTDIR}tcpdump.log
rm ${CAPTDIR}liveupdate.log

# wait for the time to get set
while [ `date -u +%Y` == "1970" ]
do
        echo "Waiting for correct time" >> ${CAPTDIR}tcpdump.log
        sleep 1
done

#/usr/bin/stdbuf -i0 -o0 -e0 /usr/sbin/tcpdump -i $INTERFACE -U -w - ${FILTER} 2>> ${CAPTDIR}tcpdump.log | \
/usr/bin/stdbuf -i0 -o0 -e0 /usr/sbin/tcpdump -i $INTERFACE -U -w - -n host 192.168.0.45 2>> ${CAPTDIR}tcpdump.log | \
        tee $CAPTDIR$PREFIX`date -u +%Y%m%d%H%M%S`.pcap | \
        /usr/bin/python -u ${CAPTDIR}liveupdate.py - 2>> ${CAPTDIR}liveupdate.log

code:

root@domoticz-01:/opt/se-logger# l -h
total 268M
drwxr-xr-x 2 root root   28K Aug 13 08:35 .
drwxr-xr-x 8 root root  4.0K Nov  2  2017 ..
-rw-r--r-- 1 root root    15 Aug 13 00:30 liveupdate.log
-rw-r--r-- 1 root root   22K Sep 20  2017 liveupdate.py
-rw-r--r-- 1 root root  2.3K Apr 17  2017 pvo-upload-3phase.php
-rw-r--r-- 1 root root  744K Aug 13 08:38 pvo-upload.log
-rw-r--r-- 1 root root  2.2K Sep 20  2017 pvo-upload.php
-rw-r--r-- 1 root root   645 Feb 15 10:51 se-logger-service.sh
-rw-r--r-- 1 root root  1.4K Sep 19  2017 solaredge-20170919212645.pcap
-rw-r--r-- 1 root root     0 Sep 19  2017 solaredge-20170919214338.pcap
-rw-r--r-- 1 root root     0 Sep 19  2017 solaredge-20170919214339.pcap
-rw-r--r-- 1 root root     0 Sep 19  2017 solaredge-20170919214340.pcap
-rw-r--r-- 1 root root   12K Sep 20  2017 solaredge-20170919214601.pcap
-rw-r--r-- 1 root root  6.8K Sep 20  2017 solaredge-20170919221254.pcap
-rw-r--r-- 1 root root   96K Sep 20  2017 solaredge-20170919223002.pcap
-rw-r--r-- 1 root root  590K Sep 20  2017 solaredge-20170920020020.pcap
-rw-r--r-- 1 root root  376K Sep 21  2017 solaredge-20170920112007.pcap
-rw-r--r-- 1 root root   94K Sep 21  2017 solaredge-20170920223001.pcap
-rw-r--r-- 1 root root  799K Sep 22  2017 solaredge-20170921020021.pcap
-rw-r--r-- 1 root root   99K Sep 22  2017 solaredge-20170921223001.pcap
...
-rw-r--r-- 1 root root  917K Aug  8 00:29 solaredge-20180806223001.pcap
-rw-r--r-- 1 root root  954K Aug  9 00:29 solaredge-20180807223002.pcap
-rw-r--r-- 1 root root  888K Aug 10 00:30 solaredge-20180808223002.pcap
-rw-r--r-- 1 root root  878K Aug 11 00:30 solaredge-20180809223001.pcap
-rw-r--r-- 1 root root  909K Aug 12 00:30 solaredge-20180810223001.pcap
-rw-r--r-- 1 root root  970K Aug 13 00:29 solaredge-20180811223002.pcap
-rw-r--r-- 1 root root  247K Aug 13 08:38 solaredge-20180812223002.pcap
-rw-r--r-- 1 root root    83 Aug 13 00:30 tcpdump.log

Maar als je een poort 1:1 afluistert zal het wel meevallen, de SE babbelt niet zo heel veel. Een monitor-poort die al het verkeer op de switch doorgooit is een heel ander verhaal....

[ Voor 56% gewijzigd door MDKlapwijk op 13-08-2018 08:42 ]

[stormfly]

Inderdaad niet heel veel het is een uniek vlan voor de SE, de linux server de de nat router voor dat segment. Er babbelt niets anders in, na wat opschonen op de VM is er 11G vrij. Volgens mij moet dat goed gaan komen

[ Voor 12% gewijzigd door stormfly op 13-08-2018 08:54 ]

[tsjoender]

stormfly schreef op maandag 13 augustus 2018 @ 07:18:
Hoe doen jullie dat met de grootte van de pcap files? Tijdens het testen had ik even een poort van een pc gemonitoord, een pc in rust. Maar dat liep zover op, dat de disk van de server vol liep. (VM met 2.5 G vrij).

Hebben jullie een schatting hoeveel data e.a. op gaat leveren als je de SE omgeving uitleest?

Zelf lees ik twee SE3000H omvormers uit en filter daarbij op de beide mac adressen om alleen de omvormer data te vangen. Dit doe ik sinds 28 december 2016 en op dit moment neemt dat 1,2 GB aan ruimte in (nog nooit pcaps weggegooid).

[Jerrythafast]

stormfly schreef op maandag 13 augustus 2018 @ 07:18:
Hoe doen jullie dat met de grootte van de pcap files? Tijdens het testen had ik even een poort van een pc gemonitoord, een pc in rust. Maar dat liep zover op, dat de disk van de server vol liep. (VM met 2.5 G vrij).

Hebben jullie een schatting hoeveel data e.a. op gaat leveren als je de SE omgeving uitleest?

Haha, die PC in rust was zeker updates gaan downloaden Hier gemiddeld 540 kB per dag over de afgelopen 2,5 jaar.

[ Voor 5% gewijzigd door Jerrythafast op 14-08-2018 21:02 ]

[teacher]

In het kader van durf te vragen:

Ik heb een raspberry pi 2 met klein touchscreentje erop. Nu is mijn plan om die in een behuizing te maken en daar dan full screen de live opbrengst van de omvormer op te laten zien.

1. Kan dit?
2. Zo ja: hoe?

Wie kan mij een zet in de goede richting geven? Thanks!

[Jerrythafast]

1. Ja, alles kan
2. Normaliter krijg je van je omvormer data per 5 minuten, dus 'live' is dan actueel tot op 5 minuten... Je zou het kunnen aanvliegen door met bv se-logger de data in een database te stoppen, en een webinterface zoals die van andrerij die je in dit topic kunt vinden erop te installeren. Open de webinterface in een browser op je Pi en run dat full-screen, daarmee ben je er wel.

Wil je sneller dan 5 minuten, dan is er wel iets via seriële verbinding te regelen (ik weet zo gauw even niet meer wat je precies moet doen, maar ik weet vrij zeker dat er een mogelijkheid is de omvormer zo te vragen om vaker data te geven). Of als alternatief kun je er een aparte meter tussen zetten die vaker uitgelezen kan worden. In beide gevallen wordt dat dus wel wat extra programmeerwerk om de benodigde tools te ontwikkelen

[ocaj]

1) Ja natuurlijk, alles kan !
2)
Simpelste is om een web-pagina te maken die zichzelf continu ververst. Als je dan de live-data bijvoorbeeld in een json-file dumpt, dan kun je dat simpel weer in je webpagina inlezen door een timer van 1 sec. of zo.

Ik ben zelf erg enthousiast over Highcharts als framework. Staan op de Highcharts-site ook voorbeelden voor live-updates en dat is niet moeilijk na te bouwen.

Om de SD-kaart te sparen zou ik wel in de webruimte een map maken die niet op je kaartje staat, maar op een ramdisk (hoeft maar een RAM-disk van een paar MB te zijn, dat is meer dan zat voor de live-data in json-formaat).

[AUijtdehaag]

Nu we het toch over vastlopende pi's hebben...
Waarom word er via pollin.de de odroid c2 met emmc, niet naar nederland verstuurd?
https://www.pollin.de/sea...Rg2HqCpQ0Q6g1BWwsDqorm78v

[ Voor 5% gewijzigd door AUijtdehaag op 15-08-2018 22:00 ]

[jacovn]

AUijtdehaag schreef op woensdag 15 augustus 2018 @ 21:59:
Nu we het toch over vastlopende pi's hebben...
Waarom word er via pollin.de de odroid c2 met emmc, niet naar nederland verstuurd?
https://www.pollin.de/sea...Rg2HqCpQ0Q6g1BWwsDqorm78v

Op hun website staan Nederland toch wel, en zelfs dat het 7.95 verzendkosten is.
Bedoel je dat een specifiek item niet opgestuurd kan worden ?

[AUijtdehaag]

@jacovn
Als je wilt afrekenen, krijg je de melding dan versturen naar nederland niet mogelijk is.

[teacher]

Huifkar.de

Jerrythafast schreef op woensdag 15 augustus 2018 @ 21:08:
1. Ja, alles kan
2. Normaliter krijg je van je omvormer data per 5 minuten, dus 'live' is dan actueel tot op 5 minuten... Je zou het kunnen aanvliegen door met bv se-logger de data in een database te stoppen, en een webinterface zoals die van andrerij die je in dit topic kunt vinden erop te installeren. Open de webinterface in een browser op je Pi en run dat full-screen, daarmee ben je er wel.

Wil je sneller dan 5 minuten, dan is er wel iets via seriële verbinding te regelen (ik weet zo gauw even niet meer wat je precies moet doen, maar ik weet vrij zeker dat er een mogelijkheid is de omvormer zo te vragen om vaker data te geven). Of als alternatief kun je er een aparte meter tussen zetten die vaker uitgelezen kan worden. In beide gevallen wordt dat dus wel wat extra programmeerwerk om de benodigde tools te ontwikkelen

ocaj schreef op woensdag 15 augustus 2018 @ 21:09:
1) Ja natuurlijk, alles kan !
2)
Simpelste is om een web-pagina te maken die zichzelf continu ververst. Als je dan de live-data bijvoorbeeld in een json-file dumpt, dan kun je dat simpel weer in je webpagina inlezen door een timer van 1 sec. of zo.

Ik ben zelf erg enthousiast over Highcharts als framework. Staan op de Highcharts-site ook voorbeelden voor live-updates en dat is niet moeilijk na te bouwen.

Om de SD-kaart te sparen zou ik wel in de webruimte een map maken die niet op je kaartje staat, maar op een ramdisk (hoeft maar een RAM-disk van een paar MB te zijn, dat is meer dan zat voor de live-data in json-formaat).

Thanks!

Ik had gehoopt dat ik het uit de standaard api kon trekken, maar ik moet dus aan de knutsel..

[stormfly]

@andrerij vandaag is de SE installatie live gegaan. De DB wordt gevuld, PVOutput werkt goed, https://pvoutput.org/intr...934&sid=60227&dt=20180819

Maar de door jou gebouwde webcontent werkt nog niet. Ik heb 8 panelen en de ID's in de config.php geplaatst. Maar de hele site blijft leeg, jij een idee? Zelf denk ik aan een php afhankelijkheid welke nu niet aan staat op de Synology Webserver?




Als jij of iemand ideeën heeft, graag ;-)

@ocaj is jouw site content ook beschikbaar voor ons?
@Jerrythafast is jouw site content ook beschikbaar voor ons?

[andrerij]

stormfly schreef op zondag 19 augustus 2018 @ 21:39:
@andrerij vandaag is de SE installatie live gegaan. De DB wordt gevuld, PVOutput werkt goed, https://pvoutput.org/intr...934&sid=60227&dt=20180819

Maar de door jou gebouwde webcontent werkt nog niet. Ik heb 8 panelen en de ID's in de config.php geplaatst. Maar de hele site blijft leeg, jij een idee? Zelf denk ik aan een php afhankelijkheid welke nu niet aan staat op de Synology Webserver?

[afbeelding]


Als jij of iemand ideeën heeft, graag ;-)

@ocaj is jouw site content ook beschikbaar voor ons?
@Jerrythafast is jouw site content ook beschikbaar voor ons?

Omdat er geen enkel gegevens van de grafieken wordt opgehaald zijn de database gegevens niet juist in de config.php file of het type inverter is niet juist ingevoerd.
Indien de panelen goed zijn ingevoerd moeten deze zwart zijn indien geen gegevens kunnen worden opgehaald. Er worden alleen geen panelen getoond indien het aantal op nul is gesteld of de plaats niet juist is ingevoerd.

[ocaj]

stormfly schreef op zondag 19 augustus 2018 @ 21:39:
@ocaj is jouw site content ook beschikbaar voor ons?

Het is meer een custom-made collectie scripts die precies doet wat het moet doen in mijn omgeving. Ik heb er nooit moeite voor gedaan om het voor een breder publiek aan te passen, dus ben wat terughoudend om het zo ergens neer te zetten.

Is dus niet echt plug&play, maar als je van knutselen houdt dan stuur maar een PM, kijken we wat we kunnen doen.

[stormfly]

@andrerij @ocaj tnx ik zal nog even stoeien, het is allemaal nog erg nieuw.

Andere vraag, bij vele SE plaatjes (dit topic zitten veel SE gebruikers) zie ik alle paneel nummers keurig in numerieke volgorde staan.

Maar bij mij is het een numerieke chaos, kan je dat als installateur nog aanpassen?

[pkleingu2]

Ik wil verbinding maken tussen mijn SolarEdge en pvoutput.org. Dan moet ik toch voldoende hebben aan de api key en de site code van de SolarEdge website, dan heb ik toch geen extra encryptiesleutel nodig.
die kan ik namelijk niet invullen op de pvoutput.org site?
Ik krijg het niet aan de praat en support wil mij hier ook niet verder mee helpen, misschien kan iemand mij hier verder helpen?

[teacher]

Je hebt de api nodig en de site id. Thats's it.

[pkleingu2]

En helaas geeft support US geen reactie en support DE zegt de enige support die zij leveren is het aanbieden van van de pdf van de handleiding.
Dit heb ik al geprobeerd om te testen:
https://monitoringapi.solaredge.com/equipment/<side ID>/list?api_key=<api key>
Waarmee je kunt testen volgens pvoutput werkt bij mij niet.

Dus ik heb ik het format van hier geprobeerd, maar dat werkt ook niet.
Moet je nog wat activeren voordat je de api key mag gebruiken?: https://monitoringapi.solaredge.com/equipment/<side ID>/SJxxxx-0xxxxxxx-0x/list?api_key=<api key>

[Jerrythafast]

pkleingu2 schreef op dinsdag 28 augustus 2018 @ 17:57:
Dit heb ik al geprobeerd om te testen:
https://monitoringapi.solaredge.com/equipment/<side ID>/list?api_key=<api key>
Waarmee je kunt testen volgens pvoutput werkt bij mij niet.

In deze link moet je op de plek van <side ID> het nummer van jouw installatie invullen. Wanneer je op de solaredge monitoring website bent ingelogd, zie je in de URL-balk van je browser deze link inclusief het bedoelde nummer:

code:

https://monitoring.solaredge.com/solaredge-web/p/site/<sideID>/

Daarnaast moet je in de monitoringapi link ook de <api key> invullen, deze sleutel kun je krijgen van je installateur. Als je op de monitoring website toegang hebt tot de pagina 'Admin' (naast o.a. 'Dashboard' en 'Layout'), kun je op die admin-pagina ook zelf een API key aanmaken.

Uiteindelijk kom je dan dus uit op een link zoals deze:

code:

https://monitoringapi.solaredge.com/equipment/123456/list/?api_key=FDHF8272CJDBCNV0382Y2BKO8VB7Q53M

En als je het goed hebt gedaan zie je als je die link opent iets als dit:

XML:

<equipmentList>
  <count>1</count>
  <list>
    <name>Omvormer 1</name>
    <manufacturer>SolarEdge</manufacturer>
    <model>SE3000</model>
    <serialNumber>12345678-9A</serialNumber>
  </list>
</equipmentList>

Als dat is gelukt kun je de site ID en API key uit de link kopiëren naar de settings-pagina van PVOutput.

[pkleingu2]

Dank je Jerry voor je uitgebreide informatie, maar dit is precies wat ik gedaan/getest heb.
Ik kan natuurlijk geen api key en site nummer op deze website laten zien, vandaar dat ik deze weg heb gelaten en vervangen door <>. Maar ondanks dat krijg ik :
HTTP Status 403 -
type Status report

message

description Access to the specified resource () has been forbidden.

Apache Tomcat/6.0.24

Ik wil je wel een pm sturen met mijn sitenummer en api key.
Maar ik denk dat jij dezelfde melding krijgt, of kan dit een firewall/windows 10 probleem zijn?
En solaredge support wil mij gewoon niet verder helpen, omdat zij hier geen support op geven.

[abhaas]

Hoeveel tekens is je api-key? (bij mij 32)
Ik krijg namelijk dezelfde melding als ik een verkeerde api-key gebruik.
De api-key is namelijk langer dan het veld waar hij instaat op de monitoring portal van solaredge.

[pkleingu2]

bij mij ook 32.
Ik kan ook zeer eenvoudig een nieuwe generen op de site door het vinkje even uit te zetten en weer aan te zetten dan krijg ik een nieuwe sleutel. Maar ook die werkt niet.

[pkleingu2]

Jerry heeft voor mij getest en bij hem werkt het ook niet, niet met mijn gegevens.
Heeft er iemand voor mij een contact bij support solaredge die mij wel wil/kan helpen?
Of kan ik op een manier alles resetten, ook bij solaredge?

[Rouske]

pkleingu2 schreef op woensdag 29 augustus 2018 @ 15:30:
bij mij ook 32.
Ik kan ook zeer eenvoudig een nieuwe generen op de site door het vinkje even uit te zetten en weer aan te zetten dan krijg ik een nieuwe sleutel. Maar ook die werkt niet.

Heb je wel aan de rechterkant op "Opslaan" geklikt?

[pkleingu2]

Ja en en hij onthoud de nieuwe sleutel ook nog ook gecheckt.
En moet iets met mijn account zijn, maar support wil mij niet helpen.
Ook al gevraagd of ze mijn account dan maar verwijderen en opnieuw aanmaken, maar geen reactie.
niet van support.de als niet van support.us.

[stormfly]

@pkleingu2

Waarom zit je in het buitenland met je vraagstuk, zijn toch gewoon Hollandse ingangen?

T-NL: 0800.7105
[e-mail]

[pkleingu2]

Via de support op de website zag ik steeds maar twee email adressen.
Ik zie nu dat er ook een nl ingang is.
https://www.solaredge.com/nl/service/support
Dank je, ik ga eens bellen.

[Dolbyadt]

@pkleingu2 Heb je inmiddels contact gehad met SolarEdge over je API key? Hebben ze je kunnen helpen hiermee?

[pkleingu2]

Ja twee dagen geleden reactie gekregen.Ze zeggen dat ze alleen een nieuwe API key te hebben genereerd ( wat ik ook al een paar keer gedaan had) maar nu werkt het gelukkig wel. Ook redelijk snel reactie via de NL support.@wopper bedankt voor de tip.

[Dolbyadt]

Ik doe het op dit moment op de plug en play manier. Ik heb sinds 3 juli 2018 een slimme stroom meter & gasmeter. Die lees ik uit via de P1 aansluiting met het programma P1monitor. Geweldig mooi programma waarin ik alles kan zien. Ik zie bijna realtime het verbruik van stroom en per uur het gas verbruik. En gewoon de SolarEdge portal om te kijken wat mijn zonnepanelen opbrengen wat ook naar PVoutput word verstuurd.

Heb afgelopen maand van mijn stroom leverancier een maand overzicht ontvangen. En de gegevens van verbruik hoog/laag en terug geleverd hoog/laag klopt heel netjes. Dus ik ben op dit moment erg te vrede met mijn manier van monitoren. Met het P1monitor programma kan ik bijna realtime, uren, dagen, maanden, jaren terug kijken van het verbruik/opgewekt in een heel mooi duidelijk overzicht.

Ik vind het geweldig om hier te lezen hoe mensen geweldig mooi dingen kunnen bouwen/maken.

[pkleingu2]

Nu heb ik eindelijk alles aan de praat.
De opbrengst van de zonnepanelen enphase en SolarEdge en Energie verbruik(met Youless) in 1 overzicht op pvoutput. Bedankt voor jullie hulp.

[ Voor 66% gewijzigd door pkleingu2 op 06-09-2018 19:50 ]

[stormfly]

Hoe heb je de tweede omvormer samengevoegd?

[pkleingu2]

Door de twee outputs als child aan te bieden aan een parent systeem (een derde systeem dus) via Data Aggregation.

[ Voor 26% gewijzigd door pkleingu2 op 06-09-2018 20:00 ]

[teacher]

Ehm... als je een fotomap beveiligt, dan zijn de foto's niet zichtbaar op het forum....

[pkleingu2]

Thanks teacher, aangepast.
Was inderdaad niet de bedoeling

[Verwijderd]

hallo ben nieuw hier,probeer een raspberry pi op te zetten voor het afluisteren van de solar edge omvormer
die ik overregens nog niet heb dmv een hub,snap nog niet hoe ik dit voor elkaar moet krijgen
aangezien linux ook nieuw is voor me.
Op de raspberry staat al domoticz,zou het zeer op prijs stellen als iemand mij stap voor stap kan vertellen hoe ik dit moet doen
mvg stelt572

[MDKlapwijk]

Ehh, Jerry was hier toch al redelijk uitvoerig in zijn omschrijving?

[ramonp]

Ik heb sinds afgelopen dinsdag een SolarEdge 3000H.
Deze is met een netwerkkabel aangesloten op een hub. Ook heb ik een Raspberry Pi (Model B+) aangesloten op deze hub. Ik heb de laatste Rasbian Stetch Lite geïnstalleerd.
Vervolgens de se-logger geïnstalleerd volgens de instructie in de startpost (al moest 'tcpdump' als extra package geïnstalleerd worden). MySql draait op een ander systeem.

Alles werkt. Ik heb vandaag de encryptiekey ontvangen, maar alles gaat nog steeds plain text over de lijn. Wellicht vanaf morgen.

Ik heb echter wel regelmatig last dat de Raspberry Pi vast loopt.
Dit is voornamelijk wanneer ik wat meer dat over het LAN stuur, zoals een backup van de folder /opt/se-logger naar een nfs folder op een andere linux machine.
Ook wanneer ik wil het systeem wil updaten (apt-get upgrade) loopt ie vast.

Iemand enig idee?

[ocaj]

Een raspberry pi die vastloopt? Nog nooit gehad. Die van mij is al bijna 500 dagen up en wordt intensief gebruikt.

Mogelijk heb je een te zwakke voeding? Dat schijnt de stabiliteit van de pi te kunnen beïnvloeden.

(en tof dat je nog een hub hebt bewaard, die dingen zijn zeldzaam tegenwoordig....)

[MDKlapwijk]

@ramonp, wat @ocaj zegt, ik heb sinds dat ik 2.5A pi voedingen gebruik geen onverwachte reboots meer, door stroom te kort, gehad en daardoor ook geen corruptie meer op de sd cards...

[ramonp]

Onlangs verhuisd, had de hub ook bijna weggegooid. Waarom dat niet is gebeurd weet ik ook niet, maar nu is het wel handig .

Ik heb voor de Pi een originele Samsung lader van 2A. Ook zit er een nieuwe SD kaart in.
Kabel van de lader naar de Pi is wel een oudje, misschien die eens vervangen...

[tsjoender]

ramonp schreef op zaterdag 29 september 2018 @ 20:39:
Kabel van de lader naar de Pi is wel een oudje, misschien die eens vervangen...

Daar kan heel goed de oorzaak liggen. Als de aders in die kabel te dun zijn, dan beperkt dat de stroom die er door kan lopen en krijgt de Pi toch te weinig vermogen. Been there, fixed that.

[ramonp]

Kabel vervagen, maar lost het niet op.

Pi is nu de afgelopen 2 dagen rond 18:30 vastgelopen. Dat is het laatste moment dat er naar de pcap bestanden is geschreven.
Deze zijn ook ca. 33 Mb, dat is toch wel een beetje aan de grote kant lijkt mij.
Het pcap bestand van vandaag is ook al weer rond de 21 Mb.

[stormfly]

@ramonp jeps dat is veel te groot, er gaat iets mis in je tcpdump. Begin eens met het kleiner krijgen van de pcap bestanden.

[ramonp]

Ik heb nu het volgende is in de se-logger-service.sh staan:

Python:

# SETTINGS
INTERFACE=eth0
FILTER=tcp && ether host 00:27:FF:FF:FF:FF
CAPTDIR=/opt/se-logger/
PREFIX=solaredge-

Eerst had ik bij FILTER alleen 'tcp' staan.

De pcap lijkt nu minder hard te groeien.
Even in de gaten houden en kijken of dit ook verband heeft met het vastlopen van de Pi.

[MDKlapwijk]

Het vastlopen klinkt toch echt als een voeding issue en als dat het niet is, misschien thermal of de pi zelfs stuk. Je zou ook eens kunnen kijken of je kan under-clocken/bluetooth uit/geen usb devices eraan/etc.

[ramonp]

Het is een oude Pi (eerste B, dus nog met maar 26 GPIO pins ipv 40).
Wellicht is die gewoon op.

Er zit dus nog geen wifi of bluetooth op. En ik heb er voor de rest ook geen andere zaken (zoals USB devices) aan hangen.

Under-clocken zou ook nog wel een idee zijn.
Ik zal ook eens voor een andere voeding kijken...

Edit:
Aanpassen van de FILTER heeft geholpen. De pcap files zijn nu (totaal) ongeveer 1,3Mb per dag.

[ Voor 22% gewijzigd door ramonp op 03-10-2018 11:13 ]

[stormfly]

Ik probeer mijn pcap's te verkleinen, de SE haalt toch soms wel veel data op/van het internet.

Nu zijn er TCP porten gebonden aan de CPU versie, maar ik vroeg mij af. Die CPU versie kan die geupdate worden is dat gelijk aan de firmware?

Communicatiesoftware versie 3.1444 of hoger via: 22222, 22221, 80
Communicatiesoftware versie 3.1256 of lager via: 22222

Zijn er gebruikers hier die al TCP filtering hebben toegepast in het script? Op IP source basis heb ik toch nog wel pcaps van enkele MB's per dag.

[Jerrythafast]

stormfly schreef op vrijdag 12 oktober 2018 @ 10:29:
Ik probeer mijn pcap's te verkleinen, de SE haalt toch soms wel veel data op/van het internet.

Nu zijn er TCP porten gebonden aan de CPU versie, maar ik vroeg mij af. Die CPU versie kan die geupdate worden is dat gelijk aan de firmware?

Communicatiesoftware versie 3.1444 of hoger via: 22222, 22221, 80
Communicatiesoftware versie 3.1256 of lager via: 22222

Zijn er gebruikers hier die al TCP filtering hebben toegepast in het script? Op IP source basis heb ik toch nog wel pcaps van enkele MB's per dag.

Ik denk dat filteren op het MAC-adres van je omvormer het meest effectief is. Dat is immers een constante (zowel IP-adres als TCP-poortnummer kan nog wel eens wisselen). Zie dit voorbeeld van eerder deze maand:

ramonp schreef op dinsdag 2 oktober 2018 @ 07:57:
Ik heb nu het volgende is in de se-logger-service.sh staan:

Python:

# SETTINGS
INTERFACE=eth0
FILTER=tcp && ether host 00:27:FF:FF:FF:FF
CAPTDIR=/opt/se-logger/
PREFIX=solaredge-

Eerst had ik bij FILTER alleen 'tcp' staan.

De pcap lijkt nu minder hard te groeien.
Even in de gaten houden en kijken of dit ook verband heeft met het vastlopen van de Pi.

Hier moet je op de plek van "00:27:FF:FF:FF:FF" het MAC-adres van je omvormer invullen.

[stormfly]

Jerrythafast schreef op zaterdag 13 oktober 2018 @ 11:17:
[...]

Ik denk dat filteren op het MAC-adres van je omvormer het meest effectief is. Dat is immers een constante (zowel IP-adres als TCP-poortnummer kan nog wel eens wisselen). Zie dit voorbeeld van eerder deze maand:

[...]

Hier moet je op de plek van "00:27:FF:FF:FF:FF" het MAC-adres van je omvormer invullen.

Daar heb ik ook over nagedacht, maar dan pakt hij nog steeds een deel communicatie mee wat niet in de database komt zoals web/firmware. Ik heb nu het tcpdump commando aangepast met alleen port 22222. Dat voorziet in de communicatie die ik wil opslaan, maar niet firmware updates en andere communicatie.

[Jerrythafast]

stormfly schreef op zaterdag 13 oktober 2018 @ 14:18:
[...]


Daar heb ik ook over nagedacht, maar dan pakt hij nog steeds een deel communicatie mee wat niet in de database komt zoals web/firmware. Ik heb nu het tcpdump commando aangepast met alleen port 22222. Dat voorziet in de communicatie die ik wil opslaan, maar niet firmware updates en andere communicatie.

Firmware updates e.d. komen daar voor zover ik weet ook gewoon bij mee. De omvormer communiceert uitsluitend over TCP (op de DNS en DHCP pakketjes na dan) en ik heb hem nooit meer dan één TCP-verbinding tegelijk zien gebruiken. Firmware updates en telemetrie gaan over dezelfde TCP-stream en zijn daarom op het niveau waarop tcpdump opereert niet te onderscheiden.

[stormfly]

Jerrythafast schreef op zaterdag 13 oktober 2018 @ 16:06:
[...]

Firmware updates e.d. komen daar voor zover ik weet ook gewoon bij mee. De omvormer communiceert uitsluitend over TCP (op de DNS en DHCP pakketjes na dan) en ik heb hem nooit meer dan één TCP-verbinding tegelijk zien gebruiken. Firmware updates en telemetrie gaan over dezelfde TCP-stream en zijn daarom op het niveau waarop tcpdump opereert niet te onderscheiden.

Er zit ook wel regelmatig een uitgaande sessie op port 80 bij, wat zich daar afspeelt is even niet gemakkelijk te onderscheiden. Zal eens kijken op de windows machine, de macbook laat de packet inhoud niet zien.

Weliswaar lijkt het idd 1 sessie op een gegeven tijdstip.

[ Voor 3% gewijzigd door stormfly op 14-10-2018 10:07 ]

[Jerrythafast]

stormfly schreef op zondag 14 oktober 2018 @ 10:02:
[...]


Er zit ook wel regelmatig een uitgaande sessie op port 80 bij, wat zich daar afspeelt is even niet gemakkelijk te onderscheiden. Zal eens kijken op de windows machine, de macbook laat de packet inhoud niet zien.

Weliswaar lijkt het idd 1 sessie op een gegeven tijdstip.


[Afbeelding]

[Afbeelding]

Zoals je zelf al zei wisselt de omvormer wel eens van TCP-poort: "Communicatiesoftware versie 3.1444 of hoger via: 22222, 22221, 80". Ongeacht welke poort wordt gebruikt, is de inhoud van de communicatie hetzelfde. Dat poort 80 erbij zit suggereert dat ze dit doen in een poging brakke router firmware te omzeilen. Poort 80 is immers bedoeld voor HTTP-verkeer, maar de omvormer gebruikt duidelijk geen HTTP op die poort.

Zelfs zonder naar de inhoud te hoeven kijken is in jouw screenshots al te zien dat de communicatie over poort 80 en 22222 van hetzelfde laken en pak is: de pakketjes hebben vergelijkbare lengtes (22, 66, 78 en 88 bytes).

[ Voor 10% gewijzigd door Jerrythafast op 14-10-2018 11:50 ]

[stormfly]

Jerrythafast schreef op zondag 14 oktober 2018 @ 11:48:
[...]

Zoals je zelf al zei wisselt de omvormer wel eens van TCP-poort: "Communicatiesoftware versie 3.1444 of hoger via: 22222, 22221, 80". Ongeacht welke poort wordt gebruikt, is de inhoud van de communicatie hetzelfde. Dat poort 80 erbij zit suggereert dat ze dit doen in een poging brakke router firmware te omzeilen. Poort 80 is immers bedoeld voor HTTP-verkeer, maar de omvormer gebruikt duidelijk geen HTTP op die poort.

Zelfs zonder naar de inhoud te hoeven kijken is in jouw screenshots al te zien dat de communicatie over poort 80 en 22222 van hetzelfde laken en pak is: de pakketjes hebben vergelijkbare lengtes (22, 66, 78 en 88 bytes).

Check lijkt inderdaad een kopie. Vanavond maar ombouwen naar MAC adres filtering. Ik ben nu overtuigd dat het inderdaad de beste keuze is.

[marcel458]

Heeft iemand al eens de losse zonnepanelen als devices in Domoticz toegevoegd? Ik gebruik de se-logger en heb dus een mooi gevulde SQL database als bron. De slimme meter, Solaredge, lampen verwarming e.d. staan allemaal in Domoticz, maar voor de opbrengst per paneel moet ik altijd een uitstapje maken naar de site van Solaredge of de eigen website opgezet met de voorbeelden in dit topic. Liever zou ik in python devices maken of zo en een tabblad zien met de panelen.
Mijn Domoticz draait overigens op een CentOS server waar ook de Solaredge gegevens worden onderschept.
Programmeren kan ik wel, maar een plugin of device maken in Domoticz zou nieuw zijn.

[Staatslot]

Ontzettend bedankt voor de info in dit topic en @Jerrythafast in het bijzonder voor het duidelijk uitschrijven van alle info en het beschikbaar stellen van de scripts. Morgen komen mijn panelen, heb een Ubuntu machine klaarstaan dus ben heel benieuwd wat we voor verkeer gaan vangen.. Spannend! Thanks!

[pkleingu2]

(kan vervallen lijkt een pvoutput probleem)

[ Voor 120% gewijzigd door pkleingu2 op 19-10-2018 10:53 ]

[willemx]

Vraagje over "last_0503":
Ik ben bezig om liveupdate.py aan te passen om het in mijn eigen domotica netwerk te kunnen draaien (ik gebruik geen MySQL maar MongoDb en wil vanuit liveupdate.py ook direct MQTT messages genereren voor mijn Node-RED app). MQTT heb ik al voor elkaar en ook opslag in MongoDb werkt al voor de inverter- en optimizer-data, maar ik zit nog een beetje te prutsen met de 0503 - key in de live_update table.
Ik zie in liveupdate.py dat er af en toe een "0503 key" gelezen word uit de PCAP info. Ik snap echter niet waar deze key voor gebruikt word (ik weet weinig van crypto). Voor zover ik zie wordt deze key eenmalig bij het opstarten uit de SQL database gelezen en gebruikt om een "decryptor" te fabriceren. Daarna lijkt het me dat er op random momenten in de PCAP info nieuwe 0503 keys op kunnen duiken, maar daar wordt niets mee gedaan, behalve steeds de meest recente key te bewaren in de SQL db. Pas bij het opnieuw opstarten van liveupdate.py wordt de laatst gelezen key weer gebruikt.
Als ik dus met een enkel commando liveupdate *.PCAP een groot aantal PCAP files ga verwerken word alleen de bij het opstarten gelezen 0503 key gebruikt voor alle PCAP files. Of zie ik iets over het hoofd?
Kan iemand me uitleggen hoe het decodeerproces werkt?

[Jerrythafast]

willemx schreef op zaterdag 20 oktober 2018 @ 15:32:
Ik zie in liveupdate.py dat er af en toe een "0503 key" gelezen word uit de PCAP info. Ik snap echter niet waar deze key voor gebruikt word (ik weet weinig van crypto). Voor zover ik zie wordt deze key eenmalig bij het opstarten uit de SQL database gelezen en gebruikt om een "decryptor" te fabriceren.

Die decryptor is nodig om de data die je omvormer verzendt te ontcijferen, SolarEdge versleutelt namelijk die informatie. De "0503 key" is een soort decryptiesleutel die periodiek wijzigt.

Daarna lijkt het me dat er op random momenten in de PCAP info nieuwe 0503 keys op kunnen duiken,

Klopt, wanneer dit gebeurt zal vanaf dat moment die nieuwe 0503 key worden gebruikt en is de voorgaande niet meer bruikbaar voor het ontsleutelen van informatie die daarna wordt verzonden.

maar daar wordt niets mee gedaan, behalve steeds de meest recente key te bewaren in de SQL db. Pas bij het opnieuw opstarten van liveupdate.py wordt de laatst gelezen key weer gebruikt.

Dat zie je niet goed, de key wordt niet alleen opgeslagen, er wordt ook weer een nieuwe decryptor gemaakt die gebruikmaakt van deze nieuwe 0503 key. Dit gebeurt helemaal aan het einde van de get_messages functie. De nieuwe key wordt dus ook opgeslagen in de database, zodat se-logger bij een herstart de meest recente 0503 key uit de database kan halen (in de hoop dat die nog geldig is).

Als ik dus met een enkel commando liveupdate *.PCAP een groot aantal PCAP files ga verwerken word alleen de bij het opstarten gelezen 0503 key gebruikt voor alle PCAP files. Of zie ik iets over het hoofd?

Hij zal dus de 0503 key die hij bij het opstarten uit de database leest gebruiken voor de eerste PCAP files, totdat hij in die PCAP files een nieuwe key tegenkomt, daarna wordt de nieuwe 0503 key gebruikt voor het vervolg (tot er wéér een nieuwe voorbij komt).

Kan iemand me uitleggen hoe het decodeerproces werkt?

Whizkidzz op GitHub (23 maart 2016) had het voor het eerst ontcijferd. Een dag later vind je een comment van mij met de eerste implementatie van de 'SEDecrypt' class die ook in liveupdate.py te vinden is.

Met name de comments van mij en Whizkidzz in dat draadje zijn wel informatief voor het uitpuzzelen van hoe dit protocol werkt.

[Staatslot]

Misschien kunnen jullie helpen..

Ik heb dus sinds afgelopen donderdag de solaredge zonnepanelen, had keurig een VM draaien die al het verkeer uitlas in afwachting van een encryption key.. Nou hebben we vandaag een enorme stroomstoring gehad en heeft de solaredge al met al ongeveer 20 minuten zonder scannen aan het internet gehangen..

Als ik zoek naar een encryption key wordt nog niks gevonden in de pcap files, de laatste entry in de database was van 18.37 uur. Daarna zijn er geen entries meer bijgekomen.. Terwijl ik de pcap files wel zie groeien nog.. overigens weet ik zeker dat ik vanaf ongeveer 17.00 uur al weer meeliep met het cappen van het verkeer.

Kan het zijn dat ik de encryptiesleutel heb gemist? Hoe kan ik dat checken?
Of is het normaal dat er 's nachts geen output naar de db wordt geschreven omdat er niks wordt opgewekt?

Dank!

[stormfly]

Zie je in de pcaps communicatie op port 2222?

Weet je zeker dat alles werkt, en inderdaad in de nacht is er niets te melden en geen inhoudelijke communicatie.

[willemx]

@Jerrythafast
Bedankt voor de uitleg van het decodeer proces. Inderdaad een interessante thread; het leest als een spannend verhaal. Jullie hebben er een hoop moeite in gestoken: respect!
Ik begrijp nu beter hoe het zit met de 0503-keys. Als je een database probeert te (re)construeren m.b.v. een hoeveelheid bewaarde PCAP files is het blijkbaar dus ook belangrijk dat ze in de goede volgorde worden gelezen...

[Jerrythafast]

willemx schreef op zondag 21 oktober 2018 @ 14:13:
@Jerrythafast
Bedankt voor de uitleg van het decodeer proces. Inderdaad een interessante thread; het leest als een spannend verhaal. Jullie hebben er een hoop moeite in gestoken: respect!
Ik begrijp nu beter hoe het zit met de 0503-keys. Als je een database probeert te (re)construeren m.b.v. een hoeveelheid bewaarde PCAP files is het blijkbaar dus ook belangrijk dat ze in de goede volgorde worden gelezen...

Zekers! En ook dat je bij de meest recente eindigt, zodat de meest recente 0503 key in de database staat voordat je verder gaat met live capture.

[Verwijderd]

@willemx
Toevallig ben ik net begonnen met uitpluizen van het Python programma om de data niet naar MySQL maar naar MQTT te sturen (en vervolgens door openHAB laten verwerken en in InfluxDB (als timeseries) oplsaan.
Kun/wil je al wat delen (via PM/link) van de aanpassingen? Dat zou veel tijd kunnen besparen... ;o)

[Staatslot]

stormfly schreef op zondag 21 oktober 2018 @ 10:48:
Zie je in de pcaps communicatie op port 2222?

Weet je zeker dat alles werkt, en inderdaad in de nacht is er niets te melden en geen inhoudelijke communicatie.

Tot nu toe 5 dagen na installatie en nog geen encryptie ingeschakeld.. de database blijft zich vullen.. ik ben benieuwd..

[willemx]

@Verwijderd
zie hier: https://gitlab.com/willemx/se-logger/tree/master voor een gerefactor-de liveupdate.py
Ik heb jerry's code functioneel opgesplitst in afzonderlijke modules en er zelf enkele aan toegevoegd t.b.v. MongoDb en MQTT.
Alles is nog in een zeer prematuur stadium, maar werkt al wel: de inverter- en optimizer-data wordt nu zowel naar MySQL als MongoDb gelogd en ook gepublished via MQTT. De 0503-keys worden niet meer naar een database geschreven, maar in een losse file. Dat leek me beter; geen idee meer waarom ook alweer
(disclaimer: ik heb nog nooit iets met/in Python gedaan, dus ik sta absoluut niet in voor de code, maar wel open voor suggesties voor verbetering...)
Edit: gitlab repository is inmiddels weer verwijderd.

[ Voor 3% gewijzigd door willemx op 28-10-2018 12:21 ]

[Verwijderd]

willemx schreef op woensdag 24 oktober 2018 @ 19:18:
@Verwijderd
zie hier: https://gitlab.com/willemx/se-logger/tree/master voor een gerefactor-de liveupdate.py
Ik heb jerry's code functioneel opgesplitst in afzonderlijke modules en er zelf enkele aan toegevoegd t.b.v. MongoDb en MQTT.
Alles is nog in een zeer prematuur stadium, ........ ik heb nog nooit iets met/in Python gedaan, dus ik sta absoluut niet in voor de code, maar wel open voor suggesties voor verbetering...)

Dankje ; ik zal er naar kijken. Ook geen ervaring met Python (maar wel vele andere talen). Als ik suggeties voor verbetering heb zal ik ze weer delen.

UPDATE:
@willemx Werkt vooralsnog prima (zonder MongoDB en MariaDB/MySQL in mijn geval). Ik zal in mijn schaarse tijd proberen er een package van te maken dat met pip geïnstalleerd kan worden en misschien nog een beetje robustere mqtt connectie met de callbacks en status checks. Kan geen kwaad....

Overigens valt mij op dat de optimizers vreemde temperatuurwaarden geven, bijvoorbeeld:
{"v_in":268,"op_id":291058763,"i_in":0,"v_out":91,"timestamp":1540451077,"e_day":0,"uptime":36,"temperature":10}
Er staan altijd waarden in de vorm van gehele getallen in. Iemand anders dat ook ervaren?

[ Voor 29% gewijzigd door Verwijderd op 25-10-2018 19:26 ]

[Verwijderd]

Ben druk bezig alles 'in te regelen' en gebruik nu nog zowel de SE API als de logger.

Vandaag was natuurlijk geen goede dag voor de zonnepanelen, maar ik constateerde een vreemd verschil tussen de API en de gelogde data t.a.v. totaal gebruik van de dag:

De API (en monitoring portal) geeft 1,41 kWh aan terwijl het e_day veld slechts 616 Wh aangeeft. De Inverter (SE7K) is overigens niet gereset of uitgeschakeld geweest vandaag (of er moet iets ongemerkt gebeurd zijn).
Weet iemand hoe de portal/API aan die totalen komt als de inverter andere getallen meldt?

UPDATE: Nadere controle van de MQTT messages toont aan dat e_day gelijk oploopt met de API info tot 13:00 en daarna dezelfde waarde blijft geven in alle volgende messages, terwijl e_total wel oploopt en ook de_day geeft steeds een klein vermogen aan over de voorgaande 5 minuten. Bugje in de Inverter?

[ Voor 25% gewijzigd door Verwijderd op 26-10-2018 16:03 ]

[stormfly]

Jerrythafast schreef op zaterdag 13 oktober 2018 @ 11:17:
[...]

Ik denk dat filteren op het MAC-adres van je omvormer het meest effectief is. Dat is immers een constante (zowel IP-adres als TCP-poortnummer kan nog wel eens wisselen). Zie dit voorbeeld van eerder deze maand:

[...]

Hier moet je op de plek van "00:27:FF:FF:FF:FF" het MAC-adres van je omvormer invullen.

Ter naslag: alles draaide weken op port 22222, vandaag stroomstoring in de wijk. Begint hij op 22221, dus MAC filtering is 100% de beste keuze.

[Verwijderd]

Hmmm, na een paar dagen goed loggen verschijnen er ineens meldingen van onverwachte sequences:

56ce08ac Out of order packet! SEQ=0000bfd4 expect=0000bead (Gap size 295)
56ce08ac Out of order packet! SEQ=0000bfd4 expect=0000bead (Gap size 295)
56ce08ac Out of order packet! SEQ=0000c1cf expect=0000bead (Gap size 802)
56ce08ac DATA LOSS 295 bytes!
56ce08ac Gap closed after 119.967536 seconds
56ce08ac Stream is contiguous again
56ce08ac Out of order packet! SEQ=0000d40a expect=0000d29b (Gap size 367)
56ce08ac Out of order packet! SEQ=0000d40a expect=0000d29b (Gap size 367)
56ce08ac Out of order packet! SEQ=0000d605 expect=0000d29b (Gap size 874)
56ce08ac DATA LOSS 367 bytes!
56ce08ac Gap closed after 119.974082 seconds
56ce08ac Stream is contiguous again
56ce08ac Out of order packet! SEQ=0000de58 expect=0000dd46 (Gap size 274)
56ce08ac DATA LOSS 274 bytes!
56ce08ac Gap closed after 85.800037 seconds
56ce08ac Stream is contiguous again
56ce08ac Out of order packet! SEQ=0000e57a expect=0000e468 (Gap size 274)
56ce08ac DATA LOSS 274 bytes!
56ce08ac Gap closed after 84.255267 seconds
56ce08ac Stream is contiguous again
56ce08ac Out of order packet! SEQ=0000fb90 expect=0000fa5a (Gap size 310)
56ce08ac DATA LOSS 310 bytes!
56ce08ac Gap closed after 92.635168 seconds
56ce08ac Stream is contiguous again
56ce08ac Out of order packet! SEQ=000102c6 expect=000101b4 (Gap size 274)
56ce08ac DATA LOSS 274 bytes!
56ce08ac Gap closed after 103.801316 seconds
56ce08ac Stream is contiguous again
56ce08ac Out of order packet! SEQ=00013bb4 expect=000139fa (Gap size 442)
56ce08ac DATA LOSS 442 bytes!
56ce08ac Gap closed after 91.393143 seconds
56ce08ac Stream is contiguous again
56ce08ac Out of order packet! SEQ=00013fb8 expect=00013e13 (Gap size 421)
56ce08ac DATA LOSS 421 bytes!
56ce08ac Gap closed after 105.978112 seconds
56ce08ac Stream is contiguous again

Zou er iets veranderd kunnen zijn aan de berichten die de inverter stuurt? Of is er iets mis in mijn configuratie?
Ter info: ik gebruik simpele port-mirroring op mijn managed switch om alle verkeer van de inverter 'af te luisteren'.

[Jerrythafast]

Verwijderd schreef op woensdag 24 oktober 2018 @ 20:20:
Ik zal in mijn schaarse tijd proberen er een package van te maken dat met pip geïnstalleerd kan worden

Gewoon een setup.py script ervoor zetten heb ik natuurlijk geen bezwaar tegen, maar liever heb ik niet dat je se-logger uploadt naar PyPI. Mogelijk is se-logger namelijk tegen hun terms of service i.v.m. de reverse engineering output die erin staat. En als dat niet zo is upload ik hem liever zelf.

(Als uploaden naar PyPI inderdaad je plan was zou ik het trouwens ook erg waarderen als je dit soort plannen eerst even met mij kortsluit in het vervolg )

Verwijderd schreef op donderdag 25 oktober 2018 @ 19:21:
Ben druk bezig alles 'in te regelen' en gebruik nu nog zowel de SE API als de logger.

Vandaag was natuurlijk geen goede dag voor de zonnepanelen, maar ik constateerde een vreemd verschil tussen de API en de gelogde data t.a.v. totaal gebruik van de dag:

De API (en monitoring portal) geeft 1,41 kWh aan terwijl het e_day veld slechts 616 Wh aangeeft. De Inverter (SE7K) is overigens niet gereset of uitgeschakeld geweest vandaag (of er moet iets ongemerkt gebeurd zijn).
Weet iemand hoe de portal/API aan die totalen komt als de inverter andere getallen meldt?

UPDATE: Nadere controle van de MQTT messages toont aan dat e_day gelijk oploopt met de API info tot 13:00 en daarna dezelfde waarde blijft geven in alle volgende messages, terwijl e_total wel oploopt en ook de_day geeft steeds een klein vermogen aan over de voorgaande 5 minuten. Bugje in de Inverter?

Dit is een bekende bug in de inverter, de SolarEdge portal zelf lijkt ook van de de_day uit te gaan. De totale energie op een dag is de som van alle de_day sinds het begin van de dag. Raar maar waar

Verwijderd schreef op vrijdag 26 oktober 2018 @ 15:58:
Hmmm, na een paar dagen goed loggen verschijnen er ineens meldingen van onverwachte sequences:


[...]


Zou er iets veranderd kunnen zijn aan de berichten die de inverter stuurt? Of is er iets mis in mijn configuratie?
Ter info: ik gebruik simpele port-mirroring op mijn managed switch om alle verkeer van de inverter 'af te luisteren'.

Het heeft er alle schijn van dat er TCP packets ontbreken in de capture. Aangezien er volgens deze output ook geen retransmission plaatsvindt lijkt het erop dat deze packets wel bij de omvormer aankomen. Zou het kunnen zijn dat je logger (of je switch?) het soms erg druk heeft en er zo pakketjes langs kunnen schieten? Anders weet ik het eigenlijk ook niet...

[willemx]

@Jerrythafast
Nu ik je reactie naar Noppes123 m.b.t. het maken van een package lees kan ik me ineens heel goed voorstellen dat je het ook geen goed idee vind dat ik jouw code zonder jouw toestemming in stukjes heb geknipt en zomaar in een public gitlab repository heb gezet.
Excuses daarvoor.
'Just say the word' en ik haal hem weer weg.
Of misschien kun je overwegen om je code zelf in een of andere git/bit-lab/hub/bucket te plaatsen met een naar jouw inzicht geschikte licentie...

[Jerrythafast]

willemx schreef op zondag 28 oktober 2018 @ 11:19:
@Jerrythafast
Nu ik je reactie naar Noppes123 m.b.t. het maken van een package lees kan ik me ineens heel goed voorstellen dat je het ook geen goed idee vind dat ik jouw code zonder jouw toestemming in stukjes heb geknipt en zomaar in een public gitlab repository heb gezet.
Excuses daarvoor.
'Just say the word' en ik haal hem weer weg.
Of misschien kun je overwegen om je code zelf in een of andere git/bit-lab/hub/bucket te plaatsen met een naar jouw inzicht geschikte licentie...

Ik heb inderdaad even overwogen dezelfde opmerking richting jou te maken, maar dit toen niet gedaan omdat ik met Git minder problemen heb. Immers is dat een open systeem waarbij het iedereen vrij staat om bijvoorbeeld pullrequests te maken om een project vooruit te helpen. Ik zou nu alsnog bijvoorbeeld mijn versie op GitHub kunnen gooien en dan zou jij jouw aanpassingen daar vanaf kunnen forken voor hetzelfde effect. Mijn probleem met PyPI is ook een beetje dat het gelijk vast hangt aan één package owner/maintainer en de daarop beschikbare versie dan automatisch wordt gezien als de "officiële", zelfs al is het eigenlijk een fork. Als ik vervolgens met versie 0.0.11 aan kom kakken hebben we een probleem omdat ik die dan niet zelf op PyPI kan zetten en upgraden via pip dus niet mogelijk is zonder tussenkomst van de persoon die het project daarop heeft gekwakt...

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

[MDKlapwijk]

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

[basvn]

Ik heb sinds vorige week donderdag 10 panelen liggen, met SolarEdge er aan.
Monitoring werkt sinds vanmiddag.

Maar ik kreeg net deze meldingen (op 9 panelen, dus niet op alle 10)


Gister nog 1.9kwh opgehaald (vandaag weet ik niet, maar zal niet veel zijn)

Moet ik me hier druk om maken? of als morgen het zonnetje wel weer normaal gaat schijnen, dat alles weer goed komt?

[Jerrythafast]

basvn schreef op dinsdag 30 oktober 2018 @ 19:06:
Ik heb sinds vorige week donderdag 10 panelen liggen, met SolarEdge er aan.
Monitoring werkt sinds vanmiddag.

Maar ik kreeg net deze meldingen (op 9 panelen, dus niet op alle 10)

[Afbeelding]
Gister nog 1.9kwh opgehaald (vandaag weet ik niet, maar zal niet veel zijn)

Moet ik me hier druk om maken? of als morgen het zonnetje wel weer normaal gaat schijnen, dat alles weer goed komt?

Lijkt erop dat je installateur de panelen verkeerd in het monitoring portaal heeft ingesteld. Elk paneel is nu zijn eigen string. Waarschijnlijk heb je op jouw dak gewoon één string liggen. De panelen zouden dan nummers moeten hebben als 1.1.1 en 1.1.2 t/m 1.1.10. Dit heeft trouwens verder geen invloed op de werking van je systeem, alleen het monitoring portaal is in de war

[basvn]

Jerrythafast schreef op dinsdag 30 oktober 2018 @ 21:52:
[...]

Lijkt erop dat je installateur de panelen verkeerd in het monitoring portaal heeft ingesteld. Elk paneel is nu zijn eigen string. Waarschijnlijk heb je op jouw dak gewoon één string liggen. De panelen zouden dan nummers moeten hebben als 1.1.1 en 1.1.2 t/m 1.1.10. Dit heeft trouwens verder geen invloed op de werking van je systeem, alleen het monitoring portaal is in de war

Okay mooi!
Ik heb het ondertussen doorgegeven aan de installateur, dat ik deze foutmeldingen krijg

Bedankt!

[Tomba]

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

[Jerrythafast]

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

se-logger heeft aan een paar MB geheugen meer dan genoeg (inclusief tcpdump)... hooguit dat je MySQL/MariaDB wat spartaans moet afstellen?

[Tomba]

Jerrythafast schreef op woensdag 31 oktober 2018 @ 16:41:
[...]

se-logger heeft aan een paar MB geheugen meer dan genoeg (inclusief tcpdump)... hooguit dat je MySQL/MariaDB wat spartaans moet afstellen?

Ok! Super bedankt voor je reactie.
Ik wil vooral niks missen eigenlijk (zoals de encryptie sleutel)

[ Voor 4% gewijzigd door Tomba op 31-10-2018 17:27 ]

[Jerrythafast]

Tomba schreef op woensdag 31 oktober 2018 @ 17:27:
[...]

Ok! Super bedankt voor je reactie.
Ik wil vooral niks missen eigenlijk (zoals de encryptie sleutel)

Je kunt nu alvast kijken of je MySQL of MariaDB aan de praat krijgt. Als dat lukt gaat het wel goed komen. Ik heb er zelf eigenlijk wel vertrouwen in, het heeft allemaal echt niet zoveel nodig.

Even los van het RAM-gebruik... Over de hele dag gemeten heeft se-logger hier 10 CPU seconds nodig gehad op mijn RPi 2B. Hij schrijft op een goede dag 500 KB in een .pcap bestand op het SD-kaartje. Alleen de hoeveeheid I/O van MySQL is voor mij niet helemaal duidelijk, maar veel zal het niet zijn (deze hoeft trouwens niet per se op de RPi te staan, alss je iets anders 24/7 hebt draaien kan dat natuurlijk ook).

[Tomba]

Jerrythafast schreef op woensdag 31 oktober 2018 @ 17:39:
[...]

Je kunt nu alvast kijken of je MySQL of MariaDB aan de praat krijgt. Als dat lukt gaat het wel goed komen. Ik heb er zelf eigenlijk wel vertrouwen in, het heeft allemaal echt niet zoveel nodig.

Even los van het RAM-gebruik... Over de hele dag gemeten heeft se-logger hier 10 CPU seconds nodig gehad op mijn RPi 2B. Hij schrijft op een goede dag 500 KB in een .pcap bestand op het SD-kaartje. Alleen de hoeveeheid I/O van MySQL is voor mij niet helemaal duidelijk, maar veel zal het niet zijn (deze hoeft trouwens niet per se op de RPi te staan, alss je iets anders 24/7 hebt draaien kan dat natuurlijk ook).

Das inderdaad 3x niks Ik ga waarschinlijk de Database niet op de RaspPi draaien dus dan moet het helemaal goed komen.

[Staatslot]

Hallo allemaal,

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

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

Zie hieronder


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