In Release v2.4.8-pre.1 there is a potentially backwards incompatible change to the Energy sensors to better fit today’s Home Assistant.
The entity names for Energy sensors will no longer have kwh in them by default.
The reason kwh should be removed from the name is because this is no longer strictly true. The inverter actually uses watt-hours and previously the entity would statically scale to kWh. However at some point Home Assistant updated to allow entities to be dynamically configured for units and precision through the UI, so now anyone can choose to see energy in Wh, kWh, MWh, whatever units HA supports for Energy class sensors. So having a sensor name with kwh in it is no longer appropriate when it could be several other supported units for its class.
This can be backwards compatibility breaking but it depends: existing energy sensor entities with kwh in the name won’t change on simple upgrades to the current version of the integration.
The name will change to the new default if you remove and re-add the integration or device. New users will notice if they installed a version after v2.4.8 for the first time that their Energy sensor names don’t end with kwh and templates will need to be adjusted to remove kwh from the name.
I don’t know if there’s a way to set up templates to look for both the old and new sensor entity names (with a name ending in kwh or not). If there is this would make it easier to accommodate existing and new users without template changes.
I don’t like making breaking changes, but sometimes it turns out that decisions made in the past that were good for the time don’t always fit long term. I like that HA added these features to change between units dynamically, but I wish I’d named my entities better to consider that.
Internally the native unit for energy will be watt-hours.
The inverter’s native units when reading it over modbus is watt-hours. The default suggested unit will still be kWh so it won’t appear anything has changed other than the name, and let Home Assistant to do the unit conversions and remove any hardcoded unit conversions.
This shouldn’t affect anyone, but I’m mentioning it just in case.
Is there a dedicated Export, Load and Combined Import/Export Power sensor? I can see some of these in the standard SolarEdge integration but they only update every 15 minutes. I have setup the last one using a template sensor based off the sensor.solaredge_m1_ac_power entity but not sure about the others.
The blueprint states:
Export Power: Sensor which contains your current export power to the grid in watts. Must not be negative! For best results, this sensor should be updated at least every minute.
Load Power: Sensor which contains your current load power (combined household appliance consumption without home battery charging consumption ) in watts. Must not be negative! For best results, this sensor should be updated at least every minute.
Combined Import/Export Power: Sensor which contains both , your current import power from the grid (positive values) and your current export power to the grid in watts (negative values). For best results, this sensor should be updated at least every minute.
Edit - sorted the Export Power sensor, just no idea how to get the load power as circled below
I’m looking for help with some battery info (since I don’t have batteries).
I want to know if the device attributes (for entity sensor.solaredge_b1_device) are fixed values or of they can change over time. The documentation calls them “battery nameplate information” which means to me that nameplate values should never change as if they are printed or attached to the device itself, and why I chose to implement them as attributes of the device.
However, if they can change over time, ones that can change should probably be added as their own sensor entities for statistics instead of attributes. These are the attributes I’m looking at:
I am using the older “SolarEdge_Modbus” integration - and for now, I haven’t really seen the requirement to change the setup (especially, since this would require to redo the whole energy dashboard, etc.)
But I do get regular errors in my logs about an invalid state - probably, when the inverter resets (as I read further above)…
2024-01-07 17:49:47.639 ERROR (SyncWorker_6) [custom_components.solaredge_modbus] Error reading modbus data
Traceback (most recent call last):
File "/config/custom_components/solaredge_modbus/__init__.py", line 240, in _refresh_modbus_data
update_result = self.read_modbus_data()
^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus/__init__.py", line 316, in read_modbus_data
and self.read_modbus_data_meter1()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus/__init__.py", line 326, in read_modbus_data_meter1
return self.read_modbus_data_meter("m1_", 40190)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus/__init__.py", line 475, in read_modbus_data_meter
exported = validate(self.calculate_value(exported, energywsf), ">", 0)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus/__init__.py", line 158, in validate
raise ValueError(f"Value {value} failed validation ({comparison}{against})")
ValueError: Value 0 failed validation (>0)
Since I am using a Modbus Proxy for the connection between HomeAssistant and my Inverter (The inverter does only accept one connection - and I need other devices read from the inverter directly) - this setup should allow me to use both integrations (Modbus multi) and my older one in parallel.
I know, a connection issue on HA side should affect both integrations, but also Inverter related disconnects.
This test should just show, if there are issues related to one of the integrations itself
I haven’t done any development with a proxy in mind, but if there are any proxy-specific problems let me know. As a direct connect it’s very stable and error-free at this point (after 162 releases and counting).
I don’t know how a proxy will work with the connection backoff and retry logic built in to the integration, but it can be adjusted in const.py in the RetrySettings class. Debug logs will show the details. Defaults were based on what works with my installation and tuned from feedback and observations.
There’s Not much behind this.
Running it since mid 2022 without any issues to overcome the limitation on Solar Edge that only one Connection can be established.
Does anyone have the idea why the Energy Distribution does not work?
I was trying to manually set the values under the “Energy” tab but the entities which should be used are not shown there.
If I am not wrong those entities should be used there?
sensor.solar_imported_power_kwh:
device_class: energy
sensor.solar_exported_power_kwh:
device_class: energy
sensor.solar_panel_production_kwh:
device_class: energy
sensor.solar_panel_to_house_kwh:
device_class: energy
sensor.solar_house_consumption_kwh:
device_class: energy
For those experiencing issues with their inverters resetting at random intervals, and thus reverting any changes to the default settings, may I suggest my solution of adding a ‘watchdog’ automation to protect against these events.
Essentially, you want to add changes, to your desired setting(s), as triggers for your automation and then assess their state. If their state is not what you want it to be at that time/under those conditions, then reset it to what it should be. What will happen, in case of a reset, is that your setting will become ‘unavailable’, your watchdog automation will try to reset it, and fail. Then, when the inverter comes back to life, the state will change again, to the default values. Your watchdog will trigger again, and this time it will be successful at setting your desired values. This should only cost you a second or two of default operation, before your settings are restored.
As an example, this is my watchdog to ensure that my battery remains in grid charge mode throughout the cheap overnight period of my tariff.
alias: Battery Go Watchdog
description: ""
trigger:
- platform: state
entity_id:
- select.solaredge_i1_storage_command_mode
condition:
- condition: and
conditions:
- condition: time
after: "00:30:00"
before: "04:29:00"
- condition: not
conditions:
- condition: state
entity_id: select.solaredge_i1_storage_command_mode
state: Charge from Solar Power and Grid
action:
- device_id: ************************
domain: select
entity_id: ************************
type: select_option
option: Charge from Solar Power and Grid
mode: single
It is also possible to roll this functionality into the main automation, by adding changes of the desired setting as an additional trigger, and using the trigger ID functionality to discern which path to take.
This specifically catches the reset that happens overnight, with conditions that check if the home battery should be charging. It can be adapted for any other situation, for example,if I’m charging the EV battery when the home battery is not charging, I shut down the battery output limit to prevent the EV draining the battery. If the inverter resets during this time, it will reset the battery output limit to max and drain the battery into the EV battery. My EV charging automation has th same trigger, with a different set of condtitions to check if the EV battery is charging at the time of reset.
This works every single time. I’m on an Agile tariff, so my charge window is not fixed.
type: entities
entities:
- entity: select.solaredge_i1_reactive_power_mode
name: Reactive Power Mode
- entity: button.solaredge_i1_commit_power_settings
name: Commit Power Settings
- entity: sensor.solaredge_i1_commit_power_settings
name: Commit Power Settings
- entity: button.solaredge_i1_default_power_settings
name: Default Power Settings
- entity: sensor.solaredge_i1_default_power_settings
name: Default Power Settings
title: I1 Power Settings
The Default Power Settings button entity is disabled by default to avoid accidentally using it. All others are enabled by default.
Button entities send the command and the matching sensor entities show the inverter’s response to the command. A value of 0 is success. Other values mean errors (which will be added to the attributes if it’s a value that was in the specs).
According to the SolarEdge documentation, you’re supposed to use the “commit” function to save changes made to most of the controls. I don’t have an inverter that supports controls, so someone with the resetting problem will need to try it and report back.
Dave, Many thanks for this very helpful input. I set up a trigger based on this to catch the overnight reset and the evening reset (the overnight one seems to be exactly 10 hours after the evening one). Overall, this has worked, but I have found that on a few occasions, values are being reset without being captured by the trigger.
This is the log extract from this morning:
Have you seen this happen at all ?. I do wonder if my 15sec data capture interval on the modbus configuration is too long so that sometimes I miss all the changes.
I never see any of that in my logbook when the inverter resets. I’m currently running v2.4.10 pre.3 of the modbus-multi integration and all I see over a reset is this when it goes off:
