Closed Oglaf closed 1 year ago
Why do you think this is a v3.5 problem? The only v3.5 device I'm seeing in those logs is "Office light" and it appears to be working fine. As for those 2 unresponsive v3.3 devices, I would check:
1) They may be in a partially-hung state and need to be rebooted
2) Double-check that the local key is correct
3) See if you can poll it using the "device22" quirk mode (i.e. d = tinytuya.OutletDevice('eb860d52d52d7d56172s3b', '192.168.1.244', '14e2fe4c41020a58', dev_type='device22', version=3.3)
then print(d.status())
)
Why do you think this is a v3.5 problem? The only v3.5 device I'm seeing in those logs is "Office light" and it appears to be working fine. As for those 2 unresponsive v3.3 devices, I would check:
- They may be in a partially-hung state and need to be rebooted
- Double-check that the local key is correct
- See if you can poll it using the "device22" quirk mode (i.e.
d = tinytuya.OutletDevice('eb860d52d52d7d56172s3b', '192.168.1.244', '14e2fe4c41020a58', dev_type='device22', version=3.3)
thenprint(d.status())
)
You are right, I have mistaken the device IDs when I was doing other tests before and quickly blamed the protocol. I will change the title to avoid confusion. I have done steps 1 and 2, will try step 3.
I found another thread where someone has a device with the same keyjup78v54myhan Product ID but is reporting protocol v3.4. I wonder if your devices are an in-between version where they're still reporting v3.3 but actually using v3.4 similar to how "device22" devices are between v3.2 and v3.3. If the 'device22' thing in my last post doesn't work then
d = tinytuya.OutletDevice('eb860d52d52d7d56172s3b', '192.168.1.244', '14e2fe4c41020a58', version=3.4).status()
+
print(d.status())
would be the next thing to try.
Thank you @uzlonewolf , yesterday I started testing tuya local and after reading the "Smart Switch Gotchas" I decided let it rest overnight and try again today.
I was surprised that leaving it unplugged overnight worked! But sometimes it still becomes unavailable if it spends too much time idle, the same behavior as my chromecast that becomes unavailable in home assistant after spending some time turned off but it comes back to life after I turn it on through google home. But in this case I have to unplug and plug it again.
Both codes throws an exception, it returns something (it's not a timeout) but it has no Status() attribute.
'NoneType' object has no attribute 'status'
I wonder if it has something to do with Overcharge Switch turned on? I noticed my other plugs doesn't have this feature. I will disable it and keep an eye on it.
You might try turning on debug to see how it responds:
import tinytuya
tinytuya.set_debug(True)
d = tinytuya.OutletDevice('eb860d52d52d7d56172s3b',
'192.168.1.244', '14e2fe4c41020a58', version=3.4)
print(d.status())
Spent the whole day yesterday doing periodic health checks and I can confirm after a few hours being Idle both plugs will stop responding to my local network. Of course, it's still works on Smart Life app.
DEBUG:TinyTuya [1.10.1]
DEBUG:status() entry (dev_type is default)
DEBUG:building command 10 payload=b'{"gwId":"eb860d52d52d7d56172s3b","devId":"eb860d52d52d7d56172s3b","uid":"eb860d52d52d7d56172s3b","t":"1676127964"}'
DEBUG:socket unable to connect (timeout) - retry 1/5
DEBUG:socket unable to connect (timeout) - retry 2/5
DEBUG:socket unable to connect (timeout) - retry 3/5
DEBUG:socket unable to connect (timeout) - retry 4/5
DEBUG:socket unable to connect (timeout) - retry 5/5
DEBUG:ERROR Network Error: Device Unreachable - 905 - payload: null
DEBUG:status() received data={'Error': 'Network Error: Device Unreachable', 'Err': '905', 'Payload': None}
Seems like a firmware "feature"? I will try to ping it for the whole day and see if I keep it "awake".
Seems like a firmware "feature"?
Haha! Well said. I have two older 3.1 devices that will suddenly stop responding locally but may or may not still connect to cloud (Smart Life app). I wish there was a way to send a "reboot" to the firmware. I haven't discovered it and didn't spend a lot of time on it since they were older. I don't know if this specific to the firmware or not.
I notice this device is called "Oven socket". I had an issue with a 3.3 device that would stop working after a while. It was an energy monitoring plug for a dryer. Eventually the plug stopped altogether. It turned out that while it was rated at 15A, it was not able to handle anything even near 10A and the startup of the dryer was spiking the limit. My theory is that when the spike happened and voltage dropped or became erratic, the firmware code or WiFi controller entered an unhandled state that effectively disabled TCP port listening. I was able to correlate it to power usage on the dryer.
After 3 days of further testing, I will close this issue. I have tested if spiking was causing this problem but doesn't seen like it. Tinytuya and Localtuya gets unresponsive but somehow it still works on tuya-local, which is fine for me.
I will take it as "It is what it is", and stay away from Avatto because I have seen many similar posts like that and it's too much coincidence to not think that Avatto customized Tuya's firmware to act like that.
The only solution I see in the far future is to switch my Tuya devices to Tasmota.
Hi @Oglaf - thanks for the update and for originally opening the issue. This helps us understand any tweaks we need to make or to help others with similar devices.
somehow it still works on tuya-local
I should have asked this earlier, what do you mean by tuya-local
? I would love to understand the difference to see if there is something we can do for our library to better support these devices.
Thanks again!
Hi Jason, tuya-local is a "new" integration for home assistant which got popular recently after some content creators made a video about it as an alternative solution to localtuya. I know they use tinytuya's for discovery but I haven't check how communication is made after that.
Ah! That's @make-all project! Jason is brilliant. He has a great project and is doing a good job trying to convince us to move TinyTuya to native async. :) Regardless, I'm recommending all HA users check out his project! 😁
It just occurs to me... you are probably running multiple tools against this plug. These Tuya devices don't handle multiple connections very well at all. Since tuya-local is using the persistence setting in TinyTuya (keeping the connection open) there is a real possibility that the issue is that tuya-local in HA has the device open so you can't use your own script (or would get the timeout errors). You may likely see the same thing if you used the Smart Life app while trying to run your script.
tuya-local is using tinytuya underneath (for everything except discovery, actually, as I haven't yet gotten around to adding support for that), so if that works, then tinytuya works. As Jason says, the problem is more likely to come from the device not handling multiple connections than from tinytuya itself.
Hello again, new device, new errors. This time is an Avatto 20A socket. Looks like a protocol 3.5 error.
Snapshot:
Devices:
Scan:
debug: