[SolarEdge] Omvormers en optimizers zelf monitoren

[ZwarteIJsvogel]

Heel onlogisch inderdaad. Ik denk dat de theorie bij SE is geweest dat die modus tijdens de commissioning altijd wordt uitgezet. Maar dat is kennelijk niet het geval. Waarschijnlijk gewoon slordig.

De term debug mode heb ik niet bedacht. Die komt van SE zelf. En het is ook een echte debug mode. Dat die mode ook gekoppeld is aan het (tijdelijk) opheffen van een toegangsbeperking, lijkt meer op een noodgreep. Tot 4.6.24 lagen de HTTP services wijd open (malware paradise). SE moest dus hoognodig wat doen, maar i.p.v. een fatsoenlijke authenticatie hebben ze de huidige quick-and-dirtyoplossing geïmplementeerd.

[Kees-Jan]

ZwarteIJsvogel schreef op donderdag 19 september 2019 @ 08:28:
Tot 4.6.24 lagen de HTTP services wijd open (malware paradise). SE moest dus hoognodig wat doen, maar i.p.v. een fatsoenlijke authenticatie hebben ze de huidige quick-and-dirtyoplossing geïmplementeerd.

Maar alléén beschikbaar vanaf LAN...

[scheric]

Mich schreef op woensdag 18 september 2019 @ 20:16:
De localAPI in HA maakt niet gebruik van de proton files en daarom kan je alleen een paar waardes maar uitlezen.

HA maakt wel gebruik van proton files. Zie: https://github.com/drobtravels/solaredge-local

lolle1212 schreef op dinsdag 17 september 2019 @ 13:01:
Ofwel lange leve de localAPI, alleen jammer dat de Home Assistant ondersteuning voor LocalAPI maar een paar gegevens mapped. (Niks over optimizers bijvoorbeeld.)

Mich schreef op woensdag 18 september 2019 @ 20:40:
De solaredge local integratie in home assistant doet toch echt maar 4 of 5 sensoren aanmaken met de opgewekte vermogens (nu, dag, maand, jaar).

De api kan veel meer aan. het is nu nog een custom_component. zie: https://github.com/home-assistant/home-assistant/pull/26708 feedback geven mag altijd.

[Tomba]

Jerrythafast schreef op zondag 25 september 2016 @ 01:23:
[,..]

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

Bij het migreren van Raspberry naar een Ubuntu machine viel het mij op dat je script de UFW firewall uitschakelt. Heb dit opgelost door:

code:

ufw --force enable

toe te voegen aan het einde van se-nat.sh en (voor de zekerheid) ufw uit te schakelen op de interface waar de Solar Edge aan hangt;

code:

ufw allow in on eth2

en alles werkt nu. Rest mij wel de vraag waarom het script de firewall precies uitschakelt, @Jerrythafast kun je me dat verklappen?

[Kees-Jan]

Mich schreef op woensdag 18 september 2019 @ 20:40:
[...]


Ik weet niet wat dat script precies doet maar ik heb die proton files gebruikt om alle info in Node-Red uit te lezen en vervolgens via MQTT door te geven aan home assistant. Zie deze post:

Mich in "[SolarEdge] Omvormers en optimizers zelf monitoren"

https://www.home-assistant.io/components/solaredge_local/

De solaredge local integratie in home assistant doet toch echt maar 4 of 5 sensoren aanmaken met de opgewekte vermogens (nu, dag, maand, jaar).

Kan je in Home Assistant een file inlezen? Of een JSON ontvangen? Dan zou je mogelijk die info via python uit de omvormer kunnen halen en dan als JSON naar HA sturen of die output file inlezen; dan heb je al meer informatie (sensors in HA?) om te verwerken.

[scheric]

Kees-Jan schreef op donderdag 19 september 2019 @ 20:38:
Kan je in Home Assistant een file inlezen? Of een JSON ontvangen? Dan zou je mogelijk die info via python uit de omvormer kunnen halen en dan als JSON naar HA sturen of die output file inlezen; dan heb je al meer informatie (sensors in HA?) om te verwerken.

File inlezen kan ik niks over zeggen maar Json ontvangen kan wel.
Als je aangeeft in https://github.com/home-assistant/home-assistant/pull/26708 welke sensors je wilt hebben dan zou ik die erin kunnen zetten.

HA gebruikt trouwens https://pypi.org/project/solaredge-local/

[Kees-Jan]

scheric schreef op vrijdag 20 september 2019 @ 16:11:
[...]


File inlezen kan ik niks over zeggen maar Json ontvangen kan wel.
Als je aangeeft in https://github.com/home-assistant/home-assistant/pull/26708 welke sensors je wilt hebben dan zou ik die erin kunnen zetten.

HA gebruikt trouwens https://pypi.org/project/solaredge-local/

Ikzelf gebruik Domoticz (herhaling).

Als je een JSON kan ontvangen dan kan je een JSON vanuit python sturen?

Ik gebruik in python https://pypi.org/project/solaredge-setapp/
met onderstaand script:

import solaredge_setapp
import requests
import json
import time

inverter_ip = "10.0.0.152"

while True:
statusBytes = requests.get("http://{0}/web/v1/status".format(inverter_ip)).content
statusCall = solaredge_setapp.status.Status()
status = statusCall.parse_protobuf(statusBytes)
f = open("/tmp/SolarEdgeStatusContinue", "w")
f.write(json.dumps(status))
f.close()
time.sleep(3)
exit()

als python script loopt als cron-job @reboot en genereert iedere 3 seconden een JSON bestand.
en lees daarna de file in Domoticz (LUA script).
lijkt me dat je die "json.dumps(status)" variabele wel in (of met) een http(s) naar HA kan krijgen?

hetzelfde geldt voor de maintenance data:

import solaredge_setapp
import requests
import json
import time

inverter_ip = "10.0.0.152"

maintenanceBytes = requests.get("http://{0}/web/v1/maintenance".format(inverter_ip)).content
maintenanceCall = solaredge_setapp.maintenance.Maintenance()
maintenance = maintenanceCall.parse_protobuf(maintenanceBytes)

f = open("/tmp/SolarEdgeMaintenance", "w")
f.write(json.dumps(maintenance))
f.close()

exit()

die loopt als cron-job 1 keer/minuut omdat de poweroptimizer-data toch niet zo snel wijzigt.

[lolle1212]

Ik heb de firmware files voor 4.6.27 en 4.7.17 inmiddels ook te pakken en aan @ZwarteIJsvogel gestuurd. Mochten er meer devs zijn op zoek naar de files, stuur even pm, dan pm ik een dropbox linkje met de nieuwste versies.

[Kees-Jan]

Kees-Jan schreef op dinsdag 17 september 2019 @ 18:09:
...

Ik heb wel dat om de 2 dagen de opwek-counters ge-reset worden. Iemand anders dat soms ook? Dit is al vanaf het begin dat ik déze omvormer heb (de 1e was na 48 dagen al goed defect)

Ik heb contact opgenomen met SolarEdge support.
Zij kunnen, zonder dat je een port-forward /NAT regel in je modem hebt ingesteld, gewoon in je omvormer kijken. Dus de sessie die de counters update op het SolarEdge portaal kan ook gebruikt worden voor remote support...

dat terzijde; m'n omvormer heeft een remote reset gehad waarna de maand, jaar en totaal tellers weer gevuld werden. Niet helemaal goed want je zou verwachten dat jaar en totaal teller gelijk zouden zijn, in ieder geval in het jaar van ingebruikname (2019-08-20)... en de maand teller klopte ook niet met "mijn" teller in Domoticz...

maar goed, vanmiddag even afwachten of de tellers weer overhoop raken...

[ZwarteIJsvogel]

lolle1212 schreef op zaterdag 21 september 2019 @ 10:17:
Ik heb de firmware files voor 4.6.27 en 4.7.17 inmiddels ook te pakken en aan @ZwarteIJsvogel gestuurd.

Mijn voorlopige conclusie is dat solaredge-local weer zou moeten werken met 4.7.17 (maar niet met 4.6.27). SE heeft de beperking dat de HTTP services alleen vanaf IP-adressen 172.16.0/24 waren te gebruiken in 4.7.17 zo te zien weer teruggedraaid. Ik heb niet gekeken of SE andere maatregelen heeft genomen om de toegang te beperken.

[lolle1212]

ZwarteIJsvogel schreef op zaterdag 21 september 2019 @ 17:46:
[...]

Mijn voorlopige conclusie is dat solaredge-local weer zou moeten werken met 4.7.17 (maar niet met 4.6.27). SE heeft de beperking dat de HTTP services alleen vanaf IP-adressen 172.16.0/24 waren te gebruiken in 4.7.17 zo te zien weer teruggedraaid. Ik heb niet gekeken of SE andere maatregelen heeft genomen om de toegang te beperken.

Lijkt helaas niet het geval.. 4.6.27 geeft de bekende internal server error, 4.7.17 geeft geen response. (localAPi werkt ook niet)

(De SetApp installeert overigens alleen 4.6.27. Om versie 4.7.17 te installeren heb ik een usb stick gebruikt.)

Ik ga nu proberen weer terug te downgraden naar 4.4.67 om localAPI terug te krijgen.. Experiment mislukt. haha

EDIT downgrade gelukt, nu laadt hij gek genoeg met 4.4.67 wel de WSA versie zien (1.3.6, whatever dat is)

[ Voor 6% gewijzigd door lolle1212 op 21-09-2019 19:24 ]

[ZwarteIJsvogel]

lolle1212 schreef op zaterdag 21 september 2019 @ 19:01:
4.7.17 geeft geen response. (localAPi werkt ook niet)

ZwarteIJsvogel schreef op zaterdag 21 september 2019 @ 17:46:
Ik heb niet gekeken of SE andere maatregelen heeft genomen om de toegang te beperken.

Ik ben even wat dieper gedoken. SE heeft inderdaad andere maatregelen genomen. Nieuw in 4.7.17 is dat ze iptables gebruiken. Dat verklaart denk ik waarom je nu helemaal geen response krijgt. De iptables configuratie kan ik niet zien: die wordt er denk ik pas bij de commissioning in gezet.

Gewijzigde conclusie: SE heeft de deur nog wat steviger dichtgegooid Het was ook te mooi om waar te zijn...

Nu blijft eigenlijk alleen nog de modbusroute over. Als SE daar de optimizerdata aan zou toevoegen, hebben we geen hacks meer nodig.

[ocaj]

Kunnen de nieuwe omvormers via RS485 behalve het Sunspec-protocol, nog wel het Solaredge-master/slave protcol gebruiken? Daar zit de optimizer-data wel bij.

Dat Solardege protocol is bedoeld om als je meerdere omvormers hebt er 1 als master in te stellen en de rest als slave. De slaves geven alles door aan de master en de master praat dan met de solaredge-portal.

De jbuehl-software simuleert een master-omvormer op de RS485-bus, waardoor je omvormer alles braaf doorgeeft. Gewoon zonder encryptie of gedoe. Werkt hier al 4,5 jaar zo (maar mijn omvormer hangt niet aan internet en krijgt dus zeker nooit updates).
Enige nadeel is dat het alleen op 115200 baud werkt, dat gaat met 9 meter kabel nog wel eens mis. Protocol is echter robuust, en data wordt de volgende keer alsnog opgestuurd. Ik ben nog nooit data kwijt geraakt.

[Mich]

Kees-Jan schreef op zaterdag 21 september 2019 @ 13:44:
[...]

Ik heb contact opgenomen met SolarEdge support.
Zij kunnen, zonder dat je een port-forward /NAT regel in je modem hebt ingesteld, gewoon in je omvormer kijken. Dus de sessie die de counters update op het SolarEdge portaal kan ook gebruikt worden voor remote support...

dat terzijde; m'n omvormer heeft een remote reset gehad waarna de maand, jaar en totaal tellers weer gevuld werden. Niet helemaal goed want je zou verwachten dat jaar en totaal teller gelijk zouden zijn, in ieder geval in het jaar van ingebruikname (2019-08-20)... en de maand teller klopte ook niet met "mijn" teller in Domoticz...

maar goed, vanmiddag even afwachten of de tellers weer overhoop raken...

Dit valt mij al vanaf het begin op dat die tellers niet gelijk lopen. Vooral de eerste maand kan je dat goed zien. Dan is maand al ongelijk aan jaar. Wat dus eigenlijk gelijk moet zijn.

Het is wel zo dat de dag opbrengst heel goed klopt met mijn losse bruto productie meter (kWh meter).

Toch slordig (en best knap) dat ze moeite hebben om maand en jaar standen niet kloppend te krijgen.

[ZwarteIJsvogel]

ocaj schreef op zaterdag 21 september 2019 @ 23:19:
De jbuehl-software simuleert een master-omvormer op de RS485-bus, waardoor je omvormer alles braaf doorgeeft. Gewoon zonder encryptie of gedoe. Werkt hier al 4,5 jaar zo (maar mijn omvormer hangt niet aan internet en krijgt dus zeker nooit updates).
Enige nadeel is dat het alleen op 115200 baud werkt, dat gaat met 9 meter kabel nog wel eens mis. Protocol is echter robuust, en data wordt de volgende keer alsnog opgestuurd. Ik ben nog nooit data kwijt geraakt.

Wat is een goede RS485-USB dongle? Bij Aliexpress en Amazon is van alles te koop, maar de bomen zijn door het bos moeilijk te zien. Edit: de dongle moet werken met Linux (Debian 9).

Is het niet ook zo dat als de SE in RS-485 slave mode via een master rapporteert, je het SE monitoring portal niet meer kunt gebruiken?

[ Voor 3% gewijzigd door ZwarteIJsvogel op 22-09-2019 14:25 ]

[ocaj]

ZwarteIJsvogel schreef op zondag 22 september 2019 @ 14:00:
[...]

Wat is een goede RS485-USB dongle? Bij Aliexpress en Amazon is van alles te koop, maar de bomen zijn door het bos moeilijk te zien. Edit: de dongle moet werken met Linux (Debian 9).

Er zijn hele goedkope voor 2 draadjes en iets duurdere met 3 draadjes (Ground).
Ik heb volgens mij deze: https://www.dx.com/p/usb-to-rs-485-adapter-2005092
Maar heb ook een paar andere. Met deze heb ik geen problemen. Draait zonder extra drivers onder raspbian, dus waarschijnlijk ook wel onder Debian.

Is het niet ook zo dat als de SE in RS-485 slave mode via een master rapporteert, je het SE monitoring portal niet meer kunt gebruiken?

Dat klopt inderdaad. De omvormer rapporteert maar aan één ontvanger, dus óf RS485, óf de monitoring portal.

[Claude]

Ik heb het in dit topic niet voorbij zien komen (als ik mij tenminste niet vergis met die 60+ pagina's). Vandaar dat ik het even meld.
Ik heb een SolarEdge omvormer zonder display. Door in mijn router te klikken op het betreffende IP-nummer krijg ik de interface te zien van de de SetApp en kan ik alle instellingen inzien. Volgens mij kan ik ook instellingen veranderen, maar dat heb ik niet getest
link

[janssuhhh]

Claude schreef op maandag 23 september 2019 @ 12:36:
Ik heb het in dit topic niet voorbij zien komen (als ik mij tenminste niet vergis met die 60+ pagina's). Vandaar dat ik het even meld.
Ik heb een SolarEdge omvormer zonder display. Door in mijn router te klikken op het betreffende IP-nummer krijg ik de interface te zien van de de SetApp en kan ik alle instellingen inzien. Volgens mij kan ik ook instellingen veranderen, maar dat heb ik niet getest
link

Dat is de webinterface waar men het in de pagina's hiervoor over heeft die in de nieuwere firmwares is dichtgezet door Solaredge. Zolang je nog een wat oudere FW op de omvormer hebt, werkt dit en kun je die gegevens gebruiken voor bijvoorbeeld domoticz om grafieken bij te houden.
Met de nieuwere firmwares is dat dus (vooralsnog) niet meer mogelijk.

[ZwarteIJsvogel]

ocaj schreef op zondag 22 september 2019 @ 16:31:
Ik heb volgens mij deze: https://www.dx.com/p/usb-to-rs-485-adapter-2005092
Maar heb ook een paar andere. Met deze heb ik geen problemen. Draait zonder extra drivers onder raspbian, dus waarschijnlijk ook wel onder Debian.

Vandaag besteld via Aliexpress! Ik verwacht ook geen problemen met Debian: de pl2303 USB-chip in dit product wordt standaard ondersteund. Wat mij verder bevalt zijn de surge en static electricity protections. Het adapterprintje met de schroefjes ga ik niet gebruiken: ik zet er een DE-9F tegenaan met ca. 2m kabel naar de SolarEdge.

[Jerrythafast]

Tomba schreef op donderdag 19 september 2019 @ 11:32:
[...]

Bij het migreren van Raspberry naar een Ubuntu machine viel het mij op dat je script de UFW firewall uitschakelt. Heb dit opgelost door:

code:

ufw --force enable

toe te voegen aan het einde van se-nat.sh en (voor de zekerheid) ufw uit te schakelen op de interface waar de Solar Edge aan hangt;

code:

ufw allow in on eth2

en alles werkt nu. Rest mij wel de vraag waarom het script de firewall precies uitschakelt, @Jerrythafast kun je me dat verklappen?

Ik heb geen idee, dat script is een copy-and-paste van de Ubuntu website geweest. Wat is het effect van het al dan niet enabled zijn van ufw, en waar in het script wordt dit uitgezet? In principe klinkt het niet echt als de bedoeling om "de firewall" uit te zetten.

Kees-Jan schreef op zaterdag 21 september 2019 @ 13:44:
[...]

Ik heb contact opgenomen met SolarEdge support.
Zij kunnen, zonder dat je een port-forward /NAT regel in je modem hebt ingesteld, gewoon in je omvormer kijken. Dus de sessie die de counters update op het SolarEdge portaal kan ook gebruikt worden voor remote support...

Klopt, ik heb daar nog een leuke anekdote over. Behalve de telemetrie kunnen er inderdaad nog allerlei andere pakketjes over die verbinding verzonden worden, zoals "lees display uit" (waarna de letterlijke tekst zoals die op het display staat wordt teruggestuurd), "druk op het knopje" (waarmee het indrukken van de knop op de onderkant van de omvormer wordt gesimuleerd, om naar het volgende menu te gaan), "start pairing" (waarmee de omvormer in pairing-modus gaat), enzovoort. Op een dag was het display van de SE3000 een eigen leven gaan leiden (ging overdag niet meer aan, en 's nachts bleef hij fel verlicht, stond geen tekst meer op). Na contact met de installateur gingen zij de omvormer uitlezen, updaten, rebooten etc. en dat verkeer kwam natuurlijk in de pcap files te staan hier. Ik was wel nieuwsgierig wat zij op het display konden lezen (het fysieke display deed het immers niet meer) en ging in de pcap files spitten. De genoemde commando's werkten allemaal gewoon, maar bij "lees display uit" kwam er als antwoord allemaal gibberish naar boven

[ZwarteIJsvogel]

Jerrythafast schreef op woensdag 25 september 2019 @ 12:55:
Behalve de telemetrie kunnen er inderdaad nog allerlei andere pakketjes over die verbinding verzonden worden, zoals "lees display uit" (waarna de letterlijke tekst zoals die op het display staat wordt teruggestuurd), "druk op het knopje" (waarmee het indrukken van de knop op de onderkant van de omvormer wordt gesimuleerd, om naar het volgende menu te gaan), "start pairing" (waarmee de omvormer in pairing-modus gaat), enzovoort.

Er zijn nog veel meer soorten pakketjes. Natuurlijk erg handig voor remote support. Maar ook een enorm risico: als de monitoring service van SolarEdge wordt gehackt (*), dan kunnen PV-installaties wereldwijd worden ontregeld. Eigenlijk een reden te meer om je omvormer niet aan het internet te hangen.

(*) Anno 2019 is het niet de vraag of dit een keer gebeurt, maar wanneer. Al verwacht ik dat de security bij een Israëlisch bedrijf beter dan gemiddeld zal zijn geregeld. De monitoring servers (prod.solaredge.com resp. prodssl.solaredge.com) staan zo te zien in Duitsland.

[Kees-Jan]

ZwarteIJsvogel schreef op donderdag 26 september 2019 @ 13:25:
[...]
De monitoring servers (prod.solaredge.com resp. prodssl.solaredge.com) staan zo te zien in Duitsland.

Dat zal waarschijnlijk een anycast DNS zijn, zodat niet álle SolarEdge omvormers uit de hele wereld naar de servers in .de connecten, maar via anycast DNS netwerk-technisch naar de geografisch dichtbij gelegen server.

[stormfly]

Kees-Jan schreef op vrijdag 27 september 2019 @ 08:23:
[...]
Dat zal waarschijnlijk een multicast DNS zijn, zodat niet álle SolarEdge omvormers uit de hele wereld naar de servers in .de connecten, maar via multicast DNS netwerk-technisch naar de geografisch dichtbij gelegen server.

anycast, bjina goed.

[Kees-Jan]

anycast, die bedoel ik...

aangepast

[ Voor 20% gewijzigd door Kees-Jan op 27-09-2019 08:38 ]

[ZwarteIJsvogel]

Kees-Jan schreef op vrijdag 27 september 2019 @ 08:23:
[...]
Dat zal waarschijnlijk een anycast DNS zijn, zodat niet álle SolarEdge omvormers uit de hele wereld naar de servers in .de connecten, maar via anycast DNS netwerk-technisch naar de geografisch dichtbij gelegen server.

Het ligt voor de hand dat te denken, maar in dit geval is het niet zo: traceroutes op FQDN vanuit verschillende delen van de wereld komen steeds weer uit in Frankfurt am Main.

[ZwarteIJsvogel]

ZwarteIJsvogel schreef op maandag 23 september 2019 @ 21:40:
Vandaag besteld via Aliexpress! Ik verwacht ook geen problemen met Debian: de pl2303 USB-chip in dit product wordt standaard ondersteund.

De kabel viel zojuist op de deurmat. Inmiddels wordt versie 2 geleverd. Deze is gebaseerd op de FT232 USB-chip van FTDI. Deze wordt (uiteraard) ook probleemloos herkend door Windows en Linux.

[janssuhhh]

ZwarteIJsvogel schreef op zaterdag 21 september 2019 @ 17:46:
[...]

Mijn voorlopige conclusie is dat solaredge-local weer zou moeten werken met 4.7.17 (maar niet met 4.6.27). SE heeft de beperking dat de HTTP services alleen vanaf IP-adressen 172.16.0/24 waren te gebruiken in 4.7.17 zo te zien weer teruggedraaid. Ik heb niet gekeken of SE andere maatregelen heeft genomen om de toegang te beperken.

Ik volg deze draad al enige tijd, omdat ik de lokale data gebruik in Domoticz en ook ik dus niet blij zou zijn met een update.
Nou heb ik gisteren vanuit Solaredge/installateur een update gepusht gekregen, omdat ik een storing had aan het systeem.

Ik dacht even dat het nu klaar zou zijn met de lokale toegang, maar ik kan met firmware 4.6.27 nog overal bij.

Firmware: 4.6.27
DSP1: 1.13.1541
DSP2: 2.19.1312
WSA: 1.1.12
IP-range: 172.17.x.x

Lijkt er dus op dat die ip-range ook werkt, bovenop 172.16.x.x

[thavini]

Hallo ik ben nieuw in dit draadje.
Ik heb sinds 3 weken een SolarEdge zonder display hangen: SE3500H. De installatie hing en het was 's avonds voor de mannen te laat om het allemaal te actieveren. Ze deden een snelle check of he inverter werkte en lieten deze actief op de LAN en de schakelaar stond op 1.

Ik ben toen uiteraard flink bezig geweest in Home Assistant om een mooi schermpje te maken. Super blij was ik. De volgende ochtend wilde de collega's op het werk graag alles weten. Ik ben blijkbaar de eerste op de afdeling met zonnepanelen. Alles leuk en wel iedereen blij en sommigen onder de indruk.

'S middags komt de monteur weer langs bij ons huis en actieveerd het systeem. Je raad het al 'Internal Server Error' daarna. Sindsdien niet meer en ik bleef maar zoeken tot ik dit vond. Ik ben blij dat ik dit vond want SolarEdge stuurt me naar de monteur en de monteur stuurt me naar SolarEdge. Dat helpt natuurlijk niet. Nu weet ik dus wel wat er scheelt.

Na wat te hebben gelezen over die debug modus. Bij het inschakelen staat het dus in debug modus. En als de monteur hem pairt met de app staat ie eigenlijk ook in debug modus? Onhandige naam maar het zij zo!

Heeft iemand enig idee wat er zal gebeuren als ik zelf een account aanmaak en dan opnieuw de pairing start met de app? Een account aanmaken voor SolarEdge SetApp schijnt gewoon te kunnen SolarEdge doet daar geen check op en het mag gewoon.
Een nadeel wellicht, volgens mij zit je dan met garantie zaken die nu via de montuer/leverancier lopen. Hoe gaat dat dan?

[thavini]

janssuhhh schreef op donderdag 3 oktober 2019 @ 09:31:
[...]


Ik volg deze draad al enige tijd, omdat ik de lokale data gebruik in Domoticz en ook ik dus niet blij zou zijn met een update.
Nou heb ik gisteren vanuit Solaredge/installateur een update gepusht gekregen, omdat ik een storing had aan het systeem.

Ik dacht even dat het nu klaar zou zijn met de lokale toegang, maar ik kan met firmware 4.6.27 nog overal bij.

Firmware: 4.6.27
DSP1: 1.13.1541
DSP2: 2.19.1312
WSA: 1.1.12
IP-range: 172.17.x.x

Lijkt er dus op dat die ip-range ook werkt, bovenop 172.16.x.x

Vraagje. Is je SolarEdge gekoppeld met de monitoring portal van SolarEdge? Misschien zit daar ook nog iets.

[ZwarteIJsvogel]

janssuhhh schreef op donderdag 3 oktober 2019 @ 09:31:
Ik dacht even dat het nu klaar zou zijn met de lokale toegang, maar ik kan met firmware 4.6.27 nog overal bij.

Firmware: 4.6.27
DSP1: 1.13.1541
DSP2: 2.19.1312
WSA: 1.1.12
IP-range: 172.17.x.x

Lijkt er dus op dat die ip-range ook werkt, bovenop 172.16.x.x

Kijkend naar de 4.6.27 firmware is dat normaliter niet het geval. Ik denk eerder dat jouw SolarEdge (om onbekende redenen) in de eerder door mij genoemde debug mode draait. Ik heb alleen geen idee waardoor die wordt beëindigd. Dat kan misschien zelfs op enig moment zomaar gebeuren.

[janssuhhh]

ZwarteIJsvogel schreef op donderdag 3 oktober 2019 @ 11:56:
[...]

Kijkend naar de 4.6.27 firmware is dat normaliter niet het geval. Ik denk eerder dat jouw SolarEdge (om onbekende redenen) in de eerder door mij genoemde debug mode draait. Ik heb alleen geen idee waardoor die wordt beëindigd. Dat kan misschien zelfs op enig moment zomaar gebeuren.

Mogelijk komt dat door debug ja, weten we inmiddels hoe we dat kunnen zien of die daarin draait? Dan zou ik het kunnen nakijken. Ik zal sowieso de boel in de gaten houden.

thavini schreef op donderdag 3 oktober 2019 @ 11:31:
[...]


Vraagje. Is je SolarEdge gekoppeld met de monitoring portal van SolarEdge? Misschien zit daar ook nog iets.

Jazeker, mijn omvormer rapporteert alles naar de portal van SolarEdge.

[ Voor 12% gewijzigd door janssuhhh op 04-10-2019 09:53 ]

[Wiley99]

Kees-Jan schreef op woensdag 18 september 2019 @ 20:15:

De SolarEdgeStatusContinue file laat ik door python continue genereren, zodat ik altijd de laatste waardes inlees.

In Domoticz heb ik een dzVents aan de SlimmeMeter gekoppeld die iedere 10 seconden een update geeft:

[...]


waarin ik ook de bovenstaande SolarEdge counters update waardoor ik iedere 10 seconden een up2date stand in domoticz heb...

Bereken je toevallig ook je bruto verbruik (W) en lukt dat een beetje aardig? Ik lees ook elke 10s de slimme meter (via Youless) en SE (via solaredge-local) tegelijkertijd in een Python3 scriptje uit maar krijg toch regelmatig negatieve bruto waardes (import - levering + opwek), waarschijnlijk omdat de timing tussen de Youless / P1 en inverter toch net langs elkaar loopt. Gebeurt namelijk vooral bij wolken en dus sterk wisselvallige opwek.

[Kees-Jan]

De SolarEdge lees ik (ongeveer) elke 3 seconden uit waarbij dan een JSON file gegenereerd wordt.

In Domoticz heb ik een event aan de Power (Slimme Meter) gekoppeld die iedere 10 seconden update. In datzelfde event lees ik die JSON file in dus eigenlijk zijn alle counters dan gelijktijdig up-2-date.

Ik zie eigenlijk nooit een raar resultaat in de waardes. Ik reken in datzelfde event ook mijn "eigen gebruik" en "daadwerkelijk gebruik" uit.

[Wiley99]

Kees-Jan schreef op vrijdag 4 oktober 2019 @ 20:25:
De SolarEdge lees ik (ongeveer) elke 3 seconden uit waarbij dan een JSON file gegenereerd wordt.

In Domoticz heb ik een event aan de Power (Slimme Meter) gekoppeld die iedere 10 seconden update. In datzelfde event lees ik die JSON file in dus eigenlijk zijn alle counters dan gelijktijdig up-2-date.

Ik zie eigenlijk nooit een raar resultaat in de waardes. Ik reken in datzelfde event ook mijn "eigen gebruik" en "daadwerkelijk gebruik" uit.

Misschien is het de update frequentie van de youless/P1 inderdaad. Ik vraag beide onafhankelijk van domoticz gewoon elke 10s op, maar als ik dan toevallig de P1 op 9s sinds de vorige update raak, zit ik ernaast. Dus maar eens gaan kijken hoe ik de event van de youless in Python kan herkennen zodat ik 'm meteen na verversen kan pakken, net als in Domoticz.

[Nelus82]

Ik krijg sinds 4 dagen een error in mijn pvo-upload.log.

"cURL error, exiting: The requested URL returned error: 400 Bad Request"
"cURL error, exiting: The requested URL returned error: 403 Forbidden"

[ Voor 22% gewijzigd door Nelus82 op 30-10-2019 18:48 ]

[Tomba]

Nelus82 schreef op woensdag 30 oktober 2019 @ 16:56:
Ik krijg sinds 4 dagen een error in mijn pvo-upload.log.

"cURL error, exiting: The requested URL returned error: 400 Bad Request"
"cURL error, exiting: The requested URL returned error: 403 Forbidden"

Wordt je pvoutput wel bijgewerkt?

[Nelus82]

Tomba schreef op donderdag 31 oktober 2019 @ 08:11:
[...]

Wordt je pvoutput wel bijgewerkt?

Nee, de data wordt niet geupdate.

Wanneer ik handmatig een curl commando geef met fictieve data dan werkt het wel.

curl -d "d=20191028" -d "t=10:00" -d "v1=1000" -d "v2=150" -H "X-Pvoutput-Apikey:xxx" -H "X-Pvoutput-SystemId: xxx" https://pvoutput.org/service/r2/addstatus.jsp

Api key en system ID zijn dus in orde.

Heb voor de zekerheid de nieuwste versie van pvo-upload.php van github gehaald en de gegevens erin gezet.

[ Voor 54% gewijzigd door Nelus82 op 31-10-2019 09:01 ]

[Tomba]

Nelus82 schreef op donderdag 31 oktober 2019 @ 08:34:
[...]


Nee, de data wordt niet geupdate.

Wanneer ik handmatig een curl commando geef met fictieve data dan werkt het wel.

@Nelus82 sorry kan geen versie nummer vinden. Pvo-upload loopt echter wel gewoon nog

[...]


Api key en system ID zijn dus in orde.

Heb voor de zekerheid de nieuwste versie van pvo-upload.php van github gehaald en de gegevens erin gezet.

Oei das bijzonder, bij mij werkt ie iig nog wel. Zal zo effe versie checken.
@Nelus82 kan helaas geen versienummer vinden in het script. Hij werkt iig wel gewoon dus ik denk dat er wellicht een vreemde waarde in je database staat. Wellicht kan @Jerrythafast daarmee helpen.

[ Voor 23% gewijzigd door Tomba op 31-10-2019 15:56 ]

[Nelus82]

Tomba schreef op donderdag 31 oktober 2019 @ 09:36:
[...]

Oei das bijzonder, bij mij werkt ie iig nog wel. Zal zo effe versie checken.
@Nelus82 kan helaas geen versienummer vinden in het script. Hij werkt iig wel gewoon dus ik denk dat er wellicht een vreemde waarde in je database staat. Wellicht kan @Jerrythafast daarmee helpen.

Weet iemand de syntax om een database helemaal leeg te gooien?

[tsjoender]

Nelus82 schreef op donderdag 31 oktober 2019 @ 20:02:
[...]


Weet iemand de syntax om een database helemaal leeg te gooien?

Als echt alles uit die database weg mag, dan is een "drop database <databasenaam>;" het snelste gevolgd door het commando waarmee je die database destijds aangemaakt hebt.

[MDKlapwijk]

@tsjoender, als je mensen dat soort adviezen geeft, is het misschien wel zo handig om ze eerst een backup te laten maken:

code:

root@domoticz-01:~# mysqldump --all-databases | gzip > ~/`hostname`.`date +\%Y\%m\%dT\%H\%M`.var.lib.mysql.dump.sql.gz
-- Warning: Skipping the data of table mysql.event. Specify the --events option explicitly.
root@domoticz-01:~# l ~/
total 737992
drwx------  3 root root      4096 Nov  1 17:13 .
drwxr-xr-x 22 root root      4096 Sep 29 19:09 ..
...
-rw-r--r--  1 root root  29232520 Nov  1 17:14 domoticz-01.20191101T1713.var.lib.mysql.dump.sql.gz
...

[ocaj]

tsjoender schreef op vrijdag 1 november 2019 @ 11:22:
[...]


Als echt alles uit die database weg mag, dan is een "drop database <databasenaam>;" het snelste gevolgd door het commando waarmee je die database destijds aangemaakt hebt.

Daarmee gooi je de database weg, dat is iets anders dan leeg maken.
Leegmaken van een tabel doe je middels het "truncate"-commando. Dat moet je dan wel voor elke tabel doen.

[Jerrythafast]

Nelus82 schreef op woensdag 30 oktober 2019 @ 16:56:
Ik krijg sinds 4 dagen een error in mijn pvo-upload.log.

"cURL error, exiting: The requested URL returned error: 400 Bad Request"
"cURL error, exiting: The requested URL returned error: 403 Forbidden"

Kan 2 dingen zijn:
1. Je omvormer heeft ergens midden in de nacht een datapunt geproduceerd en bij het uploaden van dat datapunt roept PVOutput "Error: Moon Powered!". Je kunt even kijken of er in de telemetry_inverter tabel een datapunt staat dat qua tijdstip ergens midden in de nacht valt. Dat punt zou dan moeten vallen direct na het laatste datapunt datn PVOutput nog heeft geaccepteerd. Als je die eruit gooit (of de waarde van pvo_last_live in de tabel live_update verhoogt naar net voorbij dit tijdstip) moet hij vanzelf weer verder kunnen.
2. Je had gedoneerd aan PVOutput maar die donatie is verlopen én hij probeert meer data tegelijk te uploaden dan je mag doen zonder donatie (ik geloof dat het maximum voor donateurs 100 is en voor niet-donateurs 30).

Ik verwacht dat het optie 1 is.

[Rouske]

Nelus82 schreef op woensdag 30 oktober 2019 @ 16:56:
Ik krijg sinds 4 dagen een error in mijn pvo-upload.log.

"cURL error, exiting: The requested URL returned error: 400 Bad Request"
"cURL error, exiting: The requested URL returned error: 403 Forbidden"

Sinds 4 dagen zeg je, heeft het dan niet te maken met het ingaan van de wintertijd en dat je data probeert te uploaden die qua tijd in de toekomst ligt en dat PVOutput dat niet slikt?

[Nelus82]

Bedankt voor al jullie input! Helaas heb ik de reacties net te laat gelezen en heb ik de database opnieuw opgebouwd.

Alles werkt nu weer naar behoren.

[Fl4sh3r]

ZwarteIJsvogel schreef op maandag 16 september 2019 @ 10:34:
[...]

De enige route die ik nog zie om toch weer toegang te krijgen tot de HTTP-services is te proberen om de SolarEdge op je LAN via DHCP een 172.16.0/24 IP-adres te geven. Ik kan niet direct iets vinden wat dat verhindert. Het levert uiteraard wel een conflict op met het ingebouwde WiFi AP, maar wellicht werkt het als dat AP uit staat (wat vanzelf gebeurt na 5 minuten inactiviteit). Uiteraard is het, als het al werkt, geen frisse oplossing.

[...]

Dit heb ik gisteren geprobeerd op mijn SE3000H, maar te vergeefs. Via mijn LAN op 172.16.0.1 krijg ik helaas de bekende Interval Server Error.

Ik zou graag voor de volledigheid mijn exacte versienummers noteren, maar heb nog niet gevonden hoe ik die bepaal.

Edit:
CPU-versie: 4.6.27
DSP1 versie: 1.0.756
DSP2 versie: 2.0.704
Versie WSA: 1.2.9

[ Voor 5% gewijzigd door Fl4sh3r op 19-11-2019 17:57 ]

[ZwarteIJsvogel]

Fl4sh3r schreef op dinsdag 12 november 2019 @ 13:02:
[...]
Dit heb ik gisteren geprobeerd op mijn SE3000H, maar te vergeefs. Via mijn LAN op 172.16.0.1 krijg ik helaas de bekende Interval Server Error.

De door mij geschilderde route was theoretisch (niet zelf geprobeerd). Vanaf 4.7.x is deze route principieel niet meer mogelijk: toegang tot de HTTP services gaat alleen nog via het ingebouwde WiFi AP.

Edit: zo te zien heb je in elk geval nog geen 4.7.x firmware. Dan had je namelijk zelfs de Internal Server Error niet meer gekregen maar gewoon een timeout.

Ik zou graag voor de volledigheid mijn exacte versienummers noteren, maar heb nog niet gevonden hoe ik die bepaal.

SetApp gebruiken via het ingebouwde WiFi AP Zonder SolarEdge account heb je read-only toegang tot je omvormer.

Ik heb zelf een SolarEdge installer account aangemaakt (dat kan iedereen met een omvormer serienummer in de hand). Daarmee kun je alles, inclusief firmware upgraden.

[ Voor 8% gewijzigd door ZwarteIJsvogel op 12-11-2019 18:20 ]

[lolle1212]

Fl4sh3r schreef op dinsdag 12 november 2019 @ 13:02:
[...]


Dit heb ik gisteren geprobeerd op mijn SE3000H, maar te vergeefs. Via mijn LAN op 172.16.0.1 krijg ik helaas de bekende Interval Server Error.

Ik zou graag voor de volledigheid mijn exacte versienummers noteren, maar heb nog niet gevonden hoe ik die bepaal.

SetApp en dan zonder inloggen.. readonly is voldoende omde versie nummers te zien.

Om te downgraden naar een versie waar de lokale api nog beschikbaar is, moet je de firmware op een usb zetten, de omvormer deksel eraf schroeven, usb erin, en dan in in de setAPP firmware update uitvoeren van usb. (daarna disconnect, anders gaat hij weer updaten naar de nieuwste versie)

Hier meerdere malen probleemloos gedaan. Draai nu ook al flink tijdje de downgraded firmware voor de local api.

[Fl4sh3r]

Met de SetApp zie ik geen versienummers. Hieronder screenshots van wat ik wel zie.

Ik neig ernaar dan toch maar te proberen een installateurs-account aan te vragen, om te zien wat ik dan kan leren over mijn systeem...

[lolle1212]

Fl4sh3r schreef op vrijdag 15 november 2019 @ 09:34:
Met de SetApp zie ik geen versienummers. Hieronder screenshots van wat ik wel zie.

Ik neig ernaar dan toch maar te proberen een installateurs-account aan te vragen, om te zien wat ik dan kan leren over mijn systeem...

[Afbeelding]
[Afbeelding]
[Afbeelding]
[Afbeelding]

Accountje aanmaken kan sowieso, alleen Ingelogde SetApp gaat bij connectie met een omvormer zonder keus altijd fimrware updaten. (En mogelijk brengen ze een keer firmware uit waarbij downgrade naar versies met local api niet meer mogelijk is, dus ik gebruik geen ingelogde setapp ever. Daarnaast is het zo dat als je qua setApp verbind, maar dan gewoon in de browser op je telefoon naar het ip gaat van omvormer, je de setapp met alle rechten in de browser hebt (zonder account, zonder auto update)

Maar misschien hebben ze de readonly info in de APP tegenwoordig beperkt oid.

Wat je dus kan doen is : Met je telefoon verbinden met de omvormer (Accespoint van omvormer aanzetten(doen alsof je setapp gaat gebruiken,) maar dan gewoon wifi+key invoeren in je telefoon bij wifi settings en dan naar http://172.16.0.1 gaan in browser dan heb je de beheer interface wat gelijk is aan setap+inloggen, alleen dan zonder inloggen en zonder annoying auto update.

[Fl4sh3r]

lolle1212 schreef op zaterdag 16 november 2019 @ 12:18:
[...]
Wat je dus kan doen is : Met je telefoon verbinden met de omvormer (Accespoint van omvormer aanzetten(doen alsof je setapp gaat gebruiken,) maar dan gewoon wifi+key invoeren in je telefoon bij wifi settings en dan naar http://172.16.0.1 gaan in browser dan heb je de beheer interface wat gelijk is aan setap+inloggen, alleen dan zonder inloggen en zonder annoying auto update.

Ah, dat werkt wel inderdaad. Die interface is een stuk uitgebreider. Vanuit daar kan ik wel ModBus/SunSpec aanzetten. Dat is een beginnetje voor monitoring. Volgens de specificatie is dat alleen op inverter niveau en dus zonder informatie over de modules.

Versies zijn aangevuld in mijn eerdere post.

[ZwarteIJsvogel]

Fl4sh3r schreef op dinsdag 19 november 2019 @ 17:58:
Ah, dat werkt wel inderdaad. Die interface is een stuk uitgebreider. Vanuit daar kan ik wel ModBus/SunSpec aanzetten. Dat is een beginnetje voor monitoring. Volgens de specificatie is dat alleen op inverter niveau en dus zonder informatie over de modules.

Via Modbus is momenteel (CPU firmware 4.7.26 en lager) inderdaad alleen informatie over de omvormer zelf beschikbaar. Een paar weken geleden heb ik SolarEdge daarover maar eens een e-mail gestuurd (nog geen reactie). Het zou geen probleem mogen zijn om informatie over andere onderdelen van een SolarEdge-installatie toe te voegen (niet alleen de optimizers). Het is ook iets wat ik van een gerenommeerde partij als SolarEdge verwacht.

Het voordeel van Modbus/SunSpec is dat de interface gedocumenteerd is, dit in tegenstelling tot andere op reverse engineering gebaseerde methodes voor lokale monitoring die in omloop zijn. De documentatie is overigens niet meer helemaal up to date: de Modbus TCP-poort (bij SolarEdge default 1502 i.p.v. 502) blijft in de huidige firmware gewoon open, ook als er meer dan 2 minuten geen verbinding is geweest.

[Bjorn180179]

Hopelijk kan ik hier even iets vragen. Ik kon het zo snel niet vinden op het forum. Begin juli zijn de zonnepanelen aangesloten. Begin augustus is de installatie aangemeld bij solaredge. Hierdoor kan ik de opbrengsten van juli niet zien. Is het nog mogelijk dit ergens naar voren te toveren?

[Jerrythafast]

@Bjorn180179 Als de data van nadien wel gewoon bij Solaredge zijn in te zien en worden bijgewerkt, heeft de omvormer in ieder geval deze data niet meer zelf in het geheugen. De vraag is dan of de servers van SolarEdge die data wel hebben. Voor zover ik weet (maar dit is gebaseerd op ervaring uit 2016), is het antwoord:
- Als de omvormer die eerste maand wel verbonden was met internet maar de monitoring gewoon nog niet was ingesteld: ja, die data zouden ze moeten hebben. Misschien kun je een ticket bij SolarEdge inschieten om iemand ernaar te laten zoeken.
- Als de omvormer die eerste maand geen verbinding met de servers had, kan het zijn dat je de eerste paar dagen mist. Het geheugen van de omvormer gaat maar een beperkte tijd terug. Die tijd is afhankelijk van het aantal optimizers dat erop is aangesloten (en vermoedelijk ook van het model omvormer, ik kan me voorstellen dat ze door de jaren heen wat meer geheugen kunnen hebben gekregen). Hoe meer optimizers, hoe korter de gegevens bewaard kunnen worden. Je zou dan wel op zijn minst de data van een paar dagen voor het activeren van de monitoring moeten kunnen zien.

[ Voor 6% gewijzigd door Jerrythafast op 24-11-2019 14:50 ]

[Bjorn180179]

@Jerrythafast

Thanks!! Hij is later verbonden met de WiFi dus zal dit lastig gaan worden.

[jelle2503]

Goedeavond,

Sinds een maand heb ik dus zonnepanelen met een Solaredge 3000 HD Wave. Daarnaast heb ik een Youless aan mijn slimme meter hangen, dus het inzicht in verbruik en opbrengst in PVoutput is aardig.

Maar de gebrekkige logging op PVO via de SE api bevalt me niet echt, zodoende ben ik hier terecht gekomen.

Kan de logger software ook op een Asus AC66U met 380.70 merlin firmware draaien? Ik geloof dat hier Debian op draait. Dat scheelt me ook weer de omvormer op een nieuw wifi netwerk zetten.

De SE omvormer heeft een wifimodule en de kast openmaken voor het uitlezen van de sleutel lijkt me geen probleem, eerder een uitdaging. Ik heb al een FT232RL usb serial adapter voor het flashen van tasmota firmware, deze is geloof ik wel geschikt.

Ik ga dit topic even in de gaten houden, en wellicht binnenkort ermee beginnen. Weer een leuk projectje.

[Jerrythafast]

@jelle2503 Als je er Python en tcpdump op kunt draaien moet het kunnen. Meer is er in principe niet voor nodig. Ik neem aan dat je router weinig opslag heeft, dus de data zul je wel nog ergens heen moeten krijgen. se-logger schrijft dit naar een MySQL-database, dus die kun je ergens in je netwerk laten draaien. De ruwe capture data kan misschien naar een netwerkschijf, maar hoe je dat configureert op zo'n router kan ik je niet vertellen Het is ook mogelijk de ruwe capture data na verwerking gelijk weg te gooien, dan heb je geen storage daarvoor nodig maar ook geen back-up.

[ Voor 72% gewijzigd door Jerrythafast op 30-11-2019 20:19 ]

[ZwarteIJsvogel]

jelle2503 schreef op woensdag 27 november 2019 @ 21:53:
Sinds een maand heb ik dus zonnepanelen met een Solaredge 3000 HD Wave.

@jelle2503: Is dat een oud model (met display) of een nieuw model (geen display, configuratie via SetApp)? Bij de nieuwe modellen gaat wat jij beoogt niet werken.

[BosGnoom]

@ZwarteIJsvogel Zelf ben ik ook aan het kijken hoe ik mijn Solaredge omvormer kan uitlezen. In plaats van een MITM (zal niet werken, SetApp versie 4.7.26) of een RS485 verbinding, probeer ik de reguliere weg via Modbus-over-TCP te gebruiken.

In de Sunspec specificatie van Solaredge staat een en ander uitgelegd over op welke adressen wat te vinden is.

Zelf heb ik een poging gedaan om ook de informatie over de optimizers te vinden in de Modbus-TCP omgeving. Vanaf adres 55000 - 60000 en verder kan ik waardes uitlezen. Alleen, ik heb geen idee wat deze betekenen.

Staat er in de firmware hier misschien een referentie naar? Ik lees hierboven dat je vooral python code tegenkomt. Zou je me op een of andere manier de firmware toe kunnen laten komen?

[Jerrythafast]

@BosGnoom voor zover bekend is optimizerdata niet beschikbaar via Modbus-TCP. Velen hebben al geprobeerd deze data te vinden in ongedocumenteerde registers (zie bv deze comment op GitHub) maar tot nu toe heeft niemand het kunnen ontdekken...

[BosGnoom]

@Jerrythafast dat klopt. Deze opmerking had ik ook al gelezen. Maar dat betekent niet dat de informatie niet beschikbaar is, alleen dat "we" niet weten wat deze informatie is. Misschien dat in de firmware hints zitten t.a.v. de informatie op hogere Modbus adressen...

[ZwarteIJsvogel]

BosGnoom schreef op woensdag 11 december 2019 @ 10:47:
@ZwarteIJsvogel Zelf ben ik ook aan het kijken hoe ik mijn Solaredge omvormer kan uitlezen. In plaats van een MITM (zal niet werken, SetApp versie 4.7.26) of een RS485 verbinding, probeer ik de reguliere weg via Modbus-over-TCP te gebruiken.

Dat is ook de richting waarin ik bezig ben. De idee is data als JSON naar mosquitto (MQTT-broker) te sturen zodat ik gemakkelijk allerlei afnemers kan aansluiten.

In elk geval vanaf 4.7.x (misschien ook al 4.6.x) zit er geen 2 minuten idle timeout meer op de Modbus/TCP interface. Dat maakt het een stuk werkbaarder. De RS485-kabel kan voorlopig op de plank blijven liggen.

Zelf heb ik een poging gedaan om ook de informatie over de optimizers te vinden in de Modbus-TCP omgeving. Vanaf adres 55000 - 60000 en verder kan ik waardes uitlezen. Alleen, ik heb geen idee wat deze betekenen.

Interessant. Daar moet ik eens naar kijken. Iets voor de kerstdagen De kans dat dat ook SunSpec data is, lijkt mij overigens klein. En zelfs als dat wel zo zou zijn, is er het bezwaar dat het ongedocumenteerd is en dus subject to change without notice.

Staat er in de firmware hier misschien een referentie naar? Ik lees hierboven dat je vooral python code tegenkomt.

Ik heb die firmware een tijdje geleden uitgebreid gefileerd. Even wat details:

• De firmware bestaat uit een Linux kernel (zImage), een root filesystem (ubifs) en een stel device trees (dtb, vermoedelijk voor verschillende hardwarerevisies).
• De web interface is helemaal geschreven in Python. Er is een REST-api op poort 80 die door SetApp wordt gebruikt en ook een reguliere web interface op poort 8080. Beide zijn vanaf 4.6.x alleen te gebruiken via het ingebouwde WiFi Access Point (dus niet als je omvormer als WiFi client met je LAN is verbonden; die connectie gebruikt op Linuxniveau een andere netwerkinterface).
• Er draait ook een proces genaamd core_app, een gestripte 32-bit ARM executable. Deze bevat zo te zien de functionaliteit van de vorige generatie firmware (3.x). Er zitten tientallen strings in m.b.t. o.a. Modbus en optimizers, maar de functionaliteit is verder volstrekt onduidelijk.

[BosGnoom]

@ZwarteIJsvogel Bedankt voor je hulp.

Had je deze op gitlab ook al gevonden? Deze is wel van een oudere versie.

Gisteren heb ik wat zitten rondkijken in de firmware, via /etc/inittab wordt de core_app wel gestart. Ik heb nog niet gekeken naar via welke route de SetApp naar de optimizers zoekt.

Ik denk trouwens dat ik ook een andere methode ga toepassen: kijken welke Modbus adressen informatie bevatten, deze in een database stoppen en kijken wat ze over de tijd heen doen. Als de optimizers er in zitten, zou ik verwachten dat er op z'n minst 2n aan data op en neer gaat gedurende de dag.

[ZwarteIJsvogel]

BosGnoom schreef op donderdag 12 december 2019 @ 08:48:
Had je deze op gitlab ook al gevonden? Deze is wel van een oudere versie.

Ja. Die post wekte mijn nieuwsgierigheid

Gisteren heb ik wat zitten rondkijken in de firmware, via /etc/inittab wordt de core_app wel gestart. Ik heb nog niet gekeken naar via welke route de SetApp naar de optimizers zoekt.

Voor zover ik weet, doet core_app al het echte werk (aansturen van de DSP's, communicatie met de optimizers, communicatie met het SolarEdge monitoring platform, Modbus, etc.). SetApp krijgt de optimizer informatie aangeleverd via de REST-api. Allemaal vrij recht-toe-recht-aan. SolarEdge heeft het niet ingewikkelder gemaakt dan nodig is.

Edit: Bij nader inzien denk ik (zonder bewijs) dat één van de DSP's de communicatie met de optimizers regelt. Gezien de innige relatie tussen optimizers en de DC-AC conversie ligt dat voor de hand.

[ Voor 10% gewijzigd door ZwarteIJsvogel op 12-12-2019 13:42 ]

[ZwarteIJsvogel]

BosGnoom schreef op woensdag 11 december 2019 @ 10:47:
Zelf heb ik een poging gedaan om ook de informatie over de optimizers te vinden in de Modbus-TCP omgeving. Vanaf adres 55000 - 60000 en verder kan ik waardes uitlezen. Alleen, ik heb geen idee wat deze betekenen.

Ik heb van mijn SolarEdge omvormer (SE4000H, firmware 4.7.26) alle Modbusregisters uitgelezen. Ik vind SunSpec data vanaf register 40001 (*), maar ook vanaf register 1 (*). Verder zijn er nergens uitleesbare registers (ook niet tussen 55000 en 60000). De beide SunSpec datablokken zijn identiek.

Je krijgt bij Modbus een Illegal Data Address exception response als in de opgegeven range een register zit dat niet bestaat. Ik heb elk daarom elk register apart uitgelezen. Dat leverde 64k Modbus/TCP requests op in 22 minuten (ca. 50 per seconde). De SolarEdge firmware handelde die requests fluitend af

(*) Logisch registeradres (1-65536). Het registeradres in een Modbus protocol data unit is één lager (0-65535).

[Moffin]

Is de methode om de encryptie sleutel te onderscheppen (zoals in de openingspost omschreven) nog steeds actueel? Het topic is inmiddels 3 jaar oud. Of zijn er sindsdien nog ontwikkelingen geweest mbt het direct lokaal uitlezen van de solar edge omvormer?

[Jerrythafast]

Moffin schreef op vrijdag 20 december 2019 @ 10:11:
Is de methode om de encryptie sleutel te onderscheppen (zoals in de openingspost omschreven) nog steeds actueel? Het topic is inmiddels 3 jaar oud. Of zijn er sindsdien nog ontwikkelingen geweest mbt het direct lokaal uitlezen van de solar edge omvormer?

Als je een SolarEdge omvormer met een ingebouwd display hebt en die *niet* via SetApp wordt ingesteld, is het inderdaad nog steeds actueel. Nieuw geleverde omvormers zijn echter steeds vaker / meestal niet meer compatible en helaas is hier nog geen weg omheen gevonden...

Het is dus heel simpel:
Wel display, geen SetApp ==> compatible, methode beschreven in de startpost is van toepassing
Geen display, wel SetApp ==> helaasch...

[Moffin]

Super thanks voor de snelle reactie.

[JustinoFTW]

Jerrythafast schreef op vrijdag 20 december 2019 @ 10:44:
[...]

Het is dus heel simpel:
Wel display, geen SetApp ==> compatible, methode beschreven in de startpost is van toepassing
Geen display, wel SetApp ==> helaasch...

Hoi Jerry,
Nu ben ik toch ook wel benieuwd.
Ik heb via Solar-Bouwmarkt de SE4000 HD met de optie "Monitoring portaal" in de offerte.
Enig idee of ik hierbij dan ook nog de encryptie sleutel kan achterhalen? Ik zal hem tijdens installatie niet aansluiten via de netwerkkabel

[Jerrythafast]

@JustinoFTW je offerte geeft niet genoeg informatie om dat nu te kunnen zeggen. Voor zover ik weet hebben de SolarEdge omvormers "with SetApp" dezelfde modelnummers als hun voorgangers, dat betekent dat alleen Solar-Bouwmarkt je kan vertellen welke versie je precies krijgt...

[JustinoFTW]

@Jerrythafast het gaat om deze
https://www.solar-bouwmarkt.nl/se4000h-nieuw.html

In dit geval dus een nieuwe met de "SetApp"

[Jerrythafast]

@JustinoFTW zo te zien heeft die geen display, dus ik vrees dat je aan de methode beschreven in de startpost van dit topic niets gaat hebben...

[Moffin]

Als linux noob zijnde, ben ik benieuwd of er ook images rondzwerven voor een Raspberry pi waarmee de se logger icm allerhande settings kan worden verkregen?

Ikzelf zou graag de variant met port mirroring gebruiken om de solar edge encryptie key te verkijgen.

[Japie.G]

ik heb nog een HDwave 3680 met display, en heb de encryptiesleutel;. Nu heb ik een set panelen op oost en een set panelen op zuid, in 1 string.

Is er een makkelijke manier, of tutorial hoe ik die twee sets nu los zou kunnen groepen en los naar pvoutput sturen? Als het ware twee verschillende systemen? Dat geeft een beter vergelijkbaar efficiency beeld. Ik ben helaas te linux/mysql noob om dat zelf voor elkaar te boksen. Maar het lijkt me toch mogelijk op basis van de optimiser ID's? Ik zie eerder in dit topic wel wat pogingen voorbij komen, maar helaas gaat me dat wat boven de pet..

[ Voor 15% gewijzigd door Japie.G op 04-01-2020 11:05 ]

[lsluijter]

Japie.G schreef op zaterdag 4 januari 2020 @ 11:04:
..... Nu heb ik een set panelen op oost en een set panelen op zuid, in 1 string.

Is er een makkelijke manier, of tutorial hoe ik die twee sets nu los zou kunnen groepen en los naar pvoutput sturen? Als het ware twee verschillende systemen? ........

Ik heb mijn panelen op oost en west in PVOUTPUT gedefinieerd als Secondary Array. Is dat misschien iets voor je?

Loek S

[KrL]

He bah, net een tweede SolarEdge omvormer aangeschaft (een SE4000H met nog een stuk of 18 panelen) en zit al 2 uur te klooien om te proberen de local portal/API te bereiken. Kon deze direct na de installatie nog wel bereiken maar inderdaad sinds activatie/commissioning niet meer, zie dat hij is geupgrade naar 4.7.x. Mijn 'oude' SE3680H doet het nog wel prima met mijn eerder geposte script maar kan ik met de nieuwe dus wel vergeten. Zie in het topic nog wel eea voorbijkomen maar wat is concreet de beste/makkelijkste optie?

• firmware downgrade: ik zie dat dit kan, werkt het daarna ook weer en zijn er downsides?
• de oude SE3680H als master en de nieuwe SE4000H als slave via RS485: krijg ik dan de SE4000H data in de SE3680H API?
• ESP bordje op RS485?
• Modbus?

Uiteraard kan ik ook weer ouderwets aan de SolarEdge portal koppelen maar de info daar is mij te beperkt en de update frequentie niet hoog genoeg (5 min oid).

[Japie.G]

lsluijter schreef op zaterdag 4 januari 2020 @ 15:07:
[...]

Ik heb mijn panelen op oost en west in PVOUTPUT gedefinieerd als Secondary Array. Is dat misschien iets voor je?

Loek S

Dat is feitelijk wat ik wil, Maar hoe zorg je dan dat alleen de data van oost bij je oostpanelen array komt😅. Alles zit in 1 string bij mij.

[ Voor 3% gewijzigd door Japie.G op 04-01-2020 21:35 ]

[Jerrythafast]

Wat we normaliter naar PVOutput uploaden is data op stringniveau. Dit wordt 1x per 5 minuten gemeten in de omvormer. Dat is super makkelijk, want PVOutput werkt ook met een interval van 5 minuten en de getallen uit de omvormer kunnen dus rechtstreeks naar PVOutput worden gestuurd.

De optimizers meten zelf ook wel, maar deze informatie is veel minder precies en wordt bovendien niet tegelijkertijd verzameld. Het is hierdoor zelfs behoorlijk moeilijk om vanuit de optimizer-data op ongeveer dezelfde getallen uit te komen voor de hele string. Uiteraard kun je wel een inschatting maken. Dat zal inderdaad wat programmeerwerk kosten. Voornamelijk om te bepalen welke regels in de database je bij elkaar op moet tellen en dat dan op zo'n manier te doen dat het er op PVOutput met z'n 5 minuten interval nog een beetje netjes uit komt.

Als je alleen geïnteresseerd bent in het totaal aan het einde van de dag wordt het wel een stuk eenvoudiger. In dat geval kun je 's avonds wanneer de omvormer uit is voor elke groep panelen de eindbalans opmaken en dat 1x opsturen.

[ Voor 25% gewijzigd door Jerrythafast op 04-01-2020 22:06 ]

[MaikelK.]

rjhilbrink schreef op woensdag 31 juli 2019 @ 22:38:
[...]

Ik ben met pymodbus aan de slag gegaan icm twisted. Twisted zorgt ervoor dat meerdere processen gelijk lopen. Een deel van het script haalt elke 10 sec de meterstanden op en zet deze in de juiste registers. Pymodbus doet de rest richting de SE. in de SE kun je aangeven dat je een energy meter hebt. De SE gaat deze dan gelijk uitlezen via rs 485.

@rjhilbrink ik ben nog steeds erg benieuwd naar je scripts.

Zou je deze kunnen delen?

[Moffin]

lolle1212 schreef op zaterdag 16 november 2019 @ 12:18:
[...]


Accountje aanmaken kan sowieso, alleen Ingelogde SetApp gaat bij connectie met een omvormer zonder keus altijd fimrware updaten. (En mogelijk brengen ze een keer firmware uit waarbij downgrade naar versies met local api niet meer mogelijk is, dus ik gebruik geen ingelogde setapp ever. Daarnaast is het zo dat als je qua setApp verbind, maar dan gewoon in de browser op je telefoon naar het ip gaat van omvormer, je de setapp met alle rechten in de browser hebt (zonder account, zonder auto update)

Maar misschien hebben ze de readonly info in de APP tegenwoordig beperkt oid.

Wat je dus kan doen is : Met je telefoon verbinden met de omvormer (Accespoint van omvormer aanzetten(doen alsof je setapp gaat gebruiken,) maar dan gewoon wifi+key invoeren in je telefoon bij wifi settings en dan naar http://172.16.0.1 gaan in browser dan heb je de beheer interface wat gelijk is aan setap+inloggen, alleen dan zonder inloggen en zonder annoying auto update.

Interessant dit. Straks maar eens proberen.

sinds vorige staat mijn installatie al gereed om te produceren. Helaas nog niet in kunnen schakelen. Van de leverancier van de zonnepanelen heb ik nog geen 'goed admin' account waarmee ik via de setapp de optimizers kan aanmelden en het legplan kan uploaden.

Ik heb wel een admin account, maar kan daar vrij weinig mee .Zowel de sitemapper als setapp werkt niet.

Indien gebruik gemaakt wordt van : http://172.16.0.1 , is het dan nog wel mogelijk om later de setapp te gebruiken? Of eigenlijk is mijn vraag, werken de default tools van solar edge dan nog?

Zou het jammer vinden wanneer ik alles ingesteld heb via: http://172.16.0.1 dat daarna via het account van de leverancier alles weer gewiped wordt.

[ZwarteIJsvogel]

KrL schreef op zaterdag 4 januari 2020 @ 16:40:
He bah, net een tweede SolarEdge omvormer aangeschaft (een SE4000H met nog een stuk of 18 panelen) en zit al 2 uur te klooien om te proberen de local portal/API te bereiken. Kon deze direct na de installatie nog wel bereiken maar inderdaad sinds activatie/commissioning niet meer, zie dat hij is geupgrade naar 4.7.x.

De local API is niet bedoeld voor gebruik anders dan door SolarEdge zelf en daarom ook niet publiek gedocumenteerd. En dus niet toekomstvast.

firmware downgrade: ik zie dat dit kan, werkt het daarna ook weer en zijn er downsides?

Ja en ja:

• Voor zover ik weet wordt de DSP-firmware niet mee gedowngradet. Op enig moment komt er een punt waarop oudere user interface firmware (bv. 4.4.67) niet meer compatibel is met nieuwere DSP-firmware. Het is in elk geval geen ondersteunde configuratie.
• De local API in 4.4.67 en eerder heeft geen enkele beveiliging (in 4.6.x en later heeft SE dat verholpen, daarom kom je er niet meer aan). Je omvormer ligt volledige open vanaf je lokale netwerk. Vroeg of laat gaat iemand het leuk vinden om malware te schrijven die SE-omvormers aanvalt via het LAN.
• Als je ooit support nodig hebt, is de kans groot dat je eerste een upgrade maar de meest recente firmware moet doen.

Ik kan een downgrade niet aanbevelen.

de oude SE3680H als master en de nieuwe SE4000H als slave via RS485: krijg ik dan de SE4000H data in de SE3680H API?

Ik heb even gekeken in de resultaten van mijn firmwareonderzoek van een tijdje geleden: zo te zien biedt de local API alleen toegang tot de gegevens van de omvormer waarmee je rechtstreeks contact hebt. Daar is die API ook voor bedoeld (SetApp).

ESP bordje op RS485?

Ik weet niet wat je hier precies mee bedoelt.

Modbus?

Dit is de enige door SE publiek gedocumenteerde weg. En daarmee de enige toekomstvaste. Echter:

• De modbusimplementatie van SE geeft alleen informatie over de omvormer zelf, dus niet over optimizers en andere systeemcomponenten (stand van zaken 4.7.26). Ik heb een paar maanden geleden per e-mail bij SE geïnformeerd naar hun plannen met Modbus, maar nooit antwoord gekregen (strafpunten voor SE).
• SE ondersteunt voor zover ik weet geen Modbus gateway functionaliteit in een omvormer (bv. om een slave uit te lezen via Modbus/TCP naar de master). In dat geval zul je beide omvormers aan het LAN moeten hangen (Modbus/TCP) of de 2e RS485-interface aansluiten (Modbus/RTU, voor het geval je omvormer een 2e RS485-interface heeft).
• Momenteel is er geen hapklare oplossing voor lokale SolarEdge monitoring via Modbus (ik ken ze in elk geval niet).

[Moffin]

Moffin schreef op zondag 5 januari 2020 @ 06:34:
[...]


Interessant dit. Straks maar eens proberen.

sinds vorige staat mijn installatie al gereed om te produceren. Helaas nog niet in kunnen schakelen. Van de leverancier van de zonnepanelen heb ik nog geen 'goed admin' account waarmee ik via de setapp de optimizers kan aanmelden en het legplan kan uploaden.

Ik heb wel een admin account, maar kan daar vrij weinig mee .Zowel de sitemapper als setapp werkt niet.

Indien gebruik gemaakt wordt van : http://172.16.0.1 , is het dan nog wel mogelijk om later de setapp te gebruiken? Of eigenlijk is mijn vraag, werken de default tools van solar edge dan nog?

Zou het jammer vinden wanneer ik alles ingesteld heb via: http://172.16.0.1 dat daarna via het account van de leverancier alles weer gewiped wordt.

Mmm, helaas lukt installatie via local ip niet. Blijft in een rode balk bovenaan de pagina staan (please activate inverter). Vervolgens is het niet mogelijk instellingen op te slaan.

[lsluijter]

Japie.G schreef op zaterdag 4 januari 2020 @ 21:34:
[...]


Dat is feitelijk wat ik wil, Maar hoe zorg je dan dat alleen de data van oost bij je oostpanelen array komt😅. Alles zit in 1 string bij mij.

Het is niet ideaal, maar door de juiste azimuth op te geven krijg je een benadering.

[KrL]

ZwarteIJsvogel schreef op zondag 5 januari 2020 @ 08:17:
[...]
Ik kan een downgrade niet aanbevelen.

Ok, gaan we die niet doen

ZwarteIJsvogel schreef op zondag 5 januari 2020 @ 08:17:
Ik heb even gekeken in de resultaten van mijn firmwareonderzoek van een tijdje geleden: zo te zien biedt de local API alleen toegang tot de gegevens van de omvormer waarmee je rechtstreeks contact hebt. Daar is die API ook voor bedoeld (SetApp).

Thanks, scheelt me weer proberen/vogelen.

ZwarteIJsvogel schreef op zondag 5 januari 2020 @ 08:17:
Ik weet niet wat je hier precies mee bedoelt.

Bedoel een stukje standaard hardware (ESP8266 met een stukje custom firmware) aangesloten op de RS485 om hem op die manier uit te lezen. Lijkt me mogelijk maar ik ga voor Modbus (zie onder).

ZwarteIJsvogel schreef op zondag 5 januari 2020 @ 08:17:
Dit is de enige door SE publiek gedocumenteerde weg. En daarmee de enige toekomstvaste. Echter:

• De modbusimplementatie van SE geeft alleen informatie over de omvormer zelf, dus niet over optimizers en andere systeemcomponenten (stand van zaken 4.7.26). Ik heb een paar maanden geleden per e-mail bij SE geïnformeerd naar hun plannen met Modbus, maar nooit antwoord gekregen (strafpunten voor SE).
• SE ondersteunt voor zover ik weet geen Modbus gateway functionaliteit in een omvormer (bv. om een slave uit te lezen via Modbus/TCP naar de master). In dat geval zul je beide omvormers aan het LAN moeten hangen (Modbus/TCP) of de 2e RS485-interface aansluiten (Modbus/RTU, voor het geval je omvormer een 2e RS485-interface heeft).
• Momenteel is er geen hapklare oplossing voor lokale SolarEdge monitoring via Modbus (ik ken ze in elk geval niet).

Heb gisteren al een beetje lopen zoeken en klooien en heb hem inmiddels werkend met Modbus. Zoals je aangeeft met minder (optimizer) specifieke informatie maar voldoende voor mijn doel: het near-realtime uitlezen van het vermogen.

Hoewel misschien niet hapklaar, toch een aantal goede bronnen waarmee het voor de diverse home automation platformen werkend te krijgen is:

• Sunspec monitor (perl)
• Domoticz implementatie obv bovengenoemde Sunspec monitor
• Openhab implementatie
• Pysunspec (Python)
• Ardexa implementatie obv Pysunspec

Zelf heb ik het werkend met Home Asistant dmv de volgende config:

code:

modbus:
  - type: tcp
    host: 192.168.0.250
    port: 1502
    name: solaredge2

sensor:
  - platform: modbus
    registers:
    - name: SolarEdge2_Power
      hub: solaredge2
      unit_of_measurement: W
      slave: 1
      register: 83
      precision: 1
      scale: 0.01
    - name: SolarEdge2_ACfreq
      hub: solaredge2
      unit_of_measurement: Hz
      slave: 1
      register: 85
      data_type: uint
      precision: 2
      scale: 0.001
    - name: SolarEdge2_Energy
      hub: solaredge2
      unit_of_measurement: kWh
      slave: 1
      register: 93
      count: 2
      scale: 0.001
      precision: 2
      data_type: uint
    - name: SolarEdge2_DCvolt
      hub: solaredge2
      unit_of_measurement: V
      slave: 1
      register: 98
      precision: 2
      scale: 0.1
      data_type: uint
    - name: SolarEdge2_temp
      hub: solaredge2
      unit_of_measurement: °C
      slave: 1
      register: 103
      precision: 2
      scale: 0.01
    - name: SolarEdge2_status
      hub: solaredge2
      slave: 1
      register: 107
      data_type: uint

[Wiley99]

@KrL dank je voor de links, mij local API werkt nog maar als dat ooit stopt vanwege een noodzakelijke upgrade dan kom ik hier terug. Staat er ook ergens in wat je feitelijk in die modbus prikt? Liefst heb ik een of ander goedkoop wifi interfaceje dat ik vanaf mijn RPi's beneden kan uitlezen...

[KrL]

Wiley99 schreef op zondag 5 januari 2020 @ 21:23:
@KrL dank je voor de links, mij local API werkt nog maar als dat ooit stopt vanwege een noodzakelijke upgrade dan kom ik hier terug. Staat er ook ergens in wat je feitelijk in die modbus prikt? Liefst heb ik een of ander goedkoop wifi interfaceje dat ik vanaf mijn RPi's beneden kan uitlezen...

Nog veel makkelijker: in je setapp pagina onder communicatie de optie modbus over TCP aanzetten (kan zelfs nu al) en je kunt hem benaderen via je netwerk. Schijnbaar zit er onder de oudere firmware (waar local API nog werkt) een time out op van 2 minuten na aanzetten die er in latere versies af is maar voorlopig heb je m toch nog niet nodig

[Wiley99]

Oh wauw, dat is inderdaad makkelijk. Toch maar eens gaan experimenteren dan, ik zie net dat ik het kan inschakelen op de webpagina (zonder te upgraden, geen mobiele setapp met admin login starten) en dan heb ik de scripts al klaar. Hopelijk kan het tegelijkertijd. Dank je!

Maar eerst eerste werkdag van het jaar, moet ook...

[ocaj]

[b]ZwarteIJsvogel in "[SolarEdge] Omvormers en optimizers zelf monitoren"ZwarteIJsvogel schreef op zondag 5 januari 2020 @ • SE ondersteunt voor zover ik weet geen Modbus gateway functionaliteit in een omvormer (bv. om een slave uit te lezen via Modbus/TCP naar de master). In dat geval zul je beide omvormers aan het LAN moeten hangen (Modbus/TCP) of de 2e RS485-interface aansluiten (Modbus/RTU, voor het geval je omvormer een 2e RS485-interface heeft).

Ja en Nee. Solaredge ondersteunt wel de mogelijkheid om 1 omvormer als Master in te stellen dan via de RS485-aansluitingen door te lussen naar andere omvormers. De Master-omvormer communiceert dan met de portal. Maar het is geen standaard modbus wat er over de RS485-verbinding gebabbeld wordt, maar een propriatary protocol.
In de instellingen heet deze mogelijkheid geen RS485, maar "Solaredge". Ook kun je er geen baudrate voor instellen, die is fixed: 115200 baud.
Maar het werkt uitstekend. Ik heb 2 omvormers (oude pre-HD versie), beide als Solaredge-"slave" ingesteld en deze beide via de RS485-aansluitingen doorgelust naar een raspberry pi.
Middels de hier wel eerder genoemde scripts van jbuehl (https://github.com/jbuehl/solaredge ) gedraagt die raspberry pi zich als solaredge master en zo krijg ik informatie van mijn beide omvormers binnen.

Hoe dat in actuele firmware werkt weet ik niet (mijn omvormers hangen niet aan internet en krijgen dus geen firmware updates), maar de aansluitmogelijkheid is breed gedocumenteerd (met name voor grote plants met veel omvormers), dus zal vermoedelijk wel gewoon blijven werken.

[ZwarteIJsvogel]

ocaj schreef op dinsdag 7 januari 2020 @ 00:43:
[...]
Ja en Nee. Solaredge ondersteunt wel de mogelijkheid om 1 omvormer als Master in te stellen dan via de RS485-aansluitingen door te lussen naar andere omvormers. De Master-omvormer communiceert dan met de portal. Maar het is geen standaard modbus wat er over de RS485-verbinding gebabbeld wordt, maar een propriatary protocol.

Het is zelfs helemaal geen modbus. RS485 en modbus worden ten onrechte nog wel eens op een hoop gegooid. RS485 is alleen de elektrische interface, modbus is één van de protocollen die je daar overheen kunt draaien (en het SolarEdge protocol een ander).

[ocaj]

@ZwarteIJsvogel Klopt, daarom zei ik ook "ja en nee":
Ja: Solaredge ondersteunt een master-slave-opstelling waarbij meerdere omvormers hun meetgegevens doorgeven aan één master (via het solaredge-protocol)
Nee: Dat is geen modbus-gateway.

[stormfly]

<lama> het werkt ;-)

[ Voor 123% gewijzigd door stormfly op 26-01-2020 16:49 ]

[binsentsu]

Hey. Deze week solaredge omvormer geplaatst en aangezien deze ook op nieuwste firmware zit en dus de local http API niet werkt, heb ik me beziggehouden met een Home-Assistant Solaredge Modbus integratie te schrijven. Misschien dat andere Home-Assistant gebruikers hier, er ook wat mee zijn:
https://github.com/binsentsu/home-assistant-solaredge-modbus

[andrerij]

Vandaag loopt de tijd van de se-logger een uur voor terwijl op de site van solaredge de goede tijd wordt aangegeven. Hebben andere dit ook?

[BizzieBis]

@andrerij Hier hetzelfde. Ik dacht al dat ik gek aan het worden was

De laatste update tijd in de SolarEdge app geeft ook de verkeerde tijd aan..

[ Voor 34% gewijzigd door BizzieBis op 07-02-2020 22:16 ]

[andrerij]

Vandaag loopt de tijd weer normaal. Er is dus iets bij solaredge niet goed gegaan.

[Sende115]

@KrL Bedankt voor de config! Werkt inderdaad prima. Het enige waar ik nog naar op zoek ben is de waarde voor de ACvolt register, Ik heb wel het een en ander geprobeerd, maar kreeg niet de juiste gegevens terug.

[thavini]

Super integratie. Ik heb hem via hacs geïnstalleerd (zelf de repo URL toegevoegd). Werkt fantastisch en volgens mij klopt alles, zo even snel gecheckt.
Ik kan een beetje programmeren maar heb nog nooit met eigen integraties gespeeld.

binsentsu schreef op zondag 26 januari 2020 @ 23:28:
Hey. Deze week solaredge omvormer geplaatst en aangezien deze ook op nieuwste firmware zit en dus de local http API niet werkt, heb ik me beziggehouden met een Home-Assistant Solaredge Modbus integratie te schrijven. Misschien dat andere Home-Assistant gebruikers hier, er ook wat mee zijn:
https://github.com/binsentsu/home-assistant-solaredge-modbus

Voor de rest, mijn local API was al niet meer beschikbaar versie 4.6.x vanaf installatie vorig zomer. ik heb een installateur account aangemaakt zodat ik in de SetApp kan inloggen. Vervolgens heb ik vanmorgen de stappen in die app doorlopen incl. verplichte update naar versie 4.7.x. Daarna kon ik kiezen inbedrijfstelling oid. en kreeg ik het bekende dashboard in de app. Vervolgens kon ik bij communicatie de TCP modbus inschakelen en mijn home assistent was geconnect. Tevens werkt de SolarEdge app voor monitoring ook gewoon en is er niets stuk wat door de installateur is aangemaakt.

Er is dus een redelijk simpele manier om lokaal de monitoring wel aan de praat te krijgen mits het systeem dat je wilt gebruiken iets van modbus kan uitlezen of er is iets gebouwd zoals de mooie integratie van @binsentsu

[ZwarteIJsvogel]

Sende115 schreef op zaterdag 8 februari 2020 @ 22:59:
@KrL Bedankt voor de config! Werkt inderdaad prima. Het enige waar ik nog naar op zoek ben is de waarde voor de ACvolt register, Ik heb wel het een en ander geprobeerd, maar kreeg niet de juiste gegevens terug.

Je zou verwachten dat deze waarde in register I_AC_VoltageAN staat (spanning tussen fase A en nul). Dit register geeft echter altijd de waarde 0x8000 0xffff terug (SunSpec: not implemented).

Bij een SolarEdge 1-fase inverter vind je de netspanning in register I_AC_VoltageAB (spanning tussen fase A en fase B!). Ik heb geen idee waarom SolarEdge heeft gekozen voor deze merkwaardige implementatie, maar zo werkt het in elk geval bij mijn SE4000H met firmware 4.7.26..

Let op! I_AC_VoltageAB is een integerwaarde waarop je de scale factor I_AC_Voltage_SF moet toepassen. Een scale factor (SF) is zelf weer een geheel getal (-10 tot 10) dat je als exponent van 10 moet gebruiken om de feitelijke vermenigvuldigingsfactor te krijgen (die is dus 10 ^ SF).

[Sende115]

@ZwarteIJsvogel Bedankt voor je reactie,
Echter ben ik op zoek naar de register waarde zoals in het script van @KrL gebruikt wordt, zodat ik dat kan toevoegen.
Helaas kom ik deze waardetabel niet op internet tegen. Ik heb wel een aantal waardes uit de documentatie van SolarEdge geprobeerd, maar ik kreeg of geen data terug, of waardes welke onmogelijk zijn (6000 volt?!).

[ZwarteIJsvogel]

Een SolarEdge inverter kun je via Modbus uitlezen vanaf het SunSpec standaard basisadres (40001, zoals genoemd in het Sunspecdocument van SolarEdge) en vanaf een alternatief basisadres (1). Dat zijn PLC registeradressen (1-65536). Modbus registeradressen zijn eentje lager (0-65535).

De registernummers voor het script zijn de nummers zoals genoemd in het SunSpecdocument van SolarEdge minus 40001 (alternatief basisadres, Modbus registeradressering). Het volgende zou moeten werken:

code:

    - name: SolarEdge2_ACvolt
      hub: solaredge2
      unit_of_measurement: V
      slave: 1
      register: 76
      precision: 2
      scale: 0.1
      data_type: uint

Het gebruik van een vaste scale factor is overigens riskant. De scale factor kan namelijk in principe elke keer anders zijn, al zal dat hier vermoedelijk niet het geval zijn.

Edit: Het opgewekte vermogen is zo'n register waarbij de scale factor varieert. Bij mijn SE4000H (firmware 4.7.26) is die 0.01 bij lage vermogens en 0.1 of 1.0 bij hogere vermogens.

[ Voor 42% gewijzigd door ZwarteIJsvogel op 11-02-2020 12:49 ]