New to SolarEdge

[BoHammil]

Hi,

This really isn't an issue with your software. I have had my system for 3 weeks now. I did see that solaredge sade they have a zigbee option. I have use zigbee in the past with other projects. Now, once installed, I found out that my company didn't install the zigbee unit and solar edge site is very limited about this unit. It seems that it reports back to there propitarty hub to route it out to the internet, just like if you had internet plugged directly into the inverter. I called solaredge today and just ask them the best way to read my data from my owned solaredge inverter. They stated that there was no way but via their portal. I mentioned to them that Sungevity(who installed my solaredge) isn't using their portal portal and they didnt say much. But then I said their where a couple of places on the internet who had done it. There was a quick response about there are hacking our solaredge. I felt like didn't I just spend 30k for my system, isnt it mine. But I felt like they really dont like owner of their products to have true intormation about what my system is doing without being in their cloud.

I have worked on a couple of items for people with home automation and thought this would be a good project for me to work on. But just realized today, even though I like the solaredge line for my power, they dont like people to know what your system is doing without using their data on there site.

I have worked with RasPis/Arduinos and Zigbees and thought this would be fun to monitor my own power. But I see these companies only like me to use their products.

I appreciate you guys in what you are doing. Keep it up. I want some day to try to get past the cloud and do my own reporting.

Just didnt know any other way to email you, so I opened up a ticket.

Thanks for the reading, I been doing alot since I found this forum/GitHub project.

Bo

[d-tamm]

I have now found a working method for setting up a recent Raspbian for bridging (actually, it's not bridging but natting, I think): http://raspberrypi.stackexchange.com/questions/48307/sharing-the-pis-wifi-connection-through-the-ethernet-port So now I will set the RPi between the inverter and the internet and log the traffic with tcpdump -U -w capture.pcap host 192.168.2.x.

[d-tamm]

Here comes the pcap file from last night, in the hope that it may contain something which may explain why my semonitor loses contact with my inverter during night. capture.pcap.zip I have no idea how to see in wireshark what's going on, so I hope that @jbuehl or someone else with such knowledge can have a look at the file. I find it interesting that I can extract the inverter data from the pcap file via seextract and semonitor without needing a key. As I understood from @jbuehl 's documentation, the inverter should have switched to encrypted mode as soon as it got into contact with the solagedge server.

[jbuehl]

I can see that the inverter is talking to the SolarEdge server on port 22221 at the beginning of the capture, and then about halfway through it starts talking to port 22222. I suspected something like this was happening. Changing semonitor.py to listen on multiple ports may be complicated so I can't change it quickly, but as a workaround you could try running 2 instances of semonitor.py on your server that listen on 22221 and 22222 and see if that works. I just added an option to allow you to do this easily.

python semonitor.py -t n -p 22221 data1.json
python semonitor.py -t n -p 22222 data2.json

Regarding the encryption, SolarEdge won't necessarily switch your inverter to encrypted mode immediately, but if you leave it connected for a day or so it will probably happen.

[d-tamm]

Thanks for all efforts @jbuehl! I assume that data1.json and data2.json are meant to be -o arguments since we already use -t n. I will try running on 2 ports later today and report on it :)

[jbuehl]

Yes, I forgot to include the -o.

[d-tamm]

I have now been running 2 instances of semonitor for some days and it seems to work finally. Communication seems to switch between port 22221 and 22222 each night after a DHCP release packet. The following pcap started one day later and contains only 2 days but may help analyse further: capture.pcap.zip @jbuehl I upload also 2 heavy output.log files corresponding to the same time frame as the pcap file, in case you have some use of that information and want to analyse it: debug1.zip (port 22221) debug2.zip (port 22222)

[jbuehl]

That's good to hear. I will try to make the change soon so that semonitor.py will listen on multiple ports.

[ericbuehl]

I believe this issue has been addressed and now supported in master! Please re-open if that is not the case