kbr / fritzconnection

Python-Tool to communicate with the AVM Fritz!Box by the TR-064 protocol and the AHA-HTTP-Interface
MIT License
304 stars 59 forks source link

Add cache for box feature set #36

Open IgelCampus opened 4 years ago

IgelCampus commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

kbr commented 1 year ago

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