408 Request Timeout Errors

[spud]

FYI, I implemented local polling for the Legacy Eagle, see this thread.

[automateme]

Yes, it has been solid, has not missed a beat and never had a timeout. I have the poll at 30 seconds too.

I saw the same issue on my Legacy Eagle with the blinking cloud LED.

I can confirm. I swapped out my Legacy Eagle for an Eagle 200 a couple of days ago, and so far - rock solid and no timeouts.

One observation about the -200, the Zigbee radio doesn't seem as powerful. My -100 Eagle was installed about 80 feet from my meter, and connected without issue. The -200 would not work in the same location, and I had to move it to within about 30 feet of the meter in a spare bedroom. I don't have a LAN connection in that room, but fortunately the -200 has WiFi, so I am good to go. I will keep monitoring and report back if I encounter any issues.

Edit: Just to update, I am seeing a couple of (504) Gateway Timeouts today with the -200 Eagle. No (408) Timeouts though.

[Kitar]

I am also noticing 408 timeouts on a Eagle Legacy-100

The plugin itself does not give any indication that there is a problem. It would be nice if we could test for this in an event and create some kind of alert that the data has not been received for XXX seconds.

Looking at the Plug-In management page everything looks good, no indication of any sort of failure. The PI management page should at least turn the icon amber if the PI is not receiving the data.

Aside from these minor things I think the PI looks pretty good.

spud, I've noticed that if my web browser is open and has one tab pointed at Rainforest's portal then there are no 408 errors. As soon as the browser is left to go idle and the PC sleeps the 408s return... Oddly my browser is not even on the same PC as the HS installation and plugins, but it is on the same subnet. Put another way: I get 408s every 100 seconds, which is what the timeout value is set to, but as soon as I open my browser with a background tab pointed at this URL the 408s disappear. It does not matter if the Rainforest tab is the active window.
PI ver. 3.0.0.4

https://rainforestcloud.com/rainforest/user_portal/php/main.php?view=gateway_gui&cloud_id=xxxxxx

I hope that helps somewhat. Aside from the 408 it seems to be a very tidy plug-in.

[automateme]

Yes, it has been solid, has not missed a beat and never had a timeout. I have the poll at 30 seconds too.

I saw the same issue on my Legacy Eagle with the blinking cloud LED.

Thanks! I think my utility has a $25 device rebate going now. Maybe I will pull the trigger on an upgrade.

[kevini]

Yes, it has been solid, has not missed a beat and never had a timeout. I have the poll at 30 seconds too.

I saw the same issue on my Legacy Eagle with the blinking cloud LED.

[automateme]

I've been running the plugin against my -200 since last week. Still rock solid no issues.

My own script worked for a month too with no issues.

The only stable ways with the legacy eagle is the local interface or the push. You can only push to one cloud at a time though, unlike the -200 which pushes the the rainforest cloud and then forks from there.

Is your -200 still doing well? No timeout issues? I changed my -100 back down to a poll time of 180 sec before I went to bed, and by morning I was getting tons of timeouts again. I looked at my Eagle device and the Cloud LED was blinking. I didn't think to check and see if local access was still working. I had to power-cycle the Eagle to get things working again. I set the poll back to 300 sec, and still get a dozen or so timeouts daily.

[spud]

FYI the RainforestEagle plugin is now in the store and updater

I'm still waiting a response from Rainforest about timeout issues and local API.

[Kitar]

I am also noticing 408 timeouts on a Eagle Legacy-100

The plugin itself does not give any indication that there is a problem. It would be nice if we could test for this in an event and create some kind of alert that the data has not been received for XXX seconds.

Looking at the Plug-In management page everything looks good, no indication of any sort of failure. The PI management page should at least turn the icon amber if the PI is not receiving the data.

Aside from these minor things I think the PI looks pretty good.

[automateme]

Thanks Spud. I downloaded the 3.0.0.3 update, deleted the old devices and restarted the plugin. The new devices were created in HS3, and the Eagle shows up in HSTouch Energy.

As skarragallagher mentioned, early word was that the local interface was eliminated from the -200 Eagle device. I hadn't even considered upgrading from the legacy device based on that. If Rainforest has changed that, it might be worth a look. I'm hopeful that Rainforest will get back with you though, and have a solution to the timeouts.

[spud]

I have asked Rainforest Automation about these timeout issues, as well as local API, but I did not get any response yet.

I have just released the beta version 3.0.0.3 that fix the problem of the Eagle not appearing in the HSTouch energy screen.
To make this work you will need to delete your current RainforestEagle devices, and then restart the plugin so that it recreates it.

[skarragallagher]

Well I got curious, and took a look at their documentation... It looks like they removed their local connection documentation for the legacy eagle:
https://rainforestautomation.com/support/developer/

I'll see if I downloaded a copy of it somewhere. They do have documentation though for the legacy eagle and using the "push method"

Interestingly enough it looks like the eagle-200 supports a local HTTP connection method and associated documentation. This has me interested enough to consider an upgrade to the 200 in the future. It would be awesome to have the 200 using the cloud api but having a secondary connection method in case the internet or cloud goes down, so you don't miss polling. In addition to this if possible getting the stored history in case of longer outages would be the holy grail!

[skarragallagher]

I fully agree and hope Spud can get either push or the local interface working... The issue that I have ran into seems to be common and because of the cloud. Personally I don't care if I have to use the push interface, as long the data is accurate and reliable. My personal feeling is that having a cloud option is nice however what happens when the internet goes down? Does the eagle-200 store the history and then fill in the missed the polls. I could be wrong but I don't think it does. Ultimately some error recovery or history ingestion would be ideal... I, and many others stayed away from the -200 because they pushed the cloud as the only method of connection I believe. There may be other local connections available now for the 200 but its been a long time since I've looked into it.

[automateme]

I hope that Spud is able to utilize the legacy Eagle local interface - to remove the dependence on the Rainforest Cloud. I’m polling at 300s now, and it has reduced the timeouts, but polling at 1 min would be preferred.

[kevini]

I've been running the plugin against my -200 since last week. Still rock solid no issues.

My own script worked for a month too with no issues.

The only stable ways with the legacy eagle is the local interface or the push. You can only push to one cloud at a time though, unlike the -200 which pushes the the rainforest cloud and then forks from there.

[DSteiNeuro]

With the legacy Rainforest Eagle I noticed with Spud's Plugin and the Python script that I wrote it seems to have a memory leak when you use the Cloud API. It is fine in the beginning and then slows down and you receive these timeout's. Even the local WebUI stops working.

This exactly describes the behavior that I am seeing. Funny that I didn't notice it before but maybe I never really looked.

I gave up using the Legacy Rainforest Eagle, bought a Eagle-200 and it has been rock solid. They changed the way the cloud API works, the Rainforest cloud always gets your data and then it sends it to other clouds. The API using the data in the cloud so it does not re-query the Eagle. The Eagle seems to hum away without issues.

I would be willing to give the Eagle-200 a try, if it resolves this issue.