Work around a 'stuck' legacy Eagle by sending a get_historical_data …

[toddsay]

…request and adding a delay, with logging

Notes: When the legacy Eagle returns a 503 response with text "Timeout waiting for response", through trial-and-error I discovered that it is possible to get things running again by sending the get_historical_data request to the cgi_manager endpoint (as used by the web interface). After sending this request and waiting several seconds, the requests used by this client will typically begin working again. This change automates that workaround process.

[gtdiehl]

Would increasing the polling time in Home Assistant resolve the problem? Or would it just delay the problem from occurring to a later date?

Adding scan_interval to the configuration.yaml for my Eagle-200 I'm able to increase the polling period from the default of 30 seconds.

sensor:
  - platform: rainforest_eagle
    ip_address: !secret eagle200_ip_addr
    cloud_id: !secret eagle_cloud_id
    install_code: !secret eagle_install_code
    scan_interval: 120

[toddsay]

@gtdiehl I can give that a try and report back. Currently I'm using a scan_interval of 30 (which is what the code is throttling to anyway). I'll try 120 and see if the code is still logging these workarounds.

[toddsay]

@gtdiehl I can confirm that the hang/timeout still occurs for me with a scan_interval of 120. It doesn't seem to be caused by the frequency of calls, but it does seem like the integration contributes to the problem somehow (likely an underlying Legacy Eagle bug, for this out-of-support hardware and firmware).

What I don't know, and would like to confirm, is whether the behavior I see from my Eagle device is common to most other Legacy Eagle users.

[jcalbert]

iirc I saw this problem before integrating with homeassistant. I've had the API freeze in less than a day when testing and sending a lot of requests. Not sure if it's a cumulative or probabilistic effect.

My guess is that it'll be hard to diagnose without getting shell access† to the device and the easiest thing is to just use this workaround in the integration.

†An Amazon reviewer claims to have brute forced the root password, but afaik hasn't disclosed it or the process anywhere.

[toddsay]

Yep, I noticed that Amazon review as well, regarding the poor security and brute-forceable password. As well as some comments about the API locking up after a few days.

Currently the API stops working for me about 2 times per day, with this logic recovering access automatically. With this in place its been probably 2-3 months since I last rebooted it (the first several weeks was me experimenting with different combinations of API requests each time it hung, after realizing that using the web interface could make it start responding again).

The delay between the get_historical_data request and the recovery makes me think that a process is getting restarted, but as you said it's hard to really know what's going on there without shell access. I've asked support if there is a way I can log in to fix their known "read only filesystem" condition myself (another common problem), but they wouldn't provide that access. I suspect they're employing security by obscurity there, hanging on to some master password. It's all rather disconcerting, especially with that backdoor feature where they can connect remotely (which I've disabled on mine, but of course that's taking the word of their UI).

[estebanpapp]

Can we get this change in? I am also suffering the same nonsense