Solaredge REST API - Githubissues

gaetancollaud commented 9 months ago

Is your feature request related to a problem? Please describe.

Solaredge meter are supported but as described in the doc: Only one system may access the inverter!

Solaredge provide a remote monotiring with an API. It would be nice to have this option for solaredge meter.

Describe the solution you'd like

A meter implementation that supports solaredge REST API

Describe alternatives you've considered

I guess I could add a power meter (something like a shelly 3em) next to my inverter.

Additional context

Documentation: https://knowledge-center.solaredge.com/sites/kc/files/se_monitoring_api.pdf
Authentification is done with a token found in the admin page of https://monitoring.solaredge.com/ . The token has to be provided in each request, ex: GET ...?api_key=ABC
SiteId (also found in admin page) should be provided too
I'm willing to implement this myself, but I won't start without an approval from the maintainers

andig commented 9 months ago

No point in using an unreliable remote API when you have local access. Multiple clients can be enabled using the modbus proxy, see docs.

gaetancollaud commented 9 months ago

while I understand your point of cutting the middle man and go directly to the modbus API, it seems that my solaredge inverter has no modbus enabled. For this you need an additional module. I checked and indeed none of the modbus port provided in the dor are open.

But it's ok, I have home assistant with the solar edge REST API, I guess I can get home assistant to publish the value in MQTT. This will add another middle man, but if it can save me some money :smile:

andig commented 9 months ago

Oh, thats an argument. Can we figure if thats a single-user issue?

/cc @premultiply

gaetancollaud commented 9 months ago

My integration with home assistant is not perfect... It doesn't refresh really often. I will try to use your http plugin when I have time. Maybe I can do something better.

Again, my offer to create a proper implementation still stand, but I don't want to waste my time if you're not gonna merge it in the end.

gaetancollaud commented 9 months ago

Forget it... 300 requests per day is about one request every 5min. The implementation is not worth it. And now I understand more why I don't get more updates from home assistant.

I guess I will have to buy the modbus module :disappointed:

Bodobolero commented 5 months ago

@gaetancollaud I do not agree with your conclusions. 300 requests per day would allow one every 5 min. If you limit it to the time the sun is normally shining you can have one every 2 minutes. I would not want to change my charging state more often than every 2-5 minutes, because there are vehicles which are not working well with many changes in the charging state anyhow.

I think setting up a meter that is remotely accessible (like Volkstzähler etc.) is a big hurdle for many non-electricians. Also updating the Solardege firmware to support modbus protocol (older firmwares don't have it) is a hurdle that many users will not be able to cope with. @andig So for these use cases the SolarEdge REST API is a very convenient solution because this API already collects all the necessary information for using the PV for charging the car:

the current consumption of the house
the current production of the PV

Supporting a plugin in evcc for the solaredge REST API thus would be very valuable. I already use that REST API from python to create a long-term history for my PV.

@andig I know a little go and would be willing to contribute if you can provide me some hints on where to start with the integration of using the REST API for solar edge converters.

We could have a yaml like

meters:
  - type: solaredge
    usage: pv
    api: "<your_api_key>"
    site_id: "<your_site_id>"

andig commented 5 months ago

It still remains unclear why we would need another solution. We already have one. That said, you can build any custom integration using the evcc plugins.

Bodobolero commented 5 months ago

see for example these two users who struggled with the same issue https://github.com/evcc-io/evcc/discussions/2941

Getting modbus working on solaredge converters is a real challenge, and some older models don't support it at all. Also if you don't have a smart meter getting the consumption can be a challenge, while the SolarEdge REST API has that information.

Bodobolero commented 5 months ago

Example of modbus problem:

I think I am technically experienced but I don't understand the following problem:

Wähle die ModBus Schnittstelle aus TCP/IP
 Modbus ID 1
 IP-Adresse oder Hostname 192.168.178.28
 Port 502
 Zeitüberschreitung 30s

Teste die grid Konfiguration von SolarEdge Wechselrichter ...
   Fehler: cannot create meter type 'custom': power: sunspec: subdevice 1 not found

This is the output from the solar edge python library https://pypi.org/project/solaredge-modbus/ for my converter:

Updated with most current version of solaredge-modbus from https://github.com/nmakel/solaredge_modbus:

(base)PetersMac13-3 solaredge_modbus_new % python3 example.py 192.168.178.28 502
Inverter(192.168.178.28:502, connectionType.TCP: timeout=1, retries=3, unit=0x1):

Registers:
    Manufacturer: SolarEdge
    Model: SE5K
    Type: Three Phase Inverter
    Version: 0003.2537
    Serial: 7E183BF6
    Status: Producing
    Temperature: 33.54°C
    Current: 10.34A
    Phase 1 Current: 3.44A
    Phase 2 Current: 3.45A
    Phase 3 Current: 3.44A
    Phase 1 voltage: 413.40V
    Phase 2 voltage: 411.20V
    Phase 3 voltage: 412.80V
    Phase 1-N voltage: 239.50V
    Phase 2-N voltage: 237.90V
    Phase 3-N voltage: 238.30V
    Frequency: 49.97Hz
    Power: 2435.00W
    Power (Apparent): 2464.70VA
    Power (Reactive): -382.00VAr
    Power Factor: -98.77%
    Total Energy: 51376724Wh
    DC Current: 3.29A
    DC Voltage: 750.50V
    DC Power: 2472.00W

PetersMac13-3 solaredge_modbus_new % python3 example.py --json 192.168.178.28 502
{
    "c_id": "SunS",
    "c_did": 1,
    "c_length": 65,
    "c_manufacturer": "SolarEdge",
    "c_model": "SE5K",
    "c_version": "0003.2537",
    "c_serialnumber": "7E183BF6",
    "c_deviceaddress": 1,
    "c_sunspec_did": 103,
    "c_sunspec_length": 50,
    "current": 1244,
    "l1_current": 414,
    "l2_current": 414,
    "l3_current": 415,
    "current_scale": -2,
    "l1_voltage": 4143,
    "l2_voltage": 4113,
    "l3_voltage": 4135,
    "l1n_voltage": 2394,
    "l2n_voltage": 2373,
    "l3n_voltage": 2384,
    "voltage_scale": -1,
    "power_ac": 29070,
    "power_ac_scale": -1,
    "frequency": 4999,
    "frequency_scale": -2,
    "power_apparent": 29629,
    "power_apparent_scale": -1,
    "power_reactive": -5730,
    "power_reactive_scale": -1,
    "power_factor": -9810,
    "power_factor_scale": -2,
    "energy_total": 51376860,
    "energy_total_scale": 0,
    "current_dc": 3932,
    "current_dc_scale": -3,
    "voltage_dc": 7504,
    "voltage_dc_scale": -1,
    "power_dc": 29512,
    "power_dc_scale": -1,
    "temperature": 3391,
    "temperature_scale": -2,
    "status": 4,
    "vendor_status": 0,
    "rrcr_state": 0,
    "active_power_limit": 100,
    "cosphi": 0,
    "commit_power_control_settings": 0,
    "restore_power_control_default_settings": 0,
    "reactive_power_config": 2,
    "reactive_power_response_time": 2000,
    "advanced_power_control_enable": 1,
    "export_control_mode": 0,
    "export_control_limit_mode": 0,
    "export_control_site_limit": 0,
    "meters": {},
    "batteries": {
        "Battery1": {
            "c_manufacturer": "\u0002",
            "c_model": "False",
            "c_version": "False",
            "c_serialnumber": "False",
            "c_deviceaddress": 15,
            "c_sunspec_did": 0,
            "rated_energy": -3.4028234663852886e+38,
            "maximum_charge_continuous_power": -3.4028234663852886e+38,
            "maximum_discharge_continuous_power": -3.4028234663852886e+38,
            "maximum_charge_peak_power": -3.4028234663852886e+38,
            "maximum_discharge_peak_power": -3.4028234663852886e+38,
            "average_temperature": -3.4028234663852886e+38,
            "maximum_temperature": 0.0,
            "instantaneous_voltage": -3.4028234663852886e+38,
            "instantaneous_current": -3.4028234663852886e+38,
            "instantaneous_power": 0.0,
            "lifetime_export_energy_counter": 0,
            "lifetime_import_energy_counter": 0,
            "maximum_energy": -3.4028234663852886e+38,
            "available_energy": -3.4028234663852886e+38,
            "soh": -3.4028234663852886e+38,
            "soe": -3.4028234663852886e+38,
            "status": 7,
            "status_internal": 0,
            "event_log": 0,
            "event_log_internal": 0
        },
        "Battery2": {
            "c_manufacturer": "\u0002",
            "c_model": "False",
            "c_version": "False",
            "c_serialnumber": "False",
            "c_deviceaddress": 14,
            "c_sunspec_did": 0,
            "rated_energy": -3.4028234663852886e+38,
            "maximum_charge_continuous_power": -3.4028234663852886e+38,
            "maximum_discharge_continuous_power": -3.4028234663852886e+38,
            "maximum_charge_peak_power": -3.4028234663852886e+38,
            "maximum_discharge_peak_power": -3.4028234663852886e+38,
            "average_temperature": -3.4028234663852886e+38,
            "maximum_temperature": 0.0,
            "instantaneous_voltage": -3.4028234663852886e+38,
            "instantaneous_current": -3.4028234663852886e+38,
            "instantaneous_power": 0.0,
            "lifetime_export_energy_counter": 0,
            "lifetime_import_energy_counter": 0,
            "maximum_energy": -3.4028234663852886e+38,
            "available_energy": -3.4028234663852886e+38,
            "soh": -3.4028234663852886e+38,
            "soe": -3.4028234663852886e+38,
            "status": 7,
            "status_internal": 0,
            "event_log": 0,
            "event_log_internal": 0
        },
        "Battery3": {}
    }
}

andig commented 5 months ago

and some older models don't support it at all.

that could be a reason. Modbus Sunspec debug it OT here and typically requires output of

evcc sunspec

Also if you don't have a smart meter getting the consumption can be a challenge, while the SolarEdge REST API has that information.

how? Obviously from the meter!

Bodobolero commented 5 months ago

how? Obviously from the meter!

My meter is connected to the converter over a (twisted pair?) cable S0. The SEK5 thus has the consumption values. It also transmits it to the SolarEdge cloud. However so far I did not yet find a way how it re-exports those values over Modbus. So I can not access the consumption locally. My meter is an Eltako DSZ12E Verbrauchszähler S0 mit 800 Imp/Kwh https://www.eltako.com/fileadmin/downloads/de/_bedienung/DSZ12E-3x80A_28380611-3_dt.pdf Eltako DSZ12E 3x80A

I have no local API/access to it, however the Solaredge REST API has the information it collects

Bodobolero commented 5 months ago

(base)PetersMac13-3 evcc % evcc sunspec 192.168.178.28:502 
[main  ] INFO 2024/05/19 11:10:15 evcc 0.126.3
--------- Model 1 common ---------
Mn         SolarEdge     string
Md               SE5K    string
Opt                      string
Vr           0003.253    string
SN           7E183BF6    string
DA               1.00    uint16
Pad            0x0067    pad
--------- Model 103 inverter ---------
A                    7.71    uint16
AphA                 2.57    uint16
AphB                 2.57    uint16
AphC                 2.57    uint16
A_SF                   -2    sunssf
PPVphAB            412.80    uint16
PPVphBC            411.30    uint16
PPVphCA            413.80    uint16
PhVphA             238.60    uint16
PhVphB             237.20    uint16
PhVphC             239.00    uint16
V_SF                   -1    sunssf
W                 1782.00    int16
W_SF                   -1    sunssf
Hz                  50.00    uint16
Hz_SF                  -2    sunssf
VA                1836.70    int16
VA_SF                  -1    sunssf
VAr               -445.00    int16
VAr_SF                 -1    sunssf
PF                 -97.00    int16
PF_SF                  -2    sunssf
WH            51377436.00    acc32
WH_SF                   0    sunssf
DCA                  2.41    uint16
DCA_SF                 -4    sunssf
DCV                750.10    uint16
DCV_SF                 -1    sunssf
DCW               1809.10    int16
DCW_SF                 -1    sunssf
TmpCab                n/a    int16
TmpSnk              34.11    int16
TmpTrns               n/a    int16
TmpOt                 n/a    int16
Tmp_SF                 -2    sunssf
St                      4    enum16
StVnd                   0    enum16
Evt1                  n/a    bitfield32
Evt2                  n/a    bitfield32
EvtVnd1        0x00000000    bitfield32
EvtVnd2               n/a    bitfield32
EvtVnd3               n/a    bitfield32
EvtVnd4        0x00000000    bitfield32

Bodobolero commented 5 months ago

To prove my point I have just compiled the go tool from Ulrich Schreiner https://gitlab.com/ulrichSchreiner/solaredge referenced under https://github.com/evcc-io/evcc/discussions/2941

and got the following output from the REST API

PetersMac13-3 solaredgeUlrichSchreiner % bin/solaredge site powerflow
{
  "unit": "kW",
  "connections": [
    {
      "from": "GRID",
      "to": "Load"
    },
    {
      "from": "PV",
      "to": "Load"
    }
  ],
  "GRID": {
    "status": "Active",
    "currentPower": 2.15
  },
  "LOAD": {
    "status": "Active",
    "currentPower": 3.75
  },
  "PV": {
    "status": "Active",
    "currentPower": 1.6
  }
}

My current house consumption is 3.75 kw, I get 1.6 kw from the PV and 2.15 kw from the grid - which is exactly what we need for evcc - without any setup hassle.

I think we can have an ideological discussion whether we do not want to rely on the cloud with evcc. However there is already a dependency on cloud in other components, e.g. the support of VW we.connect APIs.

I think usability and simplifying setup for unexperienced users is more important than being autark for a larger user base.

andig commented 5 months ago

Open new discussion for Sunspec. Its offtopic here.

andig commented 5 months ago

My meter is connected to the converter over a (twisted pair?) cable S0. However so far I did not yet find a way how it re-exports those values over Modbus.

And finally, there's a use case. For whatever reasons it seems super hard to come up with those. "I want" is not a use case...

I think we can have an ideological discussion

We don't, but we need a good reason for not doing things twice.

Bodobolero commented 5 months ago

Open new discussion for Sunspec. Its offtopic here.

I just used it as one example how users that have modbus support may still struggle to access their meter values.

premultiply commented 5 months ago

This is the output from the solar edge python library https://pypi.org/project/solaredge-modbus/ for my converter: "meters": {},

The Tool did not find a meter. Same as evcc.

My meter is an Eltako DSZ12E Verbrauchszähler S0 mit 800 Imp/Kwh https://www.eltako.com/fileadmin/downloads/de/_bedienung/DSZ12E-3x80A_28380611-3_dt.pdf

... is no valid metering device for this use case. A very limited and outdated S0 interface does not support the needed measurement values and accuracy required to control a battery inverter. Especially not with only 800 Imp/kWh. This device is more or less useless for this purpose.

andig commented 5 months ago

Let's close the discussion then. The desired integration is already possible using plugins. We won't provide support out of the box.

I think we can have an ideological discussion whether we do not want to rely on the cloud with evcc.

Indeed. User can still chose to use the plugins if he so wishes.

Bodobolero commented 5 months ago

A very limited and outdated S0 interface does not support the needed measurement values and accuracy required to control a battery inverter. Especially not with only 800 Imp/kWh. This device is more or less useless for this purpose.

I have no battery installed in my house and thus no battery inverter.

The only thing I want to do is decide when to charge my EV using my PV energy.

I do not want to stop/start charging every few milliseconds.

My use case is:

I have a 5.04 kWp (kilo-watt peak) PV. Because I want to use PV energy to charge my car I do not use a wallbox, instead I have a Green-up socket which supports my 1 phase 10-16 A 240 V charging device that comes with my car. Since this is our second car we will use it for short distances, usually 2-20 km and the 2.3 kw charging using the green-up socket will be enough to support our usage of the car.

I want an automated solution that decides when to start charging and when to stop charging. The decision will be based on the SOC of the car (I will charge at any time until I reach a SOC of x % (e.g. 30 % to support my local commute). I want to charge between 30 % and 80 % when there is enough PV production to support the 2.4 kw charging (with 10 A * 240 V), which means when my production is higher than \<current consumption> + 2.4 kw.

For that purpose the S0 800 Imp/kWh meter is totally sufficient.

My car has a mileage of 10.000 km per year, at 20 kwh/100 km that is 2000 kwh / year. My reimbursement for PV is 13 Eurocent. My energy tarif is 27 cent/kwh.

The total possible savings per year by optimizating the charge time is 27 cent - 13 cent = 14 cent * 2000 kwh. That means I can save a total of 280 Euro/year.

Now comes the investment argument: I can buy a cheap e-go wallbox that can be remotely controlled (around 300 Euro) and I can also replace the smart meter. To modify the house installation I need a certified electrician that will cost me a few hundred Euro.

Which means to get the current implementation of evcc working I need an investment of > 1000 Euro to save 280 Euro per year.

With a few modifications to the software I can achieve the same with just investment in code.

support REST API for SolarEdge in the metering area would save me to replace the meter
support VW We.connect to control the charging instead of requiring a remote-controllable charger would save me to buy a wallbox

I indicated above that I am wiling to work on a pull request myself if you accept that these are valid use cases and will accept my contributions (assuming the code quality will meet your requirements).

If it is unlikely that you will accept my contributions because you reject the use case I would instead code my own one-off solution that works for me instead of extending evcc for my use case.

@andig @premultiply pls let me know what you prefer - either way is fine for me

andig commented 5 months ago

The desired integration is already possible using plugins. We won't provide support out of the box.

Bodobolero commented 5 months ago

The desired integration is already possible using plugins. We won't provide support out of the box.

It is possible but requires another server (Ulrich Schreiner's server) which is another point of failure and not a simple solution for other users.

Does it also support the following use case:

support VW We.connect to control the charging instead of requiring a remote-controllable charger would save me to buy a wallbox

andig commented 5 months ago

This issue is closed. We will not support the Solaredge REST API. we-connect has absolutely nothing to do with it.

evcc-io / evcc

Solaredge REST API #12046