Add support for newer IR devices, and several IR format converters #228
Conversation
|
thank you for the patch! it looks like work but sometimes i see this error on console. idk if it is about this or not. |
|
@anar4732 Yeah, sometimes the devices just close the connection for no apparent reason. I have no idea why they do that, but tinytuya sees it and retries automatically so it's not a big deal. |
| @@ -1391,13 +1391,27 @@ def set_value(self, index, value, nowait=False): | |||
|
|
|||
| return data | |||
|
|
|||
| def set_multiple_values(self, data, nowait=False): | |||
There was a problem hiding this comment.
Love this. Was on my old TODO so thank you! ;) I also think there was an issue for this - I'll see if I can find it.
|
@uzlonewolf Sorry for the ping, but how hard would it be to add support for RF devices? Based on https://github.com/tuya-cloudcutter/tuya-cloudcutter.github.io/blob/3736ae997a30db7e8c379dd5472521922f6cd43f/devices/tuya-generic-ir-rf-universal-remote-controller-v2.0.8.json they must use the same DPS for RF as well. |
|
@Xmister I'm not sure if you're asking about cloud or local. Local already works for both Zigbee and Bluetooth sub-devices so I would expect it to work for RF devices as well. Does https://github.com/jasonacox/tinytuya/blob/master/examples/zigbee_gateway.py do anything? |
|
@uzlonewolf I'm talking about local, but I was more interested in learning/sending raw 433MHz codes, like how this IR module does, instead of interacting with an already set up gw-child pair. (My ir-rf gateway is cut from the cloud, so I can't set up subdevices anymore) |
|
Ah, I see what you mean now. I was thinking they were RF devices similar to how the Zigbee ones work. It shouldn't be too hard to add, though I'm going to need a packet capture and/or a firmware dump to figure out the protocol. I know yours is cut from the cloud, but does it have any RF devices stored? |
|
Sadly, no. I was trying libretuya-esphome on it, but didn't realise it doesn't yet support spi on these devices, so communicating with the SH4 radio module is not possible. |
|
As long as it has the JSON parsing bits in it it should work. I'm currently digging through my universal hub firmware dump to see if it knows about the RF commands, and I have a IR+RF gateway coming from Amazon in a couple days https://www.amazon.com/gp/product/B0BY2C68BJ/ |
|
Thanks. Here is the one I'm using right now: https://github.com/tuya-cloudcutter/tuya-cloudcutter.github.io/files/11353905/Tuya-Generic_IR---RF-Universal-Remote-Controller-v2.0.8.bin.zip |
|
Making some progress. Looks like if you set the key |
|
Since, this is a 2 band RF controller, I guess |
|
201 takes a JSON string so you just send `{"rf_type": ..., "control": "...", ...}`
Unfortunately I need to see the traffic between the SmartLife app and the device, so just the device won't help. Mine is showing delivery tomorrow so it won't be too long.
|
|
Ok, my device came in and I was able to get some packet captures. First, I added 2 random curtains to see what "known device" data looks like: to 'eb####tb' v3.3 cmd: 13 (0D) len(543) b'...{"dps":{"201":"{\\"rf_type\\":\\"sub_2g\\",\\"mode\\":8,\\"key1\\":{\\"code\\":\\"ffffc01fa4934924924924924d34924da4936db0\\",\\"delay\\":0,\\"intervals\\":0,\\"times\\":5},\\"feq\\":0,\\"rate\\":0,\\"cfg\\":{\\"b\\":[2,0,0,0,0,0,0,0,0,0,0,0,0,0,19,0,0,0,0,0,0,0,0,96,255,0,0,31,16],\\"c\\":[0,102,236,28,240,128,20,8,145,2,2,208],\\"s\\":[174,224,53,0,0,244,16,226,66,32,0,129],\\"d\\":[63,30,128,204,0,0,0,0,0,0,0,41,192,218,33,75,5,0,80,45,0,1,5,5],\\"t\\":[81,154,12,0,12,176,0,31,4,63,127],\\"f\\":[66,113,206,28,66,91,28,28]},\\"control\\":\\"send_pair\\"}"}}'
to 'eb####tb' v3.3 cmd: 13 (0D) len(575) b'...{"dps":{"201":"{\\"rf_type\\":\\"sub_2g\\",\\"mode\\":2,\\"key1\\":{\\"code\\":\\"924924fffcd349369249249249249269249a4924924924924d369a6d36c000\\",\\"delay\\":0,\\"intervals\\":0,\\"times\\":6},\\"feq\\":0,\\"rate\\":0,\\"cfg\\":{\\"b\\":[2,0,0,0,0,0,0,0,0,0,0,0,0,0,5,0,0,0,0,0,0,0,0,96,255,2,0,31,16],\\"c\\":[0,102,236,28,240,128,20,8,145,2,2,208],\\"s\\":[174,224,53,0,0,244,16,226,66,32,0,129],\\"d\\":[71,34,144,204,0,0,0,0,0,0,0,41,192,223,29,91,7,0,80,45,0,1,6,6],\\"t\\":[81,38,3,0,10,176,0,31,4,63,127],\\"f\\":[66,166,231,28,66,144,53,28]},\\"control\\":\\"send_pair\\"}"}}'After that I mashed the buttons a bit: Then I learned a 2-button remote. After learning each key it had me test them: Oddly enough, decoding that base64 results in another JSON string: Decoding that base64 and displaying the result as hex results in: |
|
Looks great! Can you show me the messages for the curtain pairing as well? With rf_study, I can get an encoded code, but sending back the same with |
|
There wasn't any pairing, just Add -> Curtain -> [select random brand] -> [select random model] -> "Does it work? [y/n]". Those 2 commands I posted above are the only ones it sent. What does your send function look like? It should be something like: import json
import tinytuya
d = tinytuya.Device(..., persist=True)
cmd = {
"rf_type": "sub_2g",
"control": "rfstudy_exit",
"study_feq": "433",
"ver": "2"
}
d.set_value( 201, json.dumps(cmd).replace(" ", "") )
cmd = {
"ver": "2",
"rf_type": "sub_2g",
"control": "rfstudy_send",
"study_feq": "433",
"key1": {
"code":"eyJudW0iOjEsInZlciI6IjIiLCJzdHVkeV9mZXEiOiI0MzMiLCJkYXRhMCI6Ind5U2RBelFCTkFHZEE1MEROQUUwQVowRG5RTTBBVFFCblFNMEFaMEROQUdkQTUwRE5BRTBBWjBEblFNMEFaMEROQUUwQVowRE5BR2RBelFCblFPZEF6UUJuUU5YQVRRQm5RT2RBelFCTkFHZEF6UUJuUU0wQVowRG5RTlhBVFFCblFNMEFRPT0iLCJsdiI6WzBdfQ==",
"times": 6,
"delay": 0,
"intervals": 0
}
}
d.set_value( 201, json.dumps(cmd).replace(" ", "") )With that "code" replaced with what rfstudy returned in 202. |
|
I was trying the following way: It did flash the light, so I thought it's working fine. However your code actually moves the curtain, so thank you for that. |
|
Glad it's working. Looking at the command you were sending, it looks like the differences are "rfstudy_send" vs "send_cmd", the inclusion of "study_feq", key1 numbers as integers vs strings, and the DP ID as a string vs integer ( Now that you have it working, where do we go from here? Is a new device type still needed/useful? |
|
Well, I did try with |
|
I don't mind making it, though I have my doubts that "lots" of people will use it. What functions do you want it to have? At this point I think I only have enough info to implement |
|
I think that's good enough for start. Good RF bridges are high in demand, this class could make these devices a simple one. |
|
Added in #343 |
Also adds
set_multiple_values()to core as the newer devices require everything to be in one packet. I also updated turn_on() and turn_off() to return the received data instead of just dropping it on the floor while I was in there.Documentation for new format converters and head/key sending in examples/Contrib/IRRemoteControlDevice-example.py
Closes #225 and I'm also going to say Closes #74 and Closes #27