even tussendoor: weet iemand waar ik nog een "domme ouderwetse ethernet hub" kan aanschaffen? Ik vind alleen maar switches en routers...
Je kan eens bij de kringloopwinkel kijken of probeer eens een vraag advertentie op V&A. Als je nog een access point (over) hebt wat een alternatieve firmware kan draaien zoals DD-WRT, Tomato, etc. dan zou je die ook in kunnen zetten met een vorm van "port mirroring" (iptables mangle) waarmee je die hub niet meer nodig hebt.willemx schreef op donderdag 31 mei 2018 @ 19:25:
even tussendoor: weet iemand waar ik nog een "domme ouderwetse ethernet hub" kan aanschaffen? Ik vind alleen maar switches en routers...
Helaas werkt dit niet. Zodra ik een aanpassing doe in /etc/network/interfaces wil raspbian wlan0 niet meer starten. Krijg dan de melding dat ik landcode moet instellen maar dat heb ik al gedaan. Bij een mouseover op het WiFi icoon staat er “Connection to dhcpcd lost”. Ook via raspi-config krijg ik een foutmelding als naar Network options->WiFi ga : Could not communicate with WPA_supplicant.SpeedingWilly schreef op dinsdag 29 mei 2018 @ 12:39:
Probeer dit eens:
SpeedingWilly in "[SolarEdge] Omvormers en optimizers zelf monitoren"
Ik heb hetzelfde gedaan en de WiFi met de bedrade USB dongle in een bond gezet. Dat werkt prima met als voordeel dat als je de dongel eruit trekt het blijft werken via WiFi!
Ipsa scientia potestas est
Ik heb alles op de cmd line gedaan. Ik heb gemerkt dat in de UI internet ook niet lekker werkt, maar headless wel.Fidler schreef op donderdag 31 mei 2018 @ 21:52:
[...]
Helaas werkt dit niet. Zodra ik een aanpassing doe in /etc/network/interfaces wil raspbian wlan0 niet meer starten. Krijg dan de melding dat ik landcode moet instellen maar dat heb ik al gedaan. Bij een mouseover op het WiFi icoon staat er “Connection to dhcpcd lost”. Ook via raspi-config krijg ik een foutmelding als naar Network options->WiFi ga : Could not communicate with WPA_supplicant.
Uiteraard moet je wel je Wifi SSID en je (geencrypte) Wifi paswoord invullen.
[ Voor 5% gewijzigd door SpeedingWilly op 01-06-2018 09:29 ]
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Oh, dat is niet zo consequent van mij. Ik heb het commando onder 4.1 maar even veranderd naar 'eth1', thanks!Fidler schreef op dinsdag 29 mei 2018 @ 14:48:
Thanks, ga ik straks even proberen.
Zag in de originele omschrijving wel iets wat ik niet helemaal snap :
4.1
Om de logger te testen sluit je even een computer/laptop aan in plaats van de omvormer en draai je het volgende commando op de logger (dit gaat er van uit dat de testcomputer op poort eth0 is aangesloten)
5.7
Open 'se-logger-service.sh' en zorg dat in het SETTINGS gedeelte 'interface' verwijst naar de netwerkpoort waarop de omvormer is aangesloten. Als je sectie 4.1 hebt gevolgd is het waarschijnlijk 'eth1' of 'wlan0'; als je sectie 4.2 hebt gevolgd is het 'eth0'.
Heeft er iemand ooit problemen gehad met de wifi naar raspi config?
Als ik met mijn telefoon inlog op het wlan netwerk van de raspi krijg ik netjes data op tcpdump. Ik kan mijn wifimodulle in de solaredge hd ook configureren met als resultaat succes maar krijg geen data binnen.
Ben al 2 dagen aan het stoeien maar krijg het niet aan de gang. Iemand tips?\
Alvast bedankt
Als ik met mijn telefoon inlog op het wlan netwerk van de raspi krijg ik netjes data op tcpdump. Ik kan mijn wifimodulle in de solaredge hd ook configureren met als resultaat succes maar krijg geen data binnen.
Ben al 2 dagen aan het stoeien maar krijg het niet aan de gang. Iemand tips?\
Alvast bedankt
Als je met je telefoon op het wlan netwerk van de Pi zit, kun je er dan ook daadwerkelijk mee internetten of whatsappen? Dat je data krijgt te zien in tcpdump is één (dat betekent dat je telefoon en de Pi kunnen communiceren), maar je telefoon moet via je Pi het internet ook nog kunnen bereikensunlight78 schreef op zondag 3 juni 2018 @ 14:53:
Heeft er iemand ooit problemen gehad met de wifi naar raspi config?
Als ik met mijn telefoon inlog op het wlan netwerk van de raspi krijg ik netjes data op tcpdump. Ik kan mijn wifimodulle in de solaredge hd ook configureren met als resultaat succes maar krijg geen data binnen.
Ben al 2 dagen aan het stoeien maar krijg het niet aan de gang. Iemand tips?\
Alvast bedankt
Ja geen problemen mee kan alles verzenden.Jerrythafast schreef op zondag 3 juni 2018 @ 14:57:
[...]
Als je met je telefoon op het wlan netwerk van de Pi zit, kun je er dan ook daadwerkelijk mee internetten of whatsappen? Dat je data krijgt te zien in tcpdump is één (dat betekent dat je telefoon en de Pi kunnen communiceren), maar je telefoon moet via je Pi het internet ook nog kunnen bereiken
Anoniem: 605597
kan het iets met de firewall van de raspi zijn?
of misschien met de wiffimodule. krijg namelijk helemaal niks door op tcp. hij zou altijd iets moeten geven aan data toch?
ps ik ben sunlight78. zie nu dat ik op de telefoon een ander account heb.
of misschien met de wiffimodule. krijg namelijk helemaal niks door op tcp. hij zou altijd iets moeten geven aan data toch?
ps ik ben sunlight78. zie nu dat ik op de telefoon een ander account heb.
[ Voor 68% gewijzigd door Anoniem: 605597 op 04-06-2018 15:25 ]
Ik krijg nu onderstaande binnen op tcp. Ip adres 102 klopt alleen zou niet weten of het goed of slecht is.
sudo tcpdump -i wlan0 host 192.168.177.102 -U -w -
�ò�tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
�E�]�}@�����f��EA@�����f����5-�prod2comsolaredgecomt[}�OO�'����'
sudo tcpdump -i wlan0 host 192.168.177.102 -U -w -
�ò�tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
�E�]�}@�����f��EA@�����f����5-�prod2comsolaredgecomt[}�OO�'����'
Ziet er "goed achtig" uit. Probeer het voor een voor mensen leesbare output even met dit commando:sunlight78 schreef op maandag 4 juni 2018 @ 19:19:
Ik krijg nu onderstaande binnen op tcp. Ip adres 102 klopt alleen zou niet weten of het goed of slecht is.
sudo tcpdump -i wlan0 host 192.168.177.102 -U -w -
�ò�tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
�E�]�}@�����f��EA@�����f����5-�prod2comsolaredgecomt[}�OO�'����'
sudo tcpdump -i wlan0 host 192.168.177.102
Iemand tips voor een slimmere 'sync' indien de NAS DB niet up-to-date is?SpeedingWilly schreef op donderdag 31 mei 2018 @ 10:03:
Ik schrijf de logging weg naar de rPi en tegelijkertijd ook naar mijn NAS.
Als de NAS om wat voor reden (b.v. reboot etc) even niet online is, wat gebeurt er dan met de DB data die naar de NAS weggeschreven wordt terwijl die (even) offline is? Ben ik die data dan kwijt? Of probeert het script het opnieuw?
Ik kan uiteraard de DB opnieuw vullen met alle pcap files, maar is er een slimmere manier als er data niet naar de NAS geschreven is?
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Dan is dit de output. Ik krijg nu ook alles op de website van solaredge te zien maar nog steeds niets in de database.Jerrythafast schreef op maandag 4 juni 2018 @ 21:15:
[...]
Ziet er "goed achtig" uit. Probeer het voor een voor mensen leesbare output even met dit commando:
sudo tcpdump -i wlan0 host 192.168.177.102
16:43:11.519247 IP 185.121.71.35.22222 > 192.168.178.167.49152: Flags [.], ack 81764, win 65220, length 0
16:43:11.523370 IP 192.168.178.167.49152 > 185.121.71.35.22222: Flags [.], ack 5157, win 1640, length 0
16:43:11.748801 ARP, Request who-has 192.168.178.167 tell 192.168.178.1, length 46
16:43:11.752789 ARP, Reply 192.168.178.167 is-at 00:40:9d:90:f3:fd (oui Unknown), length 28
16:43:26.782230 IP 192.168.178.167.49152 > 185.121.71.35.22222: Flags [P.], seq 81764:81786, ack 5157, win 1640, length 22
16:43:26.861734 IP 185.121.71.35.22222 > 192.168.178.167.49152: Flags [.], ack 81786, win 65198, length 0
16:43:26.866537 IP 192.168.178.167.49152 > 185.121.71.35.22222: Flags [.], ack 5157, win 1640, length 0
Worden de solaredge-201806xxxxxxxx.pcap files wel netjes gevuld?
Mocht iemand nog op zoek zijn naar kortere logintervallen dan de standaard 300 seconden...
Sinds mijn modbus-consumptiemeter aan de SE omvormer hangt, krijg ik vrijwel live (3 seconden interval) data door via het SE-dashboard.
Door het dataverkeer te analyseren met wireshark heb ik achterhaald hoe mijn omvormer die live-data doorstuurt (alleen power values, geen energy), maar dat doet ie alleen elke 3 seconden als er iemand naar dat dashboard zit te kijken, standaard wel elke 300 sec.
Het dashboard lijkt deze json op te vragen bij mij:
https://monitoring.solare...de>/currentPowerFlow.json
(uiteraard op de juiste plaats jouw eigen sitecode invullen in deze link)
Die lijkt uiteraard op een standaard API call van SE, maar via de API zegt SE dat ze maximaal 300 requests per dag toestaan.
Ik heb het bij mij nu zo geregeld dat live-update.py ook die data en de data van mijn modbusmeter (0x0022) snift en naar de MySQL stuurt.
Met dank aan de repository van jbuehl voor de informatie over de 0x0022 metering data.
Sinds mijn modbus-consumptiemeter aan de SE omvormer hangt, krijg ik vrijwel live (3 seconden interval) data door via het SE-dashboard.
Door het dataverkeer te analyseren met wireshark heb ik achterhaald hoe mijn omvormer die live-data doorstuurt (alleen power values, geen energy), maar dat doet ie alleen elke 3 seconden als er iemand naar dat dashboard zit te kijken, standaard wel elke 300 sec.
Het dashboard lijkt deze json op te vragen bij mij:
https://monitoring.solare...de>/currentPowerFlow.json
(uiteraard op de juiste plaats jouw eigen sitecode invullen in deze link)
Die lijkt uiteraard op een standaard API call van SE, maar via de API zegt SE dat ze maximaal 300 requests per dag toestaan.
Ik heb het bij mij nu zo geregeld dat live-update.py ook die data en de data van mijn modbusmeter (0x0022) snift en naar de MySQL stuurt.
Met dank aan de repository van jbuehl voor de informatie over de 0x0022 metering data.
[ Voor 3% gewijzigd door charlygolf op 06-06-2018 15:04 ]
Ze groeien wel als je dat bedoeltJerrythafast schreef op dinsdag 5 juni 2018 @ 22:47:
Worden de solaredge-201806xxxxxxxx.pcap files wel netjes gevuld?
Helemaal raar, het zit in de uitvoering van het script. Ik heb nu de key grabber gedraaid en die heeft netjes de key uit de pcap files getrokken. Maar nog steeds niets in de database. Kan ik controleren of mijn script goed uitgevoerd wordt om alles in de db te zetten?
Okee, je hebt je key in ieder geval te pakken, dat is mooi. Bewaar vooral de pcap files, zodra we erachter zijn wat er mis gaat en dat hebben gefixt kun je namelijk je database alsnog vullen met de data die daar in zit.sunlight78 schreef op vrijdag 8 juni 2018 @ 08:59:
Helemaal raar, het zit in de uitvoering van het script. Ik heb nu de key grabber gedraaid en die heeft netjes de key uit de pcap files getrokken. Maar nog steeds niets in de database. Kan ik controleren of mijn script goed uitgevoerd wordt om alles in de db te zetten?
Je kunt in liveupdate.log kijken wat het script aan het doen is. Als het goed is staat er alleen 'Reading from -' en iets als 'Setting new 0503 key'. Als je daar heel veel verhalen te zien krijgt over 'mysterious bytes' heb je waarschijnlijk je key niet goed in het liveupdate.py script gezet.
[ Voor 9% gewijzigd door Jerrythafast op 09-06-2018 11:47 ]
SInds woensdag heb ik een Solaredge HD wave, aangesloten met en vast ipadres op een fritsbox van XS4all. Gisteravond een stroomstoring gehad in het dorp, en zeker sindsdien (mogelijk eerder) krijg ik bij de lan aansluiting
Status: 11000000 (of soms 11100000)
- G server ping failed
- server 1 ping failed
- server 2 ping failed
- tcp connect failed.
Google geeft hierover geen zinvolle info.
Ik zelf heb vanaf de switch het adres prod.solaredge.com:22222 al gepingd, dat gaat goed. prod.solaredge.com:22222 is volgens de handleiding het adres dat benaderd wordt. Idem vanaf een willekeurige client in het netwerk. Ipadres dat de omvormer geeft (xxx.xxx.xxx.57) wordt ook netjes vermeld op de router en op de gekoppelde switch. Dat adres is ook vanaf een andere client te pingen. De omvormer geeft ook netjes mijn gateway aan (XXX.XXX.XXX.1)
Kortom: ik weet het effe niet meer. Is iemand die hier meer over kan zeggen?
nb: het heeft woensdag, en donderdag gewerkt. Sinds vrijdagochtend heb ik de lan status niet meer gecontroleerd.
En het antwoord gevonden: ik heb de omvormer een nieuw ipadres gegeven, lan kabel losgehaald en weer vastgemaakt en nu werkt de communicatie weer. Rara. Er waren geen dubbele adressen uitgedeeld, dus wat het nu geweest is....
Status: 11000000 (of soms 11100000)
- G server ping failed
- server 1 ping failed
- server 2 ping failed
- tcp connect failed.
Google geeft hierover geen zinvolle info.
Ik zelf heb vanaf de switch het adres prod.solaredge.com:22222 al gepingd, dat gaat goed. prod.solaredge.com:22222 is volgens de handleiding het adres dat benaderd wordt. Idem vanaf een willekeurige client in het netwerk. Ipadres dat de omvormer geeft (xxx.xxx.xxx.57) wordt ook netjes vermeld op de router en op de gekoppelde switch. Dat adres is ook vanaf een andere client te pingen. De omvormer geeft ook netjes mijn gateway aan (XXX.XXX.XXX.1)
Kortom: ik weet het effe niet meer. Is iemand die hier meer over kan zeggen?
nb: het heeft woensdag, en donderdag gewerkt. Sinds vrijdagochtend heb ik de lan status niet meer gecontroleerd.
En het antwoord gevonden: ik heb de omvormer een nieuw ipadres gegeven, lan kabel losgehaald en weer vastgemaakt en nu werkt de communicatie weer. Rara. Er waren geen dubbele adressen uitgedeeld, dus wat het nu geweest is....
[ Voor 20% gewijzigd door winnie op 10-06-2018 08:44 ]
Het enigste wat er staat is Reading from - en voor de rest komt er niets in. Ook niets over setting new keyJerrythafast schreef op zaterdag 9 juni 2018 @ 11:46:
[...]
Okee, je hebt je key in ieder geval te pakken, dat is mooi. Bewaar vooral de pcap files, zodra we erachter zijn wat er mis gaat en dat hebben gefixt kun je namelijk je database alsnog vullen met de data die daar in zit.
Je kunt in liveupdate.log kijken wat het script aan het doen is. Als het goed is staat er alleen 'Reading from -' en iets als 'Setting new 0503 key'. Als je daar heel veel verhalen te zien krijgt over 'mysterious bytes' heb je waarschijnlijk je key niet goed in het liveupdate.py script gezet.
Oké, dat is wel interessant. Ik had op zijn minst iets verwacht, aangezien je aangeeft dat de data wel op de monitoring website terechtkomen. Om het even helemaal clean te testen kun je dit proberen:sunlight78 schreef op zondag 10 juni 2018 @ 17:09:
[...]
Het enigste wat er staat is Reading from - en voor de rest komt er niets in. Ook niets over setting new key
1. Trek de netwerkkabel van de omvormer eruit, zodat die geen verbinding meer heeft.
2. Reboot je logger, zodat die ook met een schone lei start.
3. Wacht nog een kwartiertje.
4. Steek de netwerkkabel van de omvormer er weer in.
Daarna zou die binnen enkele minuten moeten verbinden en zodra dat gebeurt zou je in de liveupdate.log de 'Setting new key' regel te zien moeten krijgen. En direct daarna moet de data van de laatste 15 à 20 minuten in je database terecht komen.
Als dat niet werkt ga ik je vragen of je een pcap file met mij zou willen delen, ik vermoed dat er dan toch iets aan se-logger aangepast moet worden dat jij hebt ontdekt
Ik heb net het is-pcap-encrypted.py script gedraait en deze geeft aan dat 40% encrypted is dus er is data in de pcab file. Ik zie met whireshark ook de solaredge code staan dus dit is in ieder geval goed.Jerrythafast schreef op zondag 10 juni 2018 @ 17:58:
[...]
Oké, dat is wel interessant. Ik had op zijn minst iets verwacht, aangezien je aangeeft dat de data wel op de monitoring website terechtkomen. Om het even helemaal clean te testen kun je dit proberen:
1. Trek de netwerkkabel van de omvormer eruit, zodat die geen verbinding meer heeft.
2. Reboot je logger, zodat die ook met een schone lei start.
3. Wacht nog een kwartiertje.
4. Steek de netwerkkabel van de omvormer er weer in.
Daarna zou die binnen enkele minuten moeten verbinden en zodra dat gebeurt zou je in de liveupdate.log de 'Setting new key' regel te zien moeten krijgen. En direct daarna moet de data van de laatste 15 à 20 minuten in je database terecht komen.
Als dat niet werkt ga ik je vragen of je een pcap file met mij zou willen delen, ik vermoed dat er dan toch iets aan se-logger aangepast moet worden dat jij hebt ontdekt
[ Voor 12% gewijzigd door sunlight78 op 11-06-2018 20:57 ]
Ik bedacht me nog één ding dat je zou kunnen proberen.sunlight78 schreef op maandag 11 juni 2018 @ 19:15:
[...]
Ik heb net het is-pcap-encrypted.py script gedraait en deze geeft aan dat 40% encrypted is dus er is data in de pcab file. Ik zie met whireshark ook de solaredge code staan dus dit is in ieder geval goed.
Python:
1
2
3
4
5
| #liveupdate.py regel 344-346 # There may be some remaining padding bytes after the data; skip that. if packet_offset: f.read(packet_offset) |
Vóór dit stukje, kun je de volgende regel invoegen (let op inspringen met 8 spaties):
Python:
1
2
3
4
5
| else: print("".join("\\x%x" % ord(x) for x in etherhdr[6:9])) # Nieuwe regel om te testen # There may be some remaining padding bytes after the data; skip that. if packet_offset: f.read(packet_offset) |
Als je daarna de solaredge-logger service opnieuw start, zou je in liveupdate.log niets nieuws moeten zien. Zie je toch iets nieuws, dan heeft SolarEdge een nieuwe prefix voor hun MAC-adressen.
[ Voor 1% gewijzigd door Jerrythafast op 11-06-2018 21:24 . Reden: Typfout in code ]
Ik krijg nu de foutmeldingJerrythafast schreef op maandag 11 juni 2018 @ 21:22:
[...]
Ik bedacht me nog één ding dat je zou kunnen proberen.
Python:
1 2 3 4 5 #liveupdate.py regel 344-346 # There may be some remaining padding bytes after the data; skip that. if packet_offset: f.read(packet_offset)
Vóór dit stukje, kun je de volgende regel invoegen (let op inspringen met 8 spaties):
Python:
1 2 3 4 5 else: print("".join("\\x%x" % ord(x) for x in etherhdr[6:9])) # Nieuwe regel om te testen # There may be some remaining padding bytes after the data; skip that. if packet_offset: f.read(packet_offset)
Als je daarna de solaredge-logger service opnieuw start, zou je in liveupdate.log niets nieuws moeten zien. Zie je toch iets nieuws, dan heeft SolarEdge een nieuwe prefix voor hun MAC-adressen.
File "/opt/se-logger/liveupdate.py", line 344
else print("".join("\\x%x" % ord(x) for x in etherhdr[6:9]))
^
IndentationError: unexpected unindent
Heeft dat met dat inspringen te maken?
Ja. Acht spaties, precies zoals mijn voorbeeld. Ook zat er nog een typfout in mijn regel code: er moet een dubbele punt na 'else'. Hierboven al gecorrigeerd.sunlight78 schreef op maandag 11 juni 2018 @ 21:29:
[...]
Ik krijg nu de foutmelding
File "/opt/se-logger/liveupdate.py", line 344
else print("".join("\\x%x" % ord(x) for x in etherhdr[6:9]))
^
IndentationError: unexpected unindent
Heeft dat met dat inspringen te maken?
Ok aangepast en een reboot gedaan voor de zekere geit. Krijg nog steedsJerrythafast schreef op maandag 11 juni 2018 @ 21:30:
[...]
Ja. Acht spaties, precies zoals mijn voorbeeld. Ook zat er nog een typfout in mijn regel code: er moet een dubbele punt na 'else'. Hierboven al gecorrigeerd.
Reading from -
Voor de rest geen data
Alvast bedankt voor de super support!!
Op het moment dat ik nu de database probeer te vullen door alle pcap files te verwerken krijg ik een hele andere output in de cmd
\x0\x27\x10
\x0\x27\x10
\xb8\x27\xeb
\xb8\x27\xeb
\x0\x27\x10
\xb8\x27\xeb
\xb8\x27\xeb
\xb8\x27\xeb
\xb8\x27\xeb
\xb8\x27\xeb
\x0\x27\x10
\xb8\x27\xeb
\xb8\x27\xeb
\x0\x27\x10
\x0\x27\x10
\x0\x27\x10
\xb8\x27\xeb
\xb8\x27\xeb
\x0\x27\x10
\xb8\x27\xeb
\xb8\x27\xeb
\xb8\x27\xeb
\xb8\x27\xeb
\xb8\x27\xeb
\x0\x27\x10
\xb8\x27\xeb
\xb8\x27\xeb
\x0\x27\x10
"Intel Corporate, Malaysia"?!sunlight78 schreef op maandag 11 juni 2018 @ 22:57:
Op het moment dat ik nu de database probeer te vullen door alle pcap files te verwerken krijg ik een hele andere output in de cmd
\x0\x27\x10
\x0\x27\x10
\xb8\x27\xeb
\xb8\x27\xeb
\x0\x27\x10
\xb8\x27\xeb
\xb8\x27\xeb
\xb8\x27\xeb
\xb8\x27\xeb
\xb8\x27\xeb
\x0\x27\x10
\xb8\x27\xeb
\xb8\x27\xeb
\x0\x27\x10

Okee, hier is je fix.
Python:
1
2
3
| #liveupdate.py regel 315. if etherhdr[6:9] in ("\x00\x27\x02", "\x00\x40\x9d"): # Inverter speaking. |
Vervangen door:
Python:
1
2
3
| #liveupdate.py regel 315. if etherhdr[6:9] in ("\x00\x27\x02", "\x00\x27\x10", "\x00\x40\x9d"): # Inverter speaking. |
De "else" regel die we eerder hadden toegevoegd kan weer weg.
Ik ben nu wel nieuwsgierig, heb je de omvormer met een netwerkkabel rechtstreeks aan je Raspberry hangen, of zit daar nog iets tussen?
[ Voor 7% gewijzigd door Jerrythafast op 12-06-2018 20:55 ]
Ik heb de pi via ethernet aan het netwerk hangen en de omvormer via wifi aan de pi.Jerrythafast schreef op dinsdag 12 juni 2018 @ 20:14:
[...]
"Intel Corporate, Malaysia"?!
Okee, hier is je fix.
Python:
1 2 3 #liveupdate.py regel 315. if etherhdr[6:9] in ("\x00\x27\x02", "\x00\x40\x9d"): # Inverter speaking.
Vervangen door:
Python:
1 2 3 #liveupdate.py regel 315. if etherhdr[6:9] in ("\x00\x27\x02", "\x00\x27\x10", "\x00\x40\x9d"): # Inverter speaking.
De "else" regel die we eerder hadden toegevoegd kan weer weg.
Ik ben nu wel nieuwsgierig, heb je de omvormer met een netwerkkabel rechtstreeks aan je Raspberry hangen, of zit daar nog iets tussen?
Nu krijg ik info in mijn database. Heb net de backup gedraaid en de server weer herstart. Nu kreeg ik alleen in het log de volgende foutmelding
56cdc000 Out of order packet! SEQ=0024745f expect=002339de (Gap size 80513)
Setting new 0503 key
/opt/se-logger/liveupdate.py:376: Warning: Duplicate entry '1528832360-1930841012' for key 'PRIMARY'
self.cursor.execute(*args)
[ Voor 29% gewijzigd door sunlight78 op 12-06-2018 21:57 ]
Ah, dan heeft SolarEdge blijkbaar een nieuwe fabrikant gevonden voor hun WiFi modulessunlight78 schreef op dinsdag 12 juni 2018 @ 21:06:
[...]
Ik heb de pi via ethernet aan het netwerk hangen en de omvormer via wifi aan de pi.
Mooi! Dit was inderdaad het probleem. De melding die je krijgt kan wel eens gebeuren, zeker als er een WiFi verbinding tussen zit waarop weleens wat pakketjes wegwaaien. TCP en het SolarEdge protocol zelf zijn behoorlijk robuust en zullen data herhaaldelijk sturen als het niet goed door lijkt te komen.Nu krijg ik info in mijn database. Heb net de backup gedraaid en de server weer herstart. Nu kreeg ik alleen in het log de volgende foutmelding
56cdc000 Out of order packet! SEQ=0024745f expect=002339de (Gap size 80513)
Setting new 0503 key
/opt/se-logger/liveupdate.py:376: Warning: Duplicate entry '1528832360-1930841012' for key 'PRIMARY'
self.cursor.execute(*args)
Kijk mooizo. Nu komt de info netjes in de database. Hartelijk bedankt voor de troubleshooting. Op naar het volgende project. Mijn analoge meter uitlezen met 2 cny70 sensors en een arduino gekoppeld aan de database.
@ocaj ik heb toch wat vragen nav je post, even van topic gewisseld. ocaj in "Electriciteit opwekken met zonnepanelen (PV) deel 7" het zijn echt schitterende grafieken voor de TweakerT.
Hoe ben jij dan aangesloten, met deze module als extra en waar zit de RS485 aansluiting op, een fysieke pc?
https://www.installand.nl...0s6A7dEAQYASABEgKWZPD_BwE
Als ik dit topic doorneem dan komen er wat vragen bij mij op over de alternatieve methodes. Want een Pi kan je niet via een mirroring port op een switch benaderen? Het is of mirroring of IP communicatie, toch @Jerrythafast ?
Hoe ben jij dan aangesloten, met deze module als extra en waar zit de RS485 aansluiting op, een fysieke pc?
https://www.installand.nl...0s6A7dEAQYASABEgKWZPD_BwE
Als ik dit topic doorneem dan komen er wat vragen bij mij op over de alternatieve methodes. Want een Pi kan je niet via een mirroring port op een switch benaderen? Het is of mirroring of IP communicatie, toch @Jerrythafast ?
Ben dan ook wel benieuwd of je op deze manier het RS485 signaal digitaal naar een VMware server door kan trekken over IP? https://www.moxa.com/doc/specs/NPort_5100A_Series.pdf
Ik gebruik de 5110A al voor wat radio zend hobby, en die dingen zijn echt heel stabiel. Komt netjes binnen op een VM op een VMware servertje op een Intel NUC
Ik gebruik de 5110A al voor wat radio zend hobby, en die dingen zijn echt heel stabiel. Komt netjes binnen op een VM op een VMware servertje op een Intel NUC
Ik heb sinds kort ook een Solar Edge hangen. Heb gisteren via de rs 232 de key uitgelezen.
Echter blijf ik volgende melding krijgen:
ERROR! PCAP format not supported! Can only read little-endian PCAP files with microsecond precision!
Het is wel zo dat ik de tcpdump neem op mijn gateway/router via SSH, welke inderdaad little vs big (op de raspberry) endian heeft.
Bestaat hier geen oplossing voor?
Echter blijf ik volgende melding krijgen:
ERROR! PCAP format not supported! Can only read little-endian PCAP files with microsecond precision!
Het is wel zo dat ik de tcpdump neem op mijn gateway/router via SSH, welke inderdaad little vs big (op de raspberry) endian heeft.
Bestaat hier geen oplossing voor?
@Kaisar even voor de zekerheid: je weet zeker dat de endianness het probleem is? Dus jouw PCAP file begint met de HEX-code "a1 b2 c3 d4"? (Geopend in Windows kladblok met ANSI codering is dat "¡²ÃÔ".)
Als dat het werkelijk is, heb je iets nodig als dit om de endianness om te draaien. (Eerste wat ik kon vinden, misschien zijn er meerdere. Geen ervaring mee.) En als dat voor jou goed werkt ben ik wel bereid zoiets in se-logger in te bouwen zodat hij ook big-endian microsecond precision PCAP files kan lezen
Als dat het werkelijk is, heb je iets nodig als dit om de endianness om te draaien. (Eerste wat ik kon vinden, misschien zijn er meerdere. Geen ervaring mee.) En als dat voor jou goed werkt ben ik wel bereid zoiets in se-logger in te bouwen zodat hij ook big-endian microsecond precision PCAP files kan lezen
Mijn solaredge (nog de niet-HD versie) heeft standaard rs485, geen idee waar deze module precies voor is, maar ik had hem niet nodig.stormfly schreef op zaterdag 16 juni 2018 @ 08:40:
@ocaj ik heb toch wat vragen nav je post, even van topic gewisseld. ocaj in "Electriciteit opwekken met zonnepanelen (PV) deel 7" het zijn echt schitterende grafieken voor de TweakerT.
Hoe ben jij dan aangesloten, met deze module als extra en waar zit de RS485 aansluiting op, een fysieke pc?
https://www.installand.nl...0s6A7dEAQYASABEgKWZPD_BwE
Mijn omvormer hangt simpelweg niet aan het internet, dus hij hangt alleen via rs485 en een meter of 10 aan cat6-kabel aan een usb-rs485-adapter aan een raspberry pi. Op die raspberry pi draai ik het script van jbuehl en de output daarvan gooi ik een een mysql-database die dan weer niet op de pi draait, maar op mijn NAS.
Naast de solaredge-modbus heb ik er nog een usb-rs485 adapter waarmee ik de kwh-meters in de meterkast mee uitlees (1 x per seconde), zodat ik ook mijn eigenverbruik kan registreren.
Verder draait er op de pi ook nog een webserver waar ik de live-data (json-output) en de historische data (.csv-bestanden die ik elke nacht uit mijn database dump) op toon middels highcharts.
Highcharts zorgt dat het er gelikt uitziet, als je eenmaal door hebt hoe je de data erin zet, dan kun je daarna helemaal losgaan en vrij eenvoudig elk grafiekje of plaatje maken waar je behoefte aan hebt.
@Jerrythafast Jerrythafast Heb even jou script toegepast en gezien aan volgende output zit dat wel in orde:
pi@wolverine:~/solaredge $ python -c 'import sys;f=open(sys.argv[1],"r");print(" ".join("%02X" % ord(x) for x in f.read(24)));f.close()' solar.pcap
A1 B2 C3 D4 00 02 00 04 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 01
pi@wolverine:~/solaredge $ python -c 'import sys;f=open(sys.argv[1],"r");print(" ".join("%02X" % ord(x) for x in f.read(24)));f.close()' solar.pcap
A1 B2 C3 D4 00 02 00 04 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 01
Interessant, inderdaad een big-endian pcap file.Kaisar schreef op zaterdag 16 juni 2018 @ 23:53:
@Jerrythafast Jerrythafast Heb even jou script toegepast en gezien aan volgende output zit dat wel in orde:
pi@wolverine:~/solaredge $ python -c 'import sys;f=open(sys.argv\[1],"r");print(" ".join("%02X" % ord(x) for x in f.read(24)));f.close()' solar.pcap
A1 B2 C3 D4 00 02 00 04 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 01
Zou het voor jou erg veel werk zijn om één zo'n file door de pcap-endianness-converter heen te halen die ik linkte en het output bestand dan aan liveupdate.py te voeren? Ik zou graag willen weten of de conversie die dat programma doet voldoende is om het bestand te kunnen lezen. Dan bouw ik gewoon dezelfde omzetting in in liveupdate.py. Maar als er meer nodig blijkt te zijn doe ik liever nu geen onnodig werk
Dit lijkt te werken:Jerrythafast schreef op zondag 17 juni 2018 @ 09:38:
[...]
Interessant, inderdaad een big-endian pcap file.
Zou het voor jou erg veel werk zijn om één zo'n file door de pcap-endianness-converter heen te halen die ik linkte en het output bestand dan aan liveupdate.py te voeren? Ik zou graag willen weten of de conversie die dat programma doet voldoende is om het bestand te kunnen lezen. Dan bouw ik gewoon dezelfde omzetting in in liveupdate.py. Maar als er meer nodig blijkt te zijn doe ik liever nu geen onnodig werk
pi@wolverine:~/solaredge $ java -jar pcap-endianness-converter.jar little-endian out.pcap try.pcap
Records converted: 22
Records ignored: 0
Echter:
pi@wolverine:~/solaredge $ cat out.pcap | python liveupdate.py -
Reading from -
Warning! Got 22 mysterious bytes left! (state=0)
c0 6b b2 71 e5 5c 36 04 cb 4d a6 88 32 95 8a 15 73 19 63 9f c3 f8
Warning! Got 22 mysterious bytes left! (state=0)
c5 f7 69 12 a1 ee b7 ab ff 41 b6 e1 79 43 13 f3 df 02 fc 5d b4 f6
56ce0564 Out of order packet! SEQ=02fea8e1 expect=02fea8d7 (Gap size 10)
56ce0564 Out of order packet! SEQ=02feab05 expect=02fea8d7 (Gap size 558)
56ce0564 DATA LOSS 10 bytes!
56ce0564 Gap closed after 99.996411 seconds
Warning! Checksum failure, skipping over barker...
Warning! Skipping 534 mysterious bytes!
0e 02 f1 fd 55 02 4a 4c 11 73 fe ff ff ff 3d 00 13 25 9b fe 01 78 0a c1 6c 7b eb 77 bc e3 65 2e 05 e2 94 97 ee 08 3b 9d 0c f6 34 20 84 17 ba 7f 80 10 b6 fc 05 30 71 4c 7b e4 9e af b2 c8 88 7d 81 9f 70 f8 fe 24 0e ed 7b 65 0e c8 f5 cc c1 7b 5a ff 90 9b 6f ba e2 55 c5 62 19 b0 2e 7c b8 92 c6 d1 cc 34 1b 79 ac 0b c8 e2 ba 9a a7 8e 32 3e f9 0f 82 2e 5b 46 85 59 ef 1b 17 94 19 c7 e4 82 59 4e 58 cb 33 91 c1 2f 24 6e 8d 56 85 58 20 99 6a 11 55 78 24 54 b1 dc e8 72 8d 8f e3 52 e5 24 f0 66 6c 98 76 34 a2 43 1c 1b 52 62 8a 15 c7 8b 9d 74 64 9c 67 f4 88 60 a6 09 85 80 aa 31 0d 4b 19 49 58 6e ec 74 f6 f0 d6 3c 03 fd 41 b4 b0 7b 6f 0d ff aa 56 6c 62 9b da 11 57 9f 6d d3 ec b3 79 37 99 ad d1 98 89 da 89 27 b2 dd dc 56 f0 f9 9d 7f 71 f1 1d f4 e7 a9 ea ff 41 ab 4a 80 b4 9b e0 a8 82 85 0c 4e fe b5 9e a6 45 8b 79 74 02 ff 48 83 14 4a bb f1 89 1f ee 9e 3c 48 39 53 ce 0e e5 03 f0 ee 83 b9 2a b4 70 79 02 e1 15 d1 0b 26 73 53 f8 40 4b 07 b4 1b ff 99 5b 01 fb ae 87 5c 3e 40 d6 47 51 39 78 d0 e3 ba 6e 13 1e db 61 76 3c e9 c7 9e 6c e8 2b ea b7 2a 77 03 da 86 b2 80 13 88 9b cc cf a8 ea ae ee 14 15 61 de 20 db 35 61 38 74 57 28 56 9c bb e8 b4 60 3c ee 53 c3 40 23 f3 d5 69 ef 6f 50 4c e7 5a a0 78 c7 80 04 9f dd 43 2e 69 14 55 e8 3d a8 68 ae 16 e8 81 19 4e f7 0e 48 22 d4 ad 9f 6d fb 72 69 5f 45 4f 76 42 c3 bb 1d f3 04 6d 03 fd 9d ad 55 a1 21 82 86 51 81 51 0a ec 0f a3 d2 6a e5 5b f8 ae c8 45 5a 7c e3 04 ba 41 73 24 c6 4a 10 3a 3e 7f 13 5b dc b7 cc 78 20 13 a1 ee a7 c6 6a 95 22 c7 a1 99 ca 21 1a d7 95 6a 1a 6b 8e 3e 59 0a c7 47 58 97 98 64 0b 40 f8 55 8b 6e 32 85 a7 6e f5 17 bc 87 f9 00 20 8c 2a d7 73 e8
56ce0564 Out of order packet! SEQ=02feab05 expect=02feaafb (Gap size 10)
Warning! Got 538 mysterious bytes left! (state=7)
12 34 56 79 0e 02 f1 fd 56 02 4a 4c 11 73 fe ff ff ff 3d 00 86 7b 2a c5 b7 3d ff 08 ff b8 94 59 af 4b 71 6b e0 56 04 44 37 c9 54 bd 9d 60 cb 1a 2f b4 13 bb 2d 0a 0a bb 81 a8 0d c1 6c bf ae 95 28 70 53 c4 0e 2a 33 fd f0 41 14 64 15 b8 55 1d 83 6d 2a 17 1b 72 1c f8 5e 7c 05 5f c1 7e 8c f3 36 7f 3e 9c 8b 6e 42 36 b9 84 4a cb a2 57 f8 1d 3c 53 0b 85 7c 04 3a 27 43 b8 8c 66 f5 fa 0f bc 02 26 66 d4 55 5d 82 9d f7 88 82 fd 97 67 75 6c 2d 6f f5 c7 84 7b 35 6a 43 b5 d0 95 e9 70 45 0f 7e 4a 3c a6 1e ca e9 d0 6a 3d ca 58 d9 16 1e 38 7c ee 06 8a 2a 12 93 e9 58 f4 e1 5a e8 94 8d 85 0e ca d5 36 3c cd 5e ba 62 b7 18 ed 67 5f 74 18 7e c8 3c 5f d4 c9 d8 63 bd ef 93 d0 bf 4e 7d 62 2e ef 9a e3 2e c4 1f 2e 73 78 c6 3e fa 6a 8c e8 0b 0f bd 36 2e 9f 38 32 d3 db f8 65 a9 52 eb 32 1c ad 0f af 7c f9 f7 b6 7f 42 ab 29 41 fc 96 2b 76 bb 11 06 4f 4a 96 0c e5 f7 dc 83 16 1c 00 5d 46 da 07 7b a5 ab c5 4e 4e 87 0e 62 3f ba 14 16 8c 1e 6c 38 b4 b3 f8 74 bf d9 bd 26 19 64 78 ca 01 83 73 99 4f 90 6b b2 3f 20 2a 4c 52 e4 4e d6 19 87 91 1d 1a 42 5f d6 a4 88 fd 92 02 29 7e 29 54 44 9e c2 45 43 a2 7f f2 2f 94 01 99 52 f4 61 7c 7f ac 89 e0 32 f4 7a d8 9f da e6 13 66 52 eb 4a d3 37 16 1b d5 9e 3a 1d 6e 55 7e fb c7 ad 83 f1 6c 63 e8 2f 12 db 70 ac f9 a4 72 c4 45 6e 72 fa bc 5b e3 c5 16 cd cf 5b 08 87 71 5b d3 ab f1 d9 2e a9 fc e7 59 58 cc a3 af 1e 93 7a 40 a6 9d 11 d2 5c 02 1f 0e cb 79 7f c3 9a 77 95 32 c7 6f 98 25 7f ba 29 a3 f4 e3 ec f4 af 43 2f a2 c8 ee e6 75 57 54 66 dd 8c b3 c8 6a ed ac 03 37 44 10 8d c0 63 49 58 6e ac fc 3c 5d d6 05 65 7e 60 0a 59 8a 3f 63 3a 6f 7c db 10 2f e8 f8 4b e8 a6 29 81 db 41 01 f1 05 2d 8b 7f 60
End of file. Shutting down.
De sleutel heb ik eruit gehaald met (heb 2 getalletjes omgedraaid voor de post
pi@wolverine:~/solaredge $ python get-key-by-rs232-verbose.py
| BARKER | LEN |LEN_I| SEQ | SOURCE | DEST | CMD |DATA
SEND: 12 34 56 79 02 00 fd ff 01 00 fd ff ff ff 4a 4c 11 73 12 00 39 02 6f 82
RECV: 12 34 56 79 06 00 f9 ff 01 00 4a 4c 11 73 fd ff ff ff 90 00 59 53 ee 45 00 00 57 e3
SEND: 12 34 56 79 02 00 fd ff 02 00 fd ff ff ff 4a 4c 11 73 12 00 3a 02 6a b1
RECV: 12 34 56 79 06 00 f9 ff 02 00 4a 4c 11 73 fd ff ff ff 90 00 59 2f e1 2e 00 00 84 11
SEND: 12 34 56 79 02 00 fd ff 03 00 fd ff ff ff 4a 4c 11 73 12 00 3b 02 69 a0
RECV: 12 34 56 79 06 00 f9 ff 03 00 4a 4c 11 73 fd ff ff ff 90 00 0d 59 fe 4d 00 00 e6 54
SEND: 12 34 56 79 02 00 fd ff 04 00 fd ff ff ff 4a 4c 11 73 12 00 3c 02 60 d7
RECV: 12 34 56 79 06 00 f9 ff 04 00 4a 4c 11 73 fd ff ff ff 90 00 43 45 48 2c 00 00 fd df
Your key is '\x95..............'
En liveupdate.py:
#!/usr/bin/env python
import struct, sys, MySQLdb, time
from collections import namedtuple
__version__ = "0.0.9"
# SETTINGS
inverter_private_key = '\x95............'
db_user = "solar"
Enig idee wat hier nog mis kan zijn met de sleutel?
@Jerrythafast Heb voor de zekerheid nog maar eens de usb kabel er aan gehangen en de key opnieuw opgehaald. Die blijkt te kloppen dus ik ben even einde raad
[ Voor 5% gewijzigd door Kaisar op 18-06-2018 13:28 ]
Ik ga ook een PV installatie met SolarEdge installeren. Nu twijfel ik of ik meteen ook een SolarEdge Modbus meter mee bestel om ook gedetailleerde info van mijn 3 fasen inzichtelijk te krijgen.
Wat me niet direct duidelijk wordt is of de bestaande logging scripts ook de modbus data onderscheppen. Heeft iemand hier toevallig informatie over?
Ik krijg wellicht een nieuwe meter omdat ik mijn aansluiting upgrade naar 3 fasen. Nu zijn die slimme meters prima met de P1 poort uit te lezen. Is het in dit geval überhaupt zinvol om een modbus te plaatsen, of volstaat het uitlezen van de slimme meter ook wel? Wat is jullie advies?
Wat me niet direct duidelijk wordt is of de bestaande logging scripts ook de modbus data onderscheppen. Heeft iemand hier toevallig informatie over?
Ik krijg wellicht een nieuwe meter omdat ik mijn aansluiting upgrade naar 3 fasen. Nu zijn die slimme meters prima met de P1 poort uit te lezen. Is het in dit geval überhaupt zinvol om een modbus te plaatsen, of volstaat het uitlezen van de slimme meter ook wel? Wat is jullie advies?
Ziet eruit alsof dat inderdaad wel werkt! De pcap file parset goed (ik zie ook de kenmerkende 12 34 56 79 'barker' sequentie van SolarEdge voorbij komen), maar niet alle data lijkt lekker doorgekomen te zijn. Kan een gevalletje brakke wifi o.i.d. zijn. Als het goed is, is het hele gebeuren robuust genoeg dat het daar tegen kan. Ik zal komend weekend se-logger/liveupdate.py even een update geven om dit in te bouwen.Kaisar schreef op zondag 17 juni 2018 @ 14:55:
[...]
Dit lijkt te werken:
pi@wolverine:~/solaredge $ java -jar pcap-endianness-converter.jar little-endian out.pcap try.pcap
Records converted: 22
Records ignored: 0
Echter:
pi@wolverine:~/solaredge $ cat out.pcap | python liveupdate.py -
Reading from -
Warning! Got 22 mysterious bytes left! (state=0)
c0 6b b2 71 e5 5c 36 04 cb 4d a6 88 32 95 8a 15 73 19 63 9f c3 f8
Warning! Got 22 mysterious bytes left! (state=0)
c5 f7 69 12 a1 ee b7 ab ff 41 b6 e1 79 43 13 f3 df 02 fc 5d b4 f6
56ce0564 Out of order packet! SEQ=02fea8e1 expect=02fea8d7 (Gap size 10)
56ce0564 Out of order packet! SEQ=02feab05 expect=02fea8d7 (Gap size 558)
56ce0564 DATA LOSS 10 bytes!
56ce0564 Gap closed after 99.996411 seconds
Warning! Checksum failure, skipping over barker...
Warning! Skipping 534 mysterious bytes!
0e 02 f1 fd 55 02 4a 4c 11 73 fe ff ff ff 3d 00 13 25 9b fe 01 78 0a c1 6c 7b eb 77 bc e3 65 2e 05 e2 94 97 ee 08 3b 9d 0c f6 34 20 84 17 ba 7f 80 10 b6 fc 05 30 71 4c 7b e4 9e af b2 c8 88 7d 81 9f 70 f8 fe 24 0e ed 7b 65 0e c8 f5 cc c1 7b 5a ff 90 9b 6f ba e2 55 c5 62 19 b0 2e 7c b8 92 c6 d1 cc 34 1b 79 ac 0b c8 e2 ba 9a a7 8e 32 3e f9 0f 82 2e 5b 46 85 59 ef 1b 17 94 19 c7 e4 82 59 4e 58 cb 33 91 c1 2f 24 6e 8d 56 85 58 20 99 6a 11 55 78 24 54 b1 dc e8 72 8d 8f e3 52 e5 24 f0 66 6c 98 76 34 a2 43 1c 1b 52 62 8a 15 c7 8b 9d 74 64 9c 67 f4 88 60 a6 09 85 80 aa 31 0d 4b 19 49 58 6e ec 74 f6 f0 d6 3c 03 fd 41 b4 b0 7b 6f 0d ff aa 56 6c 62 9b da 11 57 9f 6d d3 ec b3 79 37 99 ad d1 98 89 da 89 27 b2 dd dc 56 f0 f9 9d 7f 71 f1 1d f4 e7 a9 ea ff 41 ab 4a 80 b4 9b e0 a8 82 85 0c 4e fe b5 9e a6 45 8b 79 74 02 ff 48 83 14 4a bb f1 89 1f ee 9e 3c 48 39 53 ce 0e e5 03 f0 ee 83 b9 2a b4 70 79 02 e1 15 d1 0b 26 73 53 f8 40 4b 07 b4 1b ff 99 5b 01 fb ae 87 5c 3e 40 d6 47 51 39 78 d0 e3 ba 6e 13 1e db 61 76 3c e9 c7 9e 6c e8 2b ea b7 2a 77 03 da 86 b2 80 13 88 9b cc cf a8 ea ae ee 14 15 61 de 20 db 35 61 38 74 57 28 56 9c bb e8 b4 60 3c ee 53 c3 40 23 f3 d5 69 ef 6f 50 4c e7 5a a0 78 c7 80 04 9f dd 43 2e 69 14 55 e8 3d a8 68 ae 16 e8 81 19 4e f7 0e 48 22 d4 ad 9f 6d fb 72 69 5f 45 4f 76 42 c3 bb 1d f3 04 6d 03 fd 9d ad 55 a1 21 82 86 51 81 51 0a ec 0f a3 d2 6a e5 5b f8 ae c8 45 5a 7c e3 04 ba 41 73 24 c6 4a 10 3a 3e 7f 13 5b dc b7 cc 78 20 13 a1 ee a7 c6 6a 95 22 c7 a1 99 ca 21 1a d7 95 6a 1a 6b 8e 3e 59 0a c7 47 58 97 98 64 0b 40 f8 55 8b 6e 32 85 a7 6e f5 17 bc 87 f9 00 20 8c 2a d7 73 e8
56ce0564 Out of order packet! SEQ=02feab05 expect=02feaafb (Gap size 10)
Warning! Got 538 mysterious bytes left! (state=7)
12 34 56 79 0e 02 f1 fd 56 02 4a 4c 11 73 fe ff ff ff 3d 00 86 7b 2a c5 b7 3d ff 08 ff b8 94 59 af 4b 71 6b e0 56 04 44 37 c9 54 bd 9d 60 cb 1a 2f b4 13 bb 2d 0a 0a bb 81 a8 0d c1 6c bf ae 95 28 70 53 c4 0e 2a 33 fd f0 41 14 64 15 b8 55 1d 83 6d 2a 17 1b 72 1c f8 5e 7c 05 5f c1 7e 8c f3 36 7f 3e 9c 8b 6e 42 36 b9 84 4a cb a2 57 f8 1d 3c 53 0b 85 7c 04 3a 27 43 b8 8c 66 f5 fa 0f bc 02 26 66 d4 55 5d 82 9d f7 88 82 fd 97 67 75 6c 2d 6f f5 c7 84 7b 35 6a 43 b5 d0 95 e9 70 45 0f 7e 4a 3c a6 1e ca e9 d0 6a 3d ca 58 d9 16 1e 38 7c ee 06 8a 2a 12 93 e9 58 f4 e1 5a e8 94 8d 85 0e ca d5 36 3c cd 5e ba 62 b7 18 ed 67 5f 74 18 7e c8 3c 5f d4 c9 d8 63 bd ef 93 d0 bf 4e 7d 62 2e ef 9a e3 2e c4 1f 2e 73 78 c6 3e fa 6a 8c e8 0b 0f bd 36 2e 9f 38 32 d3 db f8 65 a9 52 eb 32 1c ad 0f af 7c f9 f7 b6 7f 42 ab 29 41 fc 96 2b 76 bb 11 06 4f 4a 96 0c e5 f7 dc 83 16 1c 00 5d 46 da 07 7b a5 ab c5 4e 4e 87 0e 62 3f ba 14 16 8c 1e 6c 38 b4 b3 f8 74 bf d9 bd 26 19 64 78 ca 01 83 73 99 4f 90 6b b2 3f 20 2a 4c 52 e4 4e d6 19 87 91 1d 1a 42 5f d6 a4 88 fd 92 02 29 7e 29 54 44 9e c2 45 43 a2 7f f2 2f 94 01 99 52 f4 61 7c 7f ac 89 e0 32 f4 7a d8 9f da e6 13 66 52 eb 4a d3 37 16 1b d5 9e 3a 1d 6e 55 7e fb c7 ad 83 f1 6c 63 e8 2f 12 db 70 ac f9 a4 72 c4 45 6e 72 fa bc 5b e3 c5 16 cd cf 5b 08 87 71 5b d3 ab f1 d9 2e a9 fc e7 59 58 cc a3 af 1e 93 7a 40 a6 9d 11 d2 5c 02 1f 0e cb 79 7f c3 9a 77 95 32 c7 6f 98 25 7f ba 29 a3 f4 e3 ec f4 af 43 2f a2 c8 ee e6 75 57 54 66 dd 8c b3 c8 6a ed ac 03 37 44 10 8d c0 63 49 58 6e ac fc 3c 5d d6 05 65 7e 60 0a 59 8a 3f 63 3a 6f 7c db 10 2f e8 f8 4b e8 a6 29 81 db 41 01 f1 05 2d 8b 7f 60
End of file. Shutting down.
De sleutel heb ik eruit gehaald met (heb 2 getalletjes omgedraaid voor de post):
pi@wolverine:~/solaredge $ python get-key-by-rs232-verbose.py
| BARKER | LEN |LEN_I| SEQ | SOURCE | DEST | CMD |DATA
SEND: 12 34 56 79 02 00 fd ff 01 00 fd ff ff ff 4a 4c 11 73 12 00 39 02 6f 82
RECV: 12 34 56 79 06 00 f9 ff 01 00 4a 4c 11 73 fd ff ff ff 90 00 59 53 ee 45 00 00 57 e3
SEND: 12 34 56 79 02 00 fd ff 02 00 fd ff ff ff 4a 4c 11 73 12 00 3a 02 6a b1
RECV: 12 34 56 79 06 00 f9 ff 02 00 4a 4c 11 73 fd ff ff ff 90 00 59 2f e1 2e 00 00 84 11
SEND: 12 34 56 79 02 00 fd ff 03 00 fd ff ff ff 4a 4c 11 73 12 00 3b 02 69 a0
RECV: 12 34 56 79 06 00 f9 ff 03 00 4a 4c 11 73 fd ff ff ff 90 00 0d 59 fe 4d 00 00 e6 54
SEND: 12 34 56 79 02 00 fd ff 04 00 fd ff ff ff 4a 4c 11 73 12 00 3c 02 60 d7
RECV: 12 34 56 79 06 00 f9 ff 04 00 4a 4c 11 73 fd ff ff ff 90 00 43 45 48 2c 00 00 fd df
Your key is '\x95..............'
En liveupdate.py:
#!/usr/bin/env python
import struct, sys, MySQLdb, time
from collections import namedtuple
__version__ = "0.0.9"
# SETTINGS
inverter_private_key = '\x95............'
db_user = "solar"
Enig idee wat hier nog mis kan zijn met de sleutel?
solaredge-logger doet op dit moment niets met de Modbus meter data. Het wordt wel onderschept en in de pcap bestanden opgeslagen, maar niet verwerkt in de database. De reden is simpel: ik heb er zelf geen ervaring mee. Misschien kan iemand hier een bijdrage voor leveren. Als alternatief kun je kijken naar een soortgelijk project van jbuehl op GitHub.rtenklooster schreef op dinsdag 19 juni 2018 @ 22:25:
Ik ga ook een PV installatie met SolarEdge installeren. Nu twijfel ik of ik meteen ook een SolarEdge Modbus meter mee bestel om ook gedetailleerde info van mijn 3 fasen inzichtelijk te krijgen.
Wat me niet direct duidelijk wordt is of de bestaande logging scripts ook de modbus data onderscheppen. Heeft iemand hier toevallig informatie over?
Ik krijg wellicht een nieuwe meter omdat ik mijn aansluiting upgrade naar 3 fasen. Nu zijn die slimme meters prima met de P1 poort uit te lezen. Is het in dit geval überhaupt zinvol om een modbus te plaatsen, of volstaat het uitlezen van de slimme meter ook wel? Wat is jullie advies?
Intussen heb ik wel wat ervaring met het uitlezen van de P1 poort van een slimme meter, dat bevalt mij best goed. Ik krijg elke seconde (!!!!!) de actuele meetwaardes. Awesome.
Nou dit was ook mijn idee. Je hoeft geen aparte dure meters te bestellen en te plaatsen (groepenlast zal al aardig vol zitten) en de meters van de energieboer zijn als het goed is keurig geijkt.Jerrythafast schreef op dinsdag 19 juni 2018 @ 22:37:
[...]
Intussen heb ik wel wat ervaring met het uitlezen van de P1 poort van een slimme meter, dat bevalt mij best goed. Ik krijg elke seconde (!!!!!) de actuele meetwaardes. Awesome.
Ik laat het wel even voor wat het is. P1 is dus real-time en gratis.. dan is de keuze niet zo moeilijk. Dank!
P1 is leuk, maar het opgewekte deel wat direct verbruikt wordt kun je nergens aflezen. Wordt dan lastig in te zien hoe goed de panelen het doen ofwel hoe goed je bezig bent met verbruik verminderen.
He who controls the past, commands the future. He who commands the future, conquers the past.
Is natuurlijk vrij eenvoudig te berekenen door het te vergelijken met de output van de omvormer...[RNMC] Viper schreef op woensdag 20 juni 2018 @ 17:51:
P1 is leuk, maar het opgewekte deel wat direct verbruikt wordt kun je nergens aflezen. Wordt dan lastig in te zien hoe goed de panelen het doen ofwel hoe goed je bezig bent met verbruik verminderen.
Na dat ik veel gespeeld heb met de se-logger. Ben ik uiteindelijk van start gegaan met Modbus TCP dat ook op mijn SolarEdge omvormer zat. Ik heb een Loxone domotica systeem en ik kon de omvormer hier gewoon aan toevoegen als device en de waarden uitlezen (wel niet zo uitgebreid als via se-logger).rtenklooster schreef op dinsdag 19 juni 2018 @ 22:25:
Ik ga ook een PV installatie met SolarEdge installeren. Nu twijfel ik of ik meteen ook een SolarEdge Modbus meter mee bestel om ook gedetailleerde info van mijn 3 fasen inzichtelijk te krijgen.
Wat me niet direct duidelijk wordt is of de bestaande logging scripts ook de modbus data onderscheppen. Heeft iemand hier toevallig informatie over?
Ik krijg wellicht een nieuwe meter omdat ik mijn aansluiting upgrade naar 3 fasen. Nu zijn die slimme meters prima met de P1 poort uit te lezen. Is het in dit geval überhaupt zinvol om een modbus te plaatsen, of volstaat het uitlezen van de slimme meter ook wel? Wat is jullie advies?
Wat je over Modbus TCP binnen krijgt vind je hier: https://www.solaredge.com...tation-technical-note.pdf
@Kaisar Rechtstreeks via modbus kan inderdaad ook, echter ondersteunt de sunspec-interface alleen de omvormer-informatie. Je mist dan de informatie per paneel, die komt er va modbus simpelweg niet uit.
Mijn omvormer kan al twee dagen niet meer verbinden met internet. Dit komt voorbij in tcp dump:
Hebben meer mensen hier last van? Domein lijkt me niet helemaal te kloppen...
Update:
Dit is gewoon ip adres 185.121.71.35. Hier verbindt hij altijd mee. De logs blijven gewoon leeg.
code:
1
2
| 21:20:09.052322 IP 192.168.10.25.1955 > pix.incognitoiajdflwe.com.http: Flags [S], seq 333010, win 2152, options [mss 538], length 0 21:20:09.115628 IP pix.incognitoiajdflwe.com.http > 192.168.10.25.1955: Flags [R.], seq 0, ack 333011, win 0, length 0 |
Hebben meer mensen hier last van? Domein lijkt me niet helemaal te kloppen...

Update:
Dit is gewoon ip adres 185.121.71.35. Hier verbindt hij altijd mee. De logs blijven gewoon leeg.
[ Voor 10% gewijzigd door tjanssen op 21-06-2018 22:02 ]
Klopt, ook bij mij sinds gistermorgen ~11:30 geen connectie meer, blijft hangen op de laatste test: TCP connection Failed.
De server die in de omvormer vermeld staat is prodnt.solaredge.com
Nslookup geeft datzelfde IP: 185.121.71.35
Straks na 0:00 ga ik de omvormer even spanningsloos maken, wellicht dat dit helpt. Edit: heeft niet geholpen
Morgen SolarEdge maar eens bellen...
De server die in de omvormer vermeld staat is prodnt.solaredge.com
Nslookup geeft datzelfde IP: 185.121.71.35
Straks na 0:00 ga ik de omvormer even spanningsloos maken, wellicht dat dit helpt. Edit: heeft niet geholpen
Morgen SolarEdge maar eens bellen...
[ Voor 5% gewijzigd door Rouske op 22-06-2018 00:26 ]
Bij mij is ook de laatste online data van woensdag 11:30 uur. Zelfde melding over TCP connection failed.
Had half uurtje geleden nog bij de pvoutput van @Jerrythafast gekeken of hij er ook last van had, maar daar zag ik wel gewoon data. Dus was al stilletjes de conclusie aan het maken dat het aan mijn eigen netwerk lag.
Morgen maar weer kijken of hij het weer doet. Kan gelukkig wel via de slimme meter zien dat er wel opgewekt wordt
Had half uurtje geleden nog bij de pvoutput van @Jerrythafast gekeken of hij er ook last van had, maar daar zag ik wel gewoon data. Dus was al stilletjes de conclusie aan het maken dat het aan mijn eigen netwerk lag.
Morgen maar weer kijken of hij het weer doet. Kan gelukkig wel via de slimme meter zien dat er wel opgewekt wordt
[ Voor 1% gewijzigd door 3ssen op 22-06-2018 00:21 . Reden: 11:15 naar 11:30 ]
Dit had ik ook al gedaan, hielp ook niet. Alleen heb ik dit gedaan toen de omvormer nog in bedrijf was (rond 21:15). Dagtotaal van gisteren ben ik kwijt lijkt het....Rouske schreef op donderdag 21 juni 2018 @ 22:23:
Straks na 0:00 ga ik de omvormer even spanningsloos maken, wellicht dat dit helpt. Edit: heeft niet geholpen![]()
Morgen SolarEdge maar eens bellen...
Ik zie in mijn PV output data op de website dat de DC spanning (normaal ongeveer 749V) wel eens omhoog schiet (naar bv 881V), waarna het systeem stopt met leveren en daarna weer doorgaat.
Zie:
https://pvoutput.org/intraday.jsp?id=66359&sid=59003&dt=20180619&gs=0&m=1
Check tijdstip iets na 17:00.
Weet iemand hoe dit komt, is dit ernstig?
Zie:
https://pvoutput.org/intraday.jsp?id=66359&sid=59003&dt=20180619&gs=0&m=1
Check tijdstip iets na 17:00.
Weet iemand hoe dit komt, is dit ernstig?
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Datzelfde gedrag met de voltages zie ik ook, maar alleen bij start en stop van productie (bij mij eigenlijk alleen begin en einde dag, of als ik aan de schakelaars zit)
Ik vermoed dat de optimizers samen op 880V mikken, en dat de omvormer dat in productie naar 750 volt trekt, om het maar even cru te verwoorden.
Ik ben sowieso wel benieuwd naar de aansturing tussen de omvormer en de optimizers, ik geloof niet dat de omvormer van seconde tot seconde contact heeft met elke optimizer, dus het systeem moet zichzelf dynamisch bijsturen.
Ik vermoed dat de optimizers samen op 880V mikken, en dat de omvormer dat in productie naar 750 volt trekt, om het maar even cru te verwoorden.
Ik ben sowieso wel benieuwd naar de aansturing tussen de omvormer en de optimizers, ik geloof niet dat de omvormer van seconde tot seconde contact heeft met elke optimizer, dus het systeem moet zichzelf dynamisch bijsturen.
Na tig minuten aan de telefoon gehangen te hebben bij SolarEdge en nog niemand te pakken gekregen, heb ik mijn installateur maar gebeld en die nam wel meteen op.Rouske schreef op donderdag 21 juni 2018 @ 22:23:
Klopt, ook bij mij sinds gistermorgen ~11:30 geen connectie meer, blijft hangen op de laatste test: TCP connection Failed.
De server die in de omvormer vermeld staat is prodnt.solaredge.com
Nslookup geeft datzelfde IP: 185.121.71.35
Straks na 0:00 ga ik de omvormer even spanningsloos maken, wellicht dat dit helpt. Edit: heeft niet geholpen![]()
Morgen SolarEdge maar eens bellen...
Paar zaken doorlopen/getest. Welke internet provider ik had (Ziggo), bedraad aangesloten, internet werkt op die LAN kabel, enz...
De installateur gaat SolarEdge contacten, ook vermeld dat er meerdere systemen last hebben.
Ik ben benieuwd wanneer er een antwoord of reactie komt wat er aan de hand is.
Typisch dat niet iedereen er last van heeft. Is het alleen bij een bepaalt type omvormer? Bij mijn (oud modelletje) singel phase SE3000 heb ik nergens last van. Communicatie met SolaEdge gaat goed. Evenals de lokale logging.
EDIT: in het verleden verbrak de communicatie wel eens. Tijdelijk. Vaak was het na een paar uur weer hersteld. De omvormer bewaart de data intern totdat de communicatie met de SE-servers weer is hersteld. Dan wordt de achterstallige data alsnog verwerkt. En ook de lokale logging, gezien het principe hiervan.
Het laatste half jaar overigens geen enkele drop meer gehad.
EDIT: in het verleden verbrak de communicatie wel eens. Tijdelijk. Vaak was het na een paar uur weer hersteld. De omvormer bewaart de data intern totdat de communicatie met de SE-servers weer is hersteld. Dan wordt de achterstallige data alsnog verwerkt. En ook de lokale logging, gezien het principe hiervan.
Het laatste half jaar overigens geen enkele drop meer gehad.
[ Voor 45% gewijzigd door Aegle op 22-06-2018 15:27 ]
33 x ET Solar 270Wp = 8910Wp @ SMA Sunny TriPower STP 8000TL-20 Live: PVOutput
Ik heb het vermoeden dat dit bij mij gebeurd als de omvormer het maximale vermogen levert (9,5kW) en aftopt. Soms stijgt hierdoor de DC spanning, waarna de omvormer even de reset indrukt en opnieuw begint ofzo. Ik vind het jammer dat er zo mee en dan afgetopt wordt, maar het is niet anders.charlygolf schreef op vrijdag 22 juni 2018 @ 12:27:
Datzelfde gedrag met de voltages zie ik ook, maar alleen bij start en stop van productie (bij mij eigenlijk alleen begin en einde dag, of als ik aan de schakelaars zit)
Ik vermoed dat de optimizers samen op 880V mikken, en dat de omvormer dat in productie naar 750 volt trekt, om het maar even cru te verwoorden.
Ik ben sowieso wel benieuwd naar de aansturing tussen de omvormer en de optimizers, ik geloof niet dat de omvormer van seconde tot seconde contact heeft met elke optimizer, dus het systeem moet zichzelf dynamisch bijsturen.
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Bij mij is een inderdaad de HD Wave.Aegle schreef op vrijdag 22 juni 2018 @ 15:23:
Typisch dat niet iedereen er last van heeft. Is het alleen bij een bepaalt type omvormer? Bij mijn (oud modelletje) singel phase SE3000 heb ik nergens last van. Communicatie met SolaEdge gaat goed. Evenals de lokale logging.
@Rouske Bij jou ook?
Yep, HD Wave 3680.tjanssen schreef op vrijdag 22 juni 2018 @ 18:45:
[...]
Bij mij is een inderdaad de HD Wave.
@Rouske Bij jou ook?
Er is een apart topic voor gemaakt.
erik39 in "Solaredge monitoring geen updates meer"
erik39 in "Solaredge monitoring geen updates meer"
[ Voor 9% gewijzigd door Rouske op 22-06-2018 19:03 ]
@Rouske Bij mij werkt de logging weer, bij jou ook? Bedankt voor je belletje..
Hier net een Solar Edge HD Wave 2200 geinstalleerd.
Na aanzetten een update via netwerk sucesvol doorlopen maar uiteindelijk een foutmelding op het missen van de countrycode.
Error 3xB
Maar hoe zetten we die erin?
Menu settings lijken niet logisch.
Edit:
Na een half uur puzzelen kwamen we achter de juiste menu instellingen (die kwamen na invoer van wachtwoord 12312312 beschikbaar ) en met de countrycode erin werkt de setup naar behoren!
Na aanzetten een update via netwerk sucesvol doorlopen maar uiteindelijk een foutmelding op het missen van de countrycode.
Error 3xB
Maar hoe zetten we die erin?
Menu settings lijken niet logisch.
Edit:
Na een half uur puzzelen kwamen we achter de juiste menu instellingen (die kwamen na invoer van wachtwoord 12312312 beschikbaar ) en met de countrycode erin werkt de setup naar behoren!
[ Voor 30% gewijzigd door Leader98 op 24-06-2018 16:17 ]
@andrerij en andere die de website van Andrerij gebruiken
Vandaag blijft mijn grafiek in de rechterbovenhoek leeg (de historie van 20 dagen samen met de huidige dag). De grote grafiek met de dagopwekking werkt wel. Ook de opwerking per paneel (bij bewegen met muis over paneel) werkt gewoon.
Ook de historie is dus vandaag niet zichtbaar, terwijl die gewoon in de DB beschikbaar is. Als ik 1 dag terugga, dan is de grafiek met de 20 dagen historie wel zichtbaar.
Enig idee wat er mis is? Je kunt het bekijken op http://www.williamvanbeek.nl/zonnepanelen/
Vandaag blijft mijn grafiek in de rechterbovenhoek leeg (de historie van 20 dagen samen met de huidige dag). De grote grafiek met de dagopwekking werkt wel. Ook de opwerking per paneel (bij bewegen met muis over paneel) werkt gewoon.
Ook de historie is dus vandaag niet zichtbaar, terwijl die gewoon in de DB beschikbaar is. Als ik 1 dag terugga, dan is de grafiek met de 20 dagen historie wel zichtbaar.
Enig idee wat er mis is? Je kunt het bekijken op http://www.williamvanbeek.nl/zonnepanelen/
[ Voor 38% gewijzigd door SpeedingWilly op 25-06-2018 14:01 ]
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Er is iets niet goed in je database. De output van live-server-data-inverter.php moet series geven van 14 tot 0, Dit geeft hij ook bij voorgaande dagen maar bij vandaag loopt het van -15 tot -30.SpeedingWilly schreef op maandag 25 juni 2018 @ 08:57:
@andrerij en andere die de website van Andrerij gebruiken
Vandaag blijft mijn grafiek in de rechterbovenhoek leeg (de historie van 20 dagen samen met de huidige dag). De grote grafiek met de dagopwekking werkt wel. Ook de opwerking per paneel (bij bewegen met muis over paneel) werkt gewoon.
Ook de historie is dus vandaag niet zichtbaar, terwijl die gewoon in de DB beschikbaar is. Als ik 1 dag terugga, dan is de grafiek met de 20 dagen historie wel zichtbaar.
Enig idee wat er mis is? Je kunt het bekijken op http://www.williamvanbeek.nl/zonnepanelen/
Bij het paneel 1.1.6. is gisteren ook iets niet goed gegaan. Deze heeft een heel afwijkende waarde ten opzichte van de rest. Vandaag loopt hij wel gelijk.
Bij mij geeft de versie die jij gebruikt wel de goede waarden met mijn panelen.
Maar wat kan de oorzaak zijn?
Paneel 1.1.6 heeft gisteren niet goed meegedaan i.d.d. Daar ben ik nog mee bezig met de installateur.
Het viel mij vandaag op dat er in verschillende pcap files op de rPi geschreven wordt. Er moet toch in 1 file geschreven worden?
Zou het helpen om een lege Maria DB DB opnieuw te vullen met de informatie in de pcap files?
Edit:
Een lege DB vullen met de pcap fileswerkte niet goed, dus ik ben met een lege DB begonnen en dat lijkt weer te werken.
Paneel 1.1.6 heeft gisteren niet goed meegedaan i.d.d. Daar ben ik nog mee bezig met de installateur.
Het viel mij vandaag op dat er in verschillende pcap files op de rPi geschreven wordt. Er moet toch in 1 file geschreven worden?
Zou het helpen om een lege Maria DB DB opnieuw te vullen met de informatie in de pcap files?
Edit:
Een lege DB vullen met de pcap fileswerkte niet goed, dus ik ben met een lege DB begonnen en dat lijkt weer te werken.
[ Voor 97% gewijzigd door SpeedingWilly op 26-06-2018 07:19 ]
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Ik ben vandaag opnieuw begonnen met een lege DB en alles werkt weer goed. Wel ben ik uiteraard de historie kwijt.
Ik heb ook de oude en de nieuwe DB samengevoegd, en dit werkt, maar dan blijft de fout bestaan voor gisteren.
Vraag, waar moet ik kijken in de DB en welke waardes moet ik eventueel veranderen om het handmatig te herstellen?
Ik heb ook de oude en de nieuwe DB samengevoegd, en dit werkt, maar dan blijft de fout bestaan voor gisteren.
Vraag, waar moet ik kijken in de DB en welke waardes moet ik eventueel veranderen om het handmatig te herstellen?
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Ik ben enige tijd geleden tegen een vergelijkbaar probleem aangelopen, met hetzelfde probleem voor de output-range van live-server-data-inverter.php (-15 tot -30 ipv 14 tot 0).
De oorzaak lag in een aantal records met 0-waarde voor de solar opbrengst rond middernacht. Als ik die verwijderde was het probleem voor die dag opgelost.
Ik heb de SQL query aangepast in live-server-data-inverter.php om records met de_day=0 uit te sluiten. Daar heeft die grafiek volgens mij sowieso geen last van. (Let op, er staan 2 queries, 1 voor 1 phase omvormers, 1 voor 3-phase)
'WHERE de_day>0 AND timestamp BETWEEN ' . $date_i . ' AND ' . $tomorrow . ' ' .
De oorzaak lag in een aantal records met 0-waarde voor de solar opbrengst rond middernacht. Als ik die verwijderde was het probleem voor die dag opgelost.
Ik heb de SQL query aangepast in live-server-data-inverter.php om records met de_day=0 uit te sluiten. Daar heeft die grafiek volgens mij sowieso geen last van. (Let op, er staan 2 queries, 1 voor 1 phase omvormers, 1 voor 3-phase)
'WHERE de_day>0 AND timestamp BETWEEN ' . $date_i . ' AND ' . $tomorrow . ' ' .
Ga ik proberen!
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Bedankt voor de tip. Ik ben er nog nooit tegenaan gelopen.charlygolf schreef op dinsdag 26 juni 2018 @ 16:14:
Ik ben enige tijd geleden tegen een vergelijkbaar probleem aangelopen, met hetzelfde probleem voor de output-range van live-server-data-inverter.php (-15 tot -30 ipv 14 tot 0).
De oorzaak lag in een aantal records met 0-waarde voor de solar opbrengst rond middernacht. Als ik die verwijderde was het probleem voor die dag opgelost.
Ik heb de SQL query aangepast in live-server-data-inverter.php om records met de_day=0 uit te sluiten. Daar heeft die grafiek volgens mij sowieso geen last van. (Let op, er staan 2 queries, 1 voor 1 phase omvormers, 1 voor 3-phase)
'WHERE de_day>0 AND timestamp BETWEEN ' . $date_i . ' AND ' . $tomorrow . ' ' .
Ik heb het in de download files aangepast.
Top, ik heb dit ook aangepast en kan melden dat hiermee de data weer geplot wordt in de grafiek rechtsboven!charlygolf schreef op dinsdag 26 juni 2018 @ 16:14:
Ik ben enige tijd geleden tegen een vergelijkbaar probleem aangelopen, met hetzelfde probleem voor de output-range van live-server-data-inverter.php (-15 tot -30 ipv 14 tot 0).
De oorzaak lag in een aantal records met 0-waarde voor de solar opbrengst rond middernacht. Als ik die verwijderde was het probleem voor die dag opgelost.
Ik heb de SQL query aangepast in live-server-data-inverter.php om records met de_day=0 uit te sluiten. Daar heeft die grafiek volgens mij sowieso geen last van. (Let op, er staan 2 queries, 1 voor 1 phase omvormers, 1 voor 3-phase)
'WHERE de_day>0 AND timestamp BETWEEN ' . $date_i . ' AND ' . $tomorrow . ' ' .
@andrerij:
Ik wil de grote dagopbrengstgrafiek graag om 05:00 in de ochtend laten beginnen i.p.v. op 00:00. Ik zoom liever in op het daggedeelte dat er productie is, en van middernacht tot 5 uur in de ochtend heb ik geen productie. Weet jij hoe dit kan en wat ik dan moet veranderen? Thanks alvast voor het antwoord.
[ Voor 15% gewijzigd door SpeedingWilly op 27-06-2018 10:02 ]
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Als je in live-server-data-s.php en live-server-data-c.php de regel bij 1 fase en 3 fase inverterSpeedingWilly schreef op woensdag 27 juni 2018 @ 08:47:
[...]
Top, ik heb dit ook aangepast en kan melden dat hiermee de data weer geplot wordt in de grafiek rechtsboven!
@andrerij:
Ik wil de grote dagopbrengstgrafiek graag om 05:00 in de ochtend laten beginnen i.p.v. op 00:00. Ik zoom liever in op het daggedeelte dat er productie is, en van middernacht tot 5 uur in de ochtend heb ik geen productie. Weet jij hoe dit kan en wat ik dan moet veranderen? Thanks alvast voor het antwoord.
'WHERE timestamp BETWEEN ' . $date . ' AND ' . $tomorrow . ' ' .
aanpast in
'WHERE de_day > 0 AND timestamp BETWEEN ' . $date . ' AND ' . $tomorrow . ' ' .
dan zal de grafiek pas starten bij aanvang van de productie.
Zou je niet lever e_day in plaats van de_day checken daarvoor? Als de omvormer bij tijdelijke duisternis (bijvoorbeeld tijdens een zware zomerse bui) een paar minuten stand-by staat mis je anders een stukje van je grafiek.andrerij schreef op woensdag 27 juni 2018 @ 14:16:
[...]
'WHERE de_day > 0 AND timestamp BETWEEN ' . $date . ' AND ' . $tomorrow . ' ' .
En zeg niet dat dat niet voorkomt anders ga ik voorbeelden in mijn database lopen zoeken
[ Voor 6% gewijzigd door Jerrythafast op 27-06-2018 21:40 ]
Klopt. 31 mei was zo’n dag...:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| Date Time Energy Efficiency Power Average Normalised Temperature Voltage Energy Used Power Used ... ... 31/05/18 11:35 1.970kWh 0.758kWh/kW 254W - 0.098kW/kW 30.5C 231.0V - - 31/05/18 11:30 1.943kWh 0.747kWh/kW 359W - 0.138kW/kW 30.5C 231.2V - - 31/05/18 11:25 1.921kWh 0.739kWh/kW 184W - 0.071kW/kW 30.3C 234.7V - - 31/05/18 11:20 1.913kWh 0.736kWh/kW 25W - 0.010kW/kW 30.4C 232.4V - - 31/05/18 11:15 1.910kWh 0.735kWh/kW 51W - 0.020kW/kW 30.5C 231.5V - - 31/05/18 11:10 1.901kWh 0.731kWh/kW 118W - 0.045kW/kW 30.6C 232.7V - - 31/05/18 11:05 1.891kWh 0.727kWh/kW 106W - 0.041kW/kW 31.1C 232.0V - - 31/05/18 11:00 1.891kWh 0.727kWh/kW 0W - 0.000kW/kW 30.7C 231.2V - - 31/05/18 10:55 1.891kWh 0.727kWh/kW 0W - 0.000kW/kW 30.4C 229.5V - - 31/05/18 10:50 1.891kWh 0.727kWh/kW 0W - 0.000kW/kW 30.5C 228.9V - - 31/05/18 10:45 1.891kWh 0.727kWh/kW 0W - 0.000kW/kW 30.9C 229.7V - - 31/05/18 10:40 1.888kWh 0.726kWh/kW 94W - 0.036kW/kW 31.0C 230.2V - - 31/05/18 10:35 1.874kWh 0.721kWh/kW 222W - 0.085kW/kW 31.2C 229.3V - - 31/05/18 10:30 1.850kWh 0.712kWh/kW 331W - 0.127kW/kW 31.2C 230.5V - - 31/05/18 10:25 1.819kWh 0.700kWh/kW 368W - 0.142kW/kW 31.2C 231.1V - - 31/05/18 10:20 1.792kWh 0.689kWh/kW 260W - 0.100kW/kW 31.2C 229.3V - - |
33 x ET Solar 270Wp = 8910Wp @ SMA Sunny TriPower STP 8000TL-20 Live: PVOutput
Dit klopt. Het kan beter e_day zijn, maar voor de grafiek maakt het niets uit omdat zodra de_day weer groter dan 0 wordt de data weer op de juiste tijd wordt geschreven en de grafiek doorloopt.Jerrythafast schreef op woensdag 27 juni 2018 @ 21:40:
[...]
Zou je niet lever e_day in plaats van de_day checken daarvoor? Als de omvormer bij tijdelijke duisternis (bijvoorbeeld tijdens een zware zomerse bui) een paar minuten stand-by staat mis je anders een stukje van je grafiek.
En zeg niet dat dat niet voorkomt anders ga ik voorbeelden in mijn database lopen zoekenIk heb het meermaals gezien in de afgelopen jaren in ieder geval
Ik heb dit getest met een dag waarbij de waarde tussentijds 0 werd.
[ Voor 16% gewijzigd door andrerij op 27-06-2018 22:42 ]
Deze wijziging werkt niet. De hele grafiek blijft leeg als ik deze code gebruik. Ook met e_day i.p.v. de_day werkt het niet.andrerij schreef op woensdag 27 juni 2018 @ 14:16:
[...]
Als je in live-server-data-s.php en live-server-data-c.php de regel bij 1 fase en 3 fase inverter
'WHERE timestamp BETWEEN ' . $date . ' AND ' . $tomorrow . ' ' .
aanpast in
'WHERE de_day > 0 AND timestamp BETWEEN ' . $date . ' AND ' . $tomorrow . ' ' .
dan zal de grafiek pas starten bij aanvang van de productie.
De vorige wijziging (in live-server-data-inverter.php) werkt wel.
Wat ik nu heb gedaan is in live-server-data-s.php en live-server-data-c.php de regel:
code:
1
| $date = (new DateTime(sprintf("today %s",date("Y-m-d 00:00:00", strtotime($d1)))))->getTimestamp(); |
veranderd in:
code:
1
| $date = (new DateTime(sprintf("today %s",date("Y-m-d 05:00:00", strtotime($d1)))))->getTimestamp(); |
Ik weet niet of deze verandering correct is, maar het werkt wel bij mij.
In de 14 dagen historie grafiek en ik deze aanpassing ook geprobeerd, maar dat werkt niet (uiteraard heb ik de daglengte ook aangepast).
[ Voor 29% gewijzigd door SpeedingWilly op 28-06-2018 09:59 ]
Drone Insight - De plek waar jouw drone avontuur een vlucht krijgt!
Heeft iemand wellicht de logger draaien op een Raspberry Pi 3 model B+ met een ethernet bridge ?
Het lukt mij niet om dit aan de praat te krijgen. Zodra ik het script onder punt 4.1 in /etc/network/interfaces activeer wil mijn Pi niet meer opstarten, maar blijft hangen tijdens het bootproces...
Ik gebruik een tp-link UE300 USB ethernet adapter als tweede ethernet interface.
Het lukt mij niet om dit aan de praat te krijgen. Zodra ik het script onder punt 4.1 in /etc/network/interfaces activeer wil mijn Pi niet meer opstarten, maar blijft hangen tijdens het bootproces...
Ik gebruik een tp-link UE300 USB ethernet adapter als tweede ethernet interface.
[ Voor 12% gewijzigd door willemx op 29-06-2018 20:46 ]
Staat er iets bruikbaars in beeld op het moment dat hij blijft hangen? Iets van een hint wat er aan de hand kan zijn?willemx schreef op vrijdag 29 juni 2018 @ 20:45:
Heeft iemand wellicht de logger draaien op een Raspberry Pi 3 model B+ met een ethernet bridge ?
Het lukt mij niet om dit aan de praat te krijgen. Zodra ik het script onder punt 4.1 in /etc/network/interfaces activeer wil mijn Pi niet meer opstarten, maar blijft hangen tijdens het bootproces...
Ik gebruik een tp-link UE300 USB ethernet adapter als tweede ethernet interface.
Het scherm staat helemaal vol met een stack trace waar ik niets van snap, maar wat wel betrekking lijkt te hebben op het maken van een bridge.
Inmiddels heb ik met wat googelen en experimenteren toch een bridge aan de praat gekregen op een andere manier:
ip link add name br0 type bridge
ip link set br0 up
ip link set eth0 master br0
ip link set eth1 master br0
Na het uitvoeren van deze commando's op de command line ontstaat er een werkende bridge, maar ik weet niet hoe ik dit op de juiste manier automatisch moet laten gebeuren tijdens het booten. De hardware is in ieder geval in orde lijkt het...
Inmiddels heb ik met wat googelen en experimenteren toch een bridge aan de praat gekregen op een andere manier:
ip link add name br0 type bridge
ip link set br0 up
ip link set eth0 master br0
ip link set eth1 master br0
Na het uitvoeren van deze commando's op de command line ontstaat er een werkende bridge, maar ik weet niet hoe ik dit op de juiste manier automatisch moet laten gebeuren tijdens het booten. De hardware is in ieder geval in orde lijkt het...
Ik had mijn voorbeeld van hier, onder Configuring bridging in /etc/network/interfaces. Zoals je ziet ben ik voor het static IP voorbeeld gegaan, je zou kunnen kijken of het bij jou werkt als je hem gewoon via DHCP laat lopen. Immers: met de commando's die je net zelf geeft zal hij ook geen static IP verzinnen. (Als het met DHCP wel werkt gok ik dat er nu iets niet klopt aan je static IP settings.)willemx schreef op zondag 1 juli 2018 @ 21:06:
Het scherm staat helemaal vol met een stack trace waar ik niets van snap, maar wat wel betrekking lijkt te hebben op het maken van een bridge.
Inmiddels heb ik met wat googelen en experimenteren toch een bridge aan de praat gekregen op een andere manier:
ip link add name br0 type bridge
ip link set br0 up
ip link set eth0 master br0
ip link set eth1 master br0
Na het uitvoeren van deze commando's op de command line ontstaat er een werkende bridge, maar ik weet niet hoe ik dit op de juiste manier automatisch moet laten gebeuren tijdens het booten. De hardware is in ieder geval in orde lijkt het...
Ik gebruik ook een Pi3 B+ met USB ethernet en dat draait nu prima, geen wijzigingen/aanpassingen t.o.v de installatie handleiding gedaan. Heb je wel bridge-utils geïnstalleerd staan ?willemx schreef op vrijdag 29 juni 2018 @ 20:45:
Heeft iemand wellicht de logger draaien op een Raspberry Pi 3 model B+ met een ethernet bridge ?
Het lukt mij niet om dit aan de praat te krijgen. Zodra ik het script onder punt 4.1 in /etc/network/interfaces activeer wil mijn Pi niet meer opstarten, maar blijft hangen tijdens het bootproces...
Ik gebruik een tp-link UE300 USB ethernet adapter als tweede ethernet interface.
Daar had ik in eerste instantie overheen gelezen toen werkte het ook niet lekker na herstart.
Ipsa scientia potestas est
Ja, ik heb bridge-utils geinstalleerd en die werken prima, maar alleen als ik handmatig de volgende commando's geef om een bridge te maken, dus:
sudo brctl addbr br0
sudo brctl addif br0 eth0 eth1
Het lukt me alleen niet om een werkende configuratie in /etc/network/interfaces te maken.
Edit: het is toch gelukt. Bleek inderdaad een probleem met de static configuratie (dubbel gebruikt IP-adres).
Het script zoals beschreven in de installatiehandleiding doet het nu wel.
Bedankt iedereen voor de hulp!
sudo brctl addbr br0
sudo brctl addif br0 eth0 eth1
Het lukt me alleen niet om een werkende configuratie in /etc/network/interfaces te maken.
Edit: het is toch gelukt. Bleek inderdaad een probleem met de static configuratie (dubbel gebruikt IP-adres).
Het script zoals beschreven in de installatiehandleiding doet het nu wel.
Bedankt iedereen voor de hulp!
[ Voor 27% gewijzigd door willemx op 09-07-2018 17:28 . Reden: probleem verholpen ]
Ik heb een compleet vlan aware netwerk, ik kan meerdere SSID's aanmaken welke uitkomen in VLANs. Ook met UTP porten kan hetzelfde gerealiseerd worden.
Als ik vlan 10 aanmaak waar de omvormer inzit, dan maak ik op de pi eth0.10 aan (802.1q) en daar laat ik eventueel DHCP uitdelen. Dan kan de pi natten naar eth0.0 dan kan ik in principe al het verkeer van de solaredge zien.
http://johnkeen.tech/raspberry-pi-router-guide/
SolarEdge UTP port vlan 10 -> switches -> Pi eth0.10 -> NAT -> eth0 (in reguliere LAN netwerk + internet)
2e voordeel is dat ik geen wifi module nodig heb.
3e voordeel is dat de Pi gewoon in de meterkast kan blijven en de P1 poort blijft uitlezen.
Als ik vlan 10 aanmaak waar de omvormer inzit, dan maak ik op de pi eth0.10 aan (802.1q) en daar laat ik eventueel DHCP uitdelen. Dan kan de pi natten naar eth0.0 dan kan ik in principe al het verkeer van de solaredge zien.
http://johnkeen.tech/raspberry-pi-router-guide/
SolarEdge UTP port vlan 10 -> switches -> Pi eth0.10 -> NAT -> eth0 (in reguliere LAN netwerk + internet)
2e voordeel is dat ik geen wifi module nodig heb.
3e voordeel is dat de Pi gewoon in de meterkast kan blijven en de P1 poort blijft uitlezen.
[ Voor 11% gewijzigd door stormfly op 05-07-2018 22:26 ]
@Jerrythafast op een Synology nas heeft iemand bedacht dat het handig is dat MariaDB 10 op port 3307 draait ipv 3306. Ook als je de oude MariaDB verwijderd zakt het portnummer helaas niet.
Nu is mijn kennis te beperkt om hier een portnummer in te bouwen, zou jij mee willen denken en het misschien wel default opnemen in de zipfiles (standaard ingevuld met 3306)
Het werkt trouwens met mijn ubuntu router/nat ;-) weer een WiFi module uitgespaard bij de aanschaf na de zomervakantie.
In het liveupdate script lijkt het makkelijker:
Nu is mijn kennis te beperkt om hier een portnummer in te bouwen, zou jij mee willen denken en het misschien wel default opnemen in de zipfiles (standaard ingevuld met 3306)
Het werkt trouwens met mijn ubuntu router/nat ;-) weer een WiFi module uitgespaard bij de aanschaf na de zomervakantie.
root@raspberrypi:/opt/se-logger# cat pvo-upload.php <?php //Version 0.0.10 //SETTINGS define("DB_HOST", "localhost"); define("DB_NAME", "solaredge"); define("DB_USERNAME", "dbuser"); define("DB_PASSWORD", "dbpassword"); define("PVO_API_KEY", "a2726abcfd6254409e725b628cfaed293745dbca"); define("PVO_SYSTEM_ID", "12345"); $db = new PDO( "mysql:host=" . DB_HOST . ";dbname=" . DB_NAME . ";charset=utf8", DB_USERNAME, DB_PASSWORD, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC]);
In het liveupdate script lijkt het makkelijker:
root@raspberrypi:/opt/se-logger# cat liveupdate.py #!/usr/bin/env python import struct, sys, MySQLdb, time from collections import namedtuple __version__ = "0.0.10" # SETTINGS inverter_private_key = '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' db_user = "dbuser" db_pass = "dbpassword" db_name = "solaredge" db_host = "localhost" db_port = " 3307 "
[ Voor 4% gewijzigd door stormfly op 06-07-2018 07:40 ]
Als iptables beschikbaar is op die NAS, dan kun je met deze regel:stormfly schreef op vrijdag 6 juli 2018 @ 07:40:
@Jerrythafast op een Synology nas heeft iemand bedacht dat het handig is dat MariaDB 10 op port 3307 draait ipv 3306. Ook als je de oude MariaDB verwijderd zakt het portnummer helaas niet.
Nu is mijn kennis te beperkt om hier een portnummer in te bouwen, zou jij mee willen denken en het misschien wel default opnemen in de zipfiles (standaard ingevuld met 3306)
code:
1
| iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3306 -j REDIRECT --to-port 3307 |
ervoor zorgen dat jouw scripts gewoon port 3306 blijven gebruiken en die doorgestuurd worden naar de port waar de database op luistert. Wel even kijken of eth0 inderdaad de interface is op de NAS waar deze connecties op binnenkomen, anders vervangen met de juiste interface naam.
Tnx maar de nas is helaas niet ge-root, bewuste keuze. Alles wat ik daar hobby is na een NAS update weer verdwenen. Ik pas het liever aan in een bron script, daar kan ik ook nog wat van leren.tsjoender schreef op vrijdag 6 juli 2018 @ 09:30:
[...]
Als iptables beschikbaar is op die NAS, dan kun je met deze regel:
code:
1 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3306 -j REDIRECT --to-port 3307
ervoor zorgen dat jouw scripts gewoon port 3306 blijven gebruiken en die doorgestuurd worden naar de port waar de database op luistert. Wel even kijken of eth0 inderdaad de interface is op de NAS waar deze connecties op binnenkomen, anders vervangen met de juiste interface naam.
Neemt niet weg dat jouw oplossing prima is, echter voor mij minder toepasbaar.
@stormfly Het is niet zo moeilijk om in dat script het MySQL port number te kunnen specificeren. Onderstaande zou het moeten doen:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| <?php //Version 0.0.10 //SETTINGS define("DB_HOST", "localhost"); define("DB_PORT", "3307"); define("DB_NAME", "solaredge"); define("DB_USERNAME", "dbuser"); define("DB_PASSWORD", "dbpassword"); define("PVO_API_KEY", "a2726abcfd6254409e725b628cfaed293745dbca"); define("PVO_SYSTEM_ID", "12345"); $db = new PDO( "mysql:host=" . DB_HOST . ";port=" . DB_PORT . ";dbname=" . DB_NAME . ";charset=utf8", DB_USERNAME, DB_PASSWORD, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC]); |
@ik222
kijk dat is vrij simpel, ik zat vooral te tobben over de volgordelijkheid van de 2e regel. Thanks!
De oude error:
De nieuwe error, waarschijnljk omdat er nog geen SE hangt en de DB nog geen waarde bevat?
EDIT ik ga de database even opnieuw aanmaken:
https://gathering.tweakers.net/forum/view_message/53140997
kijk dat is vrij simpel, ik zat vooral te tobben over de volgordelijkheid van de 2e regel. Thanks!
De oude error:
Stack trace: #0 /opt/se-logger/pvo-upload.php(15): PDO->__construct('mysql:host=172....', 'solaredge', 'solaredge', Array) #1 {main} thrown in /opt/se-logger/pvo-upload.php on line 15 PHP Fatal error: Uncaught PDOException: SQLSTATE[HY000] [2002] Connection refused in /opt/se-logger/pvo-upload.php:15
De nieuwe error, waarschijnljk omdat er nog geen SE hangt en de DB nog geen waarde bevat?
@server:/opt/se-logger$ sudo php pvo-upload.php PHP Fatal error: Uncaught PDOException: SQLSTATE[21000]: Cardinality violation: 1242 Subquery returns more than 1 row in /opt/se-logger/pvo-upload.php:31 Stack trace: #0 /opt/se-logger/pvo-upload.php(31): PDO->query('SELECT timestam...') #1 {main} thrown in /opt/se-logger/pvo-upload.php on line 31
EDIT ik ga de database even opnieuw aanmaken:
https://gathering.tweakers.net/forum/view_message/53140997
[ Voor 5% gewijzigd door stormfly op 06-07-2018 10:40 ]
Opgelost door DB opnieuw te maken, door de TABS in de database.txt gaat het mis met aanmaken. En daardoor maak je waarschijnlijk zaken dubbel aan tijdens het opnieuw proberen...waardoor de 1242 error ontstaat.
@Jerrythafast wellicht aanpassen in de bron file? De TABS moeten spaties zijn.
@Jerrythafast wellicht aanpassen in de bron file? De TABS moeten spaties zijn.

[ Voor 11% gewijzigd door stormfly op 06-07-2018 10:59 ]
Hé, dat is suf. Moet ergens een instelling in Notepad++ verkloot hebben, ik gebruik normaal nooit tabsstormfly schreef op vrijdag 6 juli 2018 @ 10:57:
Opgelost door DB opnieuw te maken, door de TABS in de database.txt gaat het mis met aanmaken. En daardoor maak je waarschijnlijk zaken dubbel aan tijdens het opnieuw proberen...waardoor de 1242 error ontstaat.
@Jerrythafast wellicht aanpassen in de bron file? De TABS moeten spaties zijn.
[afbeelding]

Was het gelukt om het poortnummer verder overal in te stellen?
Ja ik denk het wel, maar ik heb nog niet kunnen testen want er is nog geen omvormer;-)Jerrythafast schreef op zaterdag 7 juli 2018 @ 22:15:
[...]
Was het gelukt om het poortnummer verder overal in te stellen?
Maar hij komt met deze melding terug, wel gek dat ik toevallig daar "db_port" heb toegevoegd.
Een dry-run geeft deze output:
root@jumpserver:~# python /opt/se-logger/liveupdate.py Traceback (most recent call last): File "/opt/se-logger/liveupdate.py", line 483, in <module> db = DBManager(db_user, db_pass, db_name, db_host, db_port) File "/opt/se-logger/liveupdate.py", line 366, in __init__ retries -= 1 TypeError: unsupported operand type(s) for -=: 'str' and 'int'
Dan zijn daar twee foutjes in geslopen! Dit is wat je had moeten doen:stormfly schreef op zaterdag 7 juli 2018 @ 22:31:
[...]
Ja ik denk het wel, maar ik heb nog niet kunnen testen want er is nog geen omvormer;-)
Maar hij komt met deze melding terug, wel gek dat ik toevallig daar "db_port" heb toegevoegd.
Een dry-run geeft deze output:
root@jumpserver:~# python /opt/se-logger/liveupdate.py Traceback (most recent call last): File "/opt/se-logger/liveupdate.py", line 483, in <module> db = DBManager(db_user, db_pass, db_name, db_host, db_port) File "/opt/se-logger/liveupdate.py", line 366, in __init__ retries -= 1 TypeError: unsupported operand type(s) for -=: 'str' and 'int'
Python:
1
2
3
4
5
6
7
8
9
10
11
12
13
| # Bovenaan bij SETTINGS voeg je deze toe (let op: geen aanhalingstekens!): db_port = 3307 # Zo rond regel 360 wordt het zo: class DBManager: def __init__(self, user, passwd, db, host, port, retries=5): self.retries = retries while retries: try: self.conn = MySQLdb.connect(user=user, passwd=passwd, db=db, host=host, port=port) # Bijna helemaal onderaan moet dit: db = DBManager(db_user, db_pass, db_name, db_host, db_port) |
Jerrythafast schreef op zaterdag 7 juli 2018 @ 22:43:
[...]
Dan zijn daar twee foutjes in geslopen! Dit is wat je had moeten doen:
Python:
1 2 3 4 5 6 7 8 9 10 11 12 13 # Bovenaan bij SETTINGS voeg je deze toe (let op: geen aanhalingstekens!): db_port = 3307 # Zo rond regel 360 wordt het zo: class DBManager: def __init__(self, user, passwd, db, host, port, retries=5): self.retries = retries while retries: try: self.conn = MySQLdb.connect(user=user, passwd=passwd, db=db, host=host, port=port) # Bijna helemaal onderaan moet dit: db = DBManager(db_user, db_pass, db_name, db_host, db_port)
root@jumpserver:~# python /opt/se-logger/liveupdate.py End of file. Shutting down.
Wauw jij bent best goed in dit soort dingen! Middelste stuk was idd fout, tnx.
Goedemiddag,
Heeft er iemand een duidelijke uitleg hoe port mirroring werkt op een TP-Link TL-SG108E
Ik vind de benaming een beetje verwarrend, je hebt port mirrored en mirroring port.
Ik neem aan dat port mirrored de port is die je wilt onderscheppen, en dan zou mirroring port de ontvangende port moeten zijn, toch?
Binnen nu en niet al te lange tijd komt er bij ons 1x SE4000H en 12x P370 optimizers met LG LG320N1K-A5.
Het wordt een oost-west installatie, iedere kant 6 stuks, ik twijfel nog steeds eigenlijk of de SE4000H niet te groot is? Ik zag wel dat hij twee strings kan ontvangen, is dat handig in dit geval?
Heeft er iemand een duidelijke uitleg hoe port mirroring werkt op een TP-Link TL-SG108E
Ik vind de benaming een beetje verwarrend, je hebt port mirrored en mirroring port.
Ik neem aan dat port mirrored de port is die je wilt onderscheppen, en dan zou mirroring port de ontvangende port moeten zijn, toch?
Binnen nu en niet al te lange tijd komt er bij ons 1x SE4000H en 12x P370 optimizers met LG LG320N1K-A5.
Het wordt een oost-west installatie, iedere kant 6 stuks, ik twijfel nog steeds eigenlijk of de SE4000H niet te groot is? Ik zag wel dat hij twee strings kan ontvangen, is dat handig in dit geval?
SolarEdge SE3500HD met 12x LG320N1K-A5 waarvan 6x ZO en 6x NW
Ja die is denk wel vrij fors want 4000 is aan de AC kant. Aan de DC zijde mag je 6200 aanbieden. Met Oost West haal je niet op een moment 3850 tegelijk.MaikelK. schreef op dinsdag 17 juli 2018 @ 17:02:
Goedemiddag,
Heeft er iemand een duidelijke uitleg hoe port mirroring werkt op een TP-Link TL-SG108E
Ik vind de benaming een beetje verwarrend, je hebt port mirrored en mirroring port.
Ik neem aan dat port mirrored de port is die je wilt onderscheppen, en dan zou mirroring port de ontvangende port moeten zijn, toch?
Binnen nu en niet al te lange tijd komt er bij ons 1x SE4000H en 12x P370 optimizers met LG LG320N1K-A5.
Het wordt een oost-west installatie, iedere kant 6 stuks, ik twijfel nog steeds eigenlijk of de SE4000H niet te groot is? Ik zag wel dat hij twee strings kan ontvangen, is dat handig in dit geval?
Mijn gevoel zegt dat je met een 3500HD al uit zou komen met 3850wp
Maar waarom de P370 en niet de P404? Want de P404 start al met 6 panelen en de P370 met 8 meen ik. Dat is exact de 6 panelen die op Oost als eerste licht opvangen.
Dat lijkt mij inderdaad de juiste aanname. Het lastige is dat er tussen de merken van netwerk producten verschillende benamingen voor hetzelfde gebruikt kunnen worden. Een andere manier om het uit te sluiten is of je meerdere poorten kunt laten mirroren. Er kan maar een poort de ontvangende poort zijn, maar meerdere poorten kunnen naar die poort gemirrord worden. Dus als je in het configuratiescherm van een type meerdere poorten kunt definieren dan weet je ook genoeg.MaikelK. schreef op dinsdag 17 juli 2018 @ 17:02:
Ik vind de benaming een beetje verwarrend, je hebt port mirrored en mirroring port.
Ik neem aan dat port mirrored de port is die je wilt onderscheppen, en dan zou mirroring port de ontvangende port moeten zijn, toch?
Kan je trouwens met de modbusmeter per fase de belasting zien? In de grafieken kan ik dit onderscheid volgens mij niet maken, wellicht in de data wel?
Het bridgen van eth0 en eth1 schijnt in de Raspbian Stretch versie anders te werken dan in de begin post staat, op internet wordt het niet veel duidelijker. Iemand van jullie enig idee?
@stormfly ik heb de installateur nog eens gevraagd het te bekijken. Ik denk sowieso dat het eigenlijk beter de SE3500 of de 3680H kan worden. Deze heeft sowieso maar 1 string als input, en met diffuus licht zullen de panelen op west evengoed spanning kunnen genereren als het goed is. In de SolarEdge designer software heb ik ook eens de twee strings ingegeven en dan komt er ook SE3500H uit met P370 optimizers. Ook al laat ik de keuze uit de opties P370/P404 en SE3500H en SE3680H
@stormfly ik heb de installateur nog eens gevraagd het te bekijken. Ik denk sowieso dat het eigenlijk beter de SE3500 of de 3680H kan worden. Deze heeft sowieso maar 1 string als input, en met diffuus licht zullen de panelen op west evengoed spanning kunnen genereren als het goed is. In de SolarEdge designer software heb ik ook eens de twee strings ingegeven en dan komt er ook SE3500H uit met P370 optimizers. Ook al laat ik de keuze uit de opties P370/P404 en SE3500H en SE3680H
SolarEdge SE3500HD met 12x LG320N1K-A5 waarvan 6x ZO en 6x NW
Let op:
Dit topic is bedoeld voor discussies rondom het zelf uitlezen van solaredge omvormers, dus buiten de standaard monitoring.
Voor algemene solaredge vragen is er Het grote SolarEdge topic
Dit topic is bedoeld voor discussies rondom het zelf uitlezen van solaredge omvormers, dus buiten de standaard monitoring.
Voor algemene solaredge vragen is er Het grote SolarEdge topic