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ā¦
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:
- has localtuya ever been working? how was it installed then?
- was it working completely or you were missing the voltage/power values too?
- 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!