Intermittant "905 - Network Device Unreachable" Errors #496
Comments
|
HI @horatio-g - I'm sad that your first foray into home automation is so problematic. But good job on troubleshooting!
Tuya devices are designed to be cloud first. The local API we are using for TinyTuya local control is a secondary API that the SmartLife app uses for setup and local control if available. However, if it can't access the local API it will go to the cloud (assuming you are not on your local network). That's why it will always see the device. I've had a few devices similar to yours and still have an old 3.1 version one that does the same. I wish we knew what cause them to become unstable. It may be due to a firmware memory leak that slowly eats the resources until it crashes. Anyway, I have at least one suggestion for you. Your monitor script which I assume you did get from the README, is not intended for long term use. It sends way too many status and heartbeat pings, way more than is needed. If your device has a firmware bug, it could be tripping that resource limit fast. Instead, you should have the heartbeat only sent after a time limit. You could use something from the example here: https://github.com/jasonacox/tinytuya/blob/master/examples/monitor.py STATUS_TIMER = 30
KEEPALIVE_TIMER = 12
heartbeat_time = time.time() + KEEPALIVE_TIMER
status_time = None
# Uncomment if you want the monitor to constantly request status - otherwise you
# will only get updates when state changes
#status_time = time.time() + STATUS_TIMER
while(True):
if status_time and time.time() >= status_time:
# poll for status
print(" > Send Request for Status < ")
data = d.status()
status_time = time.time() + STATUS_TIMER
heartbeat_time = time.time() + KEEPALIVE_TIMER
elif time.time() >= heartbeat_time:
# send a keep-alive
data = d.heartbeat(nowait=False)
heartbeat_time = time.time() + KEEPALIVE_TIMER
else:
# no need to send anything, just listen for an asynchronous update
data = d.receive()
print('Received Payload: %r' % data)
if data and 'Err' in data:
print("Received error!")
# rate limit retries so we don't hammer the device
time.sleep(5)I would also check to make sure your device doesn't have a firmware upgrade available. (TODO: update README with better code) |
|
Hi Jason, Many thanks for your reply with useful explanations and things to try. Ah! the old "memory leak" problem surfaces again - I remember back to my old DP days, as a junior programmer, in the late 80s, having loads of fun with those! Who would have thought, 40 odd years later and I would be hitting the same issue, this time in firmware! I have re-written my monitor script based (loosely) on the example you provided in your reply above, It seems my switch will not yield any data without the full ``Received Payload: {'dps': {'49': 'AQAAAAMAAAAEAAAA'}, 't': 1715428608}` The ratio of this type of response to the data that I am after is roughly (but not exactly) 50:50. (Mostly, the response seems to alternate between the above and a "valid" dataset. With above "key=49" type responses, the integer "t" seems to vary but the '49' data string remains constant (AQAAAAMAAAAEAAAA') Reading around this subject on the web, I found this key has something to do with "Alarm Set 2". Regardless, I have made the script check for this type of response and just cycle the With regard to the HEARTBEAT and STATUS functionality, I was finding it was giving me unreliable results and, tbh, the logic was tying me in knots! I thought I would try with the functionality for both removed. So, effectively, all my script does now is check the At the moment the script has been running as a service for most of the day without the switch becoming unreachable. However, if I still am encountering problems, I was just wondering about the capabilities of tinytuya being able to instigate a "soft reset/reboot" on the switch? This may release the memory leak and give me another day+ of processing before I need to do it again. As I say, I would want to try and automate this workaround, if at all possible, as manually cycling the switch is not practical in my case. WRT to your question about switch's firmware version, I used the SmartTuya app and found it to be 1.0.5 (if that makes sense?). Unfortunately, no updates are available:
I am also a bit lairy about using the app or Tuya portal at the same time as my monitor script is running as I read (somewhere in your documentation or somewhere else?) that the Tuya kit will only allow one TCP connection at a time? And (I may be assuming incorrectly here), that the remote connection has precedence? However, it must be said that my accessing the app and/or portal do not seem to co-incide with any "upsets" in the script's processing. Anyway, thanks for your time and effort - I hope I am now making progress :) Regards, |
It sounds like you figured that out, but this is expected. We don't know the logic on the frequency, but the Tuya devices will send updates for data points (DPS), usually as they change, but sometimes on some random basis or cadence.
Yes, that happens with some switches. I have 2 like that. My only advice there is to try to ensure the frequency of that I looked up your switch. Is this it here (link)? It occurs to me that these are likely installed inside metal boxers (breaker box?) and WiFi access could be a challenge. Since this is TCP, you wouldn't see that manifest as garbage, but it could translate to the Tuya switch having to do a lot of TCP retries, again adding to its load or exposing any resource leak. You might do some network sniffing to see if anything like that is happening and if so, see if you can adjust WiFi signal for less retry. Good luck! Please keep us updated on what you discover and if you find a good solution! |
|
Hi Jason, Thanks again for your quick and helpful response. Re that link to the switch; its VERY similar but mine is the EAWCPT-J and the pic in that link shows EAWCBT-J - not sure what the difference is :) As you can see from the price, one of the constraints of my project is "much cheapness!" ANd my Scottish-ness rebels at "trashing" anything until all hope is lost! Yes - you are right - the switch is in a metal box. But its right next to the router. I'll defo have a look into "sniffing the network" and see if there are multiple re-tries going on. (Yet another skill to acquire ... what's that about "old dogs?") Any feedback on my previously posed question as to whether there's any way I can use tinytuya to "re-boot" my switch? So far, as of now, the script, which I kicked off this morning, is still happily trundling along - so a big improvement already! (My earlier version of the script was encountering problems less than 2 hours after re-booting the switch.) Thanks again. Regards, |
|
Unfortunately there is no way to reboot a device, either from the cloud or via the local API. I've spent many hours combing through the official documentation and have even reverse engineered a couple firmware images and it just doesn't support it. I've inadvertently caused reboots by sending IR blasters bad data causing them to lock up until the watchdog fires, but that's been it. |
I did find a breakdown of the EARU EAWCPT-J here: https://www.elektroda.com/rtvforum/topic4018747.html
Awesome! Would you be willing to share your code? If anyone else runs across this device or one like it, it may be helpful. ...
Of course you did! @uzlonewolf you are amazing. ❤️ |
|
Script still running as a service, some 24+ hours later - looking promising! Current incarnation of script as follows (Keys and other sensitive info redacted with "***"): #
# Python script that uses tinytuya to extract data (Power & Voltage) from a Earu EAWCPT-J (Tuya) Smart Circuit Breaker and
# insert those values into a table ("reading") in a MySQL database
#
# Based on scripts by Jason Cox: https://github.com/jasonacox/tinytuya
import datetime, time, tinytuya, mysql.connector
# tinytuya.set_debug(True)
#
# Setting the address to 'Auto' or None will trigger a scan which will auto-detect both the address and version, but this can take up to 8 seconds
# d = tinytuya.OutletDevice('DEVICEID', 'Auto', 'DEVICEKEY', persist=True)
# If you know both the address and version then supplying them is a lot quicker
# d = tinytuya.OutletDevice('DEVICEID', 'DEVICEIP', 'DEVICEKEY', version=DEVICEVERSION, persist=True)
d = tinytuya.OutletDevice('bfd6923b26129897d0ejzv', '192.168.1.133', '********', version=3.3, persist=True)
mydb = mysql.connector.connect(
host="********",
user="********",
password="********",
database="*********"
)
print("\n\nStarting import_ashp.py - Sending Request for Tuya Switch Status...")
data = d.status()
print('Version: %r, Initial Status: %r' % (d.version, data))
if data and 'Err' in data:
print("Status request returned an error, is version %r and local key %r correct?" % (d.version, d.local_key))
print("\nStarting ASHP Power Data Retreival Loop")
while(True):
print("Send DPS Update & Receive Data...")
# payload = d.generate_payload(tinytuya.UPDATEDPS)
payload = d.updatedps(['19','20'], nowait=True)
d.send(payload)
# Ignore spurious key = '49' data - just keep receiving data until data is what we want or otherwise invalid
while data is not None and 'dps' in data.keys() and '49' in data['dps'].keys():
data = d.receive()
print('Received Payload: %s' % (data))
if data is not None and 'dps' in data.keys() and '19' in data['dps'].keys() and '20' in data['dps'].keys():
power = round(data['dps']['19']/10,1)
voltage = round(data['dps']['20'] / 10,1)
timestamp = datetime.datetime.utcnow().strftime("%Y-%m-%d %H:%M:%S")
print('Values: Timestamp = %s, Power = %d, Voltage = %d' % (timestamp, power,voltage))
cursor = mydb.cursor()
cursor.execute("REPLACE INTO reading (DateTime,Sensor,Rate,Watts) VALUES (%s,2,%s,%s)", (timestamp,voltage,power))
mydb.commit()
time.sleep(15)
else:
print('Invalid Data - Skipping')
time.sleep(5) |
|
Thanks @horatio-g ! Looking at the logic here (I updated your post so it formats as python) in comparison to the first code snip you shared, it seems like the difference is related to the less aggressive approach. The first sends both the I hope this fixes your problem long term. Keep us updated. |
|
Hi Jason I spoke to soon! The script was still running as at 30+ hours, but I wasn't paying too much attention to the data it was retreiving and inserting into my SQL table. However, this evening I was testing out some MySQL procedure trickery to generate views for "pretty graphs", from my ASHP data, when I noticed that my ASHP power demand had been remarkably static for the whole day ... in fact, far too static! Further investigation revealed that tinytuya was returning data via the data.receive() call BUT, it was returning the SAME dataset for the last 30 hours - Doh! I've tried swapping in I've got to get ready for (real) work tomorrow, so will have to leave this for now, but I thought I had better let you (and other folk) know that this not (yet) the correct solution! Will get back on it as soon as I can. |
|
You may need to put a I would write the logic so that you are also draining the response before sending anything else. Something like: flip = True
while(True):
print("Send DPS Update & Receive Data...")
flip = not flip
if flip:
payload = d.generate_payload(tinytuya.HEART_BEAT)
else:
payload = d.generate_payload(tinytuya.UPDATEDPS)
d.send(payload, nowait=True)
# Ignore spurious key = '49' data - just keep receiving data until data is what we want or otherwise invalid
while data is not None and 'dps' in data.keys() and '49' in data['dps'].keys():
data = d.receive() |
|
There's no need for a heartbeat in this case. As long as you're sending something at least every ~20 seconds or so it's not needed, it's only used to keep an idle connection open. |
The issue you're having now is because you are not calling data = d.updatedps(['19','20'], nowait=False)
# Ignore spurious key = '49' data - just keep receiving data until data is what we want or otherwise invalid
while data is not None and 'dps' in data.keys() and '49' in data['dps'].keys():
data = d.receive() |
|
Many thanks uzlonewolf & jason Under the cosh with my dayjob a bit at the moment. But had another look at this issue this morning: its not so good news re the amendment I made, as described, last above; I got another memory leak hang in less than 24 hours. But I have implemented uzlonewolf's ideas and fired teh script off again (as a service) to see if that improves things. Thanks also to uzlonewolf for the detail on the I'll let you know how it goes with the revised version of the script and, if successful, will re-publish here. Regards, Harry. |
|
Hiya uzlonewolf & jason, Just to finish off this topic and express my thanks. Here we are, some 2 weeks later, and the latest incarnation of the script continues to run without crashing. I have also added in an MQTT publish into the script, so, as well as populating my local dtatabase with the required information, I can now also pass it on to my Home Assistant implementation, running on a remote server. Here is the final script, if anybody needs it in the future. Rathe rthan redacting senstive info this time, I have replaced it with an indication of what is required at that point encased in angle brackets (<>) Thanks again, |
|
Thanks @horatio-g ! |
Hi,
Wonder if you can help me with a problem I'm having with my EARU EAWCPT-J 63A (Tuya) Switch. This is used to measure power consumption of my ASHP system. I have installed tinytuya on a RPI system, to intercept the output from the switch and populate a database. I am using a python script to do so. I followed your comprehensive guide to install tinytuya and obtain my local key
I fine tuned the python script to ignore the frequent dps request replies that did not contain the data I required (Power and Voltage). Initially, for about 2 days, the script and tinytuya worked fine.
However, I then became aware that I was getting continuous "'905' Network Error - Device Unreachable" errors in the log. A ping to the Tuya switch's local IP also yielded no response. The Tuya switch is set up as a Static IP on the router. I have also set the lease expiry to 21 days on the network table. Eventually, I found that a simple power cycle on the Tuya switch would allow it to be immediately "be seen" again AND my script would start receiving data again.
I thought that this was maybe a "one-off glitch", but about a day later, the same thing occured. The frequency of this disconnect seems to be increasing, so that I now get about 1 or 2 hours of data before the 905 error. Funnily enough, even when this error is occuring, the Tuya Smart App and the Tuya console can still "see" and "update" the switch. (I am only using the app/portal AFTER the error occurs, so it seems that it is NOT me accessing the app/portal that is provoking these errors.)
Here is the python script (with my key and other sensitive info redacted as "****" ):
and a section of the output log where this error starts:
Also, here is the output from "python -m tinytuya -nocolor -debug" (similarly redacted) :
I think the essential issue there is where it reads "Polling 192.168.1.133 Failed:"?
Trying to ping the switch's IP address yields the following:
As soon as I power cycle the Tuya switch (from the consumer board), the switch immediately reconnects again:
and
and
I know that "power cycling" is a workaround BUT I cannot do this away from the house; plus I am trying to get away from "manual intervention" but do require continuous data for my purposes. (A S-COP calculation.) Apologies for my amateur stab at a write-up on this issue but its my first foray into Home Automation. Have you any suggestions, ideas, etc as to why this is happening? If you require any info, please let me know and I'll endeavour to provide it.
Many Thanks & Regards,
Harry.
The text was updated successfully, but these errors were encountered: