Closed mprobber closed 8 months ago
Wow - incredibly fast work here on this and #1153! Thank you so much! Out of curiosity, what does the release cycle look like for this project?
I updated my Home Assistant to the version on main, and I’m able to see the lock, see when it’s unlocked and re-locked, but unable to lock and unlock it from home assistant. The status in HA changes, but the status in Smart Life does not, and the lock doesn’t unlock. It’s a wired device, so sleep shouldn’t be an issue. Any idea what could be the issue here?
Perhaps the method to unlock and lock is not as I understood from the information above (toggling dp 104).
There is no fixed release cycle, but usually there will be at least one release a month.
Sorry - I haven’t dug super deep into the inner workings of Tuya devices, so please forgive me if I’m misunderstanding.
Does dp 104 refer to
{
"abilityId": 104,
"accessMode": "rw",
"code": "open_closedoor",
"description": "开关门", // Open and close the door
"name": "开关门", // Open and close the door
"typeSpec": {
"type": "bool",
"typeDefaultValue": false
}
In the Query Things Data Model
response? The access control can also attach to a door contact sensor, and I would assume that would be the sensor response. But that assumption fails on a few fronts. Namely, the lock status is updated when the door is unlocked (I don’t have a contact sensor set up), and that the accessMode
of this is rw
.
This seems similar to the device discussed in #796, and the user there reported some success when unlocking with a PIN (after first calling Lock
), but I was unable to replicate that by calling Lock Service: Unlock
in HA.
The discussion on #796 is about reporting of the door being locked and unlocked by external events. That is different than unlocking and locking the door from Home Assistant. There are different methods that locks use for this, some are a simple switch-like boolean control, others are request-response systems where the remote unlock can only be done within a timeout period of a doorbell or similar event. Some seem to require a password, though that hasn't been implemented yet. There is no sure sign in the dps list above of any of these methods though, the closest seemed to be the "open_closedoor" rw dp. The sensor you are talking about is I think the doorsensor_alarm (which though also documented as rw is also documented as a "magnetic alarm", which I think refers to a reed switch).
I was just saying the devices seem to be similar (actually, from the same manufacturer), and noting that the “unlock with code” seemed to function, according to a commentor.
Digging into some Tuya docs a bit, dp 8 (remote_no_pd_set_key
), and dp 9 (remote_no_dp_key
) seem like how the remote unlock occurs. It seems like it’s a request/response system, where you store a temporary code, and then use that code to unlock. But it’s unclear what constitutes a “code” (is any string valid? Is it numbers?) and I’m unsure of how to poke around and test this out on Tuya cloud myself.
It seems likely that this would be the password method of unlocking, which is not yet implemented.
Presumably the intention is for remote_no_pd_set_key to be accessible only by admins, to set the remote unlocking key, and remote_no_dp_key is what apps use to open the door with a password.
Support was added in 2023.10.0 but I forgot to update this issue.
Hi, I have the same lock but it says "Sorry, there is no support for this device." what can i do wrong
Have a look in the Home Assistant log for a message like the one at the top of the page. It isn't necessarily that you did something wrong, the devices are often inconsistent about which dps they report, and we only find this out by trial and error of multiple people trying to get the device working.
Device matches None with quality of 0%. DPS: {"updated_at": 1704435630.3274434, "26": "high", "30": true, "31": 3, "34": 15, "102": true, "104": false}
Thanks, it looks like the difference is that the "101": true
is missing from what your device is reporting, so we need to make 101 optional.
Hello, I have successfully added :-)
Hello, I`m trying to add the same lock, but it identifies as Lucking HS06 lock
The log message is
Device matches lucking_hs6_lock with quality of 67%. DPS: {"updated_at": 1708070676.4819436, "26": "mute", "30": false, "34": 60}
Hello, and still there is no way to control the lock state?
If dp 104 does not work for that, as is configured, then I guess there is no way. I'm not sure what the unlock_phone_remote_kit does, it is possible that is involved as well.
Well, I managed to open lock with api requests to tuya smart lock api, but i guess that not the way how tuya-local works
No, that API is cloud based, tuya-local only uses local connections. There may be a way, but because this is an actual secure door lock, not a simple gate lock or child lock, it is not a simple boolean toggle, but maybe something like sending the correct passcode to dp 22 or another "raw" dp.
You could always use a python script that calls the smart lock API for remote unlocking, and tuya-local for monitoring.
No, that API is cloud based, tuya-local only uses local connections. There may be a way, but because this is an actual secure door lock, not a simple gate lock or child lock, it is not a simple boolean toggle, but maybe something like sending the correct passcode to dp 22 or another "raw" dp. Yeah, only need to understand what password it need
You could always use a python script that calls the smart lock API for remote unlocking, and tuya-local for monitoring.
Yes, but my idea is to use it locally. Thats a pity
Log Message
Information about DPS mappings
Product ID
5k8h97qska6pf5cm
Information about how the device functions
This devices controls an electric strike lock, either via fingerprint, 125khz RFID, or keypad. It allows the strike to either activate (unlock) or deactivate (lock).
This is the Amazon product info, I could not find any other manuals online