I updated to HE 2.2.5.120 and have a few problems. This is a bug report that the Rachio Integration is broken. When I launch the Rachio Integration app, it reports "There isn't any Rachio Controllers available for Hubitat to control."
I can certainly delete the integration, because I don't actually use it, but figured I would wait for support to address this in case you need me to confirm the system and handle the migration from the old app to the new app correctly.
Notice in the settings for the Rachio Integration, the app switched from using "userName" which I have set, to using "userId" which is not set. I would expect the new app to migrate the settings and state values to the new ones, and to clean-up the old values after migration. This does not appear to have happened. To further complicate the issue, there is no way to re-enter credentials, and re-associate the app to my account.
I updated to 120, I did not update to 119. I don’t know at what point it was, but as of this release, the j refraction uses userId, but in a prior version it used userName for the Rachio login. I understand yours is working. It these posts completely dismiss the facts, which is that is the applications settings page, I see an empty userId and a populated userName, which coincides with the log entry that the userId cannot be obtained. When changing a driver, it makes sense to allow the older state and settings, but at some point the old ones need to be retired. When this occurs, the new ones should already be populated.
This is not a request from the community to help me solve my issue. I know how to solve it — I just need to delete the app and reinstall. This is a report so the staff can see they broke the system for people that used the integration since an older version and a request for them to fix the broken app by implementing the following:
a feature to auto-migrate outdated settings to the new ones
add the ability to re-define the authentication credentials for a failed authentication, rather than locking out app completely.
If i use the child devices for rules or 3rd party integrations, the. They would all break and have to be reconfigured because the new app install would create a new app IF and this. We device IDs.
It's a built-in driver. We have no control over the built-in drivers. Since it is built-in, the fix must come from Hubitat. I have had the driver for a very long time, and it has been working until now. obviously the easy fix is to delete the app, and reinstall, but that breaks all integrations, rules, etc, as the drivers are components of the integration app, where the problem is.
what about adding the app again.. configuring the device.. then removing or changing the id of the old and new controller device and or zones with the "edit " button to duplicate the old ids..
yeah. that's my trick I have been doing for a while now with migrations, and updating of devices. This is not reported so I can have my devices fixed. I am not impacted by it. It is reported because it was discovered, and should be fixed. I don't have integrations, rules, etc for these device. for me, they are just informational. But if the issue affects me, it is likely to affect others.
Actually, that wouldn't work. The app id and device id are different than the device network id. The device network id can be edited, but these devices would physically get replaced.
I am trying to help, but whatever. If no body cares, I have deleted and re-added the app and now it is working.
This refusal to acknowledge the flaws in your code is just beyond ridiculous. Just look at the very first screen. Are you telling me, that it is by-design that once you authenticate with the service, if anything should happen to break the authentication, that it is okay to have to Remove and re-install the app? that the only button in the app should be "Remove" ?
I understand you are all busy fixing the numerous bugs introduced by the update (3 releases now in less than 24 hours). But flat out dismissing the flaws because it is inconvenient is troubling.
That’s fine. Like I said it worked before and it works now that I removed and re-added it. I only use the sprinkler controls for monitoring, so it doesn’t really affect me to have to remove and re-add. It may in the future, considering We are unable to re-configure authentication in the app, but for now, I was just trying get the issue looked at.
Have you attempted a soft reset and a database restore? FWIW, this is the first report of any issues with Rachio with 2.3.6.x, and there are plenty of Rachio users here.
Technically, it wouldn’t be the first if he is a me too case. It could be as simple as we changed our password. Then when the auth token expires, how do we re-enter our new credentials? It should be a simple lightbulb moment to realize there is no mechanism to re-authenticate and maybe it should be added for when the authentication fails.
That was the only reason for my initial post.
I don’t understand all the friction to this very simple observation. Nobody is pointing fingers, just expressing an observation.
Did this happen to your hub also after updating to 2.3.6? If that’s the case, I agree that his observation wouldn’t be the first after updating to 2.3.6.
I didn't mean to imply a connection between the latest update and this issue. This was simply the version running when I noticed that my Hubitat had the same Rachio app loss as the OP.
My resolution was to remove and re-install the app as noted, then go in and reconnect any broken device references in other apps.
That said, I will note that the logs held quite a few of these entries PRIOR, which is what triggered my investigation in the first place: pollChildren cannot update children because it is missing the required parameters
No idea if that will help anyone beyond a future search. Anyway thanks for responding.
