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

[pschelling]

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]

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]

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

[pschelling]

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]

#124 (comment) 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]

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]

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]

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]

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]

You basically have two options:

• Downgrade to 4.4.67 and make sure to never upgrade again (and prevent others from doing so with or without your permission). 4.4.67 is the last firmware where the protobuf based REST-api is guaranteed to be accessible on port 80 from your local network (see also issue Local API with Protocol Buffers #124).
• Give up on solaredge-local.

A few considerations:

• SolarEdge may not provide support for 4.4.67 ('please upgrade first').
• 4.4.67 may not meet legal requirements in the future.
• The REST-api in 4.4.67 (and any earlier 4.x release) is totally unsecured allowing any system on your network to change settings.

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]

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

[kingfisher63]

Unfortunately I did not get any response from SolarEdge.

[kingfisher63]

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!

[marcpuca]

Fingers crossed!

…

On Fri, 18 Sep 2020, 07:18 kingfisher63, ***@***.***> 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 <#142 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2NENRFFYUNOOCHTBFM4UDSGLUQZANCNFSM4IY2RUYQ> .

[kingfisher63]

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

[rdorsch]

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]

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:
...
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:

• Version 2.2 (December 2020): Updated Modbus Register Mapping
• Version 2.1 (September 2020): New multiple MPPT inverter extension model for Synergy inverters

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 🤞

[qistoph]

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]

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]

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