What is the official repository for this driver? I’m using Callaway.smartthings.com
The link is in the original first post.
I get a 404 error when trying to navigate to callaway.smartthings.com
The link is in the very first post, and here:
When I go to add the GitHub repo, it says I’m already enrolled then the ademco driver is already enrolled.
my.smartthings.com say I’m using the driver:
Alarm pad driver says:
Which is the philh30 GitHub account.
Which hasn’t been updated in two years.
Right, “calloway" is just part of the url, and correct, the driver hasn’t been updated in2 years. The original developer is no longer on SmartThings and no longer supporting this driver.
So is there a newer driver?
Nope, this is the current and only driver available.
@Itati and @Zach_Varberg and @Cory_Heuschkel ,
Did ST push out a fix within the last 24 hours, or even just recently? Things seem to be working again:
Yes we did! Glad to have confirmation. This was just a lua library update for edge drivers so does not require a full firmware release. For now this has just been rolled out to hubs that have installed one of the impacted drivers, but will be rolled out to other hubs over time, but we wanted to fix hubs we knew were impacted first.
Thank you!
Has the lua library been pushed to all the impacted hubs or is the updated library still being pushed. I’m asking because I am still encountering the issue. Thanks
Thank you. Mine is working again. Merry Christmas
Thank you so much my sensors seem to be working in the alarm status is reported correctly now.
In general I was just curious what happened. That is why did a library that was working stop working and need to be fixed? Some unintended interaction?
Hi @jonj , if you look at the release notes for the latest hub firmware update, you’ll see the following change that impacted us. It was intended to optimize memory on our hubs:
- Remove device event state cache from lua. Instead if
get_latest_stateis called the value will be loaded from the hub, and after that point will continue to cache events generated from the driver, but only for values that have been requested viaget_latest_state
To add some context, the affected drivers here were not using get_latest_state to access the device state, but instead directly indexing into the underlying tables. Which isn’t the recommended way to access it, and none of the official drivers use that access method, and none of our beta users used a driver that uses that method so it was missed. The test gap has been fixed, but we would still recommend any driver developers switch to using get_latest_state as it is more efficient than this method both in terms of memory use and cpu usage.
Hi, I’m having issues connecting again. It seems similar to the last time this happened in December. Is anyone else experiencing this?