Hi @JustinL, I think you got it. I still see the error (understood until the API reset) but the logs have now been consistently polling at 5min intervals, which is my current poll rate. Previously it was hitting the API at least every minute with some at 20sec intervals, too. It's looked a lot more stable.
1 Like
When I try to start a zone, (clicking on or open in the admin UI) I get the following error in the logs: groovy.lang.MissingPropertyException: No such property: open for class: java.lang.Integer on line 848 (method startZone)
Thanks
To help with this, I need the actual log (screenshot please), with debug logging set to level 3. I can't tell if that output is from the app, which device, etc. Also, what version of the app did you experience this with? And are there any other errors in the log?
1 Like
Right on time the hose controller issues disappeared.
Thanks again for your continued support.
1 Like
@JustinL , I noticed a small thing. If the daily counts in this app are supposed to be reset at UTC 00:00, Is this reading normal?
Previously you indicated that if either closed or open reached 1700 we could have problems.
No, I'm actually looking at that right now. There's a small bug in resetting that count in state. Will get it fixed.
Thanks for all your work on this.
2 Small requests
I know it's available in the app but, in the log message that contains this ...Polling API for Latest Data -- Last Update was (55.804 seconds ago)...
Can you please add the current daily API count value? This way it would easier to monitor the calls.
When using a dual poll rate (normal and when running) is there a way to start the fast poll with the last poll before the program starts running rather than waiting for first poll after the program starts? I have a 15min / 1min poll setup and it's obviously a timing thing but, as you know, you can catch the start of the program run or miss the first 14-15min cause the last poll just happened to be right before the event started. This, thanks to Murphy's Law, is what I'm seeing, I miss the first 14 minutes of the program run.
Thanks again!
Yup, good suggestion.
Are you referring to irrigation controllers or hose timers? Which one are you having this issue with? The irrigation controllers should pick up right away since it has webhooks. The hose timers don't have webhooks so this could occur with them until Rachio obliges everyone's requests for webhooks.
Yes, the hose timer. The polling has been dead nuts since your last update, which is great. But any polling system, as you're aware, will always suffer from a timing issue. I was wondering if itd be possible to look ahead at the next program run time, compare that to the current time and the current poll rate and switch to the fast poll then instead of waiting to see that actual program running. Because worst case, which is always the case :), you could end up missing the first chunk of the program run until the slow poll catches up.
Thanks again
The way I believe best to handle this is to simply schedule a poll to occur 1 minute after the program is scheduled to run. That will pick up the run and start the fast polling. I'll include this in the next release, unless you see a reason why that approach would not work well.
Sure, thats fine, whatever is easier.
Thanks!
@JustinL is it possible to have the combination of no polling/extra polling during a schedule? In otherwords, polling only when a schedule is running. I tried setting that up with extra polling every minute for hose timers, but no polling otherwise. if I cancelled a run using the Rachio app the RM dashboared never updated.
It isn't uncommon for me to use one of my hose timers to address a particular dry spot in my lawn, which means the run isn't schedued. I walk outside, see it is try and run a hose sprinkler for a few minutes on that spot. This is a different situation from what @wecoyote5 is describing above, where he is dealing with a schedule previously set up in the Rachio app.
Thanks for your work on this.
No, this is not possible yet with the hose timers, only the irrigation controllers. Because Rachio implements webhooks for the irrigation controllers, Rachio pushes updates to Hubitat when events occur. This means that Hubitat is notified when you use the Rachio app to do things, without having to poll Rachio servers to check. However, Rachio does not (yet) implement webhooks for hose timers, so Rachio is not pushing any updates to Hubitat when events occur. Rather, Hubitat has to periodically poll for updates. So, for hose timers, when you cancel a run using the Rachio app, the only way Hubitat fnds out about that is periodic polling. In other words, you have to have periodic polling in order to get hose timer events that occur from the Rachio app. If you do everything from the Hubitat side (like cancel a run from Hubitat), then Hubitat re-polls on its own at that point.
Makes sense. Thanks.
Latest version released implements your requests (with the second request implemented as scheduling a poll to occur 1 minute after a scheduled hose timer run, whereupon your extra polling during a run will pick up)
Wow! Great, thank you. I'll get it loaded when I'm back home after work.
So far, so good! Thanks again.
1 Like
Hi @JustinL, I've been monitoring and unfortunately it doesn't look like the fast poll starts as expected. I'm still seeing ~15min before the actual valve opening and the first report of that event. Once the event is detected then it goes to the fast poll. Is there anything I can look at/do to help?
Thanks
Look at the settings page for the Rachio Community app to see what methods are scheduled to occur. You should see an event scheduled for one minute after the next scheduled run.
I looked through the setting screen and I only see this, nothing that would indicate an app event tomorrow morning at 6:01. The next action is tomorrow at 6 am.
