Export Control #137
Comments
|
I'm not 100% on this one because it can be used to violate a utility interconnect agreement, such as utilities that require zero export as part of being allowed to grid tie. And it's not always a money thing, at least in Hawaii I know they do this on segments that don't have appropriately sized transformers instead of forcing transformer upgrades like some utilities do. It should probably be locked behind some kind of warning/disclaimer users have to agree to at minimum. |
|
Totally agree - this feature must always be used in compliance with the connected utility rules. The way that https://github.com/binsentsu/home-assistant-solaredge-modbus (sort of) managed this was by not implementing the unlock sequence documented on page 15 of https://github.com/WillCodeForCats/solaredge-modbus-multi/blob/main/doc/Power-Control-Open-Protocol-for-SolarEdge-Inverters.pdf - i.e. to make use of the export control feature, the user has to manually write to the registers to enable this behaviour. |
|
Zero export capability is an important feature for users who are exposed to wholesale market prices, which means the feed in price can go negative for a variable number of hours during the day. As the timing of the negative feed in is variable being able to switch this capability via HomeAssistant becomes very powerful. I have 2x three phase 7kW inverters and Powerwall2 and am happy to assist with testing. I find myself switching between binsentsu:solaredge-modbus for the export control and this solaredge-modbus-multi for the multi inverter support ;-( Last week in South Australia the negative feed in price was -$1.10/ kWh!
|
|
I understand the purpose of it, but I want to implement it in a way that does not expose them by default and requires acknowledgement that altering these settings could be in violation of a utility agreement or cause a large bill if used improperly. |
According to the docs the register at 0xF142 should be set to 1 to use any of the StoreEdge commands. But the docs for batteries aren't always completely accurate, either. My inverters do not have any of the power control modbus registers available even though they do support power control through SetApp. I've added it to Release v2.2.6-pre.1 so if you run it with debug logging it will be logged as |
|
Thanks for 2.2.6-pre.1, my logs are reporting I_AdvPwrCtrlEn for both my inverters, but disabled. I will attempt to enable via SetApp. |
Hypothetically how would one write these registers? :) speaking as someone from South Australia that is being charged an arm and leg because I can turn it down |
I have been trying out different ideas in the UI, but nothing that can be released yet. |
Are they available settings in the commissioning process part of SetApp? In the SetApp they don’t show up in the settings. How would someone normally (technician) modify these values…they are after all in the documentation for use by installers and technicians |
|
It looks so simple on the video: |
Edit…nope doesn’t stick either. I can (can’t) do that. …Just put it in AP mode, connect to is wifi and then go to http://172.16.0.1/ Problem is getting HA to do it. As I have to be next to the unit to do it that way. |
|
|
This is what I came up with for a config dialog:
It would be accessed using a two step process through integration options, then an "advanced power control" checkbox, which if checked brings the user to this screen. Thoughts? |
You are providing more context than the SetApp dialogue which I think is a good thing, but still allowing users to access the advanced settings. |
Looks perfect…merg!!! 😂 the sun is rising |
|
It's in branch |
|
I couldn't get the selectors to work properly in HA for some reason (they only worked from disabled->enabled but not the reverse) so the final version that's in PR #147 is checkboxes for each "enable" confirmation:
|
|
It might be good for compatibility with binsentsu to have similar controls:
Export control limit mode
Export Control Mode
Export Control Site limit
|
|
issue closed in error |
We're seeing similar things here in NSW and after Amber broke their retailer level integration with Solaredge grid services API, it would be great to be plugging this with HA. Flipping circuit breakers off today to doge the negative FIT felt wrong in many ways. I just want zero export while still self consuming. |
|
I need people to verify pymodbus 3.0.0 in Release v2.2.6-pre.3 runs ok since I'm not going to do any new or substantial updates to anything based on older pymodbus. |
2.2.6-pre.3 running solid for me. 2x three phase 7 kW inverters. Anything in particular you would like me to check? Some minor transient issues, but probably more to do with my home network. |
|
So far so good here too after upgrading this afternoon. Two 1P inverters SE6000 and SE5000 follower with meter. |
|
As long as it recovers from connection or update errors automatically without requiring a reload or restart to recover from, it should be fine. I'm looking for major errors where you have to restart home assistant or uncaught exceptions. |
|
Would you like me to raise new issues for each of these tracebacks or continue to file here? I think this is during the reset when changing mode and device goes unavailable: I have two inverters connected via RS485 and Inverter 1 is the master which I am issuing the export control for, which does work and controls both inverters, but the detailed logs below tell a different story. Detailed logs: |
|
Already handled in commit a807372 |
|
Various fixes will be in PR #188 |
|
Release v2.2.7-pre.8 is now available. It contains a large amount of changes to naming and validation for power control functions. |
|
Release v2.2.7-pre.9 fixes an issue on inverters that don't support power control functions over modbus. |
|
Thanks installed 2.2.7-pre.9 The display is better and we no longer have that crazy value. I am still seeing the device go unavailable briefly when changing modes and an error in the logs, but not much details. I am trying to reduce export to zero, but it looks like it is now reducing total production to zero, pre.7 was limiting export correctly :-(
|
|
There weren't any functional changes, only naming and validation cleanup. As far as I understand export site limit that's how its supposed to work: if any production exceeds consumption that would cause export in excess of the site limit value, production is throttled back to meet the site limit value. The limit control is described as "dynamically adjusts the PV power production in order to ensure that exported power does not exceed a preconfigured limit". If an inverter is unresponsive (or a read cycle fails for any reason) entities go into unavailable state until the next successful polling cycle to prevent stale or invalid data from being displayed. This behavior was added in PR #38 (suggested in issue #23). In pre.9 updates were made to conform with existing behavior whereas the earlier pre-releases were incomplete. If the inverter goes unresponsive after sending it a command I could add a config option to make the integration "sleep" after sending a command, then you can just put some value of 3-5 seconds for the sleep or whatever works for you. I can't actually do anything to fix the inverter going unresponsive. |
|
Delay after sending a command option will be in PR #197 with a default of 3 seconds, config range is 0 to 10 seconds. |
|
Release v2.2.7-pre.10 includes the new delay option. I fast tracked this one and did very little testing on it, hopefully no bugs or regressions. |
Thanks, the issue for me was it didn't appear to be limiting export to zero, it appeared to be limiting production to zero. I will do some further testing today with pre.10 once the sun comes up. |
|
Export limitation is a variable production limitation. The inverter(s) will dynamically adjust between 0% to 100% to seek the target site limit whenever consumption is less than production and there's nothing else to consume excess PV power such as charging a battery or other communicating device like the Smart EV Charger. |
|
If it was in production limitation mode with a 0 site limit, it would have hard dropped to 0 and stayed there. The graphs show them dynamically adjusting and the integration can't do that. |
|
With pre.10 the device seems to now go unavailable for a longer period when I change modes/ values. This doesn't seem to impact functionality, but it just appears in the logs and lovelace. |
|
You can try setting the Inverter Command Delay longer than 3 seconds. I don't have a reason for choosing 3 as the default. |
|
Maybe the real question is if a default is even necessary. If the default is 0 (disabled) then if inverter response timeouts after sending commands is causing a problem then the user can adjust the delay to whatever works best for them. I don't know if inverters going silent after a command is normal or only happens on some setups. |
|
Export Controls seem to be working as expected, I may have jumped the gun yesterday thinking it was limiting production to zero. Thanks, I have setup to 10 seconds and it seems to fault less, but when it does fault it goes unavailable for 10 seconds ;-( When using the binsentsu export controls the device didn't go unavailable which is my only other frame of reference. |
Looks like that one just writes blind. It doesn't try to read or validate anything, no return checks, no error handling. Here after a command is sent we immediately queue an update (if it was successful), but if the inverter is "busy" the update will time out on no response. The other difference is the suggestion from #23 where we choose not to serve stale/bad data as a design choice and switch entities to unavailable until the next successful update. |
|
I think going unavailable for a moment isn't a big issue. Maybe drop it to a warning rather than an error. |
|
I can't change the log level of the coordinator update error since it's from HA core. |
|
I have resolved what is going on when I set export limit to zero causing the system to reduce to zero production.
I have an AC coupled battery (powerwall2) set to self consumption mode and an EV charging set to excess solar via ChargeHQ. It would appear that both of these devices sense how much power is being exported and then adjust their consumption accordingly. Thus when I set SolarEdge to zero export both powerwall2 and chargehq see no export and so gradually reduce their consumption, which in turn is seen by SolarEdge as reduced load and thus it reduces production to maintain zero export. Finally the steady state is reached when I have zero export and zero production and the house is running 100% off the powerwall2 and there is no EV charging ;-( By setting export limit to 200W, the steady state is excess solar EV charging is maximised, powerwall2 excess solar charging is maximised and I may lose a little bit in exports, but that's OK. |
|
Glad to hear everything is working. I'll let the pre.10 release bake a bit on my live system and watch for running errors over time, but unless something else comes up I think it is ready for a 2.2.7 release. |
|
I have installed now...despite set-up I still don't have control. I contacted Amber and had them unenroll me in grid services...I'm told that I have been...also had Solar Edge update my firmware. Site Limit returned default a few seconds after changing....advanced power control remains off |
|
i just updated to latest version (i skipped few in between) and seems that there are some duplicated controls shown up. i am good with export control. since i dont have leagly set up PV station, i must be no export at all :) but i like controlling betwen MSC mode and remote - to charge from PV only. Shortly disel generator will be added to system. p.s. @purcell-lab grat looking powerflow chart. would you mind sharing source? :) |
|
Almost all unique IDs or names changed, which creates new entities. HA doesn't delete old entities, the user has to do that manually. |
|
@ThirstyDursty I can add a control to try and change that value, but we is already has a very large number of changes so it'll have to be in the next release. I'll work on a 2.2.8 pre-release to add that control as soon as 2.2.7 is out. |
@ThirstyDursty my site limit was constantly changing back everytime I set it because my solar inverter was still enrolled in Grid Services via SmartShift. It took me about a month to get Amber to process through SolarEdge with multiple follow-ups. I ended up with a guy in SolarEdge who could see everything and told me to keep going with Amber un-enroll process. So I would go back to Amber and confirm your SolarEdge has been un-enrolled. I have site limits working well here now, but the Advanced Power Control flag does not change. Here is my automation, I chose a limit of 200 W export so my battery Self-Powered mode and ChargeHQ excess solar mode would both work: alias: Zero Export Automation
description: ""
trigger:
- platform: numeric_state
entity_id: sensor.amber_feed_in_price
below: 0
- platform: numeric_state
entity_id: sensor.amber_feed_in_price
above: 0
condition: []
action:
- choose:
- conditions:
- condition: numeric_state
entity_id: sensor.amber_feed_in_price
below: 0
sequence:
- device_id: 8e8f45345219e32b8a645ce8dfb767c3
domain: select
entity_id: select.solaredge_i1_limit_control_mode
type: select_option
option: Export Control (Export/Import Meter)
- device_id: 8e8f45345219e32b8a645ce8dfb767c3
domain: number
entity_id: number.solaredge_i1_site_limit
type: set_value
value: 200
default:
- device_id: 8e8f45345219e32b8a645ce8dfb767c3
domain: select
entity_id: select.solaredge_i1_limit_control_mode
type: select_option
option: Disabled
mode: single
|
|
Release v2.2.7 is now available. |
|
Now that we have a release with all the power control functions I'll go ahead and close this issue, but I've created discussion #207 with a reference back to here. |
The export control block of registers allows control of how much power is exported from the system to the grid. This may be useful, for example, to prevent export if the export rate is negative.
Once the select / number controls are merged, it will be relatively easy to add support for this feature which should be the last one to bring this integration up to feature parity with https://github.com/binsentsu/home-assistant-solaredge-modbus (this was merged there in binsentsu/home-assistant-solaredge-modbus#42)
The text was updated successfully, but these errors were encountered: