I have been using my GDO blaQ openers now for about a year for my LiftMaster 8500 openers. I have them connected to Hubitat and displayed using Sharptools. I am using the Konnected drivers in Hubitat:
I have been encountering issues with my openers ‘randomly’ getting set to a Locked status which then disables remotes. More recently I have been unable to open my garage doors from Sharptools. I have been attempting to diagnose the issue and have managed to capture some of the behaviour.
When I initiate an open or close from the Konnected app or Hubitat things seem to work fine. However, when I start from an UNLOCKED status and attempt to open the garage door from Sharptools I am getting this. So the door is not opening and is getting set to LOCKED.
Another piece of information is that I do not have the locks authorised from Sharptools, so there shouldn't be any lock or unlock commands coming from Sharptools.
Here is the side by side comparing the Open Command initiated from Hubitat vs. Sharptools
@josh Has something changed recently around the interaction with Konnected or the lock and unlock capabilities? Any insight would be appreciated as currently I am unable to open/close these GDO blaQ garage doors using Sharptools.
No, the general Thing tile always uses a concept of prioritizing attributes for determine which underlying command to send when a virtual toggle() command is issued. The only device I’ve ever seen which has both lock and door control capabilities is this Konnected device and the toggle command treats the lock attribute as higher priority. It’s on my hit list to see if there’s a way to pass the inferred capability forward from the explicit tile layout so it knows to ignore the lock and toggle the door control instead, but in the meantime if there’s a child device from this driver that just has the door control capability you could use that and avoid the toggle ambiguity.
Based upon your comment I tried switching the tile layout from a Door Control Tile to Hero Attribute. That way I thought that I could isolate which attribute was called. When I did that and then edited the tile it defaults to show lock as the primary attribute which aligns with your comment.
There are a whopping 18 Hero attributes available. I tried switching the tile to any of the relevant hero attributes as primary attribute (only primary attribute was set) including door, switch, and motor. Unfortunately that did not work, they are all sending through lock commands even though lock is not one of the Hero attributes. Results in Konnected were all relatively the same as the original door control tile. Here are logs when set to the Door Hero attribute.
Not sure what else I could do in an attempt to work around this? What is also interesting here is that I have been using Sharptools-Hubitat-Konnected for months to control these doors with minimal issues...until now.
But critically, there is not a child device that only has the Door Control capability on it. So from what I understand, you are likely still using the parent GDO blaQ Garage Small parent device which I suspect has both the lock and doorControl capabilities on it among others.
Unfortunately, that wouldn't work. What I meant is that when you use the Generic Thing Tile (which is what's used for both the Lock and Door Control capabilities), it sends a virtual toggle() command to the SharpTools Hubitat app.
The virtual toggle() command is interpreted on the hub by seeing which attributes the device has and determining the relevant real command to send based on the first attribute it finds in an order like: light=on/off, lock=lock/unlock, door=open/close
All that being said, I pushed an update out to beta intended to resolve this. Feel free to reach out to me on the SharpTools community and I can get you added to the beta.
