[SolarEdge] Omvormers en optimizers zelf monitoren

[Aegle]

stormfly schreef op woensdag 12 april 2023 @ 12:27:
[...]


Hmm nee helaas, denk toch dat het te maken heeft met welke omvormer je hebt.

Dit is de url waar ik binnen kom: https://monitoring.solaredge.com/

Ik heb een SE3000 (met LCD-scherm) uit het jaar kruik, maar ook ik kan in de portal gewoon kiezen tussen de oude en nieuwe web-interface…

@Jerrythafast: jou monitoring tool uit hetzelfde jaar kruik draait hier nog steeds. Zonder ook maar één interupt

* Aegle klopt nu aan de onderzijde van een blank stuk hout…

[ Voor 19% gewijzigd door Aegle op 30-04-2023 17:28 ]

[stormfly]

Aegle schreef op zondag 30 april 2023 @ 16:50:
[...]

Ik heb een SE3000 (met LCD-scherm) uit het jaar kruik, maar ook ik kan in de portal gewoon kiezen tussen de oude en nieuwe web-interface…

Log je dan in met jouw installer account of met een klant account?

[Jerrythafast]

Gwaihir schreef op zondag 30 april 2023 @ 13:51:
[...]

Ik herinner me iets van mits je er vanaf het begin op bedacht bent. Heb het destijds zitten lezen (een flink eind terug in ditzelfde topic, dacht ik), maar vond het teveel gedoe. Iets met vanaf de allereerste start door een proxy heen trekken én de keys die dan uitgewisseld worden opvangen. Dan zou je met succes op die proxy mee kunnen blijven luisteren.

Dat was inderdaad hoe het vroeger kon, zo heb ik het in de topicstart ook beschreven. Bij mijn weten is dat met nieuwe installaties nu niet meer mogelijk.

Misschien heeft de topicstart weer eens een flinke update nodig. Nu staat daar een methode in die eigenijk niet meer relevant is. Uit de berichten van dit weekend blijkt wel dat er nu voor elke nog werkende optie wel voors en tegens zijn (benodigde hardware, nog kunnen gebruiken van monitoring portaal, ontvangen van optimizer data, gedoe met reverse engineering). Het is jammer dat er geen tweakblogs meer zijn

[eriksl]

Ja dat lijkt me een goed plan. Ik zal tzt mijn bevindingen delen.

[Gwaihir]

Jerrythafast schreef op zondag 30 april 2023 @ 21:25:
Dat was inderdaad hoe het vroeger kon, zo heb ik het in de topicstart ook beschreven. Bij mijn weten is dat met nieuwe installaties nu niet meer mogelijk.

Deels. In je topicstart heb je het over het afluisteren van een op dat moment nog onbeveiligde verbinding. Door er een volledige proxy tussen te knutselen maak je jezelf ook echt 'man in the middle' in de SSL verbinding. Het lijkt me dat de omvormer dan moet constateren dat geen geldige SSL verbinding mogelijk is (certificaat klopt niet). Hoe iemand daar exact omheen ging / wilde, werd me te ingewikkeld om verder te bestuderen..

(Is er nog blind vertrouwen omdat nog niet alles is binnengehaald m.b.t. de certificaten? Is die check niet waterdicht op zo'n 'simpel' device? Wordt je geacht dankzij de volledige controle over je netwerksetup het IP adres van Solaredge te spoofen met je proxy? Etc. Ik weet het niet meer en ik weet ook niet of ik iemands zelf-overtuigde plan van aanpak las, of iets wat met succes gedaan is. Ik ben gestopt op gaat mij te ver..)

[ocaj]

Is het probleem niet dat je met de nieuwe SetApp-omvormers het ding activeert via de SetApp-app op de telefoon van de installateur? Dan kun je nog zoveel proxies in je eigen netwerk hebben zitten, maar als de communicatie via de 4/5G van de telefoon van de installateur loopt, dan zit je toch al niet meer "tussen" de communicatie?

[Kees-Jan]

ocaj schreef op maandag 1 mei 2023 @ 14:51:
Is het probleem niet dat je met de nieuwe SetApp-omvormers het ding activeert via de SetApp-app op de telefoon van de installateur? Dan kun je nog zoveel proxies in je eigen netwerk hebben zitten, maar als de communicatie via de 4/5G van de telefoon van de installateur loopt, dan zit je toch al niet meer "tussen" de communicatie?

Nee, die kan je zelf installeren: https://play.google.com/store/search?q=setapp&c=apps
Is puur voor de instellingen voor NL en het pairen van de optimizers...

[eriksl]

Gwaihir schreef op maandag 1 mei 2023 @ 11:34:
Deels. In je topicstart heb je het over het afluisteren van een op dat moment nog onbeveiligde verbinding. Door er een volledige proxy tussen te knutselen maak je jezelf ook echt 'man in the middle' in de SSL verbinding. Het lijkt me dat de omvormer dan moet constateren dat geen geldige SSL verbinding mogelijk is (certificaat klopt niet). Hoe iemand daar exact omheen ging / wilde, werd me te ingewikkeld om verder te bestuderen..
[/message]

Er zijn op zich manieren om een transparante proxy te maken, de client ziet dan niet dat z'n verkeer geredirect wordt. Als de client een DNS resolve doet, is dat echter niet nodig, dan kun je 'm naar je eigen server laten wijzen. In beide gevallen loop je tegen hetzelfde uitdaging aan, de client laten geloven dat er niemand meeluistert. Ervan uitgaande dat er TLS (https) gebruikt wordt, dan zal de client altijd het certificaat controleren. En als je geen invloed hebt op de set van vertrouwde root certificaten op de client, kun je op geen enkele manier de communicatie afluisteren (dat is ook het hele idee van TLS...). Als er initieel geen TLS gebruikt wordt, dan zijn er wel mogelijkheden natuurlijk

[eriksl]

ocaj schreef op maandag 1 mei 2023 @ 14:51:
Is het probleem niet dat je met de nieuwe SetApp-omvormers het ding activeert via de SetApp-app op de telefoon van de installateur? Dan kun je nog zoveel proxies in je eigen netwerk hebben zitten, maar als de communicatie via de 4/5G van de telefoon van de installateur loopt, dan zit je toch al niet meer "tussen" de communicatie?

Ik lees net dat de "SetApp" converters tijdelijk een eigen SSID maken (ingebouwd access point) waar je met je telefoon op kunt associeren. Dat kan dan zonder dat je verbinding maakt met internet (via ethernet of GSM data). Op zich wel mooi, maar een schermpje had ik ook wel fijn gevonden.

[Gwaihir]

eriksl schreef op maandag 1 mei 2023 @ 18:23:
Ik lees net dat de "SetApp" converters tijdelijk een eigen SSID maken (ingebouwd access point) waar je met je telefoon op kunt associeren. Dat kan dan zonder dat je verbinding maakt met internet (via ethernet of GSM data). Op zich wel mooi, maar een schermpje had ik ook wel fijn gevonden.

Ach, het is op zich best elegant. De weergave en interactiemogelijkheden zijn via zo'n app toch beter dan via 'n klein monochroom schermpje met 'n paar knopjes ernaast. Tevens scheelt het SE die paar onderdeeltjes (WiFi zit er toch in) én geeft het, als ik me niet vergis, de toch wel toffe mogelijkheid firmware te updaten (die je daartoe eerst naar die telefoon downloadt).

[eriksl]

Nou het voordeel van een schermpje vind ik toch wel dat je zonder enig gedoe altijd even snel kunt kijken. Ik hoop niet dat je dat SSID continu nodig hebt voor de SetApp, want ik heb hier in huis al access points, SSID's en kanalen genoeg in gebruik, dat zou ik een beetje zonde t.o.v. de buren. Grote kans dat het wel zonder eigen SSID werkt, maar dan alleen als je verbindt met het portaal en dát wil ik nou juist weer niet.

Ik weet uit eigen ervaring dat als je een microcontroller hebt met een SPI module (wat meestal wel het geval is) dat je voor vijf euro (20x4 alfanumeriek), 15 euro (klein grafisch kleuren-schermpje) of 35 euro (groot grafisch kleuren-scherm) klaar kunt zijn. Voor 2,50 heb je een heel klein grafisch monochroom OLED schermpje, heeft op zich ook wel wat, kun je aansturen met I2C als je geen SPI hebt. Genoeg ruimte om de belangrijkste info op te zetten.

[Gwaihir]

eriksl schreef op dinsdag 2 mei 2023 @ 09:48:
Nou het voordeel van een schermpje vind ik toch wel dat je zonder enig gedoe altijd even snel kunt kijken.

Waarnaar zou je willen kijken dan, nadat e.e.a. eenmaal is ingesteld?

Ik hoop niet dat je dat SSID continu nodig hebt voor de SetApp, want ik heb hier in huis al access points, SSID's en kanalen genoeg in gebruik, dat zou ik een beetje zonde t.o.v. de buren. Grote kans dat het wel zonder eigen SSID werkt, maar dan alleen als je verbindt met het portaal en dát wil ik nou juist weer niet.

Het SSID voor SetApp moet je specifiek aanzetten en de omvormer is dan ook niet in (normaal) bedrijf. Dan heb je het dus over enkele minuten in z'n vele jaren levensduur.

Het is dus wél altijd een eigen SSID en de omvormer is op dat moment géén client in jouw huis-netwerk, noch verbonden met 'de portal'.

Overigens denk ik dat je nieuwsgierigheid over dit soort zaken zich beter laat bevredigen via de handleiding dan slow chat in dit topic. Je weet al exact wat er gaat komen, toch, en wil die vast toch gaan lezen?

[golfgti5]

Hallo,

Ik krijg een zonnepanelen uitbreiding met dus een 2e omvormer.
Kan je die 2e omvormer ook in de solaredge app zien, de opbrengst ervan, of moet je een 2e account aanmaken en steeds switchen in die app?

[victorclaessen]

Als die tweede omvormer in dezelfde site wordt geplaatst dan krijg je ze beide te zien in de app onder hetzelfde account.

[Stefannn]

@Jerrythafast
Kleine update mbt onderstaande.
- ik monitor nog steeds met de “overview” api call.
- ik heb de “inventory” api call wel netjes uitgewerkt en al een paar keer handmatig in de browser gepast. Dat werkt prima.
- timestamp van de overview call is duidelijk disconnected van de data-collect, timestamp is netjes elke 5 minuten terwijl data-collect soms meer dan een half uur achterloopt.
- timestamp van de “inventory” api call is ANDERS dan de timestamp van de “overview” call zelfs als de data die beide calls uitspuwen hetzelfde is

Echter… ik heb nog niet kunnen testen of de “inventory” call beter werkt. Want…. De laatste 2 weken doet de “overview” call het eigenlijk gewoon weer. Vrijwel geen timegaps meer.

@Jerrythafast geeft aan dat de “inventory” call geen timegaps had, maar ja… dat kan (voor zover ik dat kan beoordelen) dus ook toeval zijn, de “overview” heeft het nu ook niet.
Mijn sterk vermoeden is dat de timegaps veroorzaakt worden doordat de omvormer de upload naar de portal niet doet. Als de data daar niet staat dan gaat geen enkele api call die data er af kunnen halen.
De “overview” call heeft duidelijk een bug (of super raar bedoeld gedrag) in de zin dat timestamp en data disconnected zijn.
De “inventory” call heeft die connectie wellicht beter, maar ik vrees dat data die niet is geüpload er dan nog steeds niet is. Of het echt beter is weet ik niet zeker omdat de timegaps verdwenen tijdens mijn onderzoek ernaar.

Totdat het weer een probleem wordt ga ik hier even niet mee verder. Om dit helemaal goed uit te zoeken zou ik het huidige script op de “overview” call moeten uitbreiden met een retry op de “inventory” call (stomweg dubbel aanroepen loopt immers snel tegen de 300/dag grens aan). Dat is een beetje veel debuggen voor iets dat al werkt.
De “inventory” als vervanging van de “overview” heeft als nadeel dat de “inventory” alleen de totale productie geeft en niet de productie van de lopende dag. Om die te krijgen moet je dan ook weer extra werk doen.

Even gesloten dus.

En met als toch wel aardige conclusie: “data van de Solaredge portal komt weer met nette 5 minuten intervals”

Stefannn schreef op zondag 23 april 2023 @ 12:30:
[...]


Letterlijke regel van mijn php script:
curl_setopt($ch, CURLOPT_URL, 'https://monitoringapi.solaredge.com/site/999999/overview.json'.$solaredgekey);

met in de 999999 & $solaredgekey de gegevens van mijn installatie.

Mhhh... betreffende call zou ik kunnen proberen.
Had ik origineel niet gedaan omdat het "stomweg meer data is" die ik niet nodig heb.
De hamvraag is of de timestamp dan correct is. --> het maffe aan de overview-call is defacto dat de timestamp disconnected van de data is.
Ik vrees een beetje dat de data zelf dezelfde gaps vertoont. Het lijkt me dat die gaps veroorzaakt worden door de uploads van inverter naar portal. Maar goed... daar kom je natuurlijk alleen achter door te testen.

Ik ben nu met een laadpaal bezig. Ik heb nu een solaredge script dat "redelijk functioneert". Op termijn wil ik de solar informatie gebruiken om mijn laadpaal te besturen maar op dit moment is het "puur voor de gui".

Kortom: dank voor de tip. Ga ik ZEKER testen. Maar zal een poosje duren voor ik daar weer in ga duiken.

[Aegle]

stormfly schreef op zondag 30 april 2023 @ 19:12:
[...]


Log je dan in met jouw installer account of met een klant account?

Installer / admin account. Zie screenshot.



Ik heb de installatie zelf gedaan. De panelen heb ik samen met een andere tweaker gedaan. Ik heb zelf het systeem ontworpen, de materialen uitgezocht en ingekocht. Gewoon als particulier .
SolarEdge deed toentertijd (2013/2014) helemaal niet moeilijk. Tegenwoordig is het blijkbaar allemaal wat lastiger…

[golfgti5]

victorclaessen schreef op zaterdag 6 mei 2023 @ 15:16:
Als die tweede omvormer in dezelfde site wordt geplaatst dan krijg je ze beide te zien in de app onder hetzelfde account.

Inloggen op de site?
Via app niet mogelijk?

[victorclaessen]

'Site' als in 'installatieplaats', niet als in 'website'.

[golfgti5]

victorclaessen schreef op zondag 14 mei 2023 @ 21:38:
'Site' als in 'installatieplaats', niet als in 'website'.

Sorry ik kan het even niet volgen, kan je mij wat op weg helpen?

[Stefannn]

golfgti5 schreef op zondag 14 mei 2023 @ 22:21:
[...]


Sorry ik kan het even niet volgen, kan je mij wat op weg helpen?

Hij bedoelt: “als ze beiden op hetzelfde fysieke adres (site als fysieke bouwplaats) geplaatst worden” dan zijn ze beiden in hetzelfde account aanwezig.
Kortom…
Het ligt aan de installateur.
Of hij een nieuw account (bijvoorbeeld onder naam van partner) heeft aangemaakt of toegevoegd aan bestaand account.

[golfgti5]

Stefannn schreef op zondag 14 mei 2023 @ 23:20:
[...]


Hij bedoelt: “als ze beiden op hetzelfde fysieke adres (site als fysieke bouwplaats) geplaatst worden” dan zijn ze beiden in hetzelfde account aanwezig.
Kortom…
Het ligt aan de installateur.
Of hij een nieuw account (bijvoorbeeld onder naam van partner) heeft aangemaakt of toegevoegd aan bestaand account.

Het betrefd een andere instalateur, dus ik vrees dat die een eigen portal aan gaat maken…..benieuwd hoe ik dan beide in 1 app zichtbaar ga krijgen

[victorclaessen]

(Ik hoop dat de overige topiclezers en eventuele moderators mij zullen vergeven. Dit lijkt een beetje offtopic voor dit topic, maar ik wil je ook niet zonder antwoord laten hangen.)

Het zou sowieso moeten lukken om beide installaties in dezelfde app zichtbaar te maken. Als je nu account 1 hebt van installateur A waarin je site EEN, en een nieuwe installateur B maakt voor de nieuwe installatie een nieuwe site TWEE aan, dan zou je B kunnen vragen of hij account 1 inzage wil geven in site TWEE. Dan komt site TWEE ook beschikbaar in de app, naast de bestaande site EEN. Dit zijn dan twee losse installaties, en er wordt dus geen totaalplaatje berekend (voor zover mij bekend).

Als je in één oogopslag de som van beide installaties wilt zien dan moet je waarschijnlijk vragen of installateur A site EEN wil openstellen voor administratie door installateur B, zodat deze de nieuwe omvormer in site EEN kan plaatsen. Als beide omvormers in site EEN staan, dan krijg je gelijk een totaalplaatje te zien. Dat lijkt me het mooist, maar vereist wellicht enige afstemming tussen beide installateurs.

Eigen ervaring: Ik heb (als zelf-installateur) in drie stadia omvormers aan mijn eigen site toegevoegd, en die zijn allemaal in de app verschenen. Daarnaast heb ik een collega inzage gegeven in mijn site, en hij kan nu in zijn app - naast zijn eigen site - nu ook mijn site zien. Ik geloof niet dat hij een totaalplaatje van beide sites opgeteld ziet.

Wellicht ten overvloede: met site bedoel ik dus een Solaredge installatie op één locatie. Als je in de app via het menu kiest voor Site Details, dan zie je hopelijk wat ik bedoel. Een site heeft een numeriek ID en een naam (en een adres etc.) en kan meerdere omvormers omvatten. Dat laatste moet dan wel zo ingesteld worden. Als je het administratief niet voor elkaar krijgt tussen de installateurs, dan zul je wellicht eindigen met twee omvormers in elk een eigen logische site (ook al zijn ze fysiek op hetzelfde postadres present). Dan kun je ze dus wel beide inzien, maar niet opgeteld.

[golfgti5]

victorclaessen schreef op dinsdag 16 mei 2023 @ 19:42:
(Ik hoop dat de overige topiclezers en eventuele moderators mij zullen vergeven. Dit lijkt een beetje offtopic voor dit topic, maar ik wil je ook niet zonder antwoord laten hangen.)

Het zou sowieso moeten lukken om beide installaties in dezelfde app zichtbaar te maken. Als je nu account 1 hebt van installateur A waarin je site EEN, en een nieuwe installateur B maakt voor de nieuwe installatie een nieuwe site TWEE aan, dan zou je B kunnen vragen of hij account 1 inzage wil geven in site TWEE. Dan komt site TWEE ook beschikbaar in de app, naast de bestaande site EEN. Dit zijn dan twee losse installaties, en er wordt dus geen totaalplaatje berekend (voor zover mij bekend).

Als je in één oogopslag de som van beide installaties wilt zien dan moet je waarschijnlijk vragen of installateur A site EEN wil openstellen voor administratie door installateur B, zodat deze de nieuwe omvormer in site EEN kan plaatsen. Als beide omvormers in site EEN staan, dan krijg je gelijk een totaalplaatje te zien. Dat lijkt me het mooist, maar vereist wellicht enige afstemming tussen beide installateurs.

Eigen ervaring: Ik heb (als zelf-installateur) in drie stadia omvormers aan mijn eigen site toegevoegd, en die zijn allemaal in de app verschenen. Daarnaast heb ik een collega inzage gegeven in mijn site, en hij kan nu in zijn app - naast zijn eigen site - nu ook mijn site zien. Ik geloof niet dat hij een totaalplaatje van beide sites opgeteld ziet.

Wellicht ten overvloede: met site bedoel ik dus een Solaredge installatie op één locatie. Als je in de app via het menu kiest voor Site Details, dan zie je hopelijk wat ik bedoel. Een site heeft een numeriek ID en een naam (en een adres etc.) en kan meerdere omvormers omvatten. Dat laatste moet dan wel zo ingesteld worden. Als je het administratief niet voor elkaar krijgt tussen de installateurs, dan zul je wellicht eindigen met twee omvormers in elk een eigen logische site (ook al zijn ze fysiek op hetzelfde postadres present). Dan kun je ze dus wel beide inzien, maar niet opgeteld.

Bijzonder bedankt voor je duidelijke uitleg, word gewaardeerd👍🏻

[tinka]

ik zie het volgende in mijn pvo-upload.log

PVOutput error 400, exiting: Bad request 400: Invalid future date [20440105]

voorbij komen. Heeft iemand een idee wat dit kan zijn?

[eriksl]

Nou het is dan zover, de zonnepanelen liggen er, de inverter is geplaatst (SolarEdge SE3680).

Vanaf het begin heel goed opgelet dat de inverter nooit toegang had tot internet, om uitwisselen van sleutels te voorkomen. Dat heeft uiteindelijk helemaal geen zin gehad, want het blijkt dat de nieuwe(re) firmware allemaal met SSL/TLS communiceren, daar kan semonitor dus helemaal niet tussen gaan zitten. Er wordt niks meer met plaintext/prod.solaredge.com gedaan.

Volgende stap: RS485. UTP kabel aan de RS485 aangesloten, oranje = A+, oranje-wit = B-, de rest van de aders = ground. RS485 als slave actief gemaakt, semonitor gestart. Ik zie nu berichten heen en weer gaan, maar:

- het gaat heel langzaam (er komt maar eens per minuut ofzo echt iets aan data terug)
- ik krijg heel oude gegevens (van dagen terug)
- veel "master ack timeouts"

Dan zou je bijna zeggen dat er toch iets niet helemaal goed gaat met de communicatie. Ik heb al twee verschillende converters geprobeerd (USB en RS232) en dat maakt niet uit. Op een van de twee kan ik terminatie aanzetten (120 Ohm), dat gedaan en maakt ook niet uit. Kabellengte ingekort van 12 meter naar 1 meter en dan maakt ook al niet uit. Rara...

[ocaj]

Dat er soms even geen data komt en dan weer een hele bulk is vrij normaal, zeker als je niet "bij" bent.
De omvormer onthoudt welke data er nog niet gecommuniceerd is en vergeet de data pas zodra de semonitor-master ontvangst bevestigd heeft.
Vrij robuust protocol dus en je begint met de oudste data.

Overigens herinner ik me dat er bij mij toen ik nieuwe omvormers kreeg iets niet helemaal lekker liep, maar dat zat meer in de gegenereerde json-berichten. zie: https://github.com/jbuehl/solaredge/issues/166
Zodra de initiële berichten er doorheen waren heb ik zoiets niet meer gezien.

Update: Je zegt RS485-slave. Ik weet niet hoe het tegenwoordig heet, maar je moet dus geen Modbus gebruiken, maar "Solaredge-follower" (vooheen: Solaredge-slave).

[ Voor 12% gewijzigd door ocaj op 26-05-2023 17:22 ]

[eriksl]

Ja die issue had ik ook ("NaN" snapt-ie niet), maar dat had ik snel gefixt :-)

Waar ik me vooral zorgen over maak is toch wel regelmatig "master ack timeouts" en "message too large" (wat volgens mij suggereert dat er corruptie is).

Ik hoor net van jbuehl dat het op zich normaal is dat het langzaam gaat en dat je een hele berg eerst moet inhalen. Ik hoop dan maar wel dat het op een gegeven moment wel net snel genoeg gaat dat er ook echt ingehaald gaat worden, want het gaat nu wel heel erg langzaam. Hij is nu bij 23 mei

Update: ja de meeste docs noemen het (nog) slave, dat is tegenwoordig niet meer PC, dus SE is kennelijk overgestapt naar "leader" en "follower". Ik heb de inverter dus uiteraard op "follower" staan.

[ Voor 17% gewijzigd door eriksl op 26-05-2023 18:43 ]

[ocaj]

Bij mijn vorige omvormer had ik ook regelmatig "Master Ack timeouts", als hij er meer dan een paar achter elkaar heeft dan raakt de hele boel in de war en kwam het bij mij niet meer goed. Ik heb toen zelf een watchdog gemaakt die na 10 keer communicatie zonder antwoord ik de semonitor-service herstart. Dan deed hij het weer.
Mijn huidige omvormer heeft er geen last van. Doorgaans draait het script de hele dag en data is tamelijk actueel.

Misschien toch een bedradings-issue? Ik heb maar 1 draadje voor de ground, kan het komen doordat je alle overige draadjes als ground gebruikt? Heb je de termination in de omvormer (dipswitch) aan of uit staan?
Zou voor een korte kabel niet echt uit moeten maken, maar je zou eens kunnen experimenteren met die instelling.
Of eventueel een andere RS485-adapter, die zijn soms wat kieskeurig?

[eriksl]

Hmmm, interesting. Die meerdere ground aders kan het volgens mij niet aan liggen. Ik heb nu termination aan staan op de interface (computer-kant), maar heeft de omvormer die ook dan? Ik kan me niet herinneren dat ik daar iets van gezien heb eerlijk gezegd. Ik ga eens even kijken of RS485 aan een of twee kanten getermineerd moet worden. Zou geweldig zijn als dit het probleem is (en zo op te lossen is...)

[eriksl]

Het lijkt er op (na wat googlen) dat de SolarEdge (sommige?) een dipswitch hebben voor termination. Ik ga daar morgen eens naar kijken. Zoniet, dan gooi ik zelf even een 120 Ohm weerstand over A en B, kijken of dat uitmaakt.

[eriksl]

nwmakel schreef op dinsdag 19 mei 2020 @ 10:23:
Het SSL verkeer tussen omvormer en prodssl.solaredge.com is makkelijk af te vangen en ontsleutelen. Er wordt geen certificate pinning gebruikt.

Mijn huidige workflow is:

- self signed ca cert en key aangemaakt
- self signed cert toegevoegd aan /etc/ssl/certs/ca-certificates.crt
- verkeer van de omvormer op poort 443 afvangen en redirecten naar machine met sslsplit op poort 8080
- sslsplit -S /tmp/log/ -k /tmp/ca.pem ssl 0.0.0.0 8080
- De .log bestanden die hier uit komen kun je voeren aan https://github.com/jbuehl/solaredge/

Data zoals je gewend bent uit semonitor.py, waaronder omvormer statistieken:

"ABC123ABC": {"Date": "2020-05-19", "Eac": 123.0, "Eday": 123.123123, "Etot": 123.0, "Freq": 49.123, "ID": "ABC123ABC", "Iac": 7.123, "Interval": 300, "Pac": 123.123, "Pmax": 11000.0, "Temp": 46.123, "Time": "10:07:30", "Uptime": 1666, "Vac": 240.123, "Vdc": 383.123}

En optimizer telemetry:

"123ABC123": {"Date": "2020-05-19", "Eday": 123.5, "ID": "123ABC123", "Imod": 8.123, "Inverter": 0, "Temp": 46.0, "Time": "09:58:42", "Uptime": 14123, "Vmod": 29.0, "Vopt": 52.375}

Deze had ik nog niet gezien, geweldig nieuws! Ik neem aan dat dit nog steeds werkt?
*EDIT* kennelijk niet, want ik krijg "unknown CA" errors vanuit de omvormer. Wat een rotstreek!
672 856.127463818 172.17.42.2 → 167.94.110.2 TLSv1.3 73 Alert (Level: Fatal, Description: Unknown CA)

[ Voor 6% gewijzigd door eriksl op 27-05-2023 14:30 ]

[eriksl]

En weet toevallig iemand wat "Eac" is?

[eriksl]

Ik ben intussen het volgende wijs geworden over de SE3680H

- communicatie met SolarEdge gaat alleen over TLS (SSL), niks cleartext of met sleutels dus
- de inverter checkt de signer van het certificaat t.o.v. van een ingebouwde lijst, dus sslsplit werkt ook niet
- semonitor via rs485 werkt, maar niet heel erg goed, veel fouten en hertransmissies, het lijkt er op dat het protocol recent enigszins aangepast is, maar je krijgt er op een gegeven moment wel aardig wat data uit
- als je kan leven zonder de informatie van de optimisers, dan is is het echt het allerbest om de tcp modbus port open te zetten daar je informatie uit te halen. Dat werkt snel (meteen) en betrouwbaar. Dit in tegenstelling tot de semonitor records, waar je maar moet afwachten wanneer er iets binnenkomt.

Misschien zou de API van SolarEdge nog een optie kunnen zijn, maar dan heb je een restrictie van max eens per vijf minuten update en volgens mij heb je dan nog steeds geen info van de optimisers.

Die van mij draait nu lekker internet-loos :-)

[Lox-1]

Goedemiddag,

Sinds kort in het bezit van een SolarEdge Se3000H HD Wave met 8 panelen. Deze lees ik tbv domotica (Loxone) uit via modbus over TCP. Data komt netjes actueel door, maar.....

Nu merk ik dat wanneer de vermogens erg laag zijn in de ochtend en avond dat de I-AC-Power (AC Power value) op IO-adres 40083 een factor 10 hoger gaat aangeven. Op papier leuk dat er met weinig zon meer opbrengst is, maar het klopt niet.

Iemand enig idee wat daar de oorzaak van kan zijn en hoe ik dat kan aanpassen?

[eriksl]

Lijkt me een bug Loxone dan (of in ieder geval met datgene wat je gebruikt voor het uitlezen middels modbus). Bij mij is het uitlezen middels modbus juist een van de weinige dingen die wél echt vlekkeloos gaat. Ik heb een bestaand programma (ik weet niet meer of het Python of Perl was) als basis genomen en dat gecombineerd met een modbus library in Perl en dat werkt gewoon echt goed. Waar het bij jouw programma misschien misgaat is dat de inverter bij elke waarde (of groep van waardes) ook een scaling factor geeft (10^x). Als dat programma de verkeerde scaling factor gebruikt (van een andere waarde) of die maar eenmalig ophaalt in plaats van ze elke keer op te halen, dan kan ik me voorstellen dat je dit krijgt.

[eriksl]

Ik heb intussen nog een paar dingen ontdekt:
- ook als de monitoring via RS485 gaat, dan nog neemt de inverter af en toe contact op met SolarEdge servers. Ik vermoed voor het uitwisselen van alerts en voor notificaties voor nieuwe firmware. Er wordt dan geen opbrengst-data verzonden (wat klopt met wat beschreven is).
- de courante fw versie van SE3680HD (misschien anderen ook wel) heeft een implementatie van het RS485 protocol wat net iets anders is dan wat gebruikt wordt in semonitor.py. Ik heb gemerkt dat als je het wachten op de master grant acknowledge overslaat, dat je geen ack timeouts meer krijgt (...) maar dat het dan ook veel vloeiender loopt. Kennelijk wordt de grant request tegenwoordig niet meer ge-ackt, ook weinig zinvol om er dan op te wachten. Ik ga nog proberen die grant request messages helemaal niet te versturen. Kijken of je dan nog steeds opbrengst berichten krijgt, zou me eerlijk gezegd niet verbazen. Wordt het wel lekker simpel...

[Lox-1]

eriksl schreef op dinsdag 6 juni 2023 @ 16:05:
..... Waar het bij jouw programma misschien misgaat is dat de inverter bij elke waarde (of groep van waardes) ook een scaling factor geeft (10^x). ....

Mijn verwachting was dat de SolarEdge met I_AC_Power de waarde doorgeeft van het vermogen dat op dat moment voor de huisinstallatie / grid beschikbaar komt en dat daar verder geen scaling factor meer op los hoeft te worden gelaten. Is deze aanname niet juist?

Ik vraag ook de I_AC_Power_SF op en die wisselt wel een beetje gedurende de dag dus dit zou een oplossing kunnen bieden. Zou de formule dan: Werkelijk beschikbaar vermogen =I_AC_Power * 10^I_AC_Power_SF moeten zijn?

Ik merk dat ik met I_AC_Voltage AB * I_AC_Current het vermogen redelijk goed benader en de extreme afwijking bij de lage vermogens niet heb. Deze waarde ligt vanaf ongeveer 300W opbrengst over het algemeen net iets hoger, maar de I_AC_Voltage AB is ook net een paar V hoger dan dat ik in de installatie meet.

[Gwaihir]

Lox-1 schreef op woensdag 7 juni 2023 @ 10:23:
Mijn verwachting was dat de SolarEdge met I_AC_Power de waarde doorgeeft van het vermogen dat op dat moment voor de huisinstallatie / grid beschikbaar komt en dat daar verder geen scaling factor meer op los hoeft te worden gelaten. Is deze aanname niet juist?

Klopt: aanname inderdaad niet juist.

Ik vraag ook de I_AC_Power_SF op en die wisselt wel een beetje gedurende de dag dus dit zou een oplossing kunnen bieden.

Yep, dat is de actuele scaling factor. Die moet je dus wel toepassen.

Zou de formule dan: Werkelijk beschikbaar vermogen =I_AC_Power * 10^I_AC_Power_SF moeten zijn?

Ja, zoiets. Ik heb I_AC_Power * 10^(I_AC_Power_SF - 3)

Daarbij:
- geen schaling op de AI
- geeft output in kW, want dat lijkt de energiemonitor fijn te vinden
- verwacht niet dat 't uitmaakt, maar da's nog wel de oude energiemonitor. (Ik moet 'm nog converteren naar die van config versie 13+.)

Ik merk dat ik met I_AC_Voltage AB * I_AC_Current het vermogen redelijk goed benader en de extreme afwijking bij de lage vermogens niet heb. Deze waarde ligt vanaf ongeveer 300W opbrengst over het algemeen net iets hoger, maar de I_AC_Voltage AB is ook net een paar V hoger dan dat ik in de installatie meet.

Wellicht. Ik heb 'n drie fase omvormer, dus daar ga ik maar niet mee aan de slag.

[Tjeerd]

Svrooij86 schreef op donderdag 2 november 2017 @ 21:48:
Iets heel anders, volgens mij gaat dit hele Topic over het afluisteren van de verbinding tussen de omvormer en de monitoring portal, toch?

Volgens de handleiding https://www.solaredge.com...-technical-note.pdf#page4 kan je schijnbaar ook modbus over tcp aanzetten en als ik het goed begrijp heb je dan hetzelfde als dat je een seriële kabel zou aansluiten, maar dan op je eigen netwerk.

Is het een idee om dit ook eens te bekijken. Want in dat geval zou je na het activeren van deze optie (staat standaard uit) gewoon alles realtime kunnen uitlezen vanaf een computer in je netwerk, zonder dat je iets aan de portal verbinding hoeft te wijzigen en zonder dat je omvormer open moet

Een wat ouder bericht waar ik nog niet echt duidelijk het antwoord op kan vinden. Als je het modbus over TCP zou gebruiken, dan is het wat beperkt qua specificaties (SunSpec) wat je dan zou kunnen uitlezen, begrijp ik uit reacties.

Ik heb zelf een SolarEdge SE3000H-omvormer die via WiFi verbonden is en lees her en der voorbeelden waarbij je met de niet-LCD-variant iets van modbus-tcp kan aanzetten door de omvormer in een eigen wifi-stand te zetten zodat je hem zou kunnen benaderen en instellen.

Het lijkt er op dat dit niet mogelijk is allemaal in mijn SE3000H-omvormer, maar helemaal zeker weet ik het nog niet. Ook de SetApp accepteert mijn serienummer niet. Ik zie wel dat mijn omvormer een IP-adres heeft waar ik naar kan pingen, maar waarschijnlijk is dat puur om zijn eigen meetgegevens naar het SolarEdge-portaal te versturen.

Begrijp ik het dan goed dat mijn omvormer dan eigenlijk misschien alleen maar uit te lezen zou zijn via methodes zoals beschreven in het openingsbericht van dit onderwerp, dus op de seriële manier?

En de andere vraag: indien je wel modbus-tcp "aan" kunt zetten op je omvormer, kun je dan via de ingebouwde WiFi-module er bij komen om die modbus-gegevens uit te lezen?

[ Voor 6% gewijzigd door Tjeerd op 10-06-2023 21:50 ]

[RobertMe]

Tjeerd schreef op zaterdag 10 juni 2023 @ 17:34:
[...]
Een wat ouder bericht waar ik nog niet echt duidelijk het antwoord op kan vinden. Als je het modbus over TCP zou gebruiken, dan is het wat beperkt qua specificaties (SunSpec) wat je dan zou kunnen uitlezen, begrijp ik uit reacties.

Ik heb zelf een SolarEdge SE3000H- omvormer die via WiFi verbonden is en lees her en der voorbeelden waarbij je met de niet-LCD-variant iets van modbus-tcp kan aanzetten door de omvormer in een eigen wifi-stand te zetten zodat je hem zou kunnen benaderen en instellen.

Het lijkt er op dat dit niet mogelijk is allemaal in mijn SE3000H-omvormer, maar helemaal zeker weet ik het nog niet. Ook de SetApp accepteert mijn serienummer niet. Ik zie wel dat mijn omvormer een IP-adres heeft waar ik naar kan pingen, maar waarschijnlijk is dat puur om zijn eigen meetgegevens naar het SolarEdge-portaal te versturen.

Begrijp ik het dan goed dat mijn omvormer dan eigenlijk misschien alleen maar uit te lezen zou zijn via methodes zoals beschreven in het openingsbericht van dit onderwerp, dus op de seriële manier?

En de andere vraag: indien je wel modbus-tcp "aan" kunt zetten op je omvormer, kun je dan via de ingebouwde WiFi-module er bij komen om die modbus-gegevens uit te lezen?

Heb zelf geen omvormer met SetApp, maar volgens mij staat op de omvormer een QR code die je moet scannen met de SetApp? Mogelijk dat je vooraf wel ook iets op de omvormer moet doen, want de omvormer zet bij mijn weten op dat moment zijn eigen wifi netwerk op waar de telefoon automatisch verbinding mee maakt en je dus via de SetApp de instellingen kunt aanpassen.
Vervolgens schakel je dus modpus via TCP in middels de opties in de SetApp, waarna je de verbinding verbreekt. Even later maakt de omvormer dan weer vanzelf verbinding met jouw wifi netwerk (zodat die bv dus weer alle gegevens naar ee portal stuurt) maar kun je dus ook de omvormer uitlezen via modbus op de ingestelde TCP poort (+ uiteraard het IP adres).

Overigens is het ook niet dat de SunSpec specificatie / standaard beperkt is. SunSpec bevat ook onderdelen om de gegevens van de optimizers op te halen. Echter heeft SolarEdge ervoor gekozen dit niet te implementeren.,

[Tjeerd]

RobertMe schreef op zaterdag 10 juni 2023 @ 18:01:
[...]

Heb zelf geen omvormer met SetApp, maar volgens mij staat op de omvormer een QR code die je moet scannen met de SetApp? Mogelijk dat je vooraf wel ook iets op de omvormer moet doen, want de omvormer zet bij mijn weten op dat moment zijn eigen wifi netwerk op waar de telefoon automatisch verbinding mee maakt en je dus via de SetApp de instellingen kunt aanpassen.
Vervolgens schakel je dus modpus via TCP in middels de opties in de SetApp, waarna je de verbinding verbreekt. Even later maakt de omvormer dan weer vanzelf verbinding met jouw wifi netwerk (zodat die bv dus weer alle gegevens naar ee portal stuurt) maar kun je dus ook de omvormer uitlezen via modbus op de ingestelde TCP poort (+ uiteraard het IP adres).

Overigens is het ook niet dat de SunSpec specificatie / standaard beperkt is. SunSpec bevat ook onderdelen om de gegevens van de optimizers op te halen. Echter heeft SolarEdge ervoor gekozen dit niet te implementeren.,

Blijkbaar als je een LCD-model hebt dan moet je het nog op het toestel zelf doen door de menu's heen te lopen. Ik heb het volgende gedaan/gecontroleerd:

- Switch of the DC power
- Long press the ‘OK’ button for a few seconds
- Release the ‘OK’ button
- The screen will ask a password, this is ‘12312312’ (the 2nd button from the left is ‘1’, the 3rd button is ‘2’, etc…)
- Go to Communication → LAN Conf → Modbus TCP (the default port is 502).
- To modify the TCP port, select Modbus TCP → TCP Port, set the port number and long-press Enter

Dat staat allemaal goed, blijkbaar stond modbus standaard zelfs gewoon al aan. Maar je hebt een WiFi Conf en een LAN Conf in het menu. Bij WiFi heb ik alles ingesteld staan zodat het naar mijn draadloze netwerk verbindt. Als ik verder onder LAN Conf kijk, zie ik overal 0.0.0.0 staan (DNS, gateway, IP enzovoorts). Ik heb nu geprobeerd in Home Assistant de code van https://github.com/binsentsu/home-assistant-solaredge-modbus te gebruiken, maar van alle vermoedelijke WiFi-IP-adressen die ik ook invul, krijg ik geen modbusgegevens binnen van de omvormer.

Als ik een nmap-scan doe op mijn WiFi-netwerk zie ik ook niks draaien op poort 502.

Ik ben bang dat het hele verhaal van modbus-TCP alleen nog eventueel zou werken als ik een netwerkkabel er in steek. Maar ik was niet van plan om een kabeltje er naar toe aan te leggen. Of ik moet een LAN naar WiFi-adapter of iets dergelijks er tussen zetten. Maar ik vind dat wat raar terwijl de omvormer al een extra WiFi-module heeft.

Er is bar weinig over te vinden hoe en/of dit zou werken i.c.m. als je al een WiFi-module in je omvormer hebt.

Enige wat ik dan tegen kom dat de firmwareversies verschillende effecten hebben, dan weer is het niet-officieel ondersteund, dan weer weggehaald en dan lees ik weer dat het wél over WiFi kan werken. De laatste firmware die ik voor mijn type omvormer kan vinden stamt uit juli 2020, maar daar zie ik niks bij staan over modbus-verbeteringen en ik zit momenteel ook al ergens op versie 3+, de versie die ik zelf in ieder geval nooit bijgewerkt heb en de omvormer een jaar of vijf geleden heb gekocht.

Vraag me af of het zin heeft om de firmware op te waarderen om dit werkend te krijgen.

Een alternatief wat ik me nog bedenk is om misschien om dan toch maar een ethernetkabel aan te sluiten naar de omvormer via een extra powerline adapter, aangezien ik daar al twee van in huis heb of een WiFi-access point met een ethernetaansluiting. Maar ik bedenk me nu dat er ook geen stopcontact zit daar

[ Voor 18% gewijzigd door Tjeerd op 12-06-2023 16:20 ]

[Lox-1]

@Tjeerd
Hier de SolarEdge SE3000H HD-Wave (geen LCD). De installateur heeft meteen de instelling voor modbus tcp gedaan, standaard poort 1502 (niet 502 = typo) aangehouden en werkt als een zonnetje icm Loxone en HomeWizard.

Eerst ook zitten klooien met een extender, maar toch voor bedrijfszekerheid een kabeltje erbij geperst. (nooit wifi geprobeerd verder

[Tjeerd]

Lox-1 schreef op maandag 12 juni 2023 @ 14:12:
@Tjeerd
Hier de SolarEdge SE3000H HD-Wave (geen LCD). De installateur heeft meteen de instelling voor modbus tcp gedaan, standaard poort 1502 (niet 502 = typo) aangehouden en werkt als een zonnetje icm Loxone en HomeWizard.

Eerst ook zitten klooien met een extender, maar toch voor bedrijfszekerheid een kabeltje erbij geperst. (nooit wifi geprobeerd verder

Kom zelf ook tot de conclusie dat het waarschijnlijk alleen via de ethernet-aansluiting uit te lezen is. Een reserve-idee is om gewoon een API-sleutel op te vragen bij SolarEdge en het op die manier met vertraging op te halen van hun website en dat in Home Assistant te gebruiken.

Had via het servicecentrum van SolarEdge voor de zekerheid afgelopen weekend nog twee vragen gesteld over precies de vraag van modbus+WiFi en het goedszetten van mijn account, want ik ben om één of andere reden beperkt qua rechten en kan nog geen API-sleutel aanmaken.

Zal kijken of ik nog kan laten weten wat het uiteindelijk geworden is.

[RobertMe]

Tjeerd schreef op maandag 12 juni 2023 @ 16:27:
[...]
Kom zelf ook tot de conclusie dat het waarschijnlijk alleen via de ethernet-aansluiting uit te lezen is. Een reserve-idee is om gewoon een API-sleutel op te vragen bij SolarEdge en het op die manier met vertraging op te halen van hun website en dat in Home Assistant te gebruiken.

Had via het servicecentrum van SolarEdge voor de zekerheid afgelopen weekend nog twee vragen gesteld over precies de vraag van modbus+WiFi en het goedszetten van mijn account, want ik ben om één of andere reden beperkt qua rechten en kan nog geen API-sleutel aanmaken.

Zal kijken of ik nog kan laten weten wat het uiteindelijk geworden is.

Ik vermoed dat door het achter lopen van de API hwt in HA ook wat scheef gaat lopen. Immers kijkt HA voor het energy dashboarden naar de "meterstand" op het uur (dus de totale opwek). Als die vervolgens om :00, :15, :30 en :45 zou pollen dan loopt die effectief een kwartier achter (doordat als die om :00 de stats berekend voor op het dashboard de API aanroep nog niet gedaan / verwerkt is). Waarbij je natuurlijk ook nog er tegenaan zult lopen dat de portal (en dus API) ook niet perse real time is.
Wil je wel accuratere data op het dashboard en krijg je modbus niet aan de praat moet je dus uitwijken naar een alternatieve manier van meten (bv met een energiemeter ertussen / oplossing met klemmen op de kabel).

[Tjeerd]

@Lox-1 @RobertMe Vanavond nog een oude Devolo-stekker voor netwerk over stroom gevonden en een flink stukje van de omvormer vandaan nog een stopcontact gevonden. De omvormer aangesloten met een ethernetkabel en inderdaad heb nu eindelijk verbinding in Home Assistant. Zie een hoop waarden binnen komen en worden gepresenteerd, dus dit was de oplossing.

De kap is er voor de test nu alleen even af en heb de netwerkkabel rechtstreeks er aan gehangen, want het speciale gat aan onderkant wat voor communicatiekabels moet worden gebruikt past een netwerkkabel met stekker totaal niet door heen. Is die ingang nog op één of andere manier los te krijgen zodat ik de hele UTP-stekker met kabel naar binnen kan schuiven? De handleiding hint er op dat je de kabel er door heen moet schuiven en dan opnieuw de stekker er aan moet zetten, maar dat vind ik niet echt handig.

Update: zie het al in dit filmpje. Er zit een soort kunststof ring in met kleine en grote gaten die je er doorheen moet drukken. Dan heb je een groter gat waar de kabel mét stekker door heen kan. Vanavond eens proberen.

[ Voor 12% gewijzigd door Tjeerd op 16-06-2023 10:33 ]

[TBBW]

Hoi hoi,

Heeft iemand versie 4.8.28 als image/iso.
Zodat ik die met behulp van usb-stick kan installeren op de SE.

Gr,

G.

[Zandor300]

Lox-1 schreef op maandag 12 juni 2023 @ 14:12:
@Tjeerd
Hier de SolarEdge SE3000H HD-Wave (geen LCD). De installateur heeft meteen de instelling voor modbus tcp gedaan, standaard poort 1502 (niet 502 = typo) aangehouden en werkt als een zonnetje icm Loxone en HomeWizard.

Eerst ook zitten klooien met een extender, maar toch voor bedrijfszekerheid een kabeltje erbij geperst. (nooit wifi geprobeerd verder

Modbus TCP met SetApp is standaard poort 1502
Modbus TCP met LCD is standaard poort 502

[eriksl]

Ik heb denk ik wat interessante informatie heb over het uitlezen va de SolarEdge omvormers, met name de nieuwe serie (zonder display).

Kort gezegd: als je alleen algemene informatie wilt hebben, dan werkt de modbus-over-TCP interface prima. Het enige wat je niet krijgt is de informatie per panel en optimiser, dat is wel erg jammer.

De laatste maanden ben ik heel hard bezig geweest met, o.a. vanuit suggesties in dit topic, het semonitor.py programma van jbuel te gebruiken om informatie vanuit de optimisers te verkrijgen.

Ik kan intussen melden dat de nieuwere modellen en/of nieuwere firmwares TLS (https) gebruiken om met de SolarEdge servers te praten. Dat zou je in principe kunnen afluisteren door een man-in-the-middle proxy te maken, maar dat werkt nu dus ook niet meer, omdat de omvormers het certificaat van de servers controleren (en dat kun je NIET voorkomen). Dus als je een nieuwere omvormer hebt, doe geen moeite te proberen om met semonitor.py over netwerk gegevens te verkrijgen, ook al heb je encryption keys, whatever, dit is niet meer mogelijk.

Ik ben er achter gekomen dat de optimiser records nog wel via RS485 worden verstuurd en dan ook nog eens niet-versleuteld. Ik heb een tijdlang semonitor.py gebruikt via deze interface om de records binnen te halen. Omdat mijn server (trapkast) niet bij de omvormer staat (zolder) gebruik ik een TCP-naar-RS232 bridge en daar heb ik een RS485 converter op aangesloten.

Door met socat een virtueel serieel device te maken en semonitor.py daarop te laten connecten, heb ik het werkend gekregen. Probleem met deze setup is dat het binnenhalen van de records heel erg langzaam gaat. Zodanig langzaam dat de achterstand alleen maar groter wordt, ik zat op een gegeven moment op drie weken en dat is waarschijnlijk ook de maximale buffer van het apparaat.

Het lijkt er op dat semonitor.py niet zo goed kan omgaan met een RS485 verbinding die af een paar bitjes kwijtraakt, waar ik last van lijk te hebben. Ik heb al een andere RS232 naar RS485 converter gebrobeerd, maar dat maakt niet uit. Ik heb ook al terminatie-weerstanden geprobeerd, maakt ook niks uit. De lengte/kabel kan het ook niet zijn (1 meter UTP). Bridgen van netwerk naar serieel deed ik eerst op een Linux laptop en nu op een ESP8266, maakt ook niet uit.

Wat ik nu heb gedaan is een eigen implementatie maken van semonitor.py, aan de hand van de gegevens die daar in staan (helaas allemaal niet-publiek) en daarbij wat extra robuustheid toegevoegd. Zoals een ack blijven sturen totdat er nieuwe data komt en ook tijdens het ontvangen van een packet continu kijken of er al een volgend packet komt (kan zijn dat er wat bytes niet ontvangen zijn). Ik krijg nu heel veel minder foutmeldingen dan met semonitor.py en de records komen rap binnen (tot aan tien per seconden, waar ik er eerst een per paar minuten kreeg).

Ik denk niet dat dit voor iedereen wat is omdat je wel het een en ander zelf moet doen en het programma op een Linux machine moet draaien (en je moet het ook zelf compileren). Maar wie weet kan iemand er weer iets in Python van maken met een mooie GUI of zo, leef je uit zou ik zeggen...

Maar het kán dus wel

https://github.com/eriksl/secollect

[Ronald]

Goed bezig, @eriksl

Heb je ook een lijst an specifieke hardware waarmee je het werkend hebt? Laatste keer dat ik keek leek er nog wat variaties in het oerwoud van RS484/RS232?

[ocaj]

eriksl schreef op zaterdag 16 september 2023 @ 14:15:
Het lijkt er op dat semonitor.py niet zo goed kan omgaan met een RS485 verbinding die af een paar bitjes kwijtraakt, waar ik last van lijk te hebben.

Daar had ik bij mijn vorige omvormer ook last van. Ik heb toen simpelweg een watchdog gemaakt die de output van semonitor analyseerde en als er na een aantal queries niks meer terug kwam het semonitor-script stopt, eventjes wachten en dan script weer starten. Uiteindelijk kwam dan altijd alles binnen.

Ik heb die watchdog nog steeds draaien, maar sinds mijn omvormers vervangen zijn heb ik er eigenlijk nooit meer last van dat semonitor de verbinding helemaal kwijt raakt. Er zit bij mij 8 meter cat6-kabel tussen de omvormers op zolder en mijn raspberry pi in de meterkast waar een USB-RS485-adapter aan hangt.

eriksl schreef op zaterdag 16 september 2023 @ 14:15:
.... en daarbij wat extra robuustheid toegevoegd. Zoals een ack blijven sturen totdat er nieuwe data komt en ook tijdens het ontvangen van een packet continu kijken of er al een volgend packet komt (kan zijn dat er wat bytes niet ontvangen zijn).

Misschien dat ik het niet helemaal snap, maar als je een ACK stuurt zonder dat de data goed is binnengekomen, dan is voor de omvormer de verstuurde data bevestigd en zal hij die data niet meer opnieuw sturen.
Het SE-protocol (zowel over RS485 als via Internet naar de portal) is van zichzelf super-robuust: Blijf data herhalen totdat de data bevestigd is. Als de data bevestigd is, kan deze in de omvormer "vergeten" worden.
Ook al bleef het semonitor-script in het begin wel eens hangen bij mij, ik ben nog nooit data kwijt geraakt.

Heeft jouw implementatie dan niet het risico dat je data kwijt raakt, omdat je mogelijk data bevestigd die je niet correct ontvangen hebt?

Andere suggestie: Ik ben geen expert, maar RS232 en RS485 zijn toch niet hetzelfde, waarom doe je die stap met RS232 er tussen? Er zijn ook TCP-adapters die direct RS485 babbelen. Zou dat niet beter werken?
(of toch op een of andere manier een vaste RS485-kabel regelen en niet via een netwerk-tussenstap. RS485 werkt tot vele honderden meters).

[Bombtrack]

Ik probeer mijn SolarEdge omvormer uit te lezen via modbus support, maar loop tegen issues aan. Ik las hierboven al dat ik niet de enige was, en her en der op het internet vind ik dat dit mogelijk is uitgezet via wifi. Is het iemand al recent gelukt modbus via wifi aan de praat te krijgen? Of liep iemand toevallig tegen dit issue aan en lukte het via een bedraade connectie wel?

Ik kan een draad trekken, maar dat is nogal een onderneming, dus hoopte hier wat zekerheid te kregen dat het inderdaad echt zou werken.

Ik ben zelf nogal nieuw hierin en wist voor eergisteren uberhaupt niet van het bestaan van modbus.
Ik heb een solaredge wave HD SE2200h. (zonder scherm)
Deze is via wifi verbonden.
Heeft via DHCP een statisch IP gekregen, wat ik kan pingen en krijg iets terug, dus dat lijkt correct te werken.
In de omvormer zelf via de onderhoudsmodus modbus support aangezet.
In HASS solaredge modbus geinstalleerd, maar krijg op geen van de sensors iets terug.
Port staat hetzelfde als de omvormer zelf aangeeft voor modbus.

Weet iemand buiten het pingen van het interne IP adres nog een andere manier om te achterhalen of er iets fout ingesteld staat ofzo? Is het iemand gelukt dit aan de praat te krijgen?

Het werkt trouwens vlekkeloos via de API, maar met een update interval van 15minuten is de data gewoon net ff meh...Ik hoop dat behoorlijk wat accurater/meer up-to-date te krijgen.

[eriksl]

ocaj schreef op zondag 17 september 2023 @ 08:06:
Daar had ik bij mijn vorige omvormer ook last van. Ik heb toen simpelweg een watchdog gemaakt die de output van semonitor analyseerde en als er na een aantal queries niks meer terug kwam het semonitor-script stopt, eventjes wachten en dan script weer starten. Uiteindelijk kwam dan altijd alles binnen.

Ik kreeg ook wel alles binnen, maar zodanig traag, dat de achterstand steeds groter werd.

Misschien dat ik het niet helemaal snap, maar als je een ACK stuurt zonder dat de data goed is binnengekomen, dan is voor de omvormer de verstuurde data bevestigd en zal hij die data niet meer opnieuw sturen.

Je gaat natuurlijk geen sequence ACKen die je nog niet ontvangen hebt. Je herhaalt de ACK op de laatste sequence die je succesvol ontvangen hebt. En als die ACK nou net even niet goed was aangekomen (wat kennelijk regelmatig gebeurt), dan scheelt dat je een timeout van meerdere minuten.

Ook al bleef het semonitor-script in het begin wel eens hangen bij mij, ik ben nog nooit data kwijt geraakt. Heeft jouw implementatie dan niet het risico dat je data kwijt raakt, omdat je mogelijk data bevestigd die je niet correct ontvangen hebt?

Ik raak ook niks kwijt nu.

Andere suggestie: Ik ben geen expert, maar RS232 en RS485 zijn toch niet hetzelfde, waarom doe je die stap met RS232 er tussen? Er zijn ook TCP-adapters die direct RS485 babbelen. Zou dat niet beter werken?

Dat mag niks uitmaken. Het protocol op laag 1 is exact gelijk, alleen de laag 0 is verschillend. In plaats van -9 en +9 (meestal) volt ten op zichte van massa, signaleert RS485 met +5 en -5 t.o.v. van twee "+" en "-" aders (differentieel). Dat is heel eenvoudig om te zetten. Sommige van de USB omzetters van FTDI hebben gewoon beide als pins.

Ik had het direct kunnen doen, misschien doe ik dat nog wel eens. Maar ik had nog (zelf ontworpen) printjes met een ESP8266 er op en een MAX3232 dus RS232C. Dan moet ik wat bedenken met een vergelijkbare chip met RS485, die zijn er ook wel, maar lastig aan te komen in DIP formaat, dan ga je meestal meteen naar SOIC of kleiner. Of niet aan te komen voor consumenten. Dit werkt prima zo. Zoals gezegd, ik heb het ook met een laptop gedaan met een USB omzetter en een andere RS232C naar RS485 omzetter en dat werkt net zo goed / net zo slecht (ook af en toe bits die omvallen).

Nu heb ik een systeem wat nauwelijks stroom gebruikt, iets van 100 mW en meteen bereikbaar via wifi/tcp (uart transparent tcp bridge).

[ocaj]

eriksl schreef op zondag 17 september 2023 @ 18:26:
Je gaat natuurlijk geen sequence ACKen die je nog niet ontvangen hebt. Je herhaalt de ACK op de laatste sequence die je succesvol ontvangen hebt. En als die ACK nou net even niet goed was aangekomen (wat kennelijk regelmatig gebeurt), dan scheelt dat je een timeout van meerdere minuten.

Aha, ik snapte het inderdaad niet
Je herhaalt de laatste ACK voor het geval de ACK verloren was gegaan. En er zit in de omvormer dus verschil in de reactiesnelheid na zo'n ACK t.o.v. gewoon opnieuw vragen om "de volgende data"? Slim gevonden!

[eriksl]

Ronald schreef op zaterdag 16 september 2023 @ 16:20:
Goed bezig, @eriksl

Heb je ook een lijst an specifieke hardware waarmee je het werkend hebt? Laatste keer dat ik keek leek er nog wat variaties in het oerwoud van RS484/RS232?

Pfff, ik heb twee converters uit China laten komen, zit volgens mij allebei een FTDI USB converter in, kennelijk kan die ook tussen RS485 en RS232 converteren. Het is uiteindelijk alleen maar een elektrische omzetten (gewoon naar differentieel). Zou vast met een paar transistors ook nog wel kunnen. Allebei doen ze het even "goed" (als in: bijna alles komt er goed doorheen, af en toe missen een paar bits, maar dat kan ook aan de omvormer liggen).

[eriksl]

Bombtrack schreef op zondag 17 september 2023 @ 15:02:
Ik probeer mijn SolarEdge omvormer uit te lezen via modbus support, maar loop tegen issues aan. Ik las hierboven al dat ik niet de enige was, en her en der op het internet vind ik dat dit mogelijk is uitgezet via wifi. Is het iemand al recent gelukt modbus via wifi aan de praat te krijgen? Of liep iemand toevallig tegen dit issue aan en lukte het via een bedraade connectie wel?

Ik kan een draad trekken, maar dat is nogal een onderneming, dus hoopte hier wat zekerheid te kregen dat het inderdaad echt zou werken.

Ik ben zelf nogal nieuw hierin en wist voor eergisteren uberhaupt niet van het bestaan van modbus.
Ik heb een solaredge wave HD SE2200h. (zonder scherm)
Deze is via wifi verbonden.
Heeft via DHCP een statisch IP gekregen, wat ik kan pingen en krijg iets terug, dus dat lijkt correct te werken.
In de omvormer zelf via de onderhoudsmodus modbus support aangezet.
In HASS solaredge modbus geinstalleerd, maar krijg op geen van de sensors iets terug.
Port staat hetzelfde als de omvormer zelf aangeeft voor modbus.

Weet iemand buiten het pingen van het interne IP adres nog een andere manier om te achterhalen of er iets fout ingesteld staat ofzo? Is het iemand gelukt dit aan de praat te krijgen?

Het werkt trouwens vlekkeloos via de API, maar met een update interval van 15minuten is de data gewoon net ff meh...Ik hoop dat behoorlijk wat accurater/meer up-to-date te krijgen.

Bij mij werkt de modbus-over-tcp interface vlekkeloos en supersnel (query sturen = meteen antwoord). Het enige is dat je alleen info van de inverter zelf kunt krijgen, niet van de optimisers. Ik heb een HD Wave 3680.

EDIT: ik zie dat je met WiFi hebt aangesloten, dat is anders dan bij mij, ik heb 'm gewoon bedraad aangesloten. Weet je dat je een antenne moet kopen om WiFi te kunnen gebruiken? Er zit wel een WiFi chip in, maar geen antenne dus. Dat is genoeg voor de "App" toegang op korte afstand, maar na een paar meter houdt het op.

Er zit volgens mij een standaard antenne-aansluiting op, dus die kun je wat mij betreft ook van eBay of AliExpress halen.

[ Voor 10% gewijzigd door eriksl op 18-09-2023 17:59 ]

[eriksl]

ocaj schreef op maandag 18 september 2023 @ 05:31:
[...]

Aha, ik snapte het inderdaad niet
Je herhaalt de laatste ACK voor het geval de ACK verloren was gegaan. En er zit in de omvormer dus verschil in de reactiesnelheid na zo'n ACK t.o.v. gewoon opnieuw vragen om "de volgende data"? Slim gevonden!

Ik zou wel met de eer willen strijken, maar dat heeft iemand een jaar of veertig geleden al bedacht In het IP/TCP protocol gebeurt namelijk precies hetzelfde. Als de verzender van data niet binnen een bepaalde tijd een ACK krijgt, dan stuurt hij het opnieuw (net als de SolarEdge). Maar als de ontvanger al weet dat het niet goed aangekomen is, dan stuurt hij meteen ACK van het vorige segment. Dat blijft hij zolang doen totdat het segment wel goed is ontvangen. TCP heeft dus geen "NAK" en is dus ook niet nodig.

Bij de SE kun je ook wachten tot er een hertransmissie wordt gedaan, maar dat duurt zomaar een paar minuten. Als je af en toe bitfouten hebt, gaat het dan snel een langdurige zaak worden. Zeker als het soms juist de ACK is die niet goed aankomt. Dus oplossing: ACK blijven sturen todat er weer wat komt.

Ik had ook al bij jbuel gesuggereerd zoiets in zijn semonitor.py te bouwen. En ook dat de nieuwere modellen of firmwares kennelijk geen bus grant meer nodig hebben of snappen. Semonitor.py probeert die nu telkens te sturen en wacht dan op een ACK die nooit komt.

[Bombtrack]

eriksl schreef op maandag 18 september 2023 @ 17:57:
[...]

Bij mij werkt de modbus-over-tcp interface vlekkeloos en supersnel (query sturen = meteen antwoord). Het enige is dat je alleen info van de inverter zelf kunt krijgen, niet van de optimisers. Ik heb een HD Wave 3680.

EDIT: ik zie dat je met WiFi hebt aangesloten, dat is anders dan bij mij, ik heb 'm gewoon bedraad aangesloten. Weet je dat je een antenne moet kopen om WiFi te kunnen gebruiken? Er zit wel een WiFi chip in, maar geen antenne dus. Dat is genoeg voor de "App" toegang op korte afstand, maar na een paar meter houdt het op.

Er zit volgens mij een standaard antenne-aansluiting op, dus die kun je wat mij betreft ook van eBay of AliExpress halen.

Dat versterkt het vermoedden dat modbus support over wifi inderdaad in de firmware is uitgezet, zoals in dit topic en elders op internet al meermaals staat beschreven. Echt hard bewijs hiervan vinden was lastig, maar als het inderdaad zo makkelijk werkt via een draad neem ik toch aan dat dat het is. Toch eens kijken of ik niet een tijdelijke draad kan leggen om het te testen.

ps. De antenne zit er inderdaad op, en heb stabiele verbinding. Kan em pingen en via de API werkt het vlekkeloos. De wifi verbinding zelf is het issue niet in deze.

[ocaj]

eriksl schreef op maandag 18 september 2023 @ 18:04:
[...]

Ik zou wel met de eer willen strijken, maar dat heeft iemand een jaar of veertig geleden al bedacht In het IP/TCP protocol gebeurt namelijk precies hetzelfde. Als de verzender van data niet binnen een bepaalde tijd een ACK krijgt, dan stuurt hij het opnieuw (net als de SolarEdge). Maar als de ontvanger al weet dat het niet goed aangekomen is, dan stuurt hij meteen ACK van het vorige segment. Dat blijft hij zolang doen totdat het segment wel goed is ontvangen. TCP heeft dus geen "NAK" en is dus ook niet nodig.

Ha, ja, hoe het bij TCP werkt weet ik. Ooit (ergens aan het einde van de vorige eeuw) tijdens de studie nog wel eens zelf een TCP-stack moeten schrijven.....

Maar voor RS485 is dat anders. De solaredge-master is een eigen protocol van SolarEdge. Mooi dat je gevonden hebt dat die SolarEdge-stack ook sneller antwoord als je een ACK stuurt ipv gewoon afwachten tot de omvormer het weer tijd vind om wat nieuws te sturen (als je er om vraagt, want uit zichzelf doet hij niks).

[ocaj]

eriksl schreef op zaterdag 16 september 2023 @ 14:15:
Wat ik nu heb gedaan is een eigen implementatie maken van semonitor.py, aan de hand van de gegevens die daar in staan (helaas allemaal niet-publiek) en daarbij wat extra robuustheid toegevoegd. Zoals een ack blijven sturen totdat er nieuwe data komt en ook tijdens het ontvangen van een packet continu kijken of er al een volgend packet komt (kan zijn dat er wat bytes niet ontvangen zijn). Ik krijg nu heel veel minder foutmeldingen dan met semonitor.py en de records komen rap binnen (tot aan tien per seconden, waar ik er eerst een per paar minuten kreeg).

Toch nog even een vraagje, ik las bij jbuehl issue #187 dat je ook de "Bus Master Grant" weg hebt gelaten?
Kom je dan niet in de problemen als er meerdere omvormers aan je bus hangen? Het verbaast me een beetje dat de omvormer begint te praten zonder een grant, dat is niet typisch hoe RS485 werkt, of zou hij een ack als een impliciete grant zien omdat je normaal gesproken al in gesprek was met die omvormer voordat je een ack stuurt?

(maakt verder niet uit, als het werkt dan werkt het, gewoon tweakers-nieuwsgierigheid )

[eriksl]

Bombtrack schreef op maandag 18 september 2023 @ 20:44:
[...]


Dat versterkt het vermoedden dat modbus support over wifi inderdaad in de firmware is uitgezet, zoals in dit topic en elders op internet al meermaals staat beschreven. Echt hard bewijs hiervan vinden was lastig, maar als het inderdaad zo makkelijk werkt via een draad neem ik toch aan dat dat het is. Toch eens kijken of ik niet een tijdelijke draad kan leggen om het te testen.

ps. De antenne zit er inderdaad op, en heb stabiele verbinding. Kan em pingen en via de API werkt het vlekkeloos. De wifi verbinding zelf is het issue niet in deze.

Kun je connecten op de poort die je instelt? Wat gebeurt er dan, als je modbus commando's stuurt, krijg je sowieso iets terug? Heb je al eens een packet capture gedaan? Welke poort gebruik je, bij mij is het 1502.

[eriksl]

ocaj schreef op maandag 18 september 2023 @ 22:22:
[...]


Ha, ja, hoe het bij TCP werkt weet ik. Ooit (ergens aan het einde van de vorige eeuw) tijdens de studie nog wel eens zelf een TCP-stack moeten schrijven.....

Maar voor RS485 is dat anders. De solaredge-master is een eigen protocol van SolarEdge. Mooi dat je gevonden hebt dat die SolarEdge-stack ook sneller antwoord als je een ACK stuurt ipv gewoon afwachten tot de omvormer het weer tijd vind om wat nieuws te sturen (als je er om vraagt, want uit zichzelf doet hij niks).

Ja dat is heel jammer, die timeout is meerdere minuten!

Cool, eigen TCP stack. Da's nog best complex. Ik heb wel zelf een groot stuk IP op een ATMega met 32 kB ROM 2n 2 kB RAM gemaakt. IP + UDP, heel basic TCP (zonder retransmits), ping en dhcp. Heel leerzaam Het is dat de (externe, SPI) ethernet interface zelf 4 kB RAM on board had, anders was het niet echt gaan werken.

[eriksl]

ocaj schreef op dinsdag 19 september 2023 @ 08:20:
Toch nog even een vraagje, ik las bij jbuehl issue #187 dat je ook de "Bus Master Grant" weg hebt gelaten?
Kom je dan niet in de problemen als er meerdere omvormers aan je bus hangen? Het verbaast me een beetje dat de omvormer begint te praten zonder een grant, dat is niet typisch hoe RS485 werkt, of zou hij een ack als een impliciete grant zien omdat je normaal gesproken al in gesprek was met die omvormer voordat je een ack stuurt?

(maakt verder niet uit, als het werkt dan werkt het, gewoon tweakers-nieuwsgierigheid )

RS485 legt hierover zelf uiteraard niks op, dit is typisch een (proprietair) SolarEdge protocol dingetje.

Ik heb een sterk vermoeden dat dit pas gaat spelen als je meerdere masters aan de bus gaat hangen en dat zal niet vaak voorkomen. Omvormers zijn slaves. Maar wie weet blijkt straks ook wel als mijn omvormer een keer echt spanningsloos is geweest dat hij niks meer doet zonder bus grant. Dat lijkt me leerzaam

Maar los daarvan, ik kreeg toch al nooit een ACK er op... Misschien is het soms wel nodig, lijkt me slim als jbuehl het optioneel maakt.

[Bombtrack]

eriksl schreef op dinsdag 19 september 2023 @ 18:19:
[...]

Kun je connecten op de poort die je instelt? Wat gebeurt er dan, als je modbus commando's stuurt, krijg je sowieso iets terug? Heb je al eens een packet capture gedaan? Welke poort gebruik je, bij mij is het 1502.

Ik heb buiten een ping niets weten terug te krijgen van de inverter. Nu moet ik ook eerlijk toegeven dat mn kennis hier....erg te wensen overlaat.
Ping IP adres in cmd krijgt resultaat.
Ip adres in browser = niets, met :port erachter ook niets.
Voor de rest ben ik voor modbus eigenlijk volledig afhankelijk van de HASS plugin die ik daarvoor heb geinstalleerd, maar die heeft nog nooit een signaal teruggekregen van de inverter.
Het kan hierin zijn dat ik iets compleet fout doe natuurlijk. Net even snel de tool modbus poll geprobeerd maar die krijgt connection failed/timeout.

[eriksl]

Bombtrack schreef op dinsdag 19 september 2023 @ 18:57:
Ik heb buiten een ping niets weten terug te krijgen van de inverter. Nu moet ik ook eerlijk toegeven dat mn kennis hier....erg te wensen overlaat.
Ping IP adres in cmd krijgt resultaat.
Ip adres in browser = niets, met :port erachter ook niets.
Voor de rest ben ik voor modbus eigenlijk volledig afhankelijk van de HASS plugin die ik daarvoor heb geinstalleerd, maar die heeft nog nooit een signaal teruggekregen van de inverter.
Het kan hierin zijn dat ik iets compleet fout doe natuurlijk. Net even snel de tool modbus poll geprobeerd maar die krijgt connection failed/timeout.

Probeer even met telnet of een vergelijkbare tool of je een connectie kunt opzetten op poort 1501 of 501. Je kunt die poort instellen met de app en staat standaard op 501 of 1501. Als je de verbinding kunt opzetten (of je krijgt een "connection refused") dan zegt dat al heel veel.

Het zou overigens kunnen dat als je hebt ingesteld dat het hele zaakje door de servers van SE op internet gemanaged wordt, dat deze poorten inderdaad niet opengezet worden. Mijn zonnepanelen (twee inverters) zitten als een van de weinig in Nederland (denk ik...) totaal NIET aan internet. Laat de Chinezen maar komen

[Bombtrack]

eriksl schreef op dinsdag 19 september 2023 @ 19:49:
[...]

Probeer even met telnet of een vergelijkbare tool of je een connectie kunt opzetten op poort 1501 of 501. Je kunt die poort instellen met de app en staat standaard op 501 of 1501. Als je de verbinding kunt opzetten (of je krijgt een "connection refused") dan zegt dat al heel veel.

Ik krijg via telnet hetzelfde. Geen refused, maar simpelweg failed.
Toch maar eens door mn dozen oude kabels gaan om te kijken of ik nog iets heb wat naar zolder haalt over de trap

[ZwarteIJsvogel]

Bombtrack schreef op dinsdag 19 september 2023 @ 21:31:
Ik krijg via telnet hetzelfde. Geen refused, maar simpelweg failed.

Welke firmwareversie zit er in de omvormer?

[Bombtrack]

ZwarteIJsvogel schreef op woensdag 20 september 2023 @ 06:06:
[...]

Welke firmwareversie zit er in de omvormer?

Als ik het goed zeg, want de benaming in solaredge is naar mijn mening bizar, versie 4.14.229.

[eriksl]

Bombtrack schreef op dinsdag 19 september 2023 @ 21:31:
Ik krijg via telnet hetzelfde. Geen refused, maar simpelweg failed.
Toch maar eens door mn dozen oude kabels gaan om te kijken of ik nog iets heb wat naar zolder haalt over de trap

Ik moet eerlijk zeggen dat ik 0 verstand van Windows heb en de tools die erbij zitten. Mijn (Unix) telnet zegt of "connection refused" (als het apparaat niet op die poort luistert), of er gebeurt heel lang niks (als het apparaat helemaal niet reageert) of je krijgt een werkende verbinding.

Misschien eens Putty proberen anders?

[ZwarteIJsvogel]

Bombtrack schreef op woensdag 20 september 2023 @ 10:23:
[...]

Als ik het goed zeg, want de benaming in solaredge is naar mijn mening bizar, versie 4.14.229.

Als ik mij goed herinner waren 4.14.x en 4.15.x de firmware versies waarin Modbus/TCP over WiFi niet werkte en is het vanaf 4.16.x supported verklaard voor residential inverters mits het WiFi netwerk secure is. Tijd voor een firmware upgrade, zou ik zeggen.

Ik zou overigens niet weten wat er bizar is aan het versienummer.

[Bombtrack]

ZwarteIJsvogel schreef op woensdag 20 september 2023 @ 19:47:
[...]
Als ik mij goed herinner waren 4.14.x en 4.15.x de firmware versies waarin Modbus/TCP over WiFi niet werkte en is het vanaf 4.16.x supported verklaard voor residential inverters mits het WiFi netwerk secure is. Tijd voor een firmware upgrade, zou ik zeggen.

Oh dat is weer teruggezet? Ik begreep juist dat het er permanent uitgehaald was en daarom vooral oudere firmware het nog zou doen, maar dit stemt hoopvol. Ik ga eens kijken hoe ik die upgrade kan regelen. Ik zag al ergens upgrade over USB, maar eens ff zoeken waar ik die dan vandaan trek, of dat ik een OTA update knop ergens kan vinden

EDIT: Helaas, ik heb de rechten niet. Ik ga eens contact opnemen met het installatiebedrijf.

ZwarteIJsvogel schreef op woensdag 20 september 2023 @ 19:47:
Ik zou overigens niet weten wat er bizar is aan het versienummer.

Het nummer zelf niet, maar het staat in de software beschreven als CPU version, tussen een sloot aan andere nummers. Ik heb moeten googlen welke de firmware was, en wist niet zeker of ik de juiste had.

[ Voor 4% gewijzigd door Bombtrack op 20-09-2023 20:59 ]

[ZwarteIJsvogel]

Bombtrack schreef op woensdag 20 september 2023 @ 20:45:
[...]

Oh dat is weer teruggezet? Ik begreep juist dat het er permanent uitgehaald was

Dat is hier wel eens geroepen, maar ik heb daar bij SolarEdge nooit iets over gelezen. Mochten ze dat inderdaad hebben gedaan, dan hebben ze wel wat uit te leggen.

[...]

Het nummer zelf niet, maar het staat in de software beschreven als CPU version, tussen een sloot aan andere nummers. Ik heb moeten googlen welke de firmware was, en wist niet zeker of ik de juiste had.

De CPU versie is inderdaad de firmware versie. Wat nu even niet helpt is dat op de SolarEdge firmware update pagina momenteel een verkeerde tabel staat in de sectie voor 4.18.32 (o.a. staat de CPU versie in de kolom DSP1). Kennelijk zien ze bij SolarEdge ook de bomen niet meer door het eigen firmwarebos.

[ Voor 7% gewijzigd door ZwarteIJsvogel op 21-09-2023 04:53 ]

[eriksl]

Nog even iets wat me opvalt: de data van de optimisers wordt met enige vertraging doorgegeven. Dat is een gegeven en moeten we mee leven. MAAR er zitten timestamps in de berichten, en als je naar de situatie van, zeg, een kwartier geleden kijkt, dan zou daarvan de data goed en consistent moeten zijn. Maar dat is dus niet zo. Als je de grafiek van de totale opbrengst, vanuit TCP modbus (= altijd up to date), naast/over de totale opbrengst van de optimisers legt, dan zie je dat die laatste nog altijd een aantal minuten achterlopen, ondanks dat je de timestamp uit de message gebruikt (en die al een tijdje achter loopt). Als ik dat corrigeer, dan is het goed, ik zit nu op drie minuten, maar dat is denk ik dan weer net te weinig.

Hebben jullie dat ook?

[eriksl]

Nog iets anders, nog mensen die toevallig bezig zijn geweest met ontrafelen van diverse berichten? Ik heb er nu een paar gevonden, eentje waarin statistics van de microcontroller worden gestuurd (eens per dag), de regio ("Netherlands") (idem) en een opsomming van alle optimiser's id's, met een byte per optimisier die altijd 0 lijkt te zijn. Ik had gehoopt dat je hiermee de feitelijke volgorde van de optimisers (fysiek) zou kunnen achterhalen, maar ik zie optimisers van de voorkant en de achterkant van het dak door elkaar heen, dus niet zo waarschijnlijk.

Er komt ook elke paar minuten een bericht "3c2" langs. De data daarvan lijkt altijd 0 te zijn als er geen zonlicht is en anders niet-nul. Ik kan er geen chocola van maken, maar ben wel heeeeel erg benieuwd.

[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.