Request support for Tuya-Local Orion Grid Connect Bluetooth Lock via WiFi hub #654
Comments
make-all
added
subdevice
|
You are right, hubs and sub devices are not yet supported, but a pull request was submitted yesterday, so after the issues with it are fixed it should not be too far away from being ready to go. |
|
I don't think that log is for the lock. It seems to match some kind of smartplug. Prior to the recent addition of sub device support (as yet unreleased), I would not expect to get anything in the log for the lock, as it needs to go via the hub (IP address would be the same as the hub). |
make-all
added a commit
that referenced
this issue
May 1, 2023
make-all
added
awaiting confirmation
make-all
added a commit
that referenced
this issue
May 1, 2023
It is valid to have locks that cannot be locked or unlocked from the network. Such locks can still usefully be monitored by Home Assistant. Issue #654
make-all
removed
awaiting confirmation
|
Hi, I've gotten around to testing all of this again. I've tried entering it numerous ways, but the times it goes through, this is the output: I've done these recent tests on HA 2023.5.4, TuyaLocal 2023.5.1. I tried using the devices.json file that tinytuna (1.12.7) generates (as well as the API Explorer at Tuya Cloud to get the IDs/Keys). Here's devices.json (the lock is on top… the hub on bottom): The HA Integration now asks for "Sub device ID (for devices connected via gateway)". So, I tried: ID: bf92xxxxxxxxxxx Result: "Sorry, there is no support for this device." ID: bff9xxxxxxxxxxxxx ("id" of the Hub) Result: "Unable to connect to your device with those details. It could be an intermittent issue, or they may be incorrect." ID: bff9xxxxxxxxxxxxx ("id" of the Hub) Result: "Sorry, there is no support for this device." I could try more combinations, but those seemed the only logical ones. Could you please confirm what should be going where, and/or if there's some other output I can provide? Also, this is the output at Tuya Cloud API Explorer for Get Device Information: Thank you. |
|
It looks like just some dps need to be marked optional, as they are not reporting when the door has not been recently unlocked. |
make-all
added a commit
that referenced
this issue
May 25, 2023
Basically only the secondary entities (battery level, auto-lock setting) are being reported, none of the lock feedback (which I guess only comes when the lock is unlocked). Issue #654
make-all
added
awaiting confirmation
|
I tried unlocking the door and trying again, but no difference. Can you please confirm which ID should be going where? |
|
Try redownloading the integration, and select "main" as the version to install if you want to test the latest change. |
|
OK, just did. This time I'm offered three different devices types:
The log during it: I tried going with Simple Switch, but no response from anything when toggling the created switch. I'd still really love for you to confirm that I'm putting the right IDs in the right places. Could it just be getting the dps of hub outlet because I'm feeding the wrong IDs? When creating, I always switch Protocol to Auto and never tick the "poll" checkbox. |
|
OK, I got it detected! I used the "id" for Device ID, and "node_id" or "uuid" (they're the same value) for "Sub device ID". Then it detects as Orion BLE Lock! |
|
OK. Progress. I have a Lock Device in Home Assistant, which has an "Auto-Lock" switch under Configuration. Toggling that in HA properly updates "Passage Mode" in the Tuya app. Changing it on either device is quickly reflected on the other. BUT, there is also a Lock entity. However, pressing Unlock or Lock fails with "Failed to call service lock/lock.". The following is in the log: |
|
That is expected, the device did not provide any obvious way to unlock via the local network. But the lock entity should report what credential was used to unlock the door, so at least you will have logging. |
|
OK, that's good to know. Thank you. I will have a dig. I do see the "changed_by" attribute, currently "changed_by: App #1". I've tried unlocking the lock the two ways I can… app and fingerprint. In the Tuya app, I see the last unlock referred to as "Unlock with Mobile Phone" or "Unlock with fingerprint", but the "changed_by" attribute doesn't appear to change from "App #1". |
make-all
added a commit
that referenced
this issue
May 25, 2023
If these persist, app always overrides fingerprint. With them not persisting, it is likely they will only be available in the UI breifly, but at least automations can trigger and they will be in the logbook. Issue #654
|
If you update again, I have tried to fix the reporting. Likely now the "changed_by" will only appear briefly after an unlock, but it might be in the LogBook, and automations triggered on it will work so you could use an automation to update a Helper entity if you want to track the last unlock long term. |
|
So, the "Auto-Lock" (or "Passage Mode" as Orion calls it) really kinds of acts like a Locked/Unlocked control. If Auto-Lock is on, the handle is locked. If it's off, it isn't. The Unlock function in the Tuya app is only just a temporary unlock-for-a-few-seconds. I'm not sure it's even worth pursuing that, when we have Lock/Unlock functionality just from the Auto-Lock switch. I have set up the following Template Lock based exclusively on the auto-lock switch: I initially tried to just use the simple, HA-integrated method of Switch-as-Lock, but unfortunately, it's inverted, and I don't believe the Helper has an easy way of reversing it, so Template Lock to the rescue. Super simple, and works awesomely. Thank you so much for your attention and effort. I'm going to go order another two! |
make-all
added a commit
that referenced
this issue
May 30, 2023
When true, the door is locked unless opened by credential. When false, the door is unlocked, so we can use that for manual control. Issue #654
make-all
removed
awaiting confirmation
|
Hi, I thought I'd re-open this (please tell me if this should be a new issue instead) because I have not been able to get the unlocking of the door to be a trigger an automation as you suggested above. I've tried using the 'unlocking' and 'unlocked' events to no avail (no traces either): Also, am I able to switch back to the main/master branch? Thank you. |
|
Since 2023.6.0 was released yesterday, I don't think there is currently any reason to switch back to "main". But in general, if you select "Redownload" in HACS, you can choose a specific version to install, from a list that includes "main" along with recent releases. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue #162 seems to be how lock support came to be, and based on the description, I assume it's this lock (https://www.bunnings.com.au/orion-grid-connect-smart-wi-fi-entrance-lock_p0330511, which has built-in WiFi). I bought another Orion Grid Connect lock, but a Bluetooth one (https://www.bunnings.com.au/orion-grid-connect-smart-door-handle-lock_p0330508) and their Bluetooth (to WiFi) hub (https://www.bunnings.com.au/orion-grid-connect-smart-bluetooth-hub-with-socket_p0330509)
I have had IoT.Tuya set up for ages. I used
python -m tinytuya wizardto get the keys. This is the output of the devices.json the generates:(The fan is integrated via the plugin and works wonderfully)
I noticed that both the Lock and the Hub have different id's, but have the same key.
Using IoT API Explorer → Get Device Specification Attribute, I get the following for the Lock:
Interestingly, when I use the same query for the Hub, I get:
When I add the Lock in HA (using id = bf7916jzauojjy4q), I get offered a Simple Switch or Simple Switch with Timer. Upon adding to HA, there is no reaction in any device when toggling the switch.
When I add the Hub (which has an integrated power socket), I get the same matches, but in this case, when I toggle the switch, the hub's socket properly toggles.
I captured the output when adding both devices to HA, and I actually don't see any difference:
Lock:
Hub:
My first assumption, is that hubs and their devices simply aren't supported, so HA isn't even getting a chance at configuring the lock, but I thought I'd collect the info just in case it was of value. Thank you.
The text was updated successfully, but these errors were encountered: