[SolarEdge] Omvormers en optimizers zelf monitoren

[Bombtrack]

Kleine update over modbus support voor mijn solarEdge omvormer:

Ik heb contact gehad met de installateur. Die heeft ondertusen de firmware geupdate.
De solaredge modbus plugin in HA ontving direct daarna zn eerste data over wifi.
Kortom: Modbus support over wifi bestaat weldegelijk nog steeds, maar is sommige oudere firmware versies inderdaad uitgezet/kapot gemaakt zoals @ZwarteIJsvogel al schreef. De nieuwste firmware heeft dit probleem opgelost zonder kabels te hoeven trekken etc.

[LPieter]

Bombtrack schreef op woensdag 27 september 2023 @ 13:53:
Kleine update over modbus support voor mijn solarEdge omvormer:

Ik heb contact gehad met de installateur. Die heeft ondertusen de firmware geupdate.
De solaredge modbus plugin in HA ontving direct daarna zn eerste data over wifi.
Kortom: Modbus support over wifi bestaat weldegelijk nog steeds, maar is sommige oudere firmware versies inderdaad uitgezet/kapot gemaakt zoals @ZwarteIJsvogel al schreef. De nieuwste firmware heeft dit probleem opgelost zonder kabels te hoeven trekken etc.

Begrijp ik het goed dat je nu echt modbus-over-tcp via wifi werkend hebt, ongeacht wat de rest van het internet beweert? Ditzelfde probeer ik sinds dit weekend voor elkaar te krijgen, dus dat zou geweldig zijn (draad is geen optie helaas). Welke firmware heb je hiervoor geïnstalleerd?

[eriksl]

Kunnen jullie anders niet (via een omweg) bedraad aansluiten?

[Bombtrack]

LPieter schreef op woensdag 27 september 2023 @ 15:19:
[...]


Begrijp ik het goed dat je nu echt modbus-over-tcp via wifi werkend hebt, ongeacht wat de rest van het internet beweert? Ditzelfde probeer ik sinds dit weekend voor elkaar te krijgen, dus dat zou geweldig zijn (draad is geen optie helaas). Welke firmware heb je hiervoor geïnstalleerd?

Correct. Ik ben nu niet thuis dus kan de exacte firmware even niet opzoeken, maar dit inderdaad het geval. Modbus over tcp via wifi. Een simpele firmware update en direct werkte alles zoals ik het in eerste instantie verwachtte. Heeft me behoorlijk wat koppijn bezorgd

[eriksl]

Ik zag toevallig, toen ik eergisteren de SetAPP weer eens aansloot dat er een firmware update was (voor de CPU en de DSP1). Dus wie weet...

[ZwarteIJsvogel]

Bombtrack schreef op woensdag 27 september 2023 @ 13:53:
Kortom: Modbus support over wifi bestaat weldegelijk nog steeds, maar is sommige oudere firmware versies inderdaad uitgezet/kapot gemaakt

Voor firmware 4.14 werkte het toevallig (unsupported feature). Uit deze post op github:

Support answered that Modbus interface shouldn't work via Wifi from the beginning and in the newest version they "repaired" that.

Die 'reparatie' zat in versie 4.14. Daar zal ongetwijfeld flink wat kritiek op zijn gekomen. Nu is het een supported feature. Uit deze post (die citeert uit SolarEdge release notes):

Modbus TCP over secured Wi-Fi is now officially supported for residential inverters:

• Modbus TCP over unsecured Wi-Fi is blocked
• Modbus TCP over Wi-Fi for commercial inverters is blocked
• Note: Modbus TCP over Ethernet and Modbus TCP over RS485 for all inverters are supported

De firmware versie staat er zoals zo vaak helaas niet bij, maar gezien de datum moet dat 4.16 zijn geweest. Gezien de restricties heeft SolarEdge dit met frisse tegenzin gedaan. Residential inverters zijn voor zover ik weet de kleinere modellen (t/m 10 kW).

LPieter schreef op woensdag 27 september 2023 @ 15:19:
Begrijp ik het goed dat je nu echt modbus-over-tcp via wifi werkend hebt, ongeacht wat de rest van het internet beweert?

Er wordt veel beweerd op internet. Door het ontbreken van details als firmware versie en/of model omvormer gaan die beweringen in dit geval feitelijk nergens over. En er wordt uiteraard veel blind nageblaat.

[eriksl]

Laatste firmware is nu:

CPU 4.18.32
DSP1 1.100.1515
DSP2 2.100.1302

[eriksl]

Even voor mijn beeld, zijn er hier mensen die hun SolarEdge (optimiser data) uitlezen via RS485?

Ik heb namelijk het gevoel dat met de huidige firmware, ook dat zo goed als onmogelijk is gemaakt. Ik krijg nu elke 1.5 uur één record binnen (terwijl het eerder best goed werkte).

Om toch een beetje overzicht te krijgen in welk kant van het dak welk aandeel heeft elk moment van de dag ben ik nu maar een statische berekening aan het bedenken. Ben er intussen achter dat het moment dat de zon op z'n hoogst staat altijd hetzelfde is (minus zomer/wintertijd). Ik heb van een dag dat het 100% zonnig was de data van de optimisers voor- en achter en ben daarmee nu een benaderingsfunctie aan het maken. Dat loslaten op de totale opbrengst en je hebt vrij goed de verdeling over voor/achter.

[ramonp]

Ik heb se-logger (0.0.17) zonder problemen draaien op een raspberry pi 3 (debian 11).

Nu wil ik se-logger gaan draaien op een nuc (ook debian 11).

Alleen krijg ik op de nuc onderstaande melding in de tcpdump.log

code:

ERROR: ld.so: object '/usr/libexec/coreutils/libstdbuf.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
tcpdump: listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

Dit wordt veroorzaakt door onderstaande stukje code in se-logger-service.sh:

code:

/usr/bin/stdbuf -i0 -o0 -e0 /usr/bin/tcpdump

Al via Google iets proberen te vinden, maar helaas niet de oplossing kunnen vinden.

Iemand enig idee?

[Bombtrack]

Bombtrack schreef op woensdag 27 september 2023 @ 13:53:
Kleine update over modbus support voor mijn solarEdge omvormer:

Ik heb contact gehad met de installateur. Die heeft ondertusen de firmware geupdate.
De solaredge modbus plugin in HA ontving direct daarna zn eerste data over wifi.
Kortom: Modbus support over wifi bestaat weldegelijk nog steeds, maar is sommige oudere firmware versies inderdaad uitgezet/kapot gemaakt zoals @ZwarteIJsvogel al schreef. De nieuwste firmware heeft dit probleem opgelost zonder kabels te hoeven trekken etc.

Tijdje geleden alweer, maar voor de geintereseerdde:
Firmware is nu
Cpu 4.18.32
DSP1 1.0.1709
DSP2 2.01305
WSA 4.18.61

[eriksl]

ramonp schreef op dinsdag 17 oktober 2023 @ 12:39:
Ik heb se-logger (0.0.17) zonder problemen draaien op een raspberry pi 3 (debian 11).

Nu wil ik se-logger gaan draaien op een nuc (ook debian 11).

Alleen krijg ik op de nuc onderstaande melding in de tcpdump.log

code:

ERROR: ld.so: object '/usr/libexec/coreutils/libstdbuf.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
tcpdump: listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

Dit wordt veroorzaakt door onderstaande stukje code in se-logger-service.sh:

code:

/usr/bin/stdbuf -i0 -o0 -e0 /usr/bin/tcpdump

Al via Google iets proberen te vinden, maar helaas niet de oplossing kunnen vinden.

Iemand enig idee?

Kennelijk mist een deel van het stdbuf package (die bestaat uit een executable en een library, die laatste mist kennelijk). Lijkt me geen probleem, gewoon het stukje weglaten wat het probleem oplevert en dan krijg je:
/usr/bin/tcpdump
het enige nadeel is dat je dan niet altijd realtime output krijgt, kan wat vertraging in zitten.

[ZwarteIJsvogel]

eriksl schreef op maandag 6 november 2023 @ 19:49:
[...]

Kennelijk mist een deel van het stdbuf package (die bestaat uit een executable en een library, die laatste mist kennelijk).

De library (/usr/libexec/coreutils/libstdbuf.so) is er gewoon en is ook voor iedereen leesbaar (mode 644). Maar als ld.so de library probeert te openen, faalt de openat() call met EACCES (permission denied). Bij andere programma's als tcpdump (bv. /bin/ls) komt de foutmelding niet. Zeer merkwaardig.

Lijkt me geen probleem, gewoon het stukje weglaten wat het probleem oplevert en dan krijg je:
/usr/bin/tcpdump
het enige nadeel is dat je dan niet altijd realtime output krijgt, kan wat vertraging in zitten.

se-logger-service.sh start tcpdump met de -U optie zodat de output buffer na elk packet wordt geflusht. Ik zie eerlijk gezegd niet wat dan nog de functie van stdbuf is.

[LPieter]

Intussen heb ik Modbus support over wifi ook werkend zonder ooit een kabel te gebruiken (palletje kort naar P, verbinding met wifi-punt maken en vervolgens via http://172.16.0.1 > Site Communication, aanzetten). Gegevens begonnen direct binnen te komen.

CPU: 4.18.32
DSP1: 1.20.1533
DSP2: 2.20.1200
WSA: 4.18.61

[ Voor 11% gewijzigd door LPieter op 06-12-2023 13:16 ]

[ProudElm]

Klopt, dat werkt zeer goed. Zou nog mooier zijn als ook de optimizer data via de modbus uitgelezen kon worden maar helaas.

[ZwarteIJsvogel]

Ik heb gisteren mijn SE4000H voorzien van firmware 4.19.36, maar helaas: nog steeds geen optimizer data via Modbus. En dat terwijl daarvoor al voorzieningen zaten in firmware 4.6.x (augustus/september 2019). Ik denk dat ze bij SolarEdge de handen vol hebben aan zaken die commercieel van belang zijn.

[Jan-JaapK]

Hey,

Vandaag is bij mij de installatie van een Solaredge afgerond. Op basis van dit forum installateur gevraagd Modbus communicatie te activeren. Werkt gelijk als een zonnetje (ik lees deze middels een Python plugin in Domoticz uit). De installateur was ook zo vriendelijk om de documentatie van Solaredge mee te sturen. Deze logging itnerface voldoet aan de zogenaamde SunSpec Alliance specificatie (https://sunspec.org/specifications/#tabs|1).

Voor zover ik deze spec begrijp, wordt er inderdaad geen info over de individuele optimisers vrijgegeven (ondanks dat de Solaredge monitoring deze wel weergeeft....).

Mocht iemand interesse hebben, ik heb hier dus een pdf'je......

[ZwarteIJsvogel]

Het SunSpec document kun je gewoon downloaden in het SolarEdge Knowledge Center. Je moet wel even aanvinken dat je ook Engelstalige documenten wilt vinden. Ik geef hier geen rechtstreekse link omdat de titel van het document nogal eens verandert (en daarmee de link).

In tegenstelling tot wat het document zegt, werkt Modbus/TCP voor residentiële omvormers ook via WiFi (sinds CPU firmware 4.16). Ook de opmerkingen over een 2 minuten idle time zijn al lang niet meer van toepassing.

Nog een kleine waarschuwing. SolarEdge gebruikt in het document vaste registernummers, maar je ziet al bij de Synergy units dat ze zich daarvoor in wat bochten moeten wringen. Er is ook geen 100% garantie dat registernummers in een volgende software release niet veranderen (al zal dat voor het Inverter model vermoedelijk niet zo'n vaart lopen).

De enige correcte manier om modellen en registernummers te bepalen is door enumeratie van de gepresenteerde SunSpec modellen (zoals de SunSpec Alliance ook voorschrijft). Dan kom je er ook achter dat er veel meer modellen zijn dan het document beschrijft.

SolarEdge maakt prima spul, maar de kwaliteit van de documentatie komt helaas niet in de buurt.

Edit:

Jan-JaapK schreef op vrijdag 9 februari 2024 @ 18:00:
De installateur was ook zo vriendelijk om de documentatie van Solaredge mee te sturen.

Daarvoor verdient je installateur een pluim. Het is altijd fijn om te lezen dat er nog leveranciers zijn die verder kijken dan hun factuur lang is.

[ Voor 12% gewijzigd door ZwarteIJsvogel op 11-02-2024 14:14 ]

[eriksl]

ZwarteIJsvogel schreef op woensdag 8 november 2023 @ 14:05:
De library (/usr/libexec/coreutils/libstdbuf.so) is er gewoon en is ook voor iedereen leesbaar (mode 644). Maar als ld.so de library probeert te openen, faalt de openat() call met EACCES (permission denied). Bij andere programma's als tcpdump (bv. /bin/ls) komt de foutmelding niet. Zeer merkwaardig.

Ik weet niet of het nog relevant is, mijn $0.02: het kan zijn dat ld.so niet zoekt op deze locatie. Kijk even de file /etc/ld.so.conf en de directory /etc/ld.so.conf.d na. Dit kan ook het gevolg zijn van een executable met een s-bitje draaien met een library file die op een niet-vertrouwde locatie staat. Deze route was vroeger heel leuk om het systeem te hacken, mag dus al heel lang niet meer

[eriksl]

ProudElm schreef op woensdag 6 december 2023 @ 13:10:
Klopt, dat werkt zeer goed. Zou nog mooier zijn als ook de optimizer data via de modbus uitgelezen kon worden maar helaas.

Het grappige is dat er wel flinke blokken met (onbekende) registers uitgelezen kunnen worden. Ik heb voor de grap eens een paar keer die blokken helemaal uitgelezen en naast elkaar gelegd. Je ziet dan inderdaad wel verschillen, het is dus geen constante data, dat geeft hoop. Alleen, ook als het systeem standby was ('s-nachts) zaten er net zoveel verschillen in, dus dat suggereert dan weer dat er geen optimizer data in zit (maar dat weten we dus niet zeker). Als iemand het leuk vindt om hierover eens de koppen bij elkaar te steken dan houd ik me aanbevolen.

[eriksl]

ZwarteIJsvogel schreef op donderdag 7 december 2023 @ 19:42:
Ik heb gisteren mijn SE4000H voorzien van firmware 4.19.36, maar helaas: nog steeds geen optimizer data via Modbus. En dat terwijl daarvoor al voorzieningen zaten in firmware 4.6.x (augustus/september 2019). Ik denk dat ze bij SolarEdge de handen vol hebben aan zaken die commercieel van belang zijn.

Vertel, waar en hoe is dat gemeld?

Ik krijg namelijk heel sterk de indruk dat SE er alles aan doet om juist te voorkomen dat consumenten optimizer data in handen krijgen:
- communicatie met hun servers wordt steeds verder dichtgetimmerd, nu ook met een client certificaat, wat voor de beveiliging t.o.v. internet niet nodig is, dat is alleen "nodig" om gebruik van onze proxies te voorkomen.
- ook het protocol via de RS485 wordt steeds verder dichtgetimmerd. Er komen tegenwoordig allemaal onbekende packets langs (wel volgens het protocol en inclusief correcte checksums, dus geen garbage). Als je daar niet op tijd op de juiste manier op reageert, dan stopt de stroom met optimizer data. Dus ook dat klinkt als een maatregel om meekijken te voorkomen.

Maar ik hoor graag dat het anders is

[eriksl]

Jan-JaapK schreef op vrijdag 9 februari 2024 @ 18:00:
Hey,

Vandaag is bij mij de installatie van een Solaredge afgerond. Op basis van dit forum installateur gevraagd Modbus communicatie te activeren. Werkt gelijk als een zonnetje (ik lees deze middels een Python plugin in Domoticz uit). De installateur was ook zo vriendelijk om de documentatie van Solaredge mee te sturen. Deze logging itnerface voldoet aan de zogenaamde SunSpec Alliance specificatie (https://sunspec.org/specifications/#tabs|1).

Voor zover ik deze spec begrijp, wordt er inderdaad geen info over de individuele optimisers vrijgegeven (ondanks dat de Solaredge monitoring deze wel weergeeft....).

Mocht iemand interesse hebben, ik heb hier dus een pdf'je......

Aanzetten van modbus is echt een karweitje van niks, daar heb je echt geen installateur voor nodig App opstarten, naar de instellingen gaan en dan TCP ModBus aanzetten. Je kunt ook nog kiezen welke poort gebruikt wordt.

Interessant detail, als je bij de RS485 master/slave instellingen het device id van 0 (default) verandert naar 1, dan wordt je modbus id ook opeens "1". En als je er wat anders in zet, dan werkt het helemaal niet meer. Bugje of logisch?

De SolarEdge monitoring (cloud) werkt met een ander (proprietary) protocol, zelfde protocol als op de RS485 bus gebruikt wordt. Staat hier dus helemaal los van. Daar zit de optimizer data wél in.

[eriksl]

ZwarteIJsvogel schreef op zondag 11 februari 2024 @ 09:57:
Het SunSpec document kun je gewoon downloaden in het SolarEdge Knowledge Center. Je moet wel even aanvinken dat je ook Engelstalige documenten wilt vinden. Ik geef hier geen rechtstreekse link omdat de titel van het document nogal eens verandert (en daarmee de link).

Volgens mij zijn er overigens geen SunSpec registers voor optimizers. Je kunt zoeken tot je een ons weegt . Als SE optimizer dat via modbus implementeert, dan zal dat via proprietary registers zijn (en die staan uiteraard niet in de SunSpec documentatie).

Voor de algemene gegevens hoef je niet moeilijk te doen, daarvoor zijn diverse programmaatjes op internet te vinden, specifiek voor SE.

[ZwarteIJsvogel]

eriksl schreef op vrijdag 8 maart 2024 @ 09:44:
[...]

Vertel, waar en hoe is dat gemeld?

Nergens. Ik heb ooit in het programma dat de omvormer bestuurt text symbols gevonden in de dynamic symbol table die wijzen op ondersteuning voor SunSpec informatie per paneel. Ik ga er van uit dat dit er nog steeds in zit.

Ik krijg namelijk heel sterk de indruk dat SE er alles aan doet om juist te voorkomen dat consumenten optimizer data in handen krijgen:
- communicatie met hun servers wordt steeds verder dichtgetimmerd, nu ook met een client certificaat, wat voor de beveiliging t.o.v. internet niet nodig is, dat is alleen "nodig" om gebruik van onze proxies te voorkomen.
- ook het protocol via de RS485 wordt steeds verder dichtgetimmerd. Er komen tegenwoordig allemaal onbekende packets langs (wel volgens het protocol en inclusief correcte checksums, dus geen garbage). Als je daar niet op tijd op de juiste manier op reageert, dan stopt de stroom met optimizer data. Dus ook dat klinkt als een maatregel om meekijken te voorkomen.

Maar ik hoor graag dat het anders is

Ik geloof niet dat ze bewust proberen de optimizer data uit handen van hun klanten te houden. Optimizer data beschikbaar maken via Modbus heeft gewoon geen prioriteit (die data is maar voor weinigen relevant). Ik heb SolarEdge er een paar jaar geleden eens naar gevraagd, maar nooit antwoord gekregen.

SolarEdge timmert zijn producten en infrastructuur gewoon verder dicht. Met die client certificaten wordt bv. voorkomen dat een hacker zich eenvoudig als omvormer kan voordoen om het monitoring platform aan te vallen. Als je het monitoring platform weet te hacken, kun je allerlei lelijke dingen doen met aangesloten omvormers (bv. om het elektriciteitsnet van een land te destabiliseren).

Als klant ben ik blij met de inspanningen van SolarEdge om de veiligheid te vergroten, als Tweaker wat minder.

[ZwarteIJsvogel]

eriksl schreef op vrijdag 8 maart 2024 @ 09:53:
[...]

Volgens mij zijn er overigens geen SunSpec registers voor optimizers. Je kunt zoeken tot je een ons weegt . Als SE optimizer dat via modbus implementeert, dan zal dat via proprietary registers zijn (en die staan uiteraard niet in de SunSpec documentatie).

Voor de algemene gegevens hoef je niet moeilijk te doen, daarvoor zijn diverse programmaatjes op internet te vinden, specifiek voor SE.

SunSpec data per optimizer/paneel is er helaas nog steeds niet. Ik heb ook in de overige Modbus registers nooit enige data per optimizer/paneel kunnen vinden. Jammer.

[eriksl]

De combinatie van:
- client certificaat
- dichttimmeren van het protocol op RS485 zonder noodzaak
suggereert toch wel dat ze de optimizer data voor zichzelf willen houden.

Stats hacken is nou niet echt heel interessant voor hackers, ik geloof ook niet dat het ooit is gebeurd.

Zelfs zonder officiele SunSpec specificatie zou deze data vrij eenvoudig beschikbaar gesteld kunnen worden. Dat doen ze kennelijk al met heel veel (ongedocumenteerde) registers.

Voor de goede orde, ik vind SolarEdge een stuk sympathieker dan bijvoorbeeld GroWatt, maar laten we wel realistisch zijn, ze blijven een bedrijf met eigen belangen, die niet altijd overeenkomen met onze belangen.

Ik heb net een nieuwe airco gekocht en daar zie je al hetzelfde. Spul wat in het verleden (lokaal) gewoon goed toegankelijk was, wordt nu dichtgetimmerd, zodat het via de cloud MOET. De Europese branch maakt zich nu sterk voor een API zodat je in ieder geval nog iets kunt, terwijl het moederbedrijf daar helemaal niet zo enthousiast over is. Ik denk dat er gewoon een of andere hoge pief zit die het allemaal beter weet zonder zich er echt in te verdiepen, net als bij SE. Dan zijn ze bijvoorbeeld bang dat ze allemaal support moeten gaan leveren daarop en/of dat het allemaal bugs blootlegt die anders niet gevonden zouden zijn. Zelfde verhaal toch met drivers van GPU's, dat moet ook allemaal "geheim" en gesloten terwijl er eigenlijk weinig raars aan is.

[ZwarteIJsvogel]

Die clouddwang is allerlei redenen meer dan zorgelijk. Je kunt proberen dit soort producten te mijden, maar dan word je er soms achteraf toch nog mee geconfronteerd (bv. Philips Hue)

[eriksl]

Ja, ik ben er ook helemaal niet blij mee, om diverse redenen.

Ik ben denk ik ook een van de weinige mensen in Nederland die geen enkele omvormer van zonnepanelen op het internet heeft zitten.

Zou fijn zijn als de EU met een wet komt die eist dat fabrikanten hun producten bruikbaar maken zonder cloud. Met een fatsoenlijke API die je lokaal kunt aanspreken. En dan niet het "bare minimum", maar alle functionaliteit die ook via de cloud beschikbaar is (minus verwerking en user interface, natuurlijk). In ons geval dus ook de data van de optimisers dus.

[mawashigeri]

eriksl schreef op vrijdag 8 maart 2024 @ 12:14:
Ja, ik ben er ook helemaal niet blij mee, om diverse redenen.

Ik ben denk ik ook een van de weinige mensen in Nederland die geen enkele omvormer van zonnepanelen op het internet heeft zitten.

Zou fijn zijn als de EU met een wet komt die eist dat fabrikanten hun producten bruikbaar maken zonder cloud. Met een fatsoenlijke API die je lokaal kunt aanspreken. En dan niet het "bare minimum", maar alle functionaliteit die ook via de cloud beschikbaar is (minus verwerking en user interface, natuurlijk). In ons geval dus ook de data van de optimisers dus.

Voor het dagelijkse overzicht is de generieke modbus informatie meer dan voldoende, maar als je netjes wil monitoren of alle panelen wel goed meedoen zou je de optimizer data toch zeker wel willen hebben.

Overigens kan je in de cloud nog extra informatie krijgen als je admin rechten hebt, die heb ik per abuis aangevraagd bij mijn installateur (ik dacht het nodig te hebben om modbus aan te zetten). Hier kan je analyses doen, alerts inzien en rapporten opvragen.

[eriksl]

Ik heb zelf "installateur"-rechten bij SolarEdge. Kleine moeite om aan te vragen.

Had ik al gezegd dat mijn inverters niet op internet zitten?

Wat ik wil is een grafiek waarin van elk paneel afzonderlijk de bijdrage wordt getoond. Vooral die aan de voorkant en de achterkant van het huis. Nu doe ik dat met een benadering, had liever de echte data gehad.

Het enige wat ík dus wil, is via modbus in real-time de stats van de optimisers kunnen opvragen, de rest kan me gestolen worden ;-)

Je kunt via de app overigens ook de optimisers opvragen, maar dat is dan niet real-time en automatisch natuurlijk.

[ Voor 5% gewijzigd door eriksl op 08-03-2024 14:41 ]

[ocaj]

@eriksl
Ik draai hier naar volle tevredenheid al sinds 2016 zonder internet.....

Als je je omvormers niet op het internet hebt zitten, dan kun je toch bijvoorbeeld via het script van jbuehl alle optimizer-data uitlezen via het SolarEdge-protocol? Inderdaad, het is niet real-time, en er komen - net als in de online-monitoring - maar eens in de paar minuten metingen binnen, maar je kunt wel gewoon per paneel/optimizer monitoren. En daarmee dus ook de opbrengst etc per dak inzichtelijk maken.

Aantal metingen per optimizer schommelt een beetje (geen idee wat een trigger is voor SolarEdge om nieuwe data te loggen). Gisteren over de hele dag ca 105-120 metingen per optimizer. 's Zomers meer uren zon, dus ook meer metingen, dan ca 135-170. Geeft op zich een prima beeld hoor.
Het is dus niet helemaal real-time, maar wel gewoon beschikbaar.

[eriksl]

Dat de gegevens van de optimizers niet helemaal real-time zijn weet ik. Het zal waarschijnlijk te maken hebben met dat de optimizers geen dataverbinding hebben met de inverter, waardoor ze de data moeten moduleren op de DC aansluiting en aangezien die serieel gelust wordt langs alle optimizers, kan ik me voorstellen dat daarvoor een heel lage snelheid gebruikt moet worden.

Dat is niet het probleem.

Ik hoor al dat jij wat oudere inverter(s) hebt, dan heb je geluk! Op de nieuwere converters (die van mij is van 2023) zijn allemaal maatregelen genomen om te voorkomen dat je zelf die data uitleest. En geloof me, daar helpt jbuehl z'n scriptje ook niet tegen Zie ook hier, waarin hij dat zelf aangeeft: https://github.com/jbuehl/solaredge/blob/master/README.md

Zelf server spelen werkte al langer niet meer omdat de client nu een certificate verwacht.
De verbinding proxyen en dan meekijken werkt sinds vorig jaar ook niet meer omdat de server nu ook een client certificate eist.
Dus ik had me toegelegd op communicatie via RS485, wat nog steeds onversleuteld gaat. Met het script van jbuehl ging dat niet soepel, telkens na een tijdje stopte de relevante data records. Ik heb toen een eigen programma (in C) geschreven zodat ik makkelijk kon tweaken. Daarmee kreeg ik het een stuk beter aan de gang, maar na een dag-en-nacht is het nog steeds afgelopen, dan moet ik de interface resetten (via de app, dus dat is een heel gedoe), voordat er weer records komen.
Er komen redelijk veel records van een onbekend type langs (op internet ook niks over te vinden) en kennelijk moet je daar op de juist manier op reageren en anders gaat de kraan dicht. Het gaat om record type 0x3c2. Als iemand daar ook maar iets van weet houd ik me zeer aanbevolen!

[ocaj]

Die wijzigingen sinds september 2023 had ik inderdaad gemist. Maar gebruiken ze nu ook TLS over de RS485-verbinding? Dat zou wel vervelend/flauw zijn.....

Mijn omvormers zijn in 2021 vervangen door het HD-wave type zonder scherm (en helaas op de 400V-stringspanning ipv de voormalige 375), toen had ik wel even gedoe met het script van jbuehl, omdat er geen geldige json uit de default json-python-library komt (zie: https://github.com/jbuehl/solaredge/issues/166 ), maar sindsdien draait het hier prima.
Ik heb toen ook wel een hoop data gezien die ik niet herkende, maar als je die negeert is er niks aan de hand. Optimizer en omvormer-data komt er nog steeds succesvol uit bij mij (over de RS485-aansluiting).

Ik zit wel over uitbreiding van mijn set te denken, dat is dan tegen die tijd een aandachtspuntje omdat er voor de nieuwere optimizers mogelijk een firmware-update nodig is....

update: Overigens stop ik mijn script om 22:00 en start ik hem weer om 05:00. Dus mocht het ooit vastlopen dan komt het de volgende dag vanzelf weer goed.....

[ Voor 8% gewijzigd door ocaj op 09-03-2024 09:32 ]

[eriksl]

Het gaat niet om het script. De interface op de omvormer loopt vast, in die zin dat je alleen nog maar (veel) packets van één bepaald type krijgt (checksum is OK, dus is geen garbage). Dat zullen waarschijnlijk foutmeldingen zijn, maar er zit geen leesbare tekst in. En waarschijnlijk gaat hij pas verder op het moment dat je al die foutmeldingen hebt geacknowledged. Ik heb vanalles geprobeerd, maar niks werkt. Pas als je, via de app, de interface uitzet en weer aan gaat het weer werken. Dat aantal van die onbekende packets loopt heel langzaam op en op een gegeven moment worden dat er meer dan een stuk of tien en dan komt er geen data meer binnen. Dat is dus net zoals als al die 0x3c2 packets waarvan ik geen idee heb wat ik ermee moet. Iemand die meer dan één SE inverter heeft zou, net als jbuehl heeft gedaan, de twee aan elkaar koppelen en dan kijken wat de reactie moet zijn op 0x3c2 en die foutcodes. Maar dat zit er voor mijzelf dus niet in.

Ik ben er nu wel een beetje klaar mee. Ik had een hele constructie gemaakt om op afstand RS485 te kunnen sturen en uitlezen, die ga ik nu maar opruimen. Ik verwacht niet dat SolarEdge hierin behulpzaam gaat zijn. Gelukkig hebben we nog gewoon de TCP ModBus gegevens die correct en real-time zijn. Alleen dan dus geen gegevens per optimizer. Ik heb van vorig jaar de verdeling tussen voorkant/achterkant van het huis per tijdstip geanalyseerd en daaruit een algoritme gemaakt, die nu dus berekent in plaats van bepaalt hoeveel procent van welke kant van het huis komt.

De string-spanning wordt bepaald door het aantal panelen (of eigenlijk optimizers). Elke optimiser is 30 V. Dus mijn string is 12 x 30 = 360 V. Wat maakt het uit wat dat voltage precies is?

[ Voor 7% gewijzigd door eriksl op 09-03-2024 10:00 ]

[ocaj]

Aha, dat herken ik niet. Ik heb hier wél twee omvormers. Ik kan wel voor je zoeken of ik in mijn data ergens 3c2-berichten zie? Moet er weer even induiken, maar daar kom ik wel uit....
Kan natuurlijk zijn dat dit in mijn oudere firmware niet of minder voorkwam, maar misschien kun je er iets mee?

Nee, de stringspanning is constant, maar de spanning per optimizer is dynamisch afhankelijk van hoeveel zon er op valt, dat is het hele solaredge-gebeuren (zie uitleg "tuinhuisje" in het grote solaredge-topic). Ik heb op 1 omvormer met 4 panelen op Oost en 7 op West. Voor mijn oude pre-HD-omvormer (met slechts 345V stringspanning) was dat genoeg. Met 370V had ik het net gered, maar 400V heb ik tot een uur of 11 last van "clipping".

[eriksl]

Als je me ook maar iets kunt vertellen over 0x3c2 berichten of wat daar op terugkomt zou dat heel fijn zijn, misschien heb je nog ergens wat logging? Als je ook nog iets kunt zeggen over 0x4288 en 0x428a zou dat geweldig zijn, dat zijn die foutcodes die steeds meer worden.

Je onderste verhaal begrijp ik niet. Bedoel je dat je jouw inverter een maximale DC spanning heeft? Ik heb zelf 12 panelen en als die allemaal tegelijk maximaal beschenen zouden worden (wat in de praktijk nooit gebeurt), dan zou ik daarmee 3500W opwekken. Eén groep is normaal rond de 3680 W dus past precies. Dat betekent dat als ik meer panelen zou aansluiten, ik een extra groep zou moeten gebruiken en dus sowieso een extra inverter. En dan kom ik daarmee op 12 x 30 V = 360 V. En die spanning is heel erg constant (zoals volgens mij ook de bedoeling is). De enige situatie dat je volgens mij op een hogere DC zou kunnen komen is als je nóg meer panelen in één string zou zetten, bijvoorbeeld omdat de panelen niet goed gepositioneerd zijn t.o.v. de zon. Maar dan zou ik toch echt wel kiezen voor een extra inverter, ondanks dat de groep nog niet "vol" is.

BTW ik heb zes op oost en zes op west. Het huis is ietsje gedraaid t.o.v. het zuiden, waardoor oost meer oplevert dan west, maar west loopt, met name in de zomer, dan weer heel lang door in de avond en dat is dan ook wel weer mooi. Gisteren (vrijdag) lekker zonnige dag:

[ Voor 21% gewijzigd door eriksl op 09-03-2024 12:12 ]

[eriksl]

De planning is in de toekomst er nog een paar panelen bij te leggen. Ik ga dan de enkele string voor en achter onderbreken, alles van de voorkant op een (bestaande) inverter, achterkant op een nieuwe inverter en dan kan ik ze ook apart uitlezen, dan is de optimiser data ook niet meer zo belangrijk. Ik moet dan wel een nieuw groep maken dwars door het huis naar de zolder en dat is wel even een uitdaging.

[eriksl]

Mijn stringspanning:

[vincent_1971]

eriksl schreef op zaterdag 9 maart 2024 @ 12:08:
Als je me ook maar iets kunt vertellen over 0x3c2 berichten of wat daar op terugkomt zou dat heel fijn zijn, misschien heb je nog ergens wat logging? Als je ook nog iets kunt zeggen over 0x4288 en 0x428a zou dat geweldig zijn, dat zijn die foutcodes die steeds meer worden.

Je onderste verhaal begrijp ik niet. Bedoel je dat je jouw inverter een maximale DC spanning heeft? Ik heb zelf 12 panelen en als die allemaal tegelijk maximaal beschenen zouden worden (wat in de praktijk nooit gebeurt), dan zou ik daarmee 3500W opwekken. Eén groep is normaal rond de 3680 W dus past precies. Dat betekent dat als ik meer panelen zou aansluiten, ik een extra groep zou moeten gebruiken en dus sowieso een extra inverter. En dan kom ik daarmee op 12 x 30 V = 360 V. En die spanning is heel erg constant (zoals volgens mij ook de bedoeling is). De enige situatie dat je volgens mij op een hogere DC zou kunnen komen is als je nóg meer panelen in één string zou zetten, bijvoorbeeld omdat de panelen niet goed gepositioneerd zijn t.o.v. de zon. Maar dan zou ik toch echt wel kiezen voor een extra inverter, ondanks dat de groep nog niet "vol" is.

BTW ik heb zes op oost en zes op west. Het huis is ietsje gedraaid t.o.v. het zuiden, waardoor oost meer oplevert dan west, maar west loopt, met name in de zomer, dan weer heel lang door in de avond en dat is dan ook wel weer mooi. Gisteren (vrijdag) lekker zonnige dag: [Afbeelding]

Bij solaredge heb je bij elk paneel een optimizer. Er gaat een bepaalde spanning in van het zonnepaneel ( bij mij is dat maximaal 35v ) en er komt een bepaalde spanning uit ( bij mij is dat maximaal 60v ). De optimizer zorgt dat o.a. het vermogen maximaal is en ook dat de minimum spanning van de omvormer gehaald wordt. Dus in mijn geval is het 60v x 11 = maximaal 660v. Wordt niet gehaald omdat ik een z/o installatie heb. Heb je bijvoorbeeld een omvormer met maximaal 400v ingangsspanning verlies je vermogen.

[eriksl]

Dan heb jij kennelijk andere optimizers dan ik, want die van mij maken er altijd 32 V van (zie ook mijn grafiekje hierboven, twaalf panelen), vandaar 384 V string spanning, onafhankelijk van hoeveel zon er op het paneel schijnt (of het moet echt héél weinig zijn). De enige manier om boven de 400 V te komen is om nog meer panelen aan te sluiten en dan kom je weer boven de maximale invoering van een groep (3680 W). Dus echt, ik zie het probleem niet.

[ocaj]

eriksl schreef op zaterdag 9 maart 2024 @ 12:08:
Als je me ook maar iets kunt vertellen over 0x3c2 berichten of wat daar op terugkomt zou dat heel fijn zijn, misschien heb je nog ergens wat logging? Als je ook nog iets kunt zeggen over 0x4288 en 0x428a zou dat geweldig zijn, dat zijn die foutcodes die steeds meer worden.

Ik heb hier alle logging nog sinds 2016, keurig in 1 file per dag
Net al even een paar dagen zitten zoeken, maar 0x3c2 heb ik nog niet gezien. Ik zal de komende dagen nog wat verder in de logs gaan spitten.

vincent_1971 schreef op zaterdag 9 maart 2024 @ 12:20:
[...]

Bij solaredge heb je bij elk paneel een optimizer. Er gaat een bepaalde spanning in van het zonnepaneel ( bij mij is dat maximaal 35v ) en er komt een bepaalde spanning uit ( bij mij is dat maximaal 60v ). De optimizer zorgt dat o.a. het vermogen maximaal is en ook dat de minimum spanning van de omvormer gehaald wordt. Dus in mijn geval is het 60v x 11 = maximaal 660v. Wordt niet gehaald omdat ik een z/o installatie heb. Heb je bijvoorbeeld een omvormer met maximaal 400v ingangsspanning verlies je vermogen.

Nee, dat kan niet. Ik denk dat je verkeerd kijkt. VDC_Out van de optimizers ziet er bij mij bij Oost-West zo uit:

Dit is een oud plaatje met 4 x oost en 4 x West. De P404-optimizers kunnen maximaal 85V maken.

Wat (nagenoeg) constant is:
- V_DC van de omvormer
- Stroom in de hele string

Oftewel: Als 1 optimizer meer vermogen kan produceren dan de andere dan moet die optimizer een hogere spanning hebben dan een schaduw-optimizer. Solaredge regelt dat continu bij, zodat enerzijds de stringspanning constant is en anderzijds de stroom in de string (en daarmee het vermogen) zo hoog mogelijk is.

Alle optimizers dezelfde spanning heb je alleen als ze allemaal precies evenveel vermogen kunnen opleveren (bij oost/west ongeveer rond het middaguur). Maar niet elk paneel is identiek, in de praktijk komt allemaal gelijke spanning dus nooit voor.

[vincent_1971]

eriksl schreef op zaterdag 9 maart 2024 @ 12:26:
Dan heb jij kennelijk andere optimizers dan ik, want die van mij maken er altijd 32 V van (zie ook mijn grafiekje hierboven, twaalf panelen), vandaar 384 V string spanning, onafhankelijk van hoeveel zon er op het paneel schijnt (of het moet echt héél weinig zijn). De enige manier om boven de 400 V te komen is om nog meer panelen aan te sluiten en dan kom je weer boven de maximale invoering van een groep (3680 W). Dus echt, ik zie het probleem niet.

De paneelspanning bij mij varieert in deze grafiek van 32v tot 34v ( oost paneel ).
De optimizer spanning varieert van 25v tot 41v.


Kijk ik naar de omvormer zie je dat die om 7:00 voldoende spanning heeft. Dit is ook te zien in de grafiek. Gaat naar 370v en blijft vrij constant. Als je naar de optimizer grafiek kijkt zie je dat die rond 7:00 vermogen levert. Blijkbaar is het totaal aan panelen dan voldoende om de omvormer te doen produceren.

In mijn optiek heb je ergens een serieus ontwerpfout zitten in je installatie. Als je optimizers constant 32v aangeven. Wellicht zijn die defect.

[vincent_1971]

ocaj schreef op zaterdag 9 maart 2024 @ 12:53:
[...]

Ik heb hier alle logging nog sinds 2016, keurig in 1 file per dag
Net al even een paar dagen zitten zoeken, maar 0x3c2 heb ik nog niet gezien. Ik zal de komende dagen nog wat verder in de logs gaan spitten.


[...]


Nee, dat kan niet. Ik denk dat je verkeerd kijkt. VDC_Out van de optimizers ziet er bij mij bij Oost-West zo uit:
[Afbeelding: 20180319 V_DC Out]
Dit is een oud plaatje met 4 x oost en 4 x West. De P404-optimizers kunnen maximaal 85V maken.

Wat (nagenoeg) constant is:
- V_DC van de omvormer
- Stroom in de hele string

Oftewel: Als 1 optimizer meer vermogen kan produceren dan de andere dan moet die optimizer een hogere spanning hebben dan een schaduw-optimizer. Solaredge regelt dat continu bij, zodat enerzijds de stringspanning constant is en anderzijds de stroom in de string (en daarmee het vermogen) zo hoog mogelijk is.

Alle optimizers dezelfde spanning heb je alleen als ze allemaal precies evenveel vermogen kunnen opleveren (bij oost/west ongeveer rond het middaguur). Maar niet elk paneel is identiek, in de praktijk komt allemaal gelijke spanning dus nooit voor.

Heb het over paneelspanning( spanning van het zonnepaneel zelf ). Die varieert bij mij van 0 tot 35v. De optimizer spanning vertoont veelal een ander patroon, bij mij althans.

[eriksl]

Bottom line is dat de totale stringspanning heel constant is en dus niet zomaar op een deel van de dag opeens veel hoger is (wat de inverter niet fijn zou vinden).

[mawashigeri]

ZwarteIJsvogel schreef op vrijdag 8 maart 2024 @ 10:44:
Als je het monitoring platform weet te hacken, kun je allerlei lelijke dingen doen met aangesloten omvormers (bv. om het elektriciteitsnet van een land te destabiliseren).

Kun je dat eens uitleggen? Voor zover ik weet en kan zien is het monitoring platform precies dat, hoe kunnen ze mijn SolarEdge omvormer aansturen dan?

[Rouske]

eriksl schreef op zaterdag 9 maart 2024 @ 13:01:
Bottom line is dat de totale stringspanning heel constant is en dus niet zomaar op een deel van de dag opeens veel hoger is (wat de inverter niet fijn zou vinden).

Die totale stringspanning wordt alleen hoger als je omvormer aan het aftoppen is en daar kan die gewoon tegen, want zo ontworpen.
(Ook bij het in en uitschakelen van productie)

[ Voor 6% gewijzigd door Rouske op 17-04-2024 00:04 ]

[vincent_1971]

Rouske schreef op dinsdag 16 april 2024 @ 12:23:
[...]

Die totale stringspanning wordt alleen hoger als je omvormer aan het aftoppen is en daar kan die gewoon tegen, want zo ontworpen.

Nou ben het niet met je eens...zie mijn stringspanning bijvoorbeeld eens. In de ochtend en in de avond zie je een piekje. Voor de rest redelijk constante spanning.

[Browny]

@vincent_1971
De stringspanning blijft steeds redelijk constant . De stringspanning wordt hoger dan wat de omvormer wil bv bij 3fasige se..k 750volt.
Als de omvormer aan aftoppen is of aan het opstarten is dan stijgt de de spanning boven deze waarde.
De paneel spanning blijft redelijk constant en de waarde is afhankelijk van het paneel wat je hebt. De optimizers zorgen ervoor dat de stringspanning gemaakt wordt door de paneel spanning te verhogen of te verlagen. De optimizers bij solaredge is een Buck boost converter.

[Rouske]

vincent_1971 schreef op dinsdag 16 april 2024 @ 13:40:
[...]
[Afbeelding]

Nou ben het niet met je eens...zie mijn stringspanning bijvoorbeeld eens. In de ochtend en in de avond zie je een piekje. Voor de rest redelijk constante spanning.

Jij hebt zo een set-app ding.
Mijn oude SE3680H (HDWave met display) heeft ook de in en uitschakel piekjes, maar dan is de levering 0W.
Het ging mij om de verhoogde stringspanning tijdens productie aftoppen.

Zie de roze lijn of de tabel voor het voltage van de DC string bij aftoppen, standaard rond de 370V. https://pvoutput.org/intr...0752&dt=20240411&gs=0&m=0

[ Voor 1% gewijzigd door Rouske op 16-04-2024 23:58 . Reden: Verduidelijking wat er bedoeld wordt. ]

[Browny]

@Rouske

Die pieken die je ziet is dat de Dc spanning stijgt boven zijn normale waarde ten gevolge dat de omvormer aan het aftoppen is. D.w.z. dat de string meer vermogen levert dan de omvormer kan omzetten in ac vermogen. Dit is geen probleem de omvormer kan ertegen , die stijging van de Dc spanning bij aftoppen wordt gestuurd door de omvormer zelf.

[Rouske]

@Browny dat weet ik, aangezien ik dat zelf ook al zeg in het bericht er voor

Rouske schreef op dinsdag 16 april 2024 @ 12:23:
Die totale stringspanning wordt alleen hoger als je omvormer aan het aftoppen is en daar kan die gewoon tegen, want zo ontworpen.

Het bericht was meer voor @vincent_1971 ter verduidelijking dat ik niet de opstart pieken bedoel, maar de string verhoging tijdens aftoppen.

[ZwarteIJsvogel]

mawashigeri schreef op dinsdag 16 april 2024 @ 11:05:
[...]

Kun je dat eens uitleggen? Voor zover ik weet en kan zien is het monitoring platform precies dat, hoe kunnen ze mijn SolarEdge omvormer aansturen dan?

SolarEdge heeft voor remote support (probleemanalyse, firmware updates, etc.) toegang nodig tot je omvormer. Vanuit SolarEdge een verbinding opzetten gaat niet: de (NAT-)firewall van je router verhindert dat.

Voor remote support moet SolarEdge gebruik maken van de verbinding die je omvormer opzet naar het monitoring platform. Wie de juiste toegang tot het monitoring platform weet te verkrijgen, heeft daardoor in principe toegang tot alle aangesloten omvormers en vanuit de omvormers ook tot de lokale netwerken van de betreffende klanten. Dat heet een supply chain attack. SolarEdge zal daar ongetwijfeld maatregelen tegen hebben getroffen.

[eriksl]

Maar alles is te hacken. Het enige wat aansluiten over internet via SE zou opleveren is informatie over de opbrengst van de afzonderlijke panelen (optimisers). De anders informatie kun je via modbus-over-tcp opvragen. Informatie over de optimisers kun je ook, niet-realtime, opvragen met de SE app met de inverter in "AP" mode.

Kortom, ik vind het niet zoveel extra's bieden, vandaar dat die van mij gewoon niet op internet zitten.

Overigens blijkt dat de inverters op ontzettend grote ranges "registers" van tcp modbus reageren. Ik heb al gezien dat sommige ranges duplicaten zijn, dat drukt te pret wel een beetje, maar wie weet zit er stiekem toch wel informatie van de optimisers tussen. Daarvoor moet ik altijd nog eens een paar keer een dump maken van alle registers als het donker is en als de zon schijnt, en dan vergelijken. Ik heb dat al eens eerder gedaan, maar toen was er nog opbrengst, dus minder duidelijk welke registers met opbrengst te maken hebben, daar kwam toen niks uit. Wel verschillen, maar niet overduidelijk.

[ZwarteIJsvogel]

eriksl schreef op zondag 21 april 2024 @ 08:52:
Maar alles is te hacken.

Zeker. Maar daar gaat het niet om. @mawashigeri vroeg om een onderbouwing van mijn stelling dat wie het monitoring platform weet te hacken toegang kan krijgen tot je omvormer en die onderbouwing heb ik gegeven.

Overigens blijkt dat de inverters op ontzettend grote ranges "registers" van tcp modbus reageren. Ik heb al gezien dat sommige ranges duplicaten zijn

Vanaf adres 0 en vanaf adres 40000 zitten de SunSpec data modellen. Bij mijn SE4000H zijn het 15 modellen die in totaal 1101 modbus registers gebruiken. De data in deze blokken is identiek by design.

dat drukt te pret wel een beetje, maar wie weet zit er stiekem toch wel informatie van de optimisers tussen

Voor zover ik weet nog steeds niet. Helaas.

[eriksl]

Niet gedocumenteerd, inderdaad. Maar er reageren zoveel adressen, dat de kans bestaat dat er best wel wat "interne" dingen tussen zitten.

[mawashigeri]

ZwarteIJsvogel schreef op zondag 21 april 2024 @ 07:49:
SolarEdge heeft voor remote support (probleemanalyse, firmware updates, etc.) toegang nodig tot je omvormer. Vanuit SolarEdge een verbinding opzetten gaat niet: de (NAT-)firewall van je router verhindert dat.
[...]
Wie de juiste toegang tot het monitoring platform weet te verkrijgen, heeft daardoor in principe toegang tot alle aangesloten omvormers en vanuit de omvormers ook tot de lokale netwerken van de betreffende klanten.

Ah OK, leek me al sterk dat ze zomaar 'iedereen' konden bereiken - maar het is natuurlijk heel denkbaar dat een eens gegeven toegang niet altijd weer dichtgezet wordt aan de klantenkant, zeker als de eindklant dit door de installateur laat regelen.

[eriksl]

Volgens mij is het zo (en daar maak ik me wel zorgen over) dat zodra je je aanmeldt voor cloud service van SolarEdge (en bijna iedereen doet dat, lekker makkelijk grafiekjes zien), dat er dan elke paar minuten een verbinding wordt opgezet naar de SE servers. De inverters kunnen vanaf daar ook opdrachten ontvangen als de verbinding er eenmaal is. Moet je voorstellen als iemand het voor elkaar krijgt jouw inverter naar een eigen server om te leiden of de servers van SolarEdge weet te hacken.

Vandaar dat die van mij gewoon niet aan internet hangen.

[mawashigeri]

eriksl schreef op dinsdag 23 april 2024 @ 15:32:
Volgens mij is het zo (en daar maak ik me wel zorgen over) dat zodra je je aanmeldt voor cloud service van SolarEdge (en bijna iedereen doet dat, lekker makkelijk grafiekjes zien), dat er dan elke paar minuten een verbinding wordt opgezet naar de SE servers. De inverters kunnen vanaf daar ook opdrachten ontvangen als de verbinding er eenmaal is. Moet je voorstellen als iemand het voor elkaar krijgt jouw inverter naar een eigen server om te leiden of de servers van SolarEdge weet te hacken.

Vandaar dat die van mij gewoon niet aan internet hangen.

Een verbinding *naar* de servers is (hopelijk) eenrichtingsverkeer, tenzij je via de authenticatieprotocollen de omvormer alsnog over de kling kan jagen.

[eriksl]

De connectie "naar" de servers wordt vanuit de inverter opgezet (tegnies gesproken, de TCP SYN wordt vanaf de inverter gestuurd). Nadat de verbinding compleet is opgezet (-> TCP SYN, <- SYN ACK -> ACK) gaat data (full duplex) twee kanten op. Wie zegt dat de SE servers dan geen commando's naar jouw inverter kunnen sturen?

[ocaj]

eriksl schreef op zaterdag 9 maart 2024 @ 12:08:
Als je ook nog iets kunt zeggen over 0x4288 en 0x428a zou dat geweldig zijn, dat zijn die foutcodes die steeds meer worden.

Gisteren is er hier een defecte optimizer vervangen en daarbij heeft de installateur de firmware van één van mijn omvormers ge-update (kan volgens mij niet anders in de SetApp). Ik zie nu ook een enorme flood aan 0x428a en soms 0x4288-berichten. Ca. 5-6 per seconde.

Ik heb wel twee omvormers, maar als ik semonitor start voor alleen de ene niet geupdate omvormer, dan zie ik nog steeds al die 0x428a/8-berichten van de andere omvormer. Oftewel: Die omvormer staat die berichten de bus op te slingeren zonder dat hem iets gevraagd wordt.
Voorheen was het vrij simpel (net als bij modbus/RS485): slaves houden hun mond totdat de master ze aanspreekt. Maar met de huidige firmware is er dus ook een broadcast-mogelijkheid voor de omvormers. Misschien is het een soort auto-discovery-protocol of zoiets?

Ik log alle communicatie op de RS485-aansluiting al jaren en dat is normaal zo'n 5-600kB per dag. Ik zit nu in 9 uur al op 45MB.

(uiteraard gebeurt zoiets na 8 jaar probleemloos draaien precies een paar dagen voor ik op vakantie ga, dus geen tijd om te debuggen )

Anders dan bij jou komt er overigens nog wel steeds de juiste optimizer-data tussendoor. Functioneel is er dus nog niks aan de hand, maar helemaal lekker is het niet.

Voor de volledigheid een dump van zo'n 0x428a-bericht:

code:

Jul 19 13:36:33 /dev/ttyUSB_solaredge --> message: 206 length: 260
Jul 19 13:36:33 data:       12 34 56 79 ee 00 11 ff cd d3 01 7f 03 74 fe ff
Jul 19 13:36:33 data:       ff ff 8a 42 02 00 01 00 15 00 49 6e 76 50 61 63
Jul 19 13:36:33 data:       6b 2d 37 34 38 33 37 46 30 31 00 04 00 d3 00 0a
Jul 19 13:36:33 data:       10 49 6e 76 50 61 63 6b 2d 37 34 38 33 37 46 30
Jul 19 13:36:33 data:       31 10 01 1a bc 01 0a 0b 08 ff ff ff ff ff ff ff
Jul 19 13:36:33 data:       ff ff 01 12 05 0d 00 00 00 00 1a 05 0d b0 7e 8e
Jul 19 13:36:33 data:       44 22 05 0d 00 c0 3f 44 2a 05 08 bf ab eb 17 32
Jul 19 13:36:33 data:       02 08 00 3a 02 08 00 42 05 0d 00 00 00 00 4a 05
Jul 19 13:36:33 data:       0d 00 00 00 00 5a 28 0a 02 08 0f 12 09 08 03 12
Jul 19 13:36:33 data:       05 0d 00 00 c8 42 1a 13 0a 06 08 ff ff ff ff 0f
Jul 19 13:36:33 data:       1a 09 08 03 12 05 0d ff ff 7f 7f 22 02 08 02 5a
Jul 19 13:36:33 data:       28 0a 02 08 0e 12 09 08 03 12 05 0d 00 00 c8 42
Jul 19 13:36:33 data:       1a 13 0a 06 08 ff ff ff ff 0f 1a 09 08 03 12 05
Jul 19 13:36:33 data:       0d ff ff 7f 7f 22 02 08 01 62 05 0d 00 00 c8 42
Jul 19 13:36:33 data:       6a 05 0d ff ff 7f 7f 72 05 0d ff ff 7f 7f 7a 02
Jul 19 13:36:33 data:       08 00 82 01 05 0d 00 00 c8 42 8a 01 05 0d ea 43
Jul 19 13:36:33 data:       f4 4a c1 c8
Jul 19 13:36:33 dataLen:    00ee
Jul 19 13:36:33 dataLenInv: ff11
Jul 19 13:36:33 sequence:   d3cd
Jul 19 13:36:33 source:     74037f01
Jul 19 13:36:33 dest:       fffffffe
Jul 19 13:36:33 function:   428a
Jul 19 13:36:33 Unknown function 0x428a

[ocaj]

eriksl schreef op zaterdag 9 maart 2024 @ 09:58:
Het gaat niet om het script. De interface op de omvormer loopt vast, in die zin dat je alleen nog maar (veel) packets van één bepaald type krijgt (checksum is OK, dus is geen garbage). Dat zullen waarschijnlijk foutmeldingen zijn, maar er zit geen leesbare tekst in. En waarschijnlijk gaat hij pas verder op het moment dat je al die foutmeldingen hebt geacknowledged. Ik heb vanalles geprobeerd, maar niks werkt. Pas als je, via de app, de interface uitzet en weer aan gaat het weer werken.

Inmiddels is bij mij ook de hele boel vastgelopen. Ik kom alleen met geen mogelijkheid meer in de omvormer. Voorheen kon je handmatig verbinden met het wifi-netwerk van de omvormer en dan naar http://172.16.0.1 browsen, waar je hetzelfde kon doen als de SetApp, maar die pagina laadt nu niet meer.

Via de SetApp kom ik er nog wel in, maar dan heb ik alleen kijk-rechten....

@eriksl Kun je mij vertellen hoe ik de interface weer kan resetten?

[Get!em]

eriksl schreef op dinsdag 23 april 2024 @ 17:19:
De connectie "naar" de servers wordt vanuit de inverter opgezet (tegnies gesproken, de TCP SYN wordt vanaf de inverter gestuurd). Nadat de verbinding compleet is opgezet (-> TCP SYN, <- SYN ACK -> ACK) gaat data (full duplex) twee kanten op. Wie zegt dat de SE servers dan geen commando's naar jouw inverter kunnen sturen?

Vziw kan SolarEdge vanaf afstand inderdaad opdrachten geven.
Zo hebben ze bij mij de optimizers opnieuw in pairing gezet vanaf afstand (een commando dat je dus normaal vanaf je setapp stuurt)

[eriksl]

ocaj schreef op vrijdag 19 juli 2024 @ 14:04:
[...]


Gisteren is er hier een defecte optimizer vervangen en daarbij heeft de installateur de firmware van één van mijn omvormers ge-update (kan volgens mij niet anders in de SetApp). Ik zie nu ook een enorme flood aan 0x428a en soms 0x4288-berichten. Ca. 5-6 per seconde.

Ik heb wel twee omvormers, maar als ik semonitor start voor alleen de ene niet geupdate omvormer, dan zie ik nog steeds al die 0x428a/8-berichten van de andere omvormer. Oftewel: Die omvormer staat die berichten de bus op te slingeren zonder dat hem iets gevraagd wordt.
Voorheen was het vrij simpel (net als bij modbus/RS485): slaves houden hun mond totdat de master ze aanspreekt. Maar met de huidige firmware is er dus ook een broadcast-mogelijkheid voor de omvormers. Misschien is het een soort auto-discovery-protocol of zoiets?

Ik log alle communicatie op de RS485-aansluiting al jaren en dat is normaal zo'n 5-600kB per dag. Ik zit nu in 9 uur al op 45MB.

(uiteraard gebeurt zoiets na 8 jaar probleemloos draaien precies een paar dagen voor ik op vakantie ga, dus geen tijd om te debuggen )

Anders dan bij jou komt er overigens nog wel steeds de juiste optimizer-data tussendoor. Functioneel is er dus nog niks aan de hand, maar helemaal lekker is het niet.

Voor de volledigheid een dump van zo'n 0x428a-bericht:

code:

Jul 19 13:36:33 /dev/ttyUSB_solaredge --> message: 206 length: 260
Jul 19 13:36:33 data:       12 34 56 79 ee 00 11 ff cd d3 01 7f 03 74 fe ff
Jul 19 13:36:33 data:       ff ff 8a 42 02 00 01 00 15 00 49 6e 76 50 61 63
Jul 19 13:36:33 data:       6b 2d 37 34 38 33 37 46 30 31 00 04 00 d3 00 0a
Jul 19 13:36:33 data:       10 49 6e 76 50 61 63 6b 2d 37 34 38 33 37 46 30
Jul 19 13:36:33 data:       31 10 01 1a bc 01 0a 0b 08 ff ff ff ff ff ff ff
Jul 19 13:36:33 data:       ff ff 01 12 05 0d 00 00 00 00 1a 05 0d b0 7e 8e
Jul 19 13:36:33 data:       44 22 05 0d 00 c0 3f 44 2a 05 08 bf ab eb 17 32
Jul 19 13:36:33 data:       02 08 00 3a 02 08 00 42 05 0d 00 00 00 00 4a 05
Jul 19 13:36:33 data:       0d 00 00 00 00 5a 28 0a 02 08 0f 12 09 08 03 12
Jul 19 13:36:33 data:       05 0d 00 00 c8 42 1a 13 0a 06 08 ff ff ff ff 0f
Jul 19 13:36:33 data:       1a 09 08 03 12 05 0d ff ff 7f 7f 22 02 08 02 5a
Jul 19 13:36:33 data:       28 0a 02 08 0e 12 09 08 03 12 05 0d 00 00 c8 42
Jul 19 13:36:33 data:       1a 13 0a 06 08 ff ff ff ff 0f 1a 09 08 03 12 05
Jul 19 13:36:33 data:       0d ff ff 7f 7f 22 02 08 01 62 05 0d 00 00 c8 42
Jul 19 13:36:33 data:       6a 05 0d ff ff 7f 7f 72 05 0d ff ff 7f 7f 7a 02
Jul 19 13:36:33 data:       08 00 82 01 05 0d 00 00 c8 42 8a 01 05 0d ea 43
Jul 19 13:36:33 data:       f4 4a c1 c8
Jul 19 13:36:33 dataLen:    00ee
Jul 19 13:36:33 dataLenInv: ff11
Jul 19 13:36:33 sequence:   d3cd
Jul 19 13:36:33 source:     74037f01
Jul 19 13:36:33 dest:       fffffffe
Jul 19 13:36:33 function:   428a
Jul 19 13:36:33 Unknown function 0x428a

Bij mij is dat ook, maar op een gegeven moment komt er geen optimiser data meer doorheen.

En inderdaad, de data komt ook zonder sollicitation. Sterker nog, als je gaat vragen, gaat het meestal niet goed.

[eriksl]

Get!em schreef op vrijdag 19 juli 2024 @ 22:35:
[...]

Vziw kan SolarEdge vanaf afstand inderdaad opdrachten geven.
Zo hebben ze bij mij de optimizers opnieuw in pairing gezet vanaf afstand (een commando dat je dus normaal vanaf je setapp stuurt)

En ze zullen de inverter vast ook wel kunnen uit zetten. Op zich geen moeite mee, maar wel als een "derde partij" dat gaat doen. Dat is precies waar veel mensen zich zorgen over maken met toegang vanaf inverters naar internet. En daarom heb ik het niet aan staan.

[eriksl]

ocaj schreef op vrijdag 19 juli 2024 @ 22:34:
[...]


Inmiddels is bij mij ook de hele boel vastgelopen. Ik kom alleen met geen mogelijkheid meer in de omvormer. Voorheen kon je handmatig verbinden met het wifi-netwerk van de omvormer en dan naar http://172.16.0.1 browsen, waar je hetzelfde kon doen als de SetApp, maar die pagina laadt nu niet meer.

Via de SetApp kom ik er nog wel in, maar dan heb ik alleen kijk-rechten....

@eriksl Kun je mij vertellen hoe ik de interface weer kan resetten?

Oef... Die setup pagina heeft bij mij nooit gewerkt overigens. Ik moest dat altijd al via de SetApp doen.

En eh ja, ik ben bang dat je er niet aan ontkomt om je te registreren als "de installateur" en dan mag je overal bij. Ik dacht dat dat heel lastig zou zijn, maar valt reuze mee, was binnen een dag rond.

Om de interface te resetten doe je dan deze uitzetten weer aanzetten.

Maar wat je ook kunt doen is hem gewoon even uitzetten, met het kleine knopje. Ben je wel vijf minuten verder voordat alles weer up is. Maar via de SetApp ben je net zo lang bezig dus...

[ocaj]

Dank voor je reactie @eriksl . Aangezien ik in de 8 jaar sinds ik zonnepanelen heb al de nodige wijzigingen, uitbreidingen en defecte apparaten heb gehad en mijn omvormers nooit aan internet hingen had mijn leverancier ook de wijzigingen aan de layout etc nooit meer ingevoerd in de monitoring portal. Ze hadden ook niet meer het hele overzicht wat er nu precies waar lag, ik gelukkig wel. Ze gaan het invoeren, maar is nog niet gebeurd, ik neem aan ivm vakantie-periode. Dan kan ik hem in ieder geval aan de online monitoring koppelen als lokaal niet meer lukt.

Toen ik terug kwam van vakantie heb ik nog wat zitten klooien in de setup-pagina (die het niet deed met mijn iPad, maar wel met een laptop. iPad is al wat ouder, dus mogelijk een browser-compatibiliteitsdingetje of zo). Nadat ik de monitoring even naar wifi wilde zetten zag ik dat signaalsterkte beroerd was, dus geen netwerk gekozen en weer terug op RS485 gezet (en een wifi-antenne besteld).

Sindsdien doet hij het al weer een dag of 5 vlekkeloos. Geen rare berichten meer, alleen prima data.
Maar op basis van jouw ervaring check ik wel elke dag of hij ineens weer de hik gaat krijgen.
Monitoring is voor mij vooral iets wat vanzelf netjes door moet lopen en waar ik niet al te veel omkijken naar moet hebben. Als ik regelmatig de interface moet gaan resetten, dan wordt ik daar niet blij van.

Even afwachten dus of en hoe lang hij stabiel blijft draaien zonder onzin-berichten....

[eriksl]

Interessant! Bij mij gaat het namelijk altijd al binnen een dag fout. Ik zie dan steeds meer onbekende berichten langskomen en op een gegeven moment niks zinnig meer naast die berichten. Maakt niet uit hoe ik de inverter uitvraag, ik heb al heel veel geprobeerd. Ik heb ook wel geprobeerd bijvoorbeeld om al die berichten te ACK'en maar dat maakt ook niet uit.

Ik denk dat ik ergens een klein defect heb, bijvoorbeeld een bad sector in de flash, waar hij steeds meer over gaat zeuren. Helaas heb ik geen idee wat er in die onbekende berichten staat, ze zijn kort en totaal onleesbaar.

Als het zover is, moet ik de interface resetten voordat er ook nog maar iets komt.

Ik heb het voor het moment opgegeven. Ik doe het nu zo: aan de hand van historische gegevens heb ik een formule gemaakt die de verdeling tussen "voor" (6 panelen) en "achter" (6 panelen) kan benaderen op elk moment van de dag. Dat is wat ik nu toon, met de huidige opbrengst als input.

Als ik het gevoel ga krijgen dat een van de panelen/optimisers minder goed werkt, kan ik die altijd opvragen met de SetApp.

Verder werkt de tcp modbus interface uitstekend, daar haal ik elke minuut de huidige gegevens mee op. Als ze nou alleen, in die enorme hoeveelheid registers, ook nou even een páár registers zouden toewijzen waarmee je de individuele optimisers zou kunnen opvragen, dan zou ik dat perfect vinden. Maar tot op heden lijkt het er niet op dat die informatie via tcp modbus is op te vragen, heb er al aardig wat onderzoek naar gedaan.

[mawashigeri]

eriksl schreef op vrijdag 9 augustus 2024 @ 09:36:
Interessant! Bij mij gaat het namelijk altijd al binnen een dag fout. Ik zie dan steeds meer onbekende berichten langskomen en op een gegeven moment niks zinnig meer naast die berichten. Maakt niet uit hoe ik de inverter uitvraag, ik heb al heel veel geprobeerd. Ik heb ook wel geprobeerd bijvoorbeeld om al die berichten te ACK'en maar dat maakt ook niet uit.

Ik denk dat ik ergens een klein defect heb, bijvoorbeeld een bad sector in de flash, waar hij steeds meer over gaat zeuren. Helaas heb ik geen idee wat er in die onbekende berichten staat, ze zijn kort en totaal onleesbaar.

Misschien vloeken in de kerk, maar heb je toch eens geprobeerd de boel (tijdelijk) via het internet aan de SE cloud te hangen om te kijken wat voor informatie er dan over de lijntjes gaat?

[eriksl]

mawashigeri schreef op vrijdag 9 augustus 2024 @ 10:52:
[...]

Misschien vloeken in de kerk, maar heb je toch eens geprobeerd de boel (tijdelijk) via het internet aan de SE cloud te hangen om te kijken wat voor informatie er dan over de lijntjes gaat?

Dat zou ik best willen doen, maar het is tegenwoordig allemaal TLS mét validatie van certificaat van beide kanten. Geen MitM meer mogelijk dus.

[MarkBM]

Ik heb de informatie even gescand in deze topic, maar als ik het goed begrijp kan een eindgebruiker niet zomaar alerts krijgen over het niet goed functioneren van zijn zonnepanelen?

Hier ben ik eigenlijk wel naar op zoek. Mijn installatie heeft er incl reparatie nu 2 maanden uitgelegen. Ik ontdekte dit pas na ruim een maand. Ik hoef echt niet dagelijks te zien wat mijn panelen doen, maar wil wel geïnformeerd worden als het niet goed lijkt te werken.

Is hier toch niet een makkelijke optie voor? Kunnen ze je ook machtiging geven voor alerts in het gewone monitoringsgedeelte van je installatie?

[ProudElm]

Hier is toch juist het monitor portaal voor? Ik kan daar alerts zien over mijn systeem. Ik heb ooit wel een mail gehad dat mijn systeem niks produceerde door vermoedelijk sneeuw, wat klopt ;-) Ik heb wel alle rechten in het portaal.

[eriksl]

Voor mensen die zelf niet iets willen of kunnen optuigen is de portaal inderdaad volgens mij prima. Los van de veiligheidsaspecten. Je wilt toch wel een béétje weten wat er opgewekt wordt?

Totaal opgewekte vermogen en nog een paar parameters kun je ook vrij eenvoudig zelf uitlezen (met tcp modbus), daar heb je geen portaal voor nodig.

Pas op het moment dat je fouten en individuele panelen/optimisers wilt uitlezen ben je echt aangewezen op het portaal, omdat SolarEdge vindt dat je als particulier die informatie niet zelf mag opvragen. Vreemde redenatie. Als installateur overigens ook niet, het moet per sé via hun portal.

[ephymerous]

Even wat advies inwinnen hier. Ik heb nog een defecte omvormer van 4.000 watt. Eentje zonder LCD scherm overigens. Deze is onder garantie vervangen en de vervanger functioneert top. De defecte omvormer zou ik terugsturen naar SolarEdge en daarvoor zou ik details en materialen krijgen. Die heb ik gekregen en ook na herhaaldelijk contact zoeken krijg ik geen reactie hierop. Ik wil dus van de omvormer af. In de daarvoor bestemde elektronicabak of is ie daadwerkelijk nog wat waard?

[eriksl]

"hoogspanning" (230V en hoger) in combinatie met halfgeleiders en DSP's? Ik zou er zelf m'n vingers niet aan vuil willen maken, veel te veel kans op gevaarlijke problemen.

[Eboman]

Goedendag, ik heb momenteel solaredge gekoppeld aan mijn domoticz installatie via de tcp modbus (wifi) en ben ook bezig met home-assistant. Met wat testen is mijn conclusie dat modbus maar 1 tcp connectie toestaat. En ik ben dus op zoek naar een oplossing om de gegevens op beide platformen beschikbaar te maken. Ik vond hierbij een MQTT oplossing https://pypi.org/project/solaredge2mqtt/ , heeft iemand hier ervaring mee ? Ik wil het als een docker gaan draaien. Maar ik ben benieuwd of iemand het heeft draaien in domoticz of home-assistant via MQTT?

[eriksl]

Met TCP modbus is het de bedoeling dat je frequent pollt:
- setup tcp connectie
- vraag registers op (kan in bulk)
- connectie sluiten
Het is niet de bedoeling dat de connectie de hele tijd open blijft. De verbinding kan dus prima door meerdere programma's gebruikt worden, als ze maar netjes na afloop de verbinding weer sluiten.

MQTT lijkt me enorm omslachtig hiervoor? Alleen al omdat SolarEdge zelf geen MQTT protocol ondersteunt?

Betere oplossing, als de TCP modbus verbinding niet gedeeld kan worden, is dat één programma alle informatie er uit trekt en dat deelt met het andere programma?

[Eboman]

eriksl schreef op dinsdag 10 september 2024 @ 13:23:
Met TCP modbus is het de bedoeling dat je frequent pollt:
- setup tcp connectie
- vraag registers op (kan in bulk)
- connectie sluiten
Het is niet de bedoeling dat de connectie de hele tijd open blijft. De verbinding kan dus prima door meerdere programma's gebruikt worden, als ze maar netjes na afloop de verbinding weer sluiten.

MQTT lijkt me enorm omslachtig hiervoor? Alleen al omdat SolarEdge zelf geen MQTT protocol ondersteunt?

Betere oplossing, als de TCP modbus verbinding niet gedeeld kan worden, is dat één programma alle informatie er uit trekt en dat deelt met het andere programma?

Betere oplossing, als de TCP modbus verbinding niet gedeeld kan worden, is dat één programma alle informatie er uit trekt en dat deelt met het andere programma?
Dit is precies wat solaredge2mqtt probeert op te lossen, hij wordt een soort proxy voor de modbus informatie, En MQTT is een soort open standaard om informatie uit te wisselen in home-auomation.

[eriksl]

Ik ben bekend met MQTT. Ik vind het alleen absoluut geen mooi protocol *). Sowieso nogal met RPG op mug schieten (pun intended). Maar als jij het een nette manier aan de gang krijgt, leef je vooral uit ;-)

*) het is ontworpen niet voor home automation maar voor bedrijfs-gebouw-beheer. Daarom is het veel te complex voor wat je thuis zou willen doen.

[ Voor 27% gewijzigd door eriksl op 10-09-2024 13:31 ]

[Sypher]

eriksl schreef op dinsdag 10 september 2024 @ 13:30:
Ik ben bekend met MQTT. Ik vind het alleen absoluut geen mooi protocol *). Sowieso nogal met RPG op mug schieten (pun intended). Maar als jij het een nette manier aan de gang krijgt, leef je vooral uit ;-)

*) het is ontworpen niet voor home automation maar voor bedrijfs-gebouw-beheer. Daarom is het veel te complex voor wat je thuis zou willen doen.

MQTT is ontworpen voor IoT. Het is juist wel (geschikt) voor home automation. 🤨 Ben je niet in de war met KNX ofzo?

[Tijgerkracht]

eriksl schreef op dinsdag 10 september 2024 @ 13:30:
Ik ben bekend met MQTT. Ik vind het alleen absoluut geen mooi protocol *). Sowieso nogal met RPG op mug schieten (pun intended). Maar als jij het een nette manier aan de gang krijgt, leef je vooral uit ;-)

*) het is ontworpen niet voor home automation maar voor bedrijfs-gebouw-beheer. Daarom is het veel te complex voor wat je thuis zou willen doen.

MQTT is heel simpel, heb hier diverse Shelly en ook CO2 meters die alles pushen naar een MQTT broker waar Home Assistant het er weer netjes uithaalt. Werkt als een tierelier.

[eriksl]

Sypher schreef op dinsdag 10 september 2024 @ 16:09:
MQTT is ontworpen voor IoT. Het is juist wel (geschikt) voor home automation. 🤨 Ben je niet in de war met KNX ofzo?

Andy Stanford-Clark (IBM) and Arlen Nipper (then working for Eurotech, Inc.) authored the first version of the protocol in 1999.[4] It was used to monitor oil pipelines within the SCADA industrial control system.[5] The goal was to have a protocol that is bandwidth-efficient, lightweight and uses little battery power, because the devices were connected via satellite link which, at that time, was extremely expensive.[6]

[eriksl]

Tijgerkracht schreef op dinsdag 10 september 2024 @ 16:13:
MQTT is heel simpel, heb hier diverse Shelly en ook CO2 meters die alles pushen naar een MQTT broker waar Home Assistant het er weer netjes uithaalt. Werkt als een tierelier.

Correctie: als je alle software al heb en het is allemaal compatible, dan waarschijnlijk wel. Maar het protocol is een drama.

Anyway voor de vraagsteller is het kennelijk een prima oplossing.

[ Voor 7% gewijzigd door eriksl op 10-09-2024 16:33 ]

[ocaj]

eriksl schreef op vrijdag 9 augustus 2024 @ 09:36:
Interessant! Bij mij gaat het namelijk altijd al binnen een dag fout. Ik zie dan steeds meer onbekende berichten langskomen en op een gegeven moment niks zinnig meer naast die berichten.

Uiteindelijk hebben mijn omvormers een paar weken aan internet gehangen (nou ja, 1 aan internet, de andere doorgelust via RS485) voordat de installateur alles goed had ingeregeld.
Eerder deze week ben ik toch weer offline gegaan (ik vond het monitoring-platform nogal primitief en beperkt t.o.v. mijn eigen dashboards/logging) en alles werkt nu weer/nog steeds prima met de scripts van jbuehl.

Waar je op moet letten is dat er 2 plekken zijn in de instellingen:
- Monitoring -instellingen
- Site communication

Allebei moeten op "SolarEdge follower" staan. Eerst was ik 1 plek vergeten, toen was er nog heel veel "ruis" op de lijn. Verder heb ik het wifi-wachtwoord laten vergeten, nog een keer geschakeld naar ethernet (dat er niet aan zit) en uiteindelijk beide weer op SolarEdge follower via RS485 ingesteld. Voor de zekerheid ook beide omvormers nog even spanningsloos gemaakt.

Geen rare berichten-storm meer!

Enige verschil: De blauwe led gaat wél aan als hij met het online monitoringsplatform communiceert, maar niet als de communicatie via de lokale scripts draait.
Heel rouwig ben ik daar niet om; die blauwe led (2x, want 2 omvormers) verlichtten namelijk 's nachts de overloop op zolder. Nu de omvormers weer offline zijn is het 's nachts weer een stuk donkerder

[eriksl]

Zou best kunnen dat er bij mij iets mis is met de RS485 (aan de kant van de omvormer of aan de kant van mijn monitor). Ik heb heel veel geprobeerd en was er een beetje klaar mee.

Het irritante is dus dat na een reset, het best wel een tijdje werkt, maar dan steeds meer berichten die lijken op foutmeldingen totdat er alleen nog maar die berichten komen en niks anders.

Kan ook zijn dat jij een oudere omvormer hebt die net even andere firmware draait.

[Klaassie]

Iemand wel eens gehad dat er spontaan een nieuwere firmware geïnstalleerd werd?
Dat is bij mij blijkbaar gisteren gebeurt..

Zag vanmorgen ineens dat ik sinds gistermiddag 3 uur geen nieuwe data meer had op PVOutput.
Sinds de installatie van de omvormer (met display) begin 2019 draai ik al de scripts van TS om de data naar de SolarEdge portal te onderscheppen, in een eigen database te stoppen en naar PVOutput door te sturen. Vandaag kreeg ik hem echter niet meer aan de gang. Er werden wel pcap-files gegenereerd, maar kreeg de data niet meer in de database. Wat ook opviel is dat normaal de pcap-files tussen de 600 en 700 kB zijn, maar die van gisteren was 7988 kB.
Tijd zitten prutsen tot ik in Github zag dat de nieuwste versie van liveupdate.py op v0.0.17 zat (ook al van 2022) met als comment "Added support for new three-phase inverter firmware versions."
Kon hier verder ook niets over vinden eigenlijk, wat het probleem dan was en vanaf welke firmware bijvoorbeeld. Ik zit zelf nog op v0.0.13 van het script, nog met python2 ipv python3 en settings in het script, dus kan niet zomaar het nieuwste script pakken. Zag wel dat het verschil tussen v0.0.16 en v0.0.17 maar één regel betrof waar een extra lengte toegevoegd is:

code:

-   elif type == 0x0011 and length in (200, 264):  # 3ph inverter
 +   elif type == 0x0011 and length in (200, 264, 266):  # 3ph inverter

Deze aanpassing overgenomen in mijn script en alles draait weer!
Bedankt weer @Jerrythafast

Blijft natuurlijk apart dat dit zomaar optreed... Mijn firmware nu is CPU 3.2537
Helaas geen idee wat het eerder was. Deze is er volgens de SolarEdge site sowieso al vanaf juli 2020, maar is wel de meest recente voor mijn omvormer (3-fasen met display).

[Shakespeare2000]

Klaassie schreef op zondag 20 oktober 2024 @ 23:45:
Iemand wel eens gehad dat er spontaan een nieuwere firmware geïnstalleerd werd?
Dat is bij mij blijkbaar gisteren gebeurt..
...

Ik denk dat dit afgelopen zaterdag vrijdag ook bij mij is gebeurd. Ik ga meteen even proberen of dit mijn probleem oplost!

edit:
Ja, dat was het. De pcap van de 18e is ook 12MB groot.

[ Voor 10% gewijzigd door Shakespeare2000 op 21-10-2024 17:57 ]

[MantsjeKlaas]

Draai al sinds 2018 met SE-LOGGER en nog geen problemen gehad. Maar sinds gisteren krijg ik geen nieuwe dat meer in de MYSQL database. De .pcap file wordt wel elke minute geupdate. Verder heb ik in de liveupdate.log file de volgende melding: Warning! Got 78 mysterious bytes left! (state=0)
68 eb 6d 93 49 30 f3 cc 8f 53 f4 57 b9 6c 39 71 ee 0b 12 61 32 85 b1 a8 a2 14 49 90 74 16 b4 4a 50 3b 58 a4 90 17 7b d7 4a 02 88 21 4a 14 02 3f b8 f0 22 f0 95 1b ce 76 42 61 27 82 c6 3d f5 18 4f 81 c0 0c dd b0 06 5f f0 a6 04 be 9f 21.

Is er iemand die mij kan vertellen wat er aan de hand is en wat ik hier aan kan doen?

[discocandy]

Hoi. Ik ben al even bezig (weken) om de boel via WIFI aan de praat te krijgen.
ik heb een SE5000H 22 panelen in 2 strings en een inline meter 64010E4E
pingen op 192.168.178.196 lukt gewoon.
Telnet naar 1502 idem.
maar ik krijg telkens dat het instellen is mislukt in Home assistant .
Modbus Error: [Input/Output] No response received after 3 retries, continue with next request
Ik ga er van uit dat ik iets moet wijzigen in de Setapp maar ik kom er niet uit...

De error is in de modbusmulti intergratie. (de andere wilde helemaal niet...)
Ik heb duidelijk te kort kennis om dit voor elkaar te krijgen en hoop dat er mensen zijn die een handje willen helpen.
ik wil graag straks kunnen knijpen in mijn opwek en meer sturen.

onderstaand foto's zijn de error en mijn Lovelace. ieder paneel is zichtbaar (met dank aan de SolarEdge Optimizers Data plugin) en aan teklikken daarna popup.

[ Voor 3% gewijzigd door discocandy op 12-05-2025 09:55 ]

[technoot]

Het is op dit moment niet mogelijk om de actuele gegevens van individuele zonnepanelen uit omvormers van SolarEdge te halen met de volgende door SolarEdge aangeboden mogelijkheden:
• het Modbus-protocol (al dan niet over tcp)
• de webportaal (browser en app telefoon)
• de api (met api key)

In de webportaal zijn de gegevens wel te bekijken, maar je kunt de gegevens niet (automatisch) ophalen. Dat maakt het zelf monitoren van individuele zonnepanelen (o.a. grafieken van de spanning, de stroomsterkte, het vermogen en de optimizer spanning van individuele zonnepanelen gedurende de dag) onpraktisch. Ik heb daarom een MCP-server gebouwd waarmee je de gegevens van jouw individuele zonnepanelen/optimizers eenvoudig en periodiek kunt opvragen.

Ik wil nu starten met het testen van deze MCP-server en zoek daarvoor gebruikers van een Solaredge systeem die de MCP-server willen uitproberen. Heb je interesse om de MCP-server uit te proberen/te testen vul dan het formulier in op https://solaredge-formulier.marcvreeburg.nl Je ontvangt dan per omgaande nadere informatie per mail.

[Stefannn]

technoot schreef op zaterdag 24 mei 2025 @ 14:02:
Het is op dit moment niet mogelijk om de actuele gegevens van individuele zonnepanelen uit omvormers van SolarEdge te halen met de volgende door SolarEdge aangeboden mogelijkheden:
• het Modbus-protocol (al dan niet over tcp)
• de webportaal (browser en app telefoon)
• de api (met api key)

In de webportaal zijn de gegevens wel te bekijken, maar je kunt de gegevens niet (automatisch) ophalen. Dat maakt het zelf monitoren van individuele zonnepanelen (o.a. grafieken van de spanning, de stroomsterkte, het vermogen en de optimizer spanning van individuele zonnepanelen gedurende de dag) onpraktisch. Ik heb daarom een MCP-server gebouwd waarmee je de gegevens van jouw individuele zonnepanelen/optimizers eenvoudig en periodiek kunt opvragen.

Ik wil nu starten met het testen van deze MCP-server en zoek daarvoor gebruikers van een Solaredge systeem die de MCP-server willen uitproberen. Heb je interesse om de MCP-server uit te proberen/te testen vul dan het formulier in op https://solaredge-formulier.marcvreeburg.nl Je ontvangt dan per omgaande nadere informatie per mail.

[Afbeelding]

Ik kan het met het info formulier vragen maar ik denk dat meerderen dezelfde vraag hebben.

“Wat verwacht je van de respondenten”?
- wat voor setup moet je hebben (ik heb bijvoorbeeld een heel low power maar traag Linux systeem)
- wat moet daar dan op draaien?
- wat voor software programmatuur moet je daarop hebben draaien (php? Python? Home assistant?)
- moet het extern accessible zijn of enkel local?
Enz.

Als context:
Momenteel poll ik met een crontab elke minuut de Solaredge inverter via modbus over tcp. Ik doe dat met een minuscuul php script en een modbus library.

[Jerrythafast]

En misschien ook handig om te vermelden wat een MCP server is een hoe dat werkt? Wikipedia kent het niet... tenzij je het echt met een LLM aan het doen bent?

[eriksl]

Ik neem aan dat je een soort van "screen grabbing" doet (bij gebrek aan API hiervoor). Ben eigenlijk alleen geïnteresseerd hoe je dat doet, het programmeren doe ik wel lekker zelf ;-).

Overigens kleine aanvulling, de SE inverters doen ook een soort van state update via RS485, waarbij je meerdere inverters kunt koppelen aan elkaar en aan een datalogger. Via deze weg worden messages gedeeld waaruit (met vertraging, dat wel) de status (en dus ook opbrengst) van de individuele optimisers gedeeld wordt. In tegenstelling tot via IP, gaat dit (nog steeds) niet versleuteld. Het probleem is hierbij dat het allemaal nogal aankomt op precies de goede handshakes gebruiken. Ik heb er een paar maanden aan besteed en het uiteindelijk maar opgegeven. Er kwam steeds meer voor mij onbekende messages langs waar ik kennelijk "iets" mee moest omdat dan ook de messages met optimiser informatie stopten.

Heel flauw dat SE die informatie niet gewoon via de TCP modbus interface aanbiedt (wel honderden anderen variablen, overigens).

[tommiedepommie]

advies/tip gevraagd

Hallo allemaal,

zoals jullie allemaal weten, is een forum heel handig om met mensen met dezelfde interesse, te communiceren en elkaar te helpen om tot een oplossing te komen.

Maar, als je net als ik, later het idee krijgt om 'zelf monitoring' te gaan doen, is het ondoenlijk om eerst 111 lange pagina's door te lezen om te beginnen.

Daarom mijn vraag, ik heb een SE5000H met 10 panelen die ik graag via mijn eigen server wil gaan uitlezen.
Heeft iemand een suggestie hoe en waar ik moet beginnen?

Mijn doel is in eerste instantie om alleen de opbrengst uit te lezen en in grafiek te zetten en later eventueel gecombineerd met het verbruik. Ik woon in Frankrijk, niet in Nederland.

Alvast dank voor jullie hulp.

Groet Tom

[Gwaihir]

tommiedepommie schreef op maandag 7 juli 2025 @ 08:40:
Heeft iemand een suggestie hoe en waar ik moet beginnen?

Bij de topic start, de zoekfunctie, de laatste vijf pagina's?

Of vandaag de dag wellicht: door ChatGPT te vragen dit topic voor je samen te vatten?

[mawashigeri]

tommiedepommie schreef op maandag 7 juli 2025 @ 08:40:
advies/tip gevraagd

Hallo allemaal,

zoals jullie allemaal weten, is een forum heel handig om met mensen met dezelfde interesse, te communiceren en elkaar te helpen om tot een oplossing te komen.

Maar, als je net als ik, later het idee krijgt om 'zelf monitoring' te gaan doen, is het ondoenlijk om eerst 111 lange pagina's door te lezen om te beginnen.

Daarom mijn vraag, ik heb een SE5000H met 10 panelen die ik graag via mijn eigen server wil gaan uitlezen.
Heeft iemand een suggestie hoe en waar ik moet beginnen?

Mijn doel is in eerste instantie om alleen de opbrengst uit te lezen en in grafiek te zetten en later eventueel gecombineerd met het verbruik. Ik woon in Frankrijk, niet in Nederland.

Ietsje harder googelen?

[ErikJan2]

Ik wil dezelfde CSV files die ik op de web-interface met de hand kan downloaden, via code automatiseren (in Excel).
Ik heb de API key en heb gezien dat ik daarvoor de 'powerDetails' call nodig heb.
Die werkt (in een test met de hand) maar lijkt helaas alleen JSON of XML export te ondersteunen.
Stuur ik de juiste URL dus naar een browser, dan komt er dus niet vanzelf een nette CSV file als download in een folder die ik daarna kan oppikken met code en verwerken.
Het lijkt me heel vreemd dat juist deze call geen CSV ondersteunt. Mis ik iets? En zo nee, hoe zou ik dit dan het beste aanpakken?
Suggesties zijn welkom!

[Get!em]

ErikJan2 schreef op woensdag 8 oktober 2025 @ 21:33:
Ik wil dezelfde CSV files die ik op de web-interface met de hand kan downloaden, via code automatiseren (in Excel).
Ik heb de API key en heb gezien dat ik daarvoor de 'powerDetails' call nodig heb.
Die werkt (in een test met de hand) maar lijkt helaas alleen JSON of XML export te ondersteunen.
Stuur ik de juiste URL dus naar een browser, dan komt er dus niet vanzelf een nette CSV file als download in een folder die ik daarna kan oppikken met code en verwerken.
Het lijkt me heel vreemd dat juist deze call geen CSV ondersteunt. Mis ik iets? En zo nee, hoe zou ik dit dan het beste aanpakken?
Suggesties zijn welkom!

Wil je echt zelf iets maken of zou je ook willen leunen op wat al bestaat?

https://github.com/ProudElm/solaredgeoptimizers

https://github.com/stepsolar/hassio-package-panel-solar

[ErikJan2]

Dank voor de tips. Ik ben er inmiddels zelf al bijna uit (toch maar via JSON).
Wat ik wil is eigenlijk heel eenvoudig en Excel is (in mijn geval) voldoende en geeft me ook de vrijheid om zaken aan te passen en de data op meerdere manier samen te vatten, uit te rekenen en te visualiseren.
Als gezegd; ik heb nog niet echt iets maar het binnenhalen van de data lijkt te lukken, vanaf hier kom ik er wel uit ;-)

[ZwarteIJsvogel]

ErikJan2 schreef op woensdag 8 oktober 2025 @ 21:33:
Ik wil dezelfde CSV files die ik op de web-interface met de hand kan downloaden, via code automatiseren (in Excel).
Ik heb de API key en heb gezien dat ik daarvoor de 'powerDetails' call nodig heb.
Die werkt (in een test met de hand) maar lijkt helaas alleen JSON of XML export te ondersteunen.
Stuur ik de juiste URL dus naar een browser, dan komt er dus niet vanzelf een nette CSV file als download in een folder die ik daarna kan oppikken met code en verwerken.
Het lijkt me heel vreemd dat juist deze call geen CSV ondersteunt. Mis ik iets? En zo nee, hoe zou ik dit dan het beste aanpakken?
Suggesties zijn welkom!

SolarEdge Monitoring API for Windows PowerShell.

Voor export van de site energy naar een CSV-bestand kun je Export-SolarEdgeSiteEnergy gebruiken. Dat is een maand/jaar georiënteerd frontend voor Get-SolarEdgeSiteEnergy.

Als je meer flexibiliteit nodig hebt, kun je Get-SolarEdgeSiteEnergy rechtstreeks gebruiken en het resultaat door een pipeline halen, bv.

code:

PS> Get-SolarEdgeSiteEnergy args | Select-Object -ExpandProperty siteEnergy | Select-Object -ExpandProperty values | ConvertTo-Csv

Als je ook meter data nodig hebt, kun je Get-SolarEdgeSiteEnergyDetails gebruiken. De pipeline ziet er dan uiteraard anders uit.

[ramonp]

MantsjeKlaas schreef op woensdag 26 maart 2025 @ 16:38:
Draai al sinds 2018 met SE-LOGGER en nog geen problemen gehad. Maar sinds gisteren krijg ik geen nieuwe dat meer in de MYSQL database. De .pcap file wordt wel elke minute geupdate. Verder heb ik in de liveupdate.log file de volgende melding: Warning! Got 78 mysterious bytes left! (state=0)
68 eb 6d 93 49 30 f3 cc 8f 53 f4 57 b9 6c 39 71 ee 0b 12 61 32 85 b1 a8 a2 14 49 90 74 16 b4 4a 50 3b 58 a4 90 17 7b d7 4a 02 88 21 4a 14 02 3f b8 f0 22 f0 95 1b ce 76 42 61 27 82 c6 3d f5 18 4f 81 c0 0c dd b0 06 5f f0 a6 04 be 9f 21.

Is er iemand die mij kan vertellen wat er aan de hand is en wat ik hier aan kan doen?

Ik heb dit probleem ook sinds vandaag. Sinds 2018 geen problemen gehad tot vandaag.

Ik heb gekeken of ik niet een nieuwe encryptie key heb ontvangen, maar die wordt niet gevonden in de pcap files.

Iemand hier een oplossing voor?

Door de netwerkkabel van de omvormer er even uit te halen en weer terug te steken werkt het weer bij mij.

[ Voor 5% gewijzigd door ramonp op 02-11-2025 13:32 . Reden: probleem opgelost ]

[Jerrythafast]

Krijgen jullie wel nog "Setting new 0503 key"? Dan is er nog hoop en lijkt het erop dat ze er puur weer een extra laagje obfuscation overheen hebben gelegd. De uitdaging is dan om van die reeks bytes weer een herkenbaar SolarEdge-berichtje te maken, dus een die begint met 12 34 56 79. Ik neem daarbij even aan dat er geen "Warning! Checksum failure, skipping over barker..." boven staat, anders is er wat anders aan de hand.

Maar het zou ook goed kunnen (zeker als er geen vermelding van 0503 key meer in de log file komt) dat het geen nieuw laagje over het oude protocol is maar iets compleet nieuws dat opnieuw ge-reverse-engineered zal moeten worden.

Ik heb zelf geen SolarEdge meer, dus ik zal het helaas niet meer kunnen uitpluizen...