Tuya LOCAL with energy monitoring and without tuya-convert

Hi @Brocks,

this is the best “localtuya” repo on Github:

I agree! And @rospogrigio, you should send a PR to HACS default repo to include it in the default repo list.

2 Likes

Thank you very much,

I’ve followed all the steps to get to the LocalKeys, however when I try scanning the QR code.

It just getting an error “logging in “non-mobile devices”, please make sure it was you.”

If anyone knows how to fix this I would really appreciate it.

  • Brock

Well I’m really flattered and excited about this… where is the HACS repo? How should I create the PR?

I have a problem discovering the device and connecting to Tuya cloud developer platform. I’m doing it from ubuntu server running as virtual machine on Windows laptop but the device, put in pairing mode is not being discovered. Should the tuya-cli be run only from physical machine in order to make it work?

First start with this:

Then continue here (it is linked from the page above):

1 Like

Hi everybody,
I’ve installed 3.0.2 version but the update broke my localtuya integration.
3.0.1 release was working perfectly so I’ve restored my last working snapshot (last night).

Since even after that (and after rebooting) the localtuya component still did not work, I manually deleted it.
Then I installed again the 3.01 release manually by copying the “localtuya” folder from GitHub into the “custom_components” folder of HA (via Samba).

After a new reboot, HA and localtuya started working again but two strange things happen.

First:
Although I manually installed version 3.0.1, the system tells me I have 3.0.2.
As a matter of fact, HACS doesn’t tell me that there is a new update available (3.0.2)

Second:
In the log I’ve found this error below

Logger: custom_components.hacs.repository.integration.rospogrigio.localtuya-homeassistant
Source: custom_components/hacs/repositories/integration.py:88 
Integration: HACS (documentation, issues) 
First occurred: 8:54:00 PM (3 occurrences) 
Last logged: 8:55:00 PM

No file found 'manifest.json'

Any idea?
Should I have also manually copied all the other files that are outside the “localtuya” folder ?
For example “tuyadebug.tgz” and “pyproject.toml” ?
Thank you in advance

Luca

I believe we are in a special place right now:

1 Like

then the best thing to do is … wait

talking about this little issue, do you think that this error below could be “localtuya related”?

Logger: asyncio
Source: /usr/local/lib/python3.8/asyncio/selector_events.py:901 
First occurred: 22:10:28 (86 occurrences) 
Last logged: 22:10:28

socket.send() raised exception.

I would suspect this:

1 Like

Yeah sorry for the mess guys, I thought it was just a little modification but I actually broke everything… trying to fix it now.

3 Likes

Sorry but 3.03 doesn’t work.
Localtuya component not available or something like that
I’ve reinstalled manually 3.01 release and now Localtuya works again

Unfortunately the manifest bug is still there

No file found 'manifest.json'

And HACS believes that I have 3.0.3 version installed.

I’m wondering if there is some issue with the folders of this release and of the previous 3.0.2 as well.

As a matter of fact the path seems to be:

/config/custom_components/localtuya/custom_components/localtuya

But It usually is :

/config/custom_components/***component***

So below you can find a screenshot of my 3.0.1 manual installation:

Please guys, remain at 3.0.1 until localtuya has been integrated into HACS, thank you.

3 Likes

:+1:

Ok!
Thank you guys for all your efforts!

First, thanks for your work!. I have configured tuya cover successfully but device not respond commands. The generated log is:

2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.cover] Launching command on to cover
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Sending command set (device type: type_0a)
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Send payload: b’{“devId”:“dev_id”,“uid”:“dev_id”,“t”:“1603186432”,“dps”:{“1”:“on”}}’
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Waiting for sequence number 28
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=28, cmd=7, retcode=0, payload=b’’, crc=1445883824)
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Dispatching sequence number 28
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Decrypted payload: {}
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.cover] Launching command stop to cover
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Sending command set (device type: type_0a)
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Send payload: b’{“devId”:“dev_id”,“uid”:“dev_id”,“t”:“1603186432”,“dps”:{“1”:“stop”}}’
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Waiting for sequence number 29
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=29, cmd=7, retcode=0, payload=b’’, crc=2344138293)
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Dispatching sequence number 29
2020-10-20 11:33:52 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Decrypted payload: {}
2020-10-20 11:33:55 DEBUG (MainThread) [custom_components.localtuya.cover] Launching command off to cover
2020-10-20 11:33:55 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Sending command set (device type: type_0a)
2020-10-20 11:33:55 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Send payload: b’{“devId”:“dev_id”,“uid”:“dev_id”,“t”:“1603186435”,“dps”:{“1”:“off”}}’
2020-10-20 11:33:55 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Waiting for sequence number 30
2020-10-20 11:33:55 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=30, cmd=7, retcode=0, payload=b’’, crc=913496827)
2020-10-20 11:33:55 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Dispatching sequence number 30
2020-10-20 11:33:55 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Decrypted payload: {}
2020-10-20 11:34:01 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Sending command heartbeat (device type: type_0a)
2020-10-20 11:34:01 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Send payload: b’{}’
2020-10-20 11:34:01 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Waiting for sequence number -100
2020-10-20 11:34:01 DEBUG (MainThread) [custom_components.localtuya.pytuya] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b’’, crc=2958142211)
2020-10-20 11:34:01 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Got heartbeat response
2020-10-20 11:34:01 DEBUG (MainThread) [custom_components.localtuya.pytuya] [dev_id] Decrypted payload: {}

test.py shows the follow information:

-@-:/tmp/tuyadebug $ ./test.py dev_id 192.168.170.211 localkey
INFO:localtuya:localtuya version 0.0.19
INFO:localtuya:Python 3.7.3 (default, Jul 25 2020, 13:03:44)
[GCC 8.3.0] on linux
INFO:localtuya:Using pytuya version ‘8.1.0’
INFO:localtuya:Detecting list of available DPS of device dev_id [192.168.170.211], protocol 3.3.
DEBUG:localtuya.pytuya:Sending command status (device type: type_0a)
DEBUG:localtuya.pytuya:paylod=b’{“gwId”:“dev_id”,“devId”:“dev_id”}’
DEBUG:localtuya.pytuya:decode payload=b’\x9b\xd6\x96J\xc4\xd48[I\xd6HkO\xb6\x92\xcfz\x82W\xae\xa9\xe1\x87\xea\xa1\xf6\xc65\x8d\xdbPf\xc4\x15\t\xeb\x11\xfa\xb1>Mj0\x11\xf3w\xa2DHs@\xe5\xc8\xd4\xa1\xc2\xea{\x9a\x94\x00\xbdZY’ DEBUG:localtuya.pytuya:decrypted result=’{“devId”:“dev_id”,“dps”:{“1”:“3”}}’ AVAILABLE DPS ARE [{‘1’: ‘3’}]
INFO:localtuya:COMPLETE response from device dev_id [192.168.170.211].

**** deviceInfo returned OK ****

TuyaPower (Tuya Power Stats) [0.0.19]

Device dev_id at 192.168.170.211 key localkey protocol 3.3 dev_type type_0a:
DPS [1] VALUE [3]

Thanks for your help.

And here we go again, another different set of commands for covers (I believe your devices wants 1-2-3 instead of on-off-stop).
I’ll take care of this @postlund.
@pakordo, give me some time to setup a PR for you to test.

3 Likes

Thanks a lot!.

If it’s useful information, my curtain switch is this: https://templates.blakadder.com/loratap_SC400W.html

More useful than that, you could launch an opening command and post what tuyadebug reports as status (we need to understand which values are associated to the commands, from DPS [1] VALUE [3] we now that stop is associated to “3”).

1 Like

You should consider looking at the debug mode PR as that is easier to use for most people :wink:

2 Likes