IR REMOTE CONTROL #74
Comments
|
Hi @adlerlinhares - Can you post a link to the type of IR device you are trying to control? I have one IR device and the only thing I have been able to get from the device is the temperature and humidity (no joke!). It can control our HDTV and other devices from the SmartLife App and Alexa we have set up for it, but I have been unable to determine the DPS codes to control it locally. There is a possibly that it is not designed to receive local control and only works via the Tuya Cloud. If you paste the detail of your device, hopefully others in the community have figured the mystery. |
|
Thank you, the model is: " WI-FI INFRARED REMOTE CONTROL - S08 "
|
|
I'm using "Ya-IR01": I can decrypt replies using this key but I can't decrypt requests:
And this is repeated many times:
|
|
Also, device info from API: "status" field is empty at all :( |
|
Also, device responses "json obj data unvalid" on |
|
Ah! For my IR device, it has an onboard temp/humidity sensors which is the only thing that appear on QUERY. I suspect these devices are oriented toward CONTROL (sending signals vs recording or reporting state). Hum... very interesting. |
|
Seems like the |
|
I still can't control it locally but it works fine using the official Tuya Cloud API. It's offtopic but maybe it will help somebody. There is a method to send RAW IR signals: https://developer.tuya.com/en/docs/cloud/6c376807b5?id=Kb3oeb91u35ga
@jasonacox TinyTuya is designed for local communication only but it's using Cloud API calls in wizard.py. So maybe add Cloud API features to the library too? There is my Python class for Tuya API: https://pastebin.com/xwNmTcC9 - it's partially based on your code. |
|
@ClusterM I like that idea! Adding Cloud API functions would be fairly straight forward. I'll add that to my wish list for this Christmas. :) I'll see what I can get done. Great job on the RAW IR discovery! It would be good to capture it in the documentation for the cloud API calls. |
|
HI @inermetso , with v1.3.0, TinyTuya now supports cloud API functions. See https://github.com/jasonacox/tinytuya#tuya-cloud-access. You can now use the import tinytuya
# Connect to Tuya Cloud
# c = tinytuya.Cloud() # uses tinytuya.json
c = tinytuya.Cloud(
apiRegion="us",
apiKey="xxxxxxxxxxxxxxxxxxxx",
apiSecret="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
apiDeviceID="xxxxxxxxxxxxxxxxxxID")
# Display list of devices
devices = c.getdevices()
print("Device List: %r" % devices)
# Select a Device ID to Test
id = "xxxxxxxxxxxxxxxxxxID"
# Display Properties of Device
result = c.getproperties(id)
print("Properties of device:\n", result)
# Display Status of Device
result = c.getstatus(id)
print("Status of device:\n", result)
# Send Command - Turn on switch
commands = {
'commands': [{
'code': 'switch_1',
'value': True
}, {
'code': 'countdown_1',
'value': 0
}]
}
print("Sending command...")
result = c.sendcommand(id,commands)
print("Results\n:", result) |
I managed to send a request, a response comes : |
|
Can you share your code? I'm not certain, but the response may only indicate that it was a correctly formatted command, not that it would actually do anything on the device. Also, in my experience with sending commands to the cloud, the "code" value can be different for same function (e.g. switch_1 may be switch). |
|
I have a Nedis branded IR Remote I paired the device with Smart Life and got it showing up on my Tuya developer account. I then added one remote for "Samsung" TV and noticed that now I have 2 new devices in the Tuya developer view. I tried adding a "Sony" remote and now I have 3 new devices, "IR Remote Control", "TV", and "TV 2". So the specific TV remotes I added through the application now show up as new devices in cloud. When queried for local key with the wizard, I get same local_key for "IR Remote Control", "TV", and "TV 2". I'm assuming the "IR Remote Control" is a gateway device for these specific remotes? After querying for status, I get following: >>> d_ir = tinytuya.Device(dev_id, dev_ip, dev_key)
>>> d_ir.set_version(3.3)
>>> d_ir.status()
{'devId': 'xxxxxxx', 'dps': {'1': 'send_ir'}}If I repeat the same test, but just replace >>> d_tv.tinytuya.Device(tv_id, dev_ip, dev_key)
>>> d_tv.set_version(3.3)
>>> d_tv.status()
{'Error': 'Invalid JSON Response from Device', 'Err': '900', 'Payload': 'gw id invalid'}Not sure if related but there seems to be some concept of "gateway" in the tinytuya in the "payload_dict" Not sure if above is any help or not, but just chipping in. I'd love to see this working with local control. In the cloud view if I select "Debug Device" for "TV" I get following instruction set visible
|
|
Hi, I would like to know if any one had any progress on this. I'm having exactly the same issue. In the Tuya App, I see the IR blaster and the Samsung Tv I added, and I can successfully control the TV through the app. When executing But there is no reaction. Full code: https://paste.ee/p/lvsd5 It seems that in the Cloud view of "Debug Device" for "TV", I can submit instructions from there, but I always get an error, so I wonder if this is an issue from Tuya side.
I also get this, also with: >>> d_ir.detect_available_dps()
{'1': 'send_ir'}
>>> d_ir.set_value('1', 'send_ir')
{'devId': '50038154500291bd52c5', 'dps': {'1': 'send_ir'}, 't': 1646687924}
>>> d_ir.set_value('1', 'test')
{'Error': 'Timeout Waiting for Device', 'Err': '902', 'Payload': 'Check device key or version'} |
|
Hi @helen-fornazier - thanks for posting this. It seems like you are close. Have you tried sending a command via cloud calls with just one setting? Maybe try different single commands to see what works? commands = {
'commands': [{
'code': 'Volume+',
'value': 'Volume+'
}]
}
result = c.sendcommand(id,commands)I do wish we could get local control of these IR devices, but Tuya may not make that available. |
Yes, I tried that with
Me too |
|
It’s great to see others investigating this. I’ll be keeping an eye out for any updates here as I just picked up a tuya IR remote and I haven’t had any luck controlling it locally. |
|
likewise, I am writing in C# though and always get this response: {"result":true,"success":true,"t":1652789917278,"tid":"7a8d20cad5db11eca914e276ec45657f"} |
|
If it could help anyone here, I managed to get it work by doing this: First, use your mobile app to send some IR commands. They will appear few times later on tuya iot platform (Device Logs when clicking on Debug Device on the device list). IR Send events are the ones that we should consider, after extracting a decent JSON from the logs (see screenshot), I managed to get my commands work using this code in local lan mode: I hope it helps
|
|
Great discovery, @mont5piques !! This is brilliant! 👏 Would you like to submit a PR to add this instructions and example to the README in the DPS section? I think we could expand/add to this area: https://github.com/jasonacox/tinytuya#version-33---universal-ir-controller-with-temphumidity I'm happy to add it myself, but want to give you the chance to get contribution credit too. Great work! |
|
I will look into this tonight and try to make a working C# example. Cheers mate will report how it goes! |
|
Hi @jasonacox |
Add a detailled procedure to control Universal IR Controllers using JSON DPs Related to jasonacox#74
|
@jasonacox With this DPS, the I think we should have an additional param to the |
|
@mont5piques, great idea! That would be a great feature and would be fairly easy to do. The example you gave above is basically the template: payload = d.generate_payload(tinytuya.CONTROL, {index: value})
d.send(payload)If you want to try it, create a PR for it as well. Otherwise, I'll see if I have time later today to get that in. |
|
@mont5piques thanks for your suggestion! I added the parameter # Example use of nowait option
d.turn_on(nowait=True)
d.set_colour(r, g, b, nowait=True)
d.set_value(201, '9AEmAvQBJgL0ASYCQAYmAkAGJgJABiY', nowait=True) # send IR command
d.set_value(25, '010e0d0000000000000003e803e8', nowait=True) # set scene |
|
@Apollon77 I just found it. import tinytuya
ir = tinytuya.Device("35217541c45bbef5a1f1", version=3.3, persist=True)
payload = ir.generate_payload(tinytuya.CONTROL, {"1": "send_ir", "3":"020ed8000000000008001600160042015600ac05f3005807b8", "4":"01%^002001FE50AF@&%*@(", "10":3000, "13":0})
print( ir._send_receive(payload, getresponse=True) )Or import tinytuya
ir = tinytuya.Device("35217541c45bbef5a1f1", version=3.3, persist=True)
payload = ir.generate_payload(tinytuya.CONTROL, {"1": "study_key", "7":"liGiETMCqQYwAqcGOQKhBjYCSgIsAkwCNgJGAi8CTQIyAkoCLwKmBjYCowYyAqsGLwJlAhsCZQIQAmYCFQJsAg8CaAIRAmsCEQLIBhICzQYQAmYCEQJqAhECbAIQAmoCFwJmAhACxwYUAmcCEwJrAhECxgYTAskGEALHBhMCxgYSAsgGFwIgyw=="})
print( ir._send_receive(payload, getresponse=True) )Hopefully I'll get a patch put together tomorrow. |
|
Aahhh use study_key AND ID key_study (7) with the code ... what a fun ... good catch ... I should also receive such an IR device soon to verify :-) |
|
With this ... could it be worth a try to build a json like {control: 'study_key', 'key_study': base64key} for the device type with 201/202 ;-) Will earlierst be able to try next week |
|
@uzlonewolf Verified :-) Then we need the "converting formats" only for the 201/202 style devices |
|
@Apollon77 I ended up basically rewriting the entire thing. You can now send by:
|
|
Cool. Will have a look next week. |
|
@uzlonewolf I tested it and one of my devices with 201/202 do not work with head/key ... base64 sending locally is working as it should. Did that really worked for you? |
|
That "key1" says repeat twice, but the lack of a "delay" value may be confusing it. Try adding print( ir.set_value(201, '{"control":"send_ir","head":"010e0400000000000600100020003000620c4b0c5b","key1":"002%#000490#000D0010#000100@^","type":0,"delay":300}') ) |
|
I tried with and without delay ... same effect Also the blue LED is not even blinking when I send it that way |
|
oooohhhhhh ... I have it ... my issue was that I set the devId to be the "virtual one" and "gwId" to be the "real IR blaster one". I need to set both to be IR-Blaster ... then it also works ... whoooo |
|
So exact: For IR you always need to send locally with devId adn gwId being identical and the "id of the raw IR blaster device". |
|
It's not a lot, but I did stumble over some documentation for the 1-13 and 201/202 DPs at https://developer.tuya.com/en/docs/iot-device-dev/Infrared_radio_frequency?id=Kay1cva9iq4ow#title-9-What%20types%20of%20data%20points%20(DPs)%20are%20there%3F . Seems 1-13 are "Non-system DPs" while 201/202 are "System DPs" I also figured out how to send IR via the Cloud API. The remote/key API commands are documented at https://developer.tuya.com/en/docs/cloud/ir-control-hub-open-service?id=Kb3oe2mk8ya72 and I posted some exampe code in #283 |
|
Edit: nevermind. This did the trick! === Logs for my device are different:
I tried using the these values as DEBUG:building command 7 DEBUG:building command 7 payload=b'{"devId":"1866<...>9c6","uid":"1866080<...>59c6","t":"1677848838","dps":{"201":"{\\"control\\":\\"send_ir\\",\\"key1\\":\\"02$$0020E0E0E01F@%\\",\\"head\\":\\"010ed20000000000040015004000ad0730\\",\\"type\\":0,\\"delay\\":30}"}}'
DEBUG:sending payload
DEBUG:payload encrypted=b'0000<...>0aa55'The connection seems to be correct because I get the following: data = d.status()
print('set_status() result %r' % data)
# set_status() result {'devId': '1866<...>9c6', 'dps': {'1': 'send_ir'}}Any suggestions? |
|
I mean, you can do that, but the entire reason Contrib.IRRemoteControlDevice exists was to abstract away those details. There are 2 different DPS sets in use and they use slightly different key1 formats. I recommend changing to: from tinytuya.Contrib import IRRemoteControlDevice
ir = IRRemoteControlDevice( 'abcdefghijklmnop123456', '172.28.321.475', '1234567890123abc', persist=True )
ir.send_key( head, key ) |
|
Hello! Just wondering how do you convert raw ir signals from the Tuya IOT website to pronto code? Thanks! |
from tinytuya.Contrib import IRRemoteControlDevice
b64 = 'IyOvEToCZQI5AkoCOgJNAjYCTwI4AlACNQJMAjkCTQI2ApsGSwKZBkkClwZMAp8GLALLBhgC0wYRAtMGEwLRBhMCbgIdAmkCGwLKBhsCagIaAsoGGgJzAhACbwIWAnICFAJvAh0CxgYdAmoCFwLMBhoCcAIUAtAGFALRBhQC0QYUAtAGFQKXnBgjCAkXAiDL'
pulses = IRRemoteControlDevice.base64_to_pulses( b64 )
print( 'pronto:', IRRemoteControlDevice.pulses_to_pronto ( pulses ) ) |
|
Thank you so much! |
|
For anyone in Australia with a Jaycar Smart IR you want: import tinytuya
from tinytuya.Contrib import IRRemoteControlDevice
import json
power_b64 = "1UbJXFdx2CYMVVRbkDA3VJBMaQHcMGSDASJuIiIRQV8REiJwdCERXUESdG5wIV9jXzBSMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
pulses = IRRemoteControlDevice.base64_to_pulses( power_b64 )
pronto = IRRemoteControlDevice.pulses_to_pronto ( pulses )
print( 'pronto:', pronto )
headkey = IRRemoteControlDevice.pronto_to_head_key( pronto )
print ( 'headkey', headkey )
if headkey:
head, key = headkey
print( head, key )
d = tinytuya.OutletDevice(
dev_id="10630805bcddc2ec910c",
address="192.168.1.140", # Or set to 'Auto' to auto-discover IP address
local_key="5141@a:KxJR`q'hd",
version=3.1)
payload = d.generate_payload(tinytuya.CONTROL, {"1": "study_key", "7":power_b64})
d.send(payload)
data = d.status()
print('set_status() result %r' % data) |
|
Hey guys, I think I've found a different format with the DPS 201. Check this out:
In the log above the commands are sent to the main device via DPS 201, you can notice 2 things:
I was able to control the device locally by sending this exact payload, example: # this command will power off my AC
command = {"head":"010ece0000000000040014003e00ab00ca","key1":{"data":"02$$0030B24D7B84E01F@%","data_type":0,"key":"power_off"},"devid":"","ver":"3","delay":300,"control":"send_ir","v_devid":"<redacted>","key_num":1}
payload = d.generate_payload(tinytuya.CONTROL, {"201": json.dumps(command)})
d.send(payload)Another example, It seems to set mode, temperature and fan speed: command = {"head":"010ece0000000000040014003e00ab00ca","key1":{"data":"02$$0030B24D3FC040BF@%","data_type":0,"key":"M0_T24_S3"},"devid":"","ver":"3","delay":300,"control":"send_ir","v_devid":"<redacted>","key_num":1}I was able to find some information about the keys using Tuya API: it will result in a long list of hashes, (showing a single item here): ...
{
"code": "tbCM00sNmkFpazuYxQu6D4LFzBirY6UDbYLQBC2ZERI=",
"key": "M0_T24_S3",
"key_id": 0
},
...Now, I'm trying to find what is the logic to build the |
|
Yep, that is the ver:3 I mentioned a while back
Presumably the version format Contrib/IRRemoteControlDevice uses will work as long as "ver" isn't set. If you can figure out the "/rules" format I would be interested in adding it, I took a crack at it a while ago but couldn't figure it out; presumably it is encrypted or compressed or something. Just a few bits changed causes the "/rules" data to be completely different #395 (comment) |
|
@uzlonewolf Do you know any tool which can be used to maybe find the encrypt logic based on samples? I want to help with that, but I'm not sure yet how to... Here are some samples, pairing /rules agains sent commands via Cloud:
|
|
I'm trying to send this command using the tinytuya I'm totally lost I don't suppose you can send your whole script as mine doesn't seem to work. This is what I have currently: |
and others
HI, first of all apologize my poor english.
Im facing a major issue trying to code the IR remote control.
Is there anyway to find out how to control it with tinytuya?
Im using yout code:
AS result i get the follow message:
Received Payload: {'dps': {'201': '{"control":"study_exit"}'}}Is there a way that i can have a list of commands?
what shoud be this "study_exit"?
Thank you so much!
Best regards
The text was updated successfully, but these errors were encountered: