Open ljmerza opened 5 years ago
Can you change the except: block to
except Exception as e:
print(e)
self.connect()
self.s.send(encrypted_packet)
and see what the exception actually is?
Got the error again and logged it. Doesn't seem to be coming from that part. It's coming from here
if response:
data = self.s.recv(1024)
if (len(data) == 0):
self.connect()
self.s.send(encrypted_packet)
data = self.s.recv(1024)
response
is true but data is empty b''
so then it calls connect again
Hello
Seeing the same error here. The wonder is it was working fine for a month till yesterday. the switch.connect() now fails with the error maximum recursion depth exceeded in __instancecheck__. I am not sure why though. I tried to debug the stacktrace but doesn't help much. It seems to try to connect repeatedly on failure and then errors out.
This is my code which actually doesn't do much
import lakeside
import sys
if len(sys.argv) < 2:
print('Please provide action On(1) Off(0)')
sys.exit()
action = int(sys.argv[1])
user = 'username'
passwd = 'password'
try:
devices = lakeside.get_devices(username=user, password=passwd)
if devices:
code = devices[0]['code']
device_type = devices[0]['type']
device_addr = devices[0]['address']
sw = lakeside.switch(address=device_addr, code=code, kind=device_type)
sw.connect()
if sw.get_status().switchinfo.packet.switchstatus.power == (1-action):
sw.set_state(power=action)
except Exception as e:
print(e)
This is the stacktrace
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 229, in connect
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 66, in connect
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 246, in update
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 242, in get_status
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 232, in send_packet
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 90, in send_packet
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 229, in connect
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 66, in connect
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 246, in update
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 239, in get_status
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 235, in get_sequence
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 115, in get_sequence
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 232, in send_packet
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 73, in send_packet
File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Cipher/AES.py", line 232, in new
return _create_cipher(sys.modules[__name__], key, mode, *args, **kwargs)
File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Cipher/__init__.py", line 79, in _create_cipher
return modes[mode](factory, **kwargs)
File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Cipher/_mode_cbc.py", line 293, in _create_cbc_cipher
return CbcMode(cipher_state, iv)
File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Cipher/_mode_cbc.py", line 95, in __init__
self._state = VoidPointer()
File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Util/_raw_api.py", line 160, in VoidPointer
return VoidPointer_cffi()
File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Util/_raw_api.py", line 151, in __init__
self._pp = ffi.new("void *[1]")
File "/usr/lib/python2.7/dist-packages/cffi/api.py", line 247, in new
if isinstance(cdecl, basestring):
RuntimeError: maximum recursion depth exceeded in __instancecheck__
Hello
Seeing the same error here. The wonder is it was working fine for a month till yesterday. the switch.connect() now fails with the error maximum recursion depth exceeded in instancecheck. I am not sure why though. I tried to debug the stacktrace but doesn't help much. It seems to try to connect repeatedly on failure and then errors out.
This is my code which actually doesn't do much
import lakeside import sys if len(sys.argv) < 2: print('Please provide action On(1) Off(0)') sys.exit() action = int(sys.argv[1]) user = 'username' passwd = 'password' try: devices = lakeside.get_devices(username=user, password=passwd) if devices: code = devices[0]['code'] device_type = devices[0]['type'] device_addr = devices[0]['address'] sw = lakeside.switch(address=device_addr, code=code, kind=device_type) sw.connect() if sw.get_status().switchinfo.packet.switchstatus.power == (1-action): sw.set_state(power=action) except Exception as e: print(e)
This is the stacktrace
File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 229, in connect File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 66, in connect File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 246, in update File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 242, in get_status File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 232, in send_packet File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 90, in send_packet File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 229, in connect File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 66, in connect File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 246, in update File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 239, in get_status File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 235, in get_sequence File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 115, in get_sequence File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 232, in send_packet File "build/bdist.linux-armv7l/egg/lakeside/__init__.py", line 73, in send_packet File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Cipher/AES.py", line 232, in new return _create_cipher(sys.modules[__name__], key, mode, *args, **kwargs) File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Cipher/__init__.py", line 79, in _create_cipher return modes[mode](factory, **kwargs) File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Cipher/_mode_cbc.py", line 293, in _create_cbc_cipher return CbcMode(cipher_state, iv) File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Cipher/_mode_cbc.py", line 95, in __init__ self._state = VoidPointer() File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Util/_raw_api.py", line 160, in VoidPointer return VoidPointer_cffi() File ".local/lib/python2.7/site-packages/pycryptodome-3.8.0-py2.7-linux-armv7l.egg/Crypto/Util/_raw_api.py", line 151, in __init__ self._pp = ffi.new("void *[1]") File "/usr/lib/python2.7/dist-packages/cffi/api.py", line 247, in new if isinstance(cdecl, basestring): RuntimeError: maximum recursion depth exceeded in __instancecheck__
For anyone facing this issue I just plugged out and plugged the device back in and it started behaving normally back again. I think there might be some state where the device still works on wifi with the app but errors out on socket connections.
you could also increase limit with:
import sys sys.setrecursionlimit(10**6)
I ran into this problem today. Solution put forth by @theryecatcher worked. Power cycling the power switch allowed my scripts to connect to the switch again.
Not sure if there is anything we can actually do about it. This just tells me I need to take the next step in my home automation and start using z-wave.
[root@docker01 eufy]# docker logs -f eufy_filter
maximum recursion depth exceeded
maximum recursion depth exceeded
maximum recursion depth exceeded
maximum recursion depth exceeded
[Errno 104] Connection reset by peer
Checking for subscription
('PM2.5 is ', '39.9')
('Switch is ', '1')
PM2.5 is too high
Fan is already on. Sleeping
I hit this rare error today too. I suppose the Eufy device or Python socket wedges itself in some manner which requires a restart. I added logging to the exception catch, and will update if I see it again.
Nonetheless, this connect() stack overflow is undoubtably a bug:
connect() -> update() -> get_status() -> send_packet(response=True) -> connect()
If send_packet() gets a zero-length response from get_status(), it will call connect(). This is an endless loop.
Digging into the root cause, forgive my rough logging, but here is the TCP session of the T1012 light in the bad state:
Send packet:
sequence: 2519593
code: "6DC4F44B922144A4"
ping {
type: 0
}
Recv 16 bytes
Decrypted packet:
sequence: 2337970683
code: ""
ping {
type: 1
}
Send packet lakeside:
sequence: 2337970684
code: "6DC4F44B922144A4"
bulbinfo {
type: 1
}
Recv 0 bytes
Recv attempt 2
Recv attempt 3
Recv attempt 4
Expected response, but no data received!
It appears the bulb is responding to a ping packet, but not a bulbinfo packet. This is repeatable (I haven't turned my light off). The light does work fine from the Eufy app, but not from lakeside.
Final update: sniffing the Eufy Android app (and using the lakeside AES keys), I can confirm the bulb also wasn't responding to bulbinfo packets from the app. This did result in state inconsistencies in the official app (e.g. if you restart the app, it didn't know the correct light state). Once the bulb was turned off/on, both the app and lakeside worked fine.
So in conclusion, this is a Eufy device bug that wedged the bulb. (My T1012 is running firmware version 3.7.) That said, even when the bulb is unable to report its state, it still responds to state changes. I wonder if lakeside could be more robust to unknown state, but at this point it may be wishful thinking. :)
I'm getting a different but I think related error. I've been getting a stacktrace fairly recently that's so long I can't paste it here without crashing my browser, so I've put it in Pastebin: https://pastebin.com/APAG76Np
I have three T1012s running the latest firmware. I'm gonna be honest, the official HA integration with this API has never worked as far as I can tell though the devs have never acknowledged this; I made a custom version with some extra dependencies defined in manifest.json which improves things somewhat to about a 50% failure rate, but the Android app has always worked perfectly so I don't think there's an issue there.
Looks to be failing here
it f ails to send so then tries to connect and then fails and keeps going until recursion depth error