Replies: 4 comments 5 replies
-
|
The instructions for configuring logging in Home Assistant are here: https://www.home-assistant.io/integrations/logger/ There is a sample config for enabling debug logging for tinytuya in a comment here. For tinytuya, just replace |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Jason. My hypothesis seems to be true:
Or do you see any other reason why it is objecting the device other than the empty response:
I thought if this different lock would work, that your code takes care of such devices? BR, |
Beta Was this translation helpful? Give feedback.
-
|
When I look ar the commit that solved the device22 problems, maybe we need to add dp 35 (closed_opened) for device22 locks? |
Beta Was this translation helpful? Give feedback.
-
|
35 is not a common dp, 9 is probably better. |
Beta Was this translation helpful? Give feedback.
-
|
Just adding 9 and 35 did not work. It comes back in milliseconds with a "Mit diesen Angaben kann keine Verbindung zu Ihrem Gerät hergestellt werden. Es könnte sich um ein intermittierendes Problem handeln, oder die Angaben sind falsch." (sorry, German). I will later look where this error message comes from and track it down. Before, I need to bake some Xmas cookies :-D. |
Beta Was this translation helpful? Give feedback.
-
|
Hello Jason, I have seen you added some dps. I tried with your new code (a) to add the device with poll only and (b) without poll only with no success and I really can't see what would be the issue. Find here the debug logs with debug enabled for both: tuya-local and tinytuya. Can you help me? I see no sign of connection problems. (a) (b) |
Beta Was this translation helpful? Give feedback.
-
|
No, I can't help. There is no known way to get dps out of this device on demand. |
Beta Was this translation helpful? Give feedback.
-
|
Kiora Jason, Sorry for being so stubborn :-). I thought that's what we use "poll only" for, when we can't get the status on demand. Am I wrong? If you give me a hint which function will create the "Can't connect..." message, I would try to investigate further. Because I understood that you have implemented something for devices that you only poll. By this I mean: I have a FHEM (fhempy/tuya) running that is able to create a device and sends at least dp35 (closed_opened) dp11 (unlock_password) and dp22 (open_phone_remote) messages when you open it. It will send different messages on dp11 even for different passwords. And the above code will also return these values. Shouldn't that work with your integration as well? BR, |
Beta Was this translation helpful? Give feedback.
-
|
Poll only is for when devices won't push their updates on a persistent connection for some reason. I'm not sure if any devices really need it, early on they did, but it may have been due to mishandling the connection. |
Beta Was this translation helpful? Give feedback.
-
Deal all,
Short version:
My problem is: how to specify in HA to log on tuya-local and tinytuya level in order to find out that the connection problem I have is related to the fact that the T12-Wifi-II Card+Pin lock is a device22 that doesn't report a status.
I have in theory everything to include it into tuya-local (it is a kind of clone of bstuokey_access_keypad.yaml) but as long as it doesn't connect I cannot go further.
Long version:
I have the famous connection problem when trying to connect to my T12-Wifi-II Card+Pin lock. I tried all recommended things like switching off the Tuya App, re-connecting the lock and changing the local key, etc.
I also played a bit with tinytuya and tracked the problem down maybe. It is a device22 and it will not report back a status but answer something like
{'dps': {}, 'type': 'query', 't': 1732286317}It seems to be one of these devices that can only be polled. It will then report back something, e.g.:
Received Payload: {'dps': {'9': 'AAABAAA='}, 't': 1732286419}Received Payload: {'dps': {'35': 'AQAB'}, 't': 1732286419}Received Payload: {'dps': {'22': 'AAAAAQAA'}, 't': 1732286419}Received Payload: {'dps': {'35': 'AQAC'}, 't': 1732286420}The above will be delivered when you open the lock by the App. I have a more or less complete dps set description, as this lock works in fhempy/tuya for FHEM. It is 95% already in the definition of the bstuokey_access_keypad.yaml.
But my problem is that when trying to add this lock, the connection is refused. In order to track it down to the problem that it is not replying with a proper status, I would like to enable debug messages on tuya-local and tinytuya level. Can someone help me with this? I am a HA newbie.
Also, to explain why I do this: the lock works with HA cloud integration. But it will only report open/close there and I need more information. E.g. on which password was used to unlock. I know that like in the above example, there will be different unlock_password_kit messages e.g. "AAAAAQAA" for password #1 and "AAAAAgAA" for password #2. I use this lock for lockout prevention with my shutters and a kind of remote control in FHEM but want to migrate to HA.
Any help is appreciated,
Carsten.
Beta Was this translation helpful? Give feedback.
All reactions