Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

default22 device #56

Closed
IMCAgro opened this issue Jun 16, 2021 · 8 comments
Closed

default22 device #56

IMCAgro opened this issue Jun 16, 2021 · 8 comments

Comments

@IMCAgro
Copy link

IMCAgro commented Jun 16, 2021

Well one of my device is in

Problem :

I am tryinig get_status and its always return None.


DEBUG:building payload=b'{"gwId":"bf89e15533aa8988cd4avu","devId":"bf89e15533aa8988cd4avu","uid":"bf89e15533aa8988cd4avu","t":"1623820243"}'
DEBUG:payload generated=b"\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00\x88j\xff\xbf\xbd\xcb1y\x00\x1d=\x0f\x92\x02\x8d>\x142\x10\x8b\xffW\xa4\xfa\x13'\x04\xeb\xf2\x1a 1\x1f\x18\x93\xdah\x89\xf4\xa2\x13\xb5ku\xd3{\x19-\x91\xd5o\xdd\xb2\xcbl\xf4\xea\xc7\x98\x11\x9eFa\xe2\xec\xff\xbc]\xdc\xca\x05C\x90\xb7\x87\t\xa0e\xa2\xed\x802\x10\x8b\xffW\xa4\xfa\x13'\x04\xeb\xf2\x1a 1\x1f@AI\x9a;\x88n\xe9 \x92D\x84\xf8\xec\xd8\xc5\x9a/\x8c\nI\x9a@\xa6\xf0C\xaf\xac\xd2\xd3\xa5\x8f\xf9\x91\xe3\x08\x00\x00\xaaU"
DEBUG:received data=b'\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00,\x00\x00\x00\x01\x02:jyw\ta\xb85\xe7\xd3\x82\x1d\x9b\xb1\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7$\xb3g\xd5\x00\x00\xaaU'
DEBUG:raw unpacked message = TuyaMessage(seqno=0, cmd=10, retcode=1, payload=b'\x02:jyw\ta\xb85\xe7\xd3\x82\x1d\x9b\xb1\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7', crc=615737301)
DEBUG:decode payload=b'\x02:jyw\ta\xb85\xe7\xd3\x82\x1d\x9b\xb1\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7'
DEBUG:decrypting=b'\x02:jyw\ta\xb85\xe7\xd3\x82\x1d\x9b\xb1\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7'
DEBUG:decrypted 3.3 payload='json obj data unvalid'
DEBUG:'data unvalid' error detected: switching to dev_type 'device22'
DEBUG:Re-send b"\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00\x88j\xff\xbf\xbd\xcb1y\x00\x1d=\x0f\x92\x02\x8d>\x142\x10\x8b\xffW\xa4\xfa\x13'\x04\xeb\xf2\x1a 1\x1f\x18\x93\xdah\x89\xf4\xa2\x13\xb5ku\xd3{\x19-\x91\xd5o\xdd\xb2\xcbl\xf4\xea\xc7\x98\x11\x9eFa\xe2\xec\xff\xbc]\xdc\xca\x05C\x90\xb7\x87\t\xa0e\xa2\xed\x802\x10\x8b\xffW\xa4\xfa\x13'\x04\xeb\xf2\x1a 1\x1f@AI\x9a;\x88n\xe9 \x92D\x84\xf8\xec\xd8\xc5\x9a/\x8c\nI\x9a@\xa6\xf0C\xaf\xac\xd2\xd3\xa5\x8f\xf9\x91\xe3\x08\x00\x00\xaaU" due to device type change (default -> device22)
DEBUG:received data=b'\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00,\x00\x00\x00\x01\x02:jyw\ta\xb85\xe7\xd3\x82\x1d\x9b\xb1\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7$\xb3g\xd5\x00\x00\xaaU'
DEBUG:raw unpacked message = TuyaMessage(seqno=0, cmd=10, retcode=1, payload=b'\x02:jyw\ta\xb85\xe7\xd3\x82\x1d\x9b\xb1\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7', crc=615737301)
DEBUG:decode payload=b'\x02:jyw\ta\xb85\xe7\xd3\x82\x1d\x9b\xb1\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7'
DEBUG:removing 3.3=b'\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7'
DEBUG:decrypting=b'\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7'
DEBUG:incomplete payload=b'\xd2\xc1==\xc9\xa4\xf2\xfb\xcb\xbf\xf8\x88OyC\x97\xe7'
DEBUG:status received data=None

But if we call get status again - its normal return data. So re-send data is not working.
I think need some timeout ?

DEBUG:status() entry (dev_type is device22)
DEBUG:building payload=b'{"devId":"bf89e15533aa8988cd4avu","uid":"bf89e15533aa8988cd4avu","t":"1623820269","dps":{"1":null}}'
DEBUG:payload generated=b"\x00\x00U\xaa\x00\x00\x00\x02\x00\x00\x00\r\x00\x00\x00\x873.3\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x001G\x967\x8eS\x89\xba\xab\x96\x97\x10.\xe1\x94\xbc\xd5o\xdd\xb2\xcbl\xf4\xea\xc7\x98\x11\x9eFa\xe2\xec\xff\xbc]\xdc\xca\x05C\x90\xb7\x87\t\xa0e\xa2\xed\x802\x10\x8b\xffW\xa4\xfa\x13'\x04\xeb\xf2\x1a 1\x1f\xde\xb7\x99W\xf18\xa2\xaf1V\x87\xf1\xa1\xcb\xc4}\xa2\x85dS\xea\xa03\tr\xff\xfc-T\xc7\x97(\xe7\x8e\xee\x95\xf08\xc1\x13i\x9af\x87l#\x0e\xe5G@NC\x00\x00\xaaU"
DEBUG:received data=b'\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00K\x00\x00\x00\x003.3\x00\x00\x00\x00\x00\x00\x00N\x00\x00\x00\x01\x91e4K\x02\x17o\x1c\x81N\xac\xa0\x91\x98\xd4\xed\x95\xd2;\xa2\xfe\xffP\xd4X\xa9k@b\xb1\xf3r\xef\xc7\xf2O3\x18e\xb4\xf6\xe7\x03f\x90}\xb1nrIQV\x00\x00\xaaU'
DEBUG:raw unpacked message = TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00\x00N\x00\x00\x00\x01\x91e4K\x02\x17o\x1c\x81N\xac\xa0\x91\x98\xd4\xed\x95\xd2;\xa2\xfe\xffP\xd4X\xa9k@b\xb1\xf3r\xef\xc7\xf2O3\x18e\xb4\xf6\xe7\x03f\x90}\xb1n', crc=1917407574)
DEBUG:decode payload=b'3.3\x00\x00\x00\x00\x00\x00\x00N\x00\x00\x00\x01\x91e4K\x02\x17o\x1c\x81N\xac\xa0\x91\x98\xd4\xed\x95\xd2;\xa2\xfe\xffP\xd4X\xa9k@b\xb1\xf3r\xef\xc7\xf2O3\x18e\xb4\xf6\xe7\x03f\x90}\xb1n'
DEBUG:removing 3.3=b'\x91e4K\x02\x17o\x1c\x81N\xac\xa0\x91\x98\xd4\xed\x95\xd2;\xa2\xfe\xffP\xd4X\xa9k@b\xb1\xf3r\xef\xc7\xf2O3\x18e\xb4\xf6\xe7\x03f\x90}\xb1n'
DEBUG:decrypting=b'\x91e4K\x02\x17o\x1c\x81N\xac\xa0\x91\x98\xd4\xed\x95\xd2;\xa2\xfe\xffP\xd4X\xa9k@b\xb1\xf3r\xef\xc7\xf2O3\x18e\xb4\xf6\xe7\x03f\x90}\xb1n'
DEBUG:decrypted 3.3 payload='{"dps":{"1":true},"t":1623820269}'
DEBUG:decoded results='{"dps":{"1":true},"t":1623820269}'
DEBUG:status received data={'dps': {'1': True}, 't': 1623820269}
@jasonacox
Copy link
Owner

As you can see from the debug, a payload is generated and an attempt to send to the device happens. It detects the "unvalid" string which indicates the device needs 'device22' type. The retry logic attempts to send the same command payload again but with the 'device22' settings. It could be that it needs more time and I can add a delay, but it could also be that the payload that was generated also includes a timestamp. That device likely sees the same timestamp and responds with a Null. I need to do some testing to see what would be the right way to address that.

In the meantime, you can add retry logic to your code to make another get status call if you get a None response.

@IMCAgro
Copy link
Author

IMCAgro commented Jun 17, 2021

I had make it - just retry.But i think its normal that resend must be worked.
If need i ll test timestap, in few days - i am busy at work now(((

Tnx - its great work !

@IMCAgro
Copy link
Author

IMCAgro commented Jun 18, 2021 •
edited
Loading

Hi - i had found problem.
You are right - payload is generated inside command (in our case its status)
So this part is wrong - payload is still for device with type 'default'.

     if dev_type != self.dev_type:
            log.debug(
                "Re-send %s due to device type change (%s -> %s)",
                payload, <------- PAYLOAD is still for default and its generated inside called method 
                dev_type,
                self.dev_type,
            )
            return self._send_receive(payload, minresponse)

What i do

       def status(self):
            """Return device status."""
            log.debug('status() entry (dev_type is %s)', self.dev_type)
            payload = self.generate_payload(DP_QUERY)
    
            try:
                data = self._send_receive(payload)
                log.debug('status received data=%r', data)
                return data
            except Device22Error:
                # Potential Loop add max_retry
                return self.status()

and inside _send_receive

     if dev_type != self.dev_type:
            log.debug("Its device22")
            raise Device22Error

Its problem only with status, because payload_dict has diffrrent

   DP_QUERY: {  # Get Data Points from Device
            "hexByte": "0d",  # Uses CONTROL_NEW command for some reason
            "command": {"devId": "", "uid": "", "t": ""}
        },

another command work , its has same payload_dict as default - but need check all.
I had only one socket with default22

@jasonacox
Copy link
Owner

Great find and great suggestion... I will work on a fix!

In the meantime, the workaround would be to set the device22 setting during initialization instead of letting it detect:

d = tinytuya.OutletDevice(ID, IP, KEY, 'device22')

@jasonacox
Copy link
Owner

Ok, I added logic to send back ERR_DEVTYPE when device22 is auto-detected. The status() function now has logic to rebuild the payload and retry.

You can git pull the latest from https://github.com/jasonacox/tinytuya.git

_send_receive()

        # Did we detect a device22 device? Return ERR_DEVTYPE error.
        if dev_type != self.dev_type:
            log.debug(
                "Device22 detected and updated (%s -> %s) - Update payload and try again",
                dev_type,
                self.dev_type,
            )
            result = error_json(ERR_DEVTYPE)

status()

    def status(self):
        """Return device status."""
        log.debug('status() entry (dev_type is %s)', self.dev_type)
        payload = self.generate_payload(DP_QUERY)

        data = self._send_receive(payload)
        log.debug('status() received data=%r', data)
        # Error handling 
        if 'Err' in data:
            if data['Err'] == str(ERR_DEVTYPE):
                # Device22 detected and change - resend with new payload
                log.debug('status() rebuilding payload for device22')
                payload = self.generate_payload(DP_QUERY)
                data = self._send_receive(payload)       

        return data

@IMCAgro
Copy link
Author

IMCAgro commented Jun 22, 2021

Tnx

@IMCAgro IMCAgro closed this as completed Jun 22, 2021
@jasonacox
Copy link
Owner

@IMCAgro Just to confirm, this is working for you?

@IMCAgro
Copy link
Author

IMCAgro commented Oct 4, 2021

Yes - its works as expected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jasonacox @IMCAgro