That does not tell us anything useful. Can you get a screenshot of the full events page from a larger screen?
What device is controlling the door? What are these events from?
What we really need to see if the events leading up to the door opening, on the device actually controlling the door, some sort of relay I assume?
No, not really, they do not have any sort of premium support offered. I'm all you get
Personally, I have a scheduled power off to the opener at 10PM. I am pretty sure my garage door doesn't open in the middle of the night. If I get home late, I can always re-enable that outlet to open the door.
Looking at this, the command was not sent via HE. Is there any other way to trigger the door to open from the device? Is it integrated directly to anything else besides HE? If not, then the device opened the door on its own. Could be a wiring or config issues, no idea.
Basically same thing with your light, there are no on command being called from the hub or they would show in the events. The light is being turned on by some other direct integration (not through HE) or the device is malfunctioning and turning on by itself.
The garage door device was added last night around 2200 for the first time. Once I got it working, I left it as is and didn't install any configuration of rules etc.
The lights are also presenting bug-like features. Just randomly turns on in the middle of the day. They are sengled Zigbee bulbs. What could be telling them to turn them on? They have 2 rules. 1. turn on at sunset. 2. turn off at sunrise. I have a plethra of other bulbs and they don't do this. I have deleted the group. Other than resetting them, which is a pain.. I will try that.
I also have a request for Sharptools to see if they can see anything going on behind the scenes.
If sharptools or anything on the hub was sending commands to turn the devices on you would see it in the event log. If that event history is directly from the bulb device then it is malfunctioning and turning on by itself.
In your garage logs above, there was door/lock/light activity around 2200 -- were you doing that or was that all also uncommanded? If intentional, how were you sending those commands?
But to answer your question about whether or not such a thing is common or acceptable to live with, my answer would be no... If I had a device that was confirmed to be randomly actuating on its own, it would go straight in the trash. But devices truly defective like that are rare, so my money's on some other cause at this point.
Probably not relevant, but my garage door will open once in a while when it erroneously thinks I have arrived via the SmartThings arrival sensor in the car. It's usually the battery fading out-they're good for maybe 5, 6 weeks, but other loss of comms for whatever reason could cause it. I have a rule that says to close the garage door 5 minutes after arrival. Of course, this means I can't dilly dally getting into the garage, for even with the garage door's electric eye...(it is mounted pretty low), lol.
I have added additional zigbee outlet repeaters and built a nice solid system around the bulbs to ensure they are communicating. Maybe I need to get some new zigbee bulbs that work better with the 3.0 chips.
As @jtp10181 mentioned above, the screenshots in your original post are for the events that were emitted from the device rather than the commands that generated them.
So the Triggered apps section in those screenshots means that those events triggered the apps displayed rather than the other way around.
Your follow-up screenhots that list the commands and attribute events are what you would want to investigate for finding the source. If the command originated from Hubitat, you would expect to see the relevant open()command in the device logs for the device just before you see the relevant contact:opening and contact:openattribute events
In your case, it doesn't look like the logs show any commands originating from the driver for that particular device -- just events showing that it opened which would usually mean that the device was actuated from outside the driver itself (eg. physically or from a different integration)
At a previous home, I had a garage door which was being opened at various times at night by what appeared to be RF signal as it had not been automated yet.
I used a Zigbee plug in the opener power cord to disable it whenever both our cars were home (or when we were on vacation.
I understand that section where it’s triggering Sharptools. Not Sharptools triggering it. I have determined that there is something going on with the RATGDO, security 1.0 and the wall switch and power capacitors internally. It’s posted in some Home assistant forums that others are having the same issues. Such a bummer. Nothing is simple. The MQTT protocol is over my head. I got it to work but I don’t see it reporting any information in the MQTT application like I see from others posts.
The HomeKit integration works well, but it’s not available on ST dashboard. (My preference.) Unless there’s a way to integrate HomeKit.
I was curious if the 2 new Konnected options address Security 1.0, but they don't... Their FAQs are contradictory... The BlaQ FAQ says that if you have anything other than a round yellow button to get a White, but the White FAQ says that red (among others) button users should get BlaQ.
Security 1.0 seems like a bit of a black hole for this whole project (ratgdo/konnected)... Maybe time for a new opener? Either totally dumb or Security 2.0+, either of which have verified/proven control options.
I agree. They have been removed. After watching both doors cycle open multiple times, I took them out. It has something to do with the wall mounted switch and not receiving enough power so it’s sending an open command. Whatever it is, I don’t like it. I will wait for them to fix it.