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.
@nate I posted on the Konnected community as well but I'm not sure where is the best place to reach out. Did you ever get anywhere with adding an info logging toggle? I recently updated the firmware on my blaQ GDO and it now reports the door status every 5 minutes. Any info would be greatly appreciated!
I had the same issue as you but when I turned off textlogging it stopped.
As you originally stated and as others have it might be nice to be able to completly turn off logging with an additional toggle. Not sure if @nate is looking into this or not.
Is it possible to tame the logging? I agree with the others above, there is a flood of logs for these devices every time you open, close, have motion events, and so on.
It makes it hard to use the Hubitat logs when one device (this one) overwhelms every other log entry due to the sheer volume of these unnecessary logs. For example, if I am trying to log a Rule Machine rule, the logs of the Konnected GDO over the course of a day will have so many events logged that the Rule Machine log no longer exists due to it being pushed off the bottom of the logs whereby the Hubitat hub prunes the logs.
I love this device, and it all works perfectly, but the logs are one negative thing that people have repeatedly requested to be improved. I hope something can be done to fix this.
Please clarify what we're trying to accomplish here -- do you want the device to emit fewer logs, or you want Hubitat to ignore more of them?
By default Hubitat subscribes to INFO level logs from the device. There is a toggle in each device preferences that can enable DEBUG level logging. I suppose we could alter that to only subscribe to WARN or ERROR level.
As a quick fix, go in to Libraries Code > espHomeApiHelper and change lines 238-239 from:
This illustrates the issue. This is one days worth of logs, and this is at 50% scaling. I want to not have these, or the ability to dampen down the amount.
But that edit gives a different logging issue. I now get these every time there is some door action, whether it is motion, opening the door, or whatever else. I don't want to see info logs at all.
That is a good question. IMHO the devices themselves seem 'chatty' to me - maybe this is normal for ESPHome devices (these are my first) - but curious if the chatter impacts LAN traffic.
Does changing the "subscription" to the logs impact how Hubitat responds to GDO actions? i.e. open, close, % are all info level logs - will Hubitat still know the GDO status if we unsubscribe to the logs? I suspect those lines only impact what HE is putting in HE logs - but I am not sure.
The latest firemware update some how has caused status to be reported every 5 minutes. I just upgrade today and you can see that it started after the update. Here is the log
