Device never fully connects
rawbengal opened this issue · 3 comments
It looks like, in client.py, there is a missing case to break out of the loop to receive a response. After sending "get sleep," a NUMERIC result is received but "finished" is never set to True. This means that it will ignore the result and go back to waiting for a reply and eventually time out.
I think "finished=True" is needed around line 283
Stylistically, this may not be the best solution though, so I have left it to you, rather than submit a merge request.
-rob
res_len = len(response)
if res_len == 0:
finished = True
elif res_len == 1: # is response code
response_code = response[0]
if response_code == 0x01: # success
result = True
finished = True
else:
raise CommandFailed(command, response_code)
else:
#### NEED TO BREAK OUT OF LOOP
finished = True # <-------------------
type_ = response[0]
raw = response[1:]
if type_ == ResponseType.PAGE: # Page ID
data = raw[1]
elif type_ == ResponseType.STRING: # string
data = raw.decode(self._encoding)
elif type_ == ResponseType.NUMBER: # number
data = struct.unpack("i", raw)[0]
else:
logger.error(
"Unknown data received: %s" % binascii.hexlify(response)
)
It should not break out from the loop until it gets command response code from serial. This is second message it receives. I’ll take a look deeper later. But this code works for me and at least one other guy. What problem are you getting? It does not connect? Can you provide me a debug log?
I just tried reproducing the problem so I could send you log files and am unable to do so. It connects properly now. Here is the log.
2020-04-26 10:02:19,544 - INFO - Connecting: /dev/tty.usbserial-12345678, baud: 9600
2020-04-26 10:02:19,549 - INFO - Connected to serial
2020-04-26 10:02:19,549 - DEBUG - sent: b'DRAKJHSUYDGBNCJHGJKSHBDN'
2020-04-26 10:02:19,588 - DEBUG - received: b'1a'
2020-04-26 10:02:19,723 - DEBUG - sent: b'connect'
2020-04-26 10:02:19,812 - DEBUG - received: b'63XXX'
2020-04-26 10:02:19,813 - INFO - Address: 30601-0
2020-04-26 10:02:19,813 - INFO - Detected model: NX3224K024_011R
2020-04-26 10:02:19,813 - INFO - Firmware version: 142
2020-04-26 10:02:19,813 - INFO - Serial number: XXX
2020-04-26 10:02:19,813 - INFO - Flash size: 16777216
2020-04-26 10:02:19,814 - DEBUG - sent: b'bkcmd=3'
2020-04-26 10:02:19,844 - DEBUG - received: b'01'
2020-04-26 10:02:19,846 - DEBUG - sent: b'get sleep'
2020-04-26 10:02:19,876 - DEBUG - received: b'7100000000'
2020-04-26 10:02:19,877 - DEBUG - received: b'01'
2020-04-26 10:02:19,877 - INFO - Successfully connected to the device
[...]
finished
Previously, the last "received: b'01'" was not there and, instead there was a timeout from "get sleep" message. It would then loop several times, trying to connect.
The one (big) difference from my previous test and now was that I connected the device to the Nextion Editor software and it updated the firmware from 99 to 142. I suspect that the older firmware has different behavior but, without being able to roll back the firmware version, I am unable to reproduce this.
Feel free to close this issue, but it is possible you may see this again with people on older versions of firmware.
Thanks for putting this module together,
Rob
Hmm, interesting. Reopen if you see this again. 01
is not sent when bkcmd=3
fails. bkcmd
tells nextion device to send command result code all the time, not only when it fails. It is not default behaviour. Maybe I need to ditch that...