Setting timeout fritzaha

[GoogleCodeExporter]

1. Feature Description
My raspberry pi is a little slow on running all requests against the fritzbox. 
The result is a bucket of the following loglines:

16:28:12.362 WARN  o.e.jetty.client.HttpExchange[:1013] - EXPIRED 
FritzahaContentExchange@596378=GET//192.168.1.1:80/webservices/homeautoswitch.lu
a?switchcmd=getswitchstate&ain=XXX&sid=XXX#WAITING(3977ms)->EXPIRED(0ms)sent=397
8ms

It would be nice to have a feature to increase the timeout

2. Example Use Case
Slow networks, slow openhab-instances

Original issue reported on code.google.com by markus.b...@gmail.com on 21 Sep 2013 at 2:30

[GoogleCodeExporter]

Actually, it is neither the Pi nor the network that is choking it down like 
that - it is most likely the Fritz!Box itself. How many switches are you 
controlling? How many meters are you reading, and what kind?

Unfortunately, I do not have the development resources from university at hand 
right now, but I will try to see that the timeout increases with a larger 
refresh interval in the future. Increasing the timeout without increasing the 
refresh interval will do nothing, as it would just lead to an accumulation of 
dying requests.

---Christian

Original comment by pgsh.tudo on 27 Sep 2013 at 12:31

[GoogleCodeExporter]

Hi,

i've checked out the code last week, set a higher timeout and it works 
flawlessly. I will resolve this issue soon by pulling the source to the git 
repo.

Markus

Original comment by markus.b...@gmail.com on 27 Sep 2013 at 5:19

[GoogleCodeExporter]

Any news here ? I still suffer from timeouts between 3-5 seconds. The refresh 
interval is actually 60 seconds. I'm monitoring 4 x DCT200, reading the energy 
of 2.
Running build #515.

Thomas

Original comment by thomas.s...@gmail.com on 28 Oct 2013 at 2:03

[GoogleCodeExporter]

Hi Thomas,

my codechanges are ready for merging. They need to be approved by one of the 
main distributors.

Greetings,
Markus

Original comment by markus.b...@gmail.com on 29 Oct 2013 at 7:02

[GoogleCodeExporter]

My code changes for the issue are also done and tested, although I still need 
to upload them to the web. They use the approach I have outlined above, 
matching the timing to the refresh interval, requiring less specific 
configuration while achieving the maximum sensible (i.e. stable) timeout. 
Perhaps we could merge our efforts to provide your configuration options while 
keeping the default optimized?

Christian

Original comment by pgsh.tudo on 29 Oct 2013 at 1:31

[GoogleCodeExporter]

Hi,

you can see my changes on github: https://github.com/openhab/openhab/pull/60

I've got a Fritz!box with several Dect-200 and a single "Fritz 546"-Powerline 
and I only need the higher timeouts on the Fritz!box socket outlets.

A timeout = refresh interval could possible lead to concurrent requests for the 
same device.

Markus

Original comment by markus.b...@gmail.com on 29 Oct 2013 at 2:36

[GoogleCodeExporter]

> "A timeout = refresh interval could possible lead to concurrent requests for 
the same device."
Actually the idea behind that is precisely to prevent those. My code sets the 
timeout to be slightly (margin defined in the code) less than the refresh 
interval, so if the processing time varies on a sufficiently small scale, no 
concurrent requests should occur.
Actually, I would really prefer per-device (or just per-host) refresh 
intervals, but that would require modifications to the binding service 
structure that would probably be too invasive for me to be confident in its 
reliability.

Christian

Original comment by pgsh.tudo on 29 Oct 2013 at 3:26

[GoogleCodeExporter]

Christian,

Not sure if I am up to date on this issue - are you still working on preparing 
another pull request and we should NOT merge pr #60 at the moment? As far as I 
can see, pr #60 only introduces configurable timeout, so it does not seem to do 
any harm. Yet, I will wait for your feedback on this.

Original comment by kai.openhab on 3 Nov 2013 at 8:17

• Changed state: Started

[GoogleCodeExporter]

If you pull this I could do the merge on my end (which would involve adding 
some additional flags to the WebInterface config). Since I do not have the 
equipment necessary to test my changes at home it would make sense to pull what 
is already available, since I will probably be making progress rather slowly, 
if at all, in the near future.

Christian

Original comment by pgsh.tudo on 5 Nov 2013 at 1:33

[GoogleCodeExporter]

Original comment by teichsta on 5 Nov 2013 at 10:53

• Added labels: To-Github

[GoogleCodeExporter]

Ok, I have merged it! I leave this issue open and assigned to you.

Original comment by kai.openhab on 7 Nov 2013 at 8:51

[GoogleCodeExporter]

This issue has been migrated to Github. If this issue id is greater than103 its 
id has been preserved on Github. You can open your issue by calling the URL 
https://github.com/openhab/openhab/issues/<issueid>. Issues with ids less or 
equal 103 new ids were created.

Original comment by teichsta on 17 Nov 2013 at 8:08

• Added labels: Migrated-To-Github

[GoogleCodeExporter]

Set status to "invalid" to show that these issues are not tracked here anymore 
- please refer to GitHub instead!

Original comment by kai.openhab on 2 Dec 2013 at 7:12

• Changed state: Invalid