Solaredge Smartshift Integration

[herbi3]

I have x1 solaredge inverter for Smartshift (I think something has gone wrong with provisioning the other x2 inverters I have, as Smartshift only reports the status of 1/3 batteries & 1/3 inverters)

I have noticed the solaredge Smartshift integration sets the Storage control mode set to Remote each time it wishes to charge from AC or discharge the batteries. I have recorded the register settings via modbus (using python) and the settings change in this order:

Storage control mode changes from 1, Maximise self consumption to 4, Remote then it changes the related Remote settings Storage Remote Command Mode to whatever is needed (charge, maximise export, maximise self consumption etc.) along with it changing the setting for Storage AC Charge policy

Then, when it is finished, it changes the Storage control mode back to 1, Maximise self consumption

would it be best to keep Storage control mode set to 4, Remote and just have Smartshift change the related 4, Remote settings? then the Storage Default Mode can be kept permanently at Maximise self consumption and only the Storage AC Charge policy && Storage Remote Command Mode && the duration of the remote command mode StorageRemoteCtrl_CommandTimeout

by using the StorageRemoteCtrl_CommandTimeout with Storage AC Charge policy & Storage Remote Command Mode when the timeout finishes, it simply defaults back to whatever is set within Storage Default Mode instead of changing Storage control mode each time.

I imagine that by not using the StorageRemoteCtrl_CommandTimeout functionality, that if the inverter could not communicate with the outside world that the settings applied during Smartshift will continue to remain until connectivity is re-established. where as if StorageRemoteCtrl_CommandTimeout was used, it wouldn't matter if connectivity was available since the inverter would just default back to Storage Default Mode setting after the timeout period.

below applies to activating zero export during negative feed in:
during my own automation of this before Smartshift provisioning, I also noticed that if I applied export_control_mode to 1 when this was already the exact same setting within the inverter, that the inverter would then apply this again and it would HALF the dynamic active_power_limit each time the setting was applied when it was already enabled. i.e, if I applied export_control_mode to 1 x4 times, then the dynamic active_power_limit would set itself to 1/4 of its capability. ( I was also applying export_control_site_limit from its absolute maximum, to 0 so the inverter would not export and would only produce what the consumption required.

Therefore, within my automation, I had it check to see if export_control_mode was already enabled, if it wasn't, then it would enable it only once. this was permanently set to 1 and only ever changed if it somehow changed back to 0 - the only setting that would change after this was export_control_site_limit - I would set export_control_site_limit to the maximum of the inverter during positive feed in times, and then only change export_control_site_limit to 0 whenever the FiT was negative.

If there is a Smartshift beta API, I would love to use it so I can dynamically change the settings on my end without them reverting back every 30s when the inverters are enrolled in Smartshift. otherwise, it would be great to somehow participate in the solaredge Smartshift integration myself, so any improvements or potential bugs, I could help resolve asap - I would love to assist overall, rather than just "fixing" any issues for myself with my own automation and not having anyone else benefit from it.

running on my linux server, I use python to read and write to the registers of the solaredge inverters via tcp modbus proxy (proxy is used to enable multiple connections to the inverter), the data is recorded in a seperate database and other python services do the automation thereafter (set zero export mode, turn off or on the hotwater (3.6kW), turns off or on the ducted aircon (14kW). I am next going to be using a DRED style of controlling % power input to the aircon compressor (I manufacture the DRED devices (along with many other products) that are used in solar and aircon units based on ripple control to limit power by 25%, 50%, 75% or off completely. instead of using the ripple control, it would simply be based on the Smartshift API (when available)

Solaredge documentation specifies this below:

Configurations examples for dynamic commands:
Discharge 1500W for 15 minutes:
StorageRemoteCtrl_CommandTimeout = 900 // Seconds. Inverter reverts to the defaults set in the initial configuration after the time out
StorageRemoteCtrl_CommandMode = 4 // ‘Discharge’ mode 
StorageRemoteCtrl_DischargeLimit = 1500 // W

Charge 2000W from the AC for 15 minutes:
StorageRemoteCtrl_CommandTimeout = 900 // Seconds
StorageRemoteCtrl_CommandMode = 3 // ‘Charge full from AC+PV’ mode
StorageRemoteCtrl_ChargeLimit = 2000 // W

[madpilot]

I don't really know Modbus to this level, so I'm hoping if I explain what we do on our end, we'll be able to piece everything together. So sorry for the possibly unrelated discussion.

Firstly, (based on my previous comment) - we don't use Modbus for comms. While I have "reading the SunSpec specifications" on my list of things to do I haven't started yet - so I couldn't say whether the APIs we access are thin veneers over SunSpec, or if they are something else.

When we send a command, we make one API call that schedules an event. We set the timeout for that event to be 5 minutes. This (as you correctly have pointed out) means if we can never communicate the device again, it will revert to whatever event is next in the stack (an empty stack puts the device back to default - which we assume is self-consume).

So, it's the Solaredge cloud API (or possibly the inverter itself upon receiving a remote command) that is changing the inverter's Storage control mode from "Self-consumption" to "Remote".

If there is a Smartshift beta API, I would love to use it so I can dynamically change the settings on my end without them reverting back every 30s when the inverters are enrolled in Smartshift.

(I feel like this is the crux of your question)

So, you want Smartshift to tell you what to do via some API/push/webhook/queue, then you'll talk to the inverter via Modbus?

[herbi3]

Thanks @madpilot - it seems the issue may be the solaredge API command, instead of changing the remote settings, it full on disables it when the default settings are desired, rather than just changing the type of remote setting as needed. This is controllable via modbus however it is still part of the UI for the inverter itself and I presume this should? be available within the solaredge cloud API to only change the remote command rather than disable and enable remote control and then change the remote command. it doesn't seem to be using the remote command timeout, which hasn't change from its default value of 3600 seconds.

So, you want Smartshift to tell you what to do via some API/push/webhook/queue, then you'll talk to the inverter via Modbus?

that would be ideal, but I would still need to get the live kW, kWh, SOC data etc back into Smartshift so it can do its great black magic stuff. Currently, I cant enable the Automated Solar Curtailment via the app, but with my solution above I could enable it via modbus with a simple call to the amber API or my continue with my current one (5m cached values, price goes negative > calls the function to drop the export limit to 0.

With a Smartshift API, it could reduce the burden of setup and config for advanced users. example, currently I can see the provisioning has been done on 2/3 of my inverters, however x1 of those inverters has no battery and would only need curtailment. the other inverter has success in controlling the x1 battery attached but now I am waiting for the last, third inverter with 2 batteries to be provisioned. the last inverter is the most important, as with tonights multi hour spike event it will drop my capability to 1/3 of the system total capability.

[madpilot]

I presume this should? be available within the solaredge cloud API to only change the remote command rather than disable and enable remote control and then change the remote command.

I can't see anything in their documentation - we only have the ability to set a duration, delay and priority. But I'll ask out tech contact.

but I would still need to get the live kW, kWh, SOC data etc back into Smartshift so it can do its great black magic stuff

Yeah, that would be part of it too.

Currently, I cant enable the Automated Solar Curtailment via the app

can you email me at smartshift@amber.com.au with your account details - I'll investigate. We only pushed that an hour or so ago, and maybe you caught an edge case.

currently I can see the provisioning has been done on 2/3 of my inverters

I'll check this too. Though Solaredge has a leader/follower setup, so we can talk to the lead inverter and the other two will follow. What might be a bit out is the telemetry that forces Smartshift to do a thing.

[herbi3]

I'll check this too. Though Solaredge has a leader/follower setup, so we can talk to the lead inverter and the other two will follow. What might be a bit out is the telemetry that forces Smartshift to do a thing.

all three inverters are set as their own Leader because currently there is no support for multiple blackout protection devices in a leader follower configuration. once a new firmware update supports x3 BUI's in Leader/Follower config, I may change these to leader follower if it were needed.

can you email me at smartshift@amber.com.au with your account details - I'll investigate. We only pushed that an hour or so ago, and maybe you caught an edge case.

I haven't yet had a response from last nights email. understandably, I am only one customer of many and I am probably too excited to have full Smartshift functions

[madpilot]

I'll readjust your battery settings back to 5kW charge/discharge each (Just so the algorithm doesn't get confused)

[herbi3]

@madpilot - in the app, I am getting a weird view, where the battery state of charge doesn't seem right. I've also noticed under the 'live' tab in the app, the metrics for solar seem correct for the total solar at the moment from all three inverters, but the power flow seems to only have data from the Red inverter. (i.e now it says our consumption is 0.5kw, but the consumption of all three combined is actually 2.3kw. the grid in the app says 6.5kw, but the actual for all three combined is 2.1kw. the battery flow says 1.7kw, but combined, they are charging at a rate of 4.65kw. im not sure if that has any affect on the algorithm for Smartshift, but I am concerned about the battery charge status under the 'plan' tab, where the line from 'now' to previous goes significantly different than from 'now' to in the future. (im probably not explaining this correctly, so I dropped in some images)

[madpilot]

The UI only supports one battery at the moment. Most people with multiple batteries are aggregated at the inverter, but for sites like yours where that more than one "virtual" battery, you'll only see one of the batteries. Same with the past data on the plan screen. The forecast plan data comes from a different data source that is already pre-aggregated, which explains the jump. Not sure we'll get to fix it this quarter, but it's definitely on our backlog.

The algorithm definitely knows about all of them though and will optimise correctly.

[herbi3]

great stuff! - I understand. this is where being able to post data into a Smartshift API would be handy

For the curtailment, until that setting is enrolled with solaredge (since I am freely able to change that setting without it resetting back to default from no site limit implemented on red and blue inverters) I have a python script running as a service to copy the curtailment settings from the white inverter to the other x2 inverters.

[madpilot]

For the curtailment, until that setting is enrolled with solaredge (since I am freely able to change that setting without it resetting back to default from no site limit implemented on red and blue inverters) I have a python script running as a service to copy the curtailment settings from the white inverter to the other x2 inverters.

I can get Solaredge to put in a site export limit for the other inverters - just let me know what you want to set it to. I just have no control over how they send the API command.

[purcell-lab]

I am next going to be using a DRED style of controlling % power input to the aircon compressor (I manufacture the DRED devices (along with many other products) that are used in solar and aircon units based on ripple control to limit power by 25%, 50%, 75% or off completely. instead of using the ripple control, it would simply be based on the Smartshift API (when available)

I am very interested in the DRED application, I think this has real application for home automation and would be wonderful for households to match things like excess solar production (aka Kevin Smith Paladin) and price signals (aka Amber). I have the control framework already setup, which gives me the power draw I would like my airconditing to adopt, I just don't have the DRED hardware, so if you are manufacturing an interface I would be really interested.

Another setup utilising DRED for airconditing control is from Rod Webster: https://community.home-assistant.io/t/controlling-air-conditioner-using-demand-enabled-response-device-per-as-nzs-4755/481353?u=markpurcell

My Energy Management System (EMHASS) utilises a linear programming framework and in many ways replicates the control functionality of SmartShift. I have EMHASS and SmartShift running in parallel and it provides a very useful independent verification of what SmartShift is doing. However I have limited control over the Powerwall, but running EMHASS with advanced SolarEdge modbus battery control would replicate almost all of the SmartShift intelligence and enable it to be run locally.

I have documented my setup here: https://community.home-assistant.io/t/running-devices-when-energy-is-cheaper-and-greener/380011?u=markpurcell

and my optimisation for the next 24 hours is crazy with the heat wave and 4 hour price spike, the red line is what I would like a DRED enabled HVAC system to be able to follow..

[herbi3]

this is excellent @purcell-lab - usual aircon have the x4 inputs, the DRED controller we sell to TMAC (Which then sells onto Energex and Ergon) has a RJ45 dongle, where the dongle connects to the usual x4 inputs then connects via an ethernet cable into the ripple controller.

My Daikin unit doesn't have the inputs with a screw terminal, but instead its own slim molex connector. I was going to use an ESP8266 flashed with tasmota for the relay control (terminated to the daikin molex connector) however as pointed out by Rob Webster, only one relay should be enabled at a time. I might just end up using the same device as he has, so then I don't have to worry about getting a 5v supply and can have it directly connected within the AC itself (if I can still find the 230v version)

[purcell-lab]

I suspect I need to get the Daikin DRED module installed first, but nobody seems to be able to supply them, and I can't purchase directly.

I have found if I ring around and state I want to connect to PeakSmart that installers understand better, but I'm still awaiting.

I have a nice 4 channel ESP board ready to go for the Home Assistant integration, once I can talk DRED to the AC.

[herbi3]

It seems that the "preserve battery" setting causes the battery to charge from AC when it isn't already full.

It switches storage control mode from 1, Maximise consumption to 4, Remote then it changes the settings within 4, Remote to Storage Default Mode from 7, Maximize self-consumption to 3, Charge from PV+AC according to the max battery power when I select preserve battery for x minutes. I'm not sure who is able to help, @madpilot hopefully you can kindly assist with this too?

I would expect that during preserve battery mode via the app, it would change the 4, Remote settings to 0 – Off OR 1 – Charge excess PV power only