If you have a bridge, try unplugging it and then see if AU works as it used to. If it does, then try my workaround of putting the bridges on a separate WiFi net - your guest network or IoT (if your router provides one - functionally the guest network and the IoT network are identical but routers now provide both so you can still give guests internet access without them being able to talk to your IoT devices)
Just read through this whole thread and wanted to chime in my own frustrations. Iāve had the Pro Series installed in my house for the past year and the auto-unlock has never worked for me. On a few occasions, Iāve actually heard the lock unlock and re-lock several minutes after I entered my house.
My set-up is both of my locks on my separate IoT channel and I use an Android phone. Since my phone connects to my vehicles via Bluetooth, my only guess is that the Bluetooth connection to those vehicles doesnāt disconnect immediately enough(?) and therefore, cannot connect to the lock as I walk up to it?
Hi Ben12 - " Iāve actually heard the lock unlock and re-lock several minutes afterā¦" As youāve figured out, that behavior is the result of your phone not making a BT handshake with your lock quickly enough (I assume you have auto-lock enabled).
āMy set-up is both of my locksā¦ā Just FYI U-tec suggests only having autounlock enabled on one lock per location. I donāt think it matters.
āthe Bluetooth connection to those vehicles doesnāt disconnect immediately enoughā¦ā The problem isnāt (probably) with the phone not disconnecting from the vehicle. Your phone can connect to more than one device via Bluetooth (assuming there are 2 different apps involved). The problem, from my observation, is that the locks canāt communicate over BT to two different devices at the same timeā¦ and they also seem to prefer using the WiFi channel. So, yes, the phone canāt connect to the lock over BT in the time you walk up to the lock.
Since I have a bridge, it is easy for me to eliminate the WiFi connection between the lock and the router. When I do, AutoUnlock works virtually 100% of the time. With your lock, just as an experiment, shut off the IoT connection to your locks (this simulates a power outage), then try leaving and returning to test AutoUnlock. If you do this experiment, please let me know the results.
Of course, disconnecting the lock from your WiFi is not an acceptable solution for most people although personally I would make that trade off when Iām just out and around and reconnect to WiFi when I was on a trip out of town.
@Bruce4 , I appreciate your response and suggestions!
To be clear, I only have the Auto Unlock active for my front door. The other door I have disabled for Auto Unlock.
I just went out of town but will be back midway through next week and Iāll attempt to disconnect the WiFi connection and report back on what I experience!
I had turned off the Auto unlock due to spotty performance. Just picked up a new Phone, Pixel 8 Pro, Now Auto Unlock is working flawlessly BUTTTTT, It auto re-locks way too fast. 9 times out of 10 I do not get to my door in time for it to be open. It has auto locked again. I have my Auto Lock set to 5 mins, but it looks like it auto locks after an Auto Unlock in <1 minute. I set the Geofence to 300 meters to possibly give me more time, But most times it is locked again by the time I get there. I can see in the logs it did Auto unlock, but then locked again. Is there a setting for āRelock timerā after auto unlock?
Try turning off AutoLock just to see if you have any control. I donāt use AL and I have an iPhone so canāt really help. You can always try uninstalling and reinstalling.
However, note that the Geofence distance does NOT control AutoUnlocking; instead, it tells your phone to get ready to look for the Bluetooth signal from the phone. When it finds the BT signal, thatās when it sends the unlock command.
Tested turning off the Auto Lock, and that helps in that it does not ārelockā the door, so thatās good. But, I like using the Auto Lock as I never have to think about whether I have remembered to lock my door. I have it set for 5 minutes and it works great. BUT It looks like it does not honor that 5 minute setting after an Auto Unlock. weird Bug that I am hoping will get addressed
Is your lock one that comes with a ādoor sensorā. If so, that perhaps is the difference between manually unlocking AND leaving, closing the door behind you, and having AU unlock but not open and close the door.
Iām speculating that closing the door and having the sensor sense that acts as a trigger to start the 5 minute timerā¦ but with AU, the door is never opened so the timer is never āresetā, so AL kicks in almost instantly.
So hereās the next testā¦ this one is easy. Using your app (while standing near the lock), unlock the lock and see how long before it autolocks. Again, I cannot test this because my lock does not have a door sensor.
Thanks, I tested this. Unlocking the Door with the App on the Phone still abides by the AL settings (5 minutes). After validating that I tried leaving the area to go into Away Mode, and coming back. Door Auto Unlocked like a champ, but Auto Locked again in about 30 Sec to max 1 Min. I could see when it relocked in the Logs. In the screenshot, at 12:27 it was unlocked with the app. Door not touched, and auto locked again at 12:32. I then left and came back. It auto unlocked at 12:39 and Auto Locked at 12:40
Hey, you have to agree it was a good theory :^). Thatās what makes a theory a theoryā¦ it provides a testable prediction.
Interestingly, having watched these threads since I got my lock, I donāt recall anyone else reporting this problem.
You can always try a clean re-install of the app (delete the app, shut down the phone, re-install the app).
BTW, Iāve just turned on autolock and Iāll let you know if I can replicate your problem on my lock with iOS app.
I really appreciate theoretical. Always worth a try!
Iāll give reloading a try too. I have a feeling Bluetooth is getting a lot better on these phones and connecting from further out too which may exacerbate the problem.
Replicated your results!
Should be an easy software fix for u-tecā¦ Next firmware release guys? 
1 Like
I installed the firmware update issued yesterday that claims to have improved Auto-Unluck.
Auto-Unlock remains dangerously buggy. Today the lock just opened for no reason at all. The log shows I auto-unlocked it. At the time, I was in the house. I was in one room and my phone was lying on a desk in another room.
I used to write comms software drivers for a living. On my personal evaluation this is whatās required:
-
Rewrite the auto-unlock code from the ground up. The team that rewrites it must not be the people who wrote the current version.
-
The new version MUST NOT RELY ON BLUETOOTH. Bluetooth is just about the worst, most unreliable, protocol currently in use. Instead, rely on location services in the phone and communicate via the home wifi.
-
Iām as sure as I can be that the bugs in auto-unlock are actually in the phone app, not the lockās firmware. That, and the inherently flawed design. The phone should determine that it is within range of the lock to initiate auto-unluck if the phone has connection to the home wifi and if location services show the phone within 8 meters of the lock. If the phone is unable to make a connection to send the unlock command within, say, 2 minutes or some other reasonable timeout, then the auto-unlock attempt is flagged as a fail and no further attempt made.
I have been unable to connect my U-Bolt Pro WiFi to my WiFi. We lost internet connection about a month ago for an extended period of time and since then I have not been able to connect. They have sent me a new indoor unit and still no luck. I have tried several dedicated 2.4Ghz networks on my router and no luck with any of them. I just get the āfailed to connect to Wi-Fi ā¦ā message. I have many 2.4 GHz items connected without an issue. Any suggestions?
Thanks
Steve
Hi Gary,
I can almost promise you the issues are in the app, not the lock firmware, at least not in the usual sense. I have a lock that does not have built in wifiā¦ although I have a bridge, auto unlock works (actually better) when the bridge is unplugged.
Mentally reverse engineering the process I am very confident that from the lockās perspective, there is no such thing as autounlock. All it knows is that it gets a command from the phone to unlock, just as if I had opened the app and pushed the unlock ābuttonā. The app sends that Bluetooth command (and it has to be Bluetooth since it works bridge unplugged) after the phone has exited and reentered the geofence AND it senses the lockās Bluetooth signal. And thereās the rub.
My phone cannot connect to the lock over Bluetooth if the lock is currently communicating through the bridge (I assume Bluetooth āreceiversā, like speakers, can only listen to one source at a time), so auto unlock works better (for me) with the bridge unplugged, given that it appears the Utec servers poll the locks to get status, rather than having the locks just send their status to the servers when their status changes (which activates Bluetooth communication between the bridge and the lock)
Anyway, given that the autounlock feature must work over Bluetooth for locks like mine (the bridge is optional), it absolutely should have the time out feature you mention.
Hi Stephen,
My suggestion would be unplug the wifi router and move it next to the door, close as you can, with nothing metal to interfere, then turn back on. 2.4GHz canāt usually penetrate a steel frame house, for example, and even a metal filing cabinet in an intervening room can block signal.
I know that means youāll be unplugged from the WAN, but that doesnāt matter for this test.
So move the router next to the door and try to connect the door to the wifi. If it works, youāll be buying a thing called a wifi repeater. Put the router back where it belongs and place the repeater somewhere in the house that can get signal to both the router and the door.
If it doesnāt work, then check to see if the router config has somehow blacklisted the door. Also look for any weird router rules (there should be none by default). And a variation of the āIs it turned on?ā question, check to make sure you have DHCP enabled in the router. If all else fails, factory reset the router and then recreate your wifi channel.
If all of that fails then Iād be wondering if the door is transmitting at all. There are wifi sniffers that can listen for that, but by this stage Iād consider getting a qualified LAN installer to have a look.
Gary
Hi Bruce, good to meet you.
Agree totally with you on the basics of how auto-unlock works. It has to be something like you describe.
I donāt think itās possible though that the U-tec servers could poll the doors. All firewalls prevent connections initiated from outside. Outside connections can be allowed if the device on the inside sets a port-forward rule on the router, but I just checked mine and there are no port-forwards. So the door must be connecting to the servers.
My router log shows the door initiating a connection to 54.200.33.9:8883. On reverse lookup that IP is owned by Amazon, and apparently is somewhere in Oregon. Port 8883 is the standard port for a commercial protocol called MQTT that is designed to connect devices to the cloud, and it operates over SSL/TLA, which is encrypted. So thereās a big tick for that one.
I agree that the door has no inherent auto-unlock logic, at least on our combined understanding. But in that case, why was a firmware update issued the other day that among other things says āimproved auto-unlock logicā? So on the face of it, the manufacturer just implied weāre both wrong, but I donāt see how.
Iām sure youāre right about your Bluetooth bridge. Bluetooth has a theoretical connection limit of 7, but in practice itās usually 2 or 3. And due to the way it works there can be only one active connection at a time. So absolutely yes, when your doorās connection to the bridge is active, then it wonāt respond to the auto-unlock command, unless the door is programmed like a mobile phone, which is highly unlikely. Phones do an active-connection switching trick that is designed to make it look like there are multiple active connections even though there arenāt.
Bluetooth really should not be used for anything that is safety-critical. Imagine if all aircraft had their pilot controls connected to the plane via Bluetooth. How many planes would fall out of the sky every day? On the other hand if someone loses connection between their headphones and their music player, then no one died.
The door lock is somewhere between those two extremes, but Iām amazed U-tec arenāt extremely worried about this. Surely in litigation-happy America this is an ugly court case waiting to happen. Imagine if the door randomly unlocks, the owner doesnāt notice, and by bad luck a thief tries the door?
I donāt think itās possible though that the U-tec servers could poll the doors.
Well, that does make sense. Perhaps the lock was providing status on a schedule instead of just when there was a change. I say āwasā because they claimed a firmware update would extend battery life - by not communicating over wifi as often???
why was a firmware update issued the other day that among other things says āimproved auto-unlock logicā? So on the face of it, the manufacturer just implied weāre both wrong, but I donāt see how.
I can imagine improved AU logic in the firmware - for example, the lock asks the app āwhen did you reenter the geofenceā and rejects the unlock command if it has been unlocked and relocked after the reentry time.
when your doorās connection to the bridge is active, then it wonāt respond to the auto-unlock command.
You would know better than I if a suspicion of mine is true and/or a likely engineering shortcut. While viewing these messages and being part of the beta test group for the ānewā app, I sensed that people with built-in wifi seemed to have more problems with AU than people like me. This observation made me wonder if Utec had just added wifi to my non-wifi lock by funneling the wifi messages through the same channel as the Bluetooth messages, essentially blocking the BT AU commands.I donāt know how to test this theory since unlike unplugging the bridge, you can disable the internal wifi connections (yes, you can make your router invisible to your lock but that is not the same as breaking the bridge to lock Bluetooth connection.)
Imagine if the door randomly unlocks, the owner doesnāt notice, and by bad luck a thief tries the door.
If we believe the ārandomā unlocking is caused by a delayed autounlock, then the problem is not a BT security problem per se, and can be fixed by the firmware/software ideas weāve mentioned. That is, no one has hacked the BT channel, instead the system isnāt smart enough to realize it missed the boat and just steps off the edge of the dock thinking it is still there.
However, as you have experienced, there does seem to be some ārandomā unlocking, long after the AU shouldāve happened and long after the wifi channel should have gone quiescent. Also, on at least 2 occasions my lock has activated in less than a minute after Iāve unlocked and opened the doorā¦while the door is still open. And I do not have auto-lock activated. A truly random locking. Well, if it can randomly lock, it can probably randomly unlock, which is a true security problem.
Hi Bruce,
This observation made me wonder if Utec had just added wifi to my non-wifi lock by funneling the wifi messages through the same channel as the Bluetooth messages
The lock would have to use psychic powers to know that the device itās talking to has a wifi connection, and know in advance what the device would do with any message. So itād work as long as the two devices have been specifically built to work together. Thatās a variation on protocol tunneling. But if your bridge wasnāt built by u-tec then thereās zero chance.
It sounds to me like your random locking events are probably a different bug to the random unlocking.
I do have to say that the firmware has a pretty solid feel to it. Also, a lot of people donāt realize how incredibly hard it is to update firmware to in-place devices all around the world and not have significant failures. If something goes wrong that requires a manual fix itās going to be a mess. So U-tec do very well with that.
I would love for U-tec to do a phone app release with an option to log every single command that leaves the app. Then weād know for sure if itās the phone app initiating the random events, and it would probably be a good support feature for the company.
I did think of another way for the phone to be kind of legitimately sending the random unlocks. Problems with location services could cause it to happen.
Location services in the phone does from time to time go offline or get confused or have a very wide margin of error. Thereās a rather cool app called GPS Test where you can watch what the phone is thinking about itās location. (It also shows you the satnav positions)
Itās rare but possible for the margin of error to go to more than 300 meters, and if that happens, then the u-home app might legitimately flip to away mode. When location services gets its act back together then u-home would think the phone had teleported to outside the geofence and then teleported back. Which would cause it to go to back mode and since the door is nearby it would send an unlock. The same logic would apply if the phone simply lost track of itās position for a short moment.
If thatās the answer then the u-home app would simply need some anti-teleport sanity checking code to avoid sending the unlock. Which would be another good reason to put trace logging into the app, to see whatās happening.