Device never fully connects

[rawbengal]

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)
                        )

[yozik04]

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?

[rawbengal]

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

[yozik04]

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...