Huge Thank you to @bdraco for all the effort that has gone into this
I just updated HA to 2024.8.3 and re-added the Augustus / Yale Home integration (as I removed to during troubleshooting) and authenticated and received a verification code as expected.
I had an August custom integration I didn’t know of. When I deleted it and set up the default integration everything is working again.
I used to “Wake” the API every 10 minutes since this is the only way to see if the door have been locked/unlocked manually, but I guess this is what created this whole mess. Is it OK if we do this once every hour, or should it be avoided completely?
I used to “Wake” the API every 10 minutes since this is the only way to see if the door have been locked/unlocked manually, but I guess this is what created this whole mess. Is it OK if we do this once every hour, or should it be avoided completely?
Please don’t automate wake calls as that’s what helped get us in trouble in the first place. Once the new integration is available it won’t be needed anymore.
In a similar situation, need to try and keep track of the door lock status, as I’ve setup some dependant automations around motion detection from the Ring Door bell.
If the door is unlocked don’t send Ring motion notifications until the door is locked again, however with the door never reporting back on an Auto-Lock I resorted to the “wake button” work-around. Only sending the “Wake” after I expect the door to be closed and Auto Locked after 3 Minutes.
However, that now doesn’t seem to work at all, sending even single “wake” command to the lock doesn’t invoke a status update. Also noticed the “wake command” is now rate limited to 2 command in 30 Minutes.
I’ll come up with a other way to do this, with the lock not updating, the ring motion detection remains off for long periods, until I notice the door status show as unlocked while it is physically locked.
The fact that it works again is amazing, just need to problem solve in a different way not to impact overall operation / integration
“With great power comes great responsibility” (Spiderman) seems to apply here… HA gives us great power, but it is also up to us not to abuse 3rd party APIs. I am in the camp of avoiding cloud products like the plague unless local control is possible, but if that is not an option then it would be great to know what limits there are to prevent HA users from inadvertently DDoSing vendor clouds. In other words, basic guidelines on what not to do such as reloading integrations too frequently, polling in short intervals, flooding with commands, etc.
I’ve updated HA core and OS, I’ve gone to add integration and can now see on that says Yale smart living, is this the new intergration for Yale home users? I have tried to use it and entered U/N and pass but it too fails with authentication, am I doing something wrong?
The new integration is available in beta: 2024.9.0b0. The new integration uses the new WebSocket APIs which provide updates continuously so there is no need to reload or wake the locks anymore.
For Yale Home users, to migrate, add the new yale integration, and remove the old august integration.
For August/Yale Access users, continue to use the august integration.
Please report any issues with the new integration using the normal beta channels for the next week. Releases - Home Assistant. After it makes it to release, please report any issues to GitHub issues.
Great thanks for all your hard work, I have it installed chosing Yale, then Yale Home, yet it still shows as August in the devices is this correct, and I have this now
Failed setup, will retry: Rate limited, try again in 22 minutes
The new Yale integration is functioning well and is quite fast, but I’ve noticed a bug. I have both the Unity Front Door Lock and the Unity Security Screen Door Lock, and they are linked together. The issue is that when you lock or unlock one of these locks, the other one follows suit, but the status of the second lock isn’t updated in Home Assistant. To refresh the status, you have to open the Yale Home app and check the associated lock. As a result, even if both locks are actually in the same state, one may show as locked while the other shows as unlocked.
We currently don’t support the Unity line in the integration. See supported devices at Yale - Home Assistant. It will likely partially work, but nobody who works on the integration lives in the AU market so that we can support these devices properly.
The new API Yale provided may map only some device functionality for the Unity locks, and they might start working better over time. If you open a GitHub issue with diagnostics and debug logging turned on when you trigger the issue (Troubleshooting your configuration - Home Assistant), we may be able to find enough information to know what to ask them for.