Hi,
having never used node-red, after installing it is it difficult to configure it to detect the socket data?
I should follow guide 2. Node red configuration (2.2 Test node
Put settings into the tuya-local node in the simple testing flow from the previous post and test if you get the connection)
1 Like
Hi,
I installed nodered and reported the code that I found in step 3, I entered the values of my sockets in switch1 and switch2, I reported id and ip in the tuya device set, I inserted the switches and sensors in configuration.yaml, but the values are not reported and the socket status is off even if it is on.
Do I have to enter values manually also in the mqtt device set?
By doing the test of post 2.2, instead, under “msg” the values of 18 and 19 were reported.
What can I check?
1 Like
Hi @szkari,
I have six Bakibo smart plugs with power metering and original firmware and localtuya is working flawlessy in my configuration.
I’ve installed @rospogrigio 's repo on GitHub
[https://github.com/rospogrigio/localtuya-homeassistant]
I’m not completely sure if it is his repo but his nickname is so unique…
@SmartM-ui, who is a friend of mine, was unable to do the same with his Teckin SP22.
I wonder if this issue is hardware related or the @rospogrigio 's release needs an update …
What I am sure of is that localtuya works … only under certain conditions …
1 Like
I can confirm that with SP22 does not works this method, i could debug the problem:
- The socket is connected successfully
- The command to get status is sent successfully
- The response of the plug cannot be handled by pytuya package and falls in a exception
There is a mismatch of payload response of the plug, pytuya package cannot handle the response and the general purposes log message is “response is unvalid”.
Any idea? another method is trying to flash Tasmota firm…
1 Like
Hi @raimangsxr ,
have you tried node-red?
If so, could you tell me the procedure?
I have an error on function “df5da0e3.1e9ba8”: “TypeError: Cannot use ‘in’ operator to search for ‘1’ in undefined”
I also have the Teckin SP22
Thanks
I had to make some changes in NODERED and in the configurations.
Try with this script, replacing the $$REPLACE$$ with your data:
[
{
"id": "ea5358ba.a72db",
"type": "tab",
"label": "Flow 2",
"disabled": false,
"info": ""
},
{
"id": "e62f416e.81e5a",
"type": "change",
"z": "ea5358ba.a72db",
"name": "set tuya_devices",
"rules": [
{
"t": "set",
"p": "tuya_devices",
"pt": "flow",
"to": "(\t $s1 := \"switch_1\";\t [\t {\t \"devId\" : \"$$REPLACE$$\",\t \"ip\" : \"$$REPLACE$$\",\t \"name\" : $s1\t }\t ]\t)",
"tot": "jsonata"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 330,
"y": 220,
"wires": [
[]
]
},
{
"id": "d4643f9a.5a9b1",
"type": "inject",
"z": "ea5358ba.a72db",
"name": "",
"repeat": "",
"crontab": "",
"once": true,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 150,
"y": 220,
"wires": [
[
"e62f416e.81e5a"
]
]
},
{
"id": "a0ec6bf5.425b78",
"type": "inject",
"z": "ea5358ba.a72db",
"name": "",
"props": [
{
"p": "payload",
"v": "tuya_devices",
"vt": "flow"
},
{
"p": "topic",
"v": "",
"vt": "string"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "tuya_devices",
"payloadType": "flow",
"x": 140,
"y": 300,
"wires": [
[
"ff6fd49a.41c5f"
]
]
},
{
"id": "ff6fd49a.41c5f",
"type": "split",
"z": "ea5358ba.a72db",
"name": "",
"splt": "\\n",
"spltType": "str",
"arraySplt": 1,
"arraySpltType": "len",
"stream": false,
"addname": "",
"x": 290,
"y": 300,
"wires": [
[
"2abfbef4.bb35f2"
]
]
},
{
"id": "2abfbef4.bb35f2",
"type": "change",
"z": "ea5358ba.a72db",
"name": "set mqtt devices",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "(\t$topic_prefix := \"tuya\";\t$dev_name := payload.name;\t {\t \"platform\":\"mqtt\",\t \"name\": $dev_name,\t \"state_topic\":$topic_prefix & \"/\" & $dev_name & \"/status\",\t \"value_template\": \"{{ value_json.state }}\",\t \"command_topic\":$topic_prefix & \"/\" & $dev_name & \"/set\",\t \"availability_topic\":$topic_prefix & \"/\" & $dev_name & \"/available\",\t \"payload_available\":\"online\",\t \"payload_not_available\":\"offline\",\t \"json_attributes_topic\": $topic_prefix & \"/\" & $dev_name & \"/status\",\t \"json_attributes_template\": \"{{ value_json.attributes | tojson }}\",\t \"payload_on\":\"ON\",\t \"payload_off\":\"OFF\",\t \"optimistic\":false,\t \"qos\":0,\t \"retain\":false\t }\t)",
"tot": "jsonata"
},
{
"t": "set",
"p": "topic",
"pt": "msg",
"to": "\"homeassistant/switch/\" & payload.name & \"/config\"",
"tot": "jsonata"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 500,
"y": 300,
"wires": [
[
"a19c9891.9b331"
]
]
},
{
"id": "a19c9891.9b331",
"type": "mqtt out",
"z": "ea5358ba.a72db",
"name": "",
"topic": "",
"qos": "",
"retain": "",
"broker": "8a631f32.0b624",
"x": 650,
"y": 300,
"wires": []
},
{
"id": "8ef6a354.d4f0b8",
"type": "tuya-local",
"z": "ea5358ba.a72db",
"devName": "switch_1",
"devIp": "$$REPLACE$$",
"devId": "$$REPLACE$$",
"devKey": "$$REPLACE$$",
"protocolVer": "3.3",
"renameSchema": "",
"filterCB": "",
"x": 660,
"y": 400,
"wires": [
[
"a6c78422.f3669",
"bb365c60.43ec68"
]
]
},
{
"id": "4ddba09.605bae",
"type": "mqtt in",
"z": "ea5358ba.a72db",
"name": "",
"topic": "tuya/+/set",
"qos": "2",
"datatype": "auto",
"broker": "8a631f32.0b624",
"x": 100,
"y": 520,
"wires": [
[
"2e01d468.10e464"
]
]
},
{
"id": "c22c6132.c7d808",
"type": "change",
"z": "ea5358ba.a72db",
"name": "",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "data.available ? \"online\" : \"offline\"",
"tot": "jsonata"
},
{
"t": "set",
"p": "topic",
"pt": "msg",
"to": "\"tuya/\" & data.name & \"/available\"",
"tot": "jsonata"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 980,
"y": 460,
"wires": [
[
"5d21a236.721bcc"
]
]
},
{
"id": "5d21a236.721bcc",
"type": "mqtt out",
"z": "ea5358ba.a72db",
"name": "",
"topic": "",
"qos": "",
"retain": "",
"broker": "8a631f32.0b624",
"x": 1190,
"y": 420,
"wires": []
},
{
"id": "2e01d468.10e464",
"type": "change",
"z": "ea5358ba.a72db",
"name": "",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "(\t$new_state := (payload = \"true\") ? true : false; \t{ \"set\" : $new_state, \"dps\": 1 }\t)",
"tot": "jsonata"
},
{
"t": "set",
"p": "topic",
"pt": "msg",
"to": "(\t$name:= $split(topic, \"/\")[1];\t $tuya:= [\t {\t \"devId\":\"$$REPLACE$$\",\t \"ip\":\"$$REPLACE$$\",\t \"localKey\":\"$$REPLACE$$\",\t \"name\":\"switch_1\",\t \"state_t\":\"medion/switch_1\",\t \"cmd_t\":\"medion/switch_1/set\",\t \"attr_t\":\"medion/switch_1/attributes\",\t \"avai_t\":\"medion/switch_1/available\",\t \"entity_id\":\"switch.medion_switch_1_mqtt\"\t }\t ];\t$device := $filter($tuya, function($x) {\t $x.name = $name\t});\t$device.ip\t)",
"tot": "jsonata"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 320,
"y": 440,
"wires": [
[
"8ef6a354.d4f0b8"
]
]
},
{
"id": "844a1f1d.87baa8",
"type": "function",
"z": "ea5358ba.a72db",
"name": "",
"func": "\nmsg.topic = \"tuya/\" + msg.data.name + \"/status\"\n \nreturn msg;",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"x": 950,
"y": 420,
"wires": [
[
"5d21a236.721bcc"
]
]
},
{
"id": "c400326b.65091",
"type": "comment",
"z": "ea5358ba.a72db",
"name": "set device information",
"info": "",
"x": 160,
"y": 160,
"wires": []
},
{
"id": "b0d0999b.5bccb8",
"type": "comment",
"z": "ea5358ba.a72db",
"name": "set homeassistant discovery",
"info": "",
"x": 180,
"y": 260,
"wires": []
},
{
"id": "7c2f1600.89fee8",
"type": "comment",
"z": "ea5358ba.a72db",
"name": "control-status",
"info": "",
"x": 130,
"y": 380,
"wires": []
},
{
"id": "a6c78422.f3669",
"type": "function",
"z": "ea5358ba.a72db",
"name": "",
"func": "if (\"payload\" in msg) {\n return [msg,msg];\n} else {\n return [null,msg];\n}",
"outputs": 2,
"noerr": 0,
"x": 800,
"y": 540,
"wires": [
[
"844a1f1d.87baa8"
],
[
"c22c6132.c7d808"
]
]
},
{
"id": "bb365c60.43ec68",
"type": "debug",
"z": "ea5358ba.a72db",
"name": "teste",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "true",
"targetType": "full",
"statusVal": "",
"statusType": "auto",
"x": 620,
"y": 600,
"wires": []
},
{
"id": "8a631f32.0b624",
"type": "mqtt-broker",
"z": "",
"name": "hass",
"broker": "$$REPLACE$$",
"port": "1883",
"clientid": "nr-docker",
"usetls": false,
"compatmode": false,
"keepalive": "60",
"cleansession": true,
"birthTopic": "",
"birthQos": "0",
"birthRetain": "false",
"birthPayload": "",
"closeTopic": "",
"closeQos": "0",
"closeRetain": "false",
"closePayload": "",
"willTopic": "",
"willQos": "0",
"willRetain": "false",
"willPayload": ""
}
]
And with this configurations in the switch:
- platform: mqtt
name: "Aquecedor"
state_topic: "tuya/switch_1/status"
value_template: "{{ value_json.dps['1'] }}"
command_topic: "tuya/switch_1/set"
payload_on: "true"
payload_off: "false"
state_on: "True"
state_off: "False"
optimistic: false
qos: 0
retain: true
and this in the sensors:
- platform: mqtt
name: "Aquecedor_Power"
state_topic: "tuya/switch_1/status"
unit_of_measurement: W
value_template: "{{ value_json.dps['19'] | multiply(0.1) | float(2) | round (2) }}"
- platform: mqtt
name: "Aquecedor_Current"
state_topic: "tuya/switch_1/status"
unit_of_measurement: mA
value_template: "{{ value_json.dps['18'] | float(2) | round(2) }}"
- platform: mqtt
name: "Aquecedor_Voltage"
state_topic: "tuya/switch_1/status"
unit_of_measurement: V
value_template: "{{ value_json.dps['20'] | multiply(0.1) | float(2) | round (2) }}"
4 Likes
Thanks!
I try now!
It works perfectly!
The sensor states are displayed in the Home Assistant
THANK YOU
1 Like
Thank you @gustavocmorais and @monaco, i am getting measures in two Teckin SP22 now.
I can recommend that the simplest method for this device is the node-red method explaind in this thread on post 1, and the modification of the flow as @gustavocmorais describe.
this worked great. could you show how to make it witch 2 switch with the same Ip address put a different dbs. the light is on dbs 1 the fan is on dbs 2
thank you…
As i said, i have 2 switches Teckin SP22.
I could configure them successfully with node-red method yesterday and both could send measures.
Today, one switch still communicating measures but the other one return messages that cannot be parsed:
2020-07-30 21:52:08 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on tuya/switch_1/status: b'3.3\x00\x00\x00\x00\x00\x00\x00\x1c\x00\x00\x00\x015\xef\xbf\xbdD\xef\xbf\xbd\xef\xbf\xbdc\xef\xbf\xbd\n\xef\xbf\xbd\xcb\xb4\xef\xbf\xbdv=#\xef\xbf\xbd`#\xef\xbf\xbd\xef\xbf\xbdB\xef\xbf\xbdsj\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdT!1\xef\xbf\xbd\xef\xbf\xbdW\xef\xbf\xbd\xef\xbf\xbd\x0b\x18\xef\xbf\xbd\xef\xbf\xbd54\xef\xbf\xbd\x19\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbds'
2020-07-30 21:52:10 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on tuya/switch_1/status: b"3.3\x00\x00\x00\x00\x00\x00\x00\x1d\x00\x00\x00\x01\xef\xbf\xbd\xdb\x86\x0e\xef\xbf\xbd\x1ax4\xef\xbf\xbd\xef\xbf\xbd0\x19\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\x00'w\x0f\xef\xbf\xbdv\xef\xbf\xbd\x17\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdGLL\xef\xbf\xbd\xef\xbf\xbd\\\xef\xbf\xbd\xef\xbf\xbdZ\xe0\xa5\x9a\xef\xbf\xbd\x0e\xef\xbf\xbd\x047%\xef\xbf\xbd"
2020-07-30 21:52:11 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on tuya/switch_1/status: b'3.3\x00\x00\x00\x00\x00\x00\x00\x1e\x00\x00\x00\x01\xef\xbf\xbd\x16\xef\xbf\xbd\xef\xbf\xbdL\x1dV3s\xef\xbf\xbd\xef\xbf\xbd#\x7f&\xef\xbf\xbd\xd3\x9f[\xef\xbf\xbdlO\xef\xbf\xbdpZ\xef\xbf\xbd\xef\xbf\xbd\x19\xef\xbf\xbd].K^'
2020-07-30 21:52:13 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on tuya/switch_1/status: b'3.3\x00\x00\x00\x00\x00\x00\x00\x1f\x00\x00\x00\x01\xef\xbf\xbdY\xef\xbf\xbd\xef\xbf\xbdw\xef\xbf\xbd\x11\x10>\xef\xbf\xbd)\x04\r\xef\xbf\xbd^\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdk\xef\xbf\xbda\xef\xbf\xbd\x06]\xef\xbf\xbd\x06r\xef\xbf\xbda\xef\xbf\xbd\x1a\xef\xbf\xbd\x04\xef\xbf\xbd\xef\xbf\xbdB\xef\xbf\xbd&\xd2\x84\xce\xb2\x07\x07\xef\xbf\xbd4\x059'
2020-07-30 21:52:24 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on tuya/switch_1/status: b'3.3\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x01\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd)\xef\xbf\xbd\xef\xbf\xbd\x0e\x11\xef\xbf\xbd\x04\xef\xbf\xbd\x7f\xef\xbf\xbd\xef\xbf\xbd\x06\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd78\xef\xbf\xbd\x13\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdE\x00\xef\xbf\xbd\x7f\x0e\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\t\xef\xbf\xbd\x1fg\xef\xbf\xbdN[)\x13\xef\xbf\xbd\xef\xbf\xbd+\xef\xbf\xbd'
Any idea? Thank you!
@ranski1999 to get measures from 2 devices, i created two flows, one per device.
Hi everybody, I am the owner of the localtuya repo most of you are using. @liuk4friends asked me to have a look at this thread and I must tell you something: the error most of you are reporting:
is NOT an error. It’s just the way it has to be, and actually it’s me logging something not very useful, sorry about this. That debug message is showing a payload that is included in the status request message that HA is sending to the device, not the answer being received!! I wanted to print that message because I needed to be sure that the “t” part was ok (the current timestamp), and that I was actually sending those “dps” as set to null, because my cover devices needed that (other devices just needed the dps “1” to be sent as null). Don’t know if this can be the problem for your SP22 devices, but it might be necessary to send more of these “dps” set to null in the payload, it’s still not very clear to me the role of this payload in the communication. If you want to debug the communication more in deep, it’s the response messages that should be printed.
What actually IS a problem is this message:
This caused many headaches to me when trying to make my devices work, since this means that the response received cannot be decrypted because of a bad format, probably in the status request. This is a real pain in the arse to debug, I was just about to give up until I bumped into @TradeFace library that was working, and by merging his code with those of @mileperhour and @NameLessJedi I came up to the code of my repo.
Those who don’t get this error but still don’t receive the data, should have a look at the “decrypted result=…” message, that should display significant data if everything is working correctly. For example, @gustavocmorais posted this log:
As you see, the response message is correctly decrypted, but it only contains the dps “1” status (true, which means that the light is ON). This message should actually contain also the values from dps “18”, “19”, and “20”, which contain the voltage and power values (probably). What I would try to do, is to add these 3 values in the request payload, changing this line in pytuya/__init__.py :
json_data[‘dps’] = {“1”: None,“101”: None,“102”: None}
to
json_data[‘dps’] = {“1”: None,“18”: None,“19”: None,“20”: None,“101”: None,“102”: None}
And see if it works.
Since the devices appear to be working with Node-Red, the author of its node might be involved in this thread in order to better understand the problems. In my opinion, if somebody was able to make it working with Node-Red, he should have no big advantages in using localtuya. What I’m certain of is that if it works with Node-Red, there has to be some way to make it work also in localtuya.
As I told to @liuk4friends , I am not planning to be an active contributor to my repo, I published it just for people who needed this in order to use the cover devices, since I could not find any custom component that had them working, and I was not planning to change it unless my devices stop working, or I purchase new Tuya devices that need adaptation to work. This because I don’t have much spare time, but I might provide some help if needed, just don’t expect super fast replies.
Hope the above helps anybody,
rospogrigio
wow!!! i made this change to the line in pytuya/init.py and it worked!!! thanks a lot for your help in solving this issue, i have been struggling with this issue and finally gave up and use NodeRed instead. Thanks you!
Good, glad it’s working! So I believe the parameters you specify in the request payload as null represent those that you want to force to be present in the response: some devices return them anyways, other require them to be specified in the payload.
Will insert this fix in the next release 1.0.1 for everyone to benefit.
This opens to some optimizations, for example it could be possible to update the status of different parameters with different frequency (the on/off status might be queried more often than the voltage/current status). I don’t know if requiring more parameters require more time, it should be studied, maybe @freddycs can do some testing about this.
Bye everyone!
I have this light switch.
when I use the repo I can only get the first gang switch too work
the second one don’t can you help make the second one work.
this is the repo it is yours.
when I put # on my 40 -43 line It words with one gang put when I take them off switch
1 or 2 gang don’t work…
please help…
Hi @rospogrigio , you are welcome!
Thanks for sharing your project and for your great work, your presence in this topic is essential.
I tried your localtuya repository, but unfortunately the V, mAh and W sensors are not displayed in Home Assistant (Teckin SP22 sockets). No errors were reported in the log.
I have to use node-red to read those values (thanks to @gustavocmorais for sharing the working codes with Teckin SP22).
Tomorrow I try to install your repository again and replace the parameters you mentioned in pytuya / __ init__.py
I’ll let you know if the problem is solved.
Thank you again for the time you spend on this project.
PS: thanks also to my friend @liuk4friends for being able to involve the author of the repository 
Beautiful!
I couldn’t resist and I wanted to try immediately.
I installed your custom component, I entered the values as you suggested and … it worked perfectly. The values V, W, mA are also shown for the Teckin SP22 sockets.
I have seen that, compared to node-red, the values are updated much more slowly.
I am available to perform any tests to improve the updating of values.
Thanks again
Ya I notice the same on the data update interval. NodeRed updated the data with shorter interval.
Below is the screenshot of my sensor data history, WM_Power (purple line) is sensor from NodeRed and WM Current Consumption (green line) is from localtuya.
1 Like
Anyone managed to setup power monitoring on the BSD29 plug? What values did you use for current, current consumption and voltage?