Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add cache for box feature set #36

Open
IgelCampus opened this issue Mar 9, 2020 · 6 comments
Open

Add cache for box feature set #36

IgelCampus opened this issue Mar 9, 2020 · 6 comments

Comments

@IgelCampus
Copy link

I am monitoring a remote fritzbox with several Fritz!DECT200 and 301 devices.
The monitoring software (munin) runs every 5 minutes and starts ~12 scripts. Each script uses fritzconnection to connect to the remote box and extracts a single value. Because fritzconnection starts from scratch on every call it has to download all the xml files before the actual call can be executed. In my setup getting the xml descriptions takes ~25 seconds and then another second for the call to request the wanted information.

I therefore propose the introduction of a file-based cache for the given address, maybe by adding another parameter cacheDir which must point to an existing directory where a sub-directory for each ip-address is created which contains the xml files as downloaded on the first run.

@kbr
Copy link
Owner

kbr commented Mar 14, 2020

The API of a fritzbox can differ from model to model and can also change after a software update. That leads to the situation, that for a configuration-cache validation the configuration must be read – so the configuration has to be read anyway. However, it may be possible to cache the scpd-files. May be I can go into this for one of the next versions.

@IgelCampus
Copy link
Author

You could also auto-refresh after either hard-coded 24h or when another optional parameter value is exceeded. In addition, even when the firmware gets an update i am not aware that AVM ever removed a feature so in worst-case you might have one feature not available until the cache timeout kicks in.
And even this is only theoretical as the caller must explicitly change his code to use the new feature and would probably also disable or simply clear the cache while working on the code.

@jedie
Copy link

jedie commented Apr 1, 2022

If the cache "key" is a combination of device name and version and the auth data, then it's always up-to-date, isn't it?

@kbr
Copy link
Owner

kbr commented Apr 2, 2022

Yes, it would be up to date. But to get the device name and version to build the key one have to read this information first from the box – unfortunately these are part the data to cache. Also it is recommended by AVM to inspect the API first before doing any action. However, a kind of cache could be optional and at own risk. But the problem of "own risk" is, that people often don't realise this and blame others. In case of a cache feature I'm sure this will happen sooner or later.

@jedie
Copy link

jedie commented Apr 2, 2022

Okay sounds that's a bad idea to add caching.

@kbr
Copy link
Owner

kbr commented Jul 23, 2022

Found a way for proper caching – at least I think so. Will merge this to the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants