Waiting for DNS message: timed out

[Llibyddap]

First and foremost - this is a great project and I'm glad I stumbled across it. After several long days - I've got everything up and running for the most part. My basic setup is:

Inverter --> eth0 --> Raspi 4 --> wlan0 --> router (and a switch or two) --> MAC

Not sure that anything past the Raspi 4 matters - but just in case. The inverter is an SE7600A-US.

I'm now at the point that I think I'm communicating with the Inverter - but getting stuck on a handshake problem. From the command line:

pi@ArmstrongSE:~/solaredge $ sudo python semonitor.py -o 2019test.json -n eth0 -vvv -r fulldump.txt

It seems to resolve the connection and pass back and forth a couple of messages. Then it sits with the following output for a minute or so until it times out:

172.24.1.2:2821 --> message: 1 length: 37
id: f0bb
flags: 0100
question
    name: prod2.solaredge.com
    type: 0001
    class: 0001
172.24.1.2:2821 <-- message: 2 length: 72
id: f0bb
flags: 8000
question
    name: prod2.solaredge.com
    type: 0001
    class: 0001
answer
    name: prod2.solaredge.com
    type: 0001
    class: 0001
    TTL: 86400
    resource: 172.24.1.1
waiting for DNS message
connection from 172.24.1.2:2820 to port 22222
Exception while reading data: timed out
closing <socket>
_closing (files...)_

It's late where I'm at so stopped working through the code - but it looks like the inverter starts the process and then the semonitor.py replies back with an answer. But during the process it times out.

Any initial thoughts?

• With a little more observation - I've noted that the packages being sent early on are relatively quick as the inverter resolves its address. Once the inverter resolves the address the message counter starts over and hangs at the outbound message 2 as indicated above (after the address is resolved - makes me think that there isn't actually any communication happening yet).

[jbuehl]

The inverter is connecting to the Raspberry Pi and semonitor.py is waiting to receive data from it, but the timeout means that the inverter is dropping the connection. Maybe you can see if there is something being shown on the inverter display that could help. Probably it's something related to how the inverter is configured.

Just a note about the configuration with the inverter connected to a dedicated interface. I used this setup for a long time, but I had a lot of problems that were caused by running the DHCP and DNS servers in semonitor.py. The system time would periodically need to be refreshed and because it couldn't resolve the address of the time server, the system date would get stuck at some point. I was running Arch linux so if you are running Raspbian that may or may not be a problem for you. To solve this, I made entries in my local DNS that pointed prod.solaredge.com, prod2.solaredge.com, and prod3.solaredge.com to the local address of my RPi and then connected the inverter to my network and stopped using the -n option. This isn't causing the problem that you are seeing, though.

[Llibyddap]

Yep - something isn't responding back on the inverter - I can actually watch it on wireshark. I'll continue to iterate and report back if/when I find something that is helpful.

[Llibyddap]

Update... @jbuehl, you were right on point. After trouble shooting a ton of stuff on the inverter, I went all the way back to my original inverter setup (which was with a zigbee). What I found was that the zigbee switch/hardware was the problem. After I got everything working again with the zigbee, I turned that functionality off AND removed the internal hardware for it (previously I had left the hardware in place). That left the inverter with only an ethernet option. When I hooked it up again, it began communicating right away (address resolution, data handshake and reporting).

A couple of observations for others that find themselves here. When I had the ethernet connection it was working with SolarEdge reporting even though the zigbee hardware was still installed. For some reason, the hardware caused the communication issue with the raspberry pi ethernet connection. Removing the hardware allowed the raspberry pi to begin capturing the data.