[SolarEdge] Omvormers en optimizers zelf monitoren

[Jerrythafast]

@ocaj
De encryptiesleutel van de omvormer is opgeslagen in een viertal 32-bit variabelen. Ook het wel/niet gebruiken van encryptie is een 32-bit variabele (die in de praktijk altijd 0 of 1 is). En zo zijn er nog veel meer dingen in die variabelen opgeslagen.

Wat er gebeurt is dat de solaredge-server aan de omvormer de waardes van de betreffende variabelen opvraagt (met een 'get param' commando). Bij onze omvormer kwam er meteen al een sleutel uit, die had de omvormer dus blijkbaar al. Daarna gaf de solaredge-server opdracht om de variabele 'encryptie aan' op 1 te zetten ('set param' commando) en vervolgens kwam er een 'reset'-commando om de communicatiemodule opnieuw op te laten starten. That's it, zo gebeurt het.

Ruim een half jaar later werd bij ons de communicatieplaat vervangen. Op het nieuwe exemplaar stond encryptie aanvankelijk weer uit. De solaredge-server vroeg de variabelen waarin de key zit opgeslagen weer op met het 'get param' commando, maar deze waren alle vier 0. Daarop gaf de solaredge-server met het 'set param' commando zelf vier 32-bit waarden door die in die variabelen opgeslagen moesten worden. Vervolgens werd de key wederom opgevraagd (check check dubbelcheck ) en daarna werd encryptie weer aangezet.

[RTB]

Exact, bij mij is al die weken niets veranderd, dus alles werkt nog steeds zonder encryptie.
Ik heb een 5000H.

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

[ocaj]

Jerrythafast schreef op vrijdag 30 juni 2017 @ 23:17:
@ocaj
Wat er gebeurt is dat de solaredge-server aan de omvormer de waardes van de betreffende variabelen opvraagt (met een 'get param' commando). Bij onze omvormer kwam er meteen al een sleutel uit, die had de omvormer dus blijkbaar al.
...

Ruim een half jaar later werd bij ons de communicatieplaat vervangen. Op het nieuwe exemplaar stond encryptie aanvankelijk weer uit. De solaredge-server vroeg de variabelen waarin de key zit opgeslagen weer op met het 'get param' commando, maar deze waren alle vier 0. Daarop gaf de solaredge-server met het 'set param' commando zelf vier 32-bit waarden door die in die variabelen opgeslagen moesten worden.

Ok, dank voor de uitleg. Het kan dus allebei voorkomen? Dat de omvormer al een sleutel heeft, maar dat de omvormer die niet heeft en de server hem dan verzint.

Kun je met die set param dus eigenlijk de encryptie ook weer uit zetten?

(omdat de server het via internet waarschijnlijk toch weer aanzet, is dat alleen interessant voor mensen die op later moment pas bedenken dat ze hun omvormer toch maar niet aan het internet willen hangen, die zouden dan dus weer blijvend van de encryptie af kunnen?)

[Jerrythafast]

@ocaj, ja, je kunt daarmee ook de encryptie weer uitzetten. In het verleden werd het dan na enige tijd vanzelf weer aangezet, dus een echte oplossing was het toen niet. Als SolarEdge werkelijk is gestopt met het automatisch aanzetten van encryptie, zou je nu inderdaad af kunnen met een simpel script dat encryptie uit zet. Geen gedoe meer met het instellen van de encryptiesleutel in de logging software dus.

[ Voor 33% gewijzigd door Jerrythafast op 01-07-2017 15:10 ]

[serienummer]

Hoi Jerrythafast,
zoals je al misschien gezien had ben ik ook het een en ander aan het proberen.
Ik heb het script se-logger-service lopen en ik zie het een en ander gebeuren.. Er zijn wat PCAP bestanden bij gekomen. Morgen kan ik zeggen of het een werkt. Maar ik wil ook de resultaten naar PVoutput sturen.
Ik heb het bestand aangepast met de juiste gegevens. Maar als ik deze wil starten krijg ik de vogende melding:
root@MWEBNLE01:/opt/se-logger# ./pvo-upload.php
./pvo-upload.php: line 1: ?php: No such file or directory
./pvo-upload.php: line 2: //Version: No such file or directory
./pvo-upload.php: line 3: //SETTINGS: No such file or directory
./pvo-upload.php: line 4: syntax error near unexpected token `"DB_HOST",'
./pvo-upload.php: line 4: `define("DB_HOST", "localhost");'
root@MWEBNLE01:/opt/se-logger#

Heb jij enig idee waarom dit niet werkt?

Groeten
Palermo

[Jerrythafast]

@serienummer
Ja, je commando is verkeerd. Het PHP script start je met:

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

Hij probeert het nu als Bash script te interpreteren

P.S., als het PVOutput uploadscript goed werkte krijg je geen output te zien. Alleen bij problemen komt er output uit.

[ Voor 24% gewijzigd door Jerrythafast op 02-07-2017 10:02 ]

[serienummer]

P.S., als het PVOutput uploadscript goed werkte krijg je geen output te zien. Alleen bij problemen komt er output uit.

Wat je zegt klinkt eigenlijk heel logisch. hahah heel in het verleden heb ik iets met PHP gedaan.

Dit is wat ik tezien krijg bij het uivoeren van het pvo-upload.php
Ik heb het idee dat hij op deze link een fout krijgt "http://pvoutput.org/service/r2/addbatchstatus.jsp"

MWEBNLE01:/opt/se-logger# php pvo-upload.php
cURL error, exiting: The requested URL returned error: 400 Bad Request
MWEBNLE01:/opt/se-logger#

Ik meen dat ik alles goed had ingevuld.

Edit:
Ok, Ik ben een stap verder. Ik maakte me een beetje zorgen over de gemaakte database. Het maken van deze database was niet helemaal goed gegaan, kreeg foutmeldingen. Via phpmyadmin heb ik een aantal opnieuw aangemaakt. Nu krijg ik deze 400 error niet meer. Dus dit lijkt goed te gaan, Maar niet alle DB zijn gevuld.

de "TABLE live_update" is niet gevuld, net als de "TABLE telemetry_inverter_3phase"
De andere "telemetry_inverter" en de "telemetry_optimizers" zie ik wel data (Ben helemaal geen DB expert).

Is er misschien een kale .slq versie?

Groeten Palermo

[ Voor 32% gewijzigd door serienummer op 02-07-2017 11:50 ]

[Jerrythafast]

@serienummer, mogelijk mis je deze regel in je live_update tabel? Daar hoort maar 1 regel in te staan. Als er al een regel in staat hoef je dit dus niet meer te doen.

SQL:

INSERT INTO live_update (pvo_last_live, last_0503, last_telemetry) VALUES (0, "\0", 0);

Als je geen 3-fasenomvormer hebt blijft de 3phase tabel inderdaad leeg. Dat in de andere twee tabellen data staat is goed nieuws, dat betekent dat het afluisteren in ieder geval goed werkt!

[ Voor 8% gewijzigd door Jerrythafast op 02-07-2017 12:13 ]

[serienummer]

Ik geloof dat deze regel er wel in staat. Maar er staan er nog 2 bij.
Ik heb geen foutmeldingen bij het starten van de scripts. Maar heb nog geen data in PVoutput.

Ik heb het volgende in MYSQL staan:
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| phpmyadmin |
| solaredge |
+--------------------+
5 rows in set (0.00 sec)

mysql> use solaredge
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+---------------------------+
| Tables_in_solaredge |
+---------------------------+
| live_update |
| telemetry_inverter |
| telemetry_inverter_3phase |
| telemetry_optimizers |
+---------------------------+
4 rows in set (0.00 sec)

mysql> DESCRIBE live_update;
+----------------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+------------------+------+-----+---------+-------+
| pvo_last_live | int(10) unsigned | NO | | NULL | |
| last_0503 | binary(34) | NO | | NULL | |
| last_telemetry | int(10) unsigned | NO | | NULL | |
+----------------+------------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

Klopt het zo wel?
Alvast bedankt voor het helpen. :-)

Groeten Palermo

[Jerrythafast]

@serienummer, wat geeft 'SELECT pvo_last_live FROM live_update;' als resultaat?

[ Voor 9% gewijzigd door Jerrythafast op 02-07-2017 18:23 ]

[serienummer]

Ik geloof dat er niks in staat.

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

mysql>

Bij het starten van het "php pvo-upload.php" krijg ik het volgende te zien:
/opt/se-logger# php pvo-upload.php
cURL error, exiting: The requested URL returned error: 400 Bad Request

Ik heb de server al een keer opnieuw opgestart. Maar lijkt niet te helpen (Soms werkt dat:-).

Edit:
Ik ben nog even aan het verder zoeken. Ik ben geen scripter maar ik probeer het een beetje te ontcijferen.
se-logger-service.sh zorgt voor de TCP dump. Hier zit een verwijzing in naar liveupdate.py. Hier wordt gevraagt naar de "inverter_private_key" Maar deze heb ik niet kunnen vinden. Ik hoop maar dat deze niet niet geweest en dat de encryptie niet aan staat. Ik heb de bestaande code laten staan ('\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'). Misschien gaat het daar nu fout?
Bij het uitvoeren van het script krijg ik de volgende melding:
@MWEBNLE01:/opt/se-logger# ./liveupdate.py
End of file. Shutting down.
root@MWEBNLE01:/opt/se-logger#

[ Voor 40% gewijzigd door serienummer op 02-07-2017 22:25 ]

[Jerrythafast]

@serienummer, je database is in orde ("1 row in set"). De "400 bad request" error die uit het PHP script komt, is afkomstig van PVOutput. Dubbel-check even of je het juiste System ID en de juiste PVOutput Key hebt ingevuld.

Als je geen donateur bent van PVOutput zou het ook nog kunnen zijn dat het script meer data tegelijk probeert te uploaden dan door PVOutput wordt toegestaan. Om dat op te lossen kun je in het script de regel waar 'LIMIT 100' staat veranderen naar 'LIMIT 30'.

[serienummer]

@Jerrythafast
Ja het werkt. Je hebt gelijk :-) had inderdaad te maken met de limit. Heb 10 euro gedoneerd en het was opgelost. Het koste nog even wat tijd, maar het is gelukt. Was later nog vergeten dat er nog wat in de crontab moest gebeuren. Maar is allemaal werkend.
Dank je wel voor je hulp.

https://pvoutput.org/intraday.jsp?id=59545&sid=52977

In het begin van je verhaal op P1 heb je het over deze link (http://jerweb.nl/pv/), Ik ben er erg in geïnteresseerd. Ik zou graag een eigen pagina willen hebben. Is het mogelijk om om deze code vrij te geven. Ziet er namelijk erg gaaf uit.

Ik hoor het graag.

Nogmaals bedankt voor het helpen :-)

Groeten
Palermo

[Jerrythafast]

Cool! Leuk om te zien dat hij het doet

Stuur even een PM met je e-mailadres voor de code, dan stuur ik even een zipje van www.jerweb.nl/pv door.

Intussen was ik ook bezig met een nieuwe versie die wat meer toekomstproof is. Mijn wens is eigenlijk om deze twee pagina's nog samen te voegen en responsive te maken voordat ik het op GitHub gooi (en de paneeltjes er op een nette manier bij):
www.jerweb.nl/pv3
www.jerweb.nl/pv3/lifetime.html

En daarna hebben we nog allerlei grafiekjes en tabellen die erbij kunnen, zoals grafiekjes per maand:
www.jerweb.nl/pv3/month.html

[lemonade]

Zo, we zijn live!

Monitoring werkte in een keer, zie linkje in m'n footer

@Jerrythafast als je hulp nodig hebt bij de monitoring UI hoor ik het graag, ook geïnteresseerd!

[RTB]

Jerrythafast schreef op zondag 18 juni 2017 @ 20:08:
[...]

Bedankt voor het gestelde vertrouwen

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

Bijna een maand later, maar de encryptie is nu dan toch nog geactiveerd. De SE5000H is 6 Juni online gegaan en vanochtend was het updaten van PVOutput gestopt.
Stappen zoals beschreven in het begin van het topic zijn nog steeds van toepassing. Het feit dat het zo lang heeft geduurd was dus niet omdat SE een heel ander encryptiemechanisme aan het voorbereiden was.

Het get-encryption-key script van Jerry werkt dus nog gewoon, had ik natuurlijk ook niet aan mogen twijfelen ;-)

[serienummer]

@RTB
Ok duidelijk, Dan kan ik hem dus eventueel ook nog verwachten voor mijn SE4000H.
Ik zal de PCAPs goed bewaren.

[CubicQ]

Hier ook: vanochtend 09:20 is m'n update naar pvoutput gestopt. Straks even de decryptie aanzetten..

[serienummer]

Ja, Ik had mijn mond moeten houden. Die van mij is ook gestopt.
Dit is wat er in de logging(liveupdate.log) staat:

Reading from -
Warning! Got 74 mysterious bytes left! (state=0)
d5 d0 8f b5 75 ce 43 2a 7d 87 30 eb 29 4c 31 45 36 7e 9c 4c 73 30 85 ee 7e 71 2e 0f 29 89 0e 11 72 fc b4 54 73 1e 01 6a 9b 95 32 03 e8 2f$
Warning! Got 22 mysterious bytes left! (state=0)
f4 b5 4e a3 12 2c a8 53 ed 65 1a e3 22 ad dc d5 7f 13 96 79 f2 c7

Maar bij het uitvoeren van find-key-in-pcap.py door alle .pcap bestanden vind ik helaas geen key:
Sorry, your key is not in the given input file(s).

Heb ik nu een beetje pech, of mis ik een stap.

Groeten
Palermo

[lemonade]

@serienummer hier hetzelfde nu sinds 10:00.
Een aantal meldingen in de liveupdate.log zoals `Warning! Got 517 mysterious bytes left! (state=0)`.

Ook geen key te vinden in de pcap's volgens het script.

@Jerrythafast enig idee?

Edit: ik denk dat ik het al weet...ik filter de tcpdump iets te hard Dat wordt vanavond de kap eraf halen en serieel aan de gang

[ Voor 22% gewijzigd door lemonade op 05-07-2017 11:11 ]

[serienummer]

Ik zal de kap er ook even afhalen en kijken wat de aansluitingen zijn.
Ik maak nu gebruik van deze omvormer : SE4000H

Ik hoop dat het gaat lukken.. Welke omvormer heb jij? En gebruik jij extra hardware hier voor?

Groeten
Palermo

[lemonade]

@serienummer Voor zover ik me ingelezen heb is er alleen een micro-usb kabel nodig die ingeprikt kan worden op de omvormer.

[serienummer]

lemonade schreef op woensdag 5 juli 2017 @ 13:13:
@serienummer Voor zover ik me ingelezen heb is er alleen een micro-usb kabel nodig die ingeprikt kan worden op de omvormer.

Zn kabeltje heb ik wel.. Dat moet dus goedkomen. Ik zal wat foto`s maken en online zetten.

Is het mogelijk de gemaakte PCAP files later nog te uploaden? zodat er geen gat ontstaat?

[ Voor 12% gewijzigd door serienummer op 05-07-2017 14:08 ]

[serienummer]

Ik heb de kap open gemaakt. Maar ik kan geen USB aansluiting vinden.
Ik heb er foto`s van gemaakt,

@lemonade
Heb jij het zelfde?
SEO01
SEO02
SEO03

Groeten
Palermo

[lemonade]

@serienummer Hier weer alles aan de praat na het uitlezen van de key serieel.

Bij mij zit de usb poort hier:

[serienummer]

Hoi @lemonade
Ik heb duidelijk een ander controller board.
Wat voor een Omvormer heb jij?

Groeten
Palermo

[lemonade]

@serienummer zie de footer onder m'n bericht

De SE4000H (HD Wave serie) is zo te zien anders dan de 'reguliere' omvormers, wellicht heeft er iemand ervaring mee hier?
Als hij geen seriële aansluiting heeft is een factory reset wellicht? Weet niet of dat het gewenste resultaat geeft maar als laatste redmiddel wellicht een optie.

[ Voor 75% gewijzigd door lemonade op 05-07-2017 21:05 ]

[Jerrythafast]

lemonade schreef op woensdag 5 juli 2017 @ 10:41:
@serienummer hier hetzelfde nu sinds 10:00.
Een aantal meldingen in de liveupdate.log zoals `Warning! Got 517 mysterious bytes left! (state=0)`.

Ook geen key te vinden in de pcap's volgens het script.

@Jerrythafast enig idee?

Edit: ik denk dat ik het al weet...ik filter de tcpdump iets te hard Dat wordt vanavond de kap eraf halen en serieel aan de gang

Ik kan me twee opties bedenken die hier spelen:
1. De manier waarop de SolarEdge server de key opvraagt is veranderd waardoor het script het niet meer herkent.
2. Het MAC-adres of IP-adres van de omvormer heb je in het tcpdump FILTER argument gezet (in se-logger-service.sh), maar om een of andere reden wordt hiermee de communicatie naar de omvormer toe weg gefilterd. Dan vindt het script ook niet wat het zoekt.

In beide gevallen moet de key nog in de PCAP file staan. Als je telemetriedata in de PCAP file staat, dan staat de key er ook in. Simple as that.

Ik heb zojuist een pcap van @serienummer ontvangen, deze ga ik even doorpluizen.

EDIT: In het bestand van @serienummer is het probleem te verklaren door optie 2. Waarschijnlijk bij @lemonade hetzelfde probleem.

[ Voor 5% gewijzigd door Jerrythafast op 05-07-2017 21:26 ]

[lemonade]

@Jerrythafast Kleine note voor de OP: ik heb de cron onder de root user gezet ipv de default ubuntu user aangezien ik anders geen rechten had om de se-logger service te herstarten.

code:

sudo crontab -u root -e

in plaats van

code:

crontab -e

[Jerrythafast]

Bedankt @lemonade, heb het aangepast Als ik trouwens 'sudo crontab -e' doe pakt hij automatisch de crontab van root. Is dat bij jou anders?

[ Voor 55% gewijzigd door Jerrythafast op 06-07-2017 19:29 ]

[lemonade]

Klopt, dat werkt inderdaad ook aangezien je dan al root bent. Die -u is dus niet nodig.

[spirouspider]

Dag allemaal

Er wordt bij ons volgende maandag een SolarEdge SE4000H (HD Wave dus) geïnstalleerd. Ik heb het begin gelezen van dit topic en het einde, maar helaas niet alle 18 pagina's. Ik lees echter wel hier op het einde dat er wat problemen waren, maar die waren te wijten aan een tcpdump setting.

Ik ben mijn thuisnetwerk aan het indelen in VLANs en heb een VLAN voorzien voor IoT-dingen die enkel extern kunnen communiceren (dus niet naar interne Clients en bewakingscamera's en dergelijke), en zelfs dan nog gefirewalld zullen worden.

Mijn vraag is tweeledig:
- Ik overweeg om de se-logger te gebruiken, misschien niet om meteen de data te gebruiken maar om toch de key te hebben zodat ik later de mogelijkheid heb iets met de data te doen. Ik zal hiervoor een GL-Inet toestelletje gebruiken. Zijn er zaken waar ik specifiek aandacht aan moet besteden met mijn HD Wave?
- Zijn er mensen die reeds ervaring hebben met het firewallen van de SE omvormers? Is er een vaste domeinnaam of IP waarmee deze communiceert? Een vast protocol?

Alvast bedankt voor jullie tips

[Verwijderd]

hoi

Ik hem een SE7K (3 fase) omvormer en krijg alleen de volgende meldingen in de log:
==> liveupdate.log <==
Warning! Got 421 mysterious bytes left! (state=0)
2b 87 0a b6 dc 7a 26 39 eb 4d cc fe b1 53 cb 3a b4 35 d8 91 e0 73 50 50 b6 9f aa 3c b9 ee fb 16 a5 ca d5 39 d6 0b 72 10 b4 79 92 1e e6 63 93 5a e3 ee b4 26 ca 16 9b c3 17 2f af e9 70 6d 66 1a 55 15 81 fa 41 23 82 b4 83 ea 81 74 0c 27 e6 f6 f4 04 7e 4a d9 da 09 07 94 7a 8c 1e f3 99 0c 5e 6c aa 1c 9f 82 de 9d 77 6c 25 77 6f 43 ef 7c 23 d0 24 5b e6 c6 b3 f1 08 3d ed a7 db 64 3e ce 67 ff e1 db 31 45 f6 3d fd a7 3b 5a 47 5e e7 92 d2 fd cf 41 6b 88 3a 74 03 f4 2b 6a 69 58 06 a6 25 f2 7f f5 8b 1a 1e 36 26 2c 28 53 6d e4 33 52 f2 84 14 62 cd 85 12 50 1f b9 53 31 fd 47 6e 2b df 4a 7f b0 c2 a7 97 7b f5 b6 69 eb c2 ed 52 b7 af 2c f9 41 a2 53 f3 35 cb 2b f1 87 5f 68 ea 58 6d a0 18 8e 07 d9 44 5c 30 18 03 c2 1f ed 38 4f 96 c4 5f db d1 b4 f4 15 7b 60 20 6c d2 db 1a 4e a0 10 b9 ce e8 20 86 a6 dc d3 da 85 ca 9a 3b ea 28 29 da 9a 0b 05 90 13 5c 4b b2 6a 2c 0f a4 b6 3c 0f 5d 25 1a a8 31 7f c6 fe 31 71 dd 39 12 3f 7c f8 b0 95 2a 24 73 b4 f1 8b c5 9a 95 3f 5b 25 de 5c 28 fe db 92 e4 a2 44 20 39 fe c4 ac 0f 05 71 57 72 c7 b0 cd fe 7b f3 cb b1 16 73 bf a4 86 3f bd 15 a2 4e ee 89 9d ee eb 1e 33 92 0b 01 68 43 d0 0d bd b1 0f d2 e1 1e af ff 35 41 e7 18 ea 5a 14 10 27 ab f7 95 b3 13 2e a6 f6 4a 17 28 0a d8 27 ac f7 2c e8 af 5a 46 5f db 84 bf 2d 81 5d 43 8e d2 e6 4a 03
Warning! Got 22 mysterious bytes left! (state=0)
cb 9e 70 31 3e 27 1d c5 eb 73 fd 12 50 4f 0f 21 fc 67 dc 33 e5 23
Warning! Got 524 mysterious bytes left! (state=0)
3c 73 aa 2d bf 90 5b 0b 73 2b 9f 78 57 21 22 b3 1b 4f e4 43 50 6b 54 53 a3 1b d6 c0 64 f0 7c e6 e5 0b 18 23 37 41 b8 d4 cc 35 4e 19 ae b5 bd e5 08 1c 4d ea a7 58 88 ea bb 8a 7c 77 4c f4 47 64 35 ea c0 8c f8 57 99 f2 35 3c 51 df 99 3a c4 1b 9e 19 60 8e e4 74 9a 37 13 3b 53 d0 03 37 ab 61 bb 10 98 27 da 3a d8 5c cf 2c d1 04 9f e1 27 c8 c2 32 a0 20 c7 5a 6e ab f3 89 14 ac 36 31 ad f3 71 82 18 99 71 97 5d 39 e7 62 3e 55 98 57 9f 52 c4 d5 a7 bd 46 e7 23 5e 78 ad ba 43 15 04 81 b8 7a 24 16 6a 80 d0 67 c2 3e 7d 9f c8 52 b0 cc 05 90 b2 93 53 15 bb b5 ea c9 d0 35 1d d7 f3 42 6a 76 c6 14 03 2c 30 6c 57 55 63 ee b9 70 f8 be 52 02 ac c8 89 bf d3 09 1b 26 f8 c2 33 bb 7e e7 68 b5 94 bc 3f 64 48 38 67 c4 85 3c 01 14 fb bb 07 2a 83 3b f9 99 bc d3 4b 0f 94 9e 5b 2e 96 4a 8a 4a 6f 0c 75 ca 32 ed 0a f3 c6 1a 9b bb 4a 55 ec 3f fd e4 1c 63 2e 92 5d 80 d1 1e 4d da df 8f 11 56 b9 91 9f ea c9 3c 66 22 10 77 ce 00 0a 31 58 08 2c 29 9c bd 23 f2 a2 f1 a7 12 e1 13 08 75 f5 63 b7 d8 f3 a3 66 02 2f a4 9a f2 4f cb 8a 64 7e 84 ba b3 91 18 a7 6d 60 f6 f0 27 d3 19 40 c9 92 81 33 25 e9 86 f2 4b 96 80 45 d9 46 cf dd 7f f4 b7 eb 77 c6 9e 73 0f a5 43 6e 43 dd 82 83 91 c0 9a 77 9a b3 7a 2f d3 2a 3b dc 08 31 48 d6 36 ce ef d8 ee bb a3 62 3b 54 e2 80 38 b6 a2 3f 9a ef 2d 0f 6d 68 c9 1a 6b 6d 30 02 ea 77 7f 2d e3 dd 7a 6a 8c 29 7c 07 45 e7 a2 68 2e 5a f0 0a 31 50 7d 02 aa 62 76 ac 22 37 c6 93 49 e4 4a 6d 3e a8 a8 2d 51 f8 a0 bc c2 12 67 78 cb 3c 6f 73 c5 7b 6d 04 b2 36 26 cd 48 09 a6 0e 1c 0e 77 84 a9 24 48 0a 5b 30 eb c0 09 40 d3 e5 17 3b 23 2e a8 cb 24 e7 fa 5b a3 cb 96 b7 a5 d6 4d a1
Warning! Got 22 mysterious bytes left! (state=0)
c8 8a e3 e6 b7 4b 09 54 80 16 69 13 5a c4 eb f7 2b 11 d8 76 b3 4d


Is het script ook compatibel met de SE7k, of werkt hij er niet mee?

PCAP file

Alvast bedankt

[Jerrythafast]

spirouspider schreef op woensdag 12 juli 2017 @ 19:32:
- Ik overweeg om de se-logger te gebruiken, misschien niet om meteen de data te gebruiken maar om toch de key te hebben zodat ik later de mogelijkheid heb iets met de data te doen. Ik zal hiervoor een GL-Inet toestelletje gebruiken. Zijn er zaken waar ik specifiek aandacht aan moet besteden met mijn HD Wave?

Ik ben niet bekend met die GL-Inet spulletjes. Waar je in ieder geval op moet letten is dat je dus pcap files krijgt waar de data in staat die de omvormer verstuurt. Verder is het wel praktisch om ook de data die naar de omvormer toe gaat te capturen, want dat heeft het find-key-in-pcap.py script nodig om je encryptiesleutel te vinden. Als je alleen de data hebt die de omvormer verstuurt werkt dat script niet en is er wat mensenwerk nodig om de sleutel eruit te vissen als de encryptie eenmaal is ingeschakeld. Dit is wat ik vorige week voor twee mensen in dit topic heb gedaan (is op zich niet heel veel werk als je weet waar je naar zoekt, maar handig is het niet).
[quote]

- Zijn er mensen die reeds ervaring hebben met het firewallen van de SE omvormers? Is er een vaste domeinnaam of IP waarmee deze communiceert? Een vast protocol?

Voor zover ik weet communiceert hij alleen met prod.solaredge.com. Protocol is TCP, poort wisselt wel eens. Meestal 22222 of 22221 en een enkele keer schakelt hij naar poort 80 (waarschijnlijk om firewalls te ontwijken, want hij doet niks met HTTP op poort 80). Als onderdeel van de netwerktest (die met de reeks 1-tjes op het display) pingt hij ook naar google.com geloof ik.

Verwijderd schreef op woensdag 12 juli 2017 @ 20:05:
hoi

Ik hem een SE7K (3 fase) omvormer en krijg alleen de volgende meldingen in de log:
==> liveupdate.log <==
Warning! Got 421 mysterious bytes left! (state=0)
2b 87 0a b6 dc 7a 26 39 eb 4d cc fe b1 53 cb 3a b4 35 d8 91 e0 73 50 50 b6 9f aa 3c b9 ee fb 16 a5 ca d5 39 d6 0b 72 10 b4 79 92 1e e6 63 93 5a e3 ee b4 26 ca 16 9b c3 17 2f af e9 70 6d 66 1a 55 15 81 fa 41 23 82 b4 83 ea 81 74 0c 27 e6 f6 f4 04 7e 4a d9 da 09 07 94 7a 8c 1e f3 99 0c 5e 6c aa 1c 9f 82 de 9d 77 6c 25 77 6f 43 ef 7c 23 d0 24 5b e6 c6 b3 f1 08 3d ed a7 db 64 3e ce 67 ff e1 db 31 45 f6 3d fd a7 3b 5a 47 5e e7 92 d2 fd cf 41 6b 88 3a 74 03 f4 2b 6a 69 58 06 a6 25 f2 7f f5 8b 1a 1e 36 26 2c 28 53 6d e4 33 52 f2 84 14 62 cd 85 12 50 1f b9 53 31 fd 47 6e 2b df 4a 7f b0 c2 a7 97 7b f5 b6 69 eb c2 ed 52 b7 af 2c f9 41 a2 53 f3 35 cb 2b f1 87 5f 68 ea 58 6d a0 18 8e 07 d9 44 5c 30 18 03 c2 1f ed 38 4f 96 c4 5f db d1 b4 f4 15 7b 60 20 6c d2 db 1a 4e a0 10 b9 ce e8 20 86 a6 dc d3 da 85 ca 9a 3b ea 28 29 da 9a 0b 05 90 13 5c 4b b2 6a 2c 0f a4 b6 3c 0f 5d 25 1a a8 31 7f c6 fe 31 71 dd 39 12 3f 7c f8 b0 95 2a 24 73 b4 f1 8b c5 9a 95 3f 5b 25 de 5c 28 fe db 92 e4 a2 44 20 39 fe c4 ac 0f 05 71 57 72 c7 b0 cd fe 7b f3 cb b1 16 73 bf a4 86 3f bd 15 a2 4e ee 89 9d ee eb 1e 33 92 0b 01 68 43 d0 0d bd b1 0f d2 e1 1e af ff 35 41 e7 18 ea 5a 14 10 27 ab f7 95 b3 13 2e a6 f6 4a 17 28 0a d8 27 ac f7 2c e8 af 5a 46 5f db 84 bf 2d 81 5d 43 8e d2 e6 4a 03
Warning! Got 22 mysterious bytes left! (state=0)
cb 9e 70 31 3e 27 1d c5 eb 73 fd 12 50 4f 0f 21 fc 67 dc 33 e5 23
Warning! Got 524 mysterious bytes left! (state=0)
3c 73 aa 2d bf 90 5b 0b 73 2b 9f 78 57 21 22 b3 1b 4f e4 43 50 6b 54 53 a3 1b d6 c0 64 f0 7c e6 e5 0b 18 23 37 41 b8 d4 cc 35 4e 19 ae b5 bd e5 08 1c 4d ea a7 58 88 ea bb 8a 7c 77 4c f4 47 64 35 ea c0 8c f8 57 99 f2 35 3c 51 df 99 3a c4 1b 9e 19 60 8e e4 74 9a 37 13 3b 53 d0 03 37 ab 61 bb 10 98 27 da 3a d8 5c cf 2c d1 04 9f e1 27 c8 c2 32 a0 20 c7 5a 6e ab f3 89 14 ac 36 31 ad f3 71 82 18 99 71 97 5d 39 e7 62 3e 55 98 57 9f 52 c4 d5 a7 bd 46 e7 23 5e 78 ad ba 43 15 04 81 b8 7a 24 16 6a 80 d0 67 c2 3e 7d 9f c8 52 b0 cc 05 90 b2 93 53 15 bb b5 ea c9 d0 35 1d d7 f3 42 6a 76 c6 14 03 2c 30 6c 57 55 63 ee b9 70 f8 be 52 02 ac c8 89 bf d3 09 1b 26 f8 c2 33 bb 7e e7 68 b5 94 bc 3f 64 48 38 67 c4 85 3c 01 14 fb bb 07 2a 83 3b f9 99 bc d3 4b 0f 94 9e 5b 2e 96 4a 8a 4a 6f 0c 75 ca 32 ed 0a f3 c6 1a 9b bb 4a 55 ec 3f fd e4 1c 63 2e 92 5d 80 d1 1e 4d da df 8f 11 56 b9 91 9f ea c9 3c 66 22 10 77 ce 00 0a 31 58 08 2c 29 9c bd 23 f2 a2 f1 a7 12 e1 13 08 75 f5 63 b7 d8 f3 a3 66 02 2f a4 9a f2 4f cb 8a 64 7e 84 ba b3 91 18 a7 6d 60 f6 f0 27 d3 19 40 c9 92 81 33 25 e9 86 f2 4b 96 80 45 d9 46 cf dd 7f f4 b7 eb 77 c6 9e 73 0f a5 43 6e 43 dd 82 83 91 c0 9a 77 9a b3 7a 2f d3 2a 3b dc 08 31 48 d6 36 ce ef d8 ee bb a3 62 3b 54 e2 80 38 b6 a2 3f 9a ef 2d 0f 6d 68 c9 1a 6b 6d 30 02 ea 77 7f 2d e3 dd 7a 6a 8c 29 7c 07 45 e7 a2 68 2e 5a f0 0a 31 50 7d 02 aa 62 76 ac 22 37 c6 93 49 e4 4a 6d 3e a8 a8 2d 51 f8 a0 bc c2 12 67 78 cb 3c 6f 73 c5 7b 6d 04 b2 36 26 cd 48 09 a6 0e 1c 0e 77 84 a9 24 48 0a 5b 30 eb c0 09 40 d3 e5 17 3b 23 2e a8 cb 24 e7 fa 5b a3 cb 96 b7 a5 d6 4d a1
Warning! Got 22 mysterious bytes left! (state=0)
c8 8a e3 e6 b7 4b 09 54 80 16 69 13 5a c4 eb f7 2b 11 d8 76 b3 4d


Is het script ook compatibel met de SE7k, of werkt hij er niet mee?

PCAP file

Alvast bedankt

Zo te zien is op jouw omvormer de encryptie ingeschakeld. Je hebt de encryptiesleutel van de omvormer nodig om deze data te ontcijferen. Deze stuurt de omvormer 1x naar de SolarEdge server, vlak voordat de encryptie wordt ingeschakeld. Als je nog oudere PCAP files hebt dan degene die je hebt geüpload, zou je met het bij se-logger gevoegde scriptje 'find-key-in-pcap.py' misschien de sleutel kunnen vinden. Als je geen oudere PCAP files hebt, was encryptie waarschijnlijk al ingeschakeld voordat je se-logger had geïnstalleerd. In dat geval heb je de sleutel gemist. In dat geval zul je de omvormer open moeten maken om er een USB-kabel in te prikken. Dan kun je met het script 'get-key-by-rs232.py' de sleutel opvragen.

[Verwijderd]

Hoi,

Ik had al verbinding gemaakt via USB en de private key opgevraagd en in liveupdate.py gezet, en blijkbaar werkt het nog niet. Enig idee?

Alvast bedankt

[Jerrythafast]

@Verwijderd Als je de key naar liveupdate.py hebt gekopieerd zou dat verder in orde moeten zijn. Hierna zou je als het goed is door het commando 'python /opt/se-logger/liveupdate.py /opt/se-logger/*.pcap' te draaien de data moeten kunnen ontsleutelen. Het is belangrijk dat je hem hierbij dus alle eerder gemaakte pcap files ook door laat lopen (dus letterlijk het commando met '*.pcap' erin laten draaien, hij moet alles even doorlopen). In het begin kan hij een paar 'mysterious bytes' warnings geven. Er wordt namelijk nog een tweede, tijdleijke encryptiesleutel gebruikt, welke 1x tot enkele keren per dag wisselt. Pas als er zo'n encryptiesleutel voorbij komt kan de data daadwerkelijk goed ontsleuteld worden en moeten de warnings dus ophouden. (Tipje: Als je de netwerkkabel van de omvormer een aantal minuten eruit trekt zodat hij zijn verbinding met de server verliest, zal hij ook een nieuwe tijdelijke encryptiesleutel versturen wanneer de verbinding weer is hersteld. Hierna zal ontsleuteling zeker moeten werken.)

Vergeet trouwens ook niet om de solaredge-logger service even te herstarten (zodat hij het gewijzigde script gaat draaien).

[ Voor 4% gewijzigd door Jerrythafast op 12-07-2017 22:47 ]

[Shakespeare2000]

Mijn SE4K loopt via een rPi in bridge naar de router. De SE is op de onboard NIC (eth0) van de rPi aangesloten, de router middels een USB NIC (eth1).
Welke interface moet nu ge-tcpdump-t worden? 0 of 1?

Ben een beetje bang dat ik nu de verkeerde filter en dus straks de key mis...

Laat maar... ik zag de .pcap niet groeien. UTP kabel in de rPi deed wonderen .
PS op eth0 trouwens

[ Voor 32% gewijzigd door Shakespeare2000 op 14-07-2017 18:03 ]

[serienummer]

Hoi.
Ik heb een vraag.

Ik heb het vermoeden dat een nieuwe encryptie is aangemaakt. Ik heb sins vandaag geen uploads meer naar PVOutput.

Dit is wat er in het logbestand staat liveupdate.log:

Warning! Got 22 mysterious bytes left! (state=0)
2a 0d bf 5e 55 e4 1b 8d ca 1e 83 77 2a 6b 76 9a 15 d3 41 50 1a ed
Warning! Got 22 mysterious bytes left! (state=0)
d5 b4 b6 f3 7a 81 d9 9e 71 ec 77 05 45 86 a8 88 57 b6 e0 a8 64 a2
Warning! Got 74 mysterious bytes left! (state=0)
8c 76 99 0e cd 6b 0a 7e 1f 16 65 1c 02 93 9f 07 93 39 64 a6 c2 cb 21 75 30 b7 bf be ff 9d b2 a0 27 7e d5 7b e0 78 94 68 9e e0 93 31 6d 39 c6 0e 39 5a f6$
Warning! Got 507 mysterious bytes left! (state=0)
73 a2 0c de 6c e9 dd c4 2e 1a fa 24 88 6a b1 6e 45 6e 32 74 c5 1f dd 5f 1d ef a3 05 f6 c1 aa 0b a9 50 02 9a 6c 8f 1a 09 82 85 57 b4 71 f4 3d ba 9a d9 71$
Warning! Got 22 mysterious bytes left! (state=0)
32 1a 23 19 10 01 97 44 1f f5 33 c1 7c ba 42 06 17 f1 2f c3 d5 a9

@Jerrythafast Jerrytafast
Zou jij nog een keer naar de PCAP file willen kijken? Of daar een nieuwe sleutel is zit. ?

Je gaf aan in de vorige dump bestanden maar eenzijdige communicatie zat. Wat moet ik doen om het verkeer van beide kanten te capturen zodat het script "find-key-in-pcap.py" eventueel wel de code kan pakken.
(Dit geld alleen als er inderdaad een nieuwe code is aangemaakt)

Alvast bedankt.
Groeten
Palermo

[Jerrythafast]

@serienummer, eerst even een simpele check. Trek de netwerkkabel van je omvormer er even voor een kwartier uit. In dat kwartier kun je voor het gemak ook de solaredge-logger service even herstarten, zodat je met een schone pcap begint. Draai dan het commando 'tail -f /opt/se-logger/liveupdate.log' zodat je de output van de logger service in beeld hebt. Als het goed is zie je alleen wat oude meldingen en staat hij verder stil; de laatste regel is 'Reading from -', van toen de service herstartte.

Na een kwartier steek je de netwerkkabel van de omvormer er weer in. Als alles goed is komt er een regel 'Setting new 0503 key' in het log te staan en verder niets (daarna zou het ook gewoon weer moeten werken). Als het niet goed is krijg je weer mysterious byte meldingen en dan ben ik inderdaad wel nieuwsgierig naar je pcap files van vandaag en/of gisteren om te zien waar het dan kapot is gegaan.


Het is me trouwens niet helemaal duidelijk waarom er bij jou geen inbound data in de pcap file staat, aangezien je tcpdump filter gewoon "tcp" is en er dus in principe alle tcp verkeer in beide richtingen op die poort in zou moeten staan.

[spirouspider]

Jerrythafast schreef op woensdag 12 juli 2017 @ 21:37:
[...]
Ik ben niet bekend met die GL-Inet spulletjes. Waar je in ieder geval op moet letten is dat je dus pcap files krijgt waar de data in staat die de omvormer verstuurt. Verder is het wel praktisch om ook de data die naar de omvormer toe gaat te capturen, want dat heeft het find-key-in-pcap.py script nodig om je encryptiesleutel te vinden. Als je alleen de data hebt die de omvormer verstuurt werkt dat script niet en is er wat mensenwerk nodig om de sleutel eruit te vissen als de encryptie eenmaal is ingeschakeld. Dit is wat ik vorige week voor twee mensen in dit topic heb gedaan (is op zich niet heel veel werk als je weet waar je naar zoekt, maar handig is het niet).
[quote]

[...]
Voor zover ik weet communiceert hij alleen met prod.solaredge.com. Protocol is TCP, poort wisselt wel eens. Meestal 22222 of 22221 en een enkele keer schakelt hij naar poort 80 (waarschijnlijk om firewalls te ontwijken, want hij doet niks met HTTP op poort 80). Als onderdeel van de netwerktest (die met de reeks 1-tjes op het display) pingt hij ook naar google.com geloof ik.

Bedankt voor deze nuttige informatie. Dat wordt dus een
- Ping to all
- 80,22222,22221 to prod.solaredge.com
- DNS to all

Ik was net m'n GL-Inet bakje aan het voorbereiden toen het mis ging. De benodigde services nemen best wel wat plaats in m, waardoor m'n geheugen vol liep. Bij het proberen vrijmaken van wat extra geheugen helaas iets teveel gewist, waardoor hij bricked is nu. M'n UART kabel ligt op het werk dus dat is pas voor volgende week.

Ik heb er nog eentje liggen, een ander model. Ik zal eens kijken of ik die voorlopig kan inzetten alleen voor het maken van de pcaps.

[serienummer]

@Jerrythafast
Ik het precies zo gedaan en het werkt weer.
Is is overegens erg raar wat dit heb ik gister precies ook zo gedaan. Ik snap er niks van.
Geeft ook niet.. Het werkt weer.
Nu is de vraag. Ik heb de PCaps files nog.. Kan ik deze alsnog in de database zetten en door zetten naar PVOutput?

Bedankt voor je reactie :-)

Groeten
Palermo

[Jerrythafast]

@serienummer
Je kunt proberen de data alsnog in de database te stoppen. Trek voor de zekerheid eerst even weer je omvormer van het netwerk af. Daarna:

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

Hiermee laat je alle data opnieuw in de database inlezen. Er bestaat een kans dat hij de data van gisteren alsnog niet kan lezen (dan krijg je weer een bups mysterious bytes meldingen). In dat geval mist er iets aan communicatie in je pcap file van gisteren (namelijk zo'n '0503 key') waardoor de data van gisteren niet ontsleuteld kan worden.

Wanneer de data in je database staat kun je met deze MySQL query het pvo-upload script terug in de tijd zetten om de gemiste data alsnog te uploaden (hij begint met uploaden van de gegevens van de datum die je in de query invult):

MySQL:

UPDATE live_update SET pvo_last_live = UNIX_TIMESTAMP("2017-07-13");

Als je klaar bent kun je de omvormer er weer in steken, op het moment dat de omvormer weer contact krijgt moet er weer zo'n regel 'Setting new 0503 key' in je log komen te staan.

[Shakespeare2000]

Vanochtend zag ik dat PVOutput niet meer bijgewerkt werd, dus op zoek naar de key. Deze was zo gevonden, vervolgens sectie 6.3 gevolgd en PVOutput was weer bij.

Een paar uur later zie ik dat PVOutput weer stil staat. Op de rPi lijkt de pcap ook niet meer te groeien. Een aantal service stops / starts, een reboot en wat tijd later groeit de laatste pcap nog steeds niet. De laatste timestamp in telemetry_inverter_3phase is 1500115492, zo ook pvo_last_live in de live_update tabel.

Wat ik anders gedaan heb dan in de handleiding beschreven, is dat ik de bridge in /etc/network/interfaces via DHCP een IP-adres laat krijgen:

code:

iface br0 inet dhcp
    bridge_ports eth0 eth1

Iemand een idee wat er aan de hand is? Ik kan vanuit de rPi en willekeurige andere apparaten de SE4K gewoon pingen.

Edit:
Op de omvormer zag ik dat er 7 1'tjes stonden, en één 0, met daaronder TCP connection failed. Na een paar rondjes door het menu, gaat de laatste 0 naar 1, en staat er ook ineens S_OK. En PVOutput is nu ook weer bijgewerkt...
Als iemand een idee heeft wat de oorzaak hiervan is geweest, hoor ik het graag!

[ Voor 16% gewijzigd door Shakespeare2000 op 15-07-2017 22:15 . Reden: Update ]

[Jerrythafast]

(EDIT: Probleem van hierboven is al opgelost. Blijkbaar had de omvormer even een zetje nodig om weer contact te zoeken met het web )

[ Voor 163% gewijzigd door Jerrythafast op 15-07-2017 22:21 ]

[spirouspider]

Is er een gemakkelijke manier om te zien vanaf wanneer het verkeer geencrypteerd is? Ik ga namelijk manueel loggen tot de key er is, om dan daarna een toestelletje voor te bereiden.

[Jerrythafast]

@spirouspider, je hebt in ieder geval een toestelletje nodig om tcpdump (of Wireshark o.i.d.) te draaien en de data in pcap files te bewaren. Zet daar dan ook alvast het find-key-in-pcap.py script op en laat dat eens in de zoveel tijd los op je pcap files. Zodra die een key vindt weet je dat encryptie is aangezet en heb je gelijk je sleutel te pakken.

(Eén voorwaarde: de pcap files moeten de communicatie van en naar de omvormer bevatten, anders werkt het script niet.)

[spirouspider]

Dat had ik begrepen. Ik heb op m’n toestelletje een LAN en een WAN poort, dewelke ik bridge. De bridge zelf is unmanaged, heeft dus geen IP en komt niet tussen in de communicatie. Op beide poorten heb je dan een volledige communicatie heen en weer tussen netwerk en omvormer.

Buiten dat de GL-Inet’jes (die ik heb) weinig vast geheugen hebben (om de services te installeren, de pcaps kunnen eventueel op USB stick), zijn het wel goeie toestelletjes voor dit doeleinde. Je hebt twee poorten die je kan bridgen, en met WiFi kan je het ding ofwel aan je thuisnetwerk hangen ofwel als hotspot gebruiken om ermee te verbinden. Je zou ook de bridge zelf een IP kunnen geven om met het netwerk te verbinden zodanig dat je aan je loggings kan via het gewone netwerk, maar dat is bij mij niet wenselijk aangezien ik de omvormer op een aparte VLAN zet. Daarnaast moet je dan inderdaad opletten met wat je juist gaat dumpen (ook de communicatie van en naar het toestel zit erbij als je de verkeerde interface neemt).

Als ik een keer wat tijd heb probeer ik je script draaiend te krijgen op dit model (https://www.gl-inet.com/product/gl-ar300m/). Enige nadeel van deze is nog dat hij OpenWRT draait en geen systemd heeft, dus er zal wat geprutst moeten worden om de service draaiend te krijgen/houden denk ik.

[Jerrythafast]

Init script gok ik? Ik ben met dit projectje begonnen op Ubuntu 14.04 LTS. De panelen lagen er immers al voor 2016-04. In het begin draaide het bij mij via een init script. Ik was wel blij toen ik door kreeg dat het via systemd zo makkelijk in te stellen is.

Het duurde alleen een halve nacht voor het zover was, want ik kwam er pas achter dat het hele init gebeuren op de schop was gegaan van 14.04 LTS naar 16.04 LTS toen de upgrade er in een heel laat stadium mee ophield (gelukkig wist ik dat het systeem niet meer zou opstarten totdat dit gefixt was). Mijn eigen init script conflicteerde blijkbaar met iets anders waardoor de Ubuntu updater hem niet automatisch kon omzetten naar systemd service. En daarna besloot de updater dan maar gewoon helemaal niet meer verder te gaan. Heeft tot in de kleine uurtjes geduurd voordat ik de upgrade handmatig had voltooid en met gekruiste vingers het afrondende reboot commando deed

[serienummer]

@Jerrythafast

Hoi,
Ik heb geprobeerd dag 14 van deze maand in de database te zetten. Bij het uitvoeren van commando
python /opt/se-logger/liveupdate.py /opt/se-logger/solaredge-*.pcap krijg ik de voldende meding. Warning! Got 22 mysterious bytes left! (state=0)
zoals je al aangaf mist er dan het een en ander in de data. Toch bijzonder dat het alleen die dag is en zo plotseling.

Maar zolang het nu loop geeft het niet. Alvast bedankt.

Groeten
Palermo

[Cabbie_86]

@Jerrythafast

Hallo,

Vandaag zijn eindelijk mijn panelen geinstalleerd en draait mijn SolarEdge 3680h op volle toeren!
https://pvoutput.org/intraday.jsp?id=59630&sid=53059
Ik heb voordat deze is geinstalleerd me voorbereid dmv van de info uit dit forum. Nu zie ik allemaal data in de tabellen van mysql verschijnen, dus ik neem aan dat alles werkt.
Nu vraag ik me alleen af, hoe kan ik deze data zichtbaar krijgen? Ik zie in de startpost een mooie website staan, echter kan ik hier niets van vinden. Hoe kan ik dit ook gebruiken op mijn RPi3?

thanks

Willem

[ Voor 7% gewijzigd door Cabbie_86 op 22-07-2017 09:49 . Reden: Link naar pvoutput.org toegevoegd ]

[lemonade]

Sinds vannacht geven de captures de 'Mysterious bytes left' error opeens, de encryptie key zou hetzelfde moeten blijven toch?

En de last_0503 kolom bevat nu ook een cryptische waarde (non-ascii).

[ Voor 22% gewijzigd door lemonade op 05-08-2017 10:52 ]

[Jerrythafast]

@lemonade, de last_0503 kolom bevat inderdaad een non-ascii waarde. Het is eigenlijk gewoon een semi-random reeks bytes. Gebruik SELECT HEX(last_0503) om die waarde uit te lezen in MySQL.

Ik heb het vermoeden dat er op een of andere manier een 0503 key langs is geglipt. Je zou de stappen in deze post even kunnen uitvoeren voor een quick fix. Dus: omvormer los, service herstarten, oude pcaps opnieuw inlezen (niet schrikken van een hele lading duplicate key warnings), omvormer er weer aan. Daarna zou het weer stabiel verder moeten lopen. (Check dit even in het logbestand.)

Ontbrekende data op PVOutput kun je aanvullen door zoals in de gelinkte post uitgelegd de pvo_last_live waarde terug te zetten naar "2017-08-05". Dit uiteraard op voorwaarde dat het is gelukt deze data nog in de database te krijgen.

[ Voor 3% gewijzigd door Jerrythafast op 05-08-2017 12:25 ]

[lemonade]

Ik ga nog proberen de data van gister te fixen maar vandaag werkt alles weer zonder iets te doen..

Kan je uitleggen waar de 0503 key voor staat?

[Jerrythafast]

@lemonade dit laat zich niet heel makkelijk uitleggen, want het steekt redelijk complex in elkaar. Het komt er op neer dat de sleutel die je in liveupdate.py hebt moeten invullen niet direct wordt gebruikt om de communicatie mee te versleutelen.

In plaats daarvan wordt er bij elke nieuwe verbinding een nieuwe, tijdelijke encryptie-sleutel gegenereerd die wordt gecombineerd met de 'vaste' sleutel. Het mengsel van die twee sleutels samen geeft de sleutel die daadwerkelijk wordt gebruikt bij de encryptie van de communicatie. Die tijdelijke sleutel wordt verzonden met commando nummer 0503. Dus daarom heb ik het de '0503 key' genoemd.

Het 0503 commando is het eerste commando dat wordt verstuurd wanneer de omvormer 's ochtends uit Night Mode ontwaakt en ook het eerste commando dat wordt verstuurd wanneer de netwerkverbinding eruit heeft gelegen. Als se-logger het 0503 commando niet heeft gezien, mislukt de decryptie en krijg je van die errors in je log. De netwerkkabel van de omvormer er even een paar minuten uit trekken is genoeg om een nieuwe 0503 key te krijgen, waarmee se-logger als het goed is weer verder kan. (Het opnieuw inlezen van de pcap files was vooral in de hoop dat de gemiste 0503 key wel in de pcap file terecht was gekomen.)

Als je precies wilt weten hoe het werkt (en Python code snapt) moet je even naar class SEDecrypt kijken in liveupdate.py. De vaste sleutel en de 0503 key worden samen gebruikt om een SEDecrypt object te maken, dat vervolgens encrypted communcatie (commando nummer 003d) kan ontsleutelen.

[ Voor 24% gewijzigd door Jerrythafast op 06-08-2017 11:20 ]

[Aegle]

In een verloren uurtje met de SolarEdge portal zitten spelen. In het Lay-Out scherm heb je, als administrator, de mogelijkheid om na het aanklikken van de omvormer extra info op te halen. Op deze wijze kun je o.a."realtime" het display van de omvormer tonen door op het vierkante knopje onder het display klikken. Zie screenshot:



Vervolgens wordt eens in de ongeveer vijf seconden het schermpje ververst. Na 30 -40 seconden stopt dit en moet je wederom op de knop klikken.

Deze display gegevens worden ook in de .pcap-file geregistreerd. Tot mijn verbazing is deze data, in tegenstelling tot de versleutelde portal data, gewoon klare tekst:



Nu vroeg ik me af of het mogelijk is om deze data ook weer te geven. Als aanvulling op mijn bestaande web-pagina kan ik dan realtime metertjes toevoegen die om de paar seconden refreshed. Cool... .

Waar ik niet achter kom is welk commando naar de omvormer wordt verstuurd als je op de button klikt. Met mijn beperkte programmeer kennis gaat me dat ook niet lukken .
Is er iemand die dat wél kan achterhalen? Of mij in de juiste richting kan sturen?

[Corn]

Knopje is een POST (zonder body) naar:
https://monitoring.solare.../remoteLcd/switchDisplay/[Site ID]/[reporter ID]

Data ophalen (in JSON)
https://monitoring.solare...p/remoteLcd/fetchDisplay/[Site ID]/[reporter ID]

Returns:

JavaScript: return.json

{"lastUpdateTime":"2017-08-31 08:56:45.0","lcdDisplay":"Vac[V] Vdc[V] Pac[W]\n229.6  747.4  801.1 \nP_OK
: 015/015 <S_OK>\n                ON  \n","state":{"failureReason":null,"fieldReporterPK":{"fieldId"
:[Site ID],"reporterId":[Reporter ID]},"operation":"REMOTE_GET_LCD_DISPLAY","stage":null,"stageIteration":0,"stageProgressPercentage"
:0,"startTime":"2017-08-31 08:56:45.0","state":"IN_PROGRESS","timeRemaining":0,"totalStages":0}}

Succes!

[Aegle]

@Corn: Bedankt! Daar kan ik proberen mee verder te stoeien.

"siteID" ken ik. Echter, "reporterID" zegt me niets...

[ Voor 5% gewijzigd door Aegle op 31-08-2017 12:44 ]

[Corn]

reporterID is een of ander fixed ID wat (vermoed ik) bij de inverter hoort... Is onveranderlijk, blijft hetzelfde bij uit/inloggen. Je kunt 'm vinden door de communicatie te bekijken (ik gebruik Firebug hiervoor). Zal eens kijken of ik een simpel scriptje kan bouwen

[Corn]

Even wat in elkaar gezet, als testje. Volgende stap is in database, RRD database of op MQTT zetten. Ik denk alleen niet dat meneer SolarEdge dit zo bedoeld heeft, dus ik kan me voorstellen dat ze je gaan rate-limiten als je 't heel de dag gebruikt. Het is sowieso niet super reliable.

Je moet username, password, siteID en reporterID invullen, en dan kun je 'm in console draaien.

PHP: getPower.php

<?php

$user = "EDITME";
$password = "EDITME";

$siteID = "EDITME";
$reporterID = "EDITME";

$min_values = 6;
$min_same = 5;

$power_arr = array();

$ch = curl_init();

if(!login($user, $password)){
        curl_close($ch);
        echo "Login failed.\n";
        exec("rm SEcookie.txt");
        die();
}

wakeDisplay($siteID,$reporterID);
sleep(2);


while(1){
        if(count($power_arr)>=$min_values){
                $check = array_slice($power_arr,-$min_same);
                if(count(array_count_values($check))==1){
                        echo "Display asleep, it seems. Wakey wakey!\n";
                        if(!wakeDisplay($siteID,$reporterID)){
                                curl_close($ch);
                                echo "Wakeup failed.\n";
                                exec("rm SEcookie.txt");
                                die();
                        }
                        $power_arr=array();
                        sleep(4);
                };
        }
        fetchDisplay($siteID,$reporterID);
        sleep(2);
}

function login($user, $pass){
        global $ch;
        $arr['password']=$pass;
        $arr['username']=$user;
        $arr['remember']='on';
        $arr['cmd']='login';
        $arr['demo']='false';
        curl_setopt($ch, CURLOPT_URL,"https://monitoring.solaredge.com/solaredge-web/p/submitLogin");
        curl_setopt($ch, CURLOPT_POST, 1);
        curl_setopt($ch, CURLOPT_POSTFIELDS,$arr);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
        curl_setopt($ch, CURLOPT_COOKIEJAR, "SEcookie.txt");
        $server_output = curl_exec ($ch);
        $json = json_decode($server_output);
        if(isset($json->success)){
                return $json->success;
        } else {
                return false;
        }
}


function wakeDisplay($siteID, $reporterID){
        global $ch;
        curl_setopt($ch, CURLOPT_URL,"https://monitoring.solaredge.com/solaredge-web/p/remoteLcd/switchDisplay/".$siteID."/".$reporterID);
        curl_setopt($ch, CURLOPT_POST, 1);
        curl_setopt($ch, CURLOPT_POSTFIELDS,"");
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
        curl_setopt($ch, CURLOPT_COOKIEFILE, "SEcookie.txt");
        $server_output = curl_exec ($ch);
        $json = json_decode($server_output);
        if(isset($json->success)){
                return $json->success;
        } else {
                return false;
        }
}



function fetchDisplay($siteID,$reporterID){
        global $ch,$power_arr;
        curl_setopt($ch, CURLOPT_URL,"https://monitoring.solaredge.com/solaredge-web/p/remoteLcd/fetchDisplay/".$siteID."/".$reporterID);
        curl_setopt($ch, CURLOPT_POST, 0);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
        curl_setopt($ch, CURLOPT_COOKIEFILE, "SEcookie.txt");
        $server_output = curl_exec ($ch);
        $json =  json_decode($server_output);
        list($line0,$line1,$line2,$line3) = explode("\n",$json->lcdDisplay);
        if(((strstr($line2,"P_OK"))&&(strstr($line2,"<S_OK>")))||(strstr($line2,"Fac[Hz] OPs_Ok Temp"))){
                list($vac,$vdc,$pac) = preg_split('/\s+/', $line1);
                $power_arr[] = $vac.$vdc.$pac;
                echo "VAC = $vac, VDC = $vdc, PAC = $pac\n";
        } else {
                if(!wakeDisplay($siteID,$reporterID)){
                        curl_close($ch);
                        echo "Wakeup failed.\n";
                        exec("rm SEcookie.txt");
                        die();
                } else {
                        echo "Flipping to the right page\n";
                }
                $power_arr=array();
                sleep(5);
        }
}

code:

root@Utility:~/solaredge# php getPower.php
VAC = 231.0, VDC = 747.3, PAC = 1214.7
VAC = 230.9, VDC = 747.4, PAC = 1217.6
VAC = 231.3, VDC = 747.5, PAC = 1218.5
VAC = 231.3, VDC = 747.5, PAC = 1224.6
VAC = 231.4, VDC = 747.5, PAC = 1229.1
VAC = 231.3, VDC = 747.4, PAC = 1226.6
VAC = 231.3, VDC = 747.3, PAC = 1229.6
VAC = 231.4, VDC = 747.5, PAC = 1234.0
VAC = 231.3, VDC = 747.4, PAC = 1235.6
VAC = 231.3, VDC = 747.4, PAC = 1235.6
VAC = 231.4, VDC = 747.5, PAC = 1245.1
VAC = 231.2, VDC = 747.3, PAC = 1244.8
VAC = 231.2, VDC = 747.0, PAC = 1246.6
VAC = 231.2, VDC = 747.0, PAC = 1249.6
VAC = 231.0, VDC = 747.0, PAC = 1254.4
VAC = 231.0, VDC = 746.9, PAC = 1257.7
VAC = 230.8, VDC = 746.9, PAC = 1260.7
VAC = 231.0, VDC = 747.0, PAC = 1261.7
VAC = 231.0, VDC = 747.0, PAC = 1261.7
VAC = 231.0, VDC = 747.0, PAC = 1261.7
VAC = 230.8, VDC = 747.0, PAC = 1269.2
VAC = 230.9, VDC = 747.0, PAC = 1273.7
VAC = 230.8, VDC = 747.0, PAC = 1274.7
VAC = 230.8, VDC = 747.0, PAC = 1274.7
VAC = 230.7, VDC = 747.0, PAC = 1275.2
VAC = 230.7, VDC = 747.0, PAC = 1275.2
VAC = 230.7, VDC = 747.0, PAC = 1275.2
VAC = 230.7, VDC = 747.0, PAC = 1275.2
VAC = 230.7, VDC = 747.0, PAC = 1275.2
Display asleep, it seems. Wakey wakey!
VAC = 230.9, VDC = 746.9, PAC = 1304.9
VAC = 230.9, VDC = 746.9, PAC = 1304.9
VAC = 231.0, VDC = 747.0, PAC = 1311.1
VAC = 231.0, VDC = 746.9, PAC = 1314.2
VAC = 231.0, VDC = 746.9, PAC = 1317.9

[MDKlapwijk]

@Jerrythafast bedankt hiervoor.

Gistermiddag is de SE6000H bij ons geplaatst.

Gisteravond het netwerk en de RPi met Domoticz aangepast, zodat deze op eth0 gevoed wordt met een Ubiquiti mirror port van de omvormer.

De se-logger gestart en vanochtend de key uit de pcap's gehaald, de data ingelezen en pvoutput.org ingesteld.

[Rouske]

Iemand enig idee hoe het kan komen dat de Year en Total waarde op het display van de omvormer (SE3680H) 22kWh verschillen (Year<Total) terwijl het pas draait sinds April dit jaar en beide op 0 begonnen zijn.
De totalEnergy uit de 5-min data komt overeenkomt met Total op het display.

[Jerrythafast]

@Rouske Klinkt mij een beetje alsof hij helemaal in het begin op de verkeerde datum stond ingesteld (de eerste dag misschien?) en zijn Year-teller op 0 heeft gezet toen hij 'daar achter kwam'.

[Rouske]

Ik heb nog een oude foto gevonden van 1 juni nadat de omvormer uit was gegaan.
Year staat daar op 1006 kWh en Total op 1005 kWh.
Huidige stand Year is 2768 en Total 2790.
Ik ga SolarEdge wel even mailen of zij een verklaring hebben.

[Aegle]

Even een SQL-vraagje:

Ik probeer een query te maken waarin ik de totale energie van elke maand opvraag.
Mijn website maakt gebruik van de volgende query om de maand totalen in een staafdiagram te laten zien(met dank aan @Pietjebel10):
[code sql]
SELECT YEAR,
FROM_UNIXTIME(timestamp) AS `time` ,
FROM_UNIXTIME( timestamp, '%M' ) AS `date` ,
timestamp, ROUND(SUM(PeakPower),2)
FROM ( SELECT timestamp, DATE( FROM_UNIXTIME(timestamp) ),
FROM_UNIXTIME(timestamp,'%Y') AS YEAR , MAX(e_day) AS 'PeakPower' FROM `telemetry_inverter`
GROUP BY DATE( FROM_UNIXTIME(timestamp) ) ) AS ORG WHERE YEAR = 2017
GROUP BY MONTH( FROM_UNIXTIME(timestamp) );
[/code sql]
Als ik de query draai is dit het resultaat:

+------+---------------------+-----------+------------+-------------------------+
| YEAR | time                | date      | timestamp  | ROUND(SUM(PeakPower),2) |
+------+---------------------+-----------+------------+-------------------------+
| 2017 | 2017-01-01 09:04:07 | January   | 1483257847 |               112147.80 |
| 2017 | 2017-02-01 08:30:12 | February  | 1485934212 |                90307.40 |
| 2017 | 2017-03-01 07:32:49 | March     | 1488349969 |               261927.98 |
| 2017 | 2017-04-01 07:26:29 | April     | 1491024389 |               332640.14 |
| 2017 | 2017-05-01 06:43:01 | May       | 1493613781 |               355802.94 |
| 2017 | 2017-06-01 05:28:06 | June      | 1496287686 |               354335.90 |
| 2016 | 2016-07-21 05:51:22 | July      | 1469073082 |               435215.13 |
| 2016 | 2016-08-01 06:17:36 | August    | 1470025056 |               650000.33 |
| 2016 | 2016-09-01 06:49:04 | September | 1472705344 |               425431.03 |
| 2016 | 2016-10-01 07:59:27 | October   | 1475301567 |               199217.32 |
| 2016 | 2016-11-01 07:32:56 | November  | 1477981976 |               102672.90 |
| 2016 | 2016-12-01 09:00:10 | December  | 1480579210 |                75086.44 |
+------+---------------------+-----------+------------+-------------------------+
12 rows in set (0.57 sec)

In eerste instantie ziet het er goed uit, maar de volgorde klopt niet. 2017 komt voor 2016 en daardoor lopen de maanden door elkaar.
Hoe wijzig ik nu of de jaar volgorde of de maand volgorde (oud naar nieuw of nieuw naar oud)?

Mijn uiteindelijke bedoeling is om de jaren met elkaar te vergelijken. Hier is de @Jerrythafast logging pas gestart in juli vorig jaar en mis ik de data vanaf juni 2014 tot juni 2016 in de database. De maand data van 2014, 2015 en een deel van 2016 staan nu hard gecodeerd in het PHP-script om in het bestaande staafdiagram te tonen.

/me Aegle blijft sql maar lastig vinden.... .

[storeman]

@Aegle Ik kan je best even helpen met je query, maar ik kan de databasestructuur niet helemaal ontleden.

Ik kom tot de volgende conclusies:
- Je moet de tijdkolom weglaten
- Geef de kolommen logische namen
- Je maakt een som omp je piekvermogen (peakpower), dus niet je totale opbrengst

Ik kom tot de volgende query, al ken ik MySQL niet zo goed en je database structuur ook niet:

SQL:

SELECT 
 YEAR(FROM_UNIXTIME(timestamp)) AS `year`,
 MONTH(FROM_UNIXTIME(timestamp)) AS `month` ,
 FROM_UNIXTIME( timestamp, '%M' ) AS `pretty_month` ,
 ROUND(SUM(e_day),2) AS `energy`
 FROM `telemetry_inverter`
 GROUP BY 
    YEAR(FROM_UNIXTIME(timestamp)), 
    MONTH(FROM_UNIXTIME(timestamp)), 
    FROM_UNIXTIME( timestamp, '%M' )
ORDER BY `year` DESC, `month` DESC

[ Voor 3% gewijzigd door storeman op 24-09-2017 18:24 . Reden: Query voorzien van order by ]

[Aegle]

@storeman: Oef, dat is snel...

Even je query gedraaid en nu klopt de volgorde wel. Top! Hier kan ik verder mee.

De structuur is zoals in het starttopic is beschreven.
Zie hieronder de inverter tabel:

code:

CREATE TABLE telemetry_inverter (
    inv_id      INT      UNSIGNED NOT NULL,
    timestamp   INT      UNSIGNED NOT NULL,
    temperature FLOAT             NOT NULL,
    e_day       FLOAT             NOT NULL,
    de_day      FLOAT             NOT NULL,
    v_ac        FLOAT             NOT NULL,
    i_ac        FLOAT             NOT NULL,
    frequency   FLOAT             NOT NULL,
    v_dc        FLOAT             NOT NULL COMMENT 'steps of 0.0625 V',
    e_total     INT      UNSIGNED NOT NULL,
    i_rcd       FLOAT             NOT NULL,
    mode        TINYINT  UNSIGNED NOT NULL COMMENT '1 OFF, 2 SLEEPING, 3 STARTING, 4 MPPT, 5 THROTTLED, 6 SHUTTING_DOWN, 8 STANDBY',
    p_active    FLOAT             NOT NULL,
    p_apparent  FLOAT             NOT NULL,
    p_reactive  FLOAT             NOT NULL,
    PRIMARY KEY (timestamp, inv_id)

[Tallguy]

Ik heb sinds kort een SolarEdge omvormer. Deze is aangesloten op mijn LAN en de installateur heeft de boel op de SolarEdge portal beschikbaar gemaakt voor mij.

Helaas heb ik alleen het dashboard en de layout (wat ik in een ander GoT topic las is dat schijnbaar redelijk gangbaar).
Nu heb ik tot op heden niet de beste ervaringen met de leverancier (breek me de bek niet open ). Ik heb wel een API key en een Site ID gehad van ze, maar ik vermoed dat die is opgeslagen of niet correct is, want met PVOutput krijg ik gewoon geen data binnen.

De URL gebuirken https://monitoringapi.sol...ils.json?api_key=<APIKEY> resulteert in een 403 melding (access forbidden).

Ik heb ze al gemailed of ze mij niet een soort admin kunnen maken zodat ik zelf API's kan genereren en grafieken kan bouwen, koppelen aan mijn NAS cq Homey. Ze reageren echter niet.

Is het soms mogelijk dat ik mezelf alsnog zèlf aanmeld bij Solaredge met de gegevens van mijn omvormer (dus los van hetgeen de installateur al heeft gedaan) zodat ik wel zelf controle heb over mijn omvormer? Ik vind het nl niet helemaal ok als ik zelf geen rechten heb over iets dat mijn eigendom is.

[MDKlapwijk]

@Tallguy, vandaar dat we ze hier in dit topic direct zelf uitlezen en dan zelf pvoutput.org van data voorzien....

[Tallguy]

@MDKlapwijk Dat snap ik, maar ik wil eerst een werkende/correcte API voordat ik verder ga. Daarom dat ik het liefst zelf controle wil over mijn account.

[3ssen]

@Tallguy ik heb het bij mijn eigen systeem even getest. De url die je geeft werkt bij mijn eigen gegevens (siteID en apikey). Als ik echter van de apikey 1 teken verander, dan krijg ik een 403 als resultaat.

Lijkt mij dan dat ze je een verkeerde key gegeven hebben.

[Tallguy]

@3ssen Dat vermoed ik ook (vooral gezien het verleden dat ik met hun heb dat bol staat van foutjes). Maar ze reageren nog steeds niet...daarom dat ik compleet onafhankelijk wil zijn van hun en zelf een account bij SE wil voor mijn omvormer. Dat is ook de reden van mijn vraag: kan dat?

[andrerij]

@Tallguy Ik heb ook geprobeerd om de rechten van admin te krijgen, maar dit is alleen voorbehouden aan installateurs. SolarEdge zegt al een jaar dat ze bezig zijn om op een andere manier een aantal functies beschikbaar te stellen. Tot op heden is dit nog steeds niet gebeurd.

[Aegle]

In 2014 heb ik zelf de materialen ingekocht. Dus ook de SE3000 omvormer en optimizers. Ik kreeg toendertijd zonder problemen de "installateur"-rechten. Voor de duidelijkheid: ik ben géén PV-installateur .

Een e-mail of telefoontje naar SE Nederland kan natuurlijk geen kwaad. Nee heb je, ja kun je krijgen. Hoewel ik verwacht dat ze je terugverwijzen naar je installateur...

[Tallguy]

Ik heb SE gisteren al gemailed omdat de isntallateur (tot nu toe) nog steeds niet reageert Gevraagd aan SE of zij mij die rechten kunnen geven zonder dat ik 'installateur' wordt. Beetje van de zotte dat ik als eigenaar van het aparaat, niet de opties heb om zelf naar de API te kunnen om te controleren.

[david_p]

@Jerrythafast Bedankt voor dit mooie topic!

Gisteren heb ik een Pi 3 geïnstalleerd en deze geeft nu netjes data door aan pvoutput. Het kan zijn dat ik het uitwisselen van de key gemist heb omdat de omvormer (solarEdge 3000) laatst al even aan is geweest voordat ik de Pi had draaien.
In https://pvoutput.org/intr...335&sid=54605&dt=20170927 zie ik wel al data binnen komen. Is het zo dat loggen naar pvoutput wél mogelijk is als je geen key hebt weten te onderscheppen?

[MDKlapwijk]

david_p schreef op woensdag 27 september 2017 @ 11:33:
@Jerrythafast Bedankt voor dit mooie topic!

Gisteren heb ik een Pi 3 geïnstalleerd en deze geeft nu netjes data door aan pvoutput. Het kan zijn dat ik het uitwisselen van de key gemist heb omdat de omvormer (solarEdge 3000) laatst al even aan is geweest voordat ik de Pi had draaien.
In https://pvoutput.org/intr...335&sid=54605&dt=20170927 zie ik wel al data binnen komen. Is het zo dat loggen naar pvoutput wél mogelijk is als je geen key hebt weten te onderscheppen?

Dan is de key waarschijnlijk nog niet uitgewisseld. Deze zou vanzelf moeten verschijnen in de pcap files, daarna zal er waarschijnlijk ook geen data meer in pvoutput verschijnen, omdat de communicatie dan wel versleuteld is....

[david_p]

MDKlapwijk schreef op woensdag 27 september 2017 @ 12:04:
[...]

Dan is de key waarschijnlijk nog niet uitgewisseld. Deze zou vanzelf moeten verschijnen in de pcap files, daarna zal er waarschijnlijk ook geen data meer in pvoutput verschijnen, omdat de communicatie dan wel versleuteld is....

Het lijkt er op dat het verkeer van de SolarEdge niet naar buiten toe gestuurd wordt. De pcap files worden wel gevuld en pvoutput dus ook. Hoe kan ik controleren of er wel data naar de SolarEdge server gaat?

[MDKlapwijk]

@david_p, als de pcap files gevuld raken, dan is er toch verkeer vanaf de omvormer naar SolarEdge? Je luistert het verkeer immers af toch?

[Aegle]

@david_p: Zie je in de SE portal wel je data? Dan is er uiteraard communicatie met SE. Maar anders zou je lege .pcaps hebben...

Het is een vraag- en antwoord spelletje wat de portal speelt met de omvormer. Een deel van die communicatie wordt gelogd. Zie ook het starttopic hier.

[ Voor 8% gewijzigd door Aegle op 28-09-2017 12:48 ]

[david_p]

MDKlapwijk schreef op donderdag 28 september 2017 @ 11:40:
@david_p, als de pcap files gevuld raken, dan is er toch verkeer vanaf de omvormer naar SolarEdge? Je luistert het verkeer immers af toch?

Het komt wel langs in de Raspberry Pi ja, maar ik vroeg me af of het misschien niet de buitenwereld bereikt. Maar dat kan ik natuurlijk testen door een ander device aan de Lan poort van de Pi te verbinden.

Update:
@MDKlapwijk : Het werkt! De key is zojuist gevonden in één van de pcap files. Heel tof dat het allemaal werkt :-)

[ Voor 12% gewijzigd door david_p op 28-09-2017 22:52 ]

[david_p]

Aegle schreef op donderdag 28 september 2017 @ 12:47:
@david_p: Zie je in de SE portal wel je data? Dan is er uiteraard communicatie met SE. Maar anders zou je lege .pcaps hebben...

Ik heb nog geen toegang tot de SE portal. Althans, ik neem aan dat ik de gegevens daarvoor nog van de installateur ga krijgen.

[MDKlapwijk]

@david_p, je zou als het goed is van [e-mail] een mailtje moeten ontvangen met je login e.d. Maar die sturen ze je pas als je installateur je spul heeft aangemeld bij ze....

[MDKlapwijk]

En bij EnergieWonen zetten ze de rechten als volgt:

code:

User role: Dashboard & Layout
Site ownership: Granted

Ik mag dus zelf api-keys aanmaken etc.

[Rouske]

@MDKlapwijk kan je dan ook zelf je kWh tarief aanpassen met jouw rechten?

[No Hands]

MDKlapwijk schreef op woensdag 20 september 2017 @ 14:37:
@Jerrythafast bedankt hiervoor.

Gistermiddag is de SE6000H bij ons geplaatst.

Gisteravond het netwerk en de RPi met Domoticz aangepast, zodat deze op eth0 gevoed wordt met een Ubiquiti mirror port van de omvormer.

De se-logger gestart en vanochtend de key uit de pcap's gehaald, de data ingelezen en pvoutput.org ingesteld.

Waarop is dit afgezekerd? Want die SE6000H is enkel fase toch?

[MDKlapwijk]

Rouske schreef op donderdag 28 september 2017 @ 18:05:
@MDKlapwijk kan je dan ook zelf je kWh tarief aanpassen met jouw rechten?

Ja, ik heb 'm gewoon naar de 2 tariefgroepen kunnen aanpassen (of toe kunnen voegen en de oude weggehaald). Je geeft dan ook op vanaf wanneer dat die tarieven in zijn gegaan...

No Hands schreef op donderdag 28 september 2017 @ 19:13:
[...]


Waarop is dit afgezekerd? Want die SE6000H is enkel fase toch?

De woning op 1x 35A, de automaat die in de kast bijgeplaatst is een Emat EA16-32 (aardlek + 30A?)...

[Rouske]

Rouske schreef op woensdag 20 september 2017 @ 22:38:
Ik heb nog een oude foto gevonden van 1 juni nadat de omvormer uit was gegaan.
Year staat daar op 1006 kWh en Total op 1005 kWh.
Huidige stand Year is 2768 en Total 2790.
Ik ga SolarEdge wel even mailen of zij een verklaring hebben.

Solaredge is met een verklaring gekomen en heeft het gecorrigeerd op de omvormer .
Er is waarschijnlijk ooit een AC reset uitgevoerd waardoor de dagwaarde van die dag niet meer is meegenomen in de tellerstand op de omvormer.
De data is dan wel al verzonden naar onze server waardoor ik deze correctie kan uitvoeren.

En nu bedenk ik me dat er op 27 Augustus wel een stroomstoring was rond 22:00 en die dag staat met 22,270kWh in PVOutput.
Blijft wel apart dat als die teller gedurende de dag oploopt en dat het dan bij een stroomstoring in ene weer er vanaf is.

[ocaj]

Beetje vreemd misschien, maar de optimizers doen dat ook regelmatig. Als het ineens op een regenachtige/grijze dag zo donker wordt dat je binnen je lichten aan moet doen, dan begint daarna vaak de dagteller per optimizer ook weer op 0.
De omvormer zie ik zoiets eigenlijk zelden of nooit doen, maar na een stroomstoring begint de omvormer inderdaad ook weer bij 0.

Als je dat eenmaal weet is het een kwestie van een beetje slim de dagtotalen uitrekenen en de verschillende dagtotalen voor en na de reset bij elkaar optellen.

[Rouske]

Een dagteller die weer op 0 begint na een stroomstoring, ok dat kan, maar om de jaarteller dan ook terug te zetten.. Wie dat bedacht heeft
PVOutput geeft het in ieder geval goed weer, alleen het display van de omvormer zelf dan niet meer en dat is alleen door SE te corrigeren.
Ik wou dat de kWh meter van de netbeheerder ook zo werkte, dan graag aan het eind van elke dag een stroomstoring...

[ Voor 56% gewijzigd door Rouske op 04-10-2017 09:27 ]

[Jerrythafast]

Dat de dagteller bij een stroomstoring (of gewoon wanneer je de omvormer uit en weer aan zet) opnieuw begint kan ik beamen. De jaarteller is hier in ieder geval nog nooit zomaar gereset.

Ik heb hier trouwens na ruim 1,5 jaar afgelopen weekend de eerste Raspberry Pi crash doorgemaakt. Hij bootte niet meer, vermoedelijk doordat de boot partitie van de SD-kaart corrupt was geraakt (data was gelukkig nog gewoon uit te lezen op de laptop), dus heb hem nu opnieuw geïnstalleerd op een degelijker exemplaar. Hoop dat hij het nu weer een paar jaar volhoudt. Er zat na de herinstallatie blijkbaar nog iets mis in de configuratie waardoor de Pi dinsdagochtend compleet vast was gelopen. De data van SolarEdge is er nog tot een uur of 1 in de middag doorheen gekomen, maar de 'tee' naar het pcap bestand was blijkbaar al eerder gestopt. Ik heb nu voor het eerst sinds de plaatsing van de zonnepanelen een ochtend waarvan ik de SE data niet in een pcap file heb kunnen vangen...

[ Voor 3% gewijzigd door Jerrythafast op 06-10-2017 22:41 ]

[MDKlapwijk]

Jerrythafast schreef op vrijdag 6 oktober 2017 @ 22:40:
Dat de dagteller bij een stroomstoring (of gewoon wanneer je de omvormer uit en weer aan zet) opnieuw begint kan ik beamen. De jaarteller is hier in ieder geval nog nooit zomaar gereset.

Ik heb hier trouwens na ruim 1,5 jaar afgelopen weekend de eerste Raspberry Pi crash doorgemaakt. Hij bootte niet meer, vermoedelijk doordat de boot partitie van de SD-kaart corrupt was geraakt (data was gelukkig nog gewoon uit te lezen op de laptop), dus heb hem nu opnieuw geïnstalleerd op een degelijker exemplaar. Hoop dat hij het nu weer een paar jaar volhoudt. Er zat na de herinstallatie blijkbaar nog iets mis in de configuratie waardoor de Pi dinsdagochtend compleet vast was gelopen. De data van SolarEdge is er nog tot een uur of 1 in de middag doorheen gekomen, maar de 'tee' naar het pcap bestand was blijkbaar al eerder gestopt. Ik heb nu voor het eerst sinds de plaatsing van de zonnepanelen een ochtend waarvan ik de SE data niet in een pcap file heb kunnen vangen...

Vervang ook gelijk je voeding van je RPi, slechte voeding is funest voor bestanden op het sd-kaartje...

Ik gebruik zelf op de bedrijfskritische RPi's een UPS PIco om er zeker van te zijn dat er geen corruptie optreedt:
- http://pimodules.com/_pdf/_pico/UPS_PIco_BL_FSSD_V1.0.pdf

[Aegle]

Da's zonde... . Is het geen optie om de toepassing geheel op een externe HD te draaien? Het is genoegzaam bekend dat SD-kaartjes maar beperkt R/W acties aan kunnen. USB-sticks schijnen ook niet zo goed bestand tegen voortdurende lees en schrijf acties. Tot nu toe draait het hier zonder problemen.
/me Aegle klopt op blank hout.
In het Domoticz topic is daar een aantal keer op gewezen.

[ocaj]

Ik gebruik een externe database-server op mijn NAS, dat scheelt al heel veel qua schrijfacties.
Verder schrijf ik alle live-waardes (niet alleen SE, maar ook nog kwh-meters en 1-wire thermometers...) alleen naar een RAM-disk. Scheelt ook al een heleboel.
Binary logfiles met SE-data schrijf ik wel gelijk naar SD-kaartje, maar andere logfiles schrijf ik ook naar RAM-disk en net na middernacht kopieer ik die gezipt naar sd-kaartje.

Ik heb geen idee in welke mate linux en sd-kaartjes aan wear-leveling doen, maar voor de zekerheid heb ik een Kingston 16GB-kaartje in gebruik.

Allemaal dingen die een beetje zouden moeten helpen. Ben benieuwd hoe lang ik het daarmee volhoud.

Dingen vallen natuurlijk nooit uit op een handig moment. Je zou natuurlijk preventief het sd-kaartje kunnen vervangen, maar ja, met welk interval doe je dat....

[Verwijderd]

Is het ook mogelijk inplaats van RPI een andriod tv box tegebruiken?

[Jerrythafast]

@Verwijderd als je daar de benodigde scripts op kunt draaien en ervoor kunt zorgen dat die box de communicatie van de omvormer te zien krijgt op z'n netwerkpoort zou dat moeten kunnen ja.

[MDKlapwijk]

@Aegle, als je de gebruikelijke zaken als no-atime, logs naar tmpfs, etc. doet valt het allemaal wel mee:

code:

root@domoticz-01:~# cat /etc/fstab
proc            /proc      proc defaults 0 0
/dev/mmcblk0p1  /boot      vfat defaults,noatime 0 2
/dev/mmcblk0p2  /          ext4 defaults,noatime 0 1
tmpfs           /tmp       tmpfs defaults,noatime,nosuid,size=100m 0 0
#tmpfs           /var/log   tmpfs defaults,noatime,nosuid,mode=0755,size=100m 0 0

Een slechte voeding zorgt veel eerder voor corrupte files, zelfs tijdens lezen, dus ook in kernel files e.d. Waarna de meuk dus helemaal niet meer opstart. Ik verdacht eerst ook m'n Kingston kaartjes van slijtage, maar bleek dus voeding te zijn...

En externe backups kunnen nooit kwaad!

[Verwijderd]

Was het iemand al een keer gelukt om op een SolarEdge HD wave SE3000h via RS485 de encryptie key uit te lezen?

Ik had al een USB -- RS485 kabel besteld, en een keer geprobeerd met het Python script van jbuehl de key uit te lezen, maar er komt geen enkele uitvoer uit het eerste deel van het command:

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

[Jerrythafast]

@Verwijderd Ene oliv3r hier is het schijnbaar gelukt met een SE5000H. (Even een fool-proof-check voor de zekerheid: heb je in jouw commando '-s 7f101234' veranderd in het serienummer van jouw eigen omvormer?)

Als alternatief kun je het ook nog proberen met het 'get-key-by-rs232.py' script (zie Paragraaf 6.2 van de startpost van dit topic). Dat script maakt het verder niet uit als je eigenlijk via RS485 bent verbonden.

[Verwijderd]

Bedankt voor de suggestie, ik was inderdaad vergeten om het serienummer aan te passen. Ik heb nu verder ook -t 4 ipv -t 2 gebruikt, en met of zonder -m (master), maar tot zover nog geen geluk. Ik weet ook niet of het uitmaakt of de omvormer in night mode staat of niet.

Wat ik nu zie is dat het script oneindig lang blijft wachten op input.

Ik geef het voor nu even op wegens gebrek aan tijd, ik klooi nog wel een keer verder.

[Aegle]

vanmorgen is de RPi met de logging software gecrasht . Blijkt dat de USB-drive, waarop ik de pcap-files wegschreef, het heeft begeven. Door onduidelijke oorzaak is hierdoor de koppeling met het LAN verbroken. Vanaf het werk adres repareren ging wat lastig .

vanavond de USB verwijderd en in fstab de USB uitgecomment. Hij draait weer, maar helaas mis ik nu het grootste deel van de dag.

Gebruik ik expres een externe drive als 1e back-up om de SD-kaart te ontlasten, begeeft de USB drive het!
gelukkig heb ik alle data ook gekopieerd in de cloud.

Toch eens nadenken over een wat duurzamere oplossing...