Tuya LOCAL with energy monitoring and without tuya-convert

Then you could enable debug level for logging and have a look at the log file.
However, since you are saying that also the first gang stops working, maybe you have some problem with the config file, like bad spacing. The log should show something, in this case. You could also try to simply replace id 1 with 2 or 7 and see if the second gang works: if it does, then you do have a problem in file formatting or spacing.

I tried to do this and it didnā€™t work eitherā€¦

  • platform: localtuya
    host: 10.0.0.229
    local_key: xxxxxxxxxxxxxx
    device_id: xxxxxxxxxxxxxxxxxxxxxx
    name: tuya_dining
    friendly_name: tuya_dining
    protocol_version: 3.3
    switches:
    sw02:
    name: tuya_dining
    friendly_name: Dining Room Light
    id: 2
    the switch was not thereā€¦

Then try 7 instead of 2. If other numbers fail, I repeat you to enable debugging and have a look at the logs, in particular we need to get the request response.
I donā€™t mean to be rude, but you have to provide more information, you canā€™t just say ā€œIā€™ve got this problem, please fix itā€: problem solving requires information and analysis.

As I said, the current caching interval is not configurable. I was not remembering well, I had actually set it to 15 seconds, as you can see in switch.py :

        if not self._cached_status or now - self._cached_status_time > 15:

This means that when a status update request arrives from HA, the status values are not actually updated more frequently than 15 seconds from the last request. I would not take this value below 5 s, since I noticed that the handshake process usually takes about 2-3 secs. I donā€™t know how changing this value affects HA performance, also. But apart from that, how often is the status update requested by HA and how to change its frequency is beyond my knowledge, maybe there are more skilled developers that can provide an answer to this. So, if you need a more frequent update youā€™d probably need to stick to Node-red, or reduce the caching interval and have some kind of automation that forces the update with the frequency you desire.

Hi Carlo,
it seems that from what Iā€™m seeing, localtuya updates switch attributes every 3 minutes or so.
Other switches are working fine, updating every 15 seconds or so.

Is there any reason for this?

As I wrote in my last message, I really donā€™t know. The __get_status message is implemented and caches status values every 15 seconds, but I think it is called by HA and I really donā€™t know how frequently and how to change its frequency. Maybe some more HA skilled developer can answer this??
Edit: searching the documentation, I came into this page:

Can anybody try to specify this scan_interval parameter and see if the status is updated more frequently? Please share your findingsā€¦

Hmm, doing further tests, and I think that the interval issue could not be related to localtuya.
I tried also with scan_interval parameter and I donā€™t see a difference, but Iā€™m seeing very slow updates on power consumption also from GRID Connect App (a Tuya Smart clone which I used to retrieve the localkey).
I donā€™t know if, maybe, the plug does not update the power consumption attribute if the value is similar to the previous polling.
I donā€™t really understand these plugsā€¦

1 Like

You told me to try to 2. I already tried 7 and if you look back in form you could see it and no Iā€™m not saying fix this without any analyzing.

@ranski1999 Your reply seems a little bit rude to meā€¦
This a community. No one is forced to do anything. Please, remember it

And his wasnā€™t

@Roberto_Boscaro according to what @rospogrigio was suggesting last day, Iā€™m trying ā€˜scan_interval:15ā€™ with two of the six plugs that I own. Just to see the differences, if there are any.
Iā€™m going to let you know if I found out something

Hello!

Perfect work!!!

But after update last git version and change pytuya/init.py heve this

Failed to update status of device [192.168.0.58]
2020-08-04 21:54:31 DEBUG (SyncWorker_3) [custom_components.local-tuya.pytuya] result=b'F(\xa5u8j\xb7\x94\x8f\xaa\x19\xe2\xe8o\xa2\xf1\xe4'
2020-08-04 21:54:31 DEBUG (MainThread) [homeassistant.components.mqtt] Transmitting message on hass/status: online
2020-08-04 21:54:32 DEBUG (SyncWorker_3) [custom_components.local-tuya.pytuya] status() entry (dev_type is device22)
2020-08-04 21:54:32 DEBUG (SyncWorker_3) [custom_components.local-tuya.pytuya] json_payload=b'{"devId":"bf741080a98437beebdwm5","uid":"bf741080a98437beebdwm5","t":"1596567272","dps":{"1":null,"18":null,"19":null,"20":null,"101":null,"102":null}}'
Failed to update status of device [192.168.0.58]
2020-08-04 21:54:32 DEBUG (SyncWorker_3) [custom_components.local-tuya.pytuya] status received data=b'\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00K\x00\x00\x00\x003.3\x00\x00\x00\x00\x00\x00\x06U\x00\x00\x00\x01\xab5\xea\x04\x83\xd7R\x91\x0b\xff\x86eF\xeaa\xec\x0e\xdc\x854-\xe4\x82\xdd.\x04\x8au /\xbf\x13\x19\xbd\x12v\x8cE7&\xce\xae\xd6RP\x89\xe7\x07\x08\x08"+\x00\x00\xaaU'
2020-08-04 21:54:32 DEBUG (SyncWorker_3) [custom_components.local-tuya.pytuya] result=b'\xab5\xea\x04\x83\xd7R\x91\x0b\xff\x86eF\xeaa\xec\x0e\xdc\x854-\xe4\x82\xdd.\x04\x8au /\xbf\x13\x19\xbd\x12v\x8cE7&\xce\xae\xd6RP\x89\xe7\x07'
2020-08-04 21:54:33 DEBUG (SyncWorker_3) [custom_components.local-tuya.pytuya] status() entry (dev_type is device22)
2020-08-04 21:54:33 DEBUG (SyncWorker_3) [custom_components.local-tuya.pytuya] json_payload=b'{"devId":"bf741080a98437beebdwm5","uid":"bf741080a98437beebdwm5","t":"1596567273","dps":{"1":null,"18":null,"19":null,"20":null,"101":null,"102":null}}'
Failed to update status of device [192.168.0.58]
2020-08-04 21:54:33 DEBUG (SyncWorker_3) [custom_components.local-tuya.pytuya] status received data=b'\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\r\x00\x00\x00,\x00\x00\x00\x01i\x12\xea\x9d\xb1\xe4\xa5\x99\xba<A<\x8f\xf3GF(\xa5u8j\xb7\x94\x8f\xaa\x19\xe2\xe8o\xa2\xf1\xe4\xf7,Ml\x00\x00\xaaU'
2020-08-04 21:54:33 DEBUG (SyncWorker_3) [custom_components.local-tuya.pytuya] result=b'F(\xa5u8j\xb7\x94\x8f\xaa\x19\xe2\xe8o\xa2\xf1\xe4'
2020-08-04 21:54:34 ERROR (SyncWorker_3) [custom_components.local-tuya.switch] Failed to update status of device 192.168.0.58
2020-08-04 21:54:35 ERROR (MainThread) [homeassistant.components.switch] Error while setting up local-tuya platform for switch

Traceback (most recent call last):
  File "/config/custom_components/local-tuya/switch.py", line 139, in __get_status
    status = self._device.status()
  File "/config/custom_components/local-tuya/pytuya/__init__.py", line 349, in status
    result = cipher.decrypt(result, False)
  File "/config/custom_components/local-tuya/pytuya/__init__.py", line 87, in decrypt
    raw = cipher.decrypt(enc)
  File "/usr/local/lib/python3.8/site-packages/Crypto/Cipher/_mode_ecb.py", line 195, in decrypt
    raise ValueError("Data must be aligned to block boundary in ECB mode")
ValueError: Data must be aligned to block boundary in ECB mode

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 180, in _async_setup_platform
    await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
  File "/usr/local/lib/python3.8/asyncio/tasks.py", line 483, in wait_for
    return fut.result()
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/local-tuya/switch.py", line 110, in setup_platform
    TuyaDevice(
  File "/config/custom_components/local-tuya/switch.py", line 189, in __init__
    self._status = self._device.status()
  File "/config/custom_components/local-tuya/switch.py", line 170, in status
    self._cached_status = self.__get_status()
  File "/config/custom_components/local-tuya/switch.py", line 147, in __get_status
    raise ConnectionError("Failed to update status .")

ConnectionError: Failed to update status .

As I wrote, the ā€œData must be aligned to block boundary in ECB modeā€ error is a pain in the arse to debug. You wrote that you get the errors after the update and changing the init.py ā€¦ do you mean that before that everything was working? Can you revert back to a working situation and change things one step at a time so we can understand which change broke the system?

Unfortunately, I reinstalled HA completely and cannot go back to the previous version.

Sorry @Sergeus but I must ask you to be a bit more specific. You donā€™t need to revert to the previous version of HA since localtuya is working since at least ver. 109, but you might (or actually should) have stored some snapshot of a working configuration, and maybe you can revert to those configuration de-selecting to downgrade the HA version. If you never saved a snapshot of your system, start doing it from NOW.
Then you should answer these questions:

  1. has localtuya ever been working? how was it installed then?
  2. was it working completely or you were missing the voltage/power values too?
  3. what changes did you do that ended up in breaking the system?
    Please also double check that you localKey is still valid, since sometimes that can be the problem.

So, Iā€™m having a different issueā€¦ I cant even get it to load. I copied the localtuya folder to custom_components (alongside hacs and others), but for some reason itā€™s not loadingā€¦ All my other custom components load just fine - do you have any idea as to what could be wrong @rospogrigio?

Iā€™m not seeing anything about it in my logs, not even when logger is set to debug-mode.

@Yusi Mmmā€¦ it happened to me also in the past and canā€™t remember how I managed to fix itā€¦ have you defined at least one device using the localtuya platorm?
Another thing I would try is to install the repo using HACS instead of copying manuallyā€¦ you have to add it as a custom repository by going into Community -> three dots on the upper left part of the screen -> Custom repositories, and then inputting the repo URL in the popup window, selecting Integration as Category.
Let us know if it worksā€¦

Good news is, I managed to install it. Bad news is, seems like its not supported. I dont get any dps (like, at all). I only got gwId and devId. Itā€™s not strictly a tuya device, but itā€™s configured via Tuya (this one from nedis).

It was worth a shot. I also looked at flashing firmware via tuya-converter, but apparently the firmware is to new. Guess that was a wasted purchase then.

@Yusi Strange, your device is used with SmartLife, which is a variant of Tuya, so it actually should work. You should try to sniff the communication with the Tuya app (or actually, I use a certain release of Jinvoo app, another variant of Tuya) and see which dps values are returned by the device, and set them as null in the request. Try harder and I believe it should work.

Hi everybody, I published an update of the integration (v.1.0.1), which sends in the payload only the dps actually found in the configuration, so it is no longer needed to patch the code adding the ā€œ18ā€:null, etcā€¦
Tell me if it works for everybody, bye!

1 Like