NETGEAR Integration -- Make "SCAN_INTERVAL" Configurable or Shorter by Default

Feature Requests
1

Hello,

I am using the Netgear integration to track device presence for various automations based on phones connecting to the router WiFi. Everything works fine, but there is a huge delay between any changes being registered by the router and updates in the entity status.

I checked the router “Attached Devices” page directly, and it only takes a few seconds for a change to register; by contrast, the integration takes a minimum of 60 seconds and sometimes more, which makes it very difficult to use for automations – by the time the automation fires, I will’ve had time to push twenty buttons and make a coffee. For completeness, “Consider home time” is set to 5s.

Tracing the issue, I found this definition in (...)/homeassistant/lib/python-xx/site-packages/homeassistant/components/netgear/__init__.py:

(...)
SCAN_INTERVAL = timedelta(seconds=30)
(...)

It seems this sets a minimum boundary for any updates, which causes the long delay. I made a manual change to test by changing from 30 to 10 in the above, and the device tracking is now 2x-3x faster (20-30 seconds), which makes it much more useful!

After running with the above change for a couple of days, I see no ill effects, but of course YMMV on different router versions/firmwares/etc. Therefore, I’d like to request the addition of a configurable “Scan Interval” option to the configuration panel for the integration, next to the current “Consider home time” setting, thus allowing users to specify an interval that works for their needs.

If that is too complicated, at least reducing the default to a shorter interval would also resolve this, testing allowing of course.

Thank you!

Regards,
Mihnea

2

scan_interval was purposely removed from ALL GUI Integrations, so it’s very likely your FR will not go anywhere.

If you want a custom scan interval, then you need to disable polling and set up an automation for it. Petro’s post here explains how do this quite clearly.

3

Hi @ShadowFist , thank you for taking the time to respond. Unfortunately, the link you posted is not very clear on what the intended solution would be here:

  1. Disable polling – ok, that’s easy enough to do, you mean for the entire Netgear integration in this case, right?

  2. Create an automation – this part is the confusing bit:

    • do I need one automation for each individual entity, or just one and the other will somehow update as well?
    • my entities here are of type “device_tracker” and not “sensor”, does that matter?
    • the example also has manually constructed times for every single hour; do I need one for every ten seconds of every single minute of every single hour in a day, all 8640 of them? That would be… unwieldy to say the least!

Thanks again!

4

Coffee still hasn’t kicked in, so I’ll just answer this part, at least for now.

No, you use a Time Pattern trigger. In your case, you’d use the third example:

  triggers:
    - trigger: time_pattern
      seconds: "/10"
5

Thanks, this was helpful, didn’t realise that was an option.

I was able to get it working with the automation, and to answer my own questions – it seems that I do need to add each individual entity specifically, but their type does not matter.

The whole thing does feel like a kludge though, rather than having the ability to adjust the scan interval directly… Any idea why it’s set to such a long time (30 sec) by default?

6

That ship sailed over a year ago, when the powers that be decided this was the way forward for all gui integrations.
Even if you had spoken up with all others who complained about this at the time, it wouldn’t have made much of a difference because the decision had valid reasons at its core.

It’s a value the integration owner decided was the correct balance between too many and too few requests.
If you think a lower value should be safely set as the default and won’t have negative effects on ALL users of this integration (not just you), feel free to raise a PR for it

7

Ok, understood, it’s good that there’s at least an alternative option to the hardcoded value. In general it’s not a great idea to hardcode things like this in any piece of software, but if that was a collective decision, it is what it is.

You could have just said “no”, the sarcasm is uncalled for, really.

8

I wasn’t being sarcastic at all. I just wanted to point out there might be a reason why the integration owner chose that value, one which you might not be aware of.

It wouldn’t be the first time that the default scan_interval for an integration was set to a lower frequency after it was released. The Ping integration default scan_interval went through this exact same thing.

My suggestion to raise the PR was based on the fact that you already knew what to change. Even if your PR didn’t get accepted, at least you’d find out why the current value has been chosen.

9

Sorry for the misunderstanding on my part. I just interpreted it that way since you suggested ensuring that the change should have no “negative effects on ALL users of the integration”, which of course is a physical impossibility as one can’t prove a negative. I’m sure there are obscure cases or old devices which may require certain settings, that’s why I was requesting to make the interval configurable in the first place – to allow each user to set it to their preferred value.

Given that we have a perfectly functioning workaround with the automation, I don’t think it’s worth bothering the maintainers with a PR, though if that stops working in the future or perhaps we get to a point where older devices won’t be supported any more, it may come back in focus.

1 Like