Tuya LOCAL with energy monitoring and without tuya-convert

Maybe the id of the second gang is not 7… Have you tried 2? In any case you should get the id sniffing the communication like some users did, or enabling the debug and watching the response message… Give it a try and let us know!

I am very glad to hear that some of you have solved their problems.
Yes, my library follows the same approach used by @mileperhour and @NameLessJedi, and the status is cached and requested every approx. 30s, or when a command is sent. One improvement could be to have this interval configurable, and maybe separate the status and voltage/current update intervals.
Regarding what @raimangsxr wrote, I never noticed the local keys changing, unless the device could not communicate any longer and had to be reconnected to the Tuya app: in that case the local key changes.
At least, this is my experience…

I tried id 2 and it did the same thing. I don’t know about id sniffing.

Hi Carlo,
do you know which file must be modified to configure the time interval for the request to update the values?

@raimangsxr I also use the smart life app, combined with your local tuya repository, but I have not noticed the variation of the local key on my sockets.

Thanks again

Good night

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
    local_key: xxxxxxxxxxxxxx
    device_id: xxxxxxxxxxxxxxxxxxxxxx
    name: tuya_dining
    friendly_name: tuya_dining
    protocol_version: 3.3
    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


Perfect work!!!

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

Failed to update status of device []
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 []
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 []
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
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
  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.