Datalogging: PV systemen

[DRvDijk]

I went down the rabbit hole Op poort 8899 lijkt nul komma niks aan reactie te komen, wat ik er ook ingooi. Dus ben ik maar aan het packet sniffen geslagen, en daar lijk ik nu best een aardig eindje mee te komen. Ik geloof 6 typen pakketten naar de server te zien gaan, en 6 typen vanaf de server terug te komen. Daarin _zie_ ik sowieso het locale IP van de wifi stick langskomen, als ook de netwerk naam, en het serienummer & software versie van de omvormer. Ik hoop dat ik niet mijn wachtwoord terugvindt!

[TWyk]

DRvDijk schreef op donderdag 10 oktober 2019 @ 23:09:
...

Precieze type WiFi ding weet ik niet. Er zit een sticker op met “S/N 0518....”, en aan de achterkant een sticker met model LSW-241B1032. Je kunt er op inloggen (althans, nu niet, hele ding lijkt uit te staan als het donker hoort dat?) en dan kun je WiFi instellingen doen, en ook een tweede “remote server” opgeven, host/port en danwel tcp of udp. Ik heb alleen nog niet gevonden wat die server dan moet praten. Wel weet ik dat hij verbind naar data1.solarmanpv.com (daar zag ik een dns lookup voor), maar wat hij stuurt weet ik dus niet. Iemand een idee?

Daarnaast staat dus poort 80 open, en ook 8899. Maar wat je daarmee kan? Wie kan me iets verder op weg helpen?

Heb je al met je browser verbonden aan de omvormer ?

Als het goed is is er een menu waarin zaken zijn ingesteld voor je het automatisch versturen van data naar een standaard monitoring pagina.
Maar als het goed is kun je daar ook een extra servertje instellen om data te versturen.

Bij dergelijke omvormers vaak via "Advanced" => "Remote server" => "New" => IP adres van je computer / poort invullen" en starten.
Dan gaat de omvormer daar elke paar minuten data heen sturen die je met een script kan ontvangen.

[DRvDijk]

TWyk schreef op woensdag 16 oktober 2019 @ 15:35:
[...]


Heb je al met je browser verbonden aan de omvormer ?

Als het goed is is er een menu waarin zaken zijn ingesteld voor je het automatisch versturen van data naar een standaard monitoring pagina.
Maar als het goed is kun je daar ook een extra servertje instellen om data te versturen.

Bij dergelijke omvormers vaak via "Advanced" => "Remote server" => "New" => IP adres van je computer / poort invullen" en starten.
Dan gaat de omvormer daar elke paar minuten data heen sturen die je met een script kan ontvangen.

Yep, geprobeerd. Nul aanroepen op die server. Staat ook geen "test" knopje rechts van de input opties en ik kan maar één alternatieve server invullen, alsof het nét een andere versie is dan de screenshots van andere interfaces die ik gezien heb. Maar helaas, dat werkt dus niet.
Daarnaast, wat áls het zou werken, is er informatie over het protocol waarin ze het zouden sturen? Ik ben namelijk eenzelfde route aan het belopen, maar dan met packet sniffing en onderschepping naar hun server.

[TWyk]

DRvDijk schreef op woensdag 16 oktober 2019 @ 15:39:
[...]

Yep, geprobeerd. Nul aanroepen op die server. Staat ook geen "test" knopje rechts van de input opties en ik kan maar één alternatieve server invullen, alsof het nét een andere versie is dan de screenshots van andere interfaces die ik gezien heb. Maar helaas, dat werkt dus niet.
Daarnaast, wat áls het zou werken, is er informatie over het protocol waarin ze het zouden sturen? Ik ben namelijk eenzelfde route aan het belopen, maar dan met packet sniffing en onderschepping naar hun server.

Mijn omvormer gooit gewoon een voorloop code en een setje hexadecimale getallen in een berichtje van ongeveer 200 bytes.
Dat zal wel per omvormer verschillen.

Misschien kun je een screenshot plaatsen van de interface waar je de remote servergegevens invult (evt aangevuld met de gegevens die je hebt ingevuld) zodat iemand die kan herkennen omdat het lijkt op zijn/haar omvormer interface

[ Voor 3% gewijzigd door TWyk op 16-10-2019 16:11 ]

[DRvDijk]

TWyk schreef op woensdag 16 oktober 2019 @ 16:09:
[...]

Mijn omvormer gooit gewoon een voorloop code en een setje hexadecimale getallen in een berichtje van ongeveer 200 bytes.
Dat zal wel per omvormer verschillen.

Misschien kun je een screenshot plaatsen van de interface waar je de remote servergegevens invult (evt aangevuld met de gegevens die je hebt ingevuld) zodat iemand die kan herkennen omdat het lijkt op zijn/haar omvormer interface

Zo, het duurde even voordat ik overdag een screenshot kon maken. 's Avonds doet-ie het niet zo goed



Deze logger "praat" echt met de backend, hij verwacht berichten terug. Elk bericht begint met 0xA5 en eindigt met 0x15. Er lijken dus een zestal berichten heen en terug te gaan: een type 0x41 wordt beantwoord met 0x11, 0x42 met 0x12, etc.

[TWyk]

DRvDijk schreef op zondag 20 oktober 2019 @ 19:07:
[...]
Deze logger "praat" echt met de backend, hij verwacht berichten terug. Elk bericht begint met 0xA5 en eindigt met 0x15. Er lijken dus een zestal berichten heen en terug te gaan: een type 0x41 wordt beantwoord met 0x11, 0x42 met 0x12, etc.

Die berichten zullen wel de standaard communicatie vormen met de solarman webservers die de gegevens van je omvormer loggen.

Als je server B toevoegt met het adres van je PC en een port nummer zouden er berichten naar je PC moeten komen.
Je kunt op de PC een tool als netcat gebruiken als listener op die port om de berichten op te vangen

code:

nc -l 9999 > omvormerdata.txt

[DRvDijk]

TWyk schreef op maandag 21 oktober 2019 @ 14:49:
[...]

Die berichten zullen wel de standaard communicatie vormen met de solarman webservers die de gegevens van je omvormer loggen.

Als je server B toevoegt met het adres van je PC en een port nummer zouden er berichten naar je PC moeten komen.
Je kunt op de PC een tool als netcat gebruiken als listener op die port om de berichten op te vangen

code:

nc -l 9999 > omvormerdata.txt

Yep, dat had ik geprobeerd dus, maar helaas. Geen enkele aanroep op wat ik er ook invul (pi.local, 192.168.x.x, etc etc), tcp (nc -l 2134) danwel udp (nc -ul 1234). Ik ga proberen een tcp proxy ertussenin te proppen

[Jazsie]

DRvDijk schreef op zondag 20 oktober 2019 @ 19:07:
[...]

Zo, het duurde even voordat ik overdag een screenshot kon maken. 's Avonds doet-ie het niet zo goed

[Afbeelding]

Deze logger "praat" echt met de backend, hij verwacht berichten terug. Elk bericht begint met 0xA5 en eindigt met 0x15. Er lijken dus een zestal berichten heen en terug te gaan: een type 0x41 wordt beantwoord met 0x11, 0x42 met 0x12, etc.

Heb je nu een Sofar? Want mijn Omnik heeft exact de zelfde web interface

Port 8899 gebruik ik om de data uit te lezen met een python script en op te slaan in MySQL/PVOutput
En via MySQL naar Grafana voor mooie grafieken.

Werkt "/js/status.js" bij jouw? Zo ja, daar kan je ook heel veel info afhalen...

*Tevens heb ik een ongeldige Gateway/DNS opggeven zodat ie niet met de backend loopt te praten want bij Omnik werkt de portal ook maar de helft van de tijd*. Dus liever alles lokaal.

[ Voor 3% gewijzigd door Jazsie op 21-10-2019 16:08 . Reden: Typo ]

[DRvDijk]

Jazsie schreef op maandag 21 oktober 2019 @ 16:06:
[...]


Heb je nu een Sofar? Want mijn Omnik heeft exact de zelfde web interface

Port 8899 gebruik ik om de data uit te lezen met een python script en op te slaan in MySQL/PVOutput

Werkt "/js/status.js" bij jouw? Zo ja, daar kan je ook heel veel info afhalen...

*Tevens heb ik een ongeldige Gateway/DNS opggeven zodat ie niet met de backend loopt te praten want bij Omnik werkt de portal ook maar de helft van de tijd*.

Yes het is een Sofar, maar niet officieel een "Omnik" logger. Poort 8899 staat open, maar is echt een zwart gat. Niks erheen geeft enkele vorm van reactie. Dus "/js/status/js" werkt helaas ook niet

[Jazsie]

DRvDijk schreef op maandag 21 oktober 2019 @ 16:08:
[...]

Yes het is een Sofar, maar niet officieel een "Omnik" logger. Poort 8899 staat open, maar is echt een zwart gat. Niks erheen geeft enkele vorm van reactie. Dus "/js/status/js" werkt helaas ook niet

Port 8899 reageert bij mij ook op niks. Enkel met de python script. Misschien proberen waard...
Mijn omvormer wordt ook niet ondersteund maar werkt wel ermee.

Edit:
/js/status/js moet je op de gewone webinterface proberen, niet 8899.

*https://github.com/Woutrrr/Omnik-Data-Logger*

[ Voor 6% gewijzigd door Jazsie op 21-10-2019 16:12 ]

[DRvDijk]

Jazsie schreef op maandag 21 oktober 2019 @ 16:11:
[...]


Port 8899 reageert bij mij ook op niks. Enkel met de python script. Misschien proberen waard...
Mijn omvormer wordt ook niet ondersteund maar werkt wel ermee.

Edit:
/js/status/js moet je op de gewone webinterface proberen, niet 8899.

*https://github.com/Woutrrr/Omnik-Data-Logger*

Ik had die repo al eens gecloned, maar kan daar geen /js/status/js in vinden aha in de reply quote die ik nu aan het typen ben zie ik je suggestie die op de daadwerkelijke interne website te proberen Juist, morgen als er weer wat licht is weer proberen, nét te laat

Maar die repo dus al eens geprobeerd met LiveStats.py:

code:

python LiveStats.py                                                                                                                   G:master[3Y,9M] 526085c
2019-10-21 17:58:43,091 DEBUG Importing output plugin ConsoleOutput
2019-10-21 17:58:43,092 INFO connecting to 192.168.xx.x port 8899
Traceback (most recent call last):
  File "LiveStats.py", line 17, in <module>
    omnik_exporter.run()
  File "/Users/drvdijk/Downloads/_NoBackup/Omnik-Data-Logger/OmnikExport.py", line 73, in run
    data = inverter_socket.recv(1024)
socket.timeout: timed out

Wél is mijn tcp proxy nu gelukt. In elkaar gehackt stukje java code dat een poort uitluistert, en de verbinding doorstuurt naar een ander ip/host, draaiend in een docker container op de NAS. Inhoud van de berichten zelf snap ik ondertussen ook grotendeels, dus daar kan ik wel een InfluxDB output tegenaan hacken denk ik.

Wordt weer vervolgt!

[Jazsie]

DRvDijk schreef op maandag 21 oktober 2019 @ 18:47:
[...]


Ik had die repo al eens gecloned, maar kan daar geen /js/status/js in vinden aha in de reply quote die ik nu aan het typen ben zie ik je suggestie die op de daadwerkelijke interne website te proberen Juist, morgen als er weer wat licht is weer proberen, nét te laat

Maar die repo dus al eens geprobeerd met LiveStats.py:

code:

python LiveStats.py                                                                                                                   G:master[3Y,9M] 526085c
2019-10-21 17:58:43,091 DEBUG Importing output plugin ConsoleOutput
2019-10-21 17:58:43,092 INFO connecting to 192.168.xx.x port 8899
Traceback (most recent call last):
  File "LiveStats.py", line 17, in <module>
    omnik_exporter.run()
  File "/Users/drvdijk/Downloads/_NoBackup/Omnik-Data-Logger/OmnikExport.py", line 73, in run
    data = inverter_socket.recv(1024)
socket.timeout: timed out

Wél is mijn tcp proxy nu gelukt. In elkaar gehackt stukje java code dat een poort uitluistert, en de verbinding doorstuurt naar een ander ip/host, draaiend in een docker container op de NAS. Inhoud van de berichten zelf snap ik ondertussen ook grotendeels, dus daar kan ik wel een InfluxDB output tegenaan hacken denk ik.

Wordt weer vervolgt!

Netjes, ben benieuwd!

*Mocht je het morgen proberen het correcte is "/js/status.js" en niet "/js/status/js"*

[TWyk]

DRvDijk schreef op maandag 21 oktober 2019 @ 16:08:
[...]

Yes het is een Sofar, maar niet officieel een "Omnik" logger. Poort 8899 staat open, maar is echt een zwart gat. Niks erheen geeft enkele vorm van reactie. Dus "/js/status/js" werkt helaas ook niet

Berichten sturen naar de omvormer is volgens mij nutteloos. Alleen de webinterface is benaderbaar van buitenaf.

De extra ingestelde remote server stuurt gewoon elke 5 of 6 minuten een bericht richting het ingestelde IP adres:port op je PC maar reageert waarschijnlijk zelf nergens op.

[DRvDijk]

TWyk schreef op dinsdag 22 oktober 2019 @ 10:48:
[...]


Berichten sturen naar de omvormer is volgens mij nutteloos. Alleen de webinterface is benaderbaar van buitenaf.

...

Jazsie suggereerde het proberen van het Python script in deze repository: https://github.com/Woutrrr/Omnik-Data-Logger . Dat script stuurt toch berichten naar de omvormer logger om zo de omvormer's registers uit te lezen?

De extra ingestelde remote server stuurt gewoon elke 5 of 6 minuten een bericht richting het ingestelde IP adres:port op je PC maar reageert waarschijnlijk zelf nergens op.

Ik heb die extra server dus op verschillende manieren ingevuld. IP, hostname, tcp, udp, van alles geprobeerd. De server die ik er opgeef is wel degelijk beschikbaar op het interne netwerk, namelijk zo'n "nc -l 1234" commando. Daar kan ik ook op verbinden met een andere client, dus dat zou de logger ook wel moeten kunnen. Sterker nog, de logger verbindt er ook op als ik de DNS zo aanpas dat de Chinese hostname naar mijn locale server resolved (maar het nc commando geeft geen "goeie" antwoorden voor de logger natuurlijk).

Jazsie schreef op maandag 21 oktober 2019 @ 19:35:
[...]


...

*Mocht je het morgen proberen het correcte is "/js/status.js" en niet "/js/status/js"*

Er is geen "/js/status.js" helaas: de web interface laadt slechts "status.html". Daarin staat een stukje javascript:

JavaScript:

var webdata_sn = "SH1xxxxxxxxxxx  ";
var webdata_msvn = "V110";
var webdata_ssvn = "";
var webdata_pv_type = "SH1ES136";
var webdata_rate_p = "";
var webdata_now_p = "180";
var webdata_today_e = "3.46";
var webdata_total_e = "48.0";
var webdata_alarm = "";
var webdata_utime = "0";
var cover_mid = "518xxxxxx";
var cover_ver = "MW_08_2701_1.13";
var cover_wmode = "STA";
var cover_ap_ssid = "xxxx";
var cover_ap_ip = "10.10.100.254";
var cover_ap_mac = "F0xxxxxxxxxx";
var cover_sta_ssid = "xxxx";
var cover_sta_rssi = "82%";
var cover_sta_ip = "192.168.x.x";
var cover_sta_mac = "F0xxxxxxxxxx";
var status_a = "1";
var status_b = "0";
var status_c = "0";

Dat zou ik kunnen scrapen, maar dan denk ik dat ik nu al verder ben met de data uit de verschillende pakketjes die ik onderschep.

[Jazsie]

Je bent goed op weg @DRvDijk !

Ja die status.html is leuk maar heb je natuurlijk weinig aan.

Hoop dat je verder komt met het onderscheppen van de data!

[JustinoFTW]

Mack80 schreef op donderdag 18 april 2019 @ 20:31:
Wellicht vind ik hier de oplossing.
Ik heb een x aantal panelen van het merk Autarco en op de omvormer een WiFi stick en kan via de app mijn opbrengst aflezen. (Of via de webpagina)
Als ik output wil loggen naar pvoutput moet ik alles handmatig doen. Kan het zijn dat het systeem zo gesloten is dat benaderen alleen maar via hun app kan?
Weet iemand dat?
Overigens als ik inlog in mijn configuratie praten ze over een ginlong stick

Ben je hier verder mee gekomen? Ik sta op het punt om dit systeem te nemen, maar kan het zo snel even niet vinden.
In het Autarco inverter blad staat namelijk "Easy integration in Z-wave based Smart Home systems"

[Mack80]

JustinoFTW schreef op zondag 27 oktober 2019 @ 20:12:
[...]


Ben je hier verder mee gekomen? Ik sta op het punt om dit systeem te nemen, maar kan het zo snel even niet vinden.
In het Autarco inverter blad staat namelijk "Easy integration in Z-wave based Smart Home systems"

Heb mij er eerlijk gezegd ook niet meer in verdiept. Kan m’n opbrengst goed in de app zien. En opzich geen drama dat ik niet kan loggen naar pvoutput. Uiteindelijk levert dat niks op😀

[AUijtdehaag]

@Mack80
Het voordeel van pvoutput is, dat je dagen over elkaar heen kan leggen en vergelijken.
Stel dat je panelen ineens minder gaan doen, hoe wil je dat ontdekken?
En Autarco failliet, logging weg?

https://www.energienieuws...t-als-eerste-een.html?m=1
Ah. Des te meer reden om het zelf te loggen. Zo voorkom je het ja/nee spelletje als er wat mis is.

[ Voor 40% gewijzigd door AUijtdehaag op 28-10-2019 05:22 ]

[JustinoFTW]

AUijtdehaag schreef op maandag 28 oktober 2019 @ 05:16:
@Mack80
Het voordeel van pvoutput is, dat je dagen over elkaar heen kan leggen en vergelijken.
Stel dat je panelen ineens minder gaan doen, hoe wil je dat ontdekken?
En Autarco failliet, logging weg?

https://www.energienieuws...t-als-eerste-een.html?m=1
Ah. Des te meer reden om het zelf te loggen. Zo voorkom je het ja/nee spelletje als er wat mis is.

Kijk, dat is dus wel handig om te doen.
Ga mij er even verder in verdiepen, kijken in hoevere de mogelijkheden zijn.

[Mack80]

AUijtdehaag schreef op maandag 28 oktober 2019 @ 05:16:
@Mack80
Het voordeel van pvoutput is, dat je dagen over elkaar heen kan leggen en vergelijken.
Stel dat je panelen ineens minder gaan doen, hoe wil je dat ontdekken?
En Autarco failliet, logging weg?

https://www.energienieuws...t-als-eerste-een.html?m=1
Ah. Des te meer reden om het zelf te loggen. Zo voorkom je het ja/nee spelletje als er wat mis is.

Deels eens wat je zegt. Maar het systeem is zo gesloten dat je niet automatisch kan loggen naar andere sites. En stel dat het wel kan...dan is het te zien. Ga je het spelletje winnen? Nooit. Ze zijn niet helemaal gek bij Autarco. Pvoutput kan je invullen zoals je wilt. Daar kan je als consument nooit rechten mee halen.
Als ze failliet gaan heb je altijd nog de log in je omvormer staan.
(En loggen via andere methodes kan wel. Heb de waardes ook in m’n Toon van Eneco staan)
En mocht het helemaal spaak lopen dan is m’n garantie weg. Maar dan ben ik niet getreurd hoor😀

Maar sta nog steeds open hoe het systeem te loggen is

[LigeTRy]

@DRvDijk ik heb met hetzelfde issue gezeten. Inmiddels ben ik zelf voor een andere aanpak gegaan voor m'n ginglong logger. (die hex string kon ik uiteindelijk vrij weinig mee). Wat ik doe is, ik laat de data pushen naar de servers van ginglong. en met een python script haal ik de gegevens weer op van hun api en push ik ze naar pvoutput

Kijk anders even in m'n github repo. misschien heb je er wat aan.

ik gebruik het script ook nog om de data lokaal in m'n mariadb instance op te slaan, dit hoef je natuurlijk niet te gebruiken

[ Voor 13% gewijzigd door LigeTRy op 29-10-2019 10:22 ]

[DRvDijk]

LigeTRy schreef op dinsdag 29 oktober 2019 @ 10:21:
@DRvDijk ik heb met hetzelfde issue gezeten. Inmiddels ben ik zelf voor een andere aanpak gegaan voor m'n ginglong logger. (die hex string kon ik uiteindelijk vrij weinig mee). Wat ik doe is, ik laat de data pushen naar de servers van ginglong. en met een python script haal ik de gegevens weer op van hun api en push ik ze naar pvoutput

Kijk anders even in m'n github repo. misschien heb je er wat aan.

ik gebruik het script ook nog om de data lokaal in m'n mariadb instance op te slaan, dit hoef je natuurlijk niet te gebruiken

Da's inderdaad de snellere handigere aanpak. Toch ga ik door met m'n Java appje (het ding schrijft alle communicatie al weg naar disk, ben nu een parser aan het schrijven). Eerste doel daarvan natuurlijk het data logging verhaal, maar secundair een oplossing voor als de Chinese server er mee ophoudt, dat ik dan mijn eigen responses erheen kan gaan schrijven.

[LigeTRy]

DRvDijk schreef op dinsdag 29 oktober 2019 @ 10:56:
[...]


Da's inderdaad de snellere handigere aanpak. Toch ga ik door met m'n Java appje (het ding schrijft alle communicatie al weg naar disk, ben nu een parser aan het schrijven). Eerste doel daarvan natuurlijk het data logging verhaal, maar secundair een oplossing voor als de Chinese server er mee ophoudt, dat ik dan mijn eigen responses erheen kan gaan schrijven.

Laat het maar weten als je de hex goed hebt weten te ontcijferen, zelf zou ik ook liever niet alles naar een chinese server pushen en pullen, maar voor nu was dit inderdaad de snelste/betrouwbaarste methode.

[wiljums]

delete

[ Voor 98% gewijzigd door wiljums op 29-10-2019 17:36 ]

[wiljums]

Sinds 29 oktober heb ik alleen maar offline readings met het script van MarkRuys. Ook de plugin in Domoticz haalt geen data meer op sinds die tijd. Naar mijn weten is er niks verandert in instellingen of iets dergelijks. Iemand een idee wat de oorzaak zou kunnen zijn? Is er weer iets veranderd in het SEMS portal?

[merlin1201]

wiljums schreef op vrijdag 1 november 2019 @ 09:15:
Sinds 29 oktober heb ik alleen maar offline readings met het script van MarkRuys. Ook de plugin in Domoticz haalt geen data meer op sinds die tijd. Naar mijn weten is er niks verandert in instellingen of iets dergelijks. Iemand een idee wat de oorzaak zou kunnen zijn? Is er weer iets veranderd in het SEMS portal?

Bij mijn gaat dat script juist wel goed terwijl ik met het php script van Boonstra inlog fouten krijg en deze niet meer werkt.
Eerder wel het probleem dat de dag niet met nul start maar met de waarde van de dag ervoor, maar datzelfde zag ik in Sems portal ook, dus lag het daaraan en hebben zij inmiddels gefixt.

[il-Principe]

Ik weet niet of het ermee te maken heeft, maar ik gebruik nog steeds de oude Goodwe site om "gemakkelijk" mijn systeem te monitoren d.m.v. deeplink. Het was me ook nog gelukt om een nieuwe omvormer via de oude site te benaderen/koppelen. Maar in het afgelopen jaar heb ik diverse real time metingen zien verdwijnen en (weer) verschijnen. Het is dat op 24 oktober om 13:00 de real time data weer gestopt is. Misschien dat in het script nog naar een van deze waarden is gelinkt. Er wordt nog steeds data gelogt en ook data die je niet kan vinden op de nieuwe site (met name de warning codes en de (N)BUSVoltages). Handig om te zien of je omvormer ontspoort of niet.

[ruben-e]

DRvDijk schreef op maandag 21 oktober 2019 @ 18:47:
[...]


Ik had die repo al eens gecloned, maar kan daar geen /js/status/js in vinden aha in de reply quote die ik nu aan het typen ben zie ik je suggestie die op de daadwerkelijke interne website te proberen Juist, morgen als er weer wat licht is weer proberen, nét te laat

Maar die repo dus al eens geprobeerd met LiveStats.py:

code:

python LiveStats.py                                                                                                                   G:master[3Y,9M] 526085c
2019-10-21 17:58:43,091 DEBUG Importing output plugin ConsoleOutput
2019-10-21 17:58:43,092 INFO connecting to 192.168.xx.x port 8899
Traceback (most recent call last):
  File "LiveStats.py", line 17, in <module>
    omnik_exporter.run()
  File "/Users/drvdijk/Downloads/_NoBackup/Omnik-Data-Logger/OmnikExport.py", line 73, in run
    data = inverter_socket.recv(1024)
socket.timeout: timed out

Wél is mijn tcp proxy nu gelukt. In elkaar gehackt stukje java code dat een poort uitluistert, en de verbinding doorstuurt naar een ander ip/host, draaiend in een docker container op de NAS. Inhoud van de berichten zelf snap ik ondertussen ook grotendeels, dus daar kan ik wel een InfluxDB output tegenaan hacken denk ik.

Wordt weer vervolgt!

Ik lijk exact hetzelfde probleem te hebben. Ook 0 aanroepen op dat wat ik ook invul bij remote server B. Diverse IPs getest, zowel binnen als buiten netwerk, en ook verschillende poorten. Geen enkele output met nc. Heb ook nog getest om het verkeer te onderscheppen naar de chinese server. De regel werd wel geraakt, maar nog steeds geen output. Maar twijfel nu of het goed ingesteld was. De zon ging al onder en wilde nog snel wat proberen .
Onze interface ziet er ook hetzelfde uit. Alleen draait die van mij 1.0.20.

Hoe werkt de tcp proxy die je aan het schrijven bent? Zo te lezen krijg je daarmee wel iets te zien. Dat is een richting die ik nog kan proberen.

[DRvDijk]

ruben-e schreef op maandag 11 november 2019 @ 07:18:
[...]


Ik lijk exact hetzelfde probleem te hebben. Ook 0 aanroepen op dat wat ik ook invul bij remote server B. Diverse IPs getest, zowel binnen als buiten netwerk, en ook verschillende poorten. Geen enkele output met nc. Heb ook nog getest om het verkeer te onderscheppen naar de chinese server. De regel werd wel geraakt, maar nog steeds geen output. Maar twijfel nu of het goed ingesteld was. De zon ging al onder en wilde nog snel wat proberen .
Onze interface ziet er ook hetzelfde uit. Alleen draait die van mij 1.0.20.

Hoe werkt de tcp proxy die je aan het schrijven bent? Zo te lezen krijg je daarmee wel iets te zien. Dat is een richting die ik nog kan proberen.

Ik ben er nog hard mee bezig, en nog niet klaar de github repo openbaar te maken, omdat ik nog niet alle berichten goed snap en ik eigenlijk mijn eigen Chinese server wil kunnen draaien voordat ze weer wat gaan veranderen ofzo.
Maar in grote lijnen: ik draai al een eigen DNS server in m'n netwerk, namelijk pi-hole om van een stuk reclame af te zijn. Daarin kún je met moeite (niet via de webinterface namelijk) records toevoegen. Zo heb ik die Chinese hostname een lokaal IP gegeven. Dus nu probeert de logger eerst daarop te verbinden, en als dat niet lukt alsnog naar het hardcoded Chinese IP.
Maar ik draai dus wél een stukje java code waarop de inverter kan verbinden. Wat dat stukje code in eerste instantie doet is het simpelweg doorsturen naar de Chinese server Maar daarmee sla ik het uitgaande en inkomende verkeer wel eventjes op in een bestandje.
Het tweede deel waar ik dus nu lekker mee aan het prutsen ben is het ontcijferen van de data. En met al die opgeslagen data kan ik mooi testen of mijn hypotheses kloppen - "zou dit bitje aangeven dat het niet een live meting is, maar een historische meting?" - dat soort vragen

Dus nog een flinke work in progress Welk merk omvormer en logger heb jij dan? Als het (ongeveer) hetzelfde is wil ik inhoudelijk de berichten wel vergelijken natuurlijk!

[ruben-e]

DRvDijk schreef op maandag 11 november 2019 @ 08:31:
[...]


Ik ben er nog hard mee bezig, en nog niet klaar de github repo openbaar te maken, omdat ik nog niet alle berichten goed snap en ik eigenlijk mijn eigen Chinese server wil kunnen draaien voordat ze weer wat gaan veranderen ofzo.
Maar in grote lijnen: ik draai al een eigen DNS server in m'n netwerk, namelijk pi-hole om van een stuk reclame af te zijn. Daarin kún je met moeite (niet via de webinterface namelijk) records toevoegen. Zo heb ik die Chinese hostname een lokaal IP gegeven. Dus nu probeert de logger eerst daarop te verbinden, en als dat niet lukt alsnog naar het hardcoded Chinese IP.
Maar ik draai dus wél een stukje java code waarop de inverter kan verbinden. Wat dat stukje code in eerste instantie doet is het simpelweg doorsturen naar de Chinese server Maar daarmee sla ik het uitgaande en inkomende verkeer wel eventjes op in een bestandje.
Het tweede deel waar ik dus nu lekker mee aan het prutsen ben is het ontcijferen van de data. En met al die opgeslagen data kan ik mooi testen of mijn hypotheses kloppen - "zou dit bitje aangeven dat het niet een live meting is, maar een historische meting?" - dat soort vragen

Dus nog een flinke work in progress Welk merk omvormer en logger heb jij dan? Als het (ongeveer) hetzelfde is wil ik inhoudelijk de berichten wel vergelijken natuurlijk!

Ah de PI-Hole kan natuurlijk ook. Die draai ik al, ook maar eens proberen om het op die manier te doen. Ik probeerde het in m'n router met een DNAT rule. Werd dus wel geraakt, maar zag alsnog geen output van nc.
Ik zie dat de logger verbinding zoekt met data1.solarmanpv.com. Die heb jij naar een lokaal IP gemapped?

Omvormer en logger zaten al bij oplevering in mijn nieuwbouwwoning. Het is een kleine installatie. Type omvormer is een Solis Mini 1000 4G. Logger lijkt een Ginlong Solis DLS WiFi stick. Dat resultaat zie ik als ik zoek op de firmware versie.

Ik ga eens kijken of ik via de PI-Hole iets kan regelen

[DRvDijk]

ruben-e schreef op maandag 11 november 2019 @ 09:12:
[...]


Ah de PI-Hole kan natuurlijk ook. Die draai ik al, ook maar eens proberen om het op die manier te doen. Ik probeerde het in m'n router met een DNAT rule. Werd dus wel geraakt, maar zag alsnog geen output van nc.
Ik zie dat de logger verbinding zoekt met data1.solarmanpv.com. Die heb jij naar een lokaal IP gemapped?

Omvormer en logger zaten al bij oplevering in mijn nieuwbouwwoning. Het is een kleine installatie. Type omvormer is een Solis Mini 1000 4G. Logger lijkt een Ginlong Solis DLS WiFi stick. Dat resultaat zie ik als ik zoek op de firmware versie.

Ik ga eens kijken of ik via de PI-Hole iets kan regelen

Jep, data1.solarmanpv.com wijst naar een 192.x.x.x adres hier

[daanNL]

Ik heb 2 zonnepanelen met een micro-omvormer op mijn schuurtje liggen. Deze monitor ik nu met een energiemeter waar je de 230-volt stekker in steekt. Het betreft de TP-Link HS110. Deze is via wifi uit te lezen op een mobiele telefoon en dat werkt prima voor een momentopname. Deze registreert echter alleen de huidige opbrengst en de opbrengst gemiddeld over de afgelopen week en afgelopen 30 dagen. Een jaaropbrengst wordt dus bijvoorbeeld niet gelogt.

Heeft iemand adviezen voor een andere variant (plug&play) van een via wifi uitleesbare energiemeter waar je gewoon een 230volt stekker in kunt steken, die meer uitgebreide log-functies heeft?

[mkleinman]

daanNL schreef op donderdag 28 november 2019 @ 10:18:
Ik heb 2 zonnepanelen met een micro-omvormer op mijn schuurtje liggen. Deze monitor ik nu met een energiemeter waar je de 230-volt stekker in steekt. Het betreft de TP-Link HS110. Deze is via wifi uit te lezen op een mobiele telefoon en dat werkt prima voor een momentopname. Deze registreert echter alleen de huidige opbrengst en de opbrengst gemiddeld over de afgelopen week en afgelopen 30 dagen. Een jaaropbrengst wordt dus bijvoorbeeld niet gelogt.

Heeft iemand adviezen voor een andere variant (plug&play) van een via wifi uitleesbare energiemeter waar je gewoon een 230volt stekker in kunt steken, die meer uitgebreide log-functies heeft?

Plugwise zou kunnen, maar ook bijvoorbeeld Iungo. ( Beide Nederlandse producten )

[daanNL]

mkleinman schreef op donderdag 28 november 2019 @ 10:19:
[...]


Plugwise zou kunnen, maar ook bijvoorbeeld Iungo. ( Beide Nederlandse producten )

Bedankt, maar ik had mijn wens wat zorgvuldiger moeten beschrijven. Ik ben op zoek naar een systeem zonder centrale controller o.i.d. welke met Z-wave of wat dan ook verbind. Plugwise heb ik gehad, maar de doordrukstekkers hebben niet genoeg bereik naar achterin de tuin. Vandaar dat de energiemeter direct via wifi moet verbinden. Ook kostentechnisch zijn plugwise en Lungo eigenlijk niet in lijn met de opbrengsten van slechts 2 panelen.

[ Voor 8% gewijzigd door daanNL op 28-11-2019 10:40 ]

[mkleinman]

daanNL schreef op donderdag 28 november 2019 @ 10:39:
[...]
Bedankt, maar ik had mijn wens wat zorgvuldiger moeten beschrijven. Ik ben op zoek naar een systeem zonder centrale controller o.i.d. welke met Z-wave of wat dan ook verbind. Plugwise heb ik gehad, maar de doordrukstekkers hebben niet genoeg bereik naar achterin de tuin. Vandaar dat de energiemeter direct via wifi moet verbinden. Ook kostentechnisch zijn plugwise en Lungo eigenlijk niet in lijn met de opbrengsten van slechts 2 panelen.

Iungo is overigens Zwave, je kan uiteraard ook een Zwave doordrukstekker ( merk even kwijt ) voor 25 euro bestellen en samen met een Zwave receiver zou je met Domoticz op een PI eea kunnen uitlezen.

[Moffin]

Ik heb in dit topic het een en ander gelezen over de SDM 120 modbus.
Daarnaast wordt er geregeld de SDM120C benoemd. Ik kan slecht doorgronden wat het verschil is.

Zoek ik via google op de SDM120 , dan kom ik zowel degene tegen met een bruin als met een blauw plaatje. Zit hier ook nog verschil in?

https://www.bol.com/nl/p/...-modbus/9200000112039512/
https://www.elektramat.nl/1-fase-kwh-meter-sdm120c/
https://www.kwhmeter.nl/W...ie-meter-45A-LCD-MID.html

[ocaj]

@Moffin Zie: http://www.eastron.com.cn/search/product?SearchText=sdm120
Er staan daar maar liefst 99 (!) versies van de SDM120 genoemd....

Even goed opletten dus welke je precies besteld (en dan hopen dat de webwinkels nauwkeurig genoeg zijn in hun aanduiding).

[Moffin]

@ocaj Ik heb de website inderdaad gezien. Ik ben even benieuwd wat de tweaker gebruikt. Ik zou het jammer vinden als ik degene bestel die uiteindelijk niet bruikbaar is met de scripts die online zijn te vinden. Of is alleen de SO en modbus aansluiting relevant.

[jobr]

Moffin schreef op zaterdag 21 december 2019 @ 09:35:
@ocaj Ik heb de website inderdaad gezien. Ik ben even benieuwd wat de tweaker gebruikt. Ik zou het jammer vinden als ik degene bestel die uiteindelijk niet bruikbaar is met de scripts die online zijn te vinden. Of is alleen de SO en modbus aansluiting relevant.

SO en/of Modbus (meestal over RS485) is relevant. Merk/type kan ook relevant zijn. Ik heb bijv een ander merk en die is dan niet uitleesbaar met de SDM120 scripts.
Maar ik denk dat je altijd wel goed zit als je een SDM120 koopt met modbus RS485 (nog wel adapter nodig).
Mbus zie je ook wel, dat is weer wat anders.

Je hebt ook nog met toevoeging MID. Dan is deze geijkt en mag je bijv gebruiken om facturen te sturen of te declareren.

Ze kunnen soms ook niet allemaal teruglevering (bidirectional) aan.

Plaatjes op websites hoeven niet altijd te kloppen daar zou ik niet blind op varen.

En anders gewoon even aan de webshop vragen.

[Moffin]

jobr schreef op zaterdag 21 december 2019 @ 19:44:
[...]


SO en/of Modbus (meestal over RS485) is relevant. Merk/type kan ook relevant zijn. Ik heb bijv een ander merk en die is dan niet uitleesbaar met de SDM120 scripts.
Maar ik denk dat je altijd wel goed zit als je een SDM120 koopt met modbus RS485 (nog wel adapter nodig).
Mbus zie je ook wel, dat is weer wat anders.

Je hebt ook nog met toevoeging MID. Dan is deze geijkt en mag je bijv gebruiken om facturen te sturen of te declareren.

Ze kunnen soms ook niet allemaal teruglevering (bidirectional) aan.

Plaatjes op websites hoeven niet altijd te kloppen daar zou ik niet blind op varen.

En anders gewoon even aan de webshop vragen.

Super bedankt, bedoel met teruglevering (bijvoorbeeld voor zonnepanelen?) of bedoel je dat je via modbus dat je settings kan aanpassen aan de SDM120? alvast bedankt.

[jobr]

Moffin schreef op zaterdag 21 december 2019 @ 21:01:
[...]


Super bedankt, bedoel met teruglevering (bijvoorbeeld voor zonnepanelen?) of bedoel je dat je via modbus dat je settings kan aanpassen aan de SDM120? alvast bedankt.

Ik bedoel teruglevering met zonnepanelen.
Dus dat de stroom beide kanten op wordt gemeten door de meter.

[Moffin]

Mm, super goede tip. Ik wil ze namelijk ook gebruiken voor zonnepanelen.

[Dapdodo]

Eindelijk die kWh meter van YTL DTS353F-2 modbus aan de gang. De sleutel die ontbrak was de file met registers en benodigde instellingen. Op naar de logging.

[ Voor 4% gewijzigd door Dapdodo op 14-01-2020 06:59 ]

[Kire88]

Sinds vandaag komen er geen waarden meer door van mijn omvormer (SE3000H HD wave) naar de SolarEdge monitoring platform.

De status LED geeft aan dat er wel productie plaats vind maar op de monitoring platform wordt weergegeven dat er 0W geproduceerd wordt.

Een en ander is verbonden via wifi. Ik heb reeds de router en ook de omvormer gereset maar tot nu toe zonder resultaat.

Iemand een idee wat te controleren?

[Peter is Gamer]

Kire88 schreef op zondag 26 januari 2020 @ 13:32:
Sinds vandaag komen er geen waarden meer door van mijn omvormer (SE3000H HD wave) naar de SolarEdge monitoring platform.

De status LED geeft aan dat er wel productie plaats vind maar op de monitoring platform wordt weergegeven dat er 0W geproduceerd wordt.

Een en ander is verbonden via wifi. Ik heb reeds de router en ook de omvormer gereset maar tot nu toe zonder resultaat.

Iemand een idee wat te controleren?

Ik heb hier het zelfde probleem zowel via de app als via de website zie ik 0W geproduceerd.

Ik heb de stroom even van het apparaat afgehaald (zekering even omgezet). WiFi opnieuw laten verbinden. Werkt beide niet. Ik gok een storing aan hun zeide.

[Kire88]

@Peter is Gamer het lijkt erop dan ja.....

In ieder geval goed om te weten dat het niet alleen mijn systeem is.

[Aziraphale]

@Peter is Gamer @Kire88 Hier hetzelfde issue. Domoticz geeft aan dat de omvormer om 8:44 voor het laatst is gezien, daarna niets meer. Hij produceert wel gewoon, kijkend naar het totale energieverbruik.

[Kire88]

Houdt SolarEdge toevallig ergens een storingsoverzicht bij waar jullie van weten?

[Kire88]

De data komt weer langzaam terug. In mijn pvoutput is het nu bijgewerkt tm 11.45.

Edit 16.12: alles lijkt weer normaal te werken en bijgewerkt.

[ Voor 28% gewijzigd door Kire88 op 26-01-2020 16:13 ]

[merlin1201]

Misschien dat de servers in china staan #coronaoutbreak

[bd-casemod]

Ik wil graag mijn solarmanpv data loggen naar pvoutput.org, iemand dit al eens gedaan via een raspberry oid ?

Ik heb het volgende script gevonden maar krijg dit niet aan de praat: https://github.com/MattCordell/SolarMax_PVoutputLogger

[timterhorst]

Nu in het juiste topic hoop ik

Wie heeft ervaring met het uitlezen van de Tigo Access Point (TAP) ?
Ik heb drie TS4-duo optimisers voor zes panelen met schaduw.
De string gaat naar SMA SB3600-TL21. Deze heeft een webconnect/speedwire module om te connecten met internet/Sunnyportal.
nou leek het me leuk om gebruik te maken van de mogelijkheid om de optimisers uit te lezen.
Ik kocht daarom pasgeleden een TAP.
De standaard manier is om er een Tigo Cloud Connect Advanced (CCA) kastje achter te hangen en dan naar internet.
Dus: TS4 -> TAP -> CCA -> SunnyPortal oid.
Die CCA kost bijna 300 euro, dat vind ik dan al een stuk minder leuk.
De (nieuwere) SMA omvormers hebben CCA ingebouwd blijkbaar, daar kan de TAP wel rechtstreeks op aansluiten, middels een speciale stekker.
mijn idee was om de TAP rechtstreeks op de webconnect module aan te sluiten. Dat lijkt niet te kunnen, althans, ik vind nergens informatie daarover. SMA praat blijkbaar alleen met professionele installateurs en dat ben ik niet.
Alternatief idee is om de TAP met een rpi te verbinden en daar wat op te programmeren, zo ingewikkeld zal die CCA toch niet zijn?

Lang verhaal, maar hoe aan te pakken, wie heeft hier al eens naar gekeken ?

edit: ik spitte dit topic door (kende het nog niet) en zie dat @hansdegit in 2013 een aantal pogingen heeft gedaan om de code te kraken, van de voorganger van de huidige CCA, spannende lectuur maar wat was de uitkomst ?

[ Voor 8% gewijzigd door timterhorst op 14-02-2020 12:28 ]

[Pixelmagic]

Sinds gisteren een SMA TriPower 5k 3 fase omvormer en SBFspot op het netwerk draaien welke netjes de data naar oa pvoutput en Domoticz stuurt.

Enige twee waardes die ik eigenlijk mis zijn de EToday en Temerature, beide velden zijn 0 en ook vanaf de command line zijn ze leeg.

Iemand een idee of en hoe deze waardes uit de omvormer zijn te krijgen ?

[AUijtdehaag]

https://github.com/SBFspot/SBFspot/issues/290
Misschien kan @knights16 of @Tsurany je verder helpen?

In Domoticz heb je wel e-today?
Temperature kan enkel nog via modbus tcp (volgens mij) in node-red.
Ik zou, voor nu, de sbfspot.db wijzigen in V5 as NULL en openweathermap gebruiken voor de omgevings temperatuur in pvoutput.
Het is niet onverstandig om dan meteen dit ook toe te passen: sbf in "Datalogging: PV systemen"

[ Voor 39% gewijzigd door AUijtdehaag op 21-02-2020 17:16 ]

[cville]

Pixelmagic schreef op vrijdag 21 februari 2020 @ 16:59:
Sinds gisteren een SMA TriPower 5k 3 fase omvormer en SBFspot op het netwerk draaien welke netjes de data naar oa pvoutput en Domoticz stuurt.

Enige twee waardes die ik eigenlijk mis zijn de EToday en Temerature, beide velden zijn 0 en ook vanaf de command line zijn ze leeg.

Iemand een idee of en hoe deze waardes uit de omvormer zijn te krijgen ?

Helaas, om onbekende redenen levert SMA deze data niet meer en beantwoord ook geen vragen hierover. EToday kun je zelf uitrekenen en de temperatuur lees ik uit d.m.v. ModBus queries. In het SBFspot forum vind je Python code van mij die dat kan.

[Pixelmagic]

cville schreef op vrijdag 21 februari 2020 @ 19:20:
[...]

Helaas, om onbekende redenen levert SMA deze data niet meer en beantwoord ook geen vragen hierover. EToday kun je zelf uitrekenen en de temperatuur lees ik uit d.m.v. ModBus queries. In het SBFspot forum vind je Python code van mij die dat kan.

Bedankt, had die er gisteren al op gezet alleen blijft hi zeuren om een library die ik wel geïnstalleerd heb [was het iets met nebulus ?j maar blijkbaar niet goed genoeg vind op mijn Debian server.

Wel vaag dat SMA de temperatuur niet normaal publiceert, lijkt me juist prima als gebruikers bewust zijn van de temp en eventueel extra koeling kan verzorgen.

[cville]

Pixelmagic schreef op vrijdag 21 februari 2020 @ 19:24:
[...]


Bedankt, had die er gisteren al op gezet alleen blijft hi zeuren om een library die ik wel geïnstalleerd heb [was het iets met nebulus ?j maar blijkbaar niet goed genoeg vind op mijn Debian server.

Wel vaag dat SMA de temperatuur niet normaal publiceert, lijkt me juist prima als gebruikers bewust zijn van de temp en eventueel extra koeling kan verzorgen.

Mmm. Nebulus komt me niet bekend voor. Kun je nog eens kijken? Ik draai e.e.a. op Ubuntu (Debian)

[DataCopy]

Ik was van plan om mijn logging uit te breiden met 'lokale' temperatuur en zon instraling informatie vanuit de buienradar json API.

Als ik de JSON pagina opvraag krijg ik echter als laatste update (vanuit alle meetstations): 2020-02-21T09:40:00.

Misschien een storing? Maar aangezien ik het pas gisterenavond voor het eerst geprobeerd heb wil ik even checken of er mensen zijn die dit ook gebruiken.

Buienradar json pagina: https://json.buienradar.nl/

[Pixelmagic]

cville schreef op zaterdag 22 februari 2020 @ 12:45:
[...]


Mmm. Nebulus komt me niet bekend voor. Kun je nog eens kijken? Ik draai e.e.a. op Ubuntu (Debian)

Ik zat in de richting: pendulum

Ondertussen wat verder, Debian heeft standaard de 2.7 versie van python actie en ook PIP moet je PIP3 gebruiken als je Python3 wilt gebruiken. Heb ondertussen een deel van het script gebruikt om de temperatuur uit te halen.

mag ik vragen waar je de waarde 30953 voor de temp vandaan hebt ? Kan er zo goed als niets over vinden, behalve vele andere waardes.

[AUijtdehaag]

@Pixelmagic Ik denk hier vandaan. Link zip file

[cville]

Pixelmagic schreef op zaterdag 22 februari 2020 @ 13:19:
[...]


Ik zat in de richting: pendulum

Ondertussen wat verder, Debian heeft standaard de 2.7 versie van python actie en ook PIP moet je PIP3 gebruiken als je Python3 wilt gebruiken. Heb ondertussen een deel van het script gebruikt om de temperatuur uit te halen.

mag ik vragen waar je de waarde 30953 voor de temp vandaan hebt ? Kan er zo goed als niets over vinden, behalve vele andere waardes.

Je moet inderdaad pip3 gebruiken. Pendulum is een verbeterde time library. De door jou genoemde code komt uit de uitvoerige, van vele versies voorziene en bijna nooit meer terug te vinden SMA ModBus documentatie voor deze inverter

Hieronder de lijst met alle registers die ik gebruik:

code:

registers = [
    ModBusRegister(id=40029, inverter=inverters[1], name='STATUS', unit=''),
    ModBusRegister(id=30773, inverter=inverters[1], name='Pdc1', unit='W'),
    ModBusRegister(id=30961, inverter=inverters[1], name='Pdc1', unit='W'),
    ModBusRegister(id=30769, inverter=inverters[1], name='Idc1', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30957, inverter=inverters[1], name='Idc2', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30771, inverter=inverters[1], name='Udc1', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30959, inverter=inverters[1], name='Udc2', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30777, inverter=inverters[1], name='Pac1', unit='W'),
    ModBusRegister(id=30779, inverter=inverters[1], name='Pac2', unit='W'),
    ModBusRegister(id=30781, inverter=inverters[1], name='Pac3', unit='W'),
    ModBusRegister(id=30977, inverter=inverters[1], name='Iac1', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30979, inverter=inverters[1], name='Iac2', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30981, inverter=inverters[1], name='Iac3', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30783, inverter=inverters[1], name='Uac1', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30785, inverter=inverters[1], name='Uac2', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30787, inverter=inverters[1], name='Uac3', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30529, inverter=inverters[1], name='ETotal', unit='Wh'),
    ModBusRegister(id=30803, inverter=inverters[1], name='Frequency', unit='Hz', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30953, inverter=inverters[1], name='Temperature', unit='°C', conversion_factor=0.1, precision=1),
    # ModBusRegister(id=30775, inverter=inverters[1], name='Pac', unit='W'),
]

[Pixelmagic]

cville schreef op zaterdag 22 februari 2020 @ 13:38:
[...]


Je moet inderdaad pip3 gebruiken. Pendulum is een verbeterde time library. De door jou genoemde code komt uit de uitvoerige, van vele versies voorziene en bijna nooit meer terug te vinden SMA ModBus documentatie voor deze inverter

Hieronder de lijst met alle registers die ik gebruik:

code:

registers = [
    ModBusRegister(id=40029, inverter=inverters[1], name='STATUS', unit=''),
    ModBusRegister(id=30773, inverter=inverters[1], name='Pdc1', unit='W'),
    ModBusRegister(id=30961, inverter=inverters[1], name='Pdc1', unit='W'),
    ModBusRegister(id=30769, inverter=inverters[1], name='Idc1', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30957, inverter=inverters[1], name='Idc2', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30771, inverter=inverters[1], name='Udc1', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30959, inverter=inverters[1], name='Udc2', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30777, inverter=inverters[1], name='Pac1', unit='W'),
    ModBusRegister(id=30779, inverter=inverters[1], name='Pac2', unit='W'),
    ModBusRegister(id=30781, inverter=inverters[1], name='Pac3', unit='W'),
    ModBusRegister(id=30977, inverter=inverters[1], name='Iac1', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30979, inverter=inverters[1], name='Iac2', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30981, inverter=inverters[1], name='Iac3', unit='A', conversion_factor=0.001, precision=3),
    ModBusRegister(id=30783, inverter=inverters[1], name='Uac1', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30785, inverter=inverters[1], name='Uac2', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30787, inverter=inverters[1], name='Uac3', unit='V', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30529, inverter=inverters[1], name='ETotal', unit='Wh'),
    ModBusRegister(id=30803, inverter=inverters[1], name='Frequency', unit='Hz', conversion_factor=0.01, precision=2),
    ModBusRegister(id=30953, inverter=inverters[1], name='Temperature', unit='°C', conversion_factor=0.1, precision=1),
    # ModBusRegister(id=30775, inverter=inverters[1], name='Pac', unit='W'),
]

Dank hiervoor, alleen als ik het goed heb dan heb je de waarde Pdc1 2 maal staan, ik vermoed dat de 2e Pdc2 moet zijn ? (maakt voor mij niet uit, ik heb 1 string)

[cville]

Pixelmagic schreef op zaterdag 22 februari 2020 @ 17:04:
[...]


Dank hiervoor, alleen als ik het goed heb dan heb je de waarde Pdc1 2 maal staan, ik vermoed dat de 2e Pdc2 moet zijn ? (maakt voor mij niet uit, ik heb 1 string)

Ik denk dat je helemaal gelijk hebt; is me nooit opgevallen. Bedankt!

[Kalentum]

Over modbus en SMA: Sinds gisteren heb ik ook een SMA omvormer en heb veel gehad aan dit script:
https://github.com/malura...odbus/blob/master/main.py

Daarmee kan ik nu zelf de registers uitlezen en de registers uitlezen waar ik in geïnteresseerd was. Ik log alles naar een PostgreSQL database en heb dit script een beetje omgebouwd zodat het JSON oplevert.

Het is allemaal nog test dus ik weet niet helemaal of het gaat voldoen maar sofar so good.

Edit: zitten wel wat bugs in: als de productie 0 is krijg ik voor bijvoorbeeld de huidige opbrengst -2147483648 Watt. Oh well

[ Voor 23% gewijzigd door Kalentum op 22-02-2020 17:59 ]

[Pixelmagic]

Ik heb ondertussen de inverter temperatuur ook op PVoutput staan 'en in mijn database. Het is wat geknutsel bij elkaar maar mocht iemand er ook interesse in hebben, ik heb (voornamelijk voor mezelf als archief) een tweakblog posting gemaakt met alle aanpassingen: https://pixelmagic.tweakb...ngen-voor-sma-tripower-50

Ieder hier bedankt voor de tips !!

[knights16]

Pixelmagic schreef op vrijdag 21 februari 2020 @ 19:24:
[...]


Bedankt, had die er gisteren al op gezet alleen blijft hi zeuren om een library die ik wel geïnstalleerd heb [was het iets met nebulus ?j maar blijkbaar niet goed genoeg vind op mijn Debian server.

Wel vaag dat SMA de temperatuur niet normaal publiceert, lijkt me juist prima als gebruikers bewust zijn van de temp en eventueel extra koeling kan verzorgen.

Sinds een recente firmware update voor mijn SB3.0-AV41 wordt EToday wel weer gevuld : )

Als je logging wilt/hebt met Grafana en Influx, dan heb ik een query waardoor je de EToday wel kunt weergeven (is immers het verschil per dag van de ETotal)

[Pixelmagic]

knights16 schreef op dinsdag 25 februari 2020 @ 19:25:
[...]


Sinds een recente firmware update voor mijn SB3.0-AV41 wordt EToday wel weer gevuld : )

Als je logging wilt/hebt met Grafana en Influx, dan heb ik een query waardoor je de EToday wel kunt weergeven (is immers het verschil per dag van de ETotal)

Welke versie heb je dan ? Ik heb hier versie 2.13.33.R op de 5kw 3 fase.

Ik heb de data nu dmv sbfspot in een mysql db staan en kan daar wel wat op knutselen als het moet en domoticz toont ook de Etoday (berekend?) maar het is natuurlijk mooier als het gewoon goed doorkomt.

[AUijtdehaag]

@Pixelmagic
Etoday van Domoticz en Pvoutput is gewoon de totaal kWh tellerstand die doorgegeven wordt en begint iedere dag gewoon opnieuw met tellen door beiden.

[knights16]

Pixelmagic schreef op dinsdag 25 februari 2020 @ 20:20:
[...]


Welke versie heb je dan ? Ik heb hier versie 2.13.33.R op de 5kw 3 fase.

Ik heb de data nu dmv sbfspot in een mysql db staan en kan daar wel wat op knutselen als het moet en domoticz toont ook de Etoday (berekend?) maar het is natuurlijk mooier als het gewoon goed doorkomt.

Firmwareversie: 3.10.16.R.

In februari is deze update gekomen. Even website van SMA bezoeken en dan firmware.

Maar zoals er gezegd wordt, pvoutput berekend super nauwkeurig de etoday en als jij die nu wegschrijft naar een DB ben je er toch?

[Pino112]

Ik probeer toch maar eens of ik de RS485-poort van mijn Solax X1 Mini kan uitlezen. De Arduino heb ik nog liggen van school van een paar jaar geleden, nu de ESP8266 en de RS485-TTL-converter nog. Omdat deze laatste meestal uit China moet komen en dat nu redelijk lang duurt zit ik op bijv Amazon te kijken, en daar zie ik deze:
https://www.amazon.com/DR...-Indicator/dp/B075V2NMV8/
Fulfilled by Amazon, dat lijkt me dan niet uit China te komen. Is dit eenzelfde converter die moet gaan werken?

ThinkPadd schreef op vrijdag 11 augustus 2017 @ 13:10:
Waarom niet via RS485 uitlezen met een ESP8266 en RS485-TTL converter?
Zoveel mooier dan die ranzige manier waarbij de GoodWe portal gescraped wordt

Zelfs als je niet kunt programmeren e.d. zou je dit vrij simpel aan de gang moeten kunnen krijgen:
CodeIT in "Datalogging: PV systemen"

[ThinkPad]

Yep dat is dezelfde module als die ik heb, zo op het oog.

N.B. De code waarnaar ik refereer is geschreven voor Goodwe omvormers he, niet voor Solax. Een Arduino is niet nodig, aan een ESP8266 (= de Arduino eigenlijk) + die TTL-convert heb je genoeg.

[AUijtdehaag]

@Pino112 Beide op voorraad?

[Pino112]

ThinkPadd schreef op woensdag 26 februari 2020 @ 07:31:
Yep dat is dezelfde module als die ik heb, zo op het oog.

N.B. De code waarnaar ik refereer is geschreven voor Goodwe omvormers he, niet voor Solax. Een Arduino is niet nodig, aan een ESP8266 (= de Arduino eigenlijk) + die TTL-convert heb je genoeg.

Qua code weet ik, heb al code voor Solax gevonden. Ging me nu even om de hardware. Zie nu inderdaad dat alleen de IDE van Arduino nodig is ja (staat bij requirements), overheen gelezen.

AUijtdehaag schreef op woensdag 26 februari 2020 @ 08:49:
@Pino112 Beide op voorraad?

Had meerdere webshops bezocht/gezocht, deze nog niet. Dan lijkt me dat deze hetzelfde is, die is idd op voorraad. Dank.

[Waah]

Hier nu ook aan de slag met de combi Omniksolar en Raspberry Pi met Domoticz+Influxdb+grafana.
Heb alle data van de zonnepanelen en p1 slimme meter in Domoticz, en doorgestuurd naar Influxdb. In Grafana al wat tellertjes.

Echter wat ik niet voor elkaar krijg, ondanks mijn Google-Fu, is hoe ik de totale opgewekte energie van de zonnepanelen kan aftrekken van verbruik volgens de slimme meter. Want dan weet ik hoeveel ik echt verbruikt heb (als ik geen zonnepanelen had).

Het enige wat ik kan vinden is dat je met Grafana blijkbaar geen variabelen bij elkaar kan optellen/aftrekken?

Iemand enig idee hoe ik dat voor elkaar kan krijgen? Ik heb al:

1. Verbruik per dag volgens slimme meter
2. Opgewekt per dag volgens slimme meter
3. Opgewekt volgens Omnik

Ik wil dus: 3-2+1 (totaal Opgewekt - teruggeleverd + bruto verbruik = netto verbruik)

Kan dit in Grafana? Of via een andere wijze?

[cville]

Waah schreef op woensdag 26 februari 2020 @ 21:12:
Hier nu ook aan de slag met de combi Omniksolar en Raspberry Pi met Domoticz+Influxdb+grafana.
Heb alle data van de zonnepanelen en p1 slimme meter in Domoticz, en doorgestuurd naar Influxdb. In Grafana al wat tellertjes.

Echter wat ik niet voor elkaar krijg, ondanks mijn Google-Fu, is hoe ik de totale opgewekte energie van de zonnepanelen kan aftrekken van verbruik volgens de slimme meter. Want dan weet ik hoeveel ik echt verbruikt heb (als ik geen zonnepanelen had).

Het enige wat ik kan vinden is dat je met Grafana blijkbaar geen variabelen bij elkaar kan optellen/aftrekken?

Iemand enig idee hoe ik dat voor elkaar kan krijgen? Ik heb al:

1. Verbruik per dag volgens slimme meter
2. Opgewekt per dag volgens slimme meter
3. Opgewekt volgens Omnik

Ik wil dus: 3-2+1 (totaal Opgewekt - teruggeleverd + bruto verbruik = netto verbruik)

Kan dit in Grafana? Of via een andere wijze?

Ik doe dat zelf niet rechtstreeks in Grafana maar reken het uit met Python. Ik denk dat het wel rechtstreeks kan maar dan moet je continuous query's gebruiken. Ik heb daar in het verleden een paar keer over gepost maar kan het zo gauw niet vinden.

Je punt 2 is niet 'opgewekt' maar 'teruggeleverd'

[Waah]

@cville je hebt gelijk, inderdaad teruggeleverd.

Na nog wat verder prutsen (het was laat vannacht) heb ik een LUA script voor Domoticz gevonden dat het correct laat zien. Maar dit kan niet naar Influxdb gestuurd worden met omdat het een HTTP Post omdat het op basis van Device een update doet.

Dus dat moet ik op een andere manier zien te doen. Maar eens kijken of ik dat met Python in elkaar kan prutsen (want ik ben geen programmeur, far from). Maar momenteel heeft de Omnik wat issues met het verzenden van data... ook naar de eigen portal op PVoutput. Dus dat moet ik eerst oplossen vandaag ;-)

code in kwestie:

code:

-- Power consumption device script - SunnyBoy 20180523
--
-- Smart meters only measure net electricity consumption/production, i.e. 
-- Electricity consumption - Electricity production. This script subtracts 
-- electricity production from smart meter readings to get electricity 
-- consumption. It's triggered each time the smart meter or PV meter update.
--
-- 1. Create dummy hardware and device
-- 1.1 Go to Setup -> Hardware 
--     Name: anything, e.g. "Ele_Consumption" (this name is only used internally)
--     Type: "Dummy (does nothing, use for virtual switches only)"
-- 1.2 Click on 'Add'
-- 1.3 Click on 'Create Virtual Sensors' from the table of hardware above
--     Name: anything, e.g. "Power Consumption" (this name is displayed on the dashboard etc.)
--     Sensor type: "Electric (Instant+Counter)"
-- 1.4 Click 'Ok'
-- 2. Get name/id of relevant sensors
-- 2.1. Note down the name of your smart meter and solar meter devices (not hardware)
-- 2.2. Note the name and ID of your virtual sensor
-- 3. Update and copy the script below
-- 3.1. Update meter / sensor names
-- 3.2. Go to Setup -> More Options -> Events
-- 3.3. Enter name (e.g. PowerConsumption), Select 'Lua' and 'Device'
-- 3.4. Toggle event active, save
-- 4. Update utility/dashboard accordingly

commandArray = {}
debug = false

-- for debugging, use this file
if (debug) then
    file = io.open("/home/pi/lua_test.log", "a") -- append
end

-- Update these lines before use
smartmeter = "Power" -- name of smart meter device
solarmeter = "OmnikLifetime" -- name of solar meter device
dummymeter = "NettoUsage" -- name of virtual sensor
dummymeter_id = 13 -- ID of virtual sensor
dummymeter_trigger = smartmeter-- name of the meter to trigger the dummy meter update. Use the slowest meter here: if your smart meter updates every 10 sec and PV every 100 sec, you get 9 values using potentially outdated PV data. In my case cloudy days gave negative consumption because of this.

-- debug to check what devices are named (but better use 'Show current states' in
-- online editor)
if (debug) then
    file:write('other devices states:\n')
    for i, v in pairs(otherdevices) do file:write(i, v) end
    file:write("\n")
    file:write('other devices svalues:\n')
    for i, v in pairs(otherdevices_svalues) do file:write(i, v) end
    file:write("\n")
end

-- loop through all the changed devices, only update during day if solar meter
-- is triggered, or during the night if smart meter is triggered.
for deviceName,deviceValue in pairs(devicechanged) do
    if (debug) then
        file:write("Device based event fired on '"..deviceName.."', value '"..tostring(deviceValue).."'\n");
    end
    
    -- Looks like: Device based event fired on 'Power (net)', value '2058750;1175597;790812;1911744;251;0'
    -- Syntax: USAGE1;USAGE2;RETURN1;RETURN2;CONS;PROD https://www.domoticz.com/wiki/Domoticz_API/JSON_URL's#Electricity_P1_smart_meter
    -- Counter: T1: 2058.750, T2: 1175.671
    -- Counter Return: R1: 790.812, R2: 1911.744
    -- Or: Device based event fired on 'Solar Power', value '0.000;3755165.000'
    -- Counter: 3755.165
    -- Time of script consumption counter: 2058.750 + 1175.671 + 3755.165 - 790.812 - 1911.744
    if (deviceName == solarmeter and timeofday['Daytime']) or (deviceName == smartmeter and timeofday['Nighttime']) then
        -- Smart meter: Match six integers separated by semicolum
        -- first four are energy meters, last two are power meters?
        smart_e1, smart_e2, smart_e3, smart_e4, smart_p1, smart_p2 = otherdevices_svalues[smartmeter]:match("([^;]+);([^;]+);([^;]+);([^;]+);([^;]+);([^;]+)")
        -- Solar meter power;counter: 0.000;3755165.000
        solar_p, solar_e = otherdevices_svalues[solarmeter]:match("([^;]+);([^;]+)")
        
        -- Calculate power consumption and update dummy device. Consumption is 
        -- always positive, so we add our solar power to the smart meter power
        -- if solar generates 1kW, smart meter shows -0.5kW, real consumption is 0.5kW (=solar - return)
        -- if solar generates 1kW, smart meter shows 0.5kW, real consumption is 1.5kW (=solar + consumption)
        consumption_p = smart_p1 + solar_p - smart_p2
        consumption_e = smart_e1 + smart_e2 + solar_e - smart_e3 - smart_e4
        
        -- Populate commandArray with update command
        commandArray[1] = {['UpdateDevice'] = dummymeter_id .. "|0|" .. consumption_p .. ";" .. consumption_e}
        if (debug) then
            file:write("Update device".. dummymeter_id .. "|0|" .. consumption_p .. ";" .. consumption_e .. "\n");
        end
    end
end

if (debug) then
    file:close()
end

return commandArray

Als ik dit kan wijzigen naar een trigger van tijd ipv device zou dat wel naar Grafana kunnen. Maar geen idee hoe. Maar op zich een apart script in Python dat de gegevens uit Influxdb haalt en daarna na de berekening het doorstuurt zou ook een goede optie zijn. Misschien moet ik het meer in die richting zoeken.

[ Voor 81% gewijzigd door Waah op 27-02-2020 11:33 ]

[AUijtdehaag]

@Waah In DZvents?
(nog even goed testen)

code:

return {

    on = {
        devices = { 
                    87, -- Slimme meter youless
                    82, -- Zonnepanelen
                  }
         },
    logging = {
        level = domoticz.LOG_INFO,
--        level = domoticz.LOG_ERROR,
        marker = "Eigen verbruik"
               },    
    
    execute = function(domoticz, item)
        
        local Smartmeter = domoticz.devices(87)   -- Slimme meter (youless or P1)
        local Generation = domoticz.devices(82)   -- Zonnepanelen
        local Consumption = domoticz.devices(83)  -- Eigen verbruik / calculated value / dummy Elekta kWh + counter
        
        -- Smartmeter
        local EnergyImportLow = Smartmeter.rawData[1]
        local EnergyImportHigh = Smartmeter.rawData[2]
        local EnergyExportLow = Smartmeter.rawData[3]
        local EnergyExportHigh = Smartmeter.rawData[4]
        local PowerImport = Smartmeter.rawData[5]
        local PowerExport = Smartmeter.rawData[6]
        
        -- Generation
        local EnergyGeneration = Generation.rawData[2]
        local PowerGeneration = Generation.rawData[1]

        --Calculate
        local EnergyImport = EnergyImportLow + EnergyImportHigh
        local EnergyExport = EnergyExportLow + EnergyExportHigh
        
        local EnergyConsumption = EnergyImport - EnergyExport
        local PowerConsumption = PowerImport - PowerExport

        --domoticz.log('EnergyImportLow ' .. EnergyImportLow .. ' Wh ', domoticz.LOG_INFO)
        --domoticz.log('EnergyImportHigh ' .. EnergyImportHigh .. ' Wh ', domoticz.LOG_INFO)
        --domoticz.log('EnergyExportLow ' .. EnergyExportLow .. ' Wh ', domoticz.LOG_INFO)
        --domoticz.log('EnergyExportHigh ' .. EnergyExportHigh .. ' Wh ', domoticz.LOG_INFO)

        --domoticz.log('PowerImport ' .. PowerImport .. ' W ', domoticz.LOG_INFO)
        --domoticz.log('PowerExport ' .. PowerExport .. ' W ', domoticz.LOG_INFO)
        --domoticz.log('EnergyGeneration ' .. EnergyGeneration .. ' Wh ', domoticz.LOG_INFO)
        --domoticz.log('PowerGeneration ' .. PowerGeneration .. ' W ', domoticz.LOG_INFO)

        --domoticz.log('EnergyConsumption ' .. EnergyConsumption .. ' Wh ', domoticz.LOG_INFO)
        --domoticz.log('PowerConsumption: ' .. PowerConsumption .. ' W ', domoticz.LOG_INFO)
        
        domoticz.openURL('http://127.0.0.1:8095/json.htm?type=command&param=udevice&idx=83'..'&nvalue=0&svalue='..PowerConsumption..';'..EnergyConsumption)  
        --vul zelf hier idx in van dummy Consumption (83) en domoticz port (8095)
        
    end
    
}

[Waah]

@AUijtdehaag top! dit is zelfs voor mij leesbare code. Ik ga hier mee aan de slag zodra mijn zonnepanelen weer info doorgeven ;-)

Ik zie alleen dat jij ook de devices als trigger gebruikt. En ik lees overal dat je het dan niet naar influxdb kan sturen omdat de data via een deviceevent word opgeroepen.... en de HTTPlink niet getriggerd word. Uit de wiki:

Note to Virtual / Dummy sensors: If the HTTP link or MQTT is not sending any values to the database, check the update method of your virtual sensors in your scripts. If using the ['UpdateDevice'] method, you will directly write the value to the internal database without triggering an HTTPlink or MQTT update for this sensor. Better is to use the JSON API of Domoticz and update your virtual sensors this way.

https://www.domoticz.com/wiki/HttpLink

[AUijtdehaag]

@Waah Er staat toch json in die regel?

code:

domoticz.openURL('http://127.0.0.1:8095/json.htm?type=command&param=udevice&idx=83'..'&nvalue=0&svalue='..PowerConsumption..';'..EnergyConsumption)

Dus de "nieuwe dummy, consumption" kan naar influxdb

Edit: echter zal de omvormer niet aktueel uitgelezen worden? Niet synchroon met de slimme meter toch?
Dan ga je wat afwijkingen krijgen.

[ Voor 98% gewijzigd door AUijtdehaag op 27-02-2020 12:10 ]

[Waah]

AUijtdehaag schreef op donderdag 27 februari 2020 @ 12:06:
@Waah Er staat toch json in die regel?

code:

domoticz.openURL('http://127.0.0.1:8095/json.htm?type=command&param=udevice&idx=83'..'&nvalue=0&svalue='..PowerConsumption..';'..EnergyConsumption)

Dus de "nieuwe dummy, consumption" kan naar influxdb

Edit: echter zal de omvormer niet aktueel uitgelezen worden? Niet synchroon met de slimme meter toch?
Dan ga je wat afwijkingen krijgen.

Lezen is een vak, je hebt gelijk. Ik dacht dat je vanuit de code direct naar influxdb iets moest doen met JSON. Maar inderdaad: Better is to use the JSON API of Domoticz and update your virtual sensors this way.

Ga vanmiddag met je script aan de slag thanks.

EDIT: Hij doet het Moest ff prutsen, dacht eerst dat de sensor niet goed was. Maar bij de Calculation stond:
local EnergyConsumption = EnergyImport - EnergyExport
local PowerConsumption = PowerImport - PowerExport

Maar daar moet de info van de zonnepanelen nog bij opgeteld

dus:
local EnergyConsumption = EnergyImport - EnergyExport + EnergyGeneration
local PowerConsumption = PowerImport - PowerExport + PowerGeneration

Super bedankt! Heb er gisteren veel te veel tijd aan besteed... maar wil het dan zelf kunnen

@AUijtdehaag het ging heel goed. Aangezien beide elke 10 seconden uitgelezen werden. En dat gaf geen foute uitkomsten.

Alleen de Omnik vind het denk ik niet leuk elke 10 seconden uitgelezen te worden... Na een tijdje krijg ik geen data meer binnen en lijkt de Omnik logger vast te lopen (stuurt ook niet meer naar de Omnik portal). Na een reset wel opgelost. Maar niet werkbaar....

[ Voor 38% gewijzigd door Waah op 27-02-2020 20:50 ]

[AUijtdehaag]

@Waah Je hebt gelijk, die was ik vergeten. (schaam me wel, want ik heb het bij iemand anders ook zo draaien)
Let even op, wat de waarden zijn, morgen vroeg bij het inschakelen van de panelen. Ik zag (volgens mij) wat vreemde tellerstanden nog.

[Tsurany]

Let er ook op dat je de data synchroon uitleest uit de source, dus tegelijk Domoticz in. Wanneer twee systemen apart loggen en daar een aantal seconden verschil in zit kan je er dus aardig naast zitten met je internal consumption.

[Waah]

Tsurany schreef op donderdag 27 februari 2020 @ 21:19:
Let er ook op dat je de data synchroon uitleest uit de source, dus tegelijk Domoticz in. Wanneer twee systemen apart loggen en daar een aantal seconden verschil in zit kan je er dus aardig naast zitten met je internal consumption.

Er zit momenteel een seconde verschil tussen, maar dat geeft geen afwijkende uitkomst van de som. Dus dat lijkt te kloppen. Ik heb ook wel verschillen van 3 a 4 seconden gezien zonder verschil. Waarschijnlijk meet de slimme meter dus tegelijk met de Omnik.... Ik verwacht ook dat het aflezen op vaste tijdstippen gebeurt en dat die niet live bij het opvragen de data gaat verzamelen.

AUijtdehaag schreef op donderdag 27 februari 2020 @ 20:55:
@Waah Je hebt gelijk, die was ik vergeten. (schaam me wel, want ik heb het bij iemand anders ook zo draaien)
Let even op, wat de waarden zijn, morgen vroeg bij het inschakelen van de panelen. Ik zag (volgens mij) wat vreemde tellerstanden nog.

Gecheckt, en ja je hebt vreemde tellerstanden als de Slimme Meter vaker update dan de zonnepanelen. Hoe vaak laat jij de Omnik updaten? Ik wilde elke 10 seconden, maar dan stopt de Omnik na een tijdje met verzenden van data... tot ik hem reset.

Elke 30 seconden lijkt nu goed te gaan. Dan heb je dus op 10,20,40,50 seconden verkeerde data. Maar dat kan je oplossen door enkel een update te doen als je zonnepanelen een update doen. Dus:

code:

on = {
        devices = { 
                    [s]87, -- Slimme meter youless[/s]
                    82, -- Zonnepanelen
                  }
         },

Die eruit, en dan berekend die enkel het verschil tijdens de update.

Baal nog steeds dat ik niet elke 10 seconden een update kan doen.... Maar goed, het werkt in ieder geval Nu in Grafana nog de juiste grafieken eruit krijgen. Dat is bij mij meer wat invullen en hopen dat de juiste getalletjes er toevallig uitkomen dan dat ik snap hoe het nu precies werkt

[cville]

Waah schreef op vrijdag 28 februari 2020 @ 11:31:
[...]

Er zit momenteel een seconde verschil tussen, maar dat geeft geen afwijkende uitkomst van de som. Dus dat lijkt te kloppen. Ik heb ook wel verschillen van 3 a 4 seconden gezien zonder verschil. Waarschijnlijk meet de slimme meter dus tegelijk met de Omnik.... Ik verwacht ook dat het aflezen op vaste tijdstippen gebeurt en dat die niet live bij het opvragen de data gaat verzamelen.


[...]

Gecheckt, en ja je hebt vreemde tellerstanden als de Slimme Meter vaker update dan de zonnepanelen. Hoe vaak laat jij de Omnik updaten? Ik wilde elke 10 seconden, maar dan stopt de Omnik na een tijdje met verzenden van data... tot ik hem reset.

Elke 30 seconden lijkt nu goed te gaan. Dan heb je dus op 10,20,40,50 seconden verkeerde data. Maar dat kan je oplossen door enkel een update te doen als je zonnepanelen een update doen. Dus:

code:

on = {
        devices = { 
                    [s]87, -- Slimme meter youless[/s]
                    82, -- Zonnepanelen
                  }
         },

Die eruit, en dan berekend die enkel het verschil tijdens de update.

Baal nog steeds dat ik niet elke 10 seconden een update kan doen.... Maar goed, het werkt in ieder geval Nu in Grafana nog de juiste grafieken eruit krijgen. Dat is bij mij meer wat invullen en hopen dat de juiste getalletjes er toevallig uitkomen dan dat ik snap hoe het nu precies werkt

Het synchroon uitlezen is wel een punt. Ik heb een DSMR5 meter die 1x per seconde data geeft, een inverter die er 350ms over doet en een inverter die er 3s voor nodig heeft. Uiteindelijk ben ik voor 5s gegaan. In een grafiek kun je eenvoudig zien of je de goede keuzes maakt: als er verschillen zijn, dan zie je die meteen als onverklaarbare piekjes in je verbruik. Het gaat nu heel vaak maar niet altijd goed bij mij. Zie screenshot:

[AUijtdehaag]

@Waah Als je de slimme meter niet meer laat triggeren, heb je na zonsondergang ook geen "eigen verbruik" meer wat update...

Ik gebruik een SMA (elke minuut), dus ook niet echt handig met de SM.
Maar je kan de SM toch ook vertragen in domoticz, indien het P1 is? Elke 30 sec ofzo, (onder hardware)

Ik had al eens een constructie bedacht, om via de zonnepanelen te triggeren, enkel tussen sunrise en sunset, en daarna (en ervoor) via de SM te triggeren. Dan loop je inderdaad veel beter synchroon.
Maar zover ben ik nooit gekomen qua script kennis (teveel andere leuke dingen die ontdekt moeten worden)
Dus als jij een oplossing weet?

[ Voor 38% gewijzigd door AUijtdehaag op 28-02-2020 12:04 ]

[Waah]

Ah van dat vertragen wist ik niet! Dan kan ik hem gewoon om de minuut zetten (stabieler hoop ik).
Enige is nog zorgen dat ze tegelijk om data vragen. Maar dat kan ik wel regelen in de Cronjob van de Omnik-data.

Heb nu 10 seconden verschil, en dan heb ik inderdaad een verkeerde uitkomst (meter is een DSMR4.2)

Heb het nu werken. Ga nog een check inbouwen die de som opnieuw doet, en dan ook de uitkomst van zichzelf aftrekt. Die zou dus altijd op 0 moeten zijn

En kwa schakelen op tijd, dat kan blijkbaar wel. Maar hoe je dat dan koppelt aan zonsopgang/ondergang geen idee. Ga eerst kijken of dit problemen geeft. Zo ja zoek ik wel naar een oplossing.

code:

return {
    active = true,
    
    on = {
        devices = {
                        ['Sensore Movimento'] = {'at 23:00-07:00'}

        }
},
    execute =je script
}

[ Voor 45% gewijzigd door Waah op 28-02-2020 12:54 ]

[Tsurany]

AUijtdehaag schreef op vrijdag 28 februari 2020 @ 11:56:
@Waah Als je de slimme meter niet meer laat triggeren, heb je na zonsondergang ook geen "eigen verbruik" meer wat update...

Ik gebruik een SMA (elke minuut), dus ook niet echt handig met de SM.
Maar je kan de SM toch ook vertragen in domoticz, indien het P1 is? Elke 30 sec ofzo, (onder hardware)

Ik had al eens een constructie bedacht, om via de zonnepanelen te triggeren, enkel tussen sunrise en sunset, en daarna (en ervoor) via de SM te triggeren. Dan loop je inderdaad veel beter synchroon.
Maar zover ben ik nooit gekomen qua script kennis (teveel andere leuke dingen die ontdekt moeten worden)
Dus als jij een oplossing weet?

Waarom alles via Domoticz? Je kan toch veel praktischer die data via Node-Red uitlezen en dan naar Domoticz sturen als je het daar ook wilt hebben?

[AUijtdehaag]

@Tsurany Doe ik ook.
Veel praktischer voor de meeste zaken, maar @waah begon erover.
En scriptje had ik liggen.

[ Voor 13% gewijzigd door AUijtdehaag op 29-02-2020 03:00 ]

[Alfa Novanta]

hi folks,

mijn vader heeft in 2015 een Samil Power River 4500TL-D gekocht en die heeft sinds 18-10-2019 17:51:37 niet meer gecommuniceerd. Het lijkt erop dat ze uit de lucht zijn, ondanks dat de webportal nog wel online is. http://www.samilportal.com .. vandaag het netwerk nagelopen, maar dat lijkt allemaal in orde, dus ik denk dat hun loggingserver gewoon uit de lucht is. Op de Android SamilPortal app pagina zie ik ook sinds eind 2019 allerhande klachten en wordt beweerd dat ze failliet zijn.

Enig idee of er nog enige vorm van logging mogelijk is? Eventueel met een raspberry ofzo? Ik ben hier niet eerder mee bezig geweest dus weet niet precies waar op te letten. Enige pointers zijn welkom

[AUijtdehaag]

@Alfa90_Buttje Is dit iets? https://github.com/mhvis/solar
Ik heb het niet helemaal doorgelezen (dus als je er niets aan hebt, sorry)
Edit: verder dan 12/12/19 komt hij ook niet https://pvoutput.org/list.jsp?sid=44819

[ Voor 64% gewijzigd door AUijtdehaag op 29-02-2020 22:00 ]

[Wiley99]

Voor degenen die Influxdb al gebruiken (en dan ook Telegraf makkelijk kunnen aansluiten), misschien komt er in de volgende versie een bruikbare modbus interface.
Ik weet zelf nog niet of ik er iets aan heb, ik doe alles met Python omdat ik een paar systemen tegelijk uitlees en bruto/netto verbruik graag zelf bereken, maar misschien heeft één van jullie er iets aan:
https://github.com/influx...s/inputs/modbus/README.md

Zou in de nog vrij te geven 1.14 moeten verschijnen.

[antonboonstra]

Ik zie op de website van Trannergy dat de logging website ook PVOutput ondersteunt? Wat moet ik hieronder verstaan? Heeft iemand hier ervaring mee? Zou wel makkelijk zijn als je hiervoor niets aanvullend meer hoeft te regelen.

[Wiley99]

LOL ik had je bijna gewezen op je eigen PVOutput topic (ik herkende je naam en checkte eerst maar even daar), maar ik lees de zin nu anders en begrijp dat je je afvraagt wat je onder de Trannergy support moet verstaan en niet onder PVOutput ;-)

[Rouske]

Verderop die pagina staat dit:
Support PVouput.org
Trannergy-Log could upload all data to PVoutput with easy access. PVOutput.org (http://www.pvoutput.org/) is a free website platform for sharing, comparing and monitoring live solar photovoltaic (PV) and energy consumption data.

Zie ook PVOutput Community: https://forum.pvoutput.org/t/trannergy-inverter/316/2

[ Voor 13% gewijzigd door Rouske op 10-03-2020 23:14 ]

[CasGas]

Toch een crosspost vanuit een ander topic, maar dit blijft maar zoeken geblazen, dus hopelijk dat iemand hier er iets vanaf weet?

Misschien hier maar eens de vraag stellen. Ik ben al de hele dag opzoek om mijn omvormer uit te lezen maar ik kom er niet uit.
Wij hebben een nieuw huis gekocht en de vorige bewoner had deze omvormer in de schuur hangen. Blijkbaar nooit iets gedaan met uitlezen maar dat wil ik natuurlijk wel. Nu zit er op dit apparaat een rj45 poort dus maar meteen geprobeerd om het uit te lezen, maar blijkbaar de poort geeft ook helemaal geen link.

Op internet nog gezocht naar een type, maar ik kan er niks over vinden, Ik heb geen stikkers of andere dingen aan de buitenkant zitten, dus misschien dat iemand mij hier meer kan vertellen welke type dit is? Of hoe deze uberhaubt uit te lezen zou kunnen zijn?

[wizzopa]

CasGas schreef op donderdag 12 maart 2020 @ 21:19:
Toch een crosspost vanuit een ander topic, maar dit blijft maar zoeken geblazen, dus hopelijk dat iemand hier er iets vanaf weet?

Misschien hier maar eens de vraag stellen. Ik ben al de hele dag opzoek om mijn omvormer uit te lezen maar ik kom er niet uit.
Wij hebben een nieuw huis gekocht en de vorige bewoner had deze omvormer in de schuur hangen. Blijkbaar nooit iets gedaan met uitlezen maar dat wil ik natuurlijk wel. Nu zit er op dit apparaat een rj45 poort dus maar meteen geprobeerd om het uit te lezen, maar blijkbaar de poort geeft ook helemaal geen link.

Op internet nog gezocht naar een type, maar ik kan er niks over vinden, Ik heb geen stikkers of andere dingen aan de buitenkant zitten, dus misschien dat iemand mij hier meer kan vertellen welke type dit is? Of hoe deze uberhaubt uit te lezen zou kunnen zijn?

[Afbeelding]

https://gold-coast-solar-...manual-and-common-faults/

http://vdh-solar.nl/omvormers/zeversolar/evershine/

[ZwarteIJsvogel]

CasGas schreef op donderdag 12 maart 2020 @ 21:19:
Nu zit er op dit apparaat een rj45 poort dus maar meteen geprobeerd om het uit te lezen, maar blijkbaar de poort geeft ook helemaal geen link.

RJ45 betekent niet automatisch Ethernet. Bij jouw omvormer is het een RS485-interface. Het communicatieprotocol is vermoedelijk een eigen brouwsel van de fabrikant (in de manual wordt nergens een standaard protocol als Modbus genoemd).

[Kalentum]

CasGas schreef op donderdag 12 maart 2020 @ 21:19:
Op internet nog gezocht naar een type, maar ik kan er niks over vinden, Ik heb geen stikkers of andere dingen aan de buitenkant zitten, dus misschien dat iemand mij hier meer kan vertellen welke type dit is? Of hoe deze uberhaubt uit te lezen zou kunnen zijn?

Zou het deze kunnen zijn?

Je kan ook nog proberen om de vorige bewoner te vragen of er nog een factuur of zo is. En hoe oud de omvormer is: misschien kan het al uit om een andere omvormer te installeren.

[tsjoender]

CasGas schreef op donderdag 12 maart 2020 @ 21:19:
Toch een crosspost vanuit een ander topic, maar dit blijft maar zoeken geblazen, dus hopelijk dat iemand hier er iets vanaf weet?

Misschien hier maar eens de vraag stellen. Ik ben al de hele dag opzoek om mijn omvormer uit te lezen maar ik kom er niet uit.
Wij hebben een nieuw huis gekocht en de vorige bewoner had deze omvormer in de schuur hangen. Blijkbaar nooit iets gedaan met uitlezen maar dat wil ik natuurlijk wel. Nu zit er op dit apparaat een rj45 poort dus maar meteen geprobeerd om het uit te lezen, maar blijkbaar de poort geeft ook helemaal geen link.

Op internet nog gezocht naar een type, maar ik kan er niks over vinden, Ik heb geen stikkers of andere dingen aan de buitenkant zitten, dus misschien dat iemand mij hier meer kan vertellen welke type dit is? Of hoe deze uberhaubt uit te lezen zou kunnen zijn?

[Afbeelding]

Mocht direct uitlezen van de omvormer niet mogelijk of erg lastig zijn, dan kun je er ook nog een kWh meter tussen zetten zoals bijvoorbeeld een Eastron SDM630 (of SDM120 als het een 1 fase omvormer is) of iets vergelijkbaars.

[Jelte]

Voor de mensen met een Growatt omvormer die hun wifi stick lokaal uit willen lezen. @GAEvakYD heeft een tof script gebouwd.
Zie: Growatt Omvormer uitlezen via proxy