Zones reporting status repeaditly even though they didn't change

Konnected Alarm Panels
1

Hello,

I have two 12 port Alarm Panel Pros and two Garage door opener blaq’s. I’m seeing a issue in Hubitat where a zone is opened, the message comes across as zone open, but then a few minutes later another open zone message is sent even though the zone never closed. The board should only be sending zone messages when there is a change, not re-sending zone status at random times. How can I fix this?

2

Hello all, really trying to like the Konnected products but the issue list keeps growing. Besides the issue with the Pro’s repeating zone status over and over even though the zone state didn’t change they also are randomly dropping off the network (hardwired) and the only way to fix them is a power cycle. Add that to the blaq’s causing the garage doors to go into a lock state ignoring remote controls and I’m 0 for 3 here. Is there a way to contact Konnected support directly?

3

You can contact Konnected support at help@konnected.io or via support.konnected.io, but I’m also happy to answer questions and help debug here in the public forum because it helps other people.

We would need more information to diagnose the issue with the Alarm Panel Pro repeatedly sending state and/or dropping off the network. It sounds like it may be in a reboot cycle, because every time it reboots it will re-send every sensor state. You can post some logs here and I will take a look at it.

For the GDO blaQ issue – it sounds like you are executing the “lock” function on the Chamberlain/LiftMaster which by design locks out the remotes. This is the same as pressing the LOCK button on the wall control. The intent of this feature is to lock out the remote controls to secure your garage overnight or when on vacation. Maybe you have an automation in Hubitat that is locking all locks, and you are unintentionally locking the garage doors as well. I will not ever do this on its own.

4

Thanks Nate. Issues below:

  1. blaQ causes lock condition is related to Hubitat and Sharptools. See this thread for details. Basically if you use Sharptools to open or close the garage door it for some reason causes the blaQ to send a “lock” to the garage door.

  1. I have two pro’s and they both drop off the network and do not reconnect. The network sees the port active but not connected. They are both plugged into a Unifi POE switch but powered by local power supplies. The only way to get them to reconnect to the network is a power cycle. I’ll take a picture of the devices next time it happens to see LED states.

  2. Pro keeps sending zone status even though it doesn’t change. I see it in the Hubitat logs for all devices but only if they are in a open state. If the device closes, one message comes across and comms are idle until a open occurs and a message is sent. Then randomly, usually around 3 or 4 minutes the open message comes again, and on and on. I know this because I use a chime function to tell us when a door opens. This works great unless you leave a door open and it will then chime randomly all day long. I’ll try to attach some logging.

5

I have no idea why Sharptools would have anything to do with it or why it would be sending a lock command. There’s nothing in our GDO blaQ driver for Hubitat that would automatically send a lock command in conjunction with the door open command. I think you might have to loop in the Sharptools guys to help figure this out. From that log in the other thread that you just linked, it does look like something is sending that lock command but I don’t see where it was coming from. I do remember looking into that issue that @cgullett reported but I was unable to reproduce it and we stopped hearing from him on the issue.

On the Pros – are they running the newer ESPHome firmware or the legacy Konnected firmware? I would recommend updating to the newer ESPHome firmware and Hubitat integration, which uses the same ESPHome library as the GDO blaQ which is faster, more stable, and more flexible. This will require you to update all of your automations though, because it will re-create all of the Zones in Hubitat.

6

Yes, sounds like the exact same issue. SharpTools, I believe, gave me a workaround that has performed flawlessly. I’m trying to find the original info. It involves creating SharpTools rules.

7

I cannot find the original info - I believe it was a support item and not a community post. Here are screenshots of the SharpTools rule they suggested.

IMG_3250
IMG_32501290×2796 196 KB

IMG_3251
IMG_32511290×2796 174 KB

IMG_3252
IMG_32521290×2796 227 KB

IMG_3253
IMG_32531290×2796 230 KB

8

I don’t understand this at all. Why would you need to add additional rules? Why would sharptools be controlling the lock/unlock anyway?

9

I wish I could remember. The issue occurs in Sharptools, not if you are controlling the door directly in Hubitat. The rules are a workaround to take a bad? misinterpreted? variable and change it. The issue only occurs when controlling the door in Sharptools. I’ll see if I can find some of the emails that I exchanged.

10

Found them…

Last of a long exchange with Josh at Sharptools. The workaround involved a rule and proper configuration of the Sharptools tile. Hope this helps.

I suspect the issue is related to it being a single device with switch, lock , doorControl and other capabilities (rather than child devices). And when used with the Door Control Tile, it’s actually using a generic ‘Thing’ tile layout under the hood and it’s calling a virtual toggle() command under the hood that’s likely toggling multiple capabilities.

I’ll take a look at what options we have to improve that in the tile. In the meantime, you have a few options:

  • Create a rule that will send the appropriate open() or close() command based on the current door status

  • If there’s a different driver that either has just the Door Control capability or uses child devices which each have only the capabilities they control individually (Lock, Switch, Door Control), that would solve the issue as well

11

Interesting. Thank you for reposting that @cgullett. That makes sense given the explanation of how the tile works.

The 2nd workaround listed here, using child devices, may just work. There should be a preference option in the GDO blaQ device called “Enable Child Devices?”. Enable that and then it should create a child device with only a single capability that you can then use on your Sharptools dashboard without issue.

Lmk how that works out.

12

Thank you all for the suggestions. I’ve been slammed with work and snow so haven’t been able to do much but didn’t want to ghost you guys after you so quickly offered some ideas. I’ll report back shortly.