I was more concerned with causing undue load on the inverter if it wasn’t designed to be polled that often.
Does anyone know how often the app updates (I can’t get mine to connect locally to my inverter as its on a different WiFi network).
It’s a good thought, although genuinely even the most simplest of controllers would be able to handle that and the GE app is doing similar on a local level too now.
Great spot though and I’ve changed mine to 1 seconds.
Would it be possible to add a Grid Import Power sensor to the component? I’m guessing if the inverter doesn’t have this sensor then it could be calculated by subtracting Consumption Power - PV Power, plus whatever is needed to take into consideration the power from the battery.
1 Like
If you haven’t already played with this @sday15 . Here is my grid import sensor in configuration.yaml
- platform: template
sensors:
grid_import_pos:
unique_id: 'grid_import_pos'
value_template: "{% set grid_import = states('sensor.grid_export_power') | float %}
{% if grid_import < 0 %}
{{ - grid_import | int }}
{% else %}
0
{% endif %}"
device_class: power
unit_of_measurement: W
icon_template: mdi:transmission-tower
On the poll rate, the library it’s using currently has some bugs that make the poll rate unreliable. You may be seeing intermittent errors in the logs about failure to decode responses from the inverter, causing the odd missed update. The 1 minute poll rate seems to achieve a good balance for now, but once this underlying issue is fixed, a more rapid and/or configurable rate would certainly be possible.
1 Like
Certainly possible, but I think the template route is a good one for now. Most of the sensors come straight from what the inverter reports - only a couple are derived by combining those values. PV Power is one of these derived values - the inverter provides values per string, but in this case a total felt like a common enough use case. I figure everyone has slightly different requirements, so adding all possible combinations might get ugly.
Another point to bear in mind: if you start digging in to the maths too much, you realise that things don’t quite add up in some cases. For example, when my 5kW inverter maxes out, PV Power might be ~5.3kW, but power out of the inverter never exceeds 5kW (sensor to be added!).
I get another interesting example with my consumption sensor. Here’s a day with nobody at home (you can see the fridge cycling but not much else going on. As the sun comes up the sensor drops towards zero. On a normal day this is masked by household usage. Probably a question for GivEnergy.
That might explain why I can’t get the numbers to add up against what my smart meter is reporting verses what is showing on the Energy Dashboard.
Another issue that I’ve noticed is that sometimes the values go to zero, which also messes with the dashboard (see just after 12:00).
Thanks! Am liking this - look forward to further developments on the battery side of things! 
Having my battery installed on Monday, looking forward to getting this up and running. I’m happy to test future versions
Thank you for creating and sharing this!
Got it set up quickly and reporting back data every 60s.
Did your battery arrive and have you had any joy in reporting back the battery charge/discharge etc? I’ve tried with a template but as I have other solar (non-Giv) coming in, it’s getting tricky.
TIA!
Still waiting for the battery. I’ve done some initial (unpublished) work for it but had to park it while I’ve been busy. The latest estimate is still this month. Fingers crossed!
1 Like
GivTCP does this, so I guess this is a problem with the modbus library.
I’ve just published an update (v1.0.1) to try and deal with the zero data issue. The connection provides what it claims is valid data, but most values are zero. As you say, that really screws with the energy dashboard, causing a load of double counting. It should now discard those values and log an error.
In other news, I’ve just been told my battery has arrived, so just got to arrange the install 
1 Like
Thank you for this integration @cdpuk
My battery was just installed today so looking forward to get that integrated as well.
@cdpuk Would agree with the configuration prefix. I think it would be useful. Especially when in search boxes when looking for them in automations, etc. I like to see all available options for a given prefix.
I think this could be added as a config option and set to an empty string as default. Else, if set explicitly , use prefix for all entity names. I forked your project and started looking at this but got sidetracked. I will look into that in the coming weeks.
I have this installed and works perfectly. Just had my battery installed so look forward to that section being added. I had a brief look at the code to see if I could help by it’s way over my head.
Many thanks for the awesome work.
One request is for each string to be a different sensor. I have one East, one West. To get more accurate solar forecasting I’d need these as separate strings.
Hi @cdpuk
So I took a look at your excellent work and played with the battery branch you have for a bit. My conclusion is that actually the data from the battery is largely of secondary use. There’s an inverter side data point - ‘battery_percent’ which gives the human readable (and buffer adjusted SOC - the same as the givenergy dash). I’ve added this to my fork and it’s working nicely.
Obviously adding the battery data as you’re moving to do on your other branch would be good long term as it would probably be nice to have data for the battery(ies), but maybe the next priority ought to be trying to get the control side working - currently I use the API to make calls but I understand the modbus is capable of doing this locally.
I’ve added the per-string PV power sensors to the v1.1.0 release today. If there’s demand for more detail (voltage, current, etc) perhaps attributes added to these sensors would be best to avoid clutter. Let me know how you get on,
From my experience the built-in HA solar forecasting works quite well. I have one forecast for each string and template sensors to group the data together as required. This doesn’t rely on any inverter data at all. Just add “Forecast.Solar” to your integrations.
1 Like
Battery is now installed, but apparently there’s some sort of comms problem so the inverter can’t read any data from it. Fortunately it seems to charge and discharge normally so things still roughly work.
Based on that, I’ve managed to release v1.1.0 with the most important battery sensors added.
If you remove and re-add the integration, you can also configure the number of connected batteries. This part I’m currently unable to test, but if we’re lucky, you might see a new battery device in HA, with a couple of sensors such as SoC and Remaining Capacity. Keen to hear if these work for people.
Obviously more work to do for further sensors and services to change settings, but at least a shiny energy dashboard is possible now
2 Likes
The battery has shown up straight away after upgrading to 1.1.0 - thanks!
Added in the charge and discharge values to the Energy dashboard to see how it makes sense of it. Still playing around to get the true house consumption stats working correctly, which the battery was throwing out/masking I think.