search

jbuehl / solaredge

SolarEdge inverter logging data capture
GNU General Public License v3.0
288 stars 60 forks source link

Solution working with latest model (without display) and latest firmware #142

Open pschelling opened 4 years ago

pschelling commented 4 years ago

Hi,

I succesfully used the TCP listing option for years with old version se5k. Now I have a new one without display and I’m reading a lot of things that it’s not working anymore? I tried to find the answer, but couldn’t find it in clear way.

Could anyone tell me if the TCP packet sniffing way is still working on the newest units (The unit is still boxed So I’m able to do everything now).

Thnx in advance Patrick

oliv3r commented 4 years ago

in a different thread, we are analyzing a few things that are going on right now. In the end however, they still seem to use the same messaging protocol, but I'm not sure if it is not wrapped in protobuf. I say this, because the backend needs to support both methods, and the device needs to support protobuf for setapp.

Having said that, someone else is already using the API from the device, so that could be used as well.

As I don't have the new device (which is kinda sad, as the hackability of the LCD-less one is incredibly high for us.

AndyRPH commented 4 years ago

Someone else is already using the api on the newest firmware??

pschelling commented 4 years ago

I’ve a new unit still not commissioned. I can help you on testdata if you want. Should I catch all traffic in pcap files or is the old style hack impossible?

Let me know.

oliv3r commented 4 years ago

https://github.com/jbuehl/solaredge/issues/124#issuecomment-471243962 is using the local API of the device it is claimed. Not sure which version however.

I think best to capture all traffic as you commission it. I would suspect that the initial handshake is still done using their tried method, as I doubt they are exchanging the keys in the factory (would be more secure, but is far more time consuming of course). So at least we can see if the same initial key exchange is extractable. Otherwise, other means will have to be found to get the key. RS-232 is available somewhere, it's in the dts files. Not sure if we can extract it using the local API ...

pschelling commented 4 years ago

I've connected the unit and have pcap files from the beginning. could not extract data from it. Tried to connect RS485, but this is not functioning, probably because of the in place connection to the monitoring platform of solaredge.

Could somebody help me out? I can share the pcap files until now, please give me a place where to drop.

help would be very welcome

oliv3r commented 4 years ago

wireshark has support for solaredge since a while thanks to one of our members.

That said, if the entire setup is done using encryption, that won't do. We can of course use this pcap file in the future for sure, but we first need to establish that there are no sensitive credentials in it, before sending it over the internet; as we Ideally would add it to the testing directory.

As for RS-485 not working, that's to be expected, afaik rs-485 only works if configured as such, instead of the tcp communication.

AndyRPH commented 4 years ago

I updated to 4.7.19 and the normal solaredge_local package pulls all the data from the api via my LAN connection to the inverter. So no tcp sniffing necessary for the data in the new display-less setapp models.

rgstephens commented 4 years ago

I tried some curl calls based on the information in the solaredge-local package and got no response on my new display-less SE10000H-US. Did a port scan and there are no ports open on the inverter. Any ideas on next steps?

kingfisher63 commented 4 years ago

You basically have two options:

A few considerations:

I am working on Modbus/TCP for local monitoring. Unfortunately SolarEdge does not provide any optimizer information via Modbus. I sent a message to SolarEdge some 6 weeks ago suggesting that they give the Modbus interface a makeover, but got no reply so far.

marcpuca commented 4 years ago

@kingfisher63 did you get any news on optimizer informaton via modbus/TCP from SE?

kingfisher63 commented 4 years ago

Unfortunately I did not get any response from SolarEdge.

kingfisher63 commented 3 years ago

SolarEdge may actually be working on making optimizer data available via Modbus. The _/root/coreapp program of firmware 4.6.x and later contains the following strings:

Optimizer data is still not available via Modbus in 4.10.25 (which SetApp installed on my SE4000H a few days ago), but 4.11.x is already in the making. There is still hope!

marcpuca commented 3 years ago

Fingers crossed!

On Fri, 18 Sep 2020, 07:18 kingfisher63, notifications@github.com wrote:

SolarEdge may actually be working on making optimizer data available via Modbus. The /root/core_app program of firmware 4.6.x and later contains the following strings:

  • SUNSPEC_PANEL_GetPanelData
  • SUNSPEC_PANEL_ClearPanelRecord
  • SUNSPEC_PANEL_GetCommonBlock
  • SUNSPEC_PANEL_UpdatePanelRecord

Optimizer data is still not available via Modbus in 4.10.25 (which SetApp installed on my SE4000H a few days ago), but 4.11.x is already in the making. There is still hope!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jbuehl/solaredge/issues/142#issuecomment-694656641, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2NENRFFYUNOOCHTBFM4UDSGLUQZANCNFSM4IY2RUYQ .

kingfisher63 commented 3 years ago

I installed 4.11.25 on my SE4000H today. Still no joy :(

rdorsch commented 3 years ago

Thanks, I asked my solarteur to contact solaredge to check if they plan to make module date available on the SUNSPEC API over Modbus TCP.

At least I thought it does not hurt if they know that customers care about this.

qistoph commented 3 years ago

SolarEdge may actually be working on making optimizer data available via Modbus. The _/root/coreapp program of firmware 4.6.x and later contains the following strings: ... Optimizer data is still not available via Modbus in 4.10.25 (which SetApp installed on my SE4000H a few days ago), but 4.11.x is already in the making. There is still hope!

Just found this Technical Note – SunSpec Logging in SolarEdge Inverters. It has two recent updates:

And on page 18 (Multiple MPPT Inverter Extension Model):

The Multiple MPPT (Maximum Power Point Tracker) Inverter Extension Model(160) is supported for SolarEdge Synergy Inverters with firmware version 4.13.xx or later.

So, lets hope 4.13.xx will be available to us soon :crossed_fingers:

qistoph commented 3 years ago

4.12 was released the other day. I'm still keeping an eye out for 4.13 and will report on its relevant changes.

For future reference and completeness of information, I've checked 4.12.28. As expected, no MPPT information;

 SunSpecMpptHeader(ID=65535, Length=0)
kingfisher63 commented 3 years ago

Reading the latest SolardEdge SunSpec logging technical note (v2.3) it becomes apparent that the MPPT Inverter Extension Model (SunSpec model 160) in 4.13+ is only intended for Synergy inverters. So even when 4.13 can be installed on other models some day, it is unlikely that optimizer level data will be available. IMHO SunSpec model 502 (Solar Module) would be the more appropriate model for optimizer data anyway.

 SunSpecMpptHeader(ID=65535, Length=0)

Model 65535 is the SunSpec End Model. It denotes the end of the model list. The purpose of the End Model is to enable model enumeration (which is the only correct way to determine which models are present).

SolarEdge is wrong to use absolute register addresses in the technical note. This causes problems when the presence of some models is configuration dependent like the meter models. In the technical note both the MPPT Inverter Extension Model and the Meter 1 model start at register address 40121/40122. Maybe meters cannot be configured with Synergy inverters in which case this is not an immediate problem. But it is still wrong to use absolute register addresses.

qistoph commented 3 years ago

Just updated to 4.13 and you are indeed absolutely correct @kingfisher63