clach04 / python-tuya

Python interface to ESP8266MOD WiFi smart devices from Shenzhen Xenon. NOTE I'm not using any devices with this library so I can't test :-(
MIT License
239 stars 54 forks source link

Sometimes "Connection Refused" occurs #31

Open LucidSkyWalker opened 6 years ago

LucidSkyWalker commented 6 years ago

Hi together,

I am using python-tuya in my Snips Home Automation. It works fine, but sometimes I get a "Connection Refused". I know that it is blocked when the App is open (you think there is a possiblity work around?), but also if the Mobile App is closed I sometimes get a "Connection Refused".

When I reopen the App, turn off and on the light switches and then close the app it is working again...

Do you have any idea or solution for this?

Thank you for your python library!!! Most of the time it works really nice :))

BillSobel commented 6 years ago

The devices only accept one TCP connection, if the connection is used then another connection can not be made. You would need custom firmware to fix this.

One option for the most compatibility would be to firewall your mobile device so it can not talk to the devices directly, it will automatically fall back to MQTT. This way your HA system can always rely on TCP being available.

In my home seer plugin I support MQTT as well, for exactly this reason. I hope at some point this project supports it (the work to do TCP covers MUCH of the MQTT requirements, including encryption and what not).

Cheers, Bill

On Fri, Jul 20, 2018 at 4:26 AM, LucidSkyWalker notifications@github.com wrote:

Hi together,

I am using python-tuya in my Snips Home Automation. It works fine, but sometimes I get a "Connection Refused". I know that it is blocked when the App is open (you think there is a possiblity work around?), but also if the Mobile App is closed I sometimes get a "Connection Refused".

When I reopen the App, turn off and on the light switches and then close the app it is working again...

Do you have any idea or solution for this?

Thank you for your python library!!! Most of the time it works really nice :))

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/clach04/python-tuya/issues/31, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLj6CSHXsnXnRUU4VFCut737Xan6DxDks5uIaJTgaJpZM4VXudd .

t0ny-peng commented 6 years ago

@BillSobel Hi Bill, I also have this connection refused problem with my plugs. So you mean, the mobile application Tuya has two methods to communicate with the devices:

  1. via TCP if Tuya app and plug are in the same LAN.
  2. via a MQTT broker provided by Tuya. App publishes a message to the broker topic which is listened by the plug.

Is that right? If so, is there any possible way to configure the MQTT broker address inside the plug? I assume it's fixed in the firmware.

BillSobel commented 6 years ago

Correct but also correct it’s hard coded in the firmware. Bill

Sent from my iPhone please excuse any typos.

On Oct 29, 2018, at 12:29 AM, Hao Peng notifications@github.com wrote:

@BillSobel Hi Bill, I also have this connection refused problem with my plugs. So you mean, the mobile application Tuya has two methods to communicate with the devices:

via TCP if Tuya app and plug are in the same LAN. via a MQTT broker provided by Tuya. App publishes a message to the broker topic which is listened by the plug. Is that right? If so, is there any possible way to configure the MQTT broker address inside the plug? I assume it's fixed in the firmware.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

caffeinatedMike commented 6 years ago

@clach04 I also receive this error on a occasion & the device's state remains unchanged when it occurs. Typically, if I retry toggling the switch the device's state does successfully change (after a second or third try of toggling). So, I have a proposition, I think it'd be beneficial to add a try/except within a loop with range(3) to try changing the state up to three times to minimize these issues. Does that change seem like something you would allow?

For reference, I think this function is what we'd need to implement the proposed solution to.

    def _send_receive(self, payload):
        """
        Send single buffer `payload` and receive a single buffer.

        Args:
            payload(bytes): Data to send.
        """
        for i in range(3):
            try:
                s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
                s.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
                s.settimeout(self.connection_timeout)
                s.connect((self.address, self.port))
                s.send(payload)
                data = s.recv(1024)
                s.close()
                return data
            except socket.error:
                continue