Optimal "minimum time between entity updates"

[ianfretwell]

Hi - not an issue as such, more a request for assistance.

Is there an optimal setting for the "minimum time between entity updates" in the Configure settings ?

I have tried 4 and 5 minutes and on either I see the following type of results - notice the frequent inability to get any results. The wifi doesn't seem to be dropping to the inverter so I just thought there might be a 'better' value to be using for more consistent results.

Thanks.

[robbinjanssen]

Hi @ianfretwell,

Can you tell us a bit more about your setup? Like what inverter do you use?

Although you don't say that the wifi drops, it seems like a connection issue. Maybe add a binary_sensor and ping your inverter for a while? See if the connection drops?

Add this to your configuration.yaml

binary_sensor:
  - platform: ping
    host: x.x.x.x
    name: "My Inverter"
    count: 2
    scan_interval: 60

[ianfretwell]

@robbinjanssen Thanks - I'll give that a go and see what it shows up...

[HartmutHartmann]

Hi, just wanted to add that I had a similar experience since installing the integration on sunday. I've also had a ping sensor(checking every 5min) with clear times when the inverter was asleep.

[ianfretwell]

Apologies @robbinjanssen - I completely ignored part of your original response, here are the details -

Inverter - Omniksol-4k-TL

@HartmutHartmann Thanks for posting at least it shows I'm not alone.

[Step-han]

Hello!

I have the same problem. Previously I used Hein Oldenhuis's HA integration (https://github.com/heinoldenhuis/home_assistant_omnik_solar).

That integration updates neatly every 60 seconds, this cannot be shorter with that integration.

I now use this integration as Hein's integration no longer gets updates.

However, it now updates completely randomly and not stable. Not every 60 seconds, even when I set it. By default it was 4 minutes for me.

The WiFi connection is stable, there is an access point less than 5 meters from the 3 inverters.

I'm using: omnik1000tl, omnik2000tl and an omnik2500tl2.

Any idea what's going wrong?

Stephan

[MarijnS95]

@Step-han Hein's integration uses a TCP connection, which is probably more stable and also provides more statistics while at it. I've liked this integration more with a config flow and all sensor entities bundled under a device, and now that Hein's plugin is deprecated I'm working on porting TCP connection support to python-omnikinverter and this integration, stay tuned!

[klaasnicolaas]

Which version of the integration are you using? Since the last version we have abandoned the reuse of session, which could result in inverters no longer blocking a connection.

As for the interval time, it is set to 4 minutes by default because the inverter in their web interface often only updates once every 5 minutes.

[ianfretwell]

In my case the version is v2.3.0.

[MarijnS95]

@klaasnicolaas It seems that python-omnikinverter does a separate network request for the "device" and "inverter" information, even if both network requests are the same. If this HASS plugin consumes both bits of information it may hit a rate limit (if there is one) twice as quickly?

[klaasnicolaas]

This only happens if you don't pass a session otherwise it will reuse the old session to make another request. As far as we know there is no rate limit and I have never run into it during testing (which is stress testing) so I don't expect this to be the problem either.

We have just removed the session because certain inverters do not like it when you reuse a session. You could always use wireshark to see what is happening with requests in your network.

[MarijnS95]

Keeping the session/connection alive is one thing, resending an identical request for the same data (which likely also happens to be identical) - while not the end of the world (and probably not the source for this issue either) - just seems rather wasteful:

https://github.com/robbinjanssen/home-assistant-omnik-inverter/blob/d00ad655da66329ed894ba18ba590bd23d0e71dd/custom_components/omnik_inverter/init.py#L123-L124

[klaasnicolaas]

We might merge that in the future, but let's save that for another issue 😉

[Step-han]

In my case also v2.3.0.

I ran this version and Hein's version side by side for a while and Hein's always updates every 60 seconds and never misses a pull. This integration misses alot of pulls when configured with 1 minute interval, sometimes no data for more then 15 minutes.

For now I'll stick with Hein's as long as it continues to work with HomeAssistant

[robbinjanssen]

Does this also occur with a previous version? v2.2.0? v2.3.0 introduced some changes into handling sessions as klaas mentioned, maybe this has something to do with the "broken" graph

[robbinjanssen]

@HartmutHartmann @ianfretwell @Step-han you could try using the TCP backend now, just reinstall the configuration and select TCP :-)

[ianfretwell]

Thanks - I'd already uploaded to the new version and seen all the new sensors - none of which worked for me even after enabling them.

I've now reconfigured with TCP and they are now working, but I've lost two that worked previously (IP address & Signal Quality).

Is that just because of differences in what my inverter is returning depending on whether it's setup for JS or TCP?

[MarijnS95]

https://github.com/robbinjanssen/home-assistant-omnik-inverter/pull/110

Note that device information (firmware, IP address and WiFi signal strength) is unavailable through this API.

This is something that we might want to add later, by querying the device over both JS and TCP. That should also allow the Serial Number setup to be automated by first doing a JS request and parsing the number from it.

However, in my testing the Serial Number seemed to be sort-of irrelevant. The inverter still replies with data even if it's "wrong" (e.g. just set it to 0). If you can, please test with a serial number of 0 and notice if there are any timeouts (@robbinjanssen found that his inverter seemed slower to respond, and my initial testing did show signs of that as well).

In the end we'll probably rework this after turning the TCP backend into local_push instead of local_polling; but that requires some refactoring on both the python package and its usage here.

[ianfretwell]

Just an update then - after two days of using TCP rather than JS - the gaps in reporting remain pretty much the same - no better, no worse.

[MarijnS95]

@ianfretwell As far as I've understood the code these requests for updates are driven by home assistant itself (local_polling) which may be affecting this odd poll rate somehow. If I make some progress on a little redesign to make pushing possible over the TCP backend I'll let you know for testing purposes :)

[ianfretwell]

Out of interest - today the integration hasn't managed to connect even the once successfully.

Yet at the same time I use this project

https://github.com/jbouwh/omnikdatalogger

in a dedicated docker instance, also configured to use a TCP connection, and it's been absolutely fine all day. I've been using them alongside each other all along. So if one works and the other doesn't surely they're making their connections differently somehow ?

[Step-han]

Still using Hein Oldenhuis's HA integration, its not broken (yet).

Anyone tested this intergration with a omnik inverter? How is the update frequency? And is it stable now?

If nobody tested it I can test it in the future..

[ianfretwell]

For me it's no better or worse than it was when I originally posted back in February.

[robbinjanssen]

I haven't had any drops, but the code hasn't been updated in a while so probably nothing has changed. Im not sure how we can approach/debug this..

Personally im using the JS source and I don't think my inverter actually powers down at night.

1-15 dec:

14 dec:

[klaasnicolaas]

it would be interesting to find out how it is possible that an inverter can sometimes not be reached during the day 🤔

[Step-han]

@robbinjanssen

What is the interval from the data?

Hein's intergration every 60s a data record:

[klaasnicolaas]

Default is every 4 minutes, but you can adjust it in the options flow to at least 1 minute.

[github-actions[bot]]

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!